RAG 烂大街？烂大街的只是那条流水线——真正的分水岭在这六处

Ticnix
75 阅读16分钟

RAG 烂大街？烂大街的只是那条流水线——真正的分水岭在这六处

当"会搭 RAG"不再稀缺，核心竞争力搬去了哪里

📦 项目源码：weather-travel-recommend-system —— 基于气象大数据的出行推荐系统，AI Agent 全栈项目。FastAPI + PostgreSQL(TimescaleDB/pgvector/PostGIS) + Redis；LangGraph + MCP + Skill + RAG，对接 DeepSeek API。

TL;DR：2023 年你写"切块→嵌入→TopK→塞 Prompt"能拿 offer，2026 年这套流程已经写在每一个教程的第一页。但有个数据很讽刺：2025 年的统计里，95% 的 RAG 系统仍然只用单路向量检索——也就是说，绝大多数系统停在教科书的及格线上，而及格线之上还有六道真正的分水岭：把上下文还给切块（Contextual Retrieval，检索失败率降 67%）、让检索从"动作"变"决策"（Agentic RAG）、按问题类型路由而不是追新架构、从查文档升级到长记忆、把文档库"预编译"成 Wiki（知识编译）、以及一条谁也抄不走的评测闭环。这篇讲清每道分水岭的底层逻辑、关键数字和对应的开源项目，最后给我自己项目定的三步升级路线。

目录

  1. 先承认：烂大街的是流水线，不是问题
  2. 分水岭一：把上下文还给切块——Contextual Retrieval
  3. 分水岭二：检索从"动作"变"决策"——Agentic RAG
  4. 分水岭三：按问题类型路由，别追新架构
  5. 分水岭四：从查死文档，到长记忆
  6. 分水岭五：知识编译——把文档库"Wiki 化"
  7. 分水岭六（暗线）：评测闭环——唯一抄不走的东西
  8. 落地：我的 33 块试验田，三步升级
  9. 可复用清单

1. 先承认：烂大街的是流水线，不是问题

先把"烂大街"拆准。烂大街的是什么？是 Naive RAG 那条流水线：切块 → 嵌入 → 向量库 TopK → 拼 Prompt → 生成。它烂大街到什么程度——开源框架把它封装成了一个函数调用，任何架构师一周内都能搭出一个"能演示"的版本。

演示能跑和生产可用之间的鸿沟，就是竞争力所在。行业里有句话我深以为然：RAG 项目的失败，80% 不在算法，在数据质量和检索质量的度量缺失。

还有一个经常被拿来说事的问题："长上下文模型会不会杀死 RAG？"我的判断是：杀死不了，但会重新分工。Anthropic 自己给过一个分界参考：知识库小于 20 万 token（约 500 页）时，直接全塞 Prompt 加缓存更省事；但库一大，检索依然是唯一经济的方案——而且企业场景里还有长上下文给不了的三样东西：权限隔离（谁能看哪部分）、数据新鲜度（文档在变）、成本（每请求都塞全库，账单会教做人）。

所以问题从来不是"要不要 RAG"，而是"你的 RAG 凭什么不是及格线水平"。下面五处，就是我梳理 2025–2026 这波演进后认为真正拉开差距的地方。

2. 分水岭一：把上下文还给切块——Contextual Retrieval

先看一组我认为是这两年 RAG 领域性价比最高的数字，来自 Anthropic 的实验（指标：top-20 检索失败率）：

方案失败率相对改善
基线（普通嵌入）5.7%—
+ 上下文嵌入3.7%-35%
+ 上下文 BM252.9%-49%
+ 重排1.9%-67%

做法朴素到令人发笑：切块入库前，让 LLM 看着整篇文档，给每个块写一段 50–100 token 的"处境说明"（这块属于哪个文档、哪个章节、讲什么的），拼在块前面再去做嵌入和 BM25 索引。

为什么有效？回到第 3 篇讲过的切块损耗：一个块写着"营收环比增长 3%"，但它从文档里被切出来的那一刻就不知道"哪家公司、哪个季度"了——语义检索和关键词检索都救不了它。Contextual Retrieval 做的事，就是把切掉的那半句语义补回来。

它背后的思路比技巧本身更值钱：把算力花在入库时，换查询时的可靠。入库是一次性的（用 Prompt 缓存后成本约 $1/M token），查询是千万次的。同思路的还有 late chunking：先让长上下文嵌入模型读完整篇文档，再切分它输出的 token 级向量——每个块的向量天然带着全文语境。两条路殊途同归：索引侧的上下文密度，决定了查询侧的天花板。

