<p class="wp-block-paragraph">いくつかモデルを試してみたがいまいち精度がよくない。<br>１年前に戻った感じ。<br>修正後に一発でビルドが通らないレベル。<br></p> <p class="wp-block-paragraph">Copilotに聞いて下記の回答を得る。<br><strong>RAG最適化（OpenCodeのMemory強化）</strong> <br>→ モデルをいじらずに精度を上げる方法。 <br>→ 実は多くのケースでこれだけで十分。</p> <p class="wp-block-paragraph">以下では、 <strong>VRAM16GB向けに最適化された“実用的なRAG構成”</strong>を具体的にまとめるね。</p> <h1 class="wp-block-heading">🔧 VRAM16GB向け：OpenCodeのRAG最適化の最適解</h1> <h2 class="wp-block-heading">1. <strong>Embeddingモデルは「軽量＋高精度」の中間帯を使う</strong></h2> <p class="wp-block-paragraph">VRAM16GBだと、以下が最もバランス良い。</p> <h3 class="wp-block-heading">推奨モデル（Embedding）</h3> <ul class="wp-block-list"> <li><strong>bge-large-en-v1.5（約1.3GB）</strong></li> <li><strong>nomic-embed-text-v1（約1GB）</strong></li> <li><strong>jina-embeddings-v2-base（約1.2GB）</strong></li> </ul> <p class="wp-block-paragraph">これらは</p> <ul class="wp-block-list"> <li>高精度</li> <li>VRAM消費が少ない</li> <li>インデックス構築が高速 という理由で、16GB環境に最適。</li> </ul> <blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow"> <p class="wp-block-paragraph">❗ 7B〜14BのLLMを同時に動かす場合、Embeddingは<strong>CPU側で動かす</strong>のが安定。</p> </blockquote> <h2 class="wp-block-heading">2. <strong>チャンクサイズは「小さめ＋オーバーラップ」で精度が上がる</strong></h2> <p class="wp-block-paragraph">VRAMが限られる環境では、<strong>チャンクを小さくして検索精度を上げる方が有利</strong>。</p> <h3 class="wp-block-heading">推奨設定</h3> <ul class="wp-block-list"> <li><strong>chunk_size：300〜500 tokens</strong></li> <li><strong>chunk_overlap：50〜80 tokens</strong></li> </ul> <p class="wp-block-paragraph">理由：</p> <ul class="wp-block-list"> <li>小さいチャンクは検索精度が高い</li> <li>LLM側のコンテキスト消費が減る</li> <li>VRAM16GBでも長いコンテキストを扱いやすい</li> </ul> <h2 class="wp-block-heading">3. <strong>インデックスは「分割＋階層化」で高速化する</strong></h2> <p class="wp-block-paragraph">VRAM16GBでは巨大インデックスを一括ロードすると重いので、 <strong>分割インデックス（sharding）</strong>が効果的。</p> <h3 class="wp-block-heading">推奨構成</h3> <ul class="wp-block-list"> <li><strong>言語別に分割（例：Python / TypeScript / Docs）</strong></li> <li><strong>ディレクトリ単位で分割（src / tests / utils）</strong></li> <li><strong>階層化（ファイル→ディレクトリ→プロジェクト）</strong></li> </ul> <p class="wp-block-paragraph">OpenCodeのMemoryは階層化と相性が良く、 「必要な部分だけロード」できるためVRAM節約になる。</p> <h2 class="wp-block-heading">4. <strong>キャッシュを強化すると体感速度が倍になる</strong></h2> <p class="wp-block-paragraph">VRAM16GBだと、キャッシュ戦略が非常に効く。</p> <h3 class="wp-block-heading">推奨設定</h3> <ul class="wp-block-list"> <li><strong>embeddingキャッシュ（SQLite / LMDB）</strong></li> <li><strong>検索結果キャッシュ（Redis）</strong></li> <li><strong>LLM応答キャッシュ（OpenCodeのAuto Memory）</strong></li> </ul> <p class="wp-block-paragraph">特にAuto Memoryは、 「同じリポジトリでの反復作業」 に強く、VRAMが少ない環境ほど効果が大きい。</p> <h2 class="wp-block-heading">5. <strong>LLM側は「8B〜14B」を使うと最も安定</strong></h2> <p class="wp-block-paragraph">VRAM16GBなら以下が最適帯。</p> <h3 class="wp-block-heading">推奨LLM（ローカル）</h3> <ul class="wp-block-list"> <li><strong>Llama 3.1 8B Instruct</strong></li> <li><strong>Qwen2.5 7B / 14B</strong></li> <li><strong>Phi-4 14B</strong></li> <li><strong>DeepSeek-R1 7B（コード精度高）</strong></li> </ul> <p class="wp-block-paragraph">これらは</p> <ul class="wp-block-list"> <li>コード生成精度が高い</li> <li>VRAM16GBで安定動作</li> <li>RAGとの相性が良い という理由でOpenCodeに向いている。</li> </ul> <h1 class="wp-block-heading">🧠 最終構成（VRAM16GB向けの“最適RAGセットアップ”）</h1> <h3 class="wp-block-heading">✔ Embedding</h3> <ul class="wp-block-list"> <li>bge-large-en-v1.5（CPU実行）</li> </ul> <h3 class="wp-block-heading">✔ チャンク</h3> <ul class="wp-block-list"> <li>chunk_size：400</li> <li>chunk_overlap：60</li> </ul> <h3 class="wp-block-heading">✔ インデックス</h3> <ul class="wp-block-list"> <li>言語別＋ディレクトリ別の分割</li> <li>階層化インデックス</li> </ul> <h3 class="wp-block-heading">✔ キャッシュ</h3> <ul class="wp-block-list"> <li>embedding：SQLite</li> <li>search：Redis</li> <li>LLM：Auto Memory（OpenCode）</li> </ul> <h3 class="wp-block-heading">✔ LLM</h3> <ul class="wp-block-list"> <li>Llama3.1 8B または Qwen2.5 14B</li> </ul> <p class="wp-block-paragraph">この構成は、 <strong>VRAM16GBでも大規模リポジトリを高速・高精度で扱える</strong> という実績のある組み合わせ。</p> <p class="wp-block-paragraph">つづく</p>