Retrieval-Augmented GenerationRAG，检索增强生成

01是什么 / 为什么#rag-what-why

三步流程：

与微调的边界一句话：RAG 改的是「知识」，微调改的是「行为」。知识频繁变动、要引用出处、私有数据多、要快速上线——选 RAG；要固定输出格式/语气、教会模型新技能——才考虑微调，二者常组合（取舍参照 Fine-tuning 模块）。「资料全塞超长 Prompt」不可行的原因在推理侧：长上下文两头吃钱、注意力被稀释——机制账见 LLM-Inference 网页版。RAG 不能彻底消除幻觉，但「给了资料 + 要求带出处」能大幅降低，剩余风险靠重排与评估兜底。

02向量检索与 Embedding#rag-embedding

检索＝问题向量找最近的 Top-K 片段向量（余弦相似度看方向多接近）。K 是召回与噪声的权衡：太小漏答案、太大塞噪声——常见做法先多召回、再交给重排精选。大规模检索用 ANN（Approximate Nearest Neighbor，近似最近邻）：不跟库里每条向量逐一比对，靠索引（主流是 HNSW）牺牲一点点召回换百倍速度，生产标配。这意味着召回率天生不是 100%——那是设计取舍，不是 bug：客户问「这条明明在库里，为什么没检索到」，先答这一层，再看是不是切分或 Top-K 的问题。

选型三问：①数据能否出企业（API vs 自建）②要不要多语言 ③量级与预算。先小模型跑通、按评估结果升级。

选型口径核实 2026-07-07，来源 2026 对比与 arXiv 2402.03216（BGE M3）。

03切分策略#rag-chunking

为什么非切不可（客户常问「整篇丢进去不行吗」）：Embedding 与上下文都有长度上限，而检索要的是「精准的那一段」不是整篇——把 50 页手册当一个块，检索命中它就等于把 50 页全塞进上下文，既贵又稀释重点。切分躲不掉，也正因为躲不掉，它是实施工作量的大头、报价时不能漏的一项。

两个旋钮的起点：每块约 300–500 Token、重叠 10–20%（重叠像剪胶片时让相邻段共享几帧，避免把一句话拦腰劈断）——没有万能数值，起步后拿评估集实测调优。策略从简单到讲究：固定长度切（快速起步）→ 按结构切（顺着标题/段落/表格边界，结构清晰文档的好默认）→ 语义切分（句向量找话题切换点）→ 父子多粒度（小块精准检索、命中后回溯大块作答）。

上下文检索（Contextual Retrieval，Anthropic 提出）是近年最实用的低门槛增强：入库前用大模型给每个块生成一句「它在整篇文档里的定位」，前置进块里再嵌入——像给每张便利贴补一行「这是《退货政策》里关于生鲜商品的部分」。

文档全是 PDF / 扫描件时先过文档智能解析（OCR），解析质量决定切分质量（上游供给见 Data-Engineering）。

上下文检索数据来源 Anthropic Cookbook，核实 2026-07-07。不可外推边界：这是在特定数据集上、对检索失败率的相对降幅，不是准确率的绝对提升；换语料与切分策略结果会变。

04重排序#rag-reranking

机制差别：双编码器把问题和文档各自独立编码，可预建索引、能扫全库但略粗；交叉编码器把「问题+文档」拼一起联合打分，捕捉细粒度关联、准得多——但每候选实时算一次，没法预建索引，所以只做第二阶段、精排少量候选。

选型（2026-07 口径）：

收益成本账：多几百毫秒和一次调用费，换准确率明显提升——对质量敏感的场景（合规问答）几乎必上，对延迟极敏感的实时场景再权衡。

Reranker 格局核实 2026-07-12（Cohere v4.0 系为当前主线），来源 docs.cohere.com 与 2026 对比。不可外推边界：版本是当日主线，重排模型迭代快；排序质量对领域敏感，通用榜领先不等于在你的语料上领先。

05评估与诊断#rag-evaluation

归因先分两侧

四个核心指标与生产参考阈值

最终按业务风险定线。

评估方法论的完整展开（判分四法 / 判官校准 / 黄金集）在 Evaluation 网页版——那页收编了本节的三角指标。

