RAG 评估与生产工程

一条 Demo 能回答几个问题，并不等于知识库可以上线。生产 RAG 还要处理评测基线、文档变化、删除传播、权限隔离、模型迁移、成本预算，以及表格、数据库、代码和图片等非纯文本数据。

文章	重点
RAG 评估与错误归因	检索、排序、上下文、答案、引用、安全、成本和延迟的分层评估
企业级 RAG 工程	增量索引、CDC、版本、ACL、多租户、缓存、迁移、可观测性与容量规划
企业级 RAG 如何降低首 Token 延迟	从检索关键路径、上下文长度、Prompt/KV Cache、模型服务和流式传输优化 TTFT
结构化与多模态 RAG	Table RAG、Text-to-SQL、Code RAG、PDF、图像、音视频和实时检索

工程部分的核心方法是把“答案错了”拆开：原始数据是否正确、索引是否新鲜、权限是否生效、正确证据是否被召回、排序是否合理、模型是否忠实使用证据。每一层都应有自己的日志、指标和回归样例。

学习清单

下面按文章分组列出问题和详细参考答案。完成每组后，建议用自己的业务数据再跑一遍，确认不仅会背概念，也能定位失败原因。

RAG 评估：指标、数据集与回归体系

• 为什么 RAG 评估必须分层，不能只看最终答案？

  • 参考答案：最终错误可能来自解析、分块、查询、过滤、召回、排序、上下文压缩、生成、引用或权限。单个答案分数只能说明结果失败，不能指导修复。分层评估保存每个中间产物，从最早出现错误的环节归因；例如正确证据不在 top-20 应查召回，已在 top-20 却没进 context 应查 rerank 或预算，context 充分但 claim 无支持则查生成与校验。

• Precision@K、Recall@K 和 Hit Rate@K 分别适合回答什么问题？

  • 参考答案：Precision@K 看前 K 个结果的噪声比例；Recall@K 看全部相关证据被找回多少；Hit Rate@K 只看每个问题是否至少命中一条，再对问题求平均。单事实 FAQ 常看 Hit Rate 与 MRR，多证据综合更看 Recall，有限上下文还要关注 Precision。Hit Rate 高不代表多个必要证据都齐全。

• MRR、MAP、nDCG 的差异是什么？

  • 参考答案：MRR 只看第一个相关结果的倒数排名，适合首个正确结果最重要的任务；MAP 在每个相关结果出现的位置计算 Precision 并平均，关心多条二元相关证据整体是否靠前；nDCG 支持分级相关性，用对数折损排名并除以理想 DCG，适合“关键条款、辅助背景、弱相关资料”价值不同的排序。选指标要匹配任务，不能只挑分数最好看的一个。

• 为什么 faithfulness 高，答案仍可能是错的？

  • 参考答案：faithfulness 只判断回答能否由给定上下文支持。如果知识库中的文档已过期、来源不权威或适用地区错误，模型忠实复述也会得到高忠实度，但与当前真实规则不符。Correctness 需要对照有效真值；因此还要评估版本、时效、权威和适用范围。

• Golden dataset 为什么要包含 hard negatives、无答案和冲突样例？

  • 参考答案：随机无关负例太容易，无法检验系统能否区分同主题不同版本、关键词相同但结论相反的资料；无答案样例检验系统是否会拒答而非编造；冲突样例检验是否按时间、范围、版本和权威裁决。三类样例更接近企业知识库真正昂贵的错误，也能揭示平均准确率掩盖的风险。

• RAGAS、TruLens 和 DeepEval 应如何选？

  • 参考答案：RAGAS 适合围绕 RAG 数据集快速使用 Context Precision/Recall、Faithfulness 等指标；TruLens 强调 tracing 与 Context Relevance、Groundedness、Answer Relevance 三角关系；DeepEval 适合把端到端和组件指标组织成带阈值的测试并接 CI。选择取决于已有观测栈和评估工作流，业务的权限、版本、关键 claim 等确定性门禁仍要自行实现。

