世界を動かす技術を、日本語で。

ProofOfThought: Z3定理証明を用いたLLMベースの推論

2025年10月5日原文(github.com)

概要

ProofOfThought は、 Z3定理証明LLM を組み合わせた推論フレームワーク。 OpenAI API を利用し、自然言語クエリに論理的な答えを返す仕組み。 バッチ評価簡単なインストール方法 を提供。 高レベルAPIと低レベルDSLの 2層アーキテクチャ を採用。 詳細やサンプルは examples/ ディレクトリや arXiv論文 で確認可能。

ProofOfThought:LLMとZ3による推論フレームワーク概要

  • ProofOfThought :大規模言語モデル(LLM)と Z3定理証明器 を連携した推論システム
  • 自然言語クエリ を入力し、論理的根拠に基づく回答を生成
  • OpenAI API を利用したLLMクライアントの設定
  • z3dsl.reasoning モジュールによる高水準な推論API提供
  • バッチ評価 機能で複数クエリの一括検証が可能

クイックスタート手順

  • OpenAIクライアント の初期化
    • from openai import OpenAI
    • client = OpenAI(api_key="...")
  • ProofOfThoughtインスタンス の作成
    • from z3dsl.reasoning import ProofOfThought
    • pot = ProofOfThought(llm_client=client)
  • クエリ実行と回答取得
    • result = pot.query("Would Nancy Pelosi publicly denounce abortion?")
    • print(result.answer) # 出力例: False

バッチ評価手順

  • バッチ評価パイプライン の利用
    • from z3dsl.reasoning import EvaluationPipeline
    • evaluator = EvaluationPipeline(pot, output_dir="results/")
  • データセット指定による評価実行
    • result = evaluator.evaluate(dataset="strategyqa_train.json", max_samples=10)
    • print(f"Accuracy: {result.metrics.accuracy:.2%}") # 精度表示

インストール方法

  • 必要パッケージのインストール
    • pip install z3-solver openai scikit-learn numpy

アーキテクチャ

  • 2層構造アーキテクチャ
    • 上位層:z3dsl.reasoning(高レベルAPI、Pythonインターフェース)
    • 下位層:z3dsl(JSONベースのZ3定理証明器インターフェース)
  • 一般ユーザー は高レベルAPI利用を推奨

追加情報・サンプル

  • examples/ ディレクトリでAzure OpenAI対応例も含むサンプルを提供
  • 詳細情報・論文
    • arXiv論文:https://arxiv.org/abs/2409.17270

参考リンク

  • arXiv:2409.17270 (ProofOfThoughtの詳細な技術解説)

Hackerたちの意見

面白いアプローチだね。うちのチームも、ビジネスオペレーションのポリシーをLEANでエンコードする似たようなプロトタイプを作ってるよ。まずは内部のナレッジベース(GoogleドキュメントやWikiページ)をLLMを使ってLEANに変換するんだ。それからソルバーを使って一貫性を確認する。Wikiページが変更されたら、またそのプロセスを実行して、基本的にはプロセスのリンターみたいな感じ。プロトタイプの段階を超えたとは言えないけど、LEANへの変換にはエンジニアが目を通す必要があるからね。でも、特に法律や財務のコンプライアンスが厳しい分野では、確かに期待できるアプローチだよ。

自動形式化のギャップは確かに埋めるのが難しいね。私たちは、NeurIPS 2025の論文で、明確に定義された文法における自動形式化の不確実性定量化を探求したよ: https://arxiv.org/abs/2505.20047 。もしもっと詳しく話したいことがあれば、気軽にチャットしよう!

そのポリシーの例を教えてもらえる? Leanに適用できるような、現実世界で十分に定義されたものを思いつくのが難しいんだ。

それはすごくクールだね。矛盾する指針を体系的に特定するのに超役立ちそう。

