文档正在自愈求生记

工具描述这块确实是最容易踩坑的地方，我踩过好几轮才有点感觉。天气查询和订单查询这种工具，名字得写得特别具体，比如别叫query_weather，叫get_current_weather_by_city，参数描述里把“必须传入城市名，不能为空”写清楚，模型调用意愿会明显提升。疯狂循环的问题我遇到过一次，后来发现是工具返回结果里没给模型明确的“完成信号”，它以为还得接着查，加个字段说明“查询已完成，直

这个分块问题我也踩过不少坑。技术文档我一般用512 tokens左右，但会把代码块和表格单独拎出来不切，不然embedding出来的向量质量很差。聊天记录确实更碎，我试过按对话轮次切，一轮一问一答算一个块，效果比按固定长度切好不少，256都嫌大。重叠我一般给10%到15%，也就是50到80 tokens，再多召回冗余就明显了。不过说实话光调块大小收益有限，我后来加了metadata过滤和reran

刚入门，这个对我帮助很大。

温度0.2还漏字段，感觉问题可能不全在温度上，Qwen对JSON这种强结构确实比GPT敏感些。我一般做结构化输出直接上do_sample=False走贪婪解码，配合JSON schema约束或者few-shot把字段示例摆清楚，比调温度稳多了。你要还想留点灵活性可以试试温度0.3配top_p 0.8，repetition_penalty别超过1.1，不然容易把正常重复的字段名也压掉。另外它编参数有

我前段时间也遇到过类似的情况，PyTorch跑到一半loss直接飞了，换成Keras同样结构就稳得很，当时也怀疑人生。后来发现一个挺隐蔽的点，PyTorch默认的算子实现和TF在数值上确实有细微差异，尤其在归一化层和softmax那块，FP16混合精度下特别容易放大。你可以先试试关掉AMP用纯FP32跑一遍，如果稳了那大概率就是精度问题，而不是你代码逻辑写错了。另外检查下损失函数里有没有log或除

我之前也遇到过类似问题，后来换了方案。

我之前也遇到过类似问题，后来换了方案。

刚入门，这个对我帮助很大。

我之前也遇到过类似问题，后来换了方案。

我之前也遇到过类似问题，后来换了方案。

我之前也遇到过类似问题，后来换了方案。

我之前也遇到过类似问题，后来换了方案。

刚入门，这个对我帮助很大。

我之前也踩过这个坑，512的chunk对配置类问题确实偏大，容易把变更记录和日志一起裹进来。你可以试试按语义切，比如按段落或标题层级分，再小一点到256左右。另外纯向量检索对“怎么配置”这种意图不太敏感，加个BM25做混合检索会好很多。

看到这个签约消息我其实有点复杂。电商渠道确实能快速铺量，但机器人出海最难啃的骨头从来不在销售端，而是售后和运维那套东西。你提到跨境OTA，我补充一个更头疼的：不同国家的无线频谱法规和网络安全认证完全不一样，机器人联网模块的固件可能得按区域分版本，这维护成本比想象中高得多。日本那个关节柔顺度的例子很到位，我再加一个，欧洲对服务机器人的噪音和电磁兼容要求也很细，这些不是靠速卖通后台改改参数就能搞定的。

固定batch省事但浪费，工业检测batch经常是1，动态shape回退CPU确实会导致结果对不上，建议先用polygraphy查下哪些层不支持。

先看prompt里有没有明确要求只依据召回内容回答，很多时候是模型自己加戏了。

DeepLabV3+这种带空洞卷积和ASPP的结构，转ONNX时opset 12对Resize的坐标变换模式很容易被TRT解析偏掉，边缘细节崩掉基本就是这个原因。你可以把ONNX里所有Resize的coordinate_transformation_mode显式设成half_pixel或pytorch_half_pixel试试，别用默认的asymmetric。另外BN折叠在TRT里偶尔会把小bat

我理解你的困惑，但两者还真不是简单的包装关系。Function Calling 是模型层面的一种输出格式约定，本质上是让 LLM 学会“什么时候该输出一个结构化调用请求”。MCP 更像是站在客户端和工具提供方之间的中间层协议，它管的是工具怎么被发现、描述、授权和调用，跟模型本身解不解析没关系。你写文件搜索 tool 觉得像，是因为你恰好把两层叠在一起用了，把 MCP server 暴露的工具再转成

我踩过一模一样的坑，loss好看不代表模型真学会了格式。你试试把推理时的system prompt和训练时的模板逐字对一遍，特别容易漏掉工具定义那段的换行和空格。另外LangGraph那边如果自己又包了一层prompt，很可能和训练格式打架了。建议先拿训练集里的一条样本直接喂给模型，看它能不能原样复现Action，能的话基本就是推理侧对齐问题。