論文の概要: Can Large Language Models Simulate Symbolic Execution Output Like KLEE?

• arxiv url: http://arxiv.org/abs/2511.08530v1
• Date: Wed, 12 Nov 2025 02:03:24 GMT
• ステータス: 翻訳完了
• システム内更新日: 2025-11-12 20:17:03.853913
• Title: Can Large Language Models Simulate Symbolic Execution Output Like KLEE?
• Title（参考訳）: 大規模言語モデルはKLEEのように記号的実行出力をシミュレートできるか?
• Authors: Rong Feng, Vanisha Gupta, Vivek Patel, Viroopaksh Reddy Ernampati, Suman Saha,
• Abstract要約: 記号実行は、記号入力に基づいて異なる経路を探索することでプログラムをチェックするのに役立つ。 KLEEの最大の問題は、プログラムが分岐パスをたくさん持っている場合、どれだけ遅くなるかである。 我々は、100個のCプログラムのデータセットを用いて、GPT-4oがKLEE出力と最も複雑な経路を予測できるかどうかを検証した。
• 参考スコア（独自算出の注目度）: 1.167405291587978
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Symbolic execution helps check programs by exploring different paths based on symbolic inputs. Tools like KLEE are commonly used because they can automatically detect bugs and create test cases. But one of KLEE's biggest issues is how slow it can get when programs have lots of branching paths-it often becomes too resource-heavy to run on large or complex code. In this project, we wanted to see if a large language model like GPT-4o could simulate the kinds of outputs that KLEE generates. The idea was to explore whether LLMs could one day replace parts of symbolic execution to save time and resources. One specific goal was to have GPT-4o identify the most constrained path in a program, this is the execution path with the most symbolic conditions. These paths are especially important because they often represent edge cases that are harder to test and more likely to contain deep bugs. However, figuring this out usually requires fully running KLEE, which can be expensive. So, we tested whether GPT-4o could predict the KLEE outputs and the most complex path using a dataset of 100 C programs. Our results showed about 20% accuracy in generating KLEE-like outputs and identifying the most constrained path. While not highly accurate, this early work helps show what current LLMs can and can't do when it comes to simulating symbolic execution.
• Abstract（参考訳）: 記号実行は、記号入力に基づいて異なる経路を探索することでプログラムをチェックするのに役立つ。 KLEEのようなツールは、バグを自動的に検出し、テストケースを作成することができるため、一般的に使用される。 しかし、KLEEの最大の問題は、プログラムの分岐パスが多すぎるとどれだけ遅くなるかである。 このプロジェクトでは、GPT-4oのような大規模言語モデルがKLEEが生成する出力の種類をシミュレートできるかどうかを確かめたかった。 LLMがいつか、時間とリソースを節約するためにシンボリックな実行の一部を置き換えられるかどうかを調査することを目的としていた。 1つの特定のゴールは、GPT-4oがプログラムの中で最も制約されたパスを識別することであり、これは最も象徴的な条件を持つ実行パスである。 これらのパスは、テストが難しく、より深いバグを含む可能性が高いエッジケースを表すことが多いため、特に重要です。 しかし、これを確かめるためには通常、KLEEを完全に実行する必要がある。 そこで,100個のプログラムのデータセットを用いて,GPT-4oがKLEE出力と最も複雑な経路を予測できるかどうかを検証した。 その結果、KLEEのような出力を生成し、最も制約された経路を特定するのに約20%の精度が得られた。 精度は高くないが、この初期の作業は、象徴的な実行をシミュレートする上で、現在のLLMに何ができるかを示し、何ができないかを示すのに役立つ。

関連論文リスト

• Generating and Understanding Tests via Path-Aware Symbolic Execution with LLMs [8.828992823055]
  PALMは、シンボリックパス列挙とLLM支援テスト生成を組み合わせたテスト生成システムである。 Palmは、パスカバレッジをよりよく理解し、PALMが生成したテストで実際にどのパスが実行されているかを特定するのに役立つ。
  論文  参考訳（メタデータ） (2025-06-24T03:46:16Z)
