2026年6月12日金曜日2026 年 6 月 12 日
- 久しぶりに開発振り返りを書き直すことにした
- それまで「完璧な記録だけを残したい」という思いが強すぎて、かえって記録を先延ばしにしていた
- 過去約 10 日間で行った試みや考察を意味ある形で残すため、Godot 特化コーディングモデルを作るための調査とアーキテクチャ設計プロセスをまとめた
- RunPod の使用料を削減するため、ローカル PC に Qwen 系列モデルを配置する実験を実施
- RTX 3060 環境で 9B モデルを WSL 上で動かそうとした
- しかしネットワーク接続速度と応答遅延の問題が深刻で、実際に回答を生成する前の思考段階だけで 5 分以上かかり、ローカル実行実験は中止した
- Godot 特化モデル学習のため、まずデータセット収集方法を調査
- Hugging Face の
wallstoneai/godot-gdscript-dataset を参照データセットとして確認
- Gemini を使ってそのデータセットがどのように作られたかを分析
- キーとなるのは GitHub リポジトリ単位で README.md、
.gd ファイル、プロジェクト構造を一つのテキストに統合し、project.godot 設定ファイルと GDScript 文法の違いを利用して Godot 3/4 バージョンを分類する方式だった
- 特に
config_version、config/features、onready var、@onready、KinematicBody、CharacterBody3D といったバージョン別の手掛かりを活用すれば、JSON ベースの依存ファイルがないマイナー言語でもバージョンフィルタリングが可能だという洞察を得た
- ファインチューニングの流れを理解するため、OPL という古典的プログラミング言語を対象にしたファインチューニング動画を参照
- SSAFY のコーチに、特定バージョンのマイナー言語データを効果的に収集する方法を質問
- 現在参照している Godot データセットは assistant 学習用 Q&A データセットというより raw コードデータセットに近いという回答を得た
- チャットボット形式の製品を作るなら raw データをそのまま入れるより、LLM を利用して質問/回答ペアを生成し、instruction データセットとして加工すべきという方向性を固めた
- このプロセスを経ないと「マップを設計してほしい」などのリクエストに対し、既存モデルが多く学習した Python 中心の回答を生成する可能性が高いと判断した
- instruction データセット候補として
ise-uiuc/Magicoder-Evol-Instruct-110K を確認
- 大半が Python 中心で書かれているため、Godot 4 専用学習データとしてそのまま使用するには適さないと判断
- 「Godot を明示しなくても Godot の回答を出すようにできるか？」という疑問を抱いたが、既存モデルの Python ウエイトが大きいため、質問に
Godot という文脈を明確に与えることが正解の可能性を高める方向だと整理した
- 学校の先輩に RAG とプロンプティングの方向性について相談
- 全データをモデルに投入するより、Markdown 文書ベースのベクトル検索構造を作り、必要なデータを探させるガイドを作る方式の方が現実的かもしれないという助言を受けた
- 大規模文書をすべて再インデックスするコストと時間が大きいため、現段階では学習より検索/プロンプティングベースの構造が適していると判断した
- Godot 特化コーディングモデルを作るための初期アーキテクチャを設計
- 当初は
データセット収集 → 質問/正解データセット生成 → モデル学習 というシンプルな構造を考えた
- しかし Godot 3 から 4 への変更点を十分に把握しなければ、正確なフィルタリングと正解データ生成ができないという問題があった
- 間違えて Godot 3 コード、Python コード、旧バージョン API が正解データに混ざる恐れがあると判断し、アーキテクチャを再考した
- Godot 3/4 バージョン分類と変換のため、公式ドキュメントベースの RAG チャットボットを前段に配置する構造を設計
- Godot 公式マイグレーションドキュメントと Godot 4 ドキュメントをクロールして RAG チャットボットを作り、このチャットボットで収集データが Godot 3 か 4 かを分類する方向を思いついた
- その後、Godot 4 と判定されたデータのみを instruction データセットとして加工する流れを構想した
- ChatGPT を通じて追加的に SFT/DPO 学習方向に関する洞察を得た
- SFT では Godot 3/4 分類、Godot 3 → 4 変換、Godot 4 コード生成、Godot 4 エラー修正、Godot 3 API 拒否/修正 といったタスクを作成できる
- DPO/Preference では
悪い回答 = Godot 3 コードが混ざった回答、良い回答 = Godot 4 純粋コード回答 として好みデータを構成できるという方向性を整理した
unclecode/crawl4ai を使用して Godot 公式ドキュメントのクロールを実施
- データ保存と学習パイプラインのディスク I/O ボトルネックについて、学校の先輩に追加相談
- リアルタイムでファインチューニングを回すより、データ確保と前処理/後処理をリアルタイムに近い形で行い、学習はバッチ方式で実施した方が良いという助言を受けた
- データセットが一定量以上蓄積されたときに強化学習またはファインチューニングを実行する方式で、メトリクスベースのバッチ処理を検討することにした
- 再インデックスコストは構造的に完全に排除できないため、学習のリアルタイム性よりデータ確保と加工パイプラインの安定性が重要だと整理した
- 現在整理した全体方針
- 公式ドキュメントをクロールして Godot 4 基準の RAG 知識ベースを構築
- GitHub の Godot プロジェクトを収集し、リポジトリ単位で README、プロジェクト構造、GDScript ファイルを統合
project.godot 設定と Godot 3/4 文法の違いを利用して一次フィルタリング - RAG チャットボットで Godot 3/4 判定、旧バージョン API 使用有無、Godot 4 適合性を追加判定
- Godot 4 に精製されたデータから instruction/response データを生成
- SFT と DPO/Preference データで Godot 4 コーディングモデルを学習
- 振り返り
- 過去 10 日間、完成した成果物だけを残そうとしたため、むしろ過程を記録できなかった
- しかし失敗した実験、詰まったポイント、途中で変わった判断こそが次の方向性を決める重要な記録だと感じた
- 今後は完璧な結果だけを残すのではなく、試行と判断の流れを継続的に残しながら成長していくことにする
- 開発振り返り: docs/retrospectives/2026-06-12.md