一只萤火虫会调Bug

我上个月刚踩过一模一样的坑，Qwen2.5-7B做合同字段抽取，prompt换个说法结果就变，后来发现是sglang那边默认的采样温度没调，冷启动时特别明显，设成0之后稳定性好了不少。但json约束还是会偶发抽风，尤其是字段名映射，模型会自己发明一些看起来很合理但原文没有的key，后来我在system里加了一句“字段名必须从以下列表中选，不允许新增”，效果比单纯写json schema好。few-

我上周也这样，把MCP SDK降到1.0.0就通了，版本兼容确实有坑。

TF的trace机制确实和PyTorch动态图思路不一样，Agent循环里反复调子图建议直接上tf.function加input_signature固定shape试试。

微调时没混工具调用格式的话，MCP塞回来的tool result模型确实容易懵，建议把工具调用样本也加进训练数据里。

我个人试下来最管用的是“给输入样例+输出样例”，比如贴两行CSV再写明你要的结果长啥样，AI对格式的理解会准很多。另外别让它一口气写完整个流程，让它分步骤“先读取预览前5行”再继续写，这样能避免它自己脑补字段名。至于import漏掉的问题，你可以在提示词里加一句“用到的库先全部列在代码顶部”，基本能治住这个毛病。伪代码那招对复杂逻辑有用，但小数据处理反而显得绕，不如直接给个失败案例让它修正来得快。

给ReAct的prompt里加个“答案明确就输出Final Answer”的硬规则，比调参管用。

说到query重写，我试过把用户问题拆成几个子意图再分别检索，最后合并上下文，比直接拿原句去拼效果稳不少。另外你可以试试在prompt里加一句“如果上下文没有直接依据，就明确说不知道”，能压掉不少幻觉式的罗列。角色设定确实有用，但别写太长，模型容易只顾着演人设而忽略内容。

巧了，我之前也踩过这坑，加了几个增强之后显存直接翻倍。你试试torch.cuda.set_per_process_memory_fraction设个上限，让它提前崩，然后用faulthandler或者pdb配合catch Exception去抓，但更实用的是把transform拆开逐个跑一遍看每个操作前后的显存增量，这比直接看memory_summary直观多了。另外查一下你的Dataset是不是

说实话提取类任务真别死磕prompt，我试过给二十个few-shot照样乱飘。后面直接把输出格式钉死在JSON schema里，再让模型先抽出候选片段后二次校验，稳定性一下就上来了。微调这事看量级，你如果反馈量上千条，小模型绝对比大模型加花活靠谱，成本还低。关键是先定好你允许模型犯错的边界，比纠结玄学prompt有用多了。

这问题太真实了，我试过在prompt里加“严格使用以下变量名，不要改动”，结果它还是偶尔抽风。感觉模型对语义相似的变量名有“惯性”，尤其是短名字df、data这种出现频率太高了。我现在的土办法是让它先输出一个代码骨架，我确认变量名没问题后再让它填逻辑，这样改起来省事很多。另外你也可以试试在关键代码行后面加注释锁定变量名，有时候比在开头强调管用。

说实话你这个问题太典型了，我当初搞本地Agent也卡在这。单纯塞历史进prompt确实是最粗暴也最不靠谱的方案，token一超模型就开始胡言乱语。后来我试了把记忆拆成“短期工作记忆”和“长期摘要”两层，短期用最近几轮原始对话，长期用另一个小模型定期把旧对话压缩成结构化摘要存进SQLite，效果比向量检索稳很多。向量存储那个我懂，难点在于embedding模型对实体和时间的敏感度不够，你不如在检索前

我之前也踩过类似的坑，后来发现纯粹加路径前缀确实没用，得在检索前把用户问题拆成“定义”和“用法”两个子查询，分别去匹配不同文件，再按相关性权重排序拼接，效果会好不少。另外可以试试在切块时保留函数签名和docstring的关联元数据，把调用示例单独作为一类索引，而不是全混在一起。你现在的检索排序是纯向量相似度还是有加BM25混合？感觉这块对来源混淆影响挺大的。

我之前也踩过这个坑，光靠“不知道”这句话根本拦不住模型脑补，尤其是当chunk里有一点点关键词重合时，它就会顺着往下编。后来我试了个土办法，就是把system prompt改成“你只能使用下面引号内的原文内容回答问题，每句话后面必须加[来源编号]”，结果模型明显收敛多了，因为强制引用让它没空间自由发挥。另外，我发现与其只告诉它“不知道”，不如给它一个明确的“拒答信号”，比如规定输出必须以“抱歉，根

你这场景我基本复刻过，2万条小数据加Bert，compile收益确实就那样，10%算正常，官方那个30%得看模型多大、算力多挤。动态shape报错就别硬扛了，变长序列老老实实pad到固定长度或者直接eager，省心。我试过把自定义分类头拆出来单独compile，backbone保持原样，能稍微稳一点，但也就聊胜于无。部署推理如果在意延迟，直接上onnx或者TensorRT更实在，compile那点

我也踩过类似的坑，3000条数据做多工具串行确实不太够，尤其tool_call_id这种强对齐关系，LoRA低秩下很难学稳。建议先检查数据里多轮对话的assistant消息是否严格交替带tool_call和tool_result，漏一条就会带偏。另外可以试试把每个工具的参数约束写成JSON Schema直接塞prompt里，比纯文字描述更硬。全量微调先别急着上，性价比低，我后来是把数据扩到1.2万

这问题我也踩过坑，单靠向量相似度确实容易跑偏，尤其是对话这种上下文强相关的场景。建议试试把对话轮次的元数据（比如时间戳、角色）加进Chroma的filter里，先按范围圈定再算相似度，效果会稳很多。另外你每轮存一条，如果那轮内容太长，embedding会被噪音带跑，可以试着按句子或语义片段切分，检索时再拼回上下文。还有个小技巧，问“刚才推荐的餐厅”这类指代性问题时，可以先把最近几轮历史拼成一段文本

这个现象我太有同感了，之前我把路由完全交给模型的时候也翻过车。你问SQL它去查向量库，八成是工具描述写得太“像人话”了，比如“查询项目信息”这种，模型根本分不清该走哪个，我后来把描述改成强约束句式，比如“仅当需要精确字段值（如日期、金额）时使用，且必须包含完整表名”，效果立竿见影。不过我也觉得，光靠优化描述治标不治本，DeepSeek这类模型在工具选择上其实挺依赖先验知识的，你温度调到0.2已经很

我们项目之前也被这个折磨得够呛，后来干脆给每个工具都加了显式的schema校验和超时重试，至少能挡住一半的偶发问题。另外就是日志要打全，尤其是入参和返回的原始数据，不然出问题根本没法定位。你们有没有试过用状态机来约束工具调用的顺序？我们正打算这么搞，但感觉复杂度有点高。

我之前也卡在这块挺久的，bge-m3配256切分确实容易把语义拦腰截断，后来试了按章节标题和段落做结构感知切分，比纯按字数靠谱很多，比如你说的合同违约责任，先按条款切，再把每个条款里的甲乙双方描述拼在一起，漏关键内容的情况少了不少。重排序模型我倒是上了，bge-reranker-base在CPU上跑大概每个query多花几十毫秒，本地部署压力还行，但如果你文档量特别大，建议先粗召回top50再re

这题我熟，之前也栽在numpy序列化上，记得先转成list再塞进结果里。