• Empc: Effective Path Prioritization for Symbolic Execution with Path Cover [4.247960711260534]
  記号的実行は、プログラムの動作の正しさを正式に推論し、ソフトウェアバグを検出する。 それは固有の限界、すなわち経路の爆発に悩まされる。 本稿では,Empcという経路被覆を用いた新規かつ効果的な経路優先順位付け手法を提案する。
  論文  参考訳（メタデータ） (2025-05-06T14:08:36Z)
• ThrowBench: Benchmarking LLMs by Predicting Runtime Exceptions [4.852619858744873]
  大規模言語モデル(LLM)は、コード理解と合成の驚くべき能力を示している。 4つの異なるプログラミング言語で書かれた2,400以上の短いユーザ記述プログラムからなるベンチマークであるThrowBenchを紹介する。 我々は6つの最先端コードLLMのベンチマーク評価を行い、19～38%(F1スコア)の適度なパフォーマンスを確認した。
  論文  参考訳（メタデータ） (2025-03-06T09:22:23Z)
• Can LLM Generate Regression Tests for Software Commits? [15.653758694625854]
  大規模言語モデル(LLM)は、自動化されたソフトウェア工学において非常に有望であることを示している。 フィードバック指向のゼロショットLCMに基づく回帰テスト生成技術であるCleverestを実装した。 XMLやJavaScriptのようなより可読なファイルフォーマットを使用するプログラムでは、Cleverestは非常によく機能した。
  論文  参考訳（メタデータ） (2025-01-19T15:46:26Z)
• Python Symbolic Execution with LLM-powered Code Generation [40.906079949304726]
  シンボリック実行はソフトウェアテストにおいて重要な技術であり、シンボリックパスの制約を収集してテストケースを生成する。 シンボリック実行は高いカバレッジテストケースを生成する上で有効であることが証明されている。 本稿では,実行経路制約を解決するために,SMTソルバ,Z3を自動的に呼び出すエージェント LLM-Sym を提案する。
  論文  参考訳（メタデータ） (2024-09-14T02:43:20Z)
• Chain of Code: Reasoning with a Language Model-Augmented Code Emulator [115.16975276693267]
  我々は、LMコード駆動推論を改善するシンプルながら驚くほど効果的な拡張であるChain of Codeを提案する。 キーとなるアイデアは、プログラム内のセマンティックなサブタスクを、インタープリタが明示的にキャッチできるフレキシブルな擬似コードとしてフォーマットすることを、LMに促すことである。
  論文  参考訳（メタデータ） (2023-12-07T17:51:43Z)
• Guess & Sketch: Language Model Guided Transpilation [59.02147255276078]
  学習されたトランスパイレーションは、手作業による書き直しやエンジニアリングの取り組みに代わるものだ。 確率的ニューラルネットワークモデル(LM)は、入力毎に可塑性出力を生成するが、正確性を保証するコストがかかる。 Guess & Sketch は LM の特徴からアライメントと信頼性情報を抽出し、意味的等価性を解決するためにシンボリック・ソルバに渡す。
  論文  参考訳（メタデータ） (2023-09-25T15:42:18Z)
• LEVER: Learning to Verify Language-to-Code Generation with Execution [64.36459105535]
  本稿では,プログラムの実行結果の検証を学習することで,言語からコードへの生成を改善するシンプルな手法であるLEVERを提案する。 具体的には、LLMからサンプリングされたプログラムが、自然言語入力、プログラム自体とその実行結果に基づいて正しいか否かを判定するために、検証者を訓練する。 LEVER はベースコード LLMs (4.6% から 10.9% まで) を継続的に改善し、それらすべてに対して新しい最先端の結果を得る。
  論文  参考訳（メタデータ） (2023-02-16T18:23:22Z)
• PAL: Program-aided Language Models [112.94785609781503]
  自然言語問題を理解するために,プログラム支援言語モデル(PaL)を提案する。 PaLはソリューションステップをPythonインタプリタのようなプログラムランタイムにオフロードする。 私たちは12のベンチマークで新しい最先端の結果を設定しました。
  論文  参考訳（メタデータ） (2022-11-18T18:56:13Z)
• Fault-Aware Neural Code Rankers [64.41888054066861]
  サンプルプログラムの正しさを予測できる故障認識型ニューラルネットワークローダを提案する。 我々のフォールト・アウェア・ローダは、様々なコード生成モデルのpass@1精度を大幅に向上させることができる。
  論文  参考訳（メタデータ） (2022-06-04T22:01:05Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。