RAG 与知识库工程深化

• 混合检索的融合方法
• 各框架默认实现差异
• 重排序与改进

混合检索把稀疏检索（BM25 精确匹配、SPLADE 稀疏向量）与稠密检索（向量语义）结合，弥补各自短板。权重融合方面，主流做法是 RRF（Reciprocal Rank Fusion，对两路结果按排名倒数求和，无需权重调参、鲁棒）或加权线性融合（对两路分数归一化后加权求和，需调权重）。重排序：先用混合检索召回较多候选，再用 Reranker 精排。主流框架默认实现：LlamaIndex 默认用"BM25+向量"的 RRF 融合（其 QueryFusion 默认采用 RRF），重排序由独立 Reranker 提供；Haystack 提供 HybridRetriever 组合 BM25 与嵌入，融合可用加权或 RRF，重排通过 Ranker 组件；DSPy 把检索作为可编程模块，允许用 RRF/加权并在训练中优化参数。实际工程常在此基础上自定义权重或接入更强的 Reranker。

理解各框架默认融合方式（多采用 RRF 这一免调参的鲁棒方案）而非盲目调权重，是正确使用混合搜索的前提。RRF 适合"开箱即用"，加权融合适合"有明确调优预算"的场景，重排序则是在召回之上提升精度的关键一环。

• Agentic RAG 的能力
• 稳定性与提升幅度
• 生产适用性

Agentic RAG 让检索系统具备"决策能力"：模型可自主决定是否检索、检索什么、如何改写查询（Query Rewriting）、如何把复杂问题分解为子问题逐步检索（子问题分解）、以及多轮检索与工具调用。相比 Naive RAG（一次检索拼答案），Agentic RAG 在复杂、多跳、需要多源信息的问题上能显著提升召回与答案质量，提升幅度可从 10%-30% 不等（因任务而异）。但代价是：引入模型的决策不确定性，增加了失败点（误判、循环、工具调用错误），稳定性与可控性下降，token 与延迟上升。因此生产上常采用"渐进式"：先用 Naive RAG 覆盖简单问题，仅对低置信度或复杂问题触发 Agentic 路径，并加步数上限、结果校验与降级，在不牺牲稳定性的前提下获得质量提升。

Agentic RAG 的"提升幅度"与"稳定性"是权衡。它把检索从"固定的流水线"升级为"可决策的 Agent"，复杂度与灵活性同步上升。生产落地应做"Naive 兜底 + Agentic 增强"的分层，让提升只发生在值得的地方。

• 离线指标
• 在线指标
• 幻觉量化与闭环

离线评测测检索与生成质量：检索指标（Recall@k、MRR、NDCG）、生成指标（Faithfulness/忠实度、Answer Correctness、无幻觉率、引用命中率）。在线评测测真实效果：用户反馈（点赞/踩、采纳率、会话完成率）、回答被引用/被修改的比例、业务指标（转化、工单解决率）。两者联动：离线指标定位"哪一环坏了"（是检索召回不足还是生成不忠实），在线指标反映"真实用户是否满意"，通过线下回归 + 线上灰度（A/B）验证改动；幻觉量化：用忠实度评测（检查答案是否与检索上下文一致、引用是否真实存在）、无答案率（应拒答却硬答）、以及人工抽检标注，计算幻觉率，并区分为"无依据幻觉"与"证据冲突幻觉"。闭环是"离线指标驱动迭代 → 线上灰度验证 → 用户反馈回流 → 更新评测集与分块/检索/Prompt"。

RAG 评测必须有"离线诊断 + 在线验证"双环。离线能快速定位环节问题，在线能确认真实收益，幻觉作为最重要的质量指标用"忠实度 + 引用真实性 + 抽检"量化。闭环让每个优化都能被验证、被沉淀。

• GraphRAG/LightRAG 原理
• 抽取成本与延迟
• 答案质量与适用场景

GraphRAG 先把文档做实体/关系抽取，构建知识图谱，再基于图做全局与局部检索，擅长回答"跨文档、需要全局关联"的问题，答案质量高、可解释性强；但实体关系抽取成本高（需大模型处理大量文档，token 大）、构建与查询延迟高、且对抽取质量敏感。LightRAG 是轻量版，权衡了构建成本与查询延迟，用更高效的抽取与检索策略，适合资源受限或延迟敏感的场景，但全局关联能力可能弱于完整 GraphRAG。真实表现：对"需要关联多文档、复杂关系推理"的企业场景，Graph/LightRAG 明显优于纯向量 RAG；对"单文档、简单问答"场景，向量 RAG 足够且更快更便宜。取舍关键：数据规模、关系复杂度、对延迟与成本的容忍度。