• LLM-as-Judge 有哪些偏差，怎样降低风险？

  • 参考答案：常见有位置、长度、自我偏好、措辞敏感、领域不足、评分宽严漂移和提示注入。应先使用确定性规则，按 claim 给清晰 rubric 与例子，固定 Judge 版本和参数，成对比较时交换顺序，用人工标注集校准并观察混淆矩阵，对高风险或不稳定样例人工复核。多 Judge 投票只能降低部分方差，不能保证事实正确。

• 怎样设计 RAG 的回归门禁？

  • 参考答案：先设不可被平均分抵消的硬门禁，如越权上下文、关键金额错误、无答案编造、虚假引用和注入触发工具必须为零；再设 Recall、nDCG、Faithfulness、P95 和成本相对基线的统计门禁，并按业务切片检查；对 Judge 不稳定或高风险样例保留人工复核。门禁必须固定数据与系统版本，并考虑小样本波动。

• Ablation 实验应怎样做才有解释力？

  • 参考答案：固定知识库快照、评估集、模型和其他配置，一次只移除或改变一个组件，例如只去掉 BM25、reranker 或压缩，比较分层质量、切片、延迟和成本。若同时换 embedding、chunk 与 prompt，即使指标上升也无法归因。结论要指出哪些题型获益、哪些退化，以及收益是否值得额外复杂度。

• 如何从“答案错了”逐层定位根因？

  • 参考答案：先确认原始知识是否存在答案，再查解析后的 chunk 是否完整；然后检查正确 evidence 是否进入召回 top-k、是否经 rerank 与预算进入最终 context；接着检查 context 是否充分、有效且无冲突；最后检查答案 claim 是否受支持、引用是否正确、权限是否通过。如果所有链路都正确，再审查 golden 标签、Judge 或需求定义。

• RAG 的成本与延迟应该怎样纳入评估？

  • 参考答案：成本按 query embedding、检索、rerank、路由或 Judge、生成和观测拆分，生成 token 要区分普通输入、缓存输入和输出，并使用供应商当期单价。延迟记录各阶段和端到端的 P50/P95/P99、TTFT、超时与降级率。比较方案时同时报告质量增益与每请求成本、尾延迟，不能用平均延迟或单一 token 数代表体验。

• 为什么权限评估要检查候选召回，而不只检查最终答案？

  • 参考答案：无权正文即使最终被删掉，也可能已进入向量库返回、reranker、缓存、日志或 Judge，形成泄露面。ACL 应在每个召回分支最早下推，并分别测 Unauthorized Retrieval、Context 和 Citation Rate。还要测试撤权后的缓存失效、跨租户同名文档和评估平台的数据留存；最终回答没有泄露不能证明链路安全。

企业级 RAG 工程

• 为什么企业 RAG 需要文档接入状态机，只有 processed=true 有什么问题？

  • 参考答案：接入包含校验、解析、标准化、分块、embedding、索引和验证等多个可失败阶段。单一布尔值无法说明失败位置、是否可重试、是否只写入了部分索引，也无法在进程重启后恢复。状态机应持久化当前阶段、attempt、错误码、版本和更新时间；只有 chunk 数量、维度、权限字段、索引读回等验证通过后才能进入 ACTIVE。更新、删除和人工隔离还需要 SUPERSEDED / DELETING / DELETED / QUARANTINED 等明确状态。

• CDC 为什么仍然要求消费者实现幂等？应该怎样设计幂等键？

  • 参考答案：CDC 和消息队列通常是至少一次投递，消费者崩溃可能发生“写索引成功但确认消息失败”，重启后同一事件会再次到达；某些数据库逻辑解码在崩溃恢复后也可能重发近期变更。幂等键应稳定包含租户、源系统、源对象、源版本和处理流水线版本，并由数据库唯一约束兜底。chunk id 要确定性生成，索引用 upsert，删除可重复执行；激活版本时使用 compare-and-set，避免晚完成的旧事件覆盖新版本。

