长期关注创作实践笔记

10万条已经过了单靠索引能救的阶段了，建议先上reranker（比如bge-reranker），效果立竿见影。

说到这个我可太有同感了，之前调RAG prompt的时候也踩过一模一样的坑，疯狂堆砌约束和示例，结果模型跟喝了假酒似的，宁可自己编也不看检索内容。后来我琢磨着，问题可能出在咱们把“指令”和“上下文”的主次关系搞反了——RAG的prompt里，检索回来的片段才是主角，你的任务其实是给模型指个路，告诉它“这些是现场证据，你负责当个靠谱的证人”，而不是给它一堆行为守则让它分心。我当时试了个很土但有效的办

7B做多步工具调用确实容易崩，我试过在中间步骤用向量库存工具返回的关键摘要，只把最新一轮完整对话塞给模型，效果比单纯截断好点。另外LangChain的ConversationTokenBufferMemory可以设个阈值，把最老的对话自动压成几个关键词，但得调好参数，不然关键指令会被吞。你那个让LLM自己总结的思路其实可行，就是得加个强制格式化的prompt，比如让它只输出“工具结果+下一步计划”

说实话你这个问题我太有共鸣了，上周刚把一个类似的项目从纯塞历史改成混合架构，才勉强能跑。我的做法是分两层：短期记忆用滑动窗口存最近几轮原始消息，保证对话连贯性；长期记忆则抽成结构化条目，比如“用户偏好=辣”这种键值对，配合向量库做语义召回。但关键点是召回不能只靠embedding相似度，得加一层规则或LLM重排，比如你那个川菜的例子，得让模型先判断“当前问题是否涉及历史偏好”，再决定要不要去翻记忆

混合检索确实值得试试，光靠向量召回在数字和年份这种精确匹配上容易翻车，加个BM25关键词召回再合并结果，很多类似问题能直接解决。另外你说重排序有提升但不稳定，可以看看是不是重排序模型本身对长文本不敏感，试试把候选集先压缩到top50再做重排。HNSW的efConstruction对召回影响其实没那么大，更关键的可能是efSearch，查询时把调大点能明显减少漏召回。还有个偷懒技巧，在query里做

我之前做客服文档也是这个痛点，256和512来回切。后来发现干脆按文档的章节标题来切，比如每个二级标题下的内容作为一个chunk，效果比固定大小稳定很多，上下文也完整。再配合一点重叠窗口，比如每段重叠10%，基本能避免漏关键信息。至于chunk策略库，可以试试LangChain的文本分割器，但别直接用默认参数，得根据你的文档结构微调一下。

刚好最近也在折腾Agent落地的事，看到这个实测结果挺有共鸣的。GPT Agent那个静态Prompt链的问题确实太明显了，项目稍微复杂一点就容易在中途跑偏，或者卡在某个子任务上死活绕不出来，最后debug到怀疑人生。你说的动态任务分解听起来像是给Agent装了“实时纠偏”的脑子，这点如果真能做到稳定，那体验差距确实会很大。 不过有点好奇，这个“端到端成功率高出40%”是基于什么样的复杂项目？是