埋め込みやベクタDBなしで、LLMのコンテキストを約8万トークンから約2千トークンに減らす

Reddit r/artificial / 2026/4/19

💬 オピニオンDeveloper Stack & InfrastructureIdeas & Deep AnalysisTools & Practical Usage

要点

  • この記事では、埋め込みやベクターデータベースを使わずに、LLMの入力コンテキストを約8万トークンから約2千トークンへ削減する実験を紹介している。
  • RAGの代わりに、関数・クラス・ルートといった構造的シグナルを抽出し、外部依存なしのローカルなインデックスを作成したうえで、クエリごとにファイルをトークン重なり・構造一致・更新の新しさや依存関係などの単純なヒューリスティックでランキングする。
  • こうして生成する「コンテキスト層」は小さく保たれつつ、関連ファイルを見つけやすい形で提示できるとしている。
  • 複数リポジトリでの観察では、コンテキストを約97%削減でき、関連ファイルが上位5件に入る割合が約70〜80%だったほか、タスクあたりのリトライ回数が明らかに減ったとしている。
  • 著者は、多くの実務的なコーディング場面では“構造化されたコンテキスト”がモデルのサイズ以上に重要になり得ると結論づけつつ、ヒューリスティックの限界や、提供されたコンテキストに根拠づけられていることの検証方法などを課題として挙げている。

私は、LLMを実際のコードベースに使う際に繰り返しぶつかっていた問題を試行錯誤していました:

良いプロンプトであっても、大規模リポジトリはコンテキストに収まりません。そのため、モデルは: - 重要なファイルを見落とす - 不完全な情報に対して推論する - 複数回のリトライが必要になる


私が検討したアプローチ

埋め込み(embeddings)やRAGの代わりに、もっと単純な方法を試しました:

  1. 構造の手がかりだけを抽出:

    • 関数
    • クラス
    • ルート
  2. 軽量なインデックスを構築(外部依存なし)

  3. クエリごとにファイルを次でランク付け:

    • トークンの重なり
    • 構造の手がかり
    • 基本的なヒューリスティック(新しさ、依存関係)
  4. 小さな「コンテキスト層」を出力(約2Kトークン。~80Kではなく)


観察結果

複数のリポジトリにわたって:

  • コンテキストサイズが約97%減少
  • 関連ファイルがトップ5に現れる割合が約70〜80%であった
  • タスクごとのリトライ回数が目に見えて減った

最大の学び:

多くのケースで、構造化されたコンテキストの方がモデルのサイズより重要でした。


興味深い制約

私は意図的に避けました: - 埋め込み - ベクタDB - 外部サービス

すべてローカルで動作し、シンプルなパースとランキングのみで完結します。


未解決の問い

  • ヒューリスティックによるランキングは、埋め込みが必要になるまでどれくらいの距離まで行けるのか?
  • 構造 + 埋め込みのハイブリッド手法を試した人はいるのか?
  • 回答が、提示されたコンテキストに根拠づけられていることを検証する最善の方法は何か?

submitted by /u/Independent-Flow3408
[link] [comments]