• 内容哈希、源版本号和 pipeline version 各解决什么问题？

  • 参考答案：内容哈希判断标准化内容是否真正变化，可跳过无意义更新时间和复用未变化 chunk 的 embedding；源版本号表达业务发布与审计顺序，即使两次发布字节相同也可能是不同版本；pipeline version 标识解析器、分块器、上下文模板和 embedding 配置，规则变化时即使原文没变也可能必须重建。三者不能互相替代，应共同进入血缘、幂等或缓存键。

• 文档更新时，为什么推荐“构建新版本后原子切换”，而不是原地覆盖？

  • 参考答案：原地覆盖会让在线请求在构建期间读到半新半旧的 chunk，失败后也缺少完整回滚点。更稳妥的做法是给新版本生成独立 canonical artifact、chunk 和索引记录，校验完整性后原子切换 current pointer，旧版本标记 SUPERSEDED 并在观察期后回收。查询可绑定一个 knowledge snapshot，保证一次请求内版本一致。回滚时旧索引还必须包含灰度期间的更新。

• “先全库召回，再过滤无权文档”为什么不安全？ACL 前置过滤又有什么性能问题？

  • 参考答案：后置过滤意味着无权内容已经进入检索候选、reranker、模型上下文或日志，标题、分数甚至正文都可能泄露。安全过滤必须由服务端根据认证身份生成，在检索阶段限制 tenant、文档和 ACL 范围，不能信任模型传参。性能上，一些 ANN 实现可能先近邻搜索后应用过滤，在可见数据比例很低时返回空结果或召回下降，因此要核验 pre-filter 语义，用低选择率权限场景压测，并考虑按租户分区、增加搜索深度或采用过滤感知索引。

• Embedding cache、query cache、retrieval cache 和 answer cache 的失效条件有何不同？

  • 参考答案：Embedding cache 依赖规范文本、模型版本、维度、归一化和任务类型，正文或模型变化才需失效；query cache 还依赖租户、语言、改写器和会话语境；retrieval cache 必须绑定权限范围、过滤条件、索引快照、retriever 版本和 top_k；answer cache 还依赖证据指纹、prompt、生成模型和安全策略。ACL 收回、文档过期或删除时，retrieval/answer cache 必须主动失效或在线复核，TTL 不能保证立即撤权。

• 不停服升级 embedding 模型的完整步骤是什么？怎样保证可以回滚？

  • 参考答案：创建与旧空间隔离的新索引；迁移期间新数据双写；历史数据按 checkpoint 回填；校验文档、chunk、ACL、维度和删除记录完整；用固定评测集比较质量、延迟、成本，再做影子读和稳定分桶灰度；逐步扩大流量后让新索引主用。观察期保留旧索引，而且旧索引应继续双写或能从事件日志追平。否则配置切回虽成功，旧索引的数据已经落后，不是真正回滚。

• 一条 RAG trace 至少应该记录哪些信息，又有哪些内容不应默认记录？

  • 参考答案：trace 应覆盖鉴权、改写、query embedding、dense/sparse 检索、融合、重排、上下文构建、生成和引用验证；记录各阶段时延、候选数、过滤数、缓存命中、token、成本估算、索引快照及各模型/提示词版本。用户原问题、完整证据、prompt 和答案可能含个人或商业敏感信息，不应默认写入普通 trace，可保存哈希、长度、类别和受控采样，把必要原文放入权限和保留期更严格的审计存储。

• 如何估算 500 万条、1024 维、float32 向量的最低原始容量？为什么这个数字不能直接用于采购？

  • 参考答案：最低原始容量是 5,000,000 × 1,024 × 4 = 20,480,000,000 字节，约 20.48 GB（十进制）。它只包含裸向量，不含 HNSW/IVF 等索引、原文、metadata、数据库内部开销、WAL、临时构建空间、副本和备份。不同引擎与参数的索引放大率差异很大，采购前必须用代表性数据实测，并加入峰值增长、重建期间双索引和容灾副本。

