RAG 比你想象的更简单

原文 ↗ Hacker News 讨论 ↗

检索增强生成（RAG）被描述得并没有其炒作所显示的那么新，许多人认为它本质上就是传统信息检索加上一个 LLM，而且团队往往会用向量数据库和 embeddings 把它搞得过于复杂。评论者反复强调，全文搜索和 BM25 对许多现实用例依然强大、更便宜、也更容易控制，尤其适合技术和代码搜索；而 embeddings 常常被高估、难以调优，且运维成本高。与此同时，大家也对围绕 RAG 的 AI 生成教程持怀疑态度，并呼吁更清晰的设计模式、更好的评估，以及“先从简单方案开始，只有在必要时再增加复杂度”的做法。

RAG 实际上是什么

  • 许多评论说，RAG 本质上就是“经典信息检索 + LLM”，并不是什么根本性的新品类。
  • 也有人指出，“RAG ≠ 向量搜索”：任何把检索结果喂给 LLM 的检索方式（grep、SQL、FTS、网页搜索）都算 RAG。
  • 线程里还有人仍然默认把 RAG 当成“embeddings + 向量数据库”，说明这种混淆仍在持续。

Embeddings 与全文 / 关键词搜索

  • 一个强烈主题是：全文搜索（FTS/BM25/Lucene/Elasticsearch/Postgres FTS）常常被低估，而且通常应该先尝试它。
  • 支持 FTS 的理由：更简单、确定性更强、工具更成熟、更容易调试、扩展性好，而且对技术类或代码类查询往往更有效。
  • 支持 embeddings 的理由：适合表达不充分或描述性查询、同义词、多语言搜索，以及用户不知道准确术语的情况。
  • 一些人提到对 embeddings 的现实失望：语义相似度没有预期中那么强，运维开销高，重排序流水线也很复杂。
  • 也有人报告，简单的基于 embedding 的语义搜索或 BM25+向量的混合方案效果很好。

分块、规模与文档结构

  • 分块大小被反复指出非常关键；糟糕的分块会毁掉检索，不管模型多好。
  • 长文档（书籍、报告、PDF）会带来问题：token 限制、跨 chunk 的引用（“it” 指回前文）、以及当大量重叠片段都要做 embedding 时索引规模爆炸。
  • 关于中等偏大的 chunk（512–1024 tokens）是否通常足以捕捉主题上下文存在争论；有人认为足够，另一些人则说关系信息仍然会丢失。

用例：代码、企业文档、多语言

  • 对代码而言：一些工具和团队报告说，简单的 grep 或 FTS 加上智能 agent 往往比 RAG 更好；甚至有人移除了检索部分，用户也没有察觉。
  • 对于超大代码库和抽象的“概念”查找，检索仍然可能有帮助。
  • 在充满术语和缩写的企业/金融文档中，BM25 可能表现不佳；embeddings 或跨语言方案可能更有效。
  • Embeddings 被描述为一种语言无关的“公共空间”，适合跨语言搜索，但调试更困难。

系统设计、Agents 与编排

  • 许多人认为真正的“难点”不在 embeddings，而在检索设计：新鲜度、访问控制、版本管理、重叠文档、评估以及排序。
  • 基于 agent 的查询改写在传统搜索之上很受欢迎：让 LLM 生成并迭代查询，然后在底层使用稳定的词法 / FTS 基础设施。
  • 有人把 RAG 看作一个编排问题：根据用例和质量要求混合不同模块（精确搜索、向量、SQL、标签、规则）。

成本、工具与实用建议

  • 一派观点认为“把所有内容一次性嵌入，跟踪变更，然后把向量存到 BigQuery 之类的地方”就够了，前提是语料库规模适中。
  • 另一些人警告不要被厂商锁定，建议选择可移植技术、简单的 Postgres/BM25/pgvector，或者使用 LLM 生成 SQL 的 SQLite FTS5。
  • 也有人抱怨许多 RAG 教程并没有把方法和评估绑定起来；大家想要的是基准测试，以及关于何时哪种检索方案真正能改善结果的指导。

怀疑、炒作与写作风格

  • 一些评论者认为这篇文章读起来像 LLM 生成的“AI slop”：标题过于夸张，浅层的“是什么”列表配上薄弱的“为什么”，而且混合方案像是机器拼接出来的。
  • 不过也有人仍然觉得内容在实践上有用，尽管风格不佳。
  • 更广泛的反弹也存在：对 AI 生成文风的疲劳、认为 RAG 被过度使用、“magic beans”、或“已经是 2024 年的东西了”的说法，以及“先从最简单、可行的搜索开始，只在明确需要时再增加复杂度”的呼声。