RAG是一种范式全链路拆解（个人观点）

个人观点整理：市面上用 Claude Code 的 grep、Karpathy 的 LLM Wiki 来论证 RAG 已死，往往既没理解 RAG 的本质，也没说清这些技术和 RAG 的区别与联系。

市面上存在

claude code 使用 grep，或者以 Karpathy 的 llm wiki 为引子，公式化地讲解技术原理，然后开始说 RAG 怎么怎么样弱势，RAG 已死！这样的文章，既没有理解 RAG 的本质，也不理解他所提的这些技术和 RAG 的区别和联系。

判断维度	优先选 LLM Wiki	优先选传统 RAG
知识生命周期	长期（数月～数年），持续维护	短期（数天～数月），临时使用
数据规模	中小规模（百～千级词条）	大规模（万～百万级文档）
更新频率	低频稳定，定期迭代	高频动态，实时新增
核心诉求	体系化、可解释、可编辑	全覆盖、快上线、忠于原文
知识形态	概念、方法论、规则、经验	原始文档、条款、记录、数据
交互模式	系统学习、深度研究	单点问答、事实查询

长期沉淀、体系化的知识用 Wiki；海量、动态、原始的资料用 RAG。
它和 RAG、LLM Wiki 不在一个赛道。在代码场景下，精确的符号匹配远比语义检索可靠，Claude Code 的核心创新是把搜索的控制权交给 LLM 自主迭代，而非提前建好向量索引喂给模型。

RAG的本质

RAG 的本质并不是某一套固定工作流，而是一种更抽象的工程范式。RAG 是 Retrieval-Augmented Generation 的缩写，核心是检索—增强—生成：只要系统能够先获取外部信息，再将其用于增强模型上下文，并最终完成生成，就可以被归入 RAG 的范畴。比如说，skills 的渐进式披露、Agent Memory，都可以算是一种 RAG。

RAG 全链路示意

Chunking

我们一般会同时将 chunk 的所处章节信息作为 chunk 内容和正文拼接在一起进行向量化，并作为筛选过滤条件单独存储。这样一来，既避免了一次 chunk 中混杂不同章节的信息导致关键信息被隐藏；也因为一 chunk 限制在一章节内，避免了上下文被中断；同时，当缺少证据时，可以依据当前检索到的 chunk 的章节信息，依此作为过滤条件筛选 chunk 进行检索以补充证据，避免了指代、条件、结论不明确的问题；我们还可以先让模型依据问题判断信息可能所处的章节，以此为过滤条件进行检索，有效地提高了检索效率，降低检索成本。真是一举多得啊！

看到这里的佬友可能会想到一个东西，skills 的渐进式披露：当 skills 过多时，将各 skills 的简要功能介绍和所处位置集成为一个菜单，模型阅读这个菜单选择具体 skill 后再将具体的 skill.md 展示给模型。这和我们这里的结构化 chunking 是不是很像？skills 的渐进式披露本质上也是一种 RAG！当然这是我的个人观点，没有官方背书。

层 RAG（Hierarchical RAG）+ 元数据过滤的典型工程实践，核心是利用文档原生的章节结构，解决纯文本暴力分块的固有缺陷。

核心设计：双轨存储机制

向量化侧：将章节标题 / 层级路径与 chunk 正文拼接后共同向量化，让向量本身携带结构上下文，避免孤立分块导致的语义漂移；
过滤侧：章节信息作为独立元数据字段单独存储，支持检索前置过滤、检索后补全两种使用方式。

解决的四个核心痛点

消除跨章节语义混杂：强制 chunk 边界对齐章节边界，避免单个 chunk 混入多个无关主题的内容，大幅降低召回噪声。
保留上下文连贯性：分块被限制在单一章节内，语义场景统一，不会出现上下文断裂，提升后续生成的逻辑一致性。
支持证据动态补全：当已召回 chunk 信息不完整时，可通过章节标签定向召回同章节其他 chunk，补充指代、前提、条件等缺失信息，解决半截话导致的答案模糊。
前置缩小检索范围：可先让模型预判答案所属章节，再限定范围检索，显著缩小检索空间，既提升准确率，也降低向量检索的计算成本。

Embedding稠密与稀疏同样重要

稠密和稀疏 embedding 基本上是同时需要的，它们各自优缺点鲜明，结合使用才能优势互补。假如只有稠密向量，可能会导致专有名词或少见名词的遗漏，比如说中药石刁柏，如果稠密 embedding 模型没有进行过专业的中药材方面的训练，在没有上下文的情况下，它很难想到石刁柏其实就是我们平常吃的芦笋。在具体 chunk 中 embedding 模型尚且可以根据上下文使得该 chunk 向量与芦笋靠近，但是在用户的提问中，没有上下文补充，用户提问的向量会偏向于石头、柏树之类的东西。最终导致模型无法检索到有用信息，导致回答质量下降。如果只有稀疏向量，面对同义词、模糊描述会导致检索不完全，而面对同名不同义的词，又会检索错误。因此，在普通的问答模型的 RAG 中，稠密与稀疏 embedding 都会使用。

索引算法