顺带一提，这也解释了为什么 BM25 不该被扔：补出来的上下文里全是公司名、产品编号这类精确词——恰恰是第 3 篇说的"向量盲区"，两路合起来才是完整的。

3. 分水岭二：检索从"动作"变"决策"——Agentic RAG

Naive RAG 的动作是写死的：查一次，答一次。Agentic RAG 把模型从"答题者"升级成"检索调度员"——它自己决定查不查、查什么、够不够、要不要再查。业界把它拆成四层递进：

  1. 路由：判断查不查、走哪条通道（改写？数据库？网页？）；
  2. 查询规划：复杂问题拆成子问题；
  3. 自适应检索：边查边判断"继续还是作答"——Self-RAG / CRAG 的思想；
  4. 多智能体分工：检索、改写、验证、生成各配专职 agent。

这里有个对工程实践无比友好的结论。2026 年的 RAGSearch 统一基准（Do We Still Need GraphRAG?）系统对比后发现：只配"最小工具集"的 Agentic RAG——一个检索工具加少量辅助——就能大幅拉近与 GraphRAG 的差距，尤其在强化学习设定下几乎追平；重型图谱真正守住的阵地只剩"复杂多跳推理"。也就是说：Agentic 化的红利不需要重装备，Function Calling 加两三个趁手的工具就能吃到大部分。

这对我这种个人项目是重大利好。我的 search_knowledge 目前就是"查一次、答一次"的教科书动作。升级路径已经很清晰：在 LangGraph 里给检索节点加一个自检环——拿到检索结果先让模型判断"这些材料够不够回答"，不够就改写查询再查一轮，两轮还不够就明确说"资料库里没有"。CRAG（Corrective RAG）的核心就是这个环，实现成本半天。再进一步的 Probing-RAG 干脆不问模型"你确定吗"（嘴会骗人），直接读它中间层的激活状态判断置信度——这个思路对自托管开源模型的团队很有意思，闭源 API 用不了。

4. 分水岭三：按问题类型路由，别追新架构

GraphRAG 火了之后，"上图谱"一度成了政治正确。但 2026 年的几轮大规模评测给出了冷静得多的答案：不存在普适最优的 RAG 架构，存在的是"问题类型 → 架构"的路由表。

问题类型谁赢数字
单跳事实型（"XX 的营业时间"）朴素 RAG 仍最强准确率 66.87%，超过多数 GraphRAG 变体
多跳关联（"A 的负责人审批的部署是谁管的"）图谱 / Agentic向量空间里根本没有这条关系链
全局归纳（"这批文档的主题是什么"）GraphRAG 显著占优47.64% vs 朴素 RAG 35.08%
效率敏感的多跳HippoRAG检索延迟 2.44s，GraphRAG 要 44.87s

（数据来自 2025.2 的 RAG vs GraphRAG 对比、WildGraphBench 2026.2 等评测。）

代价表也要看清：GraphRAG 的图构建要烧约 8000 万 token，是 Advanced RAG 的 40–80 倍；轻量化的 LightRAG（双粒度检索，Legal 数据集胜率 85% vs 朴素 RAG 的 15%）和海马体启发的 HippoRAG（Personalized PageRank 一步多跳）把成本和延迟压下来了一大截，但"图构建成本"这个税总是要交的。

我的结论写在标题里了：别追架构，先给你的问题分类。八成日常请求是单跳事实题，朴素 RAG 加重排就够了；真正需要图谱的是那种"关系链查询"和"全局归纳题"——先统计你自己评测集里的题型分布，再决定要不要交图谱的税。Deep Research 类产品把这件事推到了极致：它们的骨架（规划→找料→记账→成稿→证据不足回头补查）本质就是"按研究阶段路由不同的检索策略"，其中"结构化研究笔记"（已确认事实/待验证假设/已排除方向四分区）是工程上最值得抄的一块。

5. 分水岭四：从查死文档，到长记忆

传统 RAG 查的是静态文档库——但 Agent 的工作负载越来越"活"：用户上轮说过的话、上周确认的偏好、三天前的失败尝试，这些不在任何文档里。

