公开论文雷达

公开 arXiv 研究简报 · 2026-08-10T00:40:09.376433+00:00

先看结论和关键数字,再决定要不要读原文。候选只在首次出现时展示;旧候选若后来通过深读门槛,仍会进入重点。

通用LLM碰形式化:都靠外部验证,可用度天差地别

三篇都拿通用大模型做形式化相关任务,却给出完全不同的可用性判断:需求转LTL已达工程可用,开权重模型写Coq证明内核仅过3.5%,工具智能体系统级验证一般不可判定。共同点是都不信模型文本本身,另设一道硬检查。先读最能立刻上手的LTL那篇。

推荐阅读顺序

  1. 2608.06287:门槛最低、结论最正面:少样本提示即可把需求转成可用LTL,先看能立刻接进流程的成果。
  2. 2608.05420:同是LLM生成形式产物,却给出3.5%的冷结论,用它校准对LLM写证明的预期。
  3. 2608.03609:最偏理论:给高风险智能体部署划出可判定边界与等变性条件,作为压轴框架。
共性方法
三者都把通用LLM当不可信的候选生成器,绝不用文本流畅或相似当合格标准,而是外接一道硬验证:人工语义核验、Coq内核逐步接受、或等变性检查与规范包装器;都主张部署前先验,而非一次生成即入库。
关键分歧
分歧在证据类型和可用度:LTL篇是实测且判定‘现在可用’;Coq篇也是实测,却是3.5%的负面结论、长证明零通过;智能体篇是理论证明加概念演示,谈可判定性边界而非成功率。验证权威也各异:人评、内核、图同构级计算。
选择准则
按任务对号入座:把需求翻成规范,用少样本加多次采样再人工核验,可上手;让LLM写证明,只认内核、别把短证明成绩外推到长证明;部署数据型智能体,先写FO-CTL规范并检验等变性。

重点深读(3 / 3 篇)

形式化与程序验证(2 篇)

形式化与程序验证 6/30

Can Open-Weight LLMs Produce Kernel-Verified Coq Proofs? A Pilot Study

开权重 LLM 单次写 Coq 证明,内核只通过 3.5%:如果你准备把 LLM 生成的 Coq 证明接进工程流程,先看内核是否接受,而不是看文本像不像证明。这个试点把六个开权重模型放到 CoqStoq 的 100 条真实项目定理上,每定理只试一次,由 Coq 内核在原始项目环境中逐步判定;600 次尝试只有 21 次通过,总成功率 3.5%。

两句看懂

过去缺少系统证据说明通用开权重 LLM 能否在真实 Coq 项目定理上产出内核接受的证明,所以该试点用六个模型各做一次单次尝试,并把 Coq 内核设为唯一判定。结果是 600 次尝试 21 次通过,成功率 3.5%;成功只落在短或中等参考证明长度上,长参考证明定理零通过。

核心判断

在真实 Coq 项目定理上,当前开权重 LLM 单次尝试的内核验证成功率只有 3.5%(600 次中 21 次);通过集中在短或中等参考证明长度,判定依据是 Coq 内核在原始项目环境中逐步接受。

关键要点

1. 旧误区:把文本相似或读起来合理当成证明正确;无内核验证时,无效语法、假策略、假引理、错假设、漏步骤、库版本差异都看不见。 2. 方法与受控检查:CoqStoq 100 条真实项目定理;六模型每定理一次、温度 0;原始项目环境中由 Coq 内核逐步判定,并对照标准 Coq 策略基线。 3. 结果与动作:600 次通过 21 次,成功率 3.5%,覆盖 15 个定理;只做短中证明的有限辅助,别把短证明成功率外推到长证明。

证据与结果

评测规模为六模型 × 100 定理 = 600 次尝试。成功标准不是生成文本相似,而是 Coq 内核在原始项目环境中接受。分项结果:Gemma 4 为 12/100,Llama 3.3 为 8/100,DeepSeek Coder V2 Lite 为 1/100,Qwen 3.5、Mistral Small 3.1、GPT-OSS 为 0/100。21 次成功覆盖 15 个不同定理,其中 11 个未被标准策略基线解决。按参考证明长度分层看,短、中有成功,长为零成功;该分层是探索性分析,未建立因果。资源只统计三个有成功模型:每次验证 741–36,193 token,14.9–178.0 秒,0.0167–0.2000 GPU 小时;零成功模型未计算。模型间差异未做统计显著性检验,因此不形成普适排名。

