RAG 比你想象的更简单

RAG Is Simpler Than You Think

▲ 486j0selit0203 HN 评论区
RAG 比你想象的更简单

别再盲目堆砌向量数据库和复杂的 reranking 流程了。大多数 RAG 系统过度工程化，而用户其实只想快速找到“如何重置密码”的文档。文章指出，应优先从 BM25 全文检索入手，配合 LLM 进行 query rewriting，这往往能解决 90% 的问题。只有在数据量大、查询模式复杂或需要语义理解时，才考虑引入 embeddings 或混合检索。根据数据更新频率、查询量和团队能力，选择从简单到复杂的六种架构，避免在模型更新时面临重新 embedding 百万文档的噩梦。

大多数“语义搜索”问题，实际上都是查询表述的问题。
阅读原文 →HN 评论区RSS

HN 评论区

203
  1. usernametaken29

    我之前做过大规模 RAG 系统，可以说大家严重低估了全文搜索（FTS），又严重高估了嵌入（embeddings）。FTS 其实非常简单、可移植且可扩展，能解决大部分问题，二八定律在这里完全适用。嵌入看起来很棒很神奇，但当你真正深入使用时会发现：语义相似度并没有你想象的那么好，肯定也无法让所有人都满意。你最终不可避免地要重新嵌入更多或不同的文本块，以支持越来越精确的嵌入搜索——到了这一步，你又会走完最后一公里，去做重排序（reranking）等等，同时还要承担向量搜索带来的运维负担。

    然后你转过头去构建一个包含 500 个关键词的搜索查询，虽然这过程很痛苦，但它就是能跑通，能覆盖所有用例，可扩展，而且总体上维护起来没那么烦人。

  2. jillesvangurp

    RAG 本质上就是老生常谈的信息检索，只是由 LLM 来执行查询。这可以包含向量搜索，但没有它也能工作。把向量搜索当作不费吹灰之力就能让搜索变得完美的神奇仙粉，这种想法未必行得通。此外，它还会给系统增加不少成本和复杂度。如果调优不当，你也不一定能得到好的结果。

    RAG 的关键在于用尽可能少的查询将正确的信息放入上下文。这需要良好的召回率（确保如果信息存在，就能通过合理的查询找到）和精确率（确保最好的内容排在前面，并尽量减少误报）。

    对于搜索，以及延伸出的 RAG 来说，“垃圾进，垃圾出”的原则依然适用。在 AI 和 RAG 出现之前，搜索团队所做的大部分内容，仍然是优化 RAG 体验的最佳方式。如果你在这上面搞砸了，搜索就不会工作得很好，再多的 AI 也无法弥补，或者只能以巨大的 token 和时间成本为代价。因此，拥有一个 ETL 管道来预处理你要索引的内容，测试和基准测试搜索质量等等，都是很有帮助的。

    好消息是，你不需要太多智能体（agentic）编码的技能就能构建一个还不错的系统。这段代码几乎可以自己写出来。甚至在索引之前花一点点精力提取结构，就能带来巨大的差异。

  3. alansaber

    我构建过使用所有这些方法的系统（全部同时使用）。在大多数情况下，除了极少数边缘案例外，构建高度优化的特定语料库信息检索策略所付出的努力并不值得（the juice is not worth the squeeze）。目前关于 RAG 的技术讨论量远远超过了其实际用例的需求。

  4. jrochkind1

    又是更多由 LLM 生成的关于 LLM 的文本。

    还有谁像我一样觉得 LLM 生成的文本越来越难读了吗？我觉得非常累，我的大脑根本不想读完它。

  5. Angostura

    我特别讨厌那些懒到第一次使用缩写时都不拼写全称的文章。

    所以：https://en.wikipedia.org/wiki/Retrieval-augmented_generation

  6. waximabbax

    我们不久前就在我们的代码智能体中移除了检索功能。说服我们的不是基准测试，而是我们发现检索路径因为一个技术故障已经有一段时间返回零结果了，但居然没人注意到，事实上它表现得比以前更好。

    经过严格的 A/B 测试后，我们放弃了索引。对于代码来说，我认为原因是代码库本身已经是可搜索的。导入语句、调用点、文件和测试名称，grep 就能给你提供廉价且可靠的、原本索引能做到的功能，智能体可以围绕匹配项阅读以进行验证。分块检索（chunked retrieval）给模型一些看起来正确的东西，它倾向于信任这些内容，而不是去查找实际源代码。我注意到的另一件事是，像 Opus 5 和 Fable 这样最智能的模型，大部分时间无论如何都会忽略这些分块，原因不明。也许它们被训练为不信任代码库的相似度检查。

    带有文档的超大代码库感觉则不同。你无法 grep 一个你无法命名的概念。这才是我仍然会使用检索的场景。

    （我在 TheGitAI 工作，特此披露。）

  7. refactor_master

    这里有一个更简单的思路：第一次就把所有内容嵌入，然后追踪哪些内容发生了变化。使用廉价模型来总结并清理文档/聊天，生成摘要和关键词。除非你要嵌入整图书馆的书，否则这只需要几百美元的 API 调用费用。

    然后，把所有东西扔进 BigQuery。它原生支持所有向量操作。

    在上面加一个智能体机器人 UI 组件，让它看起来无所不知、充满魔力。

    我假设除了 Google 之外，其他供应商也有类似的开箱即用方案，你可以直接接入。

  8. 7734128

    过去几年里已经有很多这类博客了。

    是的，嵌入计算量很大，但它们一点也不复杂，而且能提供很多好处。

    90% 基于“文档”的 RAG 项目应该将基于嵌入的语义搜索作为主要方法。

    它非常强大，而且实现起来如此简单，你可以直接尝试一下，看看性能是否真的有问题，而不是试图去预判它。

同日更多故事

2026-08-26