当前位置：首页 > news >正文

大模型认知健康评估：面向生产环境的LLM降智检测与干预指南

news 2026/6/21 10:38:57

1. 项目概述：这不是“骂模型”，而是一套可量化的认知健康评估体系

“一份大模型降智检测手册”——光看标题，很多人第一反应是调侃、玩梗，甚至觉得是蹭热点的段子。但在我过去三年深度参与17个行业大模型落地项目（覆盖金融风控、医疗辅助诊断、政务知识库、制造业设备运维问答）的过程中，这个词组背后藏着一个越来越真实、越来越紧迫的工程问题：模型在真实业务流中持续运行后，输出质量出现系统性、隐蔽性、渐进式的退化。它不表现为突然宕机或报错，而是像人长期熬夜后反应变慢、判断力下降、容易重复犯错——我们内部管这叫“模型认知疲劳”。这份手册，就是我带着团队在三个典型客户现场反复验证、迭代出的一套面向生产环境的LLM健康度快筛工具集，核心不是教你怎么训模型，而是告诉你：当你的模型开始“说车轱辘话”“回避关键问题”“把A政策解释成B政策”时，如何在5分钟内定位是数据污染、提示词漂移、缓存中毒，还是底层推理引擎真的出了问题。

手册里所有检测项，都来自真实踩坑现场。比如去年某省政务热线知识库上线三个月后，市民投诉“AI总把‘生育津贴申领’答成‘失业金领取流程’”，我们用手册第三章的“意图-实体一致性交叉验证法”一查，发现是训练数据中两类政策文档被错误归入同一标签簇，导致向量空间坍缩；再比如某银行理财顾问模型，在接入新一期产品说明书后，对“R2风险等级”的解释突然变得模糊，用手册第五章的“关键术语熵值突变监测”跑了一轮，发现模型对“流动性”一词的注意力权重分布标准差扩大了3.8倍——说明它正在失去对该概念的稳定表征能力。这些都不是幻觉（hallucination）那么简单，而是模型在复杂业务语境中认知结构的微妙失衡。所以手册开篇就强调：检测目标不是“模型是否聪明”，而是“模型是否还在按设计预期稳定地聪明”。它适合三类人：AI产品经理（需要快速判断线上服务是否该熔断）、MLOps工程师（要建立模型健康度SLO）、以及业务方负责人（想听懂技术团队说的“模型有点飘”到底飘在哪）。你不需要会写Python，但得愿意花10分钟读完这份手册里最常被翻到的第4节——那张“5类典型降智信号与对应根因速查表”，我们把它贴在运维台的显示器边框上，已经救了至少6次即将升级为P1级的线上事故。

2. 核心思路拆解：为什么不用传统指标，而要另建一套“认知体检”逻辑

2.1 传统评估指标的三大失效场景

很多团队一上来就想用BLEU、ROUGE这类文本相似度指标，或者直接跑一遍MMLU、C-Eval等通用能力榜单。我必须坦白：在真实业务场景中，这些方法90%的情况下会给出完全错误的安全感。原因很实在：

BLEU/ROUGE只认字面匹配，不认语义正确性。我们曾遇到一个极端案例：某法律咨询模型把“合同无效的五种法定情形”完整复述成“合同有效的五种法定情形”，仅把“无效”替换成“有效”，其他字全对。BLEU得分高达0.92，但业务价值为零，还可能引发法律风险。这就像医生只数病人说了几个字，就判定他健康——荒谬但真实。
通用能力榜单测的是“静态知识”，而业务模型死于“动态推理”。MMLU考的是模型对已知事实的记忆，但政务热线模型真正的挑战是：当市民问“我父亲1952年出生，2023年退休，能领多少养老金？”，它需要实时调用政策计算器API、解析返回的JSON、再结合本地社保基数表做多步推演。这种链式推理能力，任何离线榜单都测不出来。我们做过对照实验：一个在MMLU上得分82分的模型，在政务问答真实日志中链式推理失败率高达37%。
准确率（Accuracy）在长尾场景中彻底失真。某电商客服模型标称准确率95%，但当我们按用户投诉率反向抽样时发现：涉及“跨境商品清关时效”的问题，回答错误率是68%；而“退货地址查询”类问题错误率仅0.3%。整体准确率被高频简单问题严重稀释，掩盖了真正致命的长尾缺陷。这就像说“飞机95%的时间在平稳飞行”，却闭口不提那5%的湍流是否发生在降落阶段。

