idea_world_labDEV JOURNAL
2026年6月17日水曜日

2026-06-17 Godot RAG 判別器 -> Qwen 3.6 コーディングモデル 開発フロー メモ

構造画像

Godot RAG 判別器から Qwen 3.6 コーディングモデルへの開発フロー

コアフロー

Godot 公式ドキュメントの準備  
-> 第1段階のチャンク化  
-> Godot 専用の後処理  
-> ローカル検索インフラの構築  
-> GitHub データの収集と構造化  
-> RAG 判別器の実行  
-> 学習データセットの作成  
-> Qwen 3.6 コーディングモデルの学習

このメモは、まず Godot RAG 判別器を作成し、その判別器を利用して Qwen 3.6 ベースの Godot コーディングモデル学習データセットを生成する MVP フローを整理したものです。

段階概要

1. 公式ドキュメントの準備

  • godot_docs_full.zip を用意
  • 公式ドキュメントのクローリング完了版を使用
  • まだ RAG ではない元データの状態
  • 入力は .md 文書の集合

2. 第一次チャンク化

  • chunk_docs.py を実行
  • 見出し（heading）基準でチャンク化
  • 大きなブロックは max_chars と overlap で再分割
  • 第一次の成果物は docs_chunks.jsonl

3. Godot 専用の後処理

  • Sphinx の残骸を除去
  • symbols を抽出
  • class / method / property のメタデータを追加
  • migration ルールを抽出

成果物:

docs_chunks.jsonl
api_mapping.jsonl
label_prototypes.jsonl

4. ローカル検索インフラ構築

  • Vector DB: 文書埋め込み
  • Keyword Index: 正確検索
  • Reranker: 検索結果再順位付け
  • API Mapping DB / Label Prototype DB

重要な点:

ラベルはシステムが決定する。

5. GitHub データ収集および構造化

  • .gd, .tscn, .tres, project.godot, README の収集
  • repo ツリーの構成
  • コード/シーン/設定ファイルの構造化

成果物:

GitHub Structured Data JSONL

6. RAG 判別器の実行

RAG 判別器はローカルシステムとリモート LLM を併用します。

ローカルシステムの担当:

  • GitHub チャンク入力
  • シンボル抽出
  • ベクトル + キーワード検索
  • リランク
  • ラベル決定

リモート LLM の担当:

  • 修正コード生成
  • 説明生成
  • QA サンプル生成
  • DPO 候補生成

最終 JSON は Python コードが組み立てます。

7. 生成されるデータセット

version_classification
api_mapping
migration_fix
instruction_sft
dpo_preference
repo_explorer
patch_generation
metadata_verification

初期MVPは、1万〜4万サンプルを先に生成しても十分だとまとめました。

8. モデル学習

1次学習:

Qwen 3.6 SFT

目標:

  • Godot 4 を優先的に考える
  • GDScript の基本出力
  • Godot 3 API を拒否

第2次学習:

DPO

目標:

  • Godot 4 の回答の好みを強化

今後の拡張:

SWE 拡張

目標:

  • repo explorer
  • patch
  • trajectory

基本原則

  • 公式文書を基にRAG判別器をまず作成する。
  • ラベルはLLMではなくシステムが決定する。
  • LLMは生成支援のみを担当する。
  • 最終目標はQwen 3.6 Godotコーディングモデルである。