なぜRAG開発は評価の仕組みが全てなのか。Claude Codeでコストを28%削減した技術的根拠

RAGを組んで動かしたとき、「これ本当に正しく動いてる？」という壁にぶつかる。モデルやプロンプトを調整しても、測定する仕組みがなければ改善なのかノイズなのか判断できない。

RAG開発において、モデル選びよりも先に評価ハーネス（測定の仕組み）を作る。

揺れのない決定論的な指標で測定軸を固定すると、無駄を削れた割合が明確な数値で分かる。検索精度を維持したままAPI使用量を削減できた割合は28%だ。今回は、トークン最適化からローカル環境のVRAM管理まで、RAG開発の成否を分ける測定の現実を記す。

RAG運用の本質を示す最新検証とハードウェア制約のリアリティ

RAG構築の検証により、システムの成否は「使っているモデルの性能」ではなく、「品質とコストを測定する評価ハーネス」と「コンテキスト長やVRAMの制約管理」にあることが分かった。

システムが「正しいソースを検索できているか」 「嘘の回答を排除できているか」 「1クエリにいくらかかっているか」を自動で数値化する設計が標準化している。

検証データによると、検索エンジンで一般的なハイブリッド検索を素のまま導入すると、キーワードの引っ張られによって正解ページが1位から落ちる現象が確認された。リランカー（再順位付け機能）を安全装置として組み込むことで、難易度の高い質問グループにおける1位検索精度の数値は、66.7%から91.7%へと向上した。

AIに回答の忠実度を判定させる手法（LLM-as-judge）の脆さも浮き彫りになっている。同じコードと入力であっても、実行のたびに評価スコアが上下する振れ幅は±20ptに及ぶ。改善の判断基準には、評価がブレない確定的な指標であるRecallやMRRを採用する。

しんたろー：
評価スクリプトを実行するたびにスコアが20ptもぶれるのは、過去に踏んだ罠だ。LLMにLLMを採点させると情緒不安定さが出る。数字がブレない検索精度だけを信じるのが精神衛生上いい。

Difyなどのノーコード環境を活用した社内向けRAG構築においても、4つのナレッジベースを並列で検索し、プロンプトキャッシングを効かせて応答コストを下げる設計が実践されている。設定ファイル（DSL）の不具合に遭遇した際は、公式ドキュメントに頼るだけでなく、エンジニアが自らソースコードや型定義を解読する。

データ保護やコスト削減を目的にローカル環境でRAGを動かすアプローチでは、ハードウェアの物理的な制約が課題となる。パラメータ数が260億規模のモデルを動かすには、最低でも24GBから32GBのVRAMが必要だ。

費用を抑えるためにVRAMが16GBのGPUを2枚差し込む構成では、マザーボードの通信レーン分割の仕様であるx8/x8動作への対応や、物理的な電源コネクタの干渉といったトラブルが発生する。クラウドのトークン管理からローカルのメモリ配置まで、決定論的な数値でシステム全体を制御する設計手法が求められる。

確率的なAIを決定論的な数値で手懐ける技術

RAG開発において、モデルの回答が毎回ブレることは大きなリスクだ。AIに評価を行わせる手法は手軽だが、同じ入力とコードでもスコアが86.4%から63.6%へと22.8ポイント乱高下するケースがある。

このノイズを「性能向上」と勘違いすると、システムの改善を見誤る。確率的なAIの挙動に振り回されず、Recall@kやMRRといった決定的（Deterministic）な指標を軸に据える。

正解のドキュメントを検索上位に引けたか、答えられない質問に正しく「分かりません」と回答拒否（Abstention）できたか。このブレない数値を測定する評価ハーネスをコードとして構築することが、RAG開発の出発点だ。

しんたろー：
Claude Codeで開発していても、プロンプトを一言変えただけで全体の挙動が変わる。ローカルでテストを自動実行して数字で追える状態を作っておかないと、暗闇で素振りをしている気分になる。ThreadPost開発でも、まずは判定用の評価スクリプトを固めることから始めた。

