04201. 职场学习簿
Lv.1Coder，长期记录真实项目中的技术选择，技术方向以软件工程为主。持续整理架构设计、开源工具使用和可复用的工程方法；更关注能够真正落地的方法。
发表的评论
空结果就直接告诉模型“查询返回空”，别让它自己解释原因，格式化一层比塞原始JSON稳。
32B本地跑跨文件确实容易脑补，6000token不算长，试试把无关文件去掉只留接口定义？
我们之前也试过把MCP塞进训练循环，异步那块确实头疼，后来干脆把请求攒成batch在step之间统一发，牺牲一点实时性换训练稳定，卡顿基本没了。多卡那边全局连接池肯定撑不住，我们改成每个rank自己起一个轻量client，会话隔离之后并发才稳下来。另外你可以看看把MCP调用放到单独的服务进程里，用队列跟训练进程通信，别让它跟DataLoader抢线程。
我之前也踩过这个坑，问题大概率不在chunk size本身，而是文档结构没利用好。你试试在切分前把标题层级带上，每个chunk前面拼上它所属的章节路径，比如“售后政策 > 退换货 > 时间限制”，embedding对这类上下文很敏感。另外overlap可以给到100-150字符，500有点偏碎了，细粒度问题反而容易丢上下文。如果文档本身结构清晰，基于标题递归切分（LangChain里有现成的）比固
有没有更详细的教程推荐？
MCP目前对PyTorch支持确实不完善，硬塞进distributed backend基本走不通，建议先看看官方有没有roadmap。
我遇到过类似情况，纯靠Prompt确实容易翻车。后来把意图判断拆成两步：先让模型输出结构化的意图标签（天气/日历/其他），再根据标签路由到对应工具，准确率稳了不少。Function Calling本身不适合做歧义消解，它更像执行层而不是决策层。你可以试试在调用前加一个轻量分类节点，哪怕用规则兜底都比硬调强。
7B模型确实容易把示例当模板套，试试把示例删到1个或换成反例，效果可能反而稳。
参数格式没对齐吧，微调数据里tool_call的schema得跟推理时完全一致才行。
我遇到类似情况时会在server端先做一层转换，把图片单独抽出来走多模态content block，而不是塞进文本模板里。MCP本身支持返回image类型的内容块，模型对那种结构化输入的识别比纯base64字符串靠谱得多。你可以试试把JSON和图片拆成两个content项，模板里只留JSON的占位符，图片让它走原生通道。如果非要在模板里处理，至少加个前缀标记比如“以下为二进制图像数据，勿解析”，但
试试device_map="auto"配合4bit量化，显存能压到8G左右，基本能跑。
我一开始也跟你一样纠结，后来发现官方那些（比如Filesystem、GitHub）其实胜在代码透明、权限声明清楚，但功能往往比较克制。社区项目确实有些很香，比如能连数据库或者调内部API的，但风险就在于你得自己读一遍它到底开了哪些tool、有没有偷偷把数据往外发。我的习惯是先在隔离环境里跑，比如单独建个测试目录，别一上来就给它整个home或者项目根目录。另外可以看它的server配置里有没有限制路
分块这事确实容易踩坑，512字符对FAQ太粗了，一句话的问答被切碎或者跟无关内容混在一起，召回肯定飘。你可以试试按标题层级切，再把长段落拆成语义完整的句子块，bge这类模型对完整句子更敏感。另外问“如何修改密码”却召回“复杂度要求”，大概率是query和chunk的语义粒度不匹配，加一层cross-encoder重排会明显改善，但别指望它救回压根没召回的正确答案。粗召回+重排这套组合我这边实测有用
工具定义塞上下文这个问题确实很典型，我踩过类似的坑。之前挂了六个MCP server，光工具描述就吃掉小一万token，模型选工具时明显犹豫，偶尔还会把参数拼串。后来改成按需加载，只在特定任务里挂对应的server，响应速度立马回来了。生产环境我们目前稳定跑三个：一个数据库、一个内部API网关、一个文件系统，其余的都做成动态注册，需要时再拉起来。七八个同时挂着说实话有点奢侈，除非你的路由层做了很精
嵌入式部署的话建议直接看TensorFlow Lite，PyTorch那边edge端还是折腾些。
2万条数据其实不算少了，BERT微调一般够用，问题大概率出在类别不均衡和验证集划分上。你试试分层抽样切验证集，再检查下标注质量，200条的稀有类很容易被错标拖累。另外3个epoch对法律文书这种细粒度任务可能已经过拟合了，先跑1-2个epoch看early stop效果。数据增强不如先做数据清洗和分层采样，换大模型反而更容易在小类别上崩。
在项目根目录建个.cursorrules文件，把命名规范写进去，它补全时就会优先参考了。
3000字输入在A10上OOM其实不奇怪，KV cache这块int8权重帮不了你，长序列的cache占用才是大头。你试试vLLM部署，开paged attention和gpu_memory_utilization限制，并发也能扛一些。另外确认下是不是max_model_len设太大了，那个会预分配不少显存。7B跑24G单卡长文本本来就紧，量化只是缓解权重部分。
MCP确实不是干这个的，它管的是模型和外部工具/数据源之间的上下文传递，不是模型推理本身。你那个“context not found”多半是因为PyTorch那边没有按MCP的schema返回结构化context，Flask裸包一层肯定对不上。我自己是拿FastAPI做中间层，把PyTorch模型包成MCP server的一个tool，模型加载和生命周期在server启动时搞定，调用时只传prom
工具调用这块确实容易翻车，我的经验是别指望模型一次就调对，得在prompt里把参数格式和边界情况写死，再加一层JSON schema校验兜底。另外重试机制也很关键，但别傻重试，要区分是网络超时还是模型返回格式错，后者重试基本没用。我最近在试把工具拆细一点，每个工具只干一件事，成功率明显上来了。