2026年6月14日日曜日2026 年 6 月 14 日
- ソウルへ向かうバスの中で Godot 4 データセット/RAG パイプラインに関する疑問を再整理
- 以前は Godot 公式文書をクローリングし、GitHub プロジェクトを
md, jsonl 形式に変換した後 RAG チャットボットで Godot 3/4 を判別する構造を考えていた
- しかし実際にはプロジェクト全体の文脈と検索された公式文書の断片を一度にモデル入力コンテキストに入れられるか疑問が生じた
- RAG チャットボット作成時の入力コンテキストの限界を検討
- 1 つの GitHub プロジェクトにも README、ディレクトリ構造、複数の
.gd ファイル、シーンファイル、リソースパスが含まれる
- そこに RAG で検索された公式文書まで加えると入力が膨大になるため、単に文書を多く集めるよりもどのファイルと文書断片を選別するか設計する方が重要と判断
- 質問/回答データセットの形態に関する疑問を整理
- 「マップを作って」などの要求は単なる回答コード一つで終わる問題ではない可能性がある
- 実際にはプロジェクト構造の把握、使用アセットの確認、既存コードスタイルの分析、Godot 4 文法の検証、修正ファイルの決定といった複数の推論ステップが必要
- したがって instruction データセットに最終コードだけを入れるだけで十分か、探索と判断過程もデータとして残すべきか検討
- チャンク単位処理中に Python の重みが再び強くなる可能性を検討
- 「Godot 4 でマップを作って」と要求しても、モデルがプロジェクトと文書をチャンク単位で読む過程で Python 中心の事前学習重みが再び表面化する可能性があると考えた
- Godot 4 の文脈をプロンプトの前段で強く注入し、データ前処理段階で Godot 3 のコードや Python 風の回答が混入しないようより強くフィルタリングする必要を感じた
- 本日のまとめ
- RAG やクローリング自体が解決策ではなく、重要なのはモデルが実際の要求でどの文脈を読み取りどのように判断させるかを設計すること
- プロジェクトコンテキストをファイル/役割/依存性基準で分割し、instruction データには最終回答だけでなく必要に応じて探索と判断の流れも含める方向で検討することにした
- Godot 4 の文脈が推論過程で希釈されないよう、プロンプト、タグ、フィルタリング、好みデータ基準をより強く設計する必要がある
- 開発回顧: docs/retrospectives/2026-06-14.md