这就是记忆系统这条线在 2025–2026 爆发的原因，代表项目三兄弟各有侧重：

  • Mem0：会话级记忆抽取与检索，跨会话个性化，接入成本最低；
  • Zep 的 Graphiti：时序知识图谱——实体和关系带时间 validity，检索时 BM25 + 向量 + 图遍历三路合击，全程零 LLM 调用（记忆的构建在写入时完成），是目前生产验证最充分的方案，Neo4j 官方都在托管它；
  • 声明式记忆（CLAUDE.md / AGENTS.md）：最土也最普及——一个 Markdown 文件每次会话开头注入。别笑，我自己此刻就在用这套（工作区 MEMORY.md），它解决的是"规则类记忆"——不需要检索，每次都在。

值得记住的判断：知识图谱在记忆场景的价值和在文档场景完全不同——文档是给人读的（切了不心疼），交互记录是关系密集的（"谁批准的→批准人是谁的上级"这种链式查询，向量空间根本没有表示）。这也是为什么 Zep 们不约而同选了图。

6. 分水岭五：知识编译——把文档库"Wiki 化"

2026 年爆火、被很多人当成"RAG 替代品"讨论的，是这一族：DeepWiki。把任何 GitHub 仓库地址里的 github.com 换成 deepwiki.com，就能得到一本自动生成的项目维基——架构总览、模块讲解、依赖图谱（Mermaid 自动画）、还能对着代码库提问。它是 Cognition（Devin 背后的公司）开放出来的内部工具，已经索引了 5 万多个主流仓库。

它的思想源头要追溯到两条线：学术上是斯坦福的 STORM（2024 年起研究"用 LLM 从零写出 Wikipedia 式的文章"，靠多视角提问驱动检索，后演进为协作式的 Co-STORM）；理念上是 Karpathy 力推的一个观察——维基这种"持续迭代的结构化知识库"之所以一直没能普及到私有领域，是因为人类维护者受不了更新页面、修正链接、同步信息这些琐碎又没有即时反馈的活；而 LLM 恰好不怕这些。维基思想不新，新的是运维成本第一次降到了可忽略。Karpathy 发声后几个月内，四款产品几乎同时落地：Cognition 的 DeepWiki、Factory 的 AutoWiki（文档作为代码的构建产物，合并进主分支就自动重新生成，用工程机制而非自觉性保证文档与源码同步）、LangChain 的 OpenWiki（开源 CLI，从代码库文档做到"个人全量知识沉淀"）等。

怎么理解它和 RAG 的关系？一个编译器的类比最准确：

传统 RAG 是解释执行，Wiki 化是预编译。

传统 RAG 每次查询都在原始碎片上现场拼语境——这是第 2 章 Contextual Retrieval、第 4 章图谱路线都在试图缓解的根本问题。Wiki 化干脆把"整理语境"这件事在写入侧一次性做完：文档库先被编译成结构化、有导航、有层级摘要的知识层，检索发生在编译后的知识层上，而不是原始碎片上。

但要澄清一个流行误会：Wiki 不是 RAG 的替代品，而是架在 RAG 上面的预编译层。拆开 DeepWiki 的架构看，它自己内部就是一条标准 RAG 流水线（克隆→过滤→切块→嵌入→向量库→检索问答）——Wiki 生成解决的是"知识的组织形态"，RAG 解决的是"知识的存取"。Devin 的用法最能说明定位：DeepWiki 不是面向用户的产品，而是 Devin 的底层检索基础设施——预编译的知识层，让智能体不必每次从零通读整个仓库。

工程上的代价也要看清：编译层的重算是真实成本。知识一变，整个 Wiki 的受影响页面都要重生成。AutoWiki 靠"合并即重生成"的机制强制同步，DeepWiki 靠缓存加定期重索引——但这意味着一个新的一致性问题：Wiki 落后于源数据了也不报错（第 14 篇说的"看不见的耦合"又出现了）。所以我的判断是：知识编译适合读多写少的知识域（代码库、产品文档、领域知识沉淀）；读多写多、时效敏感的（资讯、行情）还是得走原始 RAG。顺带说一句，我项目那 16 个手写知识文档本身就是个手工策展的迷你 Wiki——这条路需要的不是上编译管线，而是保持策展习惯。

7. 分水岭六（暗线）：评测闭环——唯一抄不走的东西

前五道分水岭都是"技术"，最后这道是"习惯"，但它恰恰是唯一无法被开源项目填平的。

道理很简单：开源把所有架构平民化了。Contextual Retrieval 有 cookbook，Agentic RAG 有综述，GraphRAG 有现成实现——任何团队一个月内都能把五个方向各搭一版。搭完之后呢？哪一版更好？在你自己的数据上，没人知道——除非你有评测集。