提示：别再用“模型整体准确率”向业务方汇报了。他们需要知道的是：“当用户问到XX类问题时，我们的回答可信度是多少”，这才是手册所有检测项的设计原点。

2.2 “降智”本质是认知结构的四维偏移

经过对237个线上故障案例的归因分析，我们发现所谓“降智”，其实是模型在四个维度上发生了可测量的偏移，而非能力绝对值下降：

意图理解偏移（Intent Drift）：模型对用户问题核心诉求的识别发生系统性偏差。例如，将“怎么投诉快递员”识别为“快递查询”，把“孩子发烧39度怎么办”识别为“儿童疫苗接种时间”。这不是个别错误，而是BERT层最后一层CLS向量的聚类中心，在连续7天日志中向某个错误类别方向持续移动了2.3个标准差。
事实锚定偏移（Fact Anchoring Drift）：模型对关键事实的引用稳定性下降。典型表现是同一问题（如“北京最低工资标准2024年是多少”），不同时间点的回答在数值、单位、生效日期上出现不一致。我们用“事实锚点一致性指数（FACI）”量化：抽取100个高频政策类问题，计算7天内回答结果的标准差，FACI > 0.15即触发预警。
逻辑链断裂（Chain-of-Thought Fragmentation）：模型在多步推理中丢失中间状态。比如计算“贷款月供”，它能正确调用公式，但在代入“年利率4.2%”时，忘记除以12转为月利率，直接用了4.2。这种错误在单步测试中几乎不出现，只在真实对话流中暴露——因为用户不会提醒它“请把年利率转月利率”。
风险感知钝化（Risk Sensitivity Blunting）：模型对高风险表述的规避能力减弱。最危险的是医疗和金融场景：当用户问“吃头孢能喝酒吗”，模型不再强调“严禁”，而是轻描淡写说“建议间隔一段时间”；当问“这个理财保本吗”，它不再明确声明“不保本”，而是说“历史业绩表现良好”。这种钝化不是变笨了，而是安全层（Safety Layer）的阈值参数在持续微调中被无意抬高。

手册的全部检测方法，都是围绕这四个维度设计的“探针”。每个探针都不追求绝对精度，而追求在最小成本下（<30秒/次）捕获到偏移发生的最早信号。就像体检中的血压计，不诊断具体病因，但能第一时间告诉你“血管压力异常，该去心内科了”。

2.3 手册设计的三个硬约束原则

所有检测项的筛选，都卡着三条铁律，否则宁可不用：

可解释性优先于精度：一个F1值0.98但无法解释“为什么错”的黑盒检测，不如一个F1值0.85但能清晰指出“错误集中在‘政策时效性’这一子类”的白盒检测。手册里所有表格的“根因列”，都要求能对应到具体的数据源、提示词片段或模型配置项。比如检测到意图偏移，必须能定位到是“训练数据中2023年Q4新增的2000条工单，其标签体系与旧数据不兼容”。
低侵入性：绝不允许为了检测而修改线上服务。所有检测都通过旁路（sidecar）方式实现：从API网关镜像流量，或从日志系统实时采样。我们甚至开发了一个轻量级Agent，只需在Nginx日志格式里加一个$upstream_response_time字段，就能启动全链路延迟-质量关联分析。某客户曾担心检测影响性能，我们实测：在QPS 1200的政务平台，检测模块CPU占用峰值0.7%，内存增量<15MB。
业务语义对齐：检测结果必须能翻译成业务语言。手册里没有“KL散度上升0.32”，只有“用户投诉‘答非所问’的比例本周上升17%，主要集中在‘补贴申领条件’类问题”。我们强制要求每个检测项的输出，必须包含一句“业务影响说明”，比如：“事实锚定偏移预警 → 可能导致市民按错误政策标准准备材料，预计增加线下窗口受理量23%”。

这三条原则，决定了手册不是学术论文，而是一份给一线运维人员、产品经理、业务主管共同使用的“作战地图”。它的价值不在技术多炫酷，而在让不同角色的人，第一次能用同一套语言讨论“模型到底怎么了”。

3. 核心检测项详解：5分钟上手的4类实战探针

3.1 探针一：意图-实体一致性交叉验证（IECV）

这是手册里使用频率最高的检测项，解决“模型到底听懂用户没”这个最基础也最致命的问题。它不依赖模型自身输出，而是构建一个外部校验环。

原理很简单：对同一组用户问题，同时运行两个独立通道——