GraphRAG 的价值在"关联与全局"，代价是"抽取成本与延迟"。LightRAG 是对这套权衡的中间态。工程上应根据"关系复杂度"决定是否上图谱，并评估抽取成本与延迟，避免"杀鸡用牛刀"。

• Reranker 的作用
• 三种部署方式
• 成本与延迟权衡

Reranker 在召回后对候选做精排，能显著提升相关性。部署方式：服务端自部署——用开源模型（如 BGE-Reranker）在 GPU/CPU 上部署，成本可控、延迟低、数据不出域，适合高吞吐与隐私敏感场景，但要自建运维与容量；客户端——在端侧运行小 reranker，延迟最低、隐私最好，但受设备性能限制、模型能力有限；API 调用——用托管 Rerank（如 Cohere Rerank、Jina Reranker），简单、免运维、模型强，但按量计费、延迟受网络影响、数据需出域。取舍：自部署适合规模与隐私优先，API 适合快速上线与低人力，客户端适合端侧轻量。工程上常以"延迟 SLA + 吞吐量 + 隐私要求 + 成本预算"决定，并可混合（敏感数据自部署、非敏感走 API）。

Reranker 的部署方式本质是"成本-延迟-隐私-能力"的权衡。自部署赢在成本与隐私，API 赢在简单与能力，客户端赢在延迟与隐私但能力有限。按业务约束选择，避免为简单场景过度投入。

• 三种查询理解技术
• 召回提升效果
• 成本增加

查询理解用于弥合"用户口语化问题"与"检索期望"之间的差距。Query Rewriting：用模型把查询改写为更利于检索的形式（补全、澄清、去噪），提升召回但增加一次模型调用；HyDE（Hypothetical Document Embeddings）：先让模型生成一个假设答案文档，再用其嵌入检索，提升语义召回，但可能引入幻觉且成本高；多查询融合（Multi-Query）：把一个问题拆成多个子查询分别检索再融合，提升覆盖率，但召回的 token 与延迟成倍增加。三者都能提升复杂问题召回，但都增加成本与延迟。取舍：简单问题用原生查询即可，复杂问题再按需叠加（改写 → 多查询 → HyDE 视成本而定），并评估召回提升与成本增加的比例。

查询理解是"用模型成本换召回"。技术选择应遵循"最小必要"原则：先测原生查询，不足再逐级加改写/多查询/HyDE，用"召回提升/成本"决定取舍，避免对简单问题也做昂贵处理。

• 增量索引
• 文档过期与删除
• 版本回滚与缓存失效

知识更新设计：增量索引——新文档只做增量向量化与入库，不重建全量索引，降低更新成本；文档过期——给文档设有效期与版本，过期文档标记失效并从检索中排除，删除用"墓碑"（tombstone）标记避免被重新召回；版本回滚——维护索引版本与快照，异常时可回滚到上一版本；缓存失效——文档更新后，相关缓存（如重写结果、检索结果缓存）要失效，避免返回旧知识。实现上把"文档生命周期"管理起来：上传→索引→检索→更新→过期→删除，配合版本号与事件驱动，保证检索到的始终是最新且合法的知识。工程上常结合"增量 + 全量定期重建"双轨，平衡实时性与一致性。

知识库是"活"的，索引生命周期管理决定检索结果的时效与正确性。增量控制成本、墓碑防复活、版本保回滚、缓存失效保新鲜，四者配合才能让"知识更新"不产生"旧数据残留"或"新数据缺失"。

• 分块策略
• 嵌入模型选择
• 重排的协同

检索质量由三环协同：分块——决定检索的最小单元，块太大则语义混杂、召回不精准，块太小则上下文不足、容易丢失关键信息，需按文档类型与粒度选择（如固定大小 + 重叠、语义分块、父子分块），并考虑块内是否包含标题/元数据进行上下文增强；嵌入——选择与语料/语言匹配的嵌入模型，维度与量化影响召回质量与存储成本，需用真实语料评测；重排——用 Reranker 对召回候选精排，弥补嵌入召回"近似但不准"的问题。三环协同的关键是"分块适配嵌入、嵌入召回 + 重排精排"：分块决定召回上限，嵌入决定召回质量，重排决定最终排序精度。工程上应把三者放入同一评测集上联合调优，而非各自孤立优化。

检索质量是"分块-嵌入-重排"的接力。分块定上限、嵌入拉质量、重排提精度，任何一个环节短板都会拖累整体。联合评测调优才能让三者协同，避免"重排很强但分块太差"的失衡。

