外观
RAG 评测与生产工程：多模态、全链路监控与故障定位
面试结论｜ RAG 监控不能只看“接口成功率”和最终答案，它必须把一次请求拆成 Query、权限/元数据过滤、Sparse/Dense 候选、融合、精排、上下文、生成与引用，并绑定语料、索引、Embedding、Reranker、Prompt 和模型版本。多模态 RAG 还要额外监控解析、OCR/ASR、图文对齐、模态路由和跨模态证据引用，否则“检索成功”可能只是找到了错误页面或错误时间片。
目录
- 1. 小白先这样理解
- 2. 多模态 RAG 是什么
- 3. 多模态数据、索引与检索策略
- 4. 一次请求要记录什么
- 5. 指标体系：从数据到答案
- 6. 告警、看板与 SLO
- 7. 版本区分、灰度与回滚
- 8. 故障演练与排查顺序
- 9. 技术点清单与横向选型
- 10. 架构与技术调用流程
- 11. 最小 Trace Schema 与查询样例
- 12. 面试追问与总结
1. 小白先这样理解
小白先这样理解：调查一次地铁故障
地铁站报告“闸机无法识别二维码”。调查员手里有文字维修手册、闸机照片、现场录音、监控视频和设备日志。只搜文字，他可能错过照片里闪烁的红灯；只看图像，他又不知道错误码 E-17 的官方处置步骤；视频中真正异常只发生在 02:13～02:19，若整段视频压成一个向量，关键动作会被稀释。
调查员先把每种证据整理成带时间、设备、站点、版本和权限的卡片；文字按章节切，图片关联所在页与图注，音频转写并保留时间戳，视频按镜头/事件切片。接到问题后，系统按设备与时间硬过滤，分别搜索文字、图片和音视频片段，再把候选对齐到同一事件，最后输出“结论 + 引用页码 + 图片区域 + 视频时间段”。
| 生活元素 | 技术对象 | 监控重点 |
|---|---|---|
| 维修手册、照片、录音、视频、日志 | 文本/图像/音频/视频/结构化数据 | 各模态解析成功率与质量 |
| 页码、图片区域、时间段 | Provenance/定位信息 | 引用能否回到原证据 |
| 设备、站点、时间、权限 | Metadata 与硬过滤 | 过滤前后候选数、越权测试 |
| 分别找证据再汇总 | 多路检索与融合 | 每路 Recall、分数/名次和降级 |
| 对齐同一事件 | 跨模态关联/父子实体 | 图文或音视频是否错配 |
类比边界： 人能看出照片和日志是否来自同一台设备，系统只有在元数据、时间戳和关联 ID 正确时才能对齐；多模态模型也可能把视觉相似误当作事实相同。
2. 多模态 RAG 是什么
多模态 RAG（Multimodal RAG）把文本之外的图像、表格、音频、视频或结构化数据纳入检索证据，并让生成模型基于这些证据回答。它不是简单地“把图片 OCR 成文字”：
- OCR 擅长读取图片中的字，却可能丢失布局、图形关系和视觉状态；
- 图像 Embedding 能捕捉视觉语义，却不保证精确读出小字、数字或表格；
- 音频 ASR 能生成文本，但语气、说话人和非语音事件可能丢失；
- 视频同时包含画面、语音、动作和时间结构，必须保留时间片与关键帧；
- 结构化数据库查询提供精确当前状态，不能用相似度搜索代替确定性 SQL/API。
2.1 三种常见路线
| 路线 | 做法 | 优点 | 边界 |
|---|---|---|---|
| 全部转文本 | OCR/ASR/Caption 后走文本 RAG | 架构简单、易复用 BM25/Dense | 视觉布局、细节和动作可能丢失 |
| 各模态独立向量 | text/image/audio/video 分别编码与检索 | 保留模态特征，可按问题路由 | 分数不可直接比较，存储与评测更复杂 |
| 统一多模态空间 | Query 与多模态证据映射到共享空间 | 支持文字搜图、图搜文 | 依赖模型训练域，精确事实仍需原证据核验 |
生产常采用组合路线：OCR/ASR 用于精确词和引用，模态向量用于语义召回，Metadata/关系 ID 用于对齐，Multimodal LLM 用于有限候选理解。
3. 多模态数据、索引与检索策略
3.1 统一证据对象
每个证据单元不论模态，都应有稳定身份与来源定位：
json
{
"evidence_id": "manual-77#page-12#figure-3",
"parent_id": "manual-77#page-12",
"modality": "image",
"content_uri": "object://...",
"text_surrogate": "闸机控制板红灯闪烁，标签 E-17",
"region": {"page": 12, "x": 0.41, "y": 0.18, "w": 0.36, "h": 0.27},
"time_range_ms": null,
"tenant_id": "metro-a",
"device_model": "gate-pro-7",
"source_version": "2026.4",
"extractor_version": "vision-parser-2",
"vector_versions": {"image": "example-image-embed", "text": "example-text-embed"}
}模型名是占位示例。真正实现要保存精确模型 ID、维度、预处理方式与索引版本。
3.2 文本、图像、音频、视频如何切
| 模态 | 切片单元 | 不能丢的定位 | 常见失败 |
|---|---|---|---|
| 文本 | 标题/段落/句窗/父子 Chunk | 文档、章节、页码 | 条件与结论分离 |
| 表格 | 表头 + 行/列组 + 周边说明 | 页码、表格 ID、行列 | 表头脱离数据、跨页错列 |
| 图像 | 整图 + 区域/对象 + Caption/OCR | 页面、坐标、图注 | 小字误读、相似图错配 |
| 音频 | 语义段/说话轮次 | 起止时间、说话人 | ASR 专名和数字错误 |
| 视频 | 镜头/事件/固定上限片段 | 起止时间、关键帧、音轨 | 关键动作被长片段稀释 |
| 结构化数据 | SQL/API 结果快照 | 查询、主键、时间点 | 把过期快照当实时真值 |
3.3 多路召回与融合
一次问题可先分类路由：
- “图中红灯代表什么？”应提高图像/图文候选深度；
- “录音里 02:13 说了什么？”应先用时间和音频 ID 硬过滤；
- “E-17 官方步骤”应让精确词/BM25 拥有强信号；
- “这个画面和哪类故障相似？”可使用图像 Dense；
- “当前设备是否在线？”应调用实时 API/SQL，而不是从历史向量证据猜。
融合时要保留每路 retriever、rank、raw_score、normalized_score、模型版本和过滤理由。图像余弦与 BM25 分数不可直接相加，优先用 RRF，或在分模态标注集上做校准与学习排序。
3.4 多模态 Cross-Encoder/LLM 精排
有限候选可让多模态模型联合读取 Query、图片、Caption、OCR 和上下文，判断证据是否真正相关。但需要监控：
- 图片是否下载/解码成功，分辨率是否被过度缩放；
- 输入是否超过图像数、帧数或 Token 限制而被截断；
- OCR/ASR 与原媒体是否冲突；
- 精排模型是否支持当前语言、模态和区域；
- 模型版本变化是否使旧分数分布失效。
4. 一次请求要记录什么
4.1 Trace 的最小问题清单
一个 request_id 应能回答：
- 原始 Query、规范化 Query、改写 Query 分别是什么，改写规则/模型版本是什么；
- 用户、租户、ACL、产品、语言、地区、时间与版本过滤是什么；
- BM25、Dense、图像、音频等每路召回多少，过滤前后各多少；
- 每个候选的
evidence_id、父块、模态、原始分数、名次和索引版本是什么； - 融合、去重和精排后名次如何变化，候选为何被丢弃；
final_context选择了哪些证据，展开了哪些父块，截断了什么，共多少 Token/图像/帧；- 使用哪个 Prompt、生成模型、采样配置与安全策略；
- 最终答案引用哪些证据，引用是否真的支持相邻结论；
- 各阶段耗时、重试、缓存、超时、降级和错误码是什么。
4.2 不应直接记录什么
- 未脱敏的个人信息、密钥、完整身份证/订单敏感字段；
- 用户无权查看的候选正文，即使最终没返回；
- 可长期还原音视频原件的调试数据，除非有明确权限与保留策略；
- 没有采样与期限控制的全部 Prompt/Context 明文。
可采用字段脱敏、正文哈希/稳定 ID、受控抽样、加密、短保留期与审计访问。
5. 指标体系：从数据到答案
5.1 数据与索引指标
| 指标 | 定义/计算 | 解释 |
|---|---|---|
| ingestion_success_rate | 成功发布文档 / 尝试发布文档 | 不等于解析质量正确 |
| quarantine_rate | 隔离文档 / 接入文档 | 按来源、格式、解析器分桶 |
| metadata_missing_rate | 缺必填元数据 Chunk / 全部 Chunk | ACL/版本字段缺失应阻断发布 |
| index_freshness_lag | 源变更时间到可检索时间 | 区分 P50/P95/P99 |
| orphan_chunk_rate | 无有效父文档 Chunk / 全部 Chunk | 揭示删除/同步不一致 |
| multimodal_alignment_error_rate | 错页/错时间/错父实体样本 / 审核样本 | 需要人工标注抽检 |
5.2 检索指标
必须先有标注问题与相关证据集合：
还可按任务选择 MRR、nDCG、HitRate、空召回率和错误模态率。不要把所有指标堆在一起，而要明确：
- 粗排关注相关证据是否进入
k_recall； - 融合/精排关注重要证据是否进入前排；
- 上下文关注证据是否进入
final_context且没有被重复与截断挤掉； - 多模态要分 text-to-text、text-to-image、image-to-text、audio/video 等查询桶。
5.3 生成与引用指标
| 指标 | 要回答的问题 | 注意 |
|---|---|---|
| Correctness | 最终答案是否正确 | 需参考答案/人工标准 |
| Groundedness/Faithfulness | 答案是否由给定上下文支持 | 上下文本身可能错误 |
| Citation precision | 被引用证据是否支持对应陈述 | 不能只看链接存在 |
| Citation coverage | 需要证据的陈述有多少被引用支持 | 区分常识与外部事实 |
| Abstention quality | 无证据时是否正确拒答 | 同时报错拒答与应答率 |
| Modality attribution accuracy | 引用的页、区域、时间片是否正确 | 多模态特有 |
5.4 系统与成本指标
至少分阶段记录 P50/P95/P99：Query 处理、过滤、Sparse、Dense、融合、Reranker、媒体读取、生成和端到端延迟；同时记录超时率、重试率、降级率、缓存命中率、Embedding/精排/生成调用量、Token、图片数、视频帧数、GPU/CPU/内存和单请求成本。
5.5 指标分桶
全局平均值会掩盖问题，应至少按以下维度分桶：
text
tenant, product, language, region, query_type, modality,
source_type, ACL complexity, corpus/index version,
embedding/reranker/prompt/model version, cache/degraded status6. 告警、看板与 SLO
6.1 三层看板
- 业务质量看板： 问题完成率、人工转接、拒答、引用支持、用户纠错与任务成功；
- 检索质量看板： 空召回、各路候选数、正确证据排名、分数分布、重复率、精排增益；
- 系统健康看板： 阶段延迟、错误、超时、降级、索引新鲜度、资源和成本。
6.2 告警不要只设静态阈值
- 绝对阈值：越权事件必须为 0，索引新鲜度超过 SLO 告警；
- 同比/环比：某租户空召回率相对自身基线突增；
- 版本对照：候选版与控制版在同一 Query 上 Recall 或 P99 退化；
- 分布漂移：余弦相似度、Reranker 分数、Chunk 长度或 Query 类型分布显著变化；
- 对账：源文档数、可用 Chunk 数、索引记录数和删除墓碑不一致。
告警必须绑定 Runbook、责任人、影响范围和可执行止损。否则指标越多，真正故障时越难判断。
6.3 SLO 示例口径
下面是定义方法，不是推荐数值：
text
retrieval_availability
= 在时限内返回至少一个受权候选或明确合法空结果的请求数
/ 全部合法检索请求数
index_freshness_slo
= 在约定时间内完成可检索发布的有效变更数
/ 全部有效变更数合法空结果不应被算成系统失败；“接口 200 但候选来自错误版本”也不应算质量成功。
7. 版本区分、灰度与回滚
7.1 版本矩阵
每条 Trace 至少绑定：
text
corpus_version
parser_version
chunker_version
embedding_model_id + dimension + preprocessing
sparse_index_version + analyzer_version
vector_index_version + ANN params
fusion_config_version
reranker_model_version
context_policy_version
prompt_version
generator_model_version只记录 rag_version=v2 会让排障失去定位能力。
7.2 发布流程
- 固定评测集与关键越权/无答案样本；
- 新版本离线回放并与基线逐样本比较；
- 影子流量只计算不影响用户，观察质量、延迟和成本；
- 按租户、查询类型或流量比例灰度，保持控制组；
- 达到门禁后扩量，否则回退配置/索引别名；
- 保存失败样本，补入回归集与告警。
缓存键必须包含会改变结果的权限、语料、索引和检索配置版本。回滚模型但沿用新版缓存，会产生“代码回滚了、结果没回滚”的假象。
8. 故障演练与排查顺序
8.1 故障演练：只有图片类问题突然答错
现象： 文本问题正常，带“图中/截图/颜色/位置”的问题引用错页；接口成功率和总体 Recall 变化不明显。
影响范围： 多模态 Query，尤其是需要区域定位的图片证据。
定位证据： 按 query_type=image-grounded 分桶后，modality_attribution_accuracy 下降；图像候选 parent_id 与页面文本不一致，问题始于 vision-parser-3.1 发布。
根因假设与排除： 先检查图片下载/解码，再检查页面与区域映射、图像索引版本、模态路由、精排截断；若正确图片已进入 final_context，才转查多模态模型。
临时止损： 回滚图像解析/索引别名；无法保证定位时只返回文字证据或明确提示需要人工查看原页。
长期修复： 用稳定 page_id + region_id 建关联，发布前执行图文对齐样本门禁，并对解析器版本做影子对照。
回归与防复发： 固化图片区域、表格、跨页图注和错误页映射用例；告警按模态与解析器版本分桶。
证据边界｜ 这是生产风险演练，不是本仓库已发生事故，也没有真实提升数字。
8.2 通用排查顺序
text
固定 request_id、身份和版本
→ 原始/改写 Query
→ ACL/Metadata 过滤
→ 各模态候选数、分数和索引新鲜度
→ 融合与去重
→ Cross-Encoder/多模态精排
→ final_context、媒体数量和 Token/帧截断
→ Prompt/模型生成
→ 引用是否支持结论核心方法是找到正确证据第一次消失或第一次错配的阶段。
9. 技术点清单与横向选型
| 技术点 ID | 技术点/环节 | 类型 | 采用方案 | 链路职责 | 版本/证据边界 |
|---|---|---|---|---|---|
| TP-O01 | 多模态解析与对齐 | 数据管道/模型 | OCR/ASR/Caption + 原媒体定位 + 稳定关联 ID | 把媒体变为可检索且可引用证据 | 模型与格式需分桶验证 |
| TP-O02 | 多模态检索 | 检索/模型 | 文本代理 + 模态向量多路召回 | 覆盖精确词、语义和视觉/音频信号 | 分数需分路保存与校准 |
| TP-O03 | Trace | 可观测组件 | OpenTelemetry 风格 Span + 候选快照 Schema | 定位正确证据消失阶段 | 正文记录需隐私治理 |
| TP-O04 | 指标与评测 | 评测系统 | 离线固定集 + 在线分桶指标 + 人工抽检 | 质量、延迟、成本和安全门禁 | LLM Judge 不替代金标/人工 |
| TP-O05 | 发布治理 | 基础设施 | 版本矩阵 + 影子 + 灰度 + 别名回滚 | 控制变更风险 | 阈值由业务 SLO 定义 |
| 技术点 ID | 候选方案 | 优点 | 缺点/代价 | 适用场景 | 不适用场景 | 选择结论与依据 |
|---|---|---|---|---|---|---|
| TP-O01 | 全转文本 | 链路简单、BM25 友好 | 丢视觉/声音信息 | 文字主导扫描件 | 图表、动作、环境声 | 作为基线和补充 |
| TP-O01 | 原生多模态 + 文本代理 | 信息更完整、可交叉验证 | 存储、模型和评测复杂 | 图文、音视频证据 | 无多模态需求 | 高价值模态按需引入 |
| TP-O02 | 单一统一向量 | 接口简单 | 特定模态和精确词可能弱 | 模态相近、快速 PoC | 复杂企业检索 | 先做基线 |
| TP-O02 | 分模态检索 + 融合 | 可独立调优和降级 | 融合与权重复杂 | 多种查询类型 | 缺评测数据 | 生产更可诊断 |
| TP-O03 | 仅应用日志 | 接入快 | 缺跨阶段因果与候选快照 | 最小实验 | 生产排障 | 不足以闭环 |
| TP-O03 | Trace + 结构化候选事件 | 可重放、可按版本对照 | 存储与隐私成本 | 多阶段生产系统 | 无治理能力 | 采样与脱敏后采用 |
| TP-O04 | 仅 LLM-as-a-Judge | 扩展快 | 偏差、漂移、不可自证 | 辅助大规模评审 | 安全/关键事实唯一裁判 | 与金标和人工组合 |
| TP-O04 | 标注集 + 线上反馈 + 人工抽检 | 证据更稳健 | 建设和维护成本 | 生产发布门禁 | 一次性 Demo | 默认组合 |
| TP-O05 | 全量直接发布 | 快 | 爆炸半径大、难归因 | 可丢弃实验 | 生产 | 不推荐 |
| TP-O05 | 影子/灰度/回滚 | 风险可控、保留对照 | 双资源和运营成本 | 生产变更 | 无观测的系统 | 与版本矩阵一起使用 |
10. 架构与技术调用流程
图：架构｜多模态 RAG 的证据、检索与观测平面
替代文本： 文本、图像、音频、视频和结构化源经各自解析器进入统一证据目录，并写入词法、向量和业务查询索引；在线请求经过权限与模态路由、多路召回、融合精排、上下文构造和生成，观测平面收集版本、候选、质量、系统与成本数据。
图表加载中…
读图结论： 多模态不是在 LLM 前临时塞图片，而是从解析、证据身份、索引、路由、排序到引用全链路保留模态与定位信息。
图：技术调用流程｜带 Trace 的多模态查询、降级与拒答
替代文本： 用户请求进入编排器后生成根 Span，权限与模态路由决定检索通道；各通道回传候选和版本，融合精排后检查媒体读取和证据完整性，媒体失败可退到受支持的文本代理，完全无可靠证据则拒答；所有阶段上报指标与候选决策。
图表加载中…
读图结论： 多模态链路可以降级到可信文本代理，但不能在媒体错配、越权或完全无证据时静默生成。
11. 最小 Trace Schema 与查询样例
11.1 Span 事件示例
json
{
"request_id": "req-...",
"span": "rerank",
"query_hash": "sha256:...",
"tenant_id": "metro-a",
"versions": {
"corpus": "2026-07-13.2",
"text_index": "text-41",
"image_index": "image-12",
"reranker": "example-reranker-id",
"prompt": "support-mm-9"
},
"input_candidate_count": 48,
"output_candidate_count": 12,
"dropped_reasons": {"duplicate": 9, "low_score": 25, "media_unreadable": 2},
"latency_ms": 83,
"degraded": false
}示例中不保存候选正文，只保存数量、ID/哈希、版本和决策原因；是否足够取决于隐私、审计与重放要求。
11.2 诊断查询思路
sql
-- 伪 SQL：比较版本切换前后，图片类查询的错配与延迟。
SELECT
versions['image_index'] AS image_index_version,
percentile(latency_ms, 0.95) AS p95_ms,
avg(CASE WHEN outcome = 'wrong_region' THEN 1 ELSE 0 END) AS wrong_region_rate,
avg(CASE WHEN degraded THEN 1 ELSE 0 END) AS degraded_rate
FROM rag_trace_events
WHERE event_time >= :release_time
AND query_type = 'image_grounded'
GROUP BY versions['image_index'];真正实现可使用日志平台、Trace 后端、数据仓库或流式指标系统；关键不是具体产品，而是字段能支撑分阶段、分版本和分查询桶比较。
12. 面试追问与总结
12.1 递进追问
- 为什么 OCR 文本不能完全替代原图检索？
- 多模态检索各路分数如何融合，为什么不能直接相加？
- 一次 RAG Trace 至少要保存哪些候选与版本信息？
- 为什么总体 Recall 正常，图片类问题仍可能全面退化？
- 如何区分“合法空结果”和“检索服务失败”？
- 如何设计 Embedding/解析器升级的影子流量与回滚？
- 如果正确证据已进入
final_context，下一步应查什么？
12.2 一分钟面试复述版
我会把 RAG 可观测性拆成数据、检索、上下文、生成、系统和成本六层，并让每条 Trace 绑定语料、解析、切片、Embedding、索引、融合、Reranker、Prompt 和模型版本。多模态场景下，OCR/ASR 只提供文本代理，我还会保留原图区域、音视频时间片和父子关联，按模态分别召回和评测。线上退化时先固定
request_id与身份版本，找到正确证据第一次消失或错配的阶段；发布则用离线集、影子、灰度和别名回滚。权限事件必须为零容忍，相关性组件可以降级，但不能用越权或无证据内容兜底。
简明总结
一句话记忆： 能看到最终答案不叫可观测；能证明哪条证据在哪个版本、哪一阶段被找到、丢弃、截断或错配，才叫 RAG 可观测。
- 多模态 RAG 要保留原媒体定位、文本代理、模态向量和统一证据身份；
- 指标必须覆盖数据、召回、排序、上下文、生成、引用、系统与成本；
- Trace 要记录原始/改写 Query、过滤、每路候选、精排变化、最终上下文和完整版本矩阵；
- 看板与告警必须分租户、查询类型、模态和版本，避免平均值掩盖局部退化；
- 影子、灰度、回滚和失败样本回流共同构成生产防线。