大多数团队用错了RAG：问题不在检索而在上下文策展

ClickOk5811 · reddit · 2026-08-22

Reddit 上一篇高信息量讨论：当知识密集型任务的输出质量下降时，多数团队的第一反应是加向量数据库做 RAG，但这往往不对。

作者的核心论点：这类质量问题大多不是检索失败，而是策展失败——模型不缺信息，而是被大量「松散相关」的材料淹没，没有信号告诉它哪块内容更该被重视。典型症状是加了 RAG 后问题没有消失，只是变了形状：答案的事实确实都在上下文里了，但模型依然分不清五个检索片段里哪个才是这个问题真正的关键，答案反而更含糊。这本质是把「上下文组织问题」往下游挪了一层。

RAG 真正值得上复杂度的场景：语料巨大且频繁变化、精简后也塞不进上下文，如法律取证、大型代码库。而对多数内部工具，正确做法朴素得多：在数据到达模型之前，先按任务把源材料裁剪到结构性相关，并认真定义什么叫「相关」。团队跳过这步是因为它需要人真正去思考数据，而套用检索基础设施是现成的已知模式。作者最后邀请反例：有谁实测过 RAG 解决了纯靠上下文策展解决不了的质量问题？

原文链接 →

「编程与Agent」频道最新

更多「编程与Agent」频道 AI 资讯 →