百万token上下文窗口的出现，曾经让人兴奋地认为只需将所有知识库“一股脑”地塞进提示词，就能解决所有问题。然而，现实是即使拥有了庞大的上下文，AI仍然可能自信地引用去年的价格表，甚至幻觉出一个从未存在但听起来合理的价格表，导致销售团队陷入困境。因此，仅仅依靠大模型本身是不够的，检索增强生成（RAG）技术才是确保AI系统输出准确、可靠信息的关键，一个好的RAG架构师，比单纯的prompt工程师更为重要。
上下文窗口的局限性：代价与幻觉
虽然诸如Gemini 2.5和GPT-4等模型在技术上可以处理大量文本，但每次处理这些海量提示词的成本是惊人的。更严重的问题是延迟，用户需要等待很长时间才能得到回复。即使拥有了如此多的上下文，模型仍然难以保证精度。将大量信息“喂”给模型，它仍然可能找到错误的“针”，或者用无关紧要的“稻草”编织出虚假的故事。 近期 benchmark 测试和实际经验表明，仅仅增加上下文长度并不能神奇地提高模型的忠实性，只有当提供的上下文具有高度针对性和相关性时，才能实现更好的效果。 这也是为什么我们需要RAG的原因。
例如，一个内部财务机器人基于去年的年度报告为本季度的战略提供建议，这显然是不可取的。因此，我们需要关注RAG系统的质量，而不是一味追求更大的上下文窗口。
RAG架构：不仅仅是检索
检索增强生成（RAG）已经成为AI领域的“家常便饭”。混合检索、密集向量、稀疏向量以及重排序器等技术几乎成为标配。Serverless向量存储降低了查询成本，使得黑客马拉松原型更容易扩展。更复杂的Agentic RAG管道可以循环并重新调整查询，直到达到置信度阈值。实时索引对于支持或交易等应用至关重要。此外，LlamaIndex或Cohere等评估工具可以提供hit-rate和事实性得分的仪表板，这都极大地提高了RAG系统的可用性和可维护性。
然而，问题在于，我们是否只是将这些技术视为“现代AI Stack”中的新复选框？我们是否认真地实施这些先进的RAG模式，还是仅仅简单地添加最新的开源库并期望获得最佳效果？拥有一个向量数据库和一个retrieve()函数并不意味着已经解决了问题，这仅仅意味着进入了一个更有趣、更复杂的游戏。
RAG的挑战：被忽视的细节
RAG系统的真正价值在于其解决问题的能力。然而，在光鲜的宣传背后，RAG面临着许多被忽视的挑战。
- 检索偏差和知识漂移： 初始索引是时间快照。当产品规格发生变化、法律准则更新或医学知识发展时，会发生什么？如果检索器对时间戳视而不见，或者没有根据当前的真实情况持续更新和重新评估，那么不仅会提供次优答案，还可能大规模传播错误信息。
- 案例： DriftMedQA的结果表明，医学知识的演变速度很快，如果RAG系统没有及时更新，可能会提供过时的医疗建议。
- 知识产权陷阱和版权问题： 在内部PDF、Wiki和Slack频道中，可能包含未经授权的Gartner报告图表或受版权保护的教科书引用。RAG系统可能会逐字显示这些文本块，从而导致侵权。
- 案例： 一个营销部门构建的chatbot，如果不小心使用了未经授权的图片素材，最终可能会导致侵权诉讼。
- 治理债务： 我们花费了数十年时间构建成熟的SQL世界工具，包括模式管理、细粒度访问控制、强大的审计跟踪以及GDPR合规的数据擦除API。然而，对于向量数据库，情况却像是狂野西部。谁访问了哪个块？如何证明这个向量嵌入不包含PII？如何选择性地删除与“被遗忘权”请求相关的数据？
- 案例：一家金融公司使用RAG系统处理客户数据，但缺乏适当的访问控制和审计跟踪，可能会面临严重的合规风险。
- KPI指标的对齐： 我们喜欢技术指标，如检索召回率、精度、MRR、BLEU分数。但是，CEO关心的是支持中心的工单减少、座席处理时间缩短、产品问答的销售转化率提高或新员工的入职速度加快。
- 案例：一个客服中心使用RAG系统提高了问题解决效率，但是没有和降低运营成本，提升客户满意度等KPI关联起来，最终导致项目被搁置。
RAG架构的未来：模式与预测
为了在2025年更好地应用RAG，我们需要关注以下架构模式：
- 可配置交换组件： 嵌入模型、向量数据库甚至重排序器的选择不应是永久性的。应该设计管道，以便可以通过配置交换这些组件。
- 案例： 如果当前的向量数据库提供商被收购或其定价模式发生变化，可以轻松切换到另一个提供商。
- 检索+工具使用： RAG不仅是获取文本，还包括获取LLM可以推理或使用的事实或能力。
- 案例： LLM在从RAG获得一些初始上下文后，可以决定调用计算器、通过API查询SQL数据库甚至分析图像。
- 记忆增强RAG： 如果用户提出问题，RAG系统经过复杂的检索和生成过程来提供一个很好的答案，那么应该记住这一点。缓存成功的查询-上下文-答案三元组，并将其用作软提示或微调数据，以使系统在将来对类似查询做出更智能、更快速的响应。
- 案例：如果一个用户多次询问同一个产品的功能，RAG系统可以缓存之前的回答，从而更快地提供答案。
- 多模态检索： 知识库越来越多地包含图表、表格、PDF中嵌入的图表、产品图像和视频。应该能够有意义地索引这些内容，并检索它们以供可以理解多模态输入的模型使用。
- 案例：AI助手不仅可以告诉用户销售趋势，还可以显示来自最新董事会会议的相应图表。
- Guardrails优先： 应该设计系统以“优雅地失败”。如果检索置信度较低，LLM最好说“我没有足够的信息从提供的文档中准确回答这个问题”，并显示其（可能缺乏的）来源，而不是自信地提供错误的答案。
- 案例： 如果RAG系统无法找到与用户查询相关的文档，它应该返回一个提示用户重新表述查询或联系客服人员的消息，而不是生成一个不准确的答案。
以下是对未来的一些预测：
- 检索工程师将比提示工程师更受欢迎： 构建健壮、可扩展且相关的检索系统是一项复杂的工程学科。
- 亚200毫秒的RAG延迟将成为标配： 用户不会等待。这将推动硬件感知近似最近邻（ANN）索引和高度优化管道的创新。
- 向量标准将会出现： 对具有专有嵌入格式和向量DB API的供应商锁定感到痛苦将变得足够严重，以至于我们将看到对可移植嵌入规范和互操作性层的推动。
- 符合标准的审计跟踪将内置于下一代向量DB中： 查询日志记录与有效负载哈希、版本化数据和不可变记录，由监管压力驱动。
- 上下文感知成本分配将成为现实： 财务部门将希望知道哪些业务部门的文档对token账单的贡献最大，从而将使用情况追溯到检索到的文档ID。
结论：重视RAG的每一个环节
不要只关注“添加RAG”的最初炒作。应该记录每一个环节：问题、检索到的ID、延迟、用户反馈、下游业务结果。自动化索引刷新；在源头系统上设置webhook触发器。运行专门的开发冲刺，以积极寻找偏差、过时的事实和PII泄漏。从小处着手，但要使其模块化。
检索带来相关性，生成带来推理。如果在检索方面偷工减料，那么后者（无论LLM多么强大）都只会发出噪音，或者更糟的是，产生结构精美的胡说八道。真正成功的AI系统，那些能够带来真正、持续价值的系统，将是那些首先做好检索的系统。然后，也只有在那时，才应该让大模型思考。