• relevance grading 自评
• 检索不足的纠正路径
• 引用生成

Self-RAG/CRAG 引入"检索质量评估"闭环节：模型或判别器对检索结果做相关性评分（relevance grading），判断检索是否充分。若检索充分，则基于检索结果生成并附引用；若检索不足，走纠正路径：重写查询再检索、扩大检索范围、尝试其他检索源，或明确告知用户"缺乏依据"并拒答/转人工，避免幻觉。引用生成：让答案中的每个关键论断都关联到具体检索片段（chunk/文档），输出时带引用来源，供用户核验。这样既提升忠实度，又通过"无依据则拒答"控制幻觉。工程上把相关性评分、纠正策略与引用渲染做成可配置流程，并纳入评测（引用命中率、无答案率）。

CRAG 把"检索可能失败"当作常态来设计。通过自评质量、纠正检索错误、无依据即拒答，形成"检索→评估→纠错→生成→引用"的闭环，从机制上抑制幻觉，而非仅靠模型自觉。

• 多模态文档处理
• 视觉检索模型
• 与文本检索的边界

多模态 RAG 要处理含表格、图表、图片的文档。传统做法是 OCR/版面解析把内容转成文本再入文本检索，但对复杂图表、手写、扫描件效果差。ColPali/ColQwen 等视觉检索模型直接以页面图像做嵌入，实现"视觉检索"，能捕获视觉布局与图表语义，避免 OCR 信息损失。工程边界：视觉检索适合"视觉信息密集"的文档（图表、扫描件、复杂版面、公式），文本检索适合"文字为主"的文档；两者可并行：对图文混合文档，用视觉检索定位页面，再用文本检索/解析提取细节，最后用多模态模型生成。取舍是：视觉检索对多模态模型与算力要求高、成本高，文本检索成熟便宜；应按文档类型与检索需求路由，而非一律视觉化。

多模态 RAG 的边界是"按内容类型选检索方式"。视觉检索补文本检索之短（图表、扫描、版面），文本检索补视觉之快（纯文字）。并行混合 + 按文档路由，能在成本与召回之间取得平衡。

• 文档级 ACL
• 租户隔离
• 检索过滤与脱敏

企业级 RAG 必须防止越权访问。落地要点：文档级 ACL——每份文档标注访问权限（如按用户/角色/部门），检索时结合当前用户权限做过滤，只让有权文档进入候选，防止"检索到但无权看"；租户隔离——多租户场景下按租户分区索引与检索，确保租户间数据不可见；检索过滤——在向量检索/过滤阶段就用权限条件（metadata filter）把无权文档排除，而不只在生成后过滤；内容脱敏——对返回内容做敏感字段脱敏（PII、密钥），并记录访问日志供审计。关键原则是"权限在检索前就生效"（Permission-aware RAG），而非"生成后再检查"，否则会导致信息泄露。实现上把权限条件随查询注入检索，并做端到端校验。

企业 RAG 的安全核心是"权限前置"。文档级 ACL、租户隔离、检索过滤构成"数据能见度"的边界，脱敏与审计构成"事后"防线。权限在检索前生效，才能避免"检索到无权内容"的泄露风险。

• 增量索引
• 知识过期
• 删除墓碑

知识与治理手段：增量索引——只对新增/变更文档做向量化与入库，避免全量重建；知识过期——为文档设定有效期与版本，过期后从检索中排除或标记降权；删除墓碑——删除文档时写入墓碑记录（tombstone），防止被重新召回或残留索引，同时保证"删除即生效"（不要在缓存或旧索引里还能查到）。治理要点：统一文档生命周期（上传→索引→更新→过期→删除），用版本号+事件驱动保证一致性；对增量与全量定期重建做双轨，定期清理孤儿向量与陈旧缓存；删除操作要穿透到所有索引副本与缓存。这样知识库"活着"且不残留过期/已删数据。

知识更新治理的核心是"删除和过期要可靠生效"。增量控成本、墓碑防复活、过期保时效，三者配合才能让检索结果始终反映"当前有权可见的最新知识"，避免法律/合规上的"已删数据仍被检索到"。

• 检索与生成指标
• 端到端评分
• 异常归因

检索指标（Recall@k、MRR、NDCG）衡量"候选是否含答案"，生成指标（忠实度、正确性、无幻觉率）衡量"答案是否好且忠于检索"。端到端评分应把两者联合：定义"端到端正确 = 检索命中 + 生成正确"（如"答案正确且引用真实"），并区分失败阶段——是检索失败（召回不足）还是生成失败（召回够但生成错）。通过"golden 检索/生成联合评测集"计算端到端准确率，并记录每例的失败原因。异常归因：用"检索命中率 vs 生成忠实度"的交叉分析定位瓶颈——检索命中率低说明分块/嵌入/召回有问题，已命中但生成差说明生成/提示词/重排有问题，从而把异常归因到具体环节，避免盲目调优。