打开论文原文
它要解决什么
通用开权重 LLM 能否在真实 Coq 项目定理上生成被内核接受的形式证明?单次尝试下,成功率、能覆盖的定理,以及 token、时间和 GPU 消耗各是多少?
研究路径
每个 LLM 在温度 0 下只根据定理陈述生成一次证明文本。随后系统把该文本放回定理原来的 Coq 项目环境运行;Coq 内核基于归纳构造演算逐步检查每个策略变换是否合法,任何一步违反规则就拒绝整个证明。只有全部步骤都被内核接受,才记为成功;输出 token、挂钟秒数和 GPU 小时同步记录。
这对工程意味着什么
第一步动作:把评测脚本改成只在原始 Coq 项目环境中以内核逐步接受计通过,并同步记录 token、秒数和 GPU 小时。要避开的捷径:不要用文本流畅度、相似度或短证明成功率,去推断长参考证明定理也能过;本数据中长证明是零通过。
证据定位
Gemma 4 通过 12/100,Llama 3.3 通过 8/100,DeepSeek Coder V2 Lite 通过 1/100,其余三个模型为 0/100。合计 600 次尝试通过 21 次,即 3.5%;这 21 次覆盖 15 个不同定理,其中 11 个标准 Coq 策略基线未解。所有成功定理的参考证明都是短或中等长度;长参考证明定理没有任何模型通过。(筛选维度:形式化验证、可复核评测)
适用边界
每条定理只试一次且温度为 0,不能代表多次采样或迭代修订场景。样本只有 100 条定理,模型间差异没有统计显著性检验。参考证明长度与成功率的关系是探索性分析,未建立因果。六个模型也不覆盖全部开权重模型。
方法与英文摘要

评测取 CoqStoq 中 100 条来自真实 Coq 项目的定理。模型为 Gemma 4、Llama 3.3、DeepSeek Coder V2 Lite、Qwen 3.5、Mistral Small 3.1、GPT-OSS。每个模型对每条定理只生成一次,温度设为 0。生成文本回到该定理原始 Coq 项目环境中,由内核逐步检查;任一步失败,整个证明拒绝。对照是标准 Coq 策略自动化;同时记录输出 token 数、挂钟时间和 GPU 小时。

Large language models (LLMs) can generate text that resembles a mathematical proof, but resemblance does not establish correctness. A formal proof checker verifies whether each proof step follows established logical rules. Coq bases its rules on the Calculus of Inductive Constructions, a logical framework that defines which proof steps the system may accept. This pilot study evaluated six open-weight LLMs on the same 100 theorems from CoqStoq, a benchmark derived from real Coq projects. Each LLM received one attempt per theorem with the temperature set to 0, and Coq checked every proposed proof in the theorem's original project environment. We counted a proof as successful only if the Coq kernel accepted it. Gemma 4 verified 12 of 100 theorems, Llama 3.3 verified 8, and DeepSeek Coder V2 Lite verified 1. Qwen 3.5, Mistral Small 3.1, and GPT-OSS verified none. The 21 successful model-theorem results covered 15 distinct theorems, 11 of which were not solved by a baseline of standard Coq tactics. All verified theorems had short or medium human-written reference proofs; no model verified a theorem with a long reference proof. Because the proof-length analysis was exploratory, this pattern does not establish that proof length caused the difference. For the three models with at least one success, the total generation cost per verified proof ranged from 741 to 36,193 output tokens, 14.9 to 178.0 seconds, and 0.0167 to 0.2000 aggregate GPU hours. We could not calculate these ratios for models with no verified proofs. Across 600 attempts, the models produced 21 kernel-verified proofs, giving an overall success rate of 3.5%. The study reports descriptive differences among the models but does not statistically test whether one model outperforms another. Therefore, the results do not establish a universal ranking of the six models.

形式化与程序验证 4/30

Formal Verification of Agentic Systems over Operational Data

