論文の概要: Code Monitor Red Teaming for Public-Test-Passing Code
- arxiv url: http://arxiv.org/abs/2607.20852v1
- Date: Thu, 23 Jul 2026 02:23:09 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-07-24 18:26:25.260727
- Title: Code Monitor Red Teaming for Public-Test-Passing Code
- Title(参考訳): Code Monitor Red Teaming for Public-Test-Passing Code
- Abstract要約: 生成器の圧力、検証器の足場、強度の弱い能力を変えながら、公開チェック情報境界を修正するために、Code Monitor Red Teamingを導入します。
71,000人を超える候補者、43,677人が公開テストに合格し、そのうち23,081人が隠れテストに失敗している。
強靭性ストレステストとして、逆向きの公試オーバーフィット圧力は検証器AUROCを低下させ、ほとんどの細胞において低FPRミス率を上昇させる。
- 参考スコア(独自算出の注目度): 10.934702002803434
- License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
- Abstract: Visible tests are a common gate for LLM-generated code, but passing them does not certify specification correctness. We study a deployment-like monitoring problem: after code has passed public tests, can a weaker LLM verifier identify the residual hidden bugs? We introduce Code Monitor Red Teaming, a monitor-red-teaming protocol that fixes a public-check information boundary while varying generator pressure, verifier scaffolding, and weak-to-strong capability. We instantiate it as CodeMonitorBench, spanning function-level, data-science, and workflow code. Across 71,000 generated candidates, 43,677 pass public tests and 23,081 of those fail hidden tests. Weak verifiers improve with scaffolding and model family, but still miss most hidden bugs at 5% false-positive rate. As a robustness stress test, adversarial public-test-overfit pressure lowers verifier AUROC and raises low-FPR miss rates in most cells. A GLM-5.1 verifier recovers part of the gap under the same evidence boundary; an inferability audit shows that remaining misses mix verifier failures with M1 evidence limits.
- Abstract(参考訳): 可視性テストはLLM生成コードの共通ゲートであるが、それらを渡すことは仕様の正しさを証明しない。
コードが公開テストに合格した後、より弱いLCM検証者が隠れたバグを特定できるだろうか?
生成器の圧力、検証器の足場、強度の弱い能力を変えながら、公開チェック情報境界を修正できる監視赤チームプロトコルであるCode Monitor Red Teamingを紹介した。
関数レベル、データサイエンス、ワークフローコードにまたがるCodeMonitorBenchとしてインスタンス化します。
71,000人を超える候補者、43,677人が公開テストに合格し、そのうち23,081人が隠れテストに失敗している。
弱検証器は足場やモデルファミリーで改善されるが、5%の偽陽性率でほとんどの隠れバグを見逃す。
強靭性ストレステストとして、逆向きの公試オーバーフィット圧力は検証器AUROCを低下させ、ほとんどの細胞において低FPRミス率を上昇させる。
GLM-5.1検証器は、同じエビデンス境界の下でギャップの一部を回復する。
関連論文リスト
- ExecCritic: Learn to Test, Test to Improve for Coding Agents [68.42713285082912]
実行時のフィードバックは、コーディングエージェントを正しいリポジトリの修復に導くことができますが、テストが問題によって要求された振る舞いをキャプチャした場合のみです。
ExecCriticを導入し、テスト-検証-修正足場と、その中のトレーニングエージェントのためのロール固有の強化学習レシピを組み合わせる。
テストエージェントが独立してリポジトリネイティブなテストを生成し、フェイルクローズされたハーネスがそれらを調整して凍結し、リカバリエージェントがテストを変更することなく、ソースコードを実行フィードバックから修正する。
論文 参考訳(メタデータ) (2026-09-08T17:53:37Z) - Evaluating and Mitigating the Misguidance Effect of Buggy Code in LLM-Generated Unit Tests [6.228248513679207]
本稿では,その誤動作を検証するテストを生成するために,バギーコードによるLSMを誘導する現象である「誤用効果」を測定するための新しい指標を提案する。
我々は,テスト中のコードをLCM生成した仕様文書に置き換える仕様ベースの単体テスト生成パラダイムを導入し,検証する。
本研究の結果から,このパラダイムは誤操作を効果的に低減し,有効なテストを大幅に増加させ,複数ラウンドのフィードバック駆動型テスト生成パイプラインを改善し,バグやバグのないコードにも適用可能であることが示唆された。
論文 参考訳(メタデータ) (2026-07-24T19:47:41Z) - Beyond Fail-to-Pass: Iterative Hardening of Co-Generated Bug Reproduction Tests and Fixes [55.114939648705395]
大規模言語モデル(LLM)は、現実のバグに対して、プログラムの自動修正をますます実用的にしている。
バグ再現テスト(BRT)は、バグレポートを実行可能なバグ固有の信号に変換することで、このギャップを埋めるのに役立つ。
本稿では,ループ内収束基準としてLax信号を用いるコジェネレーションフレームワークであるCoHardenを提案する。
論文 参考訳(メタデータ) (2026-07-22T07:30:07Z) - How Far Are We from Detecting Flaky Tests? On the Limits of Code-Based Detection [41.369102837712795]
燃えるようなテストは同じコードバージョンでパスしてフェールし、テスト結果のシグナルを弱める。
コードベースのフレキネス検出器は強力なベンチマーク結果を報告しているが、実際の使用は限られている。
フレキネスはテストコードの静的な特性ではなく、テストが不安定かどうかを決定するのに必要な情報が欠けていることが多い、と私たちは主張する。
論文 参考訳(メタデータ) (2026-07-10T12:24:25Z) - Verus-SpecGym: An Agentic Environment for Evaluating Specification Autoformalization [26.123396123145415]
LLMエージェントが非公式なプログラミング問題を忠実な形式仕様に変換することができるかどうか、仕様自動書式化について検討する。
Codeforces問題から派生した581の仕様記述タスクのベンチマークであるVerus-SpecBenchを紹介する。
フェールモードの解析は、モデル生成仕様が重要な入力仮定を受け入れ、誤った出力を受け入れ、有効な仕様を拒否できることを示している。
論文 参考訳(メタデータ) (2026-05-26T02:12:48Z) - Code-A1: Adversarial Evolving of Code LLM and Test LLM via Reinforcement Learning [54.95476453942411]
コード生成のための強化学習は、単体テストのパスレートから検証可能な報酬に依存する。
最近のセルフプレイ手法は、1つのモデルでコードとテスト生成を統合する。
Code-A1は、人間のアノテーションによるテストでトレーニングされたコード生成のパフォーマンスマッチングまたはモデルを超えることを実現する。
論文 参考訳(メタデータ) (2026-03-16T17:58:13Z) - Is the Cure Still Worse Than the Disease? Test Overfitting by LLMs in Automated Program Repair [7.216607755908824]
自動プログラムの修復は、確認されたテストに合格するが、隠されたテストの保留セットで失敗する、修復されたコードの生成に影響を受けやすいことが示されている。
この問題はテストオーバーフィッティングと呼ばれ、大きな言語モデルが出現する前に特定され研究されている。
リポジトリレベルのSWE-benchタスクを使用して、テストオーバーフィッティングがまだ問題であるかどうかを実験的に検討する。
論文 参考訳(メタデータ) (2025-11-20T23:55:56Z) - ImpossibleBench: Measuring LLMs' Propensity of Exploiting Test Cases [58.411135609139855]
タスク完了のための「ショートカット」は、大規模言語モデルの信頼性評価と展開に重大なリスクをもたらす。
我々は,LLMエージェントがテストケースを利用するための正当性を測定するベンチマークフレームワークであるImpossibleBenchを紹介する。
実践的なフレームワークとして、ImpossibleBenchは単なる評価ではなく、汎用的なツールである。
論文 参考訳(メタデータ) (2025-10-23T06:58:32Z) - Measuring the Influence of Incorrect Code on Test Generation [22.168699378889148]
間違ったコードエクスペリエンスのために生成されたテストは、バグ検出率を47%上回っている。
+18%の精度、+4%のカバレッジ、+34%のバグ検出の改善は、自然言語によるコード記述を提供することで達成できる。
論文 参考訳(メタデータ) (2024-09-14T15:17:34Z) - TestART: Improving LLM-based Unit Testing via Co-evolution of Automated Generation and Repair Iteration [7.509927117191286]
大規模言語モデル(LLM)は、単体テストケースを生成する際、顕著な能力を示した。
本研究では,新しい単体テスト生成法であるTestARTを提案する。
TestARTは、自動生成と修復の反復の共進化を通じて、LLMベースのユニットテストを改善している。
論文 参考訳(メタデータ) (2024-08-06T10:52:41Z) - GPT-HateCheck: Can LLMs Write Better Functional Tests for Hate Speech Detection? [50.53312866647302]
HateCheckは、合成データに対してきめ細かいモデル機能をテストするスイートである。
GPT-HateCheckは,スクラッチからより多彩で現実的な機能テストを生成するフレームワークである。
クラウドソースのアノテーションは、生成されたテストケースが高品質であることを示しています。
論文 参考訳(メタデータ) (2024-02-23T10:02:01Z) - Auditing AI models for Verified Deployment under Semantic Specifications [65.12401653917838]
AuditAIは、解釈可能な形式検証とスケーラビリティのギャップを埋める。
AuditAIは、画素空間の摂動のみを用いた検証の限界に対処しながら、検証と認定トレーニングのための制御されたバリエーションを得られるかを示す。
論文 参考訳(メタデータ) (2021-09-25T22:53:24Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト(すべての情報・翻訳含む)の品質を保証せず、本サイト(すべての情報・翻訳含む)を使用して発生したあらゆる結果について一切の責任を負いません。