更细一层是六段诊断：解析（内容完整进库？）→ 切分（块边界合理？）→ 召回（证据进候选池？）→ 重排（证据排到前面？）→ 上下文（证据密度够？）→ 生成引用（主张被支撑？）——同样是「答错」，三种病吃三种药：gold chunk 没进池修检索、进了池没进上下文修重排与预算、进了上下文还答错修提示词或换模型。

06最小管线#rag-pipeline

最小可用版本比想象中小：纯 API + 向量库客户端几十行代码——切分（第 3 节）、嵌入建库（第 2 节）、宽召回精排（第 4 节）、带出处生成（第 1 节），每段代码对应一节。框架不是必需品：管线简单就纯 API 拼（透明好排障）；生产常见组合是 LlamaIndex 管数据接入、 LangGraph 管多步编排、Langfuse/LangSmith 管观测——各管一段，不是二选一。

给客户报量级：能跑的原型几天，「可用」两周级——难点从来不是调模型 API，而是把文档变成高质量的块（解析、切分调优、建评估集）。对接现有文档系统走连接器增量同步，要确认的是权限映射：文档系统里的可见性要在检索层复刻（见 生产化）。

07混合检索#rag-hybrid

企业语料里型号、代号、专名密度极高——纯向量检索的翻车率被普遍低估。

融合用 RRF（Reciprocal Rank Fusion，倒数排名融合）：两套分数不可比（BM25 无上界、余弦 0~1），RRF 只看名次——按 1/(k+r) 相加，k=60（Elasticsearch 默认）开箱即用。算一遍就懂：文档 A 在 BM25 第 1、向量第 8 → 0.031；文档 B 两榜都第 3 → 0.032 胜——两边都不错的稳健选手，赢过单边冠军。生产标配三段式：双路宽召回（各 Top-50~100，求不漏）→ RRF 融合（不比分数、不用调权）→ 交叉编码器重排取 Top-10（求不错）。

落地捷径：Elasticsearch / OpenSearch 已原生支持向量检索与 RRF 混合查询——存量 ES 用户升级配置即可，数据不搬家、运维不新增；向量库阵营（Qdrant/Milvus/Weaviate）用稀疏+稠密双向量一次查询完成融合。成本增量主要是 BM25 索引存储，比向量便宜得多。

RRF 为主流引擎原生支持（Elasticsearch 默认 k=60、Qdrant 默认 k=2），核实 2026-10-20，来源 Elasticsearch / Qdrant 官方文档。不可外推边界：默认 k 各引擎不同，且都是出厂值，不是对某个语料调优的结果；要不要调，用自己的评估集回答。

08Agentic RAG#rag-agentic

经验路径：从 Router 起步 → 需要多跳再上 ReAct → CRAG 随时叠加兜底，别一上来就 Multi-Agent。成本口径要主动讲：每多一轮检索多一轮模型调用，token 通常 2~5 倍、延迟从一秒级到几秒级——用路由分流，简单问题走朴素管线。护栏三件：限最大检索轮数（如 3 轮）、工具白名单、每步落日志——它本质是个带循环上限的状态机，比听起来可控。

与 Agent 的接缝一句话：RAG 给模型「开卷的书」，Agent 给模型「动手的手」，Agentic RAG 就是让那双手自己去翻书——把检索管线注册成 agent 的一个工具，两边投资都复用（循环与工具的机制在 Agent 网页版）。

五大模式与 CRAG 来源 arXiv 2501.09136 / LangGraph 官方教程，核实 2026-07-08。不可外推边界：论文与教程给的是模式骨架，不含各模式的成本与延迟代价；多轮检索会把单次问答的 token 与耗时抬上去，选型要连成本一起比。

09生产化与常见坑#rag-production

Trace 的价值实例：正确片段其实在 Top-5、但排第 4、被截断在上下文之外——问题在截断策略，不在检索；没有 Trace，多半冤枉嵌入模型。排障三问固定问：检索到没有？排上来没有？用上没有？

成本、权限、可信

