RAG 烂大街？烂大街的只是那条流水线——真正的分水岭在这六处
RAG 烂大街？烂大街的只是那条流水线——真正的分水岭在这六处
Spots 
当"会搭 RAG"不再稀缺，核心竞争力搬去了哪里 📦 项目源码：weather-travel-recommend-system ——…
当"会搭 RAG"不再稀缺，核心竞争力搬去了哪里 📦 项目源码：weather-travel-recommend-system —— 基于气象大数据的出行推荐系统，AI Agent 全栈项目。FastAPI + PostgreSQL(TimescaleDB/pgvector/PostGIS) + Redis；LangGraph + MCP + Skill + RAG，对接 DeepSeek API。
📦 项目源码：weather-travel-recommend-system —— 基于气象大数据的出行推荐系统，AI Agent 全栈项目。FastAPI…
📦 项目源码：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 年这套流程已经写在每一个教程的第一页。但有个数据很讽刺：202…
TL;DR：2023 年你写"切块→嵌入→TopK→塞 Prompt"能拿 offer，2026 年这套流程已经写在每一个教程的第一页。但有个数据很讽刺：2025 年的统计里，95% 的 RAG 系统仍然只用单路向量检索——也就是说，绝大多数系统停在教科书的及格线上，而及格线之上还有六道真正的分水岭：把上下文还给切块（Contextual Retrieval，检索失败率降 67%）、让检索从"动作"变"决策"（Agentic RAG）、按问题类型路由而不是追新架构、从查文档升级到长记忆、把文档库"预编译"成 Wiki（知识编译）、以及一条谁也抄不走的评测闭环。这篇讲清每道分水岭的底层逻辑、关键数字和对应的开源项目，最后给我自己项目定的三步升级路线。
TL;DR：2023 年你写"切块→嵌入→TopK→塞 Prompt"能拿 offer，2026 年这套流程已经写在每一个教程的第一页。但有个数据很讽刺：202…
TL;DR：2023 年你写"切块→嵌入→TopK→塞 Prompt"能拿 offer，2026 年这套流程已经写在每一个教程的第一页。但有个数据很讽刺：2025 年的统计里，95% 的 RAG 系统仍然只用单路向量检索——也就是说，绝大多数系统停在教科书的及格线上，而及格线之上还有六道真正的分水岭：把上下文还给切块（Contextual Retrieval，检索失败率降 67%）、让检索从"动作"变"决策"（Agentic RAG）、按问题类型路由而不是追新架构、从查文档升级到长记忆、把文档库"预编译"成 Wiki（知识编译）、以及一条谁也抄不走的评测闭环。这篇讲清每道分水岭的底层逻辑、关键数字和对应的开源项目，最后给我自己项目定的三步升级路线。 分水岭一：把上下文还给切块——Contextual Retrieval 分水岭二：检索从"动作"变"决策"——Agentic RAG
先把"烂大街"拆准。烂大街的是什么？是 Naive RAG 那条流水线：切块 → 嵌入 → 向量库
先把"烂大街"拆准。烂大街的是什么？是 Naive RAG 那条流水线：切块 → 嵌入 → 向量库 TopK → 拼 Prompt → 生成。它烂大街到什么程度——开源框架把它封装成了一个函数调用，任何架构师一周内都能搭出一个"能演示"的版本。 演示能跑和生产可用之间的鸿沟，就是竞争力所在。行业里有句话我深以为然：RAG 项目的失败，80% 不在算法，在数据质量和检索质量的度量缺失。
还有一个经常被拿来说事的问题："长上下文模型会不会杀死 RAG？"我的判断是：杀死不了，但会重新分工。Anthropic 自己给过一个分界参考：知识库小于…
还有一个经常被拿来说事的问题："长上下文模型会不会杀死 RAG？"我的判断是：杀死不了，但会重新分工。Anthropic 自己给过一个分界参考：知识库小于 20 万 token（约 500 页）时，直接全塞 Prompt 加缓存更省事；但库一大，检索依然是唯一经济的方案——而且企业场景里还有长上下文给不了的三样东西：权限隔离（谁能看哪部分）、数据新鲜度（文档在变）、成本（每请求都塞全库，账单会教做人）。 所以问题从来不是"要不要 RAG"，而是"你的 RAG 凭什么不是及格线水平"。下面五处，就是我梳理 2025–2026 这波演进后认为真正拉开差距的地方。 2. 分水岭一：把上下文还给切块——Contextual Retrieval 先看一组我认为是这两年 RAG 领域性价比最高的数字，来自 Anthropic 的实验（指标：top-20 检索失败率）： 做法朴素到令人发笑：切块入库前，让 LLM 看着整篇文档，给每个块写一段 50–100 token 的"处境说明"（这块属于哪个文档、哪个章节、讲什么的），拼在块前面再去做嵌入和 BM25 索引。
为什么有效？回到第 3 篇讲过的切块损耗：一个块写着"营收环比增长 3%"，但它从文档里被切出来的那一刻就不知道"哪家公司、哪个季度"了——语义检索和关键词检索…
为什么有效？回到第 3 篇讲过的切块损耗：一个块写着"营收环比增长 3%"，但它从文档里被切出来的那一刻就不知道"哪家公司、哪个季度"了——语义检索和关键词检索都救不了它。Contextual Retrieval 做的事，就是把切掉的那半句语义补回来。
它背后的思路比技巧本身更值钱：把算力花在入库时，换查询时的可靠。入库是一次性的（用 Prompt 缓存后成本约 $1/M…
它背后的思路比技巧本身更值钱：把算力花在入库时，换查询时的可靠。入库是一次性的（用 Prompt 缓存后成本约 $1/M token），查询是千万次的。同思路的还有 late chunking：先让长上下文嵌入模型读完整篇文档，再切分它输出的 token 级向量——每个块的向量天然带着全文语境。两条路殊途同归：索引侧的上下文密度，决定了查询侧的天花板。 顺带一提，这也解释了为什么 BM25 不该被扔：补出来的上下文里全是公司名、产品编号这类精确词——恰恰是第 3 篇说的"向量盲区"，两路合起来才是完整的。 3. 分水岭二：检索从"动作"变"决策"——Agentic RAG Naive RAG 的动作是写死的：查一次，答一次。Agentic RAG 把模型从"答题者"升级成"检索调度员"——它自己决定查不查、查什么、够不够、要不要再查。业界把它拆成四层递进： 路由：判断查不查、走哪条通道（改写？数据库？网页？）； 自适应检索：边查边判断"继续还是作答"——Self-RAG / CRAG 的思想； 多智能体分工：检索、改写、验证、生成各配专职 agent。
这里有个对工程实践无比友好的结论。2026 年的 RAGSearch 统一基准（Do We Still Need…
这里有个对工程实践无比友好的结论。2026 年的 RAGSearch 统一基准（Do We Still Need GraphRAG?）系统对比后发现：只配"最小工具集"的 Agentic RAG——一个检索工具加少量辅助——就能大幅拉近与 GraphRAG 的差距，尤其在强化学习设定下几乎追平；重型图谱真正守住的阵地只剩"复杂多跳推理"。也就是说：Agentic 化的红利不需要重装备，Function Calling 加两三个趁手的工具就能吃到大部分。