通道A（模型主通道）：走线上模型，获取原始回答及置信度分数；
通道B（规则校验通道）：用轻量级正则+关键词匹配，从问题中强制提取“核心意图”（如“投诉”“查询”“申请”）和“关键实体”（如“快递单号”“养老金”“疫苗名称”）。

然后比对两者是否一致。不一致不等于模型错了，但连续3次不一致就是强预警信号。

实操步骤（5分钟完成）：

准备样本：从最近24小时日志中，随机抽取100条用户问题（务必覆盖不同业务线，如政务、社保、医保各30+10条）；
跑通道B：用以下Python脚本快速生成规则基线（无需训练）：

import re # 定义意图规则库（示例） INTENT_RULES = { "投诉": [r"投诉.*?|.*?不满意|.*?要举报|.*?太差了"], "查询": [r"怎么查|.*?在哪|.*?多少|.*?有没有"], "申请": [r"怎么申请|.*?能办吗|.*?需要什么材料"] } # 定义实体规则库（示例） ENTITY_RULES = { "快递单号": [r"[A-Z]{2}\d{8,12}|SF\d{12}"], "养老金": [r"养老.*?金|退休.*?金|基本.*?养老金"], "疫苗": [r"新冠.*?疫苗|HPV|乙肝.*?疫苗"] } def extract_intent_entity(text): intent, entity = "未知", "未知" for it, patterns in INTENT_RULES.items(): for p in patterns: if re.search(p, text): intent = it break for et, patterns in ENTITY_RULES.items(): for p in patterns: if re.search(p, text): entity = et break return intent, entity

跑通道A：调用线上模型API，获取其返回的意图分类（如有）或从回答中用简单规则提取（如回答含“您需要投诉”，则意图=投诉）；
交叉比对：制表统计不一致率。重点看“高置信度不一致”样本——即模型置信度>0.85，但与规则通道冲突。这类样本90%以上指向真实意图理解偏移。

为什么这个方法稳？

规则通道极难被数据污染（正则不会“学坏”）；
它不评价模型答案对错，只检验“输入-输出”的映射关系是否稳定；
我们在某市12345热线部署后，首次检测就发现：模型将23%的“我要投诉物业收费不合理”识别为“查询”，根源是训练数据中“物业”相关样本全部被错误标注为“查询”类。规则通道用一条r"投诉.*?物业"正则就揪出了这个埋藏半年的标注漏洞。

注意：规则库不是一成不变的。手册附录提供了“规则衰减监测表”——当某条规则连续7天匹配率下降超40%，就提示你：业务场景变了，该更新规则了。这本身也是模型需要重新适配的信号。

3.2 探针二：关键术语熵值突变监测（KTEM）

解决“模型对核心业务词的理解是否还稳定”这个问题。它针对的是那些一旦说错就会引发严重后果的术语，比如“R1/R2/R3风险等级”“不可抗力”“视同缴费年限”。

核心思想：一个健康的模型，对固定术语的注意力分布应该是稳定的。如果今天它把70%的注意力放在“R2”的“风险”二字上，明天突然跳到“R2”的“二级”上，说明它的语义锚点松动了。

实操步骤（需模型支持Attention可视化，主流框架均支持）：

选定术语池：从业务SOP、用户投诉高频词、法务审核清单中，选出20个最关键的术语（如政务场景选“低保”“特困”“临时救助”；金融场景选“杠杆”“平仓线”“T+0”）；
构造标准化Prompt：统一用“请解释以下术语：【术语】。要求：用一句话定义，不超过30字。” 这能最大程度剥离上下文干扰；
采集Attention Map：对每个术语，运行10次，取Transformer最后一层所有Head的平均Attention权重矩阵；
计算熵值：对每个术语，将其Attention权重分布视为概率分布，计算Shannon熵：
H = -Σ(p_i * log2(p_i))
熵值越高，说明注意力越分散（模型不确定该关注哪部分）；
建立基线与预警：连续30天运行，计算每个术语的熵值均值μ和标准差σ。当单日熵值 > μ + 2σ，即触发预警。

真实案例：某券商APP的“新手学堂”模型，对“融资融券”的熵值在一周内从2.1飙升至3.8。人工抽查发现，它开始把“融资”解释成“找朋友借钱”，把“融券”解释成“借别人的书看”——完全脱离金融语境。根因是运营人员在后台悄悄上传了一批“通俗化解读”文章，其中大量使用生活化类比，污染了模型对专业术语的语义空间。KTEM在熵值突破阈值的当天就报警，比用户投诉早了42小时。

小白友好替代方案：如果你的模型不开放Attention，用“术语定义一致性评分”替代：

