[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f13ucqgzqlajun":3},{"_id":4,"slug":5,"title":6,"subtitle":6,"kind":7,"cards":8,"tags":56,"categories":57,"source":58,"lang":61,"author":62,"audioState":65,"stats":66,"publishedAt":69,"renderer":70},"6abab965ca21c797c7e9a34a","rag-bbdb11e0","RAG 烂大街？烂大街的只是那条流水线——真正的分水岭在这六处","news",[9,12,17,22,27,31,36,41,46,51],{"headline":6,"body":6,"imageUrl":10,"images":11},"\u002Fapi\u002Fmedia\u002Fposts\u002Frag-bbdb11e0\u002F0.webp",{"local":10},{"headline":13,"body":14,"imageUrl":15,"images":16},"当\"会搭 RAG\"不再稀缺，核心竞争力搬去了哪里 📦 项目源码：weather-travel-recommend-system ——…","当\"会搭 RAG\"不再稀缺，核心竞争力搬去了哪里 📦 项目源码：weather-travel-recommend-system —— 基于气象大数据的出行推荐系统，AI Agent 全栈项目。FastAPI + PostgreSQL(TimescaleDB\u002Fpgvector\u002FPostGIS) + Redis；LangGraph + MCP + Skill + RAG，对接 DeepSeek API。","\u002Fapi\u002Fmedia\u002Fposts\u002Frag-bbdb11e0\u002F1.webp",{"local":15},{"headline":18,"body":19,"imageUrl":20,"images":21},"📦 项目源码：weather-travel-recommend-system —— 基于气象大数据的出行推荐系统，AI Agent 全栈项目。FastAPI…","📦 项目源码：weather-travel-recommend-system —— 基于气象大数据的出行推荐系统，AI Agent 全栈项目。FastAPI + PostgreSQL(TimescaleDB\u002Fpgvector\u002FPostGIS) + Redis；LangGraph + MCP + Skill + RAG，对接 DeepSeek API。","\u002Fapi\u002Fmedia\u002Fposts\u002Frag-bbdb11e0\u002F2.webp",{"local":20},{"headline":23,"body":24,"imageUrl":25,"images":26},"TL;DR：2023 年你写\"切块→嵌入→TopK→塞 Prompt\"能拿 offer，2026 年这套流程已经写在每一个教程的第一页。但有个数据很讽刺：202…","TL;DR：2023 年你写\"切块→嵌入→TopK→塞 Prompt\"能拿 offer，2026 年这套流程已经写在每一个教程的第一页。但有个数据很讽刺：2025 年的统计里，95% 的 RAG 系统仍然只用单路向量检索——也就是说，绝大多数系统停在教科书的及格线上，而及格线之上还有六道真正的分水岭：把上下文还给切块（Contextual Retrieval，检索失败率降 67%）、让检索从\"动作\"变\"决策\"（Agentic RAG）、按问题类型路由而不是追新架构、从查文档升级到长记忆、把文档库\"预编译\"成 Wiki（知识编译）、以及一条谁也抄不走的评测闭环。这篇讲清每道分水岭的底层逻辑、关键数字和对应的开源项目，最后给我自己项目定的三步升级路线。","\u002Fapi\u002Fmedia\u002Fposts\u002Frag-bbdb11e0\u002F3.webp",{"local":25},{"headline":23,"body":28,"imageUrl":29,"images":30},"TL;DR：2023 年你写\"切块→嵌入→TopK→塞 Prompt\"能拿 offer，2026 年这套流程已经写在每一个教程的第一页。但有个数据很讽刺：2025 年的统计里，95% 的 RAG 系统仍然只用单路向量检索——也就是说，绝大多数系统停在教科书的及格线上，而及格线之上还有六道真正的分水岭：把上下文还给切块（Contextual Retrieval，检索失败率降 67%）、让检索从\"动作\"变\"决策\"（Agentic RAG）、按问题类型路由而不是追新架构、从查文档升级到长记忆、把文档库\"预编译\"成 Wiki（知识编译）、以及一条谁也抄不走的评测闭环。这篇讲清每道分水岭的底层逻辑、关键数字和对应的开源项目，最后给我自己项目定的三步升级路线。 分水岭一：把上下文还给切块——Contextual Retrieval 分水岭二：检索从\"动作\"变\"决策\"——Agentic RAG","\u002Fapi\u002Fmedia\u002Fposts\u002Frag-bbdb11e0\u002F4.webp",{"local":29},{"headline":32,"body":33,"imageUrl":34,"images":35},"先把\"烂大街\"拆准。烂大街的是什么？是 Naive RAG 那条流水线：切块 → 嵌入 → 向量库","先把\"烂大街\"拆准。烂大街的是什么？是 Naive RAG 那条流水线：切块 → 嵌入 → 向量库 TopK → 拼 Prompt → 生成。它烂大街到什么程度——开源框架把它封装成了一个函数调用，任何架构师一周内都能搭出一个\"能演示\"的版本。 演示能跑和生产可用之间的鸿沟，就是竞争力所在。行业里有句话我深以为然：RAG 项目的失败，80% 不在算法，在数据质量和检索质量的度量缺失。","\u002Fapi\u002Fmedia\u002Fposts\u002Frag-bbdb11e0\u002F5.webp",{"local":34},{"headline":37,"body":38,"imageUrl":39,"images":40},"还有一个经常被拿来说事的问题：\"长上下文模型会不会杀死 RAG？\"我的判断是：杀死不了，但会重新分工。Anthropic 自己给过一个分界参考：知识库小于…","还有一个经常被拿来说事的问题：\"长上下文模型会不会杀死 RAG？\"我的判断是：杀死不了，但会重新分工。Anthropic 自己给过一个分界参考：知识库小于 20 万 token（约 500 页）时，直接全塞 Prompt 加缓存更省事；但库一大，检索依然是唯一经济的方案——而且企业场景里还有长上下文给不了的三样东西：权限隔离（谁能看哪部分）、数据新鲜度（文档在变）、成本（每请求都塞全库，账单会教做人）。 所以问题从来不是\"要不要 RAG\"，而是\"你的 RAG 凭什么不是及格线水平\"。下面五处，就是我梳理 2025–2026 这波演进后认为真正拉开差距的地方。 2. 分水岭一：把上下文还给切块——Contextual Retrieval 先看一组我认为是这两年 RAG 领域性价比最高的数字，来自 Anthropic 的实验（指标：top-20 检索失败率）： 做法朴素到令人发笑：切块入库前，让 LLM 看着整篇文档，给每个块写一段 50–100 token 的\"处境说明\"（这块属于哪个文档、哪个章节、讲什么的），拼在块前面再去做嵌入和 BM25 索引。","\u002Fapi\u002Fmedia\u002Fposts\u002Frag-bbdb11e0\u002F6.webp",{"local":39},{"headline":42,"body":43,"imageUrl":44,"images":45},"为什么有效？回到第 3 篇讲过的切块损耗：一个块写着\"营收环比增长 3%\"，但它从文档里被切出来的那一刻就不知道\"哪家公司、哪个季度\"了——语义检索和关键词检索…","为什么有效？回到第 3 篇讲过的切块损耗：一个块写着\"营收环比增长 3%\"，但它从文档里被切出来的那一刻就不知道\"哪家公司、哪个季度\"了——语义检索和关键词检索都救不了它。Contextual Retrieval 做的事，就是把切掉的那半句语义补回来。","\u002Fapi\u002Fmedia\u002Fposts\u002Frag-bbdb11e0\u002F7.webp",{"local":44},{"headline":47,"body":48,"imageUrl":49,"images":50},"它背后的思路比技巧本身更值钱：把算力花在入库时，换查询时的可靠。入库是一次性的（用 Prompt 缓存后成本约 $1\u002FM…","它背后的思路比技巧本身更值钱：把算力花在入库时，换查询时的可靠。入库是一次性的（用 Prompt 缓存后成本约 $1\u002FM token），查询是千万次的。同思路的还有 late chunking：先让长上下文嵌入模型读完整篇文档，再切分它输出的 token 级向量——每个块的向量天然带着全文语境。两条路殊途同归：索引侧的上下文密度，决定了查询侧的天花板。 顺带一提，这也解释了为什么 BM25 不该被扔：补出来的上下文里全是公司名、产品编号这类精确词——恰恰是第 3 篇说的\"向量盲区\"，两路合起来才是完整的。 3. 分水岭二：检索从\"动作\"变\"决策\"——Agentic RAG Naive RAG 的动作是写死的：查一次，答一次。Agentic RAG 把模型从\"答题者\"升级成\"检索调度员\"——它自己决定查不查、查什么、够不够、要不要再查。业界把它拆成四层递进： 路由：判断查不查、走哪条通道（改写？数据库？网页？）； 自适应检索：边查边判断\"继续还是作答\"——Self-RAG \u002F CRAG 的思想； 多智能体分工：检索、改写、验证、生成各配专职 agent。","\u002Fapi\u002Fmedia\u002Fposts\u002Frag-bbdb11e0\u002F8.webp",{"local":49},{"headline":52,"body":53,"imageUrl":54,"images":55},"这里有个对工程实践无比友好的结论。2026 年的 RAGSearch 统一基准（Do We Still Need…","这里有个对工程实践无比友好的结论。2026 年的 RAGSearch 统一基准（Do We Still Need GraphRAG?）系统对比后发现：只配\"最小工具集\"的 Agentic RAG——一个检索工具加少量辅助——就能大幅拉近与 GraphRAG 的差距，尤其在强化学习设定下几乎追平；重型图谱真正守住的阵地只剩\"复杂多跳推理\"。也就是说：Agentic 化的红利不需要重装备，Function Calling 加两三个趁手的工具就能吃到大部分。","\u002Fapi\u002Fmedia\u002Fposts\u002Frag-bbdb11e0\u002F9.webp",{"local":54},[],[],{"name":59,"url":60},"Juejin","https:\u002F\u002Fjuejin.cn\u002Fpost\u002F7690218295266066441","zh",{"handle":63,"displayName":64},"spots","Spots",null,{"views":67,"likes":68,"saves":68,"shares":68,"completions":68,"opens":68,"skips":68,"depthSum":68},3,0,"2026-09-28T19:00:53.586Z","local"]