LLM工具智能体的系统级验证一般不可判定,但等变性可把有限域验证降到PSPACE完全:如果你在高风险业务工作流里部署LLM工具智能体,只检查单次工具调用并不够:系统可能跨完整执行过程破坏运营数据的安全性和进展性。作者把“LLM+工具编排+关系型运营数据”形式化为STEAD,用FO-CTL写业务规范,并证明等变性是让有限域验证可判定的关键条件。

两句看懂

LLM工具智能体对FO-CTL运营数据规范的一般验证不可判定,但满足等变性并限定有限域后,验证复杂度为PSPACE完全。案例管理工作流表明LLM实际会违反等变性;规范部署包装器可以强制等变性,但规范表示计算等价于图同构困难。

核心判断

LLM工具智能体对FO-CTL运营数据规范的验证在一般情况下不可判定;等变性条件与有限域限制可给出PSPACE完全验证,但LLM实际可能违反等变性,而强制等变性所需的规范表示计算等价于图同构困难。

关键要点

1. 旧假设是转移机制由符号规则确定;LLM引入非符号且可能非等变的决策,接口级监控也不能覆盖完整工作流。 2. STEAD建模LLM、工具编排和关系型运营数据;等变性检查要求标识符置换后工具调用同步重命名。 3. 一般验证不可判定;等变性加有限域使验证为PSPACE完全;部署前先检验等变性,不满足时加装规范包装器。

证据与结果

作者用人工构造的案例管理工作流演示框架。实例包含关系型运营数据表和FO-CTL业务规范,例如所有请求须最终完成、关键操作须先记录审批。该实例展示了STEAD语义和FO-CTL表达能力,也展示了LLM会对同构数据状态选择非对称工具调用。规范部署包装器在同一实例上保证了等变性。论文没有给出大规模基准数据集或量化统计结果,主要验证形式是三项理论证明和概念演示。

打开论文原文
它要解决什么
旧的数据感知验证通常假设转移机制由符号规则完全确定,但LLM会加入非符号决策,而且可能不随标识符置换保持等变。实际问题是:如何验证LLM工具智能体在整个工作流中对运营数据是否满足安全性和进展性,并在一般情况不可判定时找出可决策的充分条件?
研究路径
LLM在自然语言策略约束下读取一阶关系型运营数据,选择工具调用并更新状态。FO-CTL规范描述三类要求:不能发生的安全性问题、最终必须发生的进展目标,以及不同决策分支应满足的条件。等变性把不透明标识符看成可交换对象:数据D变成σ(D)后,工具调用也必须按σ重命名。满足该条件后,系统不必区分仅由标识符不同造成的同构状态,因而能在有限域中构造显式有限转移系统。
这对工程意味着什么
第一步是把业务规则写成FO-CTL规范,并先检验LLM工具智能体在可达决策上下文中的等变性。不要走“只做接口级监控”的捷径,因为它只约束单次工具调用,无法覆盖运营数据层跨完整工作流执行的安全性和进展性。
证据定位
一般STEAD对FO-CTL规范的验证不可判定。加入等变性并限制有限域后,验证复杂度为PSPACE完全。案例管理工作流演示显示,LLM可能对同构数据状态输出不对称的工具调用,即实际违反等变性。规范部署包装器可在该实例上保证等变性。规范表示计算等价于图同构困难,这给包装器扩展带来计算边界。三项理论结果分别覆盖不可判定性、PSPACE完全性和图同构困难性。(筛选维度:形式化验证)
适用边界
框架只处理单LLM加单工具编排的STEAD结构,没有扩展到多智能体系统。案例研究来自手工构造的案例管理工作流,缺少大规模或真实生产数据集验证。规范表示计算的图同构困难性会限制包装器的实际可扩展性,论文也没有提供实证性能评估。
方法与英文摘要

作者把系统建成STEAD三元组:接受自然语言策略的LLM、工具编排框架和一阶关系型运营数据。业务需求用FO-CTL表达,覆盖安全性、进展性和决策分支。等变性要求:对域元素施加任意置换σ后,LLM输出的工具调用也必须被σ对应重命名。满足等变性并限定有限域后,可构造显式有限转移系统并完成PSPACE完全验证。作者还提出规范部署包装器:先标准化决策上下文,再输入LLM,最后把输出工具调用映射回原始标识符,从而在不修改基础模型的情况下强制等变性。