学过数据库的佬友都知道，索引是一种优化技术，旨在提高数据检索的速度。索引的核心作用类似于书籍的目录，它允许系统快速定位到数据的存储位置，而无需遍历整个数据库。同样的，为了提高模型检索效率，我们在进行向量存储时，也会用到一些专门的索引算法。包括 HNSW、IVF、倒排索引等等，其实这一块不用太深究，大致知道有哪些索引即可。大家就当看个乐吧。

查询优化

检索部分最重要的其实是这个
查询优化的本质是在将用户原始问题发送给检索器之前，对其进行一系列处理、改写或增强的技术。因为不是所有模型使用者都是那么聪明（笨笨），说话都那么清楚明白的，这时候就需要 LLM 提前帮用户把话说明白，这样才方便后续的检索。你在使用大模型的过程中，模型 Thinking 时就是在做这个哦。

查询优化主要包括改写、扩写、重写、多查询、子查询和 HyDE。

重排（Rerank）

说了这么多，但我们之前的检索其实还是相当于一遍粗筛，根本原因还是在于语义相似不等于问题相关：检索找的是语义上相似的文档，但它们可能并没有直接回答用户的具体问题。同时，模型为了保证不漏掉任何信息，在检索阶段会带回大量文档（如 Top 50-100）。这其中混杂着大量不相关的内容，如果全部塞给 LLM，不仅会浪费其上下文窗口，增加成本，还可能让模型被错误信息干扰，降低回答质量。因此我们还需要进行重排。

我所熟知的重排方法包括两种，一种是 Cross-Encoder（交叉编码器），一种是基于 LLM 的重排。

Cross-Encoder（交叉编码器）模型：这是目前精度最高的方法。它将查询和文档拼接在一起，输入到一个模型中进行深度联合分析，从而输出一个精确的相关性分数。其代价是计算开销大、速度慢，通常需要对每个查询-文档对做一次独立的推理。典型代表有 bge-reranker 系列和 Cohere Rerank。
基于 LLM 的重排：直接利用强大的 LLM 进行重排。通过设计特定的提示词（Prompt），让 LLM 对候选文档列表进行阅读、比较和排序。这种方法能利用 LLM 强大的推理能力，但成本更高、速度更慢。某种意义上和其目的背道而驰了吗？

总结观点

首先一个就是目前 code agent 最常用的 grep，grep 命令本身不就是一种关键词检索吗？code agent 利用 grep 命令获取所需的代码片段用于执行任务，这正是 RAG 的定义啊。其次是 Karpathy 的 llm wiki，用这个来踩 RAG 更是诡异。Karpathy 的 LLM Wiki 指的是 Karpathy 在 2026 年 4 月提出的一种个人/团队知识库模式：让 LLM 不只是临时检索资料并回答，而是持续把资料编译成一个可维护、可链接、会累积的 Wiki。这个本质就是个会增量更新的 RAG 啊。用本质 RAG 的东西来贬低 RAG，是典型的自我反驳。

RAG 早就从传统文档进化成了一种范式，Agent Memory 需要 RAG，skills 的渐进式披露需要 RAG，自我反思与进化也需要 RAG……RAG 从来都没死过，它到处都是！

补充：定制化需求与细节优化

需要定制化需求和细节优化，可以看这里。

一、Embedding 模型选择

选择维数多且支持最大上下文大的模型。

二、Reranker 模型选择

选择支持最大上下文大的模型。

三、权限管控

在项目中搜 todo 权限 有注释的代码用。

使用 RBAC 模型，文档分配给角色，角色分配给用户。
入库流程：公用文档存入 Metadata 字段 public，私有文档 Metadata 字段添加关系型数据库的文档 ID。
提问流程：用户搜索时查询到自己权限的文档 ID，查询向量数据库时添加 Metadata 过滤字段（public、文档）。

四、向量数据库 Milvus

注意 dimension 字段要和 embedding 维度对应。
可以使用混合搜索，通过稠密向量 + 稀疏向量进行匹配，得到结果更精准。

五、上下文入关系型库

Redis 过期事件监听（整条存；由于我的项目 Redis 存上下文只存最新的 10 条对话，所以如果要用这个方案得自己改一下）。
每次 LLM 生成完之后异步添加（单条存，通过 sessionId + userId 查询）（推荐）。

六、文件解析

通过 OCR 将扫描版 PDF 转为文本（图片同理）。

向量数据库选型对照

数据库	类型	适合场景
LangChain4j In-Memory	索引库 / 内存库	Java 技术栈的 RAG 原型验证；中小型项目中追求极致低延迟的检索场景（生产不要用）
Chroma	开源	个人开发者、原型验证（PoC）、小型项目
Milvus	开源	超大规模、企业级生产系统；有专业运维团队
Pinecone	商业	追求极简运维、快速上线的商业项目
Qdrant	开源	高并发、低延迟检索；自托管且注重性价比
Weaviate	开源	知识库、智能问答等需结合语义与结构化关系
Pgvector	扩展	数据已在 PG 的轻量级 RAG 或 MVP 项目
Elasticsearch	混合引擎	已有 ES 技术栈，需要文本 + 向量一体化搜索
腾讯云 VectorDB	商业	企业级 RAG、智能客服；尤其适合腾讯云生态的企业