让大模型学会自我检查！Python实现AI回答质量评估、错误识别与自动重试机制

一、引言：单次调用的大模型，本质上是一个不可靠函数

把 LLM 接进生产系统的人，迟早都会撞上同一堵墙：模型的单次输出是不可信的。

它可能在 JSON 里塞一段 Markdown 代码块，让下游的json.loads当场爆炸；可能自信地编造一个不存在的 API 参数；可能在你要它"只回答三个要点"时洋洋洒洒写了一千字；也可能在你明确给了参考资料的情况下，仍然把资料里没有的数字写进结论。这些问题在 Demo 阶段是"偶尔抽风"，在生产阶段就是 P0 故障。

传统的工程解法是"重试"——失败就再调一次。但对大模型来说，盲重试是最糟糕的策略之一：温度不变、提示词不变，模型大概率会以极高的相似度复现同一个错误。你付出了三倍 token 成本，换来三个一样的坏答案。

真正有效的做法，是把"生成"从一次性动作改造成一个闭环控制系统：生成 → 评估 → 诊断 → 带反馈重试。这篇文章会拆解这套机制的核心原理，并用 Python 给出一份可直接落地的实现。

二、核心原理：把生成变成闭环控制

2.1 三个必须解耦的组件

一个自检系统的最小闭环由三部分组成：

• Evaluator（评估器）：回答"这个答案好不好"，输出可比较的分数与通过判定；
• Diagnoser（诊断器）：回答"哪里不好、为什么不好"，输出结构化的错误类型与定位信息；
• Retry Policy（重试策略）：回答"接下来怎么改"，决定是否重试、如何修改提示词、用什么参数。

工程上最常见的失败，是把这三者揉进一个"你检查一下有没有问题"的提示词里。结果模型回一句"回答基本正确，可以进一步优化"，信息量约等于零，既无法驱动重试，也无法做监控告警。

为什么一定要解耦？因为这三者的输入输出契约完全不同。评估器的输出要能横向比较（不同 case、不同时间点的分数得可比），所以它必须是数值稳定的；诊断器的输出要能被人和程序同时消费，所以它必须是结构化的枚举与定位；重试策略是纯程序逻辑，不该再依赖模型判断——一旦让模型来决定"要不要重试"，你就把控制流的确定性也交了出去，故障时根本无法复盘是"模型判断错了"还是"策略本身错了"。解耦之后，任何一环出问题都能被单独定位、单独替换、单独测试。

2.2 评估信号有三个层次，成本差一个数量级

关键原则是：能用 L1 解决的，绝不交给 L2。JSON 解析失败这种事，json.loads一毫秒就能判定，让模型去评分纯属浪费钱，而且模型对格式错误的判定远不如解析器可靠。

这里还有一条容易被忽略的工程细节：L1 和 L2 的评估结果需要合并，而不是二选一。正确的顺序是"先 L1 短路，L2 再补语义"，即 L1 命中致命错误时直接返回判决、不再调用评估模型；L1 通过后，L2 只负责语义层面的质量打分。这样既省钱，又避免了两套信号互相打架——比如 L1 认为 JSON 合法、L2 却因为内容质量差给出低分，两者在语义上并不矛盾，可以并存。

另外，L1 的检查项应当尽量穷举可机械验证的约束，而不是只盯着 JSON。常见的 L1 检查包括：长度区间、是否包含禁用词、是否使用了指定语言、引用的文档 ID 是否真实存在于检索结果里、生成的代码能否通过compile()、正则能否匹配出要求的字段。这些检查加起来往往只有几十行代码，却能把下游的脏数据挡掉一大半。

2.3 反馈必须可执行：错误分类法比分数更重要

一个 0.3 分的差值，对修复毫无指导意义。真正驱动重试的，是错误类型（Error Type）。实践中可收敛为六类：