リポジトリの詳細はあまりないね、掘り下げないといけない。これは、言及された論文のためのアーティファクトとしての意味合いがあるのかも。間違ってなければ、これは主にLLMに実際のクエリを「論理的に」表現するZ3プログラムを生成させるためのAPIだね。これによって生じる「監視」は、評価される論理的な命題を文字通り読む能力と、ソルバーを実行してそれが成り立つかどうかを確認することだよ。自然に疑問が浮かぶのは、誰が一連のSMTルールを手動で読んで、実際の理解と照らし合わせて正確にダブルチェックできるのかってこと。定数をダブルチェックするのは誰? LLMが誤って(あるいは意図的に、目標を達成するために)論理的にも現実的にも不健全な事実やルールを追加するのをどう防ぐの? 論文では論理ベンチマークで*51%*の誤検出率が報告されてる! これは驚くほど高い数字で、LLMが論理モデルに弱いか、常に不健全なものを生み出していることを示唆してる。残念ながら、これがどのように評価されているのか、そして何が不足しているのかについては情報が少ないね。

そうだね。論文は昨年、GPT-4oで書かれたものだよ。それ以来、新しいモデルでずいぶん良くなった。例えば、https://arxiv.org/pdf/2505.20047 のタブ1では、テキストのみとSMTのみのパフォーマンスを比較してる。o3-miniは、テキストの推論をSMTでうまく反映してるし、Gemini Flash 2.0とも比較できる。このことは、ページ29の図14、15で見ることができるよ。AWSの自動推論チェックのような商業用製品では、ドメインからモデルを構築して(例えばPDFポリシー文書から)、正確性をクロスチェックして、回答生成の際には、LLMからのQ/Aペアがポリシーに従っているかをソルバーを使って確認するだけなんだ。これにより、99%を超える健全性保証を提供できる。つまり、サービスがQ/Aペアがポリシーに対して有効または保証されていると言った場合、99%以上の確率で正しいってことだよ。 https://aws.amazon.com/blogs/aws/minimize-ai-hallucinations-...

これは非常に興味深い研究分野だね。数年前に、論理と確率的論理推論エンジンを使って、結論が前提から導かれることを確認するようなことをしたよ。エージェントを使って、ドメイン知識を合成、形式化、批判することもやった。もちろん、これは万能ではないけど、ある程度の正確性は確保できると思う。シンボリズムやエージェントを「判定者」として導入するのは、今後の有望な方法だと思うよ。例えば、これを見てみて: https://arxiv.org/abs/2410.10934

うん!君の研究を読んだよ!すごく面白いね!この夏、AWS ARChecksで自動形式化のための似たような深い研究エージェントに取り組んでたんだ。似たようなパターンを使ってね。残念ながら、その研究は公開されてないけど、一般に利用可能な製品で遊んでみて! [1] https://aws.amazon.com/blogs/aws/minimize-ai-hallucinations-...

エージェント/LLMを判定者として使うのはバイアスがかかっていて、ブートストラップにはいいけど、性能を人工的に制限しちゃう。能力が向上するにつれて、LLMを判定者として使うのは限界があるから、専門の人間の判定者か、決定論的オラクルに移行する必要があるよ。

面白い研究だね!DSLがどんな感じかリポジトリ見に行ったけど、わかりやすい例が見つけにくかったよ。READMEにサンプルを追加してくれたら嬉しいな。

こんにちは!興味を持ってくれてありがとう!それやってみるね。とりあえず、11ページ以降を見てみて。いろんな状況について説明してるよ!

LLMは結局、統計的な言語モデル(当たり前だけど)で、推論するものじゃないんだよね。論理プログラム、特にPrologのソースを生成するのが異常にうまくいくことに気づいたけど、[1]、多分Prologが記号的な自然言語処理のために導入されたから、トレーニングセットに翻訳の例が豊富にあるからかも。Z3の代替Datalog構文[2]をチェックする価値があるかもね、LispっぽいSMTLib構文の代わりに。

Hacker Newsで議論の続きを見る