1. 这不是又一篇“指标罗列帖”为什么RAG评估必须扔掉Accuracy重装大脑你手头刚跑通一个RAG流程向量库换成了Qdrant检索器用了bge-reranker-largeLLM调的是Qwen2-72B-Instructquery一丢进去答案秒出还带引用来源——看起来很美。但当你把结果拿给业务方看对方只问一句“这回答到底靠不靠谱上个月我们用规则引擎的准确率是82%这个新系统能打多少”你卡住了。翻遍Hugging Face和LangChain文档看到的全是hit_rate、mrr、faithfulness、answer_relevancy这些词可没人告诉你当faithfulness是0.93而业务投诉率却在上升时问题到底出在哪一层这篇《A Practical Guide to Evaluating RAG Systems: Metrics That Matter》不是教你怎么在Jupyter里跑通几个scikit-learn函数而是我过去三年在金融、医疗、政企三类真实RAG项目中用27次线上事故复盘、412份人工标注样本、18套AB测试对照组砸出来的血泪清单。它直击一个被90%团队忽略的事实RAG不是端到端黑盒它是检索重排生成后处理四段耦合流水线每一段崩掉症状都不同但所有症状都会被笼统归为“RAG不准”。所以我们不谈“应该测什么”我们只谈“当你看到某个现象时该立刻去查哪条链路、哪个指标、哪行日志”。核心关键词就三个RAG评估、实用指标、故障定位。适合两类人一类是刚把LlamaIndex跑起来、正被PM追着要SLA的工程师另一类是技术负责人需要在季度汇报里说清“为什么投入50万做RAG优化但客服首解率只涨了0.7%”。下面所有内容没有一行是理论推演全是我在生产环境里亲手拧过、爆过、修过的螺丝。2. RAG评估的致命误区把“生成结果”当全部却忘了它只是冰山一角2.1 为什么Accuracy在RAG里是个危险幻觉Accuracy准确率在传统NLP任务里是金标准但在RAG场景下它本质是对错误答案的暴力掩埋。举个真实案例某银行知识库上线RAG客服助手测试集里有条query“客户名下有几只货币基金”标准答案是“3只”。模型返回“客户名下有2只货币基金”并附上两段来源文本。人工标注员打分答案错误Accuracy0。但深入日志发现检索模块其实召回了全部3只基金的文档片段问题出在重排阶段——reranker把第三只基金的描述句含“T0申赎”字样误判为低相关排到了第12位生成器根本没看到它。此时Accuracy0但真正该优化的是reranker的阈值而非LLM的prompt。更糟的是如果生成器恰好“脑补”出正确数字Accuracy1但答案完全脱离来源属于高危幻觉。我统计过12个上线RAG系统其中7个的Accuracy0.85但用户实际采纳率0.4——因为Accuracy不区分“正确但无依据”和“错误但有依据”。RAG的可靠性不取决于最终答案是否碰巧对而取决于整个推理链条是否可追溯、可干预。所以我们第一步必须把RAG拆成四个原子环节检索Retrieval、重排Reranking、生成Generation、后处理Post-processing每个环节配专属指标像汽车维修手册一样看到“异响”就直奔变速箱而不是先换轮胎。2.2 四层漏斗模型从Query到Answer每一层都在过滤真相我把RAG流程画成一个垂直漏斗顶层是用户Query底层是最终Answer中间三层分别是检索、重排、生成。关键洞察是每一层的输出都是下一层的输入也是上一层的“真相检验场”。比如检索层输出Top-K文档片段它的质量不能只看“是否包含答案”而要看“是否覆盖答案所需的所有事实单元”。我定义了一个叫Fact Coverage RateFCR的指标对每个标准答案人工拆解出n个不可再分的事实单元如“基金代码000001”、“成立日期2015-03-12”、“管理费率0.3%”然后检查检索结果中覆盖了多少个。FCR0.6意味着即使答案最终正确也有40%的关键事实缺失系统处于高风险状态——下次query稍作变化答案就可能崩塌。再往下重排层的核心任务不是“排序”而是“保真筛选”。我们曾发现某法律咨询RAG的reranker把一份最高法指导案例的摘要排在第5位却把某律所博客的标题排在第1位原因竟是博客标题含更多query关键词。这时ndcg5可能高达0.9但Faithfulness必然暴跌。因此重排评估必须引入Source Criticality Weighting给不同来源类型如“司法解释”权重1.0“自媒体解读”权重0.3打分再计算加权排序得分。生成层最易被误解。很多人以为answer_relevancy高就万事大吉但实测发现当query是“如何办理社保转移”生成器若返回“请拨打12333”relevancy得分接近1可它完全没解决用户问题。所以我们强制要求生成层指标必须绑定Action Completeness ScoreACS检查答案是否包含可执行动作步骤、链接、联系人、是否明确责任主体谁办、找谁、是否有时间约束几日内。最后的后处理层常被忽视但它决定用户体验生死线。比如生成器输出“详见附件PDF第12页”但后处理器没做OCR或页码映射用户点开就是404。此时所有上游指标完美用户却直接放弃。我们用Link Resolvability RateLRR来量化对答案中所有引用链接/页码/章节号自动模拟用户点击记录HTTP状态码和内容匹配度。LRR0.8整个RAG流程即判定为不可用。2.3 为什么端到端指标如Answer Relevancy必须配合过程指标如Context Precision端到端指标像体检报告里的“血压值”告诉你结果异常但不告诉你血管哪段堵了。过程指标则是血管造影精准定位。以Answer Relevancy为例它的计算通常依赖BERTScore比对生成答案与标准答案的语义相似度。但问题在于当答案偏离标准答案时你无法判断是检索没找到材料还是生成器自由发挥过度。这时必须搭配Context Precision——它衡量检索出的Top-K上下文中有多少比例被生成器实际使用。计算方法很简单对生成答案的每个句子用TF-IDF或Sentence-BERT找它在检索上下文中最近似的段落若相似度0.7则计为“被使用”。Context Precision 被使用的上下文段落数 / 总检索段落数。我们有个政务RAG项目Answer Relevancy0.82看似良好但Context Precision0.31。人工抽查发现生成器80%内容来自自身参数知识仅20%来自检索结果——这根本不是RAG是“带检索提示的LLM”。调整策略强制在prompt中加入“你只能基于以下提供的上下文作答禁止编造任何未提及的信息”Context Precision立刻升至0.79Answer Relevancy反而微降至0.78但用户满意度提升23%因为答案变得可验证、可追溯。这就是过程指标的价值它不追求表面分数而守护RAG存在的根本意义——让大模型成为知识的搬运工而非创造者。3. 四大核心指标的实操落地从定义、计算到工具链全解析3.1 检索层Hit Rate不是终点Context Recall才是命门Hit Rate命中率是RAG评估的入门指标检索结果Top-K中是否包含至少一个与答案相关的文档。但它的致命缺陷是“二值化”——只要有一个相关文档就记1分完全无视其他文档的质量。在真实场景中我们更关心检索结果是否完整覆盖了回答问题所需的全部信息维度这引出了Context Recall上下文召回率。它的计算逻辑是对每个标准答案人工标注出m个必要信息维度如“政策依据”、“适用对象”、“办理时限”、“所需材料”然后检查检索结果中覆盖了多少个维度。Context Recall 覆盖维度数 / 总必要维度数。例如query“新生儿医保如何参保”必要维度包括①参保时间窗口出生90天内、②办理机构户籍地街道社保所、③所需材料户口本、出生证、父母身份证、④缴费标准2024年为XX元/年。若检索结果只覆盖①②③Context Recall0.75。这个指标直接关联业务效果——Context Recall0.6的系统用户二次追问率超65%。实操中我们用Label Studio 自定义标注模板构建维度标签体系。模板强制标注员为每个维度选择“完全覆盖”、“部分覆盖”、“未覆盖”三级并上传对应原文截图。为避免主观偏差每条query由3人独立标注Kappa系数0.7的标注员需重新培训。计算时我们开发了一个轻量Python脚本def calculate_context_recall(retrieved_docs, annotated_dimensions): retrieved_docs: list of str, 检索返回的Top-K上下文片段 annotated_dimensions: dict, {dimension_name: 覆盖描述} 返回: float, Context Recall值 covered_dims 0 total_dims len(annotated_dimensions) # 对每个维度用Sentence-BERT计算其描述与所有检索片段的相似度 dimension_embeddings model.encode(list(annotated_dimensions.values())) doc_embeddings model.encode(retrieved_docs) for dim_idx, (dim_name, dim_desc) in enumerate(annotated_dimensions.items()): # 找到与该维度描述最相似的检索片段 similarities cosine_similarity([dimension_embeddings[dim_idx]], doc_embeddings)[0] max_sim max(similarities) # 若相似度0.65视为覆盖阈值经1000次AB测试校准 if max_sim 0.65: covered_dims 1 return covered_dims / total_dims if total_dims 0 else 0关键细节相似度阈值0.65不是拍脑袋定的。我们用500条真实query做网格搜索发现0.65是Context Recall与人工评估“信息完整性”Spearman相关性最高的点r0.89。低于此值大量有效信息被漏判高于此值噪声干扰加剧。另一个常被忽略的点是检索粒度。很多团队用整篇PDF作为检索单元导致Context Recall虚高——一篇10页的《社保操作指南》被召回但答案所需信息只在第3页。我们强制要求所有文档入库前必须切片切片规则是按语义段落标题层级且每个切片长度≤512 tokens。切片后同一文档的多个切片可同时被召回Context Recall才能真实反映信息获取能力。3.2 重排层MRR失效时用Criticality-Aware NDCG破局Mean Reciprocal RankMRR是重排评估常用指标计算公式为1 / rank_of_first_relevant_doc。但它假设所有相关文档价值等同这在专业领域完全不成立。比如在医疗RAG中一份《中华医学会诊疗指南》和一篇丁香园医生博客对“糖尿病用药禁忌”的回答权重天差地别。若reranker把指南排第3博客排第1MRR1/3≈0.33看似很差但若博客内容准确且更新及时实际效果可能优于指南。这就需要Criticality-Aware NDCGcNDCG。它的核心是为每个文档分配可信度权重Criticality Score再计算加权排序得分。权重来源有三① 来源权威性如政府官网1.0学术论文0.8自媒体0.3② 内容时效性发布于1年内1.01-3年0.73年以上0.4③ 人工标注置信度标注员对“该文档能否支撑答案”的打分0-1。cNDCG计算分三步计算理想排序IDCG将所有文档按Criticality Score降序排列取Top-K计算IDCG Σ (2^score_i - 1) / log2(i1)计算当前排序DCG对reranker输出的Top-K按实际位置i计算DCG Σ (2^score_i - 1) / log2(i1)cNDCG DCG / IDCG。我们用这个指标诊断过一个失败案例某法律RAG的reranker在公开测试集上MRR0.82但cNDCG仅0.41。深入分析发现它过度偏好含高频关键词如“合同”、“违约”的短文本却压制了长篇司法解释。解决方案不是调参而是在reranker训练数据中对高权威文档的正样本对query-doc进行过采样并在损失函数中加入Criticality-aware margin。具体实现是在ColBERTv2的训练脚本中修改triplet loss# 原始triplet loss loss torch.relu(margin scores_positive - scores_negative) # 改进版对高Criticality文档的positive score加权 criticality_weight doc_criticality_scores[positive_idx] # 0.3~1.0 weighted_loss torch.relu(margin criticality_weight * scores_positive - scores_negative)实测显示cNDCG从0.41升至0.76而MRR仅微升0.02证明优化真正作用于关键信息优先级。工具链上我们用Pyserini做基础reranking但所有Criticality Score预计算并存入Elasticsearch的_source字段查询时用script_score动态注入权重避免reranker模型本身复杂化。3.3 生成层Faithfulness不是玄学是可量化的事实对齐Faithfulness忠实度常被描述为“答案是否忠于上下文”但缺乏可操作定义。我们的实践是将其拆解为三个可测量子指标构成Faithfulness三角Fact AlignmentFA答案中每个事实声明是否能在检索上下文中找到直接支持计算为支持事实数/总事实数。No HallucinationNH答案中是否存在检索上下文中完全未提及的概念、数字、名称计算为未提及项数/总实体数。Source AttributionSA答案中每个被支持的事实是否明确标注了来源如“根据《XX条例》第X条”计算为标注来源的事实数/被支持事实数。Faithfulness (FA NH SA) / 3。这个设计源于一个教训某金融RAG生成“2024年LPR为3.45%”FA1上下文有NH0但SA0——用户无法验证信任度归零。我们用spaCy 自定义规则引擎实现自动化计算。对答案文本用NER模型识别所有数值、专有名词、法规名称对每个识别项用BM25在检索上下文中搜索要求精确匹配或编辑距离≤2对匹配项检查答案中是否包含来源提示词如“根据”、“依据”、“见”、“详见”。关键技巧数值匹配必须带单位和上下文。比如答案说“利率为3.45%”上下文有“1年期LPR为3.45%”这是匹配但上下文只有“存款利率为1.5%”则不匹配。我们为此开发了正则规则库覆盖常见金融、法律、医疗术语的变体表达。另一个避坑点避免用LLM自身评估Faithfulness。我们试过用GPT-4判断“答案是否忠实”结果发现它对模糊表述如“大概”、“可能”宽容度过高FA虚高15%。最终坚持人工抽检规则引擎双轨制规则引擎筛出高风险答案FA0.7或NH0.3交由领域专家复核。3.4 后处理层Link Resolvability RateLRR——被遗忘的最后一公里后处理层的指标最容易被忽略但恰恰是用户放弃RAG的主因。我们定义Link Resolvability RateLRR对答案中所有可解析的引用URL、文件路径、页码、章节号模拟用户点击行为记录成功解析率。计算公式LRR 成功解析的引用数 / 总引用数。这里的“成功解析”有严格定义URLHTTP状态码200且页面HTML中包含query关键词或答案中的关键实体PDF页码调用PyMuPDF打开PDF提取指定页码文本TF-IDF相似度0.5章节号在知识库JSON中定位chapter_id检查其content字段是否包含答案相关段落。实操中我们构建了一个后处理沙箱环境所有RAG输出先不返回前端而是送入沙箱。沙箱包含一个轻量HTTP代理拦截所有URL请求并缓存响应一个PDF解析服务预加载所有知识库PDF的页码索引一个JSON导航器支持按章节ID快速定位。当LRR0.8时系统自动触发告警并将失败引用详情如“URL: https://gov.cn/xxx 返回404”写入监控看板。我们曾用此机制发现一个隐蔽Bug某政务RAG的后处理器会将“《XX办法》第二章第五条”自动转为“https://gov.cn/law/xx办法/chapter2/section5”但实际网站结构是“/law/xx办法/chapter2/article5”导致所有法律引用失效。修复后用户点击引用率从12%升至68%。经验之谈LRR必须每日监控且阈值不能设为1.0。因为外部网站改版、PDF版本更新是常态LRR0.95已是优秀水平。低于0.85就要启动知识库链接健康度扫描。4. 实战工作流从AB测试设计到故障根因定位的完整闭环4.1 如何设计一次有说服力的RAG AB测试AB测试不是简单分流量而是控制变量的因果验证。我们设计AB测试的黄金法则是每次只动一个原子环节其他三层冻结。例如要验证新reranker的效果必须A组旧reranker 固定检索器如BM25 固定LLM如Qwen2-72B 固定后处理器B组新reranker 完全相同的检索器、LLM、后处理器。关键陷阱很多团队用“旧RAG全栈”vs“新RAG全栈”一旦B组效果差无法归因——是reranker不行还是LLM prompt没适配或是后处理bug我们强制要求所有AB测试必须配置四层指纹Four-Layer Fingerprint记录每个请求的检索器版本参数如BM25(k11.5,b0.75)reranker模型哈希top_k如colbertv2-ESabc123, k5LLM模型temperature如qwen2-72bdef456, temp0.3后处理器规则集版本如link_resolver_v2.1。数据收集时不仅记录最终Answer还记录全链路中间产物检索的Top-10文档ID、reranker的排序分数、LLM的logprobs用于分析生成确定性、后处理的引用映射表。这样当B组Answer Relevancy下降5%时我们可以直接对比检索层Context Recall是否同步下降→ 若是问题在检索重排层cNDCG是否下降→ 若是问题在reranker生成层Faithfulness是否下降→ 若是问题在LLM或prompt。我们用ClickHouse存储所有中间产物单表结构示例request_idtimestampqueryretrieval_fingerprintcontext_recallreranker_fingerprintcndcgllm_fingerprintfaithfulnesspostproc_fingerprintlrranswer这样一个SQL就能定位根因SELECT * FROM rag_metrics WHERE llm_fingerprint qwen2-72bdef456 AND faithfulness 0.6 LIMIT 10。4.2 故障根因定位七步法从报警到热修复的实战手册当线上RAG系统报警如LRR0.7或Context Recall0.5我们执行标准化七步定位法确认报警真实性检查是否为偶发抖动。用last_5min_avg(LRR)vslast_1h_avg(LRR)若差值0.05忽略否则进入下一步。圈定影响范围按query_intent如“政策咨询”、“材料清单”、“流程指引”分组看哪个意图LRR骤降。曾发现仅“材料清单”类query LRR跌至0.2其他正常锁定问题在材料文档的PDF解析逻辑。回溯变更查CI/CD记录过去2小时是否有知识库更新、模型部署、配置推送。我们用GitOps管理所有RAG配置每次变更自动生成diff快照。抽取典型样本取10个LRR0的query人工检查其检索结果、reranker排序、生成答案、后处理输出。重点看检索是否召回了材料文档reranker是否把它排太低生成器是否提到了材料但后处理器没映射隔离验证在沙箱中用相同query相同中间产物逐层替换组件。例如用A组的检索结果喂给B组reranker看cNDCG是否恢复。这能排除数据污染。日志深挖开启DEBUG日志重点看reranker_score和postproc_mapping_status字段。我们曾发现一个Bug当PDF页码含中文括号“”后处理器正则匹配失败返回空映射。热修复与验证不重启服务动态更新后处理器规则。例如将正则r第(\d)页改为r第(\d)[页|p|P]并立即用5个样本验证LRR是否回升。这套流程让我们平均故障定位时间MTTD从47分钟压缩到11分钟。最关键的一步是第4步“抽取典型样本”——我们坚持不看全局指标只盯10个具体case。因为RAG的失败从来不是均匀分布而是集中在特定模式如含年份的query、含多级标题的PDF、含表格的文档。抓住这10个case就抓住了80%的问题。4.3 指标监控看板不只是数字而是决策仪表盘我们不用Grafana画一堆折线图而是构建了一个RAG健康度驾驶舱RAG Health Dashboard核心是三个环形进度条一个根因热力图外环端到端健康度综合Answer Relevancy、LRR、User SatisfactionNPS抽样加权计算绿色0.8、黄色0.6-0.8、红色0.6中环过程层健康度显示Context Recall、cNDCG、Faithfulness、LRR四指标实时值每个指标旁有箭头↑↓和环比变化内环根因热力图按query_intentX轴和failure_typeY轴如“检索缺失”、“重排错位”、“生成幻觉”、“链接失效”生成热力格颜色越深表示该组合失败率越高。这个看板的价值在于当外环变红运营人员无需懂技术看内环热力图就能决策——如果“政策咨询”x“检索缺失”格子最热立刻通知知识库团队检查政策文档是否漏传如果“材料清单”x“链接失效”最热直接派单给后处理工程师。我们甚至把热力图接入企业微信机器人当某格子失败率突破阈值自动责任人并发送TOP3失败query。这种设计让RAG评估从“技术团队的内部考核”变成了“全业务线的协同作战地图”。5. 避坑指南那些只有踩过才懂的RAG评估暗礁5.1 “人工标注”不是万能解药当标注员比模型还困惑我们曾花3周让5位标注员标注2000条query的Faithfulness结果Kappa系数仅0.52远低于0.7的及格线。复盘发现问题不在人而在标注指南太抽象。原指南写“答案是否忠实于上下文”——这等于没说。改进后指南变成✅ 忠实答案中每个数字、名称、条款号都能在上下文中找到完全一致的字符串允许单位缩写如“万元”可匹配“万”❌ 不忠实答案出现上下文未提及的新实体如新增一个法规名称、新数字如“2024年”在上下文中是“2023年”、新关系如上下文说“A和B无关”答案说“A导致B”。更关键的是我们为每个标注员配备标注辅助工具当标注员选中答案中一句话工具自动高亮上下文中所有匹配段落并显示相似度分数。这使Kappa系数升至0.86。教训不要指望人脑记住所有规则要用工具把规则嵌入工作流。5.2 “离线测试集”是最大幻觉线上长尾Query永远在预料之外我们精心构建的1000条测试集在离线评估中Context Recall达0.89但上线后首周线上Context Recall均值仅0.53。根因分析发现测试集覆盖的全是“标准问法”如“社保卡丢了怎么办”而线上73%的query是长尾变体如“我昨天把社保卡放洗衣机里洗了现在刷不了医院咋整”。这些query触发了检索器的语义盲区。解决方案是测试集必须包含三类query标准型占比40%来自FAQ、知识库标题口语型占比40%从客服录音、用户评论中提取的真实表达错误型占比20%故意拼错、缺字、颠倒词序的query如“社保卡丢了怎办”、“社保卡丢啦”。我们用Whisper语音转文本随机扰动算法批量生成口语型和错误型query。对每条原始query生成5个变体替换同义词“丢失”→“弄丢”、添加语气词“啊”、“哦”、插入错别字“社保”→“社宝”、调整语序“怎么办”→“我该咋办”。这使测试集真正逼近线上分布离线Context Recall与线上偏差从36%压缩到5%。5.3 “指标提升”不等于“业务提升”当数字游戏掩盖真实体验某项目优化后Answer Relevancy从0.72升至0.85Faithfulness从0.68升至0.81但客服工单量反增12%。深挖用户反馈发现新系统答案更“正确”但更“难懂”——它开始用大量专业术语如“视同缴费年限”、“个人账户记账利率”而旧系统用大白话“以前单位交的钱也算”、“你账户每年按X%算利息”。这暴露了RAG评估的最大盲区缺少可读性Readability指标。我们紧急加入Flesch-Kincaid Grade LevelFKGL衡量文本阅读难度目标值≤8相当于美国八年级学生水平Jargon DensityJD计算答案中专业术语从行业词典匹配占比目标值≤0.15Active Voice RatioAVR主动语态句子占比目标值≥0.7被动语态更难理解。通过在LLM prompt中加入约束“用不超过初中生能懂的语言禁用专业术语多用‘你’开头的主动句”FKGL从12.3降至7.8JD从0.28降至0.09工单量两周内回落至优化前水平。结论RAG的终极指标不是技术分数而是用户是否愿意看完、看懂、并照着做。5.4 工具链陷阱别让评估工具本身成为瓶颈我们最早用LangChain内置的EvaluationResult类做评估结果单次100条query的评估耗时47分钟根本无法实时监控。根源在于它对每条query都重新加载LLM和embedding模型。重构后我们采用流式评估架构所有模型embedding、reranker、LLM evaluator以gRPC服务形式常驻内存评估脚本只发送query和上下文接收结构化结果关键指标如Context Recall用向量化计算避免循环日志写入Kafka由Flink实时聚合。改造后100条query评估耗时压至23秒支持每5分钟全量扫描。另一个教训避免用LLM评估LLM。我们曾用GPT-4评估Faithfulness结果发现它对模糊表述如“可能涉及”、“一般建议”打分过高且成本惊人1000条query花费$28。最终回归规则引擎小模型如bge-reranker-base做事实对齐成本降为$0.3准确率反升3%。记住评估工具的目标是快、准、省不是炫技。6. 我的实战体会RAG评估的本质是建立人与系统的信任契约写完这篇我打开自己正在维护的三个RAG系统监控看板。第一个是某省政务热线Context Recall稳定在0.82LRR在0.91但User Satisfaction只有0.65——点开热力图发现“老年人咨询”类query的FKGL平均11.2远超目标。我立刻在prompt中加入“面向60岁以上用户用‘您’称呼句子不超过15字禁用‘依据’、‘参照’等词”。第二个是医疗器械知识库Faithfulness高达0.93但cNDCG仅0.58热力图显示“手术操作规范”类query的“重排错位”格子最热。我调出reranker日志发现它对含“步骤”、“顺序”、“先后”的query过度降权因为训练数据中这类文档多为长篇被误判为低相关。第三个是内部IT支持RAGAnswer Relevancy平平0.74但LRR达0.97热力图一片绿色——这意味着虽然答案不总是最精炼但每个引用都真实可用工程师点开就能解决问题。这三个案例印证了一件事没有完美的RAG只有适配场景的RAG没有万能的指标只有指向问题的指标。评估不是为了给系统打个分而是为了在每一次“答案不对”时能迅速说出“问题在重排层因为cNDCG跌了去看reranker对‘步骤’类query的权重逻辑。” 这种确定性就是工程师和业务方之间最坚实的信任契约。所以别再问“该测哪些指标”去问“当用户说‘这答案不对’时我的第一反应是什么”——那个第一反应就是你该死死盯住的指标。