算账口径：月成本 ≈ 建库一次性 + 增量嵌入 + 存储 +（检索+重排+生成）× 月问量 × （1 − 缓存命中率）——命中率是最值得投资的变量。三层缓存各砍一件重复劳动：嵌入缓存省重算、语义缓存让相似问题直接命中历史答案（客服约四成问题重复，生成成本立砍四成）、 Prompt 缓存省重复上下文的输入费。

权限在检索层设卡：每个块入库带 ACL 元数据（部门/密级/角色），查询时按提问者身份过滤候选集——安检设在书库门口，不是等读者借走再追回。真实翻车模式：全公司文档进同一个向量库不带权限元数据，员工问「高管薪酬方案」居然真答出来了。安全三件套：数据不出租户、检索层 ACL、审计日志——可溯源是 RAG 相对纯生成的安全加分项。可信回答还要过四层证明：可访问（当前用户有权看）→ 可定位（指认出处）→ 可支持（真被证据支撑）→ 可呈现（可点摘录/冲突提示/拒答）——像法庭证据链，断一环整条作废。

上线前的验收：一条回答能不能复现

把前面十二章各留一条验收证据串起来，收敛成一句可执行的终极判断：

10GraphRAG#rag-graphrag

四步：实体抽取 → 建图 → 社区检测（Leiden 分区）→ 分层摘要——像出版社给一万本书做导读体系。查询两条路：本地查询沿实体邻居找证据（细节题），全局查询汇总社区摘要（全局题）。贵在索引期：每块过 LLM 抽取、每社区预写摘要。

值得付 6–8 倍索引成本的三类问题：全局归纳（「主要主题/趋势」）、关系追溯（「A 通过什么关联到 B」）、合规审计（出处链有法律意义）。起步建议：先把混合检索+重排做扎实，收集三个月真实问题——全局性/关系性问题占比可观（如超一成）再用 LazyGraphRAG 小语料试点。增量更新是痛点：语料高频变化的场景选 LazyGraphRAG 或把图谱限定在稳定核心语料上。

成本账核实 2026-07-09，来源 Microsoft GraphRAG 文档与 2026 实践者评测。不可外推边界：索引成本的倍数随语料规模与实体密度变化很大，文档给的是其示例语料下的口径；小语料上的倍数不能外推到全量知识库。

11多模态 RAG#rag-multimodal

三条路线从便宜到强（②的代表：Cohere Embed 5 / voyage-multimodal-3.5；③的 MaxSim 逐词对格打分，表格、图表、手写体一视同仁）：

选型口诀：图少且简单→转述最划算；产品图/截图混在文档里→统一嵌入；扫描件海量、查询「视觉难」→ColPali 系。先便宜后贵、增量演进：先转述兜底，三个月后看坏答案，「视觉难」查询集中失败再对那部分语料上多向量。生成端要配套能看图的模型才闭环——「模型怎么看懂图」的能力边界在 Multimodal 模块（那边给眼睛，本节给眼睛配图书馆）。

三路线格局核实 2026-07-09，来源 arXiv 2407.01449（ColPali）与 2026 实践综述。不可外推边界：论文口径以文档视觉检索基准为主，落地效果强依赖文档类型；扫描件、图纸、表格密集的材料差异很大，按自己的材料实测。

12查数与语义层#rag-structured

裸 Text-to-SQL 为什么不及格：模型写标准 SQL 语法早已过关，难在语义落地——真实企业库几百张表、字段名像密码、同一个「收入」五种口径。准确率随基准的「真实程度」断崖式下滑：学术单轮基准（Spider / BIRD）能到 80–90%，中等企业化基准掉到 50–70%，最贴近真实脏 schema 的企业基准（Spider 2.0 类）低到 10–21%——所以对客要讲最低那档（场景视角与口径战场见 Solution-Patterns ChatBI 节）。而且错法危险：SQL 跑得通、数字是错的（静默错误）。同一个「去年营收多少」，sum 订单表（含取消单）和 sum 财务确认收入能差 15%，都「语法正确」。

不用先重构几百张表：先给 20 个高频指标建口径映射就能上线——语义层是「乱库上面的整洁层」。

风险三道闸

