411 讀數

重温 RAG

经过 Dominic Ligot4m2024/10/03

太長; 讀書

是时候重新思考 AI 工程并摆脱时尚了。RAG 在工具包中占有一席之地，但它并不是万能药。

嗚汪。嗚汪。嗚汪。

在将人工智能应用于业务流程和产品的竞争中，出现了一种令人不安的趋势：对检索增强生成 (RAG) 的痴迷。虽然 RAG（一种将大型语言模型 (LLM) 与外部知识检索相结合的方法）无疑为与知识的互动开辟了新途径，但太多从业者对此感到困惑。

现在是时候重新构建有关 AI 实施的对话，认识到过度依赖 RAG 的缺陷，并探索可能更合适、更具成本效益和更优雅的替代方法。

RAG 狂热：许多用例的过度杀伤

RAG 已成为许多希望通过提供外部上下文来提高语言模型准确性的 AI 工程师的首选技术。原理很简单：通过将大量文本上传到向量存储中，这些 AI 系统可以查找相关文档、检索数据并将其与语言模型的生成能力相结合，以产生更精确的答案。

然而，对 RAG 的热情导致了大量高估其实用性的实现。工程师将数百万个文档转储到向量存储中，导致云存储和处理成本膨胀，却不了解用例是否需要如此复杂的功能，这种情况并不罕见。许多人没有考虑更简单的解决方案是否足够，或者 RAG 是否对他们的特定问题必不可少。

简单的 RAG 实施的缺陷

更糟糕的是，大多数工程师都以一种幼稚的心态来实施 RAG，忽视了长期成本和维护负担。他们认为将每一段文本上传到向量存储中会以某种方式让 AI 变得更聪明。但通常情况下，这种做法适得其反。由于向量存储中充斥着冗余和不必要的文档，LLM 不堪重负，不得不检索没有价值的数据。这导致响应时间变慢、成本增加和解决方案效率降低。

RAG 最适合用来增强精确和相关的知识，而不是用来收集所有可用的文档。通过 RAG 进行过度设计还会导致其他关键 AI 功能利用不足，并且过于注重检索，而许多问题可以用更简单的逻辑和结构来解决。

并非每个问题都需要 RAG

事实是：并非所有用例都需要设置 RAG。如果任务范围狭窄且定义明确（例如回复常见问题解答、客户支持查询或参与结构化对话），则简单的查找表或知识图谱就足够了。当可以使用基于规则的系统甚至代理框架构建解决方案时，无需承担运行大量向量存储和数百万参数模型的开销。

使用 RAG 的热情源于这样一种理念：数据越多，性能越好。但在很多情况下，质量胜过数量。具有针对性知识的微调模型，甚至具有基于规则能力的知识感知聊天机器人，都可以在不接触 RAG 管道的情况下表现更好。实施 RAG 的决定应该取决于任务的复杂性，而不是它在 AI 爱好者中的受欢迎程度。

知识面狭窄的小型代理商案例

臃肿的 RAG 系统的替代方案通常更为优雅和有效：小型、专业化的代理，具有有限但精确的知识。这些代理在串联使用时，可以胜过单个承载 TB 级文本的大型模型。每个代理都可以设计为处理工作流程的特定部分或响应某些类型的查询，从而实现模块化和灵活的 AI 系统。这不仅可以降低成本，还可以使整个系统更易于维护和扩展。

想象一下这样一个场景：一个代理负责调度，另一个代理负责汇总，第三个代理负责执行网络搜索。这些代理可以协同工作，只利用它们所需的知识，而无需单片系统的开销。通过部署许多小型模型或基于逻辑的代理，企业可以获得更精确、更快速的输出，同时显著降低处理和存储成本。

过度使用法学硕士：何时使用简单的逻辑即可

最后，在简单逻辑就可以完成的场景中，LLM 被过度使用。LLM 在理解和生成自然语言方面非常出色，但这并不意味着它们应该取代所有形式的自动化。许多任务（如数据验证、表单填写或结构化报告生成）都可以使用基本脚本、规则引擎或确定性系统更快、更可靠地完成。

一个典型的例子是使用 LLM 进行算术任务或排序问题。这是低效且不必要的。它不仅浪费计算资源，而且还增加了在简单函数或算法更准确的情况下出错的可能性。急于将 LLM 应用于一切已经变成了“LLM 锤子找钉子”综合症。这种误用会导致期望过高，当模型在它们原本设计用来处理的任务上表现不如预期时，最终会令人失望。