大多数团队用错了RAG：问题不在检索而在上下文策展
ClickOk5811 · reddit · 2026-08-22
Reddit 上一篇高信息量讨论：当知识密集型任务的输出质量下降时，多数团队的第一反应是加向量数据库做 RAG，但这往往不对。
作者的核心论点：这类质量问题大多不是检索失败，而是策展失败——模型不缺信息，而是被大量「松散相关」的材料淹没，没有信号告诉它哪块内容更该被重视。典型症状是加了 RAG 后问题没有消失，只是变了形状：答案的事实确实都在上下文里了，但模型依然分不清五个检索片段里哪个才是这个问题真正的关键，答案反而更含糊。这本质是把「上下文组织问题」往下游挪了一层。
RAG 真正值得上复杂度的场景：语料巨大且频繁变化、精简后也塞不进上下文，如法律取证、大型代码库。而对多数内部工具，正确做法朴素得多：在数据到达模型之前，先按任务把源材料裁剪到结构性相关，并认真定义什么叫「相关」。团队跳过这步是因为它需要人真正去思考数据，而套用检索基础设施是现成的已知模式。作者最后邀请反例：有谁实测过 RAG 解决了纯靠上下文策展解决不了的质量问题？
「编程与Agent」频道最新
- Perplexity 开源支撑其 Computer 产品的智能体沙箱平台 SPACE — AravSrinivas · 2026-10-16
- Vercel Python 正式 GA:原生支持 FastAPI/Django 与 Fluid Compute — steren · 2026-10-16
- Claude Opus 5.5 + Unity 6 完整教程：六步从空文件夹做出可玩游戏 — Roger_M_Taylor · 2026-10-16
- mitsuhiko 儿子用 AI 做多人游戏，顺手教会老爸 PeerJS — mitsuhiko · 2026-10-16
- Marc Lou 公开安利 PostShiba：独立开发者的邮件基础设施新选择 — marclou · 2026-10-16
- RExBench 基准:最强编码 Agent 自主完成研究扩展成功率仅 33% — najoungkim · 2026-10-16