RAG 是"检索+生成"接力，任何一环失败都会拖累端到端。联合评测把"检索失败"与"生成失败"分开看，才能精准归因。归因是优化的前提，否则会把"检索问题"误当成"生成问题"去调。

• 索引规模增长
• 检索延迟
• 向量存储成本

随数据量增长，RAG 成本体现在：向量化与索引构建成本（嵌入 API/算力）、向量存储成本（维度×数量×精度）、检索延迟（在大库上 ANN 检索耗时/召回质量下降）。优化手段：存储——用量化（如 int8/二进制）降低向量体积，用 HNSW/IVF 等 ANN 索引减少存储与检索开销，只存必要维度；检索延迟——用分层检索（先粗筛再精排）、预过滤、缓存热门查询结果；索引——按频次/热度分层，冷数据降级或压缩；成本——混合检索中复用缓存、对大库用分片与并行。工程上要权衡"召回质量 vs 延迟 vs 存储成本"，数据量越大，越需要量化、索引与分层的综合优化。

RAG 成本随数据量非线性增长，是高可用架构的隐性天花板。优化本质是"在召回质量可接受的前提下，用量化、索引、分层、缓存把存储与延迟压下来"，并随数据增长持续评估容量与成本。

• 多步检索
• 工具调用
• 与普通 RAG 的区别

Agentic RAG 把检索集成到 Agent 的决策循环中：模型可自主决定"检索什么、要不要多次检索、是否调用其他工具（如计算器、数据库、API）"。多步检索指"先检索初步信息，再据此细化查询继续检索，直到信息足够"；工具调用指"检索之外还能调用 SQL、计算、第三方 API 等工具获取更实的数据"。与普通 RAG 的区别：普通 RAG 是"一次检索→拼答案"的固定流水线，Agentic RAG 是"模型按需决策检索与工具调用"的动态循环。Agentic RAG 能处理更复杂、多源、需要推理的问题，但引入决策不确定性（循环、误判）与更高成本。落地需加步数上限、工具校验与降级，并结合 HITL 对高风险操作。

Agentic RAG 的"Agent"二字是关键——它把检索从"被动执行"变成"主动决策"。多步检索与工具调用让系统能处理复杂查询，但灵活性上升伴随后不确定性上升，需用控制与兜底保障稳定性。

• RRF 与加权融合
• 参数调优
• 回归验证

混合检索融合稀疏（BM25/SPLADE）与稠密（向量）结果。RRF 无需调权重（按排名倒数求和），鲁棒；加权融合需对各路分数归一化后加权求和，权重（如稀疏:dense = 0.5:0.5）需调优。调优方法：在带有标准的评测集上，用网格搜索/贝叶斯优化扫描权重（或 RRF 的 k 值），以 Recall@k/MRR/NDCG 为目标选最优；用交叉验证防止过拟合。回归：每当分块、嵌入模型、Reranker 或语料变化时，重跑同一评测集，确保融合参数与检索质量不退化；把融合参数加入版本管理，与索引/嵌入版本绑定，支持回滚。要点是"调优要有标定集、回归要有固定基线"，避免参数被某次语料带偏。

融合参数是"两头拉"的旋钮，RRF 免调参适合作默认，加权融合适合精细化。调优与回归的关键是"固定评测集 + 版本化"，让权重选择有据可依、可回退，防止每次语料变化都凭感觉改参数。

• 反馈采集
• 反馈归因
• 回流优化

反馈闭环：先采集"无答案/低质量"信号（用户点踩、追问、放弃、采纳率低、日志中检出无依据回答），再归因到具体环节（是分块切得差、检索没召回、还是生成没用好上下文），最后回流优化对应环节。回流路径：无答案/召回不足 → 调整分块粒度（语义分块、父子分块）与检索策略（改写、多查询、重排）；答案不忠实 → 优化 Prompt（强调基于上下文、无依据拒答）与生成侧约束；检索到但答偏 → 改进 Reranker 与上下文组装。工程上把反馈样本沉淀成"难题集"，持续扩充评测集，形成"反馈→标注→归因→优化→回归"的闭环，让系统在真实问题上越用越准。

反馈闭环把"用户满意"作为最终目标，把问题归因到具体环节再针对性优化。它的价值是"数据驱动"——让每次失败都成为改进样本，并通过难题集固化成果，避免同类问题反复出现。