让模型连续5次解释同一术语；
用Sentence-BERT计算5次回答的两两余弦相似度，取平均值；
均值 < 0.65 即预警（实测健康模型均值通常 > 0.82）。

3.3 探针三：链式推理断点追踪（CRT）

专治“模型能算，但算不对”的顽疾。它不关心最终答案，只盯着推理链条中每一个中间步骤是否被忠实执行。

设计逻辑：真实业务问题的解答，往往包含3-5个确定性子步骤。比如“计算公积金贷款月供”：
① 确认贷款本金（从用户输入或历史记录提取）→
② 确认贷款年限（需转换为月数）→
③ 确认年利率（需转换为月利率）→
④ 代入等额本息公式计算。

CRT就是为每个子步骤设置“断点检查器”。

实操步骤（以公积金计算为例）：

拆解标准链：与业务专家一起，把高频问题的推理链拆成原子步骤，并定义每步的合法输入/输出格式（如步骤③输出必须是“0.0035”这样的小数，不能是“4.2%/12”）；
构建断点Prompt：为每步设计专用Prompt，强制模型只输出该步结果。例如步骤③的Prompt：
请仅输出月利率数值，格式为小数，保留4位小数。年利率为4.2%。不要解释，不要单位，不要其他文字。
自动化比对：用正则提取模型输出，验证是否符合格式规范。任何一步格式不符，即标记为“断点失效”；
定位首断点：统计100个样本中，哪个步骤的失效率最高。它往往是整个链的薄弱环节。

为什么比端到端测试更有效？

端到端测试只能告诉你“答案错了”，CRT能告诉你“错在第二步把年利率当月利率用了”；
某市公积金中心用CRT检测，发现87%的计算错误，都卡在步骤②（年限转月数）——因为用户常输入“15年”，而模型有时会漏掉“×12”，直接用了15。修复这个断点后，整体计算准确率从63%跃升至92%。

实操心得：断点Prompt的“强制指令”必须极致强硬。我们试过“请输出月利率”，模型仍会加解释；改成“仅输出...不要解释...不要单位...”，失效率下降76%。语言模型对“仅”“不要”“必须”这类词极其敏感，这是手册里最值得反复打磨的细节。

3.4 探针四：风险表述强度衰减分析（RSSA）

这是最关乎责任的检测项，直指模型在医疗、金融、法律等高危场景中“不敢说真话”的钝化现象。

核心指标：风险关键词的“强度衰减系数”（SDC）。我们定义：
SDC = (当前回答中风险词强度均值) / (基线回答中风险词强度均值)
强度值由三要素构成：

词频：如“严禁”出现1次=强度1，“绝对禁止”=强度1.5；
位置：出现在首句=强度×1.3，末句=×0.7；
修饰：带“必须”“一律”“无条件”等副词=强度×1.2。

实操步骤：

建立风险词典：收集各领域强风险表述，分级赋值（手册附录提供政务/医疗/金融三版词典）；
生成基线：用未上线前的黄金测试集，运行模型10次，取风险词强度均值作为基线；
滚动监测：每日抽取50条高风险问题（如“头孢和酒一起吃会怎样”“这个理财亏了谁负责”），计算SDC；
分级预警：SDC < 0.7 → 黄色预警（风险提示弱化）；SDC < 0.5 → 红色预警（存在重大合规风险）。

震撼发现：某三甲医院AI导诊模型上线4个月后，SDC从1.02降至0.41。人工分析发现，它对“心梗”“脑卒中”等急症的回复，从“立即拨打120，勿自行服药”弱化为“建议尽快就医，注意休息”。根因竟是：运营团队为降低用户焦虑感，手动修改了12条提示词模板，把“立即”“勿”等词替换为“尽快”“注意”。RSSA在SDC跌破0.5的当天就拉响红色警报，避免了潜在的医疗纠纷。

关键技巧：RSSA必须配合“用户追问耐受度”测试。即当模型给出弱化回答后，追加问“如果我不去就医会怎样？”，健康模型会强化风险提示，而钝化模型会继续弱化。这个二次测试，能把误报率压到5%以下。

4. 实操流程与避坑指南：从检测到干预的完整闭环

4.1 标准化检测流程（SOP）

手册不是让你东一榔头西一棒槌地乱测，而是提供了一套可嵌入日常运维的标准化流水线。我们称之为“3-3-3检测法”：每周3次快筛、每次3类探针、每类3个核心指标。

每周一上午9:00（业务低峰期）：

