检索增强生成解决了大多数团队实际上并不存在的问题

在知识密集型任务中，当输出质量下降时，通常第一步是添加向量数据库。但这很少是正确的选择。这类问题中的大多数质量故障并非检索失败，而是披着检索外衣的策展失败。模型并非信息不足。它被大量松散相关材料淹没，没有任何指示来权衡轻重，而RAG只是自动喂给它更多此类内容。迹象在于，团队添加检索后，问题并未完全消失，只是改变了形式。从技术上讲，答案因事实存在于上下文中而更有依据，但在更重要的意义上，它们变得更模糊：模型仍无法分辨检索到的五个片段中哪个对特定问题真正关键。检索扩大了正确信息的池子，却从未解决模型必须决定如何处理它的部分。这不是检索问题。这是RAG本应修复的同一个上下文结构化问题，只是转移到了下游一层。RAG真正值得其复杂性的场景是那些确实庞大、频繁变化的数据集，即使经过激进策展，也无法将相关片段完全纳入上下文，例如法律发现、大型代码库等。对于许多内部工具和产品功能，实际修复措施比向量数据库更小、更无趣：在到达模型之前，将源材料缩减到与任务结构相关的部分，并对“相关”一词在该特定请求中的含义更加谨慎。团队跳过这一步是因为它需要有人真正思考数据，而是转向检索基础设施，因为这是一个已知模式，有现成工具。并非声称RAG从不正确。而是声称在实际瓶颈完全在检索上游的情况下，它被默认使用。如果有人部署过一个案例，其中RAG可测量地修复了一个更好的上下文策展无法解决的质量问题，我真的很感兴趣那是什么样的。