这次我们来看一个很有意思的 LLM 使用场景让大模型在你完全不熟悉的专业领域里生成一个反例counterexample。反例是数学、逻辑和工程验证里最锋利的工具。想证明一个命题不成立不一定需要穷举所有情况只要找到一个符合条件的反例就够了。但这件事一旦交给 LLM就会出现一个很尴尬的局面模型给出的反例往往看起来头头是道而你如果对这个领域完全不熟根本无法判断它到底是一个真实反例还是模型一本正经地幻觉hallucination出来的。更麻烦的是有些时候 LLM 生成的反例确实是真的。大模型在训练语料里见过大量数学推导、领域规则和代码逻辑它有概率组合出连提问者本人都没能找到的反例。这带来一个双刃剑效果你获得了超出自己专业能力的候选答案却同时失去了用自身经验判断真伪的能力。这篇文章不打算空谈 LLM 的推理能力而是聚焦三个可落地的主题怎么调用 LLM 生成反例如何在外挂验证器的帮助下判断反例是否成立以及如何把整个流程做成接口化和批量化的流水线。1. LLM 生成反例的能力速览与核心限制1.1 核心能力速览能力项说明核心能力对给定命题或规则生成候选反例并给出解释模型形态通用大语言模型 API或本地开源权重模型典型部署云端 API / Ollama / vLLM 等 OpenAI 兼容服务显存需求本地推理取决于模型规模与量化方式需按实际测试纯 API 调用无显存要求是否支持 CPU本地小模型可以 CPU 推理速度较慢是否支持 API支持一般通过 /v1/chat/completions 兼容接口是否支持批量任务支持需要自行实现任务列表、并发控制与重试外部验证器可接入 SymPy、Z3、LEAN 等工具做独立验证适合场景科研假设筛查、命题边界测试、代码或算法边界分析主要风险幻觉反例、专业知识误判、验证链缺失这张表格里的重点是最后两行。LLM 在这里的角色是“反例候选生成器”而不是“真伪裁判”。你真正依赖的是表格里的外部验证器以及你自己设计的那条验证链路。所以判断一个 LLM 反例生成方案好不好不只是看模型聪明不聪明更要看验证环节能不能独立地把反例确认下来。1.2 为什么这个场景值得关注反例生成并不是新玩法数学家和工程师一直在做。真正被 LLM 改变的是门槛。过去你想在一个陌生领域里找出某个命题的反例必须先理解这个领域的符号体系、定理背景和计算规则否则连问题都问不出来。现在LLM 能根据你一句普通的自然语言描述直接产出候选反例。这本质上是一种“专业能力外溢”模型的训练数据覆盖了远超单个人类专家的知识面。但专业能力外溢的另一面是“判断力缺位”。当反例真的跑进了你完全不懂的领域你既没有能力确认它也没有能力解释它。此时如果不引入外部验证手段整条链路的可信度就会归零。这篇文章后续的所有流程本质上都是在解决“如何在不懂专业知识的前提下仍然能确认一个反例是否合法”的工程问题。2. 适用场景与使用边界2.1 适合谁来用第一类人是正在做科研假设验证的研究人员。你可以把论文里读到的定理、猜想、边界条件交给 LLM让它快速产出几个“可能推翻命题”的候选再用符号计算脚本复核。第二类人是工程师尤其是写框架、写规则引擎、写复杂算法的工程师。你手里往往有一堆隐含假设例如“所有订单都必须有支付时间”“所有 ID 都是正整数”“所有数组都非空”这些假设到底成不成立可以批量丢给 LLM 找反例。第三类人是技术决策者想快速了解一个陌生技术方案是否在边界条件下成立LLM 的反例可以给你一张“需要额外调研”的候选清单。2.2 适合解决什么问题用它来验证命题边界是最合适的场景。比如你设计了一个缓存策略假设“只要 key 前缀相同过期时间就相同”这个假设在某些组合条件下可能被打破。LLM 虽然没有跑过你的系统但它见过大量类似的分布式系统配置能猜出几个高风险反例。这类任务的特点是可快速验证、不依赖严格证明、失败成本低。用 LLM 生成的候选反例去指导重点测试可以大幅缩小排查范围。2.3 不适合什么场景正式数学证明不适合因为 LLM 的输出不是形式化证明任何依赖“模型说成立就成立”的流程都有风险。涉及真实产品、真实用户数据的高风险决策也不适合尤其在医疗、法律、金融风控等领域。另外如果反例的验证成本极高例如需要跑几天的仿真或者做真实物理实验那 LLM 生成的候选就只能作为参考不能作为最终结论。还有一类场景要格外慎重如果你让 LLM 针对某个真实系统寻找攻击性反例必须确认自己有合法的测试授权且只用于防御性验证。2.4 版权、隐私与合规边界反例本身是中性信息但生成过程可能触及训练语料中的既有内容。如果你正在撰写论文或专利最好把“LLM 生成候选反例、外部验证器确认”这个过程写进方法部分确保学术规范。不要把未脱敏的业务数据、用户隐私、内部代码片段塞进提示词尤其是调用云端 API 时。涉及人脸、声音、商业机密或未公开技术方案的内容要优先选择本地部署模型或对输入做彻底脱敏。3. 环境准备与前置条件3.1 通用检查清单无论你走云端 API 还是本地推理建议先确认以下环境项。这不是某个具体项目的硬性要求而是一套通用检查清单按本机实际情况调整版本。Python 3.9 及以上建议使用虚拟环境或 conda 环境。pip 或 conda 包管理器。云端调用准备 API Key、接口地址、目标模型名称。本地推理准备 Ollama 或 vLLM以及充足的磁盘空间。外部验证安装 sympy、z3-solver、openai 等 Python 包。GPU 可选。本地跑小模型没有 GPU 也能跑但速度会明显变慢。3.2 安装验证工具下面这条命令安装的是通用依赖。openai 用于调用 OpenAI 兼容接口sympy 用于符号计算验证z3-solver 用于约束求解验证。pip install openai sympy z3-solver装完之后先用 Python 确认导入正常import openai import sympy import z3 print(openai imported) print(sympy version:, sympy.__version__) print(z3 imported)如果三者都能正常导入说明环境基本就绪。接下来只需要确定模型服务从哪里来。4. 部署与启动方式API、Ollama 与 vLLM4.1 方式一直接调用云 API如果不想管显存、GPU、模型文件直接使用云端 API 是最快的方式。下面的代码是 OpenAI 兼容接口的通用写法具体模型名、接口地址需要按你实际使用的服务替换。from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlhttps://api.example.com/v1 # 替换为实际服务商地址 ) response client.chat.completions.create( modelYOUR_MODEL_NAME, messages[ {role: system, content: 你是一个严谨的数学检验助手。}, {role: user, content: 判断命题是否成立不成立则给出反例 对所有正整数 nn^2 n 41 都是素数。}, ], temperature0.2, max_tokens1024 ) print(response.choices[0].message.content)这段代码里的YOUR_API_KEY、base_url、YOUR_MODEL_NAME都是占位符实际运行时请替换为对应服务商的信息。保持temperature偏低可以减少模型自由发挥的空间让输出更稳定。max_tokens按命题复杂度调整给太少可能导致输出被截断。4.2 方式二Ollama 本地部署本地部署适合对数据隐私有要求、或者想反复试不同开源模型的场景。Ollama 是目前比较轻量的本地推理方案安装完成后拉取一个通用模型即可使用。# 拉取一个通用模型模型尺寸按本机内存和显存决定 ollama pull qwen2.5:7b # 启动服务默认监听 11434 端口 ollama serveOllama 服务启动后会提供一个 OpenAI 兼容接口默认地址是http://127.0.0.1:11434/v1。这时可以直接用 4.1 的代码把base_url改成这个地址api_key填任意非空字符串即可model填你拉取的模型名。先跑通本地服务再进入反例生成测试。4.3 方式三vLLM 高吞吐部署如果你要批量执行大量反例生成任务vLLM 在吞吐性能上更有优势。启动方式同样是 OpenAI 兼容服务但命令参数依赖 vLLM 版本和模型格式下面的命令只是模板。# 用 vLLM 启动 OpenAI 兼容接口模型路径按实际环境替换 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --port 8000 \ --max-model-len 8192启动后访问http://127.0.0.1:8000/v1即可。相比 OllamavLLM 对显存规划、并发控制和批处理策略更细适合跑大批量任务。第一次启动时可以先用一个小模型验证服务连通性再切换到实际要用的模型。5. LLM 反例生成的功能测试与效果验证这个章节是整个流程的核心。先用已知反例验证链路再进入陌生领域最后用验证器确认。5.1 测试一生成一个已知反例先给模型一个你已知答案的简单命题比如“所有素数都是奇数”。这个命题是错的反例是 2。测试目的不是考验模型而是确认提示词、接口、输出链路都是通的。from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlhttp://127.0.0.1:11434/v1 # 本地 Ollama 示例 ) response client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是一个严谨的检验助手。}, {role: user, content: 判断命题是否成立所有素数都是奇数。 如果不成立请给出反例并且解释原因。}, ], temperature0.2, max_tokens512 ) print(response.choices[0].message.content)预期结果是模型给出反例 2并解释 2 是唯一的偶素数。如果模型在这个简单命题上都答不对那你需要检查提示词、模型选择以及服务是否正常工作。这个测试的实际价值是“最小链路验证”不要跳过。5.2 测试二在陌生领域生成反例现在进入标题里说的“专业领域之外”的场景。这里用数论里一个经典命题做演示对所有正整数 nn^2 n 41 都是素数。这个命题在 n 取 0 到 39 时都成立看起来很像真命题但 n40 时会得到 1681而 1681 41 × 41是一个合数。对大多数不研究数论的工程师来说这个领域已经足够陌生你很难凭感觉判断这个命题是否成立更不容易立刻想到 n40。把这个问题交给 LLM它可能会直接给出 n40也可能会给出其他候选值。关键不在于它第一次给得对不对而在于你有没有手段确认它给的结果。这就是 5.3 要解决的问题。5.3 测试三用 SymPy 独立验证假设模型输出反例是 n40下一步用 SymPy 验证。这里的验证逻辑完全不依赖 LLM也不依赖你的专业水平它是独立的符号计算。from sympy import isprime # 命题对所有正整数 nn^2 n 41 都是素数 counterexample 40 value counterexample**2 counterexample 41 print(value , value) print(is prime , isprime(value))运行结果是value 1681is prime False。这说明该命题确实被 n40 推翻了。验证器返回的 False和模型是否解释清楚、是否自信都没有关系。这一步就是把反例从“模型说法”变成“可确认事实”的关键环节。如果模型给出的候选值不是 40而是其他数字把这个数字代入同一个验证函数即可。任何一个值都能用同样方式判断。这样即使你完全不懂数论也能确认反例是否成立。5.4 测试四多模型交叉验证如果验证器无法覆盖当前领域比如你要判断的是一个自然语言规则没有现成的符号验证工具可以采用多模型交叉验证。用两个不同厂商、不同训练分布的模型分别独立生成反例然后对比结论。双模型一致能提高置信度但有一个注意事项模型之间的一致性不能替代验证器只能说明两个模型的训练盲区可能不同。真正要下结论时仍然需要人类专家或形式化工具介入。多模型交叉验证适合用来“筛掉明显不靠谱的输出”不适合作为最终裁判。5.5 判断成功与失败的标准反例生成流程的“成功”不是看模型是否自信而是看输出能否通过独立的验证环节。判断标准如下结果含义处理方式验证通过反例真实成立记录反例、验证结果、模型输出进入下一步验证未通过生成的反例是幻觉丢弃该候选调整提示词或换模型重试部分通过多个候选里至少一个成立保留成立项分析不成立项的原因验证器报错输出格式或领域不匹配检查提取逻辑或将反例转化为验证器可处理的形式在实际使用中最影响效率的是“验证未通过”太多。如果模型频繁生成幻觉反例可以尝试让模型在输出前先进行自检例如在提示词里要求“先计算再判断最后给出反例”。推理能力更强的模型通常会更稳但同时也需要更多的推理 token。6. 将反例生成接入接口 API 与批量任务单个问题的反例生成价值有限批量处理才能支撑科研筛查和规则审计。这一章介绍如何把反例生成、验证、记录组装成一条可重复执行的流水线。6.1 批量任务设计输入是一份命题清单推荐使用 JSON 格式每个命题有独立 id。输出采用 JSONL 追加写入方便中断后续跑。{ tasks: [ { id: p001, statement: 对所有正整数 nn^2 n 41 都是素数 }, { id: p002, statement: 对任意非空字符串 ss s 的长度是偶数 } ] }任务设计时要考虑三个问题并发数多少、超时时间多长、失败重试几次。建议第一次跑小批量比如 5 到 10 条命题确认稳定后再扩大规模。6.2 Python 调用示例下面的代码演示了批量读取命题、调用本地 Ollama 兼容接口、解析返回结果并追加写入 JSONL 的完整流程。这个示例面向本地 Ollama换成云端 API 时只需要改base_url和model。import json import time from pathlib import Path from openai import OpenAI client OpenAI( api_keynot-needed, base_urlhttp://127.0.0.1:11434/v1 ) MODEL_NAME qwen2.5:7b def generate_counterexample(statement: str, model: str MODEL_NAME) - dict: prompt ( 请判断下面的命题是否成立。如果不成立请给出一个具体的反例。\n f命题{statement}\n 请用 JSON 格式输出 {status: true 或 false, counterexample: 你的反例, reason: 简要解释} ) resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.1, max_tokens512, timeout60, ) return json.loads(resp.choices[0].message.content) tasks json.loads(Path(propositions.json).read_text(encodingutf-8))[tasks] out_path Path(results.jsonl) for item in tasks: for attempt in range(3): try: result generate_counterexample(item[statement]) record { id: item[id], statement: item[statement], result: result, model: MODEL_NAME, attempt: attempt 1, ts: time.time(), } with out_path.open(a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) print(done:, item[id]) break except Exception as exc: print(failed:, item[id], attempt:, attempt 1, exc) time.sleep(2 * attempt)注意json.loads解析模型输出时如果模型返回了额外文字会导致解析失败。一个稳妥做法是先提取输出中的 JSON 片段再做解析。示例里为了保持可读性直接使用了json.loads实际生产代码需要加异常处理和提取逻辑。6.3 串接独立验证器批量生成反例之后需要自动验证。以 n^2 n 41 为例定义一个针对该命题的验证函数然后对每条生成结果调用。from sympy import isprime def validate_n2_n_41(n: int) - bool: 返回 True 表示 n 是该命题的一个真实反例 value n * n n 41 return not isprime(value) # 示例验证模型生成的反例 n 40 print(validate_n2_n_41(40))运行结果是 True说明 n40 确实推翻了命题。在真实项目中每个命题都需要自己的验证函数。如果命题领域可以统一到某个符号计算框架可以考虑用规则引擎统一管理验证函数而不是写一堆散落的脚本。6.4 失败重试与断点续跑批量任务容易在长时间运行中碰到超时、限流、网络抖动。处理思路是每完成一条就写一条 JSONL记录每个任务的完成状态重试超过最大次数后将任务标记为 failed重新运行时扫描已有输出文件跳过已完成的任务。这样可以保证中断后不需要从头跑。下面是一个断点续跑的轻量实现思路import json from pathlib import Path out_path Path(results.jsonl) done_ids set() if out_path.exists(): for line in out_path.read_text(encodingutf-8).splitlines(): if line.strip(): record json.loads(line) done_ids.add(record[id]) for item in tasks: if item[id] in done_ids: print(skip:, item[id]) continue # 实际调用生成器并写结果这段代码不是完整生产实现但给出了断点续跑的核心逻辑先扫描已完成记录再跳过这些任务。7. 资源占用与性能观察7.1 本地推理的资源观察本地推理时资源占用主要看模型规模和推理长度。用nvidia-smi可以随时观察显存变化nvidia-smi --query-gpuname,memory.total,memory.used --formatcsv如果模型加载后显存明显不足会报 CUDA out of memory此时需要换小模型、使用量化版本或者减少并发。CPU 推理也可以跑但显存占用会转化为内存和 CPU 计算压力速度会明显下降。具体数字依赖模型、量化格式、输入输出长度和推理引擎版本因此建议每次更换模型环境时先跑一次 5.1 的最小链路测试记录显存、耗时和输出质量。7.2 API 方式的成本与限流使用云端 API 时本地不需要关心显存但要注意 token 消耗、接口限流和网络延迟。一次反例生成任务的 token 消耗由三部分组成系统提示词、用户命题、模型输出。批量任务中建议统一控制max_tokens避免模型返回过长解释导致成本膨胀。遇到限流时不要盲目提高并发优先增加退避重试。第一次接入新 API 时先发 1 到 2 条请求确认兼容性再跑大批量。7.3 批量任务的性能优化批量反例筛选有一个实用的分层策略先用小模型或便宜 API 跑大批量候选只保留通过简单语法或启发式检查的结果再用强模型或验证器对候选做精确认证。这样能显著节约成本。另一个思路是控制单次请求的上下文长度让问题尽量聚焦避免模型在长上下文里丢失关键信息。对于重复出现的命题模板可以把模板固定下来只替换变量部分输出格式会更稳定也更容易做自动解析。8. 常见问题与排查方法问题现象可能原因排查方式解决方案模型输出的“反例”代入后不成立模型幻觉用验证器逐条验证增加验证器环节重跑候选模型返回内容无法解析为 JSON输出格式不稳定打印模型原始输出在提示词中强化格式要求加 JSON 提取逻辑接口超时或限流请求 token 太长或并发过高查看服务日志和响应码减少 max_tokens限制并发增加退避重试本地推理非常慢模型过大或使用 CPU观察 CPU、GPU 占用换小模型、量化、使用 GPU 加速显存不足模型超过显存容量使用 nvidia-smi 查看使用更小模型或量化版本关闭并发多个模型结论不一致训练分布不同不依赖模型一致性以验证器为准人工复核差异项批量结果缺失任务中断或超时检查结果 JSONL记录已完成 id断点续跑模型生成的反例看不懂超出自身专业范围不要直接采纳输入验证器工具处理或咨询领域专家8.1 模型生成的结果无法看懂怎么办这是标题里最核心的问题反例跑进了你完全不熟悉的领域。此时有两个可执行路径。第一把反例转化为验证器能处理的符号形式用计算确认。第二如果领域没有可用的符号验证器就把模型输出当作“需要研究的高风险提示”带着它去查资料或找专家。最忌讳的做法是因为看不懂就选择相信或选择忽略这两种处理都不够严谨。9. 最佳实践与使用建议9.1 把 LLM 当候选生成器而不是权威裁判LLM 的作用是扩展候选搜索范围不是给出最终裁决。你在提示词里要求“给出反例”时它确实会给出但这不意味着输出正确。设计流程时始终把 LLM 放在生成端把验证器或人工复核放在裁决端。模型输出再流畅、解释再完整都不能替代独立验证。9.2 验证器必须独立于模型验证器不能是“同一个模型再问一遍”那样只是把幻觉复制了一遍。理想情况下验证器是符号计算工具、定理证明器、真实运行环境或者至少是另一个完全不同的模型。独立性越强整套流程越可信。比如数学命题用 SymPy 或 Z3代码逻辑用真实运行测试规则引擎用最小复现脚本。9.3 保留可审计记录批量反例生成要保留审计信息输入命题、模型名称、模型版本、提示词模板、温度参数、模型原始输出、验证结果、耗时、运行时间。这些信息在正式研究、项目复盘或排查问题时价值很大。在结果 JSONL 里记录模型名和验证结果是最基本的审计要求。9.4 在正式场景加入人工复核如果反例会进入论文、报告、产品决策或法律文档不能只靠自动验证。人工复核的要点不是“重新验一遍数学”而是确认命题本身是否被正确建模、验证器是否覆盖了命题的真实语义、反例是否在业务场景下确实构成推翻条件。这一层复核解决的是“验证器验的东西和你想验的东西是否一致”的问题。技术流程可以把 90% 的候选筛掉但最终结论必须有人负责。9.5 合规与隐私提醒所有反例测试都应该在合法授权的测试环境中进行。不要把真实用户数据、未公开代码、商业敏感信息直接发送给外部模型服务。如果你针对某个真实系统的规则做反例审计先确认自己有明确的测试授权。涉及论文发表要按学术规范声明使用了 LLM 辅助。如果模型生成了与特定国家、地区、人群相关的反例不要将其用于任何攻击性、歧视性或误导性用途。反例的用途应该是发现认知盲区和改进系统而不是制造问题。10. 总结与下一步最值得尝试的第一步是先拿一个你知道答案的命题跑通全流程生成、提取、验证、记录。确认链路是稳的再去碰你完全不懂的领域。最容易踩的坑只有一个看到模型给出的反例很漂亮就直接拿去做结论。反例的价值不取决于它看起来多专业而取决于它能不能通过外部验证。下一步可以把这套流程接到你的 Agent 工具链里。让 Agent 在推理前先调用验证器甚至通过 MCP 连接符号计算工具让“生成反例、验证反例、修正假设”变成一个可循环的自动化过程。再进一步可以用 RAG 把领域知识外挂到提示词构建过程中让模型先检索相关知识再生成反例减少因为上下文缺失导致的幻觉。最后提醒一句任何自动验证流程都存在覆盖盲区建议在关键决策前保留人工复核环节。