真实面经题目 · 原创解析
这题考察的不是“能不能背几个指标名”，而是能否把多模态/RAG 项目上线前的评价体系拆成可决策、可归因、可监控的指标框架。来源只支持“项目上线前评价指标”和“RAG 子模块评价指标”这两个面试追问，因此回答应聚焦通用方法论，不编造任何阿里内部指标。高质量答案要先定义上线目标和风险边界，再把评价拆成三层：端到端业务效果、模型回答质量、RAG 链路子模块效果。最终要能回答三个问题：整体效果好不好、如果不好是哪一段坏了、达到什么阈值才能灰度上线。
我会把上线前评估拆成“端到端效果”和“RAG 子模块归因”两套指标，但两者要用同一批代表性评测集串起来。第一层是项目整体指标，回答上线后用户是否真的能完成任务，包括任务成功率、人工验收通过率、答案采纳率、用户满意度、覆盖率、P95 延迟、单次成本、失败率、安全拦截率和线上灰度 A/B 指标。对多模态/RAG 项目，还要重点看答案是否基于检索证据、是否正确引用图片/表格/文档信息、是否有幻觉、是否遗漏关键视觉信息。第二层是回答质量指标，通常包括 correctness、faithfulness、relevance、completeness、citation accuracy、multimodal grounding、robustness 和 safety。第三层是 RAG 子模块指标：数据层看知识覆盖率、文档解析质量、OCR/表格/图片描述质量、chunk 质量、元数据完整性和新鲜度；召回层看 recall@k、hit rate、MRR、nDCG、查询改写收益和多路召回贡献；重排层看 top-k evidence precision、nDCG、pairwise preference 和延迟；上下文组装层看证据覆盖、冗余率、冲突证据处理、token 利用率和关键证据是否进入 prompt；生成层看基于证据的正确率、引用准确率、拒答合理性、幻觉率和格式稳定性。上线前我会做离线 golden set、人评、自动评估、模块消融、错误归因和小流量灰度，只有当硬门槛指标如安全、正确性、幻觉率、延迟、成本都达标，且主要错误可解释可回滚，才进入更大范围发布。
上线前评价不能从指标名开始，而要先问这个多模态/RAG 项目要解决什么任务：是文档问答、商品图文理解、知识库客服、报告解析，还是图片/表格/文本混合检索。不同任务的上线目标不同，但共同点是必须把“用户任务完成”作为最高层指标，而不是只看模型生成得像不像。还要明确哪些风险是硬门槛，例如事实错误、引用伪造、敏感内容泄露、错误读取图片或表格、超时、成本不可控、无法降级。面试回答中可以强调：整体指标用于判断能否上线，子模块指标用于定位问题；如果没有这层拆分，只看端到端分数会不知道该优化检索、重排、解析还是生成。
整体效果指标应该围绕用户最终体验和业务交付。离线侧可以看任务成功率、人工验收通过率、答案正确率、答案完整性、相关性、可读性、拒答合理性、幻觉率、引用准确率和多模态 grounding。线上侧可以看采纳率、二次追问率、人工转接率、用户反馈、投诉率、会话完成率、留存或转化等业务指标。工程侧必须看 P50/P95/P99 延迟、超时率、错误率、单次请求成本、检索与生成 token 消耗、缓存命中率、降级率和可用性。上线前最好把这些指标分成硬门槛和优化指标：安全、正确性、幻觉、隐私、可用性是硬门槛；满意度、成本、延迟、覆盖率则用于决定灰度比例和迭代优先级。
多模态/RAG 项目比纯文本 RAG 多一层输入解析和跨模态对齐。评价时要检查图片、截图、PDF、表格、图表、OCR 文本和普通文本是否被正确抽取和关联。典型指标包括 OCR 字符/字段准确率、表格结构还原准确率、图表关键信息抽取准确率、图片描述覆盖率、视觉实体识别准确率、区域定位或证据定位准确率、跨模态一致性和视觉信息遗漏率。如果答案涉及图片中的数值、位置、属性或关系，就要看模型是否真的使用了视觉证据，而不是用语言先验猜测。对上线前评估来说，多模态错误往往会传导到检索和生成，所以需要把“解析错误导致答错”和“检索没召回导致答错”区分开。
RAG 的第一段不是检索，而是知识建设。数据层要评估语料覆盖率、更新新鲜度、去重率、过期内容比例、权限标注完整性、元数据完整性、文档解析成功率、chunk 粒度合理性、chunk 语义完整性和跨页/跨表关系保留情况。多模态场景还要评估图片、表格、公式、截图、流程图等非文本内容是否被转换成可检索、可追溯的表示。常见做法是为高频问题建立 evidence oracle，即人工标注哪些文档、段落、图片区域或表格单元能支撑答案，然后用这批标注来评估后续召回和重排。数据层不达标时，后面的 reranker 和生成模型很难补救，因为正确证据可能根本不存在或被切碎了。
召回层的核心问题是：给定用户 query，系统是否把足够支撑答案的证据放进候选集合。常用指标包括 recall@k、hit rate@k、MRR、nDCG、coverage、query rewrite 成功率、多路召回贡献率和无结果率。对于 RAG，上线前不要只看向量相似度或 embedding 分数，因为相似度高不等于能回答问题；更重要的是正确证据是否进入候选 top-k。多模态场景还要分别评估文本召回、图片召回、表格召回、OCR 召回、结构化字段召回，以及混合召回融合后的增益。一个好的回答可以说：召回指标主要保证 recall，不直接保证最终答案正确，但召回低会给端到端效果设置天花板。
召回之后，重排要解决“哪些证据最应该给生成模型看”。可以用 top-1/top-3 evidence precision、nDCG@k、pairwise preference、正负样本区分能力、跨模态证据排序准确率和重排延迟来评估。上下文组装还要看关键证据覆盖率、冗余率、冲突证据处理、证据顺序、token 利用率、被截断证据比例和引用 ID 是否稳定。很多 RAG 项目端到端答错，不是因为没召回，而是正确证据排得太靠后、被 token 截断、和无关证据混在一起，或者图片/表格证据没有以模型能理解的形式进入 prompt。因此上线前要做模块消融：固定生成模型，分别替换 oracle retrieval、oracle rerank、oracle context，观察整体分数提升，就能定位瓶颈。
生成层评价要把“说得通”和“有证据支撑”分开。核心指标包括答案正确率、faithfulness/groundedness、引用准确率、证据覆盖率、无证据编造率、拒答合理性、格式稳定性、指令遵循、可读性和多轮一致性。对于 RAG，模型不应该在证据不足时强行回答；所以拒答不是负指标，错误地自信回答才是风险。多模态场景还要检查模型是否正确引用视觉内容，例如视觉输入中的实体、表格里的数值、图表趋势、截图里的按钮或状态。上线前可以采用人评加 LLM-as-judge 的组合，但高风险样本、边界样本和线上高频样本必须有人审，因为自动评估容易被流畅但错误的答案欺骗。
评测集要覆盖真实线上分布和风险样本，至少包括高频问题、长尾问题、多跳问题、时效问题、无答案问题、相似文档干扰、权限隔离、图片/表格/文本混合问题、噪声 OCR、跨页引用和多轮追问。每条样本最好包含标准答案、可接受答案、证据标注、不可接受错误类型和难度标签。归因时可以建立错误标签：数据缺失、解析错误、召回失败、重排失败、上下文截断、证据冲突、生成幻觉、拒答错误、格式错误、安全策略误伤。这样整体分数下降时，团队能知道是该补知识库、调 chunk、换 embedding、改召回策略、训练 reranker，还是优化 prompt/生成模型。
上线前应该设定 gate，而不是只给一个总分。可以设计硬门槛：安全违规为零或低于极小阈值，隐私权限错误为零，关键任务正确率超过业务要求，幻觉率低于阈值，P95 延迟和单次成本在预算内，服务可用性和降级链路验证通过。灰度阶段要监控端到端任务成功率、负反馈、无答案率、人工转接率、异常 query 聚类、召回无结果率、引用点击率、成本和延迟。还要保留回滚策略：模型版本、索引版本、chunk 版本、reranker 版本和 prompt 版本都要可追踪，否则线上波动无法定位。面试里讲到这一层，能体现你理解评价指标不是论文分数，而是上线决策系统。
可以做 oracle ablation。先用人工标注的正确证据替换检索结果，如果答案大幅变好，说明主要瓶颈在数据、召回、重排或上下文组装；如果给了正确证据仍然答错，说明生成模型、prompt、引用策略或安全拒答策略有问题。还可以看中间指标：正确证据是否进入 recall@k、是否被 rerank 到前几位、是否被放入 prompt、是否被生成答案引用。
最关键的是正确证据的 recall@k 和 hit rate@k，因为召回层的目标是把能回答问题的证据找出来。MRR 和 nDCG 可以进一步评估正确证据是否靠前。多模态 RAG 还要分开看文本、图片、表格、OCR 等不同证据类型的召回表现，否则整体 recall 看起来不错，但某类视觉证据可能一直找不到。
最终答案准确率只能说明端到端结果，不告诉你原因。答案答对可能是模型靠常识猜对，并没有用到证据；答案答错也可能是知识库缺失、chunk 切分错误、召回失败、重排失败、prompt 截断或生成幻觉。上线前需要模块指标，否则优化会变成盲调，甚至可能把一个模块调好却让整体稳定性变差。
可以把幻觉拆成无证据编造、证据矛盾、视觉误读、引用伪造和过度推断。评估时让标注者检查答案中的关键 claim 是否能被检索证据支撑，特别是图片、表格、图表里的数值、实体、位置和关系。对无答案问题也要评估拒答，证据不足时正确拒答应算好结果，自信编造才是严重问题。
评测集要来自真实 query、产品核心场景和风险样本，而不是只手写简单问题。每条样本最好有标准答案、证据标注、难度标签、所属模态、是否多跳、是否有答案、权限要求和错误类型。还要保留线上失败样本做回归集，保证每次更新索引、embedding、reranker、prompt 或模型时都能比较新旧版本。
可以辅助，但不能完全替代。LLM-as-judge 适合大规模粗筛、格式检查、相关性初判和回归趋势观察，但在事实正确性、引用真实性、多模态视觉细节、安全边界和业务高风险样本上仍需要人评。比较稳妥的做法是自动评估覆盖全量，人评覆盖高风险、争议样本和线上高频样本，并定期校准 judge 与人工一致性。
