idea_world_labDEV JOURNAL
2026年7月15日水曜日

Qwen Validation Debugger 合成データ E2E 契約

作成日: 2026年 7月 15日

文書の目的

Qwen Validation Debugger は、運用用 Retriever と検証器が完成する前に合成データで全体フローをテストするツールです。

1 つのテストテーマについて Godot 3 のコードと Godot 4 のコードを作成し、そのコードに合う JSONL と合わない JSONL を生成します。その後、同じ JSONL を各バージョンのコードに適用し、最終判定が 예 または 아니오（日本語では「はい」または「いいえ」）として正しく出力されるか確認します。

既存の応答スキーマと判定種類は変更していません。

  • 文法範囲: common, separate
  • JSONL テーブル: docs_chunks, api_mapping, label_prototypes
  • スロット: positive, negative
  • 最終判定: 예, 아니오

第3の判定値、スコア、追加理由フィールドは作成していません。

全体フロー

TEST_ITEM
  -> common / separate 分類
  -> 分類結果の保存
  -> 対象バージョンコードの生成
  -> 実際の Godot エンジンパーサーの検査
  -> Qwen のはい/いいえコード検査
  -> 合格したコードのみで JSONL を生成
  -> 既存の JSON Schema の検査
  -> 現在のコードと直接証拠の検査
  -> JSONL とコードの交差検証

separate 項目は Godot 3 のコードを先に作成します。Godot 4 のコードはその Godot 3 のコードを REFERENCE_GODOT3_CODE として受け取り、同じ機能と実行フローを維持した対応コードとして生成されます。

分類とコード生成入力の分離

分類の応答は既存の五つのフィールドを維持します。

{
  "syntax_scope": "common 또는 separate",
  "label": "짧은 한국어 라벨",
  "reason": "분류 근거",
  "godot3_focus": "Godot 3 코드 생성 포인트",
  "godot4_focus": "Godot 4 코드 생성 포인트"
}

reason、godot3_focus、godot4_focusは画面表示と記録には残すが、コード生成プロンプトには渡さない。分類段階で誤ったバージョン文法を説明したとしても、その文が次のコード生成の事実根拠とならないようにするためである。

コード生成には次の入力だけを使用する。

  • テスト項目
  • common または separate
  • 生成対象バージョン
  • separate Godot 4 生成時に先に通過した Godot 3 コード
  • 再試行時に直前の拒否コードと実際の検査診断

合成コード契約

生成コードはコード片のように見える文字列ではなく、エンジンがパースできる 1 つの GDScript ファイルである必要がある。

  • 最初の実行文は extends 宣言である。
  • テスト API を実際に所有しているクラスを使用する。
  • 通常の関数は他の関数の中に入れ子にしない。
  • テスト項目の実際の動作 API を使用する。
  • pass、コメント、ローカル call で対象の動作を真似しない。
  • 逆バージョン専用文法をコメントやコードに混在させない。
  • Godot 4 のコードは先に通過した Godot 3 のコードと機能、入力、対象、結果を保持する。

RPC のようにバージョンごとに文法が明確に異なる項目は、公式文法契約をプロンプトに提供する。これは生成結果の単語を事後置換するロジックではない。生成されたソース文字列を任意に修正せず、そのままエンジンパーサに入れる。

実際の Godot エンジン検査

Qwen が自分のコードを再評価するだけでは誤った文法を通過させることができた。実際のテストでは、Godot 3 のコードに Godot 4 の @rpc が入っていても Qwen 検査器が「はい」と答えた事例があった。

現在はコード生成直後に実際のエンジンを実行する。

Godot 3: --no-window --check-only --script  
Godot 4: --headless --check-only --script  
common: Godot 3とGodot 4の両方を検査

実行ファイルは GODOT3_BIN、GODOT4_BIN で指定できる。ローカルのデフォルトインストールはリポジトリ外のユーザーデータディレクトリに置く。検査するコードは一時ファイルとしてのみ作成し、検査後に削除する。診断ログでは一時パスとユーザーホームパスを除去する。

コード生成と検査は最大で三回実行する。失敗した場合は同じ応答を繰り返さないようにシードを変更し、直前のコードと実際のエンジン診断を次の生成プロンプトに入れる。

JSONL スキーマの維持

トップレベルフィールドは既存の三つのテーブル定義と同じである。

docs_chunks

chunk_id, doc_version, source_url, source_file, source_sha256,
doc_type, symbol, section_path, heading, content, code_blocks,
language_tags, godot_version_tags, api_symbols, token_count, metadata

api_mapping

mapping_id, source_api, target_api, change_type, godot_from,
godot_to, confidence, evidence_chunk_ids, match_terms, notes,
negative_patterns

label_prototypes

prototype_id, label, task_type, input_pattern, expected_finding,
recommended_action, evidence_mapping_ids, evidence_chunk_ids,
severity, validator_rules

validator_rulesも既存の4つのフィールドだけを使用します。

{
  "required_when_seen_in_code": [],
  "before_code": "",
  "after_code": "",
  "reject_when_seen_in_code": []
}

応答を受け取った後、既存の JSON Schema で必須フィールド、型、enum、追加フィールドの有無を検査する。モデルが confidence を数値で記述したり section_path を文字列で記述した場合は拒否し、最大三回まで再生成する。

positive と negative の生成

positive JSONL は現在の合成コードの直接的な証拠を使用する。

  • docs_chunks: コードの目的、対象、入力フロー、結果を直接説明する。
  • api_mapping: Godot 3 の source_api と Godot 4 の target_api がそれぞれ実際のコードに存在する必要がある。
  • label_prototypes: before の根拠は Godot 3 のコードに、after の根拠は Godot 4 のコードにある必要がある。
  • positive の negative_patterns と reject_when_seen_in_code は空配列である。

negative JSONL の生成では現在のコードと現在の項目を提供しない。現在の項目の次にあるサンプル項目を動的に NEGATIVE_TEST_ITEM として選択し、その別の項目だけで JSONL を作成する。生成後、サーバーが現在のコードと直接比較し source/before の証拠が重複すれば拒否する。

このプロセスは特定の API 名や文を一対一で置換するものではない。サンプル順序の選択と実際の生成結果の文字列比較のみを使用する。

検証順序

検証は次の順序で処理する。

  1. バージョンスロット構造で結果が確定した場合、モデルを呼び出さずに いいえ と判定する。
  2. マイグレーション変更前の直接的な根拠が現在のコードに一つもない場合、いいえ と判定する。
  3. 上記二条件で確定しない場合にのみ、Qwen が意味と使用方法を比較する。

決定論的ゲートは新しい状態を作らない。返却値は従来通り はい または いいえ である。

JSONL 検証対象 期待応答
同バージョン docs_chunks positive 生成基準コード はい
異バージョン docs_chunks positive クロスバージョンコード いいえ
docs_chunks negative どのコードでも いいえ
3 -> 4 migration positive Godot 3 コード はい
3 -> 4 migration positive Godot 4 コード いいえ
3 -> 4 migration negative どのコードでも いいえ

API リクエストの安定性

  • thinking 出力を無効化する。
  • 分類、コード、JSONL は既存フィールドのみを持つ JSON Schema の応答を要求する。
  • 最終判定は grammar で 예 または 아니오 のみを許可する。
  • コードと JSONL の再生成は seed を変更する。
  • HTTP 429、502、503、504、接続終了、リクエストタイムアウトは最大三回まで再試行する。

API キーはブラウザメモリの現在入力値のみでリクエストに含める。リポジトリ、ドキュメント、ログ、コミットには記録しない。

2026年7月15日 試験結果

単体契約テストは 27 件が合格した。

実際の Godot エンジン検査では以下を確認した。

  • Godot 3 の remote func コードは Godot 3 パーサを通過した。
  • Godot 3 のコードに @rpc を入れると Unexpected '@' で拒否された。
  • Godot 4 の @rpc コードは Godot 4 パーサを通過した。

実際の RunPod Qwen 試験の進行結果は以下の通りである。

  • 初期全体 E2E: 5/12 合格。誤った Godot 3 合成コードと広い関連性判定が確認された。
  • エンジン検査と生成契約適用後の全体 E2E: 10/12 合格。
  • 動的 negative 項目と直接文字列ゲート適用後の migration negative: 4/4 合格。
  • 残りの 2 件は migration positive を Godot 4 に再適用できないというスロット契約をモデルが無視したケースだった。該当条件は決定論的バージョンゲートに移行し、単体テストが合格した。
  • 最終全体再試験を開始したが、RunPod サービスが /v1/models と生成リクエストに HTTP 502 を返し中断された。コードまたは JSONL の拒否ではなく、リモートサービスの無応答である。

リモートサービスが再び応答すれば、同じ 12 カ所の E2E を最初から再実行しなければならない。

参考