终身学习职场成长记

我之前也踩过类似的坑，用Llama 3做本地问答时，一开始直接抄网上的通用模板，结果客服场景下经常答非所问，后来把角色设定砍到只剩一句“你是XX产品的客服，只回答与产品相关的问题”，输出反而稳多了。我的体会是模板别贪多，越复杂的指令模型越容易在边缘case上自由发挥，尤其是小参数版本，指令一多它就开始编。现在我会把业务规则拆成两三层，最上面是身份和边界，中间放一两个few-shot示例，下面留一句

先拿几个难样本跑下相似度对比，bge-small对近义场景确实容易翻车，有条件直接换bge-m3试试，还不行再上OpenAI不迟。

说实话我觉得问题可能出在“健壮”这个词上，模型对它的理解跟咱们不太一样。你让一个工程经验不足的LLM写“健壮”，它可能只会加个try except就算完事，但真正的健壮要考虑文件名冲突、非法字符、权限问题这些边界情况。我自己的经验是把需求拆得更碎，比如直接告诉它“要检查目标文件是否已存在，存在就跳过并打印警告”，这样它反而能给出更具体的代码。另外，网上那些惊艳的效果，很多是经过多轮迭代调试出来的，

这问题我太有同感了，bge-m3配faiss在长文档上确实容易把上下文切碎。你提到的rerank得先安排上，但光rerank解决不了逻辑断层，更关键的是检索前得做“语义块”切分，比如按小节或者主题段落来分，而不是死磕字数和overlap。父子chunk我也试过，对跨段落的总结类问题有效，但实现起来比想象中麻烦，得维护两级索引。另外可以试试在检索后加一步“上下文补全”，把每个chunk前面那一段也带

说实话我之前也踩过这个坑，后来发现问题八成不在top_k上，而是embedding模型跟你的对话场景不匹配，比如通用模型对带角色或上下文的query区分度很差。你可以试试先固定一个不错的embedding，然后手动检查几条召回结果的相似度分数，看是不是分数本身就没拉开差距。还有个偏方，就是给每条记忆加个简单的关键词标签，召回时先做一次粗筛再向量排序，会比纯靠向量稳很多。另外MCP的memory工具