如今，大多数人似乎对他们的 RAG 堆栈进行了过度工程化。他们跳过 embeddings、向量数据库和重排序管道，直接进入这些复杂的东西。然而，他们的用户只是想找到那篇上面写着 "如何重置我的密码" 的文档。在工程学中，总有适合每个问题的正确工具。在 AI 检索系统中也不例外。在我们深入讨论各种方法之前，让我们先确定何时使用每种方法。关键因素如下：1. 数据新鲜度要求 - 实时更新（新闻、社交媒体）更倾向于易于重新索引的方法。每日或每周更新适合混合方法。稳定的语料库（每月或每季度更新）使得预嵌入变得合理。2. 语料库特征 - 高更替率（每日变化超过 10%）意味着你应该避免全面的预嵌入。稳定的文档适合预嵌入。长尾分布（90% 从未访问）意味着实时生成获胜。3. 查询模式 - 关键词密集型查询应从全文搜索开始。语义或对话式查询受益于嵌入。混合模式需要混合方法。4. 规模和性能 - 每天少于 1000 次查询意味着简单的方法足够。每天 1K 到 10K 次查询时需要选择性优化。每天超过 10K 次查询需要全面优化。5. 团队能力 - 没有机器学习专业知识意味着应坚持使用全文加查询重写。一些机器学习经验使得混合搜索可管理。如果有机器学习团队可用，则高级方法是可行的。现在，让我们看看这本食谱书。从顶部开始。只有在你有数据证明需要的时候，才向下移动。老派的 BM25。Elasticsearch。Postgres 全文搜索。在“嵌入”成为动词之前存在的那些东西。你刚刚起步。你的用户写关键词样式的查询（“pandas 合并数据框”）。精确匹配很重要（“发票 #12345”）。你想要零机器学习复杂性。你的语料库有专有术语（稍后会详细说明）。零 API 成本。快速（低于 10 毫秒）。易于调试（你可以准确看到为何某个文档匹配）。出奇有效（处理许多用例）。不需要分块策略 - 与完整文档一起工作。不需要评估复杂性 - 易于测试和验证。没有模型贬值风险（BM25 不会改变）。错过同义词（“车”和“汽车”）。对语义查询失败（“我该如何......？”）。不能理解超出关键词的意图。根据我的经验，这处理了相当大一部分用例。不要跳过这个步骤。你可能会惊讶于你能走多远。当你直接跳到嵌入时，你立刻面临这样的问题：什么块大小？（512 个 tokens？1024 个？）什么重叠？（50 个 tokens？100 个？）语义块还是固定大小？我如何评估我的分块是否良好？通过全文搜索，你可以跳过所有这些。你的文档就是你的文档。搜索就是如此简单。使用 LLM 将杂乱的用户查询转换为干净的关键词搜索。大多数 “语义搜索” 问题实际上是查询表述问题。用户以对话的方式提问。词汇不匹配（用户说 “修复 bug”，文档说 “调试”）。你有内部行话（你的框架称为 “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...