• FORMAT：结构化输出不合规（最常见，也最好修）；
• INSTRUCTION：违反显式指令（语言、长度、角色、禁用词）；
• HALLUCINATION：无据可依的具体断言、数字、引用；
• INCOMPLETE：漏答子问题、覆盖不全；
• REASONING：推理链断裂或自相矛盾；
• REFUSAL：过度拒答。

有了分类，重试策略就能分化：FORMAT直接把解析器的报错原文回灌给模型；HALLUCINATION要求模型"删除所有参考资料中未出现的具体数字，或明确标注为推测"；REFUSAL则应该软化提示词而不是加热温度。

为什么错误分类比分数更重要？因为分数只回答"要不要重试"，分类才回答"怎么重试"。如果只有分数，策略层能做的唯一动作就是"再试一次"，那又退回到了盲重试。而一旦有了分类，每一类都能对应一句明确的、写死的、经过验证的修复指令——修复指令是工程资产，是可以在离线集上反复打磨的，而"分数"不是。

还有一条经验：错误分类的粒度要克制。分类太粗（比如只有"好/坏"）无法驱动策略，分类太细（比如把 FORMAT 拆成括号缺失、引号缺失、逗号多余等十几类）则会让评估器本身变得不稳定，模型经常在相似类别间摇摆。六到八类是实践中的甜点区，既能覆盖绝大多数场景，又能让评估器的判定保持较高一致性。

2.4 重试不是重复，而是"策略升级"

我推荐的重试阶梯是：

1. 第 1 次：原始提示词，temperature=0（追求确定性）；
2. 第 2 次：注入上一轮的结构化批评（Critique & Revise），温度微升至 0.3；
3. 第 3 次：切换提示词策略（如强制 CoT、强制"先列要点再展开"、拆分任务），温度 0.7。

同时必须配预算控制：最大尝试次数、总 token 上限、超时熔断。没有预算约束的自检系统，会在长尾 case 上把成本放大到失控。

这个阶梯背后的逻辑是逐级引入更多的随机性与更强的约束。第 1 次温度最低，是为了让"能一次答对的 case"稳定答对，避免无谓波动；第 2 次注入批评、轻微升温，是因为多数错误靠"知道自己错在哪"就能修好，升温只是为了跳出上一轮的死循环；第 3 次才动用重武器——换提示词骨架、拆任务、强制推理链，同时把温度拉高以探索和之前完全不同的输出分布。如果第 3 次还是失败，正确做法往往是放弃并且兜底，而不是无限加码。

还有一个隐藏的坑：重试的对话历史会迅速膨胀。每轮都追加"上一轮的答案 + 批评"，到第三轮上下文里可能塞了五六份完整答案，token 成本翻倍不说，还会分散模型注意力。正确的做法是只保留最近一轮的批评摘要（fix_hint），把历史轮次的完整答案丢弃。

三、实战：用 Python 搭一个自检重试引擎

下面用一个"带参考资料问答 + 强制 JSON 输出"的任务作为例子，完整实现评估器与重试引擎。

3.1 第一步：定义结构化评估结果

from__future__importannotationsfromenumimportEnumfrompydanticimportBaseModel,FieldimportjsonclassErrorType(str,Enum):FORMAT="format"INSTRUCTION="instruction"HALLUCINATION="hallucination"INCOMPLETE="incomplete"REASONING="reasoning"REFUSAL="refusal"classVerdict(BaseModel):score:float=Field(ge=0,le=10,description="整体质量分")passed:boolerror_types:list[ErrorType]=Field(default_factory=list)issues:list[str]=Field(default_factory=list,description="具体、可定位的问题，每条不超过 50 字，禁止空泛评价",)fix_hint:str=Field(default="",description="给下一轮重试的一句话修正指令")defprogrammatic_checks(answer:str,expect_json:bool=True)->Verdict|None:"""L1 层：确定性校验。命中则短路，不调用评估模型。"""ifexpect_json:text=answer.strip()iftext.startswith("```"):# 模型最爱的 Markdown 包裹text=text.strip("`").split("\n",1)[-1].rsplit("```",1)[0]try:json.loads(text)exceptjson.JSONDecodeErrorase:returnVerdict(score=0.0,passed=False,error_types=[ErrorType.FORMAT],issues=[f"JSON 解析失败：{e.msg}(line{e.lineno}col{e.colno})"],fix_hint="只输出单个合法 JSON 对象，不要 Markdown 代码块、不要任何解释文字。",)iflen(answer.strip())<10:returnVerdict(score=1.0,passed=False,error_types=[ErrorType.INCOMPLETE],issues=["答案长度异常，疑似被截断"],fix_hint="完整回答问题，不要中途停止。",)returnNone# 无需短路，交给 L2

这段代码的价值在于成本分层：绝大多数格式类错误在本地一毫秒内被拦截，并且json解析器给出的line/col信息，比任何模型评价都更精确、更适合回灌给模型做修复。

注意Verdict用 Pydantic 定义，而不是裸dict。这带来两个实际好处：一是字段类型约束（score被限制在 0～10）能在解析阶段就拦住评估器自己的胡说八道；二是model_validate_json抛出的异常是明确的、可被try/except捕获的，避免了"评估结果格式不对导致主流程崩溃"这种低级但高频的事故。

另外，programmatic_checks里那段剥 Markdown 的代码看似随便，其实很关键：模型包不包代码块的概率相当高，如果每次都对带 ```的输出判 FORMAT 失败，会造成大量无意义的重试。在能宽容的地方宽容，在必须严格的地方严格，是 L1 校验的设计准则——剥壳属于"宽容"，而剥壳后仍不合规则属于"严格"。

3.2 第二步：带 Rubric 的 LLM 评估器

importosfromopenaiimportAsyncOpenAI client=AsyncOpenAI(base_url=os.getenv("LLM_BASE_URL"),api_key=os.getenv("LLM_API_KEY"))JUDGE_MODEL=os.getenv("JUDGE_MODEL","gpt-4o-mini")RUBRIC="""你是严格的答案质检员，请依据以下量规评估【待检答案】： 1. 事实性(0-3)：是否存在参考资料中不存在的具体断言、数字、引用； 2. 指令遵循(0-3)：是否满足用户显式要求（格式、语言、长度、角色）； 3. 完整性(0-2)：是否覆盖问题的全部子问题； 4. 自洽性(0-2)：推理是否连贯、有无前后矛盾。 判定规则：score >= 8 且无致命问题（事实编造 / 格式非法 / 拒答）时 passed 为 true。 issues 必须具体到可修改的位置，禁止输出"不够好""可以优化"这类空泛评价。 """asyncdefjudge(question:str,answer:str,context:str="")->Verdict:resp=awaitclient.chat.completions.create(model=JUDGE_MODEL,temperature=0,# 评估必须稳定，绝不能采样messages=[{"role":"system","content":RUBRIC},{"role":"user","content":(f"# 用户问题\n{question}\n\n"f"# 参考资料\n{contextor'（无）'}\n\n"f"# 待检答案\n{answer}")},],response_format={"type":"json_object"},)raw=resp.choices[0].message.contentor"{}"try:returnVerdict.model_validate_json(raw)exceptException:# 评估器本身也会出错，必须兜底，绝不能让它把主流程拖死returnVerdict(score=5.0,passed=False,error_types=[ErrorType.REASONING],issues=["评估器输出不可解析，降级为保守判定"],fix_hint="保持与上一轮相同的输出结构，重新作答。",)

这里有三处值得展开的细节。

第一，temperature=0是评估器的硬性要求。很多人会顺手沿用生成时的温度，结果同一个答案被评估两次得到 7 分和 9 分，阈值判断随之抖动，系统变得"神经质"。评估是判断任务而非创作任务，必须尽量消掉采样随机性。

第二，response_format={"type": "json_object"}只是尽力而为，不是保证。不同厂商、不同模型对结构化输出的支持程度差异很大，有的会返回带 Markdown 的 JSON，有的会把分数写成"8分"。所以try/except兜底不是多此一举，而是必需品。兜底时选择passed=False是保守策略：宁可多试一次，也不要放过一个未经确认的答案。

第三，Rubric 的分项权重是有意设计的。事实性 3 分 + 指令遵循 3 分占了满分 10 分的六成，是因为这两项直接对应生产事故；完整性和自洽性各 2 分，属于"体验问题"。如果你的场景里格式合规是生死线，那就该把 FORMAT 提到致命问题里，让它的权重凌驾于分数之上——分数只是兜底，致命项才是一票否决。

3.3 第三步：重试策略——把错误类型翻译成修复指令

# 每一类错误对应一句经过验证的修复指令。它是工程资产，不要随手写。REPAIR_INSTRUCTIONS:dict[ErrorType,str]={ErrorType.FORMAT:("上一轮输出不是合法 JSON。请只输出一个 JSON 对象，""不要 Markdown 代码块，不要前后缀说明文字。"),ErrorType.INSTRUCTION:("上一轮违反了显式指令。请重新检查用户对格式、语言、长度、角色的全部要求，""逐条对照后再作答。"),ErrorType.HALLUCINATION:("上一轮包含参考资料中不存在的具体断言或数字。""请删除所有无据可依的具体数字，或明确标注为「推测」，""并在每个事实性结论后用 [n] 标注引用来源编号。"),ErrorType.INCOMPLETE:("上一轮漏答了部分子问题。请先把用户问题拆成子问题清单，""逐条作答，确保无遗漏。"),ErrorType.REASONING:("上一轮推理存在断裂或前后矛盾。请先写出推理步骤，""再给出结论，确保每一步都能由前一步推出。"),ErrorType.REFUSAL:("该请求合法且资料充足，不应拒绝。请基于已有参考资料直接作答，""对于确实无法确定的部分，明确说明「资料未涵盖」。"),}# 阶梯式重试配置：(温度, 是否注入批评)RETRY_LADDER:list[tuple[float,bool]]=[(0.0,False),# 第 1 次：原始提示，追求确定性(0.3,True),# 第 2 次：注入批评，Critique & Revise(0.7,True),# 第 3 次：升温探索，同时叠加修复指令]defbuild_retry_suffix(verdict:Verdict,attempt:int)->str:"""把上一轮的结构化批评，翻译成下一轮提示词尾部的修复指令。"""ifnotverdict.error_typesandnotverdict.fix_hint:return""lines=["","---","## 上一轮回答的质检反馈（必须修复）"]foretindict.fromkeys(verdict.error_types):# 去重且保持顺序lines.append(f"- [{et.value}]{REPAIR_INSTRUCTIONS[et]}")ifverdict.fix_hint:lines.append(f"- 额外要求：{verdict.fix_hint}")ifattempt>=3:lines.append("- 本轮请改变作答方式：先列出回答要点提纲，再逐条展开，""最后仅输出要求的 JSON。")return"\n".join(lines)

dict.fromkeys那行是个小技巧：评估器可能同时报出FORMAT和HALLUCINATION，去重后既能避免重复指令稀释注意力，又能保持稳定的顺序，方便日志比对。

3.4 第四步：闭环引擎与预算熔断

importasyncioimporttimefromdataclassesimportdataclass@dataclassclassBudget:max_attempts:int=3max_total_tokens:int=20000timeout_s:float=90.0used_tokens:int=0defconsume(self,n:int)->None:self.used_tokens+=ndefexhausted(self)->bool:returnself.used_tokens>=self.max_total_tokensclassSelfCheckEngine:"""生成 → 评估 → 诊断 → 带反馈重试 的闭环。"""def__init__(self,generate,budget:Budget|None=None):self.generate=generate# async (prompt, temperature) -> (text, tokens)self.budget=budgetorBudget()asyncdefrun(self,question:str,context:str="",base_prompt:str="")->tuple[str,Verdict]:deadline=time.monotonic()+self.budget.timeout_s last_answer,last_verdict="",Verdict(score=0.0,passed=False)forattempt,(temp,use_critique)inenumerate(RETRY_LADDER,start=1):ifattempt>self.budget.max_attemptsorself.budget.exhausted():breakiftime.monotonic()>deadline:# 超时熔断breaksuffix=build_retry_suffix(last_verdict,attempt)ifuse_critiqueelse""prompt=(f"{base_prompt}\n\n# 用户问题\n{question}\n\n"f"# 参考资料\n{contextor'（无）'}{suffix}")text,tokens=awaitself.generate(prompt,temp)self.budget.consume(tokens)last_answer=text# L1 优先短路，命中就不调用评估模型verdict=programmatic_checks(text,expect_json=True)ifverdictisNone:verdict=awaitjudge(question,text,context)last_verdict=verdictifverdict.passed:returntext,verdict# 预算耗尽：返回当前最好结果，并由调用方决定是否降级returnlast_answer,last_verdict

调用侧的用法：

asyncdefmain():engine=SelfCheckEngine(generate=my_llm_call,budget=Budget(max_attempts=3))answer,verdict=awaitengine.run(question="这款相机的续航是多少？请以 JSON 返回。",context="产品手册：电池容量 5200mAh，连续拍摄约 4 小时。",base_prompt="你是客服助手，只依据参考资料作答，输出单个 JSON 对象。",)print("passed =",verdict.passed," score =",verdict.score)print(answer)

整个引擎只有几十行，却同时具备了：格式错误的本地拦截、语义质量的模型评估、可执行的反饋回灌、阶梯式重试，以及 token 与超时的双重熔断。

四、常见问题 FAQ

Q1：评估器自己会不会出错？要不要再给评估器加一个评估器？

会，但不要无限套娃。评估器的错误率远低于生成器，再叠一层评估成本翻倍而收益递减。正确做法是：给评估器加确定性约束（结构化输出、温度 0、分项打分），并在离线集上统计它与人工标注的一致率。一旦一致率低于阈值，就去改 Rubric，而不是再加一层。

Q2：score阈值定多少合适？

不要拍脑袋定 8。正确做法是收集 50～100 条带人工标注的样本，画出分数分布，找到能同时满足"漏检率低"和"重试率可接受"的切点。经验上多数场景在 7～8 之间，但格式合规这类硬约束应该跳过分数、直接一票否决。

Q3：为什么评估要用另一个模型，而不是让生成模型自评？

自评存在明显的自我偏好偏差——模型倾向于认为自己的输出是对的。实践中更稳的组合是"生成用快模型、评估用强模型"，或者至少用不同的系统提示词与采样配置，制造一点"视角差异"。如果成本受限必须同模型自评，那一定要把温度设为 0 并把评估提示词写得极其严格。

Q4：重试几次是极限？

三次。第一次追求确定性，第二次注入批评，第三次换策略。第四次以后的边际收益极低，更多时候是在烧钱。超过三次仍失败，说明问题不在生成，而在于任务本身表述不清或资料不足——这时应该走兜底话术或人工介入，而不是继续重试。

Q5：评估会显著拖慢响应吗？

会，串行评估大约让延迟增加 30%～80%。优化手段有三：一是尽量让 L1 命中（零成本）；二是把 L1 与 L2 的调用并行化（L1 结果出来前的这段时间可以并发发起 L2）；三是对低风险场景抽样评估（比如只评估 20% 的请求），而不是全量。

Q6：异步并发下Budget会不会被多个请求串用？

会，这也是常见 bug。Budget必须每个请求实例化一个，绝不能挂在全局。如果需要做全局配额（比如整站每分钟 token 上限），那要另建一个信号量或令牌桶，和单次请求的Budget分开管理。

五、踩坑与优化建议

坑 1：把评估结果直接透传给用户。issues是给系统和开发看的内部语言，可能包含"疑似被截断""评估器输出不可解析"这类让人困惑的信息。对外必须做一层翻译，只暴露温和的重试提示或直接返回兜底话术。

坑 2：忽略评估调用本身的 token 消耗。评估动辄几十上百 token，是"看不见的成本"。建议把生成 token 与评估 token 分开打点，否则你会在账单上看到"生成成本正常，总成本翻倍"的诡异现象。

坑 3：response_format一开就以为万事大吉。不同厂商对结构化输出的支持差异巨大，有的要求提示词里同时出现 “JSON” 字样，有的在长上下文下会偷偷退化成普通文本。务必保留解析失败的兜底路径。

坑 4：修复指令写得像人话但不可执行。“请更准确一些”"注意质量"这类指令对模型几乎无效。有效的修复指令必须满足三点：指向明确（哪一句、哪个字段）、动作明确（删除/补充/改写）、验收明确（改完长什么样）。

坑 5：没有记录失败样本。每一次passed=False都是一条宝贵的训练与调优数据。建议把question / answer / verdict / attempt全量落库，定期分析错误分布——你会发现 80% 的失败集中在两三类错误上，修好那两三类，整体通过率立刻上一个台阶。

优化建议 1：给致命错误单独设"一票否决"。无论分数多高，只要出现HALLUCINATION或未标注的引用，直接判不通过。分数是软约束，致命项是硬约束。

优化建议 2：把高频修复指令前置到系统提示里。如果某类错误反复出现，说明它不是"偶发失误"而是"提示词缺陷"。这时应该把修复指令从重试后缀提升为原始系统提示的一部分，从源头上减少重试。

优化建议 3：监控重试率而非只看准确率。重试率突然升高，往往意味着上游检索质量下降、上游 promopt 变更或模型版本更新。它是最灵敏的异常信号之一。

优化建议 4：给评估器做小样本回归测试。准备一组固定答案与期望判定，每次修改 Rubric 后跑一遍，确保没有把原本能通过的 case 判成失败。这条实践能帮你避免"为了修 A 类错误而引入 B 类误伤"。

六、小结

单次调用的大模型是不可靠函数，但"可靠"不是靠换更强的模型实现的，而是靠把生成包进一个闭环：用 L1 拦掉机械错误，用 L2 判断语义质量，用错误分类驱动差异化重试，用预算熔断守住成本。

这套机制的核心洞见只有一句话：反馈必须是结构化、可分类、可执行的。

更多硬核网安与AI工具包，请扫码获取完整源码！
当你把一句"回答得不太好"替换成"[hallucination]删除参考资料中不存在的数字，并标注引用来源"，你就把一次祈祷式的重试，变成了一次有方向的修复。
了修 A 类错误而引入 B 类误伤"。

六、小结

单次调用的大模型是不可靠函数，但"可靠"不是靠换更强的模型实现的，而是靠把生成包进一个闭环：用 L1 拦掉机械错误，用 L2 判断语义质量，用错误分类驱动差异化重试，用预算熔断守住成本。

这套机制的核心洞见只有一句话：反馈必须是结构化、可分类、可执行的。

[CSDN_IMG_FOOTER]
[CSDN_IMG_FOOTER]
[CSDN_IMG_FOOTER]
[CSDN_IMG_FOOTER]

更多硬核网安与AI工具包，请扫码获取完整源码！
当你把一句"回答得不太好"替换成"[hallucination]删除参考资料中不存在的数字，并标注引用来源"，你就把一次祈祷式的重试，变成了一次有方向的修复。