生产定式：RAG 做检索层 + 语义层做回答层，查文 / 查数入口路由。场景视角（ChatBI 口径战场）在 Solution-Patterns 第 8 章。

语义层前后 50–70% → 85–95% 为 dbt 2026 基准口径（核实 2026-07-09）；裸 SQL 随基准真实度分档（学术 80–90% / 中等 50–70% / 最难企业基准 10–21%）经 2026-07-23 复核、2026-09-05 与 SP 册对齐，来源 dbt 基准与 Spider 2.0 / 企业化基准（BEAVER、Spider-Ent）。不可外推边界：准确率强依赖 schema 复杂度与基准口径，别拿学术单轮数字对客报真实企业库。

13上云怎么落地#cloud

离线建库：把文档变成查得动的库

顺着追问什么：文档现在放在哪、有多少、多久变一次？扫描件和表格占多大比例（决定要不要上 OCR 与版面解析）？文档系统里谁能看什么——那套权限要在检索层复刻吗？

云替你做不了什么：托管 RAG 把管线接起来，不保证它内置的切分策略适合你的语料——切多大、重叠多少仍要用评估集实测（见切分策略）。还有一笔要在选型当天就报给客户的账：换嵌入模型等于换坐标系，全库必须重算（见向量检索与 Embedding）——托管服务让重算这件事更省心，但省不掉。

在线问答：一次提问怎么走完

顺着追问什么：客户的高频查询里，型号、错误码这类必须一字不差的占多少（这个比例直接决定混合检索的价值，见混合检索）？端到端延迟能接受到几秒——决定要不要上 agentic 环（见Agentic RAG）。

云替你做不了什么：托管检索一键开启的重排用的是平台自己的模型，效果好不好仍要用你的评估集验，不是开了就赢。「生成端点可换」说的是接口可换，不是换了模型效果不变——换模型要重跑评估集。

工程保障：上线之后靠什么活着

顺着追问什么：出了一条坏答案，现在多久能定位到是检索段还是生成段？谁有权看到全量问答日志——这批日志本身就是敏感数据。评估集打算多久跑一次，谁看结果？

云替你做不了什么：IAM 管的是谁能调用这个接口，管不了检索回来的片段该不该给这个人看——那道卡设在检索层的元数据过滤上，设漏了就是「员工问出高管薪酬」（见生产化与常见坑）。语义缓存按相似度命中，问题相近而答案因人而异的场景会串答，缓存键必须带身份。

按场景才用得到的三块

顺着追问什么：这三块每一块动手前都先问同一句——不用它，混合检索加重排能到几分？拿评估集跑出那个数，再决定值不值得加一层。

云替你做不了什么：托管图库解决的是「图谱放哪」，解决不了「图谱抽得准不准」——全量 GraphRAG 索引成本是 6–8 倍，批量接口省的是索引期那一次，不是每次查询（见GraphRAG）。语义层把准确率抬到 85–95% 是基准库口径，自家 schema 更复杂，必须实测（见查数与语义层）。

本节服务清单与「给客户一句话」与讲义各章的「上云怎么落地」页同源，未引入新事实；成本量级（GraphRAG 6–8 倍、批价约 5 折、语义层 85–95%）见来源与核实登记。不可外推边界：这是「哪个环节有云服务可用」的地图，不是选型结论——具体产品的地域可用性、配额、计价单位与生命周期状态会月级变动，出方案前按当期官方文档逐项复核。

14现场高频追问#qa

只收会改变某个决定的问题——会改变技术方案、风险判断、验收方法、对客沟通或下一步行动。

每题标出它加入本题库的日期：2026-07-07/08 来自讲义首版对练页，2026-07-09 来自进阶三章，2026-07-12 来自 Reranker 格局复核，2026-07-23 是按客户交锋场景补的四题（准确率承诺 / 已有系统 / 换模型 / POC 验收）。

15相关模块#related

同一个概念在库里只有一个主要归属，其余模块讲的是它的另一个层面。

16来源与核实#sources

本页时效性数字均经联网核实后写入，完整登记（事实 × 核实日期 × 信源）见本模块 MANIFEST。核实窗口 2026-07-07 至 2026-07-12。引用任何数字前先核日期。