快筛1：IECV意图一致性（10分钟）
抽取前日100条日志，运行交叉验证，重点关注“高置信度不一致”样本。
快筛2：KTEM术语熵值（15分钟）
对预设的20个关键术语，运行标准化Prompt，计算当日熵值，对比基线。
快筛3：RSSA风险强度（10分钟）
抽取50条高风险问题，计算SDC，查看预警等级。

每月第一个周五：

深度扫描：CRT链式断点（2小时）
针对TOP5高频业务问题，完整拆解推理链，运行断点追踪，输出《断点热力图》。
根因深挖：不一致样本人工复盘（1.5小时）
对当月所有IECV不一致样本，由AI产品经理+业务专家+算法工程师三方会审，确认是数据问题、提示词问题，还是模型架构问题。

所有检测结果，自动同步至共享看板。看板不是堆数据，而是用三色灯呈现：

绿色：所有指标正常，可安心运营；
黄色：1项指标预警，需在48小时内启动根因分析；
红色：≥2项指标预警或1项红色预警，立即触发熔断预案（如切换至规则引擎备用通道）。

这套SOP在某省级人社厅落地后，模型线上事故平均响应时间从72小时缩短至4.2小时，用户投诉率下降63%。关键在于：它把模糊的“模型好像不太灵了”，转化成了明确的“周二IECV不一致率升至28%，聚焦‘失业金申领’类问题”。

4.2 六大高频陷阱与破解方案

在帮23家客户部署手册的过程中，我们总结出六个90%团队都会踩的坑。它们不是技术难题，而是思维惯性导致的误操作：

陷阱1：用测试集当基线，导致“自我感觉良好”

现象：团队把模型上线前在测试集上的表现，当作永久基线。结果模型在真实数据上漂移了，但对比测试集仍“达标”。
破解：手册强制要求“动态基线”。基线必须是上线后连续30天的滚动均值。我们甚至开发了一个小工具，每天自动计算并更新基线值，旧基线自动归档。记住：基线不是起点，而是航标——它必须随洋流移动。

陷阱2：只测“会不会”，不测“敢不敢”

现象：大量检测聚焦在模型能否正确回答问题，却忽略它在面对模糊、矛盾、高风险问题时的应对策略。比如用户问“这个政策是不是快废止了？”，健康模型应答“政策有效期至2025年12月31日，目前无废止计划”，而钝化模型可能答“这个我不太清楚”。后者不是能力问题，是风险规避机制过度激活。
破解：手册第四章专门设计了“模糊性压力测试包”，包含30个刻意设计的模糊、矛盾、诱导性问题。必须每月运行一次，它才是检验模型“职业素养”的试金石。

陷阱3：把检测当终点，忘了干预才是目的

现象：团队花大力气建好检测系统，但预警来了没人管，或者只做表面修复（如调高温度参数）。
破解：手册配套《三级干预预案》：
- 一级（自动）：IECV不一致率>25% → 自动降权该意图类别的模型回答，提升规则引擎权重；
- 二级（半自动）：KTEM熵值超标 → 自动触发“术语专项重训”，只用该术语相关数据微调最后两层；
- 三级（人工）：RSSA红色预警 → 强制暂停该业务线所有AI服务，启动法务+业务+技术三方会审。
  干预动作必须在检测报告中明确标注，形成PDCA闭环。

陷阱4：忽视“人”的因素，把问题全甩给模型

现象：检测发现意图偏移，第一反应是“模型坏了”，却没检查运营人员是否在后台悄悄改了提示词，或业务部门是否更新了SOP但没同步给AI团队。
破解：手册要求所有检测报告，必须包含“人因核查栏”。例如IECV预警时，必须填写：“已确认上周无提示词变更（✓）”“已核对最新政策文件已入库（✓）”“运营后台无手动干预记录（✓）”。这个小栏位，把责任边界划得清清楚楚。

陷阱5：追求“全量检测”，导致资源浪费

现象：有团队想对每一条用户请求都跑全套检测，结果服务器直接卡死。
破解：手册采用“分层采样策略”：
- 全量监控：只做最轻量的IECV（规则通道几乎零成本）；
- 10%抽样：KTEM和RSSA，用分层随机法确保覆盖所有业务线；
- 1%深度扫描：CRT只针对TOP10高频问题。
  资源永远投在刀刃上——高频问题的稳定性，比长尾问题的绝对精度重要100倍。

陷阱6：把手册当银弹，期待一劳永逸