Anthropic 那张漂亮表格的前提是人家测了；Clinical 场景那项研究里，"按主题边界切块"让检索 F1 从 0.24 翻到 0.64——这么大的差异，不测就是纯玄学。评测集的搭建也没那么玄：不用追求大而全，从真实失败案例反向构造 30–50 道题（每题标注"正确答案来自哪个块"），跑 recall@k 和失败率，就够支撑绝大多数决策了。RAGAS 这类框架可以加分，但自建的 30 道真题永远比别人的 1000 道基准题有用。

这也是我在第 14 篇总结的那条硬规则的 RAG 版："这个东西如果坏了，我怎么知道？"——检索变差往往不报错，只是答案悄悄变笨。没有评测闭环的 RAG 团队，等于闭着眼睛开车。

8. 落地：我的 33 块试验田，三步升级

诚实说，我自己的项目就停在"烂大街层"：33 块纯向量召回，EMBED_TOP_K=5，Top-1 命中靠的是语料干净（第 3 篇的运气）。按这篇的框架，我的升级路线按性价比排序：

  1. 入库侧上 Contextual Retrieval（半天）：16 个文档总共 33 块，入库时让 DeepSeek 给每块写 50 字处境说明——数据量小到成本可以忽略，预期收益最确定；
  2. 查询侧加自检环（半天，第 3 章的 CRAG 轻量版）：search_knowledge 结果先判"够不够"，不够改写再查——正好复用现成的 LangGraph 循环和 MCP 工具链，这是"最小工具集"路线的标准姿势；
  3. 攒 30 题评测集（一天，但永远增值）：从真实问法反向出题，标好标准出处块。前两步做得对不对，全靠它说话。

至于图谱、记忆系统和知识编译，我的语料太小、交互历史太短，暂时不交那个税——知道什么税不用交，也是竞争力的一部分。

9. 可复用清单

  • 烂大街的是流水线，不是"正确时机拿到正确上下文"这个问题——95% 的系统还停在单路向量。
  • 入库侧的上下文密度决定查询侧天花板：Contextual Retrieval（块前拼处境说明）降低 67% 检索失败，是性价比之王；late chunking 是它的嵌入侧孪生。
  • Agentic 红利不需要重装备：一个检索工具 + "够不够"自检环 = CRAG 的八成收益；工具堆多了反而乱。
  • 先给问题分类再选架构：单跳事实题朴素 RAG 最强，全局归纳才轮到图谱；图谱的构建税（数千万 token）先问值不值。
  • 交互记忆是另一个物种：链式关系查询向量空间表示不了，Mem0/Graphiti 按需上；规则类记忆用一个 Markdown 文件就够。
  • 知识编译是预编译层，不是 RAG 替代品：DeepWiki 内部仍是 RAG；适合读多写少的知识域，代价是写入侧重算和"Wiki 过期不报错"的一致性问题。
  • 评测集是唯一抄不走的护城河：30 道从真实失败案例反推的真题，胜过任何公开基准。
  • 知道什么税不用交，也是竞争力。

下一篇预告

A 辑下一篇想写 A5「Agentic Search 与 Deep Research」：把第 3、4 章的"检索调度员"展开讲透——四层递进怎么一步步落进 LangGraph、结构化研究笔记怎么设计、以及"证据不足回头补查"这个闭环为什么是 Deep Research 和普通 RAG 的真正分水岭。要的话我接着写。

参考资料

  1. 项目源码（仍在更新中） —— 本文升级路线对应 backend/app/services/{rag_service,knowledge_loader}.py
  2. Anthropic - Introducing Contextual Retrieval —— -67% 检索失败率的完整数字与方法
  3. Do We Still Need GraphRAG?（RAGSearch 基准，arXiv 2604.09666） —— Agentic Search 与 GraphRAG 的统一对比
  4. Agentic RAG 综述（arXiv 2501.09136） —— 四层递进分类与训练路线
  5. LightRAG（HKU） —— 图谱轻量化：双粒度检索
  6. HippoRAG（arXiv） —— 海马体记忆索引 + Personalized PageRank
  7. Zep Graphiti —— 时序知识图谱记忆，检索期零 LLM
  8. Mem0 —— 会话级记忆层
  9. DeepWiki（Cognition） —— 仓库级自动维基 + 对话式问答；Devin 的预编译知识层
  10. STORM / Co-STORM（斯坦福） —— LLM 从零生成 Wikipedia 式文章的开源实现
avatar
文章
阅读
粉丝