2026年6月17日水曜日2026 年 6 月 17 日
- Godot 4 コーディングモデルの方向性を、単なる Q&A 学習ではなく SWE エージェントのトラジェクトリ学習の観点で再整理
- 小さな instruction Q&A だけでは「マップを作って」などのプロジェクト単位の要求を処理しにくいと判断
- 実際のコーディングエージェントはリポジトリ探索、関連ファイル選択、コード修正、テスト/検証、パッチ生成まで続くトラジェクトリが必要と整理
- 関連キーワードとして
Long-context repository-level software engineering agent training, SWE-agent trajectory training を記録
- 参考事例として SWE-agent trajectories, SWE-smith, SWE-Gym, CoderForge-Preview, ACC, RepoBench/CrossCodeEval/RepoCoder, aiXcoder CoLT, godot-dodo, wallstoneai dataset を整理
- Godot LLM 開発全体ロードマップを画像と文書で記録
- 全体フローを
データ -> 1次 RAG チャットボット -> SFT -> DPO -> SWE Agent の段階で整理
- Stage 0 準備段階から Stage 6 継続的改善まで分け、データ収集/構造化、1次 RAG チャットボット、データラベリング、モデル学習、SWE Agent 開発、運用/再学習の流れを記録
- 重要なのは 1次 RAG チャットボットをまず Godot 文書の専門家にし、そのチャットボットを使って GitHub データをラベリング/加工した後にモデル学習と SWE Agent に拡張すること
- Godot RAG 判別器ベースのデータ生成構造をメモとして追加
- LLM に最終ラベル決定を任せず、ラベルと検証はシステムパイプラインが決定する構造で整理
- LLM は修正コード、説明、SFT 質問/回答、DPO の悪い回答、パッチ草案など生成支援役のみを担う方向で設計
- API マッピング DB、公式文書ベクトル DB、ラベルプロトタイプ DB を基にシンボル抽出、検索、ラベルスコアリング、JSONL 組み立て/検証まで続くフローを記録
- 生成対象データセットを version classification, api mapping, migration fix, instruction SFT, DPO preference, repo explorer, patch generation, metadata verification の 8 種類に整理
- Godot RAG 判別器から Qwen 3.6 コーディングモデルへつながる MVP 開発フローを別メモで整理
godot_docs_full.zip の原本文書準備から chunk_docs.py ベースの 1次チャンク化、Godot 専用後処理、ローカル検索インフラ構築までの流れを記録- Vector DB、Keyword Index、Reranker、API Mapping DB、Label Prototype DB を組み合わせ、ラベルをシステムが決定する構造で整理
- GitHub データを構造化した後 RAG 判別器を実行し、LLM は修正コード/説明/QA サンプルなど生成支援役のみを担うよう役割を分離
- 1次 Qwen 3.6 SFT では Godot 4 を優先的に扱い、GDScript の基本出力、Godot 3 API の拒否を目標とし、以降 DPO と SWE 拡張へつながるフローを記録
- GitHub 緑のブランチ（貢献）反映問題を解決するために Git author/email 設定を整理
- グローバル Git 設定を
yyeongjin <appsky1888@gmail.com> に変更
- 既存の
main 履歴の author/committer メールがローカルホストメール、naver メール、GitHub noreply など混在していた問題を確認
main 履歴の author/committer を yyeongjin <appsky1888@gmail.com> に統一し、リモートに反映- 書き換え前の状態はローカルバックアップブランチ
backup/before-author-email-rewrite-2026-06-17 に保管
- 記録文書