现象：部署完手册就束之高阁，认为从此高枕无忧。
破解：手册本身就是活的。我们要求每季度进行“手册健康度自检”：
- 检查现有检测项是否还覆盖新出现的业务场景（如新增“数字人民币”业务，就要补充相关术语）；
- 检查预警阈值是否需要调整（如业务量翻倍后，不一致率基线自然上升）；
- 检查是否有新探针可加入（如发现“模型开始频繁要求用户重复提问”，就新增“追问容忍度”指标）。
  手册不是终点，而是你和模型共同进化的路线图。

4.3 从检测到行动：一份真实的故障处理纪要

为了让你更直观感受手册如何落地，这里复盘一个真实案例——某市医保局“门诊慢特病认定”AI助手的降智事件。

时间：2024年3月18日（周一）上午10:15
预警触发：IECV快筛显示，“门诊慢特病”类问题不一致率从常态8%飙升至31%；RSSA显示，对“高血压”“糖尿病”等病种的风险提示强度SDC=0.38（红色预警）。

10:30-11:00 初步定位：

抽取10条不一致样本，发现模型将“申请高血压慢特病”全部识别为“查询高血压用药”；
查看RSSA样本，模型对“需定期复查肾功能”的提示，从“必须每3个月复查”弱化为“建议关注肾功能”。

11:00-12:00 根因深挖：

数据侧：检查3月15日入库的新版《高血压诊疗指南》，发现其中将“慢特病认定标准”章节标题改为“慢病管理建议”，导致模型训练时将该文档错误归类；
提示词侧：运营人员为提升用户体验，将原提示词“请严格依据《门诊慢特病管理办法》回答”改为“请用通俗易懂的语言解释相关政策”；
人因核查：确认无其他变更。

12:00-13:00 干预执行：

一级干预：IECV预警触发，自动将“慢特病认定”类问题路由至规则引擎（基于老版管理办法的正则库），准确率即时恢复至99%；
二级干预：KTEM检测到“高血压”“糖尿病”术语熵值超标，启动术语专项重训，仅用2小时完成；
三级干预：RSSA红色预警，暂停所有慢特病相关AI服务2小时，法务团队审核新版提示词。

15:00 复盘会议：

确认根本原因是“数据归类错误+提示词弱化”双重作用；
修订SOP：新增“政策文档入库前，必须经AI团队标注校验”；
更新手册：在“提示词管理规范”中，明确禁止使用“通俗易懂”等模糊指令，改为“使用《医保服务用语规范》第3.2条表述”。

结果：3月19日，所有指标回归绿色。用户投诉量下降82%。这次事件没有成为危机，反而推动了医保局AI治理体系的升级。这就是手册的价值——它不保证模型永不犯错，但保证错误发生时，你能在最短时间内，用最确定的方式，把它扳回正轨。

5. 常见问题与排查技巧实录：一线工程师的私藏笔记

5.1 “检测结果忽高忽低，是不是探针不准？”——论数据噪声的优雅处理

这是新手最常问的问题。比如IECV不一致率，周一25%，周二12%，周三33%……看起来像模型在抽风。其实90%的情况，是数据噪声在捣鬼。

噪声来源与对策：

用户输入噪声：市民发来“查一下我的养…老…金…”，中间夹杂省略号、空格、错别字。规则通道可能匹配失败，而模型靠上下文猜对了，造成“假不一致”。
→对策：在规则通道前加“输入净化层”：统一删除多余空格、替换全角字符、纠正高频错别字（如“养劳金”→“养老金”）。手册附录提供了一份政务高频错别字映射表。
模型随机性噪声：即使相同Prompt，模型因temperature>0也会有波动。KTEM熵值单日跳变，未必是真漂移。
→对策：KTEM必须取“3次运行均值”，且只对连续2天超标才预警。我们实测，单日波动被过滤后，误报率从38%降至6%。
业务节奏噪声：月底、季初、政策发布日，用户问题结构天然变化。某市公积金中心发现，每月25日后“贷款额度计算”类问题激增，IECV不一致率必然上升——因为用户常问“我还能贷多少”，而模型训练数据中这类预测性问题较少。
→对策：手册要求所有指标必须“按业务周期归一化”。例如公积金场景，IECV基线要分“常规期”和“月末冲刺期”两套，系统自动切换。

终极心法：把检测结果看作“心电图”，单个波峰波谷没意义，要看趋势、看形态、看与其他指标的关联。当IECV飙升的同时KTEM也飙升，那才是真危机；如果IECV飙升但RSSA纹丝不动，大概率只是用户输入质量波动。