Agentic systems driven by large language models (LLMs) are increasingly deployed in real-world workflows where they act on persistent operational data. Before deployment, these systems need to be verified against business requirements that govern workflow execution and data evolution. However, existing approaches do not provide such system-level guarantees, as they mainly constrain or analyse behaviour at the agent's interface level. We study here the verification of agentic systems comprising a single LLM and a tool orchestration harness over relational operational data. We formalise them as Stateful Tool-Enabled Agentic Deployments (STEADs), give their semantics, define the problem of verifying them against First-Order Computation Tree Logic (FO-CTL) specifications, and show that it is undecidable. We identify sufficient conditions for exact preservation of FO-CTL specifications under a finite-domain restriction, over which verification is PSPACE-complete. The key requirement is that renaming opaque identifiers in the data must correspondingly rename the selected tool calls. We show that LLM-driven agents can violate this condition and introduce a canonical deployment wrapper that guarantees it for arbitrary base agents while preserving already-equivariant behaviour. We prove that computing canonical representations required by this construction is graph-isomorphism-hard. Finally, we illustrate our framework on an LLM agent orchestrating a case-management workflow.

软件工程与仓库智能(1 篇)

软件工程与仓库智能 12/30

Automatic Translation of Unstructured Requirements into Linear Temporal Logic through Large Language Models

不用微调,通用大语言模型已能把非结构化需求翻成可用的LTL公式:做需求形式化的团队常被模板语言培训卡住;这项评测说明,只要给通用大语言模型几条少样本提示,就能把工业里常见的非结构化自然语言需求直接转成线性时态逻辑公式,且达到实际可用水平。方法是对6个通用模型在15条异质需求上各独立采样5次,共450条候选公式,用人工语义评估、pass@k和自一致性三项指标打分。

两句看懂

过去自动形式化靠结构化自然语言和模板,可工业文档多是歧义、带隐含时态假设的非结构化句子,规则流水线在这里会失效,所以本研究直接用少样本提示驱动6个通用LLM生成LTL公式。评测在15条异质需求上每组合采样5次共450条候选公式,用人工语义、pass@k和自一致性三项指标确认:不微调也能达到实际可用。

核心判断

当前通用大语言模型不用做任务特定微调,就能把非结构化自然语言需求转成实际可用的LTL公式。这个判断基于450条候选公式的人工语义评估、pass@k指标和语法自一致性度量。

关键要点

1. 旧路失效:自动形式化多依赖结构化NL和模板,工程师要学模板语言;工业里的非结构化NL语法不可预测,规则流水线因此失灵。 2. 做法与对照:15条异质需求×6个通用LLM×少样本提示,每组合独立采样5次共450条公式;以自一致性度量作控制,量化随机性影响。 3. 结果与动作:人工语义、pass@k(k=1/3/5)、自一致性三维判定无微调即可用;应多次采样加pass@k筛选,再由专家做最终语义核验。

证据与结果

基准是15条结构各异的非结构化需求,含隐含时态假设、欠定义条件、领域术语等典型歧义。规模为6个LLM×15条需求×5次独立采样=450条候选公式。三维评估:人工逐条判语义正确;pass@k(k=1,3,5)算k次内至少一次正确的概率;自一致性度量看随机试验间语法结构的复现稳定性。主要障碍是非结构化NL的歧义、隐含时态假设和欠定义条件;自一致性差异显示各模型在随机采样下语法稳定性分布不均;各模型具体分值未在可用摘录中披露。

