私は、LLMを実際のコードベースに使う際に繰り返しぶつかっていた問題を試行錯誤していました:
良いプロンプトであっても、大規模リポジトリはコンテキストに収まりません。そのため、モデルは: - 重要なファイルを見落とす - 不完全な情報に対して推論する - 複数回のリトライが必要になる
私が検討したアプローチ
埋め込み(embeddings)やRAGの代わりに、もっと単純な方法を試しました:
構造の手がかりだけを抽出:
- 関数
- クラス
- ルート
軽量なインデックスを構築(外部依存なし)
クエリごとにファイルを次でランク付け:
- トークンの重なり
- 構造の手がかり
- 基本的なヒューリスティック(新しさ、依存関係)
小さな「コンテキスト層」を出力(約2Kトークン。~80Kではなく)
観察結果
複数のリポジトリにわたって:
- コンテキストサイズが約97%減少
- 関連ファイルがトップ5に現れる割合が約70〜80%であった
- タスクごとのリトライ回数が目に見えて減った
最大の学び:
多くのケースで、構造化されたコンテキストの方がモデルのサイズより重要でした。
興味深い制約
私は意図的に避けました: - 埋め込み - ベクタDB - 外部サービス
すべてローカルで動作し、シンプルなパースとランキングのみで完結します。
未解決の問い
- ヒューリスティックによるランキングは、埋め込みが必要になるまでどれくらいの距離まで行けるのか?
- 構造 + 埋め込みのハイブリッド手法を試した人はいるのか?
- 回答が、提示されたコンテキストに根拠づけられていることを検証する最善の方法は何か?
[link] [comments]