• 备份向量数据库为什么仍可能无法正确恢复 RAG？

  • 参考答案：向量索引只是派生物。若缺少原始文档、版本与 ACL、解析/分块/embedding 配置、接入状态和 CDC checkpoint，即使向量文件恢复成功，也无法判断是否漏更新、包含已删除内容或与 metadata 处于同一水位。恢复演练应从一致的事实源和血缘恢复或重建索引，重放 checkpoint 之后的增量，再校验文档数、chunk 数、tombstone、ACL，并运行质量和越权测试后接流量。

• 线上仍回答旧政策时，应按什么顺序排查？

  • 参考答案：先确认事实源的版本和有效期，再查变更事件是否产生、CDC 是否积压、接入作业是否完成、索引记录是否完整、current pointer 是否已切到新快照；随后查看在线 trace 中实际命中的 chunk/version，最后检查 retrieval cache 和 answer cache 是否失效。若进入模型的证据本身就是旧的，优先修数据与缓存链路，而不是先调 prompt。

企业级 RAG 如何降低首 Token 延迟

• TTFT 和 TTFB 有什么区别？

  • 参考答案：TTFB 是客户端收到第一个响应字节的时间，可能只是状态事件或网关响应；TTFT 是收到模型第一个输出 Token 的时间。RAG 还应关注首个有效内容时间和完整答案时间，否则可能把“提前显示正在查询”误认为真正降低了模型回答延迟。

• 为什么 RAG 的上下文长度会影响首 Token 时间？

  • 参考答案：模型在生成首 Token 前需要先处理输入上下文，也就是 Prefill。最终 Prompt 越长，通常需要处理的输入 Token 越多，Prefill 计算、显存占用和数据传输成本也越高。因此应先召回和重排，再去重、压缩并只保留支持当前问题的证据。压缩不能删除必要的条件、例外和版本信息。

• 如何降低 Query Rewrite 对 TTFT 的影响？

  • 参考答案：不要让所有请求都调用大模型改写。可以让简单问题直接检索，多轮指代使用轻量 standalone rewrite，复杂比较题才使用问题分解或 Multi-Query；必要时让原始查询先开始检索，改写结果回来后再融合。要同时限制并发、超时和额外调用次数。

• 为什么 Dense、BM25 和结构化检索适合并行？

  • 参考答案：如果这些分支相互独立，串行执行会把耗时相加，并行执行的关键路径更接近最慢分支的耗时加融合时间。并行会增加资源消耗，因此需要设置超时、取消慢分支、限制候选数量。ACL 必须在每个检索分支中尽早执行，不能为了性能后置过滤。

• Prompt Cache 能不能直接让模型输出更快？

  • 参考答案：Prompt Cache 主要复用稳定 Prompt 前缀的处理结果，减少输入处理和 Prefill，通常可以改善长上下文场景下的 TTFT；它不会直接加快输出 Token 的 Decode 阶段。命中一般要求缓存前缀精确一致，动态问题和动态证据应放在缓存前缀之后。

• Prompt Cache 和 Answer Cache 有什么区别？

  • 参考答案：Prompt Cache 复用模型处理稳定输入前缀的计算结果，仍然会根据本次问题生成答案；Answer Cache 直接复用最终回答。Answer Cache 更容易遇到答案过期、权限变化、证据变化和问题约束不一致的问题。企业高风险问答通常优先缓存 embedding、检索结果或 Prompt 前缀，而不是直接缓存答案。

• 如何判断是检索慢还是模型慢？

  • 参考答案：为鉴权、路由、改写、embedding、dense、sparse、fusion、rerank、context build、模型队列、Prefill 和首 Token 分别记录 span 和耗时，再比较 P50、P95、P99。检索结束后等待时间很长，通常应查模型队列或网络；Prompt 较短但 Prefill 很慢，应查模型实例和调度；某个检索分支的尾延迟明显，则应查分片、过滤和连接池。

