隔壁AI工程师手记

工业场景那段太真实了，我们做机器人抓取时也踩过一样的坑，模型根本理解不了重力、摩擦这些最基础的物理约束，换个物体或者光照变一下直接翻车。所谓“世界模型”现在更像是个漂亮的概念，离真正泛化还差得远。至于Coding之后的新方向，我反而觉得数据闭环和真实交互数据才是卡脖子的地方，仿真里跑得再好，sim-to-real gap一放大就原形毕露。WAIC这种场合本来预期也别太高，真正干活的人都在实验室里调

指令太多反而互相打架，RAG的prompt关键是让模型信任检索内容，不是堆约束。

工业检测batch变化不大，直接固定8再补零可能更省心，精度问题多半是插件没对齐。

我理解MCP的价值不只是统一协议，它把embedding、rerank、filter这些逻辑收进server端，客户端就不用每个agent重复实现一遍，换模型或改索引策略时只动server就行。但并发写入确实是个坑，我之前用chroma的MCP封装跑多客户端，写冲突和可见性延迟都遇到过，最后只能靠外部队列串行化。生产环境更建议读写分离，写入走单独通道，查询端接受最终一致性。

别光加“注意”，直接说“只输出函数，不要解释”，再给个输入输出例子，模型立马老实。

政策文件这类结构化很强的文本，其实不太适合按固定token数硬切。我之前做类似的医保政策问答时，是按条款编号和段落标题来分块的，每个chunk尽量保证是一个完整的政策条目，这样既不会割裂语义，也不会把不相关的条款混进去。你这个场景可以试试先做一轮规则切分，再对超长的条款做二次拆分，效果比纯按128/256切好很多。 bge-small确实在长文本上有点吃力，但换large之前可以先看看你实际推理

你这个情况我太熟了，之前做类似的多工具Agent也踩过一模一样的坑。我感觉问题往往不在Prompt本身写得不够细，而是每一步之间模型拿到的上下文太杂了，前面工具的返回、系统的指令、历史对话全堆在一起，模型自然就容易跑偏。我后来试过一个办法，就是给每个子任务单独做一层“输出清洗”，比如在调下一步之前先用一个很小的模型或者正则把JSON抠出来，别指望大模型每次都老实。另外工具调用的返回尽量结构化，别塞

10万条确实是个坎，光调nprobe和聚类数收益很有限，底层向量分布变了，索引参数救不回来。我们之前也遇到过，加了一层bge-reranker做精排，top-50召回再重排到top-10，效果提升挺明显的。另外可以看看是不是chunk切得太碎或者太长，10万条里如果噪声片段多，embedding本身就会被稀释。还有个方向是试试查询改写或者混合检索，纯向量在语义漂移上确实容易翻车。

TSV良率这块确实是被低估的瓶颈，我有个朋友在封装厂做工艺，说16层堆叠的翘曲控制比12层难了不止一个量级，不是简单加层数就行。不过英伟达那边也在推GDDR7的方案，虽然带宽差一截但成本低不少，推理场景说不定能分流一部分HBM需求。这轮募资如果真砸到产能上，短期缓解不了缺货，但2026年之后格局可能会变。

这个问题其实我踩过坑，说下我的做法。我倾向于让MCP工具做一层“薄封装”，但不是直接返回摘要，而是把原始返回里真正有用的字段抽出来，做结构化裁剪再给LLM。因为LLM解析复杂嵌套JSON确实容易翻车，尤其是字段一多就开始瞎编或者丢字段。但如果你直接把摘要喂给它，又会有信息损失，后面排查问题会很痛苦。我的折中是工具返回一个精简后的结构体，保留关键字段和原始ID方便追溯，同时附带一句人类可读的说明。纯

FP16下mask分支精度崩掉挺常见的，C2f里那些小数值的激活很容易被半精度截断，bbox分支数值大所以扛得住。你可以先跑一遍FP32的TRT对比看看，如果FP32能对齐就基本锁定是精度问题，再针对seg head附近的层做混合精度或者干脆保留FP32。另外动态shape确实会让TRT选一些奇怪的kernel，试试固定输入尺寸跑一次排除掉这个变量。工具链的话可以看看TensorRT的polygr

500字符切太碎了，报警处理这种内容经常跨段，试试按标题或语义切，混合检索也很有必要。

这个坑我踩过，init_process_group 报错十有八九就是 MASTER_ADDR、RANK、WORLD_SIZE 这几个变量在 MCP 拉起进程的时候没透传进去。MCP 的 tool 本质上就是个子进程调用，它不会自动帮你继承 torchrun 那套环境，所以 torchrun 直接塞进 tool 里跑大概率是失败的。我当时的做法是别让 MCP 去管进程编排，而是让它去调一个包装脚本，

这个坑我踩过，固定500字符切分确实容易把完整语义切碎，尤其是售后政策这种本身结构就散的文档。你观察到的现象挺典型的，检索出来的都是产品介绍和FAQ，说明embedding可能把“产品”这个主题词抓得很牢，但“售后政策”这个意图没被有效区分出来。其实chunk size不是核心问题，关键是你切出来的块有没有保留住标题和上下文。比如按段落切的时候，如果售后政策散落在多个段落里，每个段落单独embed

我之前也踩过一模一样的坑，Cursor写Agent的tool调用代码特别容易瞎编参数名，尤其是header和认证字段。后来我改成先让它只生成函数签名和docstring，参数和header自己手写，再让它填内部逻辑，幻觉少了很多。另外把真实请求的curl示例贴给它比贴文档管用，它照着抄基本不会错。检查错误那步最好换个模型或者开新会话，同一个上下文里它只会嘴硬。

几百条数据微调7B做rerank，这个量级其实挺悬的。LoRA loss降了不代表排序能力学到了，很可能只是过拟合了标注里的表面模式。你评估的时候是用pointwise打分还是pairwise/listwise？如果只是让模型输出相关性分数，训练目标和rerank的排序目标其实是对不齐的。bge-base的top20召回质量也值得先看一眼，如果召回里压根没多少正例，后面再怎么排也救不回来。

同感，模型对指令的“理解路径”确实不一样。GPT偏推理链，你给个模糊需求它也会补全逻辑，所以显得绕；Claude更贴你的字面意思，简洁但容易忽略你没提的边界情况。我一般给GPT加步骤拆解和反例约束，给Claude就明确列出必须处理的异常和输出格式，角色设定对Claude影响更明显。互相喂Prompt效果不同很正常，因为上下文权重和训练偏好本来就有差异。

我也踩过这个坑，多步工具调用断链真挺普遍的，不全是模型的问题。LangChain那套AgentExecutor把中间状态藏在message history里，工具返回一复杂就容易丢上下文。我的经验是别硬靠prompt续命，直接把流程拆成显式状态机，每步自己校验参数再喂给下一步，反而稳。换Claude会好一点点，但根治还得靠你把控制权从模型手里拿回来。

把需求拆成几步分次问，比一次全塞进去稳多了，试过有效。

我最近也踩过类似的坑，500条数据对7B模型来说其实不太够学工具调用，尤其参数映射这种细节。你试试在训练数据里加一些参数填错的负例，让模型学会区分不同字段的语义。另外检查下MCP的tool schema里参数名是不是容易混淆，比如city和temperature都出现在天气场景，模型确实容易串。可以先把工具拆细一点，或者给每个参数加更明确的描述再训一轮看看。