雨夜写码记

我也遇到过类似问题，后来发现关键在于每轮对话里别只重复角色设定，而是把当前任务进度和约束一起带进去。比如让AI先输出个任务拆解表，下一轮就引用那个表继续，比单纯喊“你是项目经理”管用多了。另外可以把核心指令压缩成简短的状态摘要，每次user message前面附上，相当于手动帮模型维护上下文。不过说实话，轮次一多还是容易漂，可能得配合外部记忆或定期重置对话。

品牌后端和Agent思维链不匹配这块太真实了，我们之前对接也是卡在数据模型上，改造成本巨高。

给AI喂真实数据片段和期望输出，比写十句描述都管用，它缺的是具体上下文不是角色。

200条数据3个epoch确实容易过拟合，先降到1个epoch试试。

这个现象挺常见的，我一开始用bge也踩过类似的坑。你观察到的“分数差距不大”其实是个关键信号——bge这类模型在短文本上的区分度本来就有限，而年假、调休、考勤这几个词在训练语料里经常一起出现，向量空间里它们本来就挨得很近，模型觉得“相关”也不算冤枉它。分块500字按段落切，问题在于一个段落里可能混了好几个主题，向量被平均之后语义就模糊了，检索时容易跟其他含相似词汇的块撞上。我一般会先把块切小一点，

chunk大小得看查询粒度，关键词问句用大chunk加ada确实稳，细粒度配置问题小chunk更灵。我一般按文档结构切，再拿几个典型query测召回，别硬套公式。

结构化抽取这种任务，GPT-4确实容易在边界case上翻车，尤其是日期和地点这种需要精确匹配的字段。我现在的做法是让模型只负责兜底那些正则覆盖不到的模糊表达，能规则搞定的绝不走模型，反而整体准确率上去了。Prompt工程不是没用，而是别把它当万能钥匙，生产环境里模型+规则的混合管线才是常态。

这个问题我踩过类似的坑。之前也试过把Prompt写得特别满，结果模型注意力全被那些约束条件带跑了，反而对检索回来的内容不够聚焦。后来我试着把系统Prompt砍到只剩核心目标，比如“根据以下资料回答问题”，那些防幻觉和格式要求挪到后处理或者用结构化输出约束去管，效果反而稳了不少。 我猜可能跟上下文窗口里的注意力分配有关系，你塞的指令越多，模型越容易在“遵守规则”和“利用资料”之间反复横跳。尤其

我也踩过这个坑，后来把历史对话和检索结果分开管理就好多了。别把聊天记录直接塞进query去检索，容易污染语义，试试用最近一轮的问题做检索，历史只用来做指代消解。另外切片512有点短，多轮里上下文碎片化会更严重，可以试试按语义切或者加大到800左右再配rerank。

模板不一致确实是大坑，线上用户说话方式千奇百怪，你训练时那个“请调用xxx工具”的固定句式很容易让模型过拟合到特定表达上。我之前也遇到过类似情况，后来把训练数据里的指令改得更口语化、多样化，效果稳了不少。另外只调最后一层可能太保守了，LoRA一般建议至少调q和v两个投影层，冻结太多确实会影响泛化能力。你可以先固定线上输入做一轮对比测试，看看到底是模板问题还是模型本身没学好。

我踩过类似的坑，问题多半出在合并环节而不是MCP本身。多路子查询各自召回后如果直接拼一起，没有统一打分和去重，主题肯定散，最相关的那段容易被淹没。建议给每个子查询结果加个加权融合，或者干脆先用原始query走一遍主检索，MCP只做补充召回。另外bge这类模型对query改写比较敏感，拆得太碎反而丢语义，可以试试让MCP少拆几路。

随机负样本太简单了，模型学不到东西，换成hard negatives试试，另外温度别设太低。

工业场景确实最能检验真实水平，光照一变就翻车太真实了，实验室和产线差距不是一点半点。

先把手动编排跑通，再上框架，不然换啥都白搭。

我也遇到过，把参数说明写进模板变量旁边会稳一点，比如 `{file_path}` 后面紧跟“请填字符串路径”。

5000条300token确实少了点，LoRA虽然省显存但数据量不够也白搭。试试把rank拉到16或32看看？

代码场景下切分粒度确实很关键，按函数或类来切比按固定token数靠谱多了，可以试试tree-sitter做语法级别的chunking。embedding的话可以看看jina-code或者voyage-code，比通用模型在代码检索上强不少。另外你可以在检索后加一层rerank，把最相关的片段排前面，再配合模型支持的lost-in-the-middle特性把关键内容放头尾。如果交互链路固定，也可以考

我之前也踩过这个坑，用Llama 3 8B做路由确实容易飘，尤其是意图边界模糊的时候。你提到的“想去北京看故宫”这种输入，模型可能觉得既涉及景点又可能涉及天气，判断就摇摆了。我后来发现光靠prompt里写“请判断是否需要调用工具”效果有限，得把路由逻辑拆得更细，比如先让模型输出一个明确的分类标签，再根据标签走后续分支。另外tool-call的格式也很关键，如果你用的是类似ReAct那种文本解析，模

我踩过同样的坑，后来发现关键不是无脑扩容，而是把工具返回值做结构化裁剪——只保留关键字段，长文本直接摘要成两三行。滑动窗口配摘要压缩确实能用，LangChain里用ConversationSummaryBufferMemory就挺省事，但摘要本身也得控制长度，不然还是会爆。如果工具调用特别多，建议把中间步骤的完整结果存外部，上下文里只留引用ID，模型需要时再按需拉取。7B模型其实够跑这种场景，主要

你用的推理框架本身没问题，关键可能卡在默认参数上。vLLM的gpu_memory_utilization默认0.9，但max_num_seqs和max_model_len如果没调，并发一上来就容易排队。建议先把max_model_len压到实际业务需要的一半，再开连续批处理看看吞吐变化。量化到AWQ或GPTQ能省显存但别指望提速，瓶颈多半在调度策略而不是显存。内存飙高的话查一下是不是KV cach