• 为什么不能只把 top-k 调小来降低 TTFT？

  • 参考答案：top-k 过小会导致正确证据无法进入候选集，降低 Recall；top-k 过大则增加 Rerank、上下文组装和 Prefill 成本。应把候选召回数量和最终上下文数量分开调节，并按 FAQ、精确编号、多跳和高风险问题分别评估质量、延迟和成本。

• 低延迟降级时哪些步骤不能跳过？

  • 参考答案：不能跳过租户和 ACL 过滤、删除和撤权检查、版本边界、真实来源引用约束以及高风险问题所需的证据验证。可以考虑跳过非必要 Rewrite、减少 Multi-Query、普通问题不做 Rerank 或使用更小模型，但必须有问题类型和风险等级控制，不能全局粗暴降级。

• 如何证明一次 TTFT 优化是有效的？

  • 参考答案：冻结同一份评测集和系统版本，逐项做消融实验，比较 TTFT 的 P50/P95/P99、完整答案延迟、Recall、答案忠实度、引用准确率、权限错误率、成本和缓存陈旧命中数。只有延迟下降且质量、安全门禁仍满足，才能认为优化有效。

最后记住

先测量关键路径
  -> 简单问题走短路径
  -> 检索分支并行
  -> 减少最终上下文
  -> 复用稳定 Prompt / KV Cache
  -> 处理模型排队和网络
  -> 用质量、安全、成本共同验收

企业级 RAG 的低延迟不是牺牲权限和证据质量换来的“快”，而是在不突破安全和质量门禁的前提下，减少不必要的工作、缩短关键路径，并复用已经做过的计算。

结构化与多模态 RAG

• 为什么不能把表格、代码、PDF 和音视频全部转成普通文本后使用同一套向量检索？

  • 参考答案：普通文本会丢失回答所需的结构。表格需要表头、类型、单位和行列关系；代码需要 AST、符号、调用图和 commit；PDF 需要阅读顺序、页面区域和坐标；音视频需要说话人、画面和时间轴。向量检索可以负责语义召回，但聚合计算、精确定位和关系遍历应交给对应结构化索引或工具。系统可以统一查询入口和 Evidence 协议，不应强行统一底层表示。

• 一条统一 Evidence 记录至少应包含哪些字段？为什么 content + score 不够？

  • 参考答案：至少包含稳定 evidence id、modality、可读内容、模态特有 structured payload、来源 URI、版本、精确 locator、有效/观察时间、租户与授权决策、抽取器或查询 provenance，以及检索分数。只有 content 和 score 无法回到表格行列、代码 commit、PDF bbox 或媒体时间片，也无法判断数据是否过期、用户是否有权、解析器是否低置信，因而不能支撑引用、审计、删除传播和评估。

• Table RAG 与 Text-to-SQL 的边界是什么？什么问题需要两者组合？

  • 参考答案：Table RAG 常处理文件或已抽取表格，通过表级摘要、行文本和结构化记录完成找表、找行列与小范围查询；Text-to-SQL 面向可查询数据库，适合过滤、join、聚合、排序和实时数值。问“退款表每列是什么意思”偏 Table/schema RAG，问“上月各区域退款总额排名”偏 SQL。若用户问“按制度定义计算本月退款率”，应先从文本/表格知识中取指标口径，再由受限 SQL 查询分子分母并用确定性代码计算。

• 生产 Text-to-SQL 为什么不能仅靠 prompt 要求“只生成 SELECT”？

  • 参考答案：模型输出不具备安全保证，可能生成写操作、危险函数、全表扫描、越权表列或缺少租户谓词。生产链路应使用只读账号和副本，解析目标方言 SQL AST，限制语句、表、列和函数，由服务端注入行级安全，参数化用户值，并设置扫描成本、超时、返回行数和并发门槛。prompt 只是提高生成成功率，数据库权限和验证器才是最终边界。

• Code RAG 应怎样切块和扩展上下文，为什么固定 token 切分通常不够？

  • 参考答案：应使用语言解析器按函数、类、接口、方法、配置和测试等 AST/符号边界建检索单元，并保存全名、路径、起止行、commit、imports 和调用关系。固定 token 可能拆开签名与实现或混合多个符号。在线先用小符号精确召回，再按问题扩展所属类、必要 imports、调用方/被调用方和相关测试，形成 small-to-big 上下文；扩展受 token 预算约束，引用必须绑定 commit 和行号。

