いくつかモデルを試してみたがいまいち精度がよくない。
１年前に戻った感じ。
修正後に一発でビルドが通らないレベル。

Copilotに聞いて下記の回答を得る。
RAG最適化（OpenCodeのMemory強化）
→ モデルをいじらずに精度を上げる方法。
→ 実は多くのケースでこれだけで十分。

以下では、 VRAM16GB向けに最適化された“実用的なRAG構成”を具体的にまとめるね。

🔧 VRAM16GB向け：OpenCodeのRAG最適化の最適解

1. Embeddingモデルは「軽量＋高精度」の中間帯を使う

VRAM16GBだと、以下が最もバランス良い。

推奨モデル（Embedding）

• bge-large-en-v1.5（約1.3GB）
• nomic-embed-text-v1（約1GB）
• jina-embeddings-v2-base（約1.2GB）

これらは

• 高精度
• VRAM消費が少ない
• インデックス構築が高速 という理由で、16GB環境に最適。

❗ 7B〜14BのLLMを同時に動かす場合、EmbeddingはCPU側で動かすのが安定。

2. チャンクサイズは「小さめ＋オーバーラップ」で精度が上がる

VRAMが限られる環境では、チャンクを小さくして検索精度を上げる方が有利。

推奨設定

• chunk_size：300〜500 tokens
• chunk_overlap：50〜80 tokens

理由：

• 小さいチャンクは検索精度が高い
• LLM側のコンテキスト消費が減る
• VRAM16GBでも長いコンテキストを扱いやすい

3. インデックスは「分割＋階層化」で高速化する

VRAM16GBでは巨大インデックスを一括ロードすると重いので、 分割インデックス（sharding）が効果的。

推奨構成

• 言語別に分割（例：Python / TypeScript / Docs）
• ディレクトリ単位で分割（src / tests / utils）
• 階層化（ファイル→ディレクトリ→プロジェクト）

OpenCodeのMemoryは階層化と相性が良く、 「必要な部分だけロード」できるためVRAM節約になる。

4. キャッシュを強化すると体感速度が倍になる

VRAM16GBだと、キャッシュ戦略が非常に効く。

推奨設定

• embeddingキャッシュ（SQLite / LMDB）
• 検索結果キャッシュ（Redis）
• LLM応答キャッシュ（OpenCodeのAuto Memory）

特にAuto Memoryは、 「同じリポジトリでの反復作業」 に強く、VRAMが少ない環境ほど効果が大きい。

5. LLM側は「8B〜14B」を使うと最も安定

VRAM16GBなら以下が最適帯。

推奨LLM（ローカル）

• Llama 3.1 8B Instruct
• Qwen2.5 7B / 14B
• Phi-4 14B
• DeepSeek-R1 7B（コード精度高）

これらは

• コード生成精度が高い
• VRAM16GBで安定動作
• RAGとの相性が良い という理由でOpenCodeに向いている。

🧠 最終構成（VRAM16GB向けの“最適RAGセットアップ”）

✔ Embedding

• bge-large-en-v1.5（CPU実行）

✔ チャンク

• chunk_size：400
• chunk_overlap：60

✔ インデックス

• 言語別＋ディレクトリ別の分割
• 階層化インデックス

✔ キャッシュ

• embedding：SQLite
• search：Redis
• LLM：Auto Memory（OpenCode）

✔ LLM

• Llama3.1 8B または Qwen2.5 14B

この構成は、 VRAM16GBでも大規模リポジトリを高速・高精度で扱える という実績のある組み合わせ。

つづく