打开论文原文
它要解决什么
通用大语言模型在不微调的情况下,能否把非结构化自然语言需求直接转成线性时态逻辑公式,并达到工程上可用的准确率?
研究路径
先挑15条结构各异的非结构化需求组成异质基准;再给6个通用LLM配同一套少样本提示;每条需求-模型组合独立随机采样5次,累计450条候选LTL公式;每条公式同步生成自然语言解释;随后用人工语义评估判正确性,用pass@k(k=1,3,5)衡量多次尝试的成功率,用语法自一致性度量量化随机试验间的语法复现稳定性;另配时间线LTL可视化,帮助非专家做可读性分析。
这对工程意味着什么
第一步动作:把通用LLM少样本提示、多次采样和pass@k筛选接进需求形式化流程,先省下模板培训成本。要避开的捷径:不要拿单次生成结果直接入库;自一致性数据表明随机试验间语法结构波动明显,必须多次采样后再由人做语义核验。
证据定位
评分用三条线:人工逐条判语义对错;pass@k取k为1、3、5,看k次里至少对一次的概率;再算语法自一致性,看多次随机采样下语法结构是否稳定。结论是:无微调条件下,通用LLM在这项任务上达到实际可用性能;自一致性还把不同模型在随机采样中的语法稳定性差异分开了。(筛选维度:形式化验证、可复核评测、软件工程方法)
适用边界
基准只有15条需求,规模偏小,领域覆盖范围披露不充分;评估依赖人工语义判断,评分者间一致性未见报告;只测了少样本提示,未与零样本或微调方案对比;各模型具体量化分数未在可用摘录中披露,无法直接引用数值。
方法与英文摘要

建一个15条需求的基准,结构各不相同,覆盖工业文档里典型的隐含时态假设、欠定义条件和领域术语。选6个通用大语言模型,统一用少样本提示。每条需求对每个模型独立随机采样5次,共生成450条候选LTL公式,同时给每条公式配一段自然语言解释,方便非专家读。

Automatically translating unstructured natural language requirements into formal specifications remains a challenge in requirements engineering and formal methods, particularly for safety- and mission-critical systems whose verification depends on mathematically precise specifications. This paper evaluates whether contemporary off-the-shelf Large Language Models (LLMs) can help bridge this gap by generating Linear Temporal Logic (LTL) formulas directly from unstructured requirements. The study examines six modern LLMs using a few-shot prompting strategy on a heterogeneous benchmark of 15 structurally varied requirements. Five independent generations were collected for each requirement-model pair, yielding 450 candidate LTL formulas in total. Performance was assessed through manual semantic evaluation, pass@k for k in {1, 3, 5}, and a self-consistency measure capturing syntactic reproducibility across stochastic trials. The results indicate that current general-purpose LLMs can achieve practically significant performance on the unstructured NL-to-LTL task without task-specific fine-tuning. The study also considers understandability for non-experts by pairing generated formulas with model-produced natural language explanations and discussing the complementary use of timeline-based LTL visualization. The findings suggest that modern LLMs are becoming viable front-end assistants for semi-automated formalization workflows.

代码质量与优化(0 篇)

本轮没有通过深读证据门的重点论文。

UI 与 GUI Agent(0 篇)

本轮没有通过深读证据门的重点论文。

个人知识与本体(0 篇)

本轮没有通过深读证据门的重点论文。

人机协同与对齐(0 篇)

本轮没有通过深读证据门的重点论文。

本轮分类概览

同一论文只归入一个最先命中的赛道,避免重复计数;“新增候选”只统计首次展示的论文。

赛道新增候选重点
形式化与程序验证02
软件工程与仓库智能01
代码质量与优化00
UI 与 GUI Agent00
个人知识与本体00
人机协同与对齐00

近一个季度监测日历

北京时间。绿色表示有可阅读的新候选,灰蓝表示已监测但无新增,橙色表示部分降级;“无记录”不等于失败。

2026 年 6 月

1无记录2无记录3无记录4无记录5无记录6无记录7无记录8无记录9无记录10无记录11无记录12无记录13无记录14无记录15无记录16无记录17无记录18无记录19无记录20无记录21无记录22无记录23无记录24无记录25无记录26无记录27无记录28无记录29无记录30无记录

近 14 次监测窗口

仅展示公开源的聚合运行状态,不含提示词、全文或个人数据。

本轮新增候选(0 篇)

按赛道、评分和日期展开;中文标签用于导航,英文摘要用于核验。已展示过的旧候选不会每日重复。

形式化与程序验证(0 篇)

本轮该赛道没有候选论文。

软件工程与仓库智能(0 篇)

本轮该赛道没有候选论文。

代码质量与优化(0 篇)

本轮该赛道没有候选论文。

UI 与 GUI Agent(0 篇)

本轮该赛道没有候选论文。

个人知识与本体(0 篇)

本轮该赛道没有候选论文。

人机协同与对齐(0 篇)

本轮该赛道没有候选论文。