• Layout-aware PDF RAG 相比普通 PDF 文本抽取多做了什么？

  • 参考答案：它区分数字 PDF、扫描 PDF 和混合页，结合文本对象与 OCR，检测标题、段落、列表、表格、图、页眉页脚，恢复双栏等阅读顺序，并保存页码、bbox、block type、旋转和 OCR 置信度。检索可同时使用区域文本、关键词、页面或区域视觉向量；命中图表或低置信 OCR 时再查看原页面裁剪。引用不仅给文件名和页码，还能高亮准确区域。

• 视觉 RAG 为什么不能只检索自动生成的 caption？

  • 参考答案：caption 是有损且可能幻觉的文本摘要，常遗漏小字、版本号、按钮状态、图例单位和局部缺陷。合理方案并行保存整图/区域 embedding、OCR、caption、对象检测与原始资产；caption 用于粗召回，命中后由视觉模型查看原图或相关 bbox，并返回资产版本和区域引用。评测要加入外观近似但局部事实不同的 hard negative。

• 音视频 RAG 如何回答“谁在什么时候说了什么，同时屏幕显示了什么”？

  • 参考答案：建立统一时间轴：音轨经过 ASR、词句时间戳和说话人分离；视频经过镜头切分、关键帧、屏幕 OCR 和视觉描述；每个 segment 保存开始结束时间、speaker、转写、关键帧和置信度。检索时组合文本、关键词、视觉和时间过滤，命中后扩展相邻窗口处理指代。回答引用媒体版本与时间范围，并区分说话人的观点和已验证事实。

• Temporal RAG 中 event time、valid time 与 ingestion/system time 有什么区别？

  • 参考答案：event time 是事件实际发生时间；valid time 是规则或事实在业务世界成立的区间；ingestion/system time 是系统何时收到并知道它。追溯生效的政策可能发布于 9 月、从 8 月起有效、9 月 2 日才被知识库接入。问历史业务规则要按 valid time，问系统在当时掌握什么要按 system time。迟到事件不能按到达顺序覆盖新状态，应使用业务版本、序列或有效区间。

• Web/real-time RAG 为什么不能直接把搜索摘要当最终证据？

  • 参考答案：搜索摘要可能被截断、过期、脱离上下文，甚至与当前页面不一致。系统应把搜索结果当候选，读取原页面或官方 API，检查域名、发布时间、抓取时间和正文，抽取可引用片段；高风险事实需要多源或权威源验证。价格、库存和服务状态等快速变化信息优先调用结构化 API，并在答案展示 observed_at。网页内容还可能包含间接提示词注入，必须作为不可信数据处理。

• 多个检索器的分数为什么不能直接加权相加？可以怎样融合？

  • 参考答案：cosine、BM25、OCR 置信度、视觉相似度和 SQL 精确结果的量纲与语义不同，0.5 × scoreA + 0.5 × scoreB 通常没有可解释性。可先在各路内部排序和过滤，再用 RRF 等基于名次的方法合并，之后用 query-evidence reranker，并加入来源权威性、时间和业务规则。SQL 精确结果的口径正确性仍需 schema 与验证器保障，不能靠融合分数决定真假。

• 怎样评估一个结构化与多模态 RAG，而不是只看最终答案？

  • 参考答案：分层评估抽取、路由、召回、工具执行、生成、引用和安全。抽取测 OCR/ASR/表结构/AST/时间戳；路由测正确目标和多路完整性；召回测表列、代码符号、页面区域和时间片；执行测 SQL 与计算结果、成本和限制；生成测事实忠实、单位、版本和拒答；引用测 claim 是否被精确 locator 支持；安全测行列、仓库、媒体派生物和缓存是否越权。所有动态数据评测都要绑定 commit、数据库快照或抓取时刻。