LLM 题解去幻觉：证明链比漂亮解释更重要

LLM 题解去幻觉：证明链比漂亮解释更重要

一、题解幻觉通常很有迷惑性

LLM 写算法题解时，最危险的不是语气不自信，而是解释非常顺，却在关键逻辑上错了。它可能把贪心条件说得像定理，却没有交换论证；也可能给出动态规划状态，却漏掉初始化边界。

题解去幻觉的核心，是把自然语言解释拆成可验证的证明链。一个合格题解应该说明状态定义、转移依据、边界条件、正确性理由和复杂度。缺任何一环，都不能只靠“看起来合理”放过。

二、证明链要结构化

flowchart TD
  A[题意解析] --> B[核心不变量]
  B --> C[算法步骤]
  C --> D[正确性证明]
  D --> E[复杂度分析]
  E --> F[边界用例]

不同算法需要不同证明重点。贪心题要证明局部选择不会破坏全局最优。动态规划题要证明状态覆盖全部情况且没有重复。图论题要证明遍历顺序或松弛规则的正确性。证明链不能只有结论。

结构化之后，系统可以逐项检查。没有不变量，就提示证明不足；没有边界用例，就提示验证不完整；复杂度和代码结构不匹配，就提示重新分析。

三、代码和解释要互相校验

def extract_features(code: str) -> dict:
    return {
        "uses_sort": "sort(" in code or ".sort()" in code,
        "uses_heap": "heapq" in code,
        "nested_loop": "for" in code and code.count("for") >= 2,
    }

代码特征可以反向校验解释。解释说没有排序，但代码里调用了 sort，复杂度至少要考虑排序成本。解释说使用堆，代码里却没有优先队列结构，也要标记可疑。

这类检查不需要完美理解代码，只要抓常见矛盾就很有价值。题解幻觉往往不是深奥错误，而是解释和实现之间对不上。

claim_check:
  claim: "时间复杂度为 O(n)"
  evidence: "代码包含排序"
  status: suspicious

四、反例搜索要参与验证

如果题解声称使用贪心，系统可以针对贪心条件生成反例。比如区间选择、字符串匹配、数组划分，都能构造小规模穷举，对比暴力解和生成解。小输入反例往往最能暴露逻辑漏洞。

反例搜索不只用于代码，也能用于解释。解释里的不变量如果无法覆盖某些状态，就要求模型补充证明或承认适用范围。题解不是背模板，必须能经得起追问。

还可以引入“声明抽取”。先让模型把题解里的关键结论抽成列表，再逐条验证。比如“窗口左端只会右移”“每条边最多松弛一次”“排序后相邻元素即可比较”。这些声明如果无法被代码或数学理由支撑，就标记为待复核。去幻觉不是让模型少说话，而是让每句话都有来源。

版本管理也很重要。换模型、换提示词或换题解模板后，历史题解要重新抽样验证。某个版本可能更会写长解释，却更容易漏边界；另一个版本可能代码更稳，但证明更薄。没有版本对比，就很难判断优化是否真实。

最后，去幻觉结果要反馈给生成阶段。常见错误如复杂度低估、贪心证明缺失、边界不完整，可以反向写进生成提示和审查清单。验证系统不能只做裁判，也要帮助生成器少犯同类错误。

对高风险题型，可以强制二次生成证明。第一轮生成代码，第二轮只根据代码和题目生成证明，再比较两轮解释是否一致。如果两轮对核心性质说法不同，就说明题解需要人工或规则复核。

五、总结

LLM 题解去幻觉要把解释拆成证明链，并用代码特征、复杂度校验和反例搜索交叉验证。

漂亮解释不是正确性证明。算法文章真正可靠的地方，在于每个结论都能被代码、用例或逻辑推导支撑。