2026-06-17 Godot RAG 判別器ベース データ生成構造 メモ

構造画像

核心アイデア

この構造の核心は LLM に最終ラベル決定を任せないことです。LLM は修正コード、説明、SFT 質問/回答、DPO 悪い回答、パッチ草案などの生成補助役割を担い、実際のラベルと最終 JSONL の組み立て/検証はローカルシステムのパイプラインが決定します。

整理すると次の原則です。

LLMは生成補助  
ラベルはシステムが決定  
最終JSONLはパイプラインが組み立て/検証

全体の流れ

文書準備
-> ローカルDB構築
-> GitHub ソースデータ入力
-> シンボル抽出
-> ルール/ベクトル/キーワード検索
-> ラベルスコアリングおよび決定
-> LLM生成支援
-> 最終JSONL生成

この構造は Godot 3/4 の分類、API マッピング、マイグレーション修正、instruction SFT、DPO 優先度、repo explorer、パッチ生成、メタデータ検証 データを 1 つのパイプラインで作成するための草案です。

1. 文書の準備

オフライン段階で Godot 公式文書を収集し、精製する。

• Godot 公式文書の収集
• 不要な文句の除去
• 文書タイプの分類
• 構造ベースのパース
• 文書チャンクの生成
• 埋め込みおよびインデックスの構築

生成される基本的な成果物:

docs_chunks.jsonl

2. 構築される3つの主要DB

API マッピング DB

Godot 3 API と Godot 4 API の変更関係を保存する。

例:

KinematicBody2D -> CharacterBody2D
yield -> await
export var -> @export
move_and_slide(v) -> move_and_slide()

保存ファイル:

api_mapping.jsonl

公式ドキュメント ベクトル DB

ドキュメントのチャンクを埋め込み、根拠検索用のベクトル DB を作成する。

用途:

• 関連公式ドキュメントのチャンク検索
• 変換根拠の提供
• API 変更理由の説明
• 幻覚（hallucination）削減

ラベル プロトタイプ DB

ラベル候補と類似度検索のためのプロトタイプを保存する。

例示ラベル:

godot3_code
godot4_code
mixed_code
broken_code

保存ファイル:

label_prototypes.jsonl

3. 検索/ラベル決定

GitHubで収集した原データが入ってきたら、まずコードとドキュメントをシステムが分析します。

入力例：

repo: owner/repo
file_path: scripts/Player.gd
content: ...
repo_tree: ...

システムはシンボルを抽出します。

例:

KinematicBody2D
move_and_slide(velocity)
export var
yield

その後、次の検索を実行する。

• API マッピング DB の照会
• 公式ドキュメント ベクトル DB の検索
• ラベル プロトタイプ DB の検索

最終ラベルは LLM ではなくシステムスコアリングで決定する。

例：

label: godot3
confidence: 0.93
bad_apis:
  - KinematicBody2D
  - move_and_slide(v)
  - export var
replacement_apis:
  - CharacterBody2D
  - move_and_slide()
  - @export

4. LLM 生成補助

LLMはラベルを直接決定せず、システムが決定したラベルと根拠を入力として受け取り、生成作業を補助します。

可能な生成作業:

• 修正コード生成
• 説明/根拠生成
• SFT 質問/回答生成
• DPO 悪い回答生成
• ファイル探索正解生成
• パッチ生成補助
• 検証/問題点分析

重要な点は次のとおりです。

LLM生成結果は草案です。  
ラベル、最終スキーマ、confidence、検証の有無はシステムが管理します。

5. 最終 JSONL 生成

パイプラインはシステム結果と LLM 生成結果を 1 つの JSON オブジェクトに組み立てる。

検証段階では次を確認する。

• 必須フィールドの有無
• ラベルの一貫性
• 誤った API の残存有無
• confidence の再計算
• 文書根拠と出力の連結性

生成される 8 つのデータセット

1. バージョン分類データ

ファイル:

version_classification.jsonl

内容:

• Godot 3/4/mixed/broken 分類
• valid_for_godot4 判定
• bad_apis 抽出

2. API マッピング データ

ファイル:

api_mapping.jsonl

内容:

• old_api -> new_api マッピング
• change_type, category など

3. 変換/修正 正解データ

ファイル:

migration_fix.jsonl

内容:

• before/after コード
• 変更理由
• 設定一覧

4. 質問/回答 SFT データ

ファイル:

instruction_sft.jsonl

内容:

• instruction/input/output
• さまざまなパターンのサンプル

5. DPO 好みデータ

ファイル:

dpo_preference.jsonl

内容:

• chosen
• rejected
• 理由/条件

6. Repo Explorer データ

ファイル:

repo_explorer.jsonl

内容:

• 作業/エラー解決のために読むべきファイルの予測
• 読むべき理由

7. パッチデータ

ファイル:

patch_generation.jsonl

内容:

• before/after
• unified diff / patch
• 適用理由

8. メタ/検証情報

ファイル:

metadata_verification.jsonl

• 信頼度
• スコア
• 根拠
• 出典文書チャンクID
• 品質/リスク情報

実行要約フロー

GitHub ソースデータ
-> シンボル抽出
-> ルール/DB 検索
-> ラベルスコアリング
-> LLM 生成支援
-> 最終 JSON 組み立ておよび保存

基本原則

• ラベルはシステムが決定する。
• LLMは生成支援の役割のみを担う。
• 最終 JSONL はパイプラインが組み立てて検証する。
• 根拠文書、スコア、confidence、出典情報を一緒に保存する。
• 誤った Godot 3 API が残っていないか必ず検査する。