别迷信 LLM 的“一次性正确”：在生产环境构建“验证-修正”循环 (Verification Loop)

在 AI Lab 的交付现场，很多开发者习惯于追求一个“完美的 Prompt”，试图通过不断增加指令细节，让模型在一次推理中就给出 100% 正确的答案。

但在处理复杂逻辑（如多步推理、复杂数据提取或代码生成）时，这种做法往往会触碰 LLM 的能力上限。无论 Prompt 多么精妙，模型依然会有概率在某个关键步骤产生幻觉或逻辑跳跃。

核心痛点：单次推理的不可靠性

单次推理（Single-pass Inference）最大的问题在于：模型没有机会自我审视。 当它在第二步产生一个微小的错误时，后续的所有步骤都会基于这个错误继续推演，最终导致结果彻底崩盘。

在生产环境中，我们不能依赖运气。我们需要将“生成”与“验证”解耦，构建一套 Verification Loop（验证-修正循环）。

Verification Loop 的工程实现模式

一个成熟的验证循环通常包含三个阶段：生成 (Generate) $\rightarrow$ 验证 (Verify) $\rightarrow$ 修正 (Correct)。

1. 生成阶段 (Generate)

模型根据输入产生初步结果 $R_1$。此时不需要追求极致的完美，而应追求结构化的输出（如 JSON），以便于后续验证。

2. 验证阶段 (Verify)

这是最关键的一步。验证不应由原模型简单地问一句“你确定对吗？”，而应采用以下三种硬核手段：
- 确定性校验 (Deterministic Check)：例如，如果结果是 SQL，则尝试在沙箱中执行；如果结果是 JSON，则校验 Schema 和必填字段。
- 交叉验证 (Cross-Verification)：使用另一个独立且更强的模型（或同一模型的不同 Temperature 设置）对 $R_1$ 进行审计，寻找逻辑漏洞。
- 反向推演 (Reverse Reasoning)：要求模型将结果 $R_1$ 反向推导回原始输入 $\text{Input}$。如果推导不一致，则判定为错误。

3. 修正阶段 (Correct)

一旦验证失败，系统不应直接报错给用户，而是将 [原始输入 + 错误结果 + 具体的验证失败原因] 作为新的上下文重新喂给模型。
指令示例：“你之前的输出在第 3 步出现了逻辑矛盾（具体原因：...），请重新审视并修正。”

实战案例：复杂报表提取 Agent

我们在开发一个从非结构化 PDF 中提取财务数据的 Agent 时发现，单次提取的准确率仅为 82%。其中大部分错误源于模型将“去年”和“今年”的数据行搞混。

我们引入了 Verification Loop：
1. 生成：提取数据并输出 JSON 表格。
2. 验证：编写一个简单的 Python 脚本计算表格中的各项总和是否等于 PDF 中标注的总计金额（确定性校验）。
3. 修正：如果总额不符，将差异金额和相关行号反馈给模型重新提取。

经过这一循环，最终交付的准确率提升至 98%，且响应时间仅增加了约 2 秒。

给工程团队的建议

不要试图通过增加 Prompt 的长度来消除幻觉，因为 Token 的增加会带来更多的噪声。相反，你应该把精力花在构建一个高效的 Verifier（验证器） 上。

记住：一个平庸的模型 + 一个强大的验证器 $\gg$ 一个顶尖的模型 + 一个简单的 Prompt。