RAG 比您想象的更简单

如今，大多数人似乎过度设计了他们的 RAG 堆栈。他们直接跳到嵌入、向量数据库和重新排序管道。与此同时，他们的用户只想找到“如何重置我的密码”的文档。在工程领域，总有针对正确问题的正确工具。在人工智能检索系统中，情况也没有什么不同。在我们深入研究食谱之前，让我们先确定何时应该使用每种方法。关键因素是： 1. 数据新鲜度要求 - 实时更新（新闻、社交媒体）倾向于易于重新索引的方法。每日或每周更新适用于混合方法。稳定的语料库（每月或每季度更新）使预嵌入变得合理。 2. 语料库特征 - 高流失率（每日变化超过 10%）意味着您应该避免完全预嵌入。稳定的文档与预嵌入配合得很好。长尾分发（90% 从未访问过）意味着即时获胜。 3. 查询模式 - 关键字密集的查询应从全文搜索开始。语义或会话查询受益于嵌入。混合模式需要混合方法。 4. 规模和性能 - 每天少于 1000 个查询意味着简单的方法就足够了。每天 1K 到 10K 的查询需要选择性优化。每天超过 10K 的查询证明全面优化是合理的。 5. 团队能力 - 没有 ML 专业知识意味着只能进行全文加查询重写。一些机器学习经验使混合搜索变得易于管理。拥有一个可用的机器学习团队使得先进的方法变得可行。现在，我们来看看食谱书。从顶部开始。仅当有数据证明需要时才向下移动。好旧的 BM25。弹性搜索。 Postgres 全文搜索。在“嵌入”成为动词之前就存在的东西。你才刚刚开始。您的用户编写关键字式查询（“pandas 合并数据框”）。完全匹配很重要（“invoice #12345”）。您希望 ML 复杂性为零。您的语料库有专有术语（稍后会详细介绍）。 API 成本为零。快速（低于 10 毫秒）。易于调试（您可以准确地看到文档匹配的原因）。出奇的有效（处理许多用例）。无需分块策略 - 适用于完整文档。没有评估复杂性——易于测试和验证。无模型弃用风险（BM25 不变）。缺少同义词（“汽车”与“汽车”）。语义查询失败（“我如何...？”）。无法理解关键字之外的意图。根据我的经验，这可以处理很大一部分用例。不要跳过这一步。您可能会惊讶自己能走多远。当您直接跳到嵌入时，您立即面临这样的问题：块大小是多少？ （512 个令牌？1024 个？）什么重叠？ （50 个标记？100 个？）语义分块还是固定大小？如何评估我的分块是否良好？通过全文搜索，您可以跳过所有这些。你的文件就是你的文件。搜索就可以了。使用法学硕士将混乱的用户查询转换为干净的关键字搜索。大多数“语义搜索”问题实际上是查询表述问题。用户以对话方式提问。词汇不匹配（用户说“修复错误”，文档说“调试”）。你有内部术语（你的框架称为“Atlas”）。您希望能够灵活地快速迭代查询策略。每个查询约 0.001 美元（使用 GPT-4o-mini 进行查询重写）LLM 可以删除停用词（“我如何”变得毫无意义）。它可以添加同义词（“汽车”变成“汽车汽车车辆”）。它可以翻译领域术语（“加速代码”变成“优化性能”）。它可以分解复杂的查询（“读取 CSV 并绘制”变为 [“读取 CSV”，“绘制数据”]）。它可以从您的词汇表中学习（通过系统提示）。对于嵌入，如果结果不好，您需要调整分块策略，重新嵌入整个语料库，对评估集运行回归测试，并希望它有所改善。通过查询重写，如果结果不好，您可以调整系统提示。就是这样。立即测试。更好的是，您可以创建一个循环：代理可以迭代、学习和适应 - 所有这些都无需重新嵌入任何内容。假设您的公司有一个名为“Atlas”的 Python 框架。如果您使用通用嵌入：通用嵌入模型（在互联网上训练）：“Atlas” = [指向希腊神话、地图、地理的向量] 您的实际 Atlas 文档 = [有关数据处理的向量] 相似度得分：0.15（太糟糕了！）该模型不知道您的“Atlas”存在。它会回归到在训练中学到的东西。但通过查询重写：对于专有术语，精确的关键字匹配胜过语义理解。使用 BM25 获取候选者（前 50-100 名），然后使用嵌入重新排名（前 10 名）。 BM25 快速且擅长关键字匹配。嵌入擅长语义理解。他们一起弥补彼此的弱点。用户提出语义问题（“找到 X 的替代方案”）。 BM25 加上查询重写本身并不能解决问题（你有数据证明这一点）。您可以容忍 100-500 毫秒的延迟。你的语料库相对稳定（不会每分钟都在变化）。让我们用当前定价进行数学计算（OpenAI text-embedding-3-s