検索精度を上げるための定説にも罠がある。密検索にキーワード検索を混ぜるハイブリッド検索は万能に見えるが、表層的な単語の一致が邪魔をして、検索最上位の正解率を示すRecall@1が86.4%から72.7%へ下落することすらある。

ここで効いてくるのが、検索結果を再評価するリランカーだ。単語の表面的な一致で浮上した無関係なページを押し下げ、落とした精度を86.4%まで回収する役割を果たす。

難しい質問が混ざる領域では、このリランカーを配置することで正解率が66.7%から91.7%まで跳ね上がる。難易度別のデータで数値を取るからこそ、こうした安全装置の真価が見えてくる。

クラウドAPIのコスト最適化でも、この検索の絞り込みが直結する。無駄なトークンをモデルに渡さない設計と、同じ指示を保持するプロンプトキャッシングの組み合わせが、1リクエストあたりのコストを削り取る。

ローカルRAGの構築を目指す場合、物理的なハードウェアの制約が壁となる。パラメータ数が260億規模のモデルを動かすには、最低でも24GBから32GBのVRAMが必要だ。

費用を抑えようと16GBのGPUを2枚差し込む構成に挑むと、マザーボードの仕様に悩まされる。通信帯域を分けるx8/x8動作に対応したボードを選ばなければ、片方のスロットがx4接続のボトルネックになる。

ケース内でパーツ同士が干渉して電源ケーブルが刺さらないといったトラブルも発生する。VRAM領域の容量計算から基板上のミリ単位の物理配置まで、ローカル運用は物理法則との戦いだ。

Difyのようなノーコードツールを組み込む際も油断はできない。ビジュアル上でノードを繋ぐだけで動く反面、設定ファイル（DSL）の書き出しや高度なカスタマイズでは、ドキュメントの記述が追いついていないエラーに遭遇する。

画面上のエラー表示で手詰まりになったとき、開発者を救うのはGitHub上のソースコードや型定義を直接読み解く力だ。ブラックボックスを恐れず、オープンソースのコードに飛び込んで仕様を解明する。

モデルの選定やプロンプトの工夫といった作業に時間を奪われてはいけない。まずは何をもって正解とするかの評価ハーネスをコードで定義し、クラウドのトークン量やローカルのVRAM容量といった現実的な制約を数字で管理する。この地味な測定の仕組みこそが、RAG開発の成否を分ける根拠になる。

プロンプトをこねる前に測定器を置く。RAG開発で明日から変わる実務

「RAGの精度が上がらない」と悩んだとき、プロンプトの文面を変えたり、最新のモデルに乗り換えたりしたくなる。その前にやるべき作業がある。システムの精度を客観的に計測する評価ハーネスの構築だ。

明日からのRAG開発で意識すべき3つの実務アクションを整理する。

1. 確率的な評価指標を捨て、決定論的な数値だけを信じる

LLMに回答の忠実度（Faithfulness）を採点させると、コードを変えていないのにスコアが大きくぶれる。実際に計測された変動幅は20ポイント以上だ。ノイズの大きい指標をベースに改善を重ねても、偶然を成果と勘違いするリスクがある。

実務で指標として採用するのは、何度実行しても同じ結果が返ってくる決定論的な数値だ。

* Recall@k（検索結果の上位k件に正解が含まれているか）

* MRR（正解ドキュメントが何位にランクインしたか）

* 応答拒否率（答えられない質問に対して正しく「分かりません」と返せたか）

この3つを自動で測定するスクリプトをリポジトリ内に用意する。プロンプトの調整やリランカーの導入は、この測定環境が整ってから行う。

2. コンテキストの物理的限界をコストとVRAMの数字で管理する

RAGの運用コストは、クラウドAPIを使うかローカルLLMで動かすかで直面する課題が変わる。

クラウドAPIを利用する場合、リクエストごとのコンテキスト量が請求金額に直結する。検索上位の件数を無駄に増やさず、プロンプトキャッシュを有効化して重複トークンを削る。Claude Codeを活用してコンテキストの重複を削ぎ落とした結果、コスト削減率は28%だ。

ローカルLLMでRAGを構築する場合は、グラフィックボードのVRAM容量という物理的制約が立ちはだかる。Gemma2 26bクラスのモデルを動かす場合、快適な動作に必要なVRAMの容量は24GBから32GBになる。

コストを抑えるために16GBのグラフィックボードを2枚刺す構成を選ぶなら、マザーボードの仕様チェックが欠かせない。レーン分割が「x8/x8」で動作するか、補助電源コネクタがケース内で物理干渉しないかといった確認作業が成功を左右する。

しんたろー：
評価スクリプトを書かずにプロンプトをいじり回すのは、暗闇で適当にサイコロを振るようなものだ。Claude Codeにリポジトリ全体を読み込ませて、評価ハーネスの自動実行や設定ファイルの型定義チェックを任せるスタイルが、結果的に打率が高くなる。

3. ノーコードツールでもコードと型定義を直接読む

Difyのようなノーコードツールは強力だが、高度なワークフローを組んだり設定ファイル（DSL）を書き出したりする段階で、ドキュメントに載っていないエラーに遭遇する。

画面上のエラー表示だけで原因を探ろうとすると、何時間も足踏みすることになる。開発者として持つべきスタンスは、オープンソースとして公開されているリポジトリのコードや型定義を直接読み解くことだ。

ブラックボックス化された挙動を恐れず、内部の処理ロジックまで踏み込んで仕様を把握する。この姿勢があって初めて、ノーコードツールを使いこなすことができる。

よくある質問

RAGの評価指標として最も信頼できるものは何ですか？

LLMを使った評価は実行のたびに数値がブレるため、メインの指標にするのは危険だ。入力に対して出力が一義的に決まる決定論的な指標を優先する。

具体的には、検索候補に正解が含まれる確率を示すRecall@kや、正解の掲載順位を評価するMRRが信頼できる。また、回答できない質問に対して正しく回答を辞退できたかを示すAbstention rateも組み込む。

Difyの構築中にドキュメント未記載のエラーが出たらどうすべきですか？

画面上のエラーログだけで原因を探ろうとすると、何時間も足踏みすることになる。ブラウザの開発者ツールで通信ログを追いつつ、GitHubのリポジトリにあるソースコードを直接読み解くのが早い。

特に設定ファイルの型定義やノード間のデータ受け渡しは、コードを見れば一目瞭然だ。ノーコードツールであっても、内部ロジックまで踏み込んで解読する姿勢がトラブルシューティングの鍵になる。

ローカルLLMでRAGを運用するにはVRAMがどれくらい必要ですか？

快適な動作環境を構築するためのメモリ容量として、最低でも24GBから32GBのVRAMを用意する。Gemma2 26bクラスのモデルを実用的な速度で動かす場合、VRAM容量が処理のボトルネックになるからだ。

16GBのグラフィックボードを2枚刺して容量を稼ぐ構成も選択肢に入るが、ハードウェアの制約には注意が必要だ。マザーボードがx8/x8動作のPCIeスロットに対応しているかや、補助電源コネクタの物理的な干渉がないかを事前に確認する。

まとめ

モデルを最新に切り替える前に、評価ハーネスで数値を測る。これがRAGのコストを28%削れた理由だ。

確率的なAIに振り回されず、決定論的な指標でシステムを育てる感覚が掴めると、開発はラクになる。自身のThreadPost開発でもこの計測を徹底している。

RAGの品質を「なんとなく」で終わらせないために、まずは測定する仕組みを作る。

👉 ThreadPostでSNS運用を自動化する