终身学习职场成长记

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

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

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