RAGの理想と現実
Retrieval Augmented Generation (RAG)は「ベクトルDBから関連文書を取得してLLMに渡す」というシンプルな概念だ。プロトタイプは半日で動く。しかし本番環境で安定した品質を出すのは全く別の話だ。KGAは過去1年で12件のRAGシステムを本番投入し、そのうち4件で大規模な設計見直しを余儀なくされた。この記事では、その経験から得た実践的な知見を共有する。
チャンキング戦略: 最も過小評価される要素
RAGの品質の70%はチャンキングで決まると言って過言ではない。固定長チャンキング（512トークンで分割）は最も簡単だが、文の途中で切れるため文脈が失われる。KGAが検証した5つのチャンキング手法の比較結果を示す。
固定長（512トークン）: 実装容易、検索精度68%。文境界分割: 実装容易、検索精度74%。段落分割: やや複雑、検索精度78%。セマンティックチャンキング（embedding類似度ベース）: 複雑、検索精度84%。ドキュメント構造ベース（見出し・セクション単位）: 中程度、検索精度82%。
KGAの推奨はセマンティックチャンキングだ。文のembeddingを計算し、隣接する文のcosine similarityが閾値（0.75が目安）を下回る点で分割する。これにより意味的にまとまった単位でチャンクが生成される。実装にはLangChainのSemanticChunkerが使えるが、大量のドキュメント処理ではembedding APIのコストに注意。KGAではローカルのsentence-transformers (all-MiniLM-L6-v2)でembeddingを計算し、APIコストをゼロに抑えている。
チャンクサイズも重要だ。小さすぎると文脈不足、大きすぎるとノイズが増える。KGAの経験則では、FAQ系なら200-400トークン、技術文書なら400-800トークン、法的文書なら800-1200トークンが適切だ。
Embeddingモデルの選択
Embeddingモデルの選択はチャンキングに次いで重要だ。KGAが日本語文書RAGで検証した結果、OpenAI text-embedding-3-large: NDCG@10 0.82、Cohere embed-v3: 0.80、multilingual-e5-large-instruct: 0.78、bge-m3: 0.81。
コストを考慮するとbge-m3がベストバランスだ。オープンソースで無料、日本語性能もOpenAIに迫る。KGAでは本番環境でbge-m3をGPUサーバーでセルフホスティングし、レイテンシとコストの両面で最適化している。
リランキング: 検索精度を10-15%向上させる魔法
ベクトル検索の結果をそのままLLMに渡すのは次善策だ。リランキングモデルを挟むことで、検索精度を10-15%向上できる。原理はシンプルで、ベクトル検索の上位20-50件をリランキングモデルに入力し、クエリとの関連度で再順位付けする。
KGAではCohere Rerank v3をデフォルトで使用。APIコストは$1/1000リクエスト程度で、品質改善に対してコストは微小だ。セルフホスティングならbge-reranker-v2-m3が推奨。
リランキングの落とし穴は初期検索の recall だ。ベクトル検索の上位50件にそもそも正解文書が含まれていなければ、リランキングしても正解は出てこない。KGAではhybrid search（ベクトル検索 + BM25キーワード検索のスコア融合）でrecallを確保し、その上でリランキングする2段階方式を採用している。
評価パイプライン: RAGの品質を定量化する
RAGの品質評価は「なんとなく良い回答が出ている」では不十分だ。KGAが使用している評価フレームワークは以下の3指標。
Faithfulness: 回答がretrievedドキュメントに忠実か（hallucination検出）。Answer Relevancy: 回答がクエリに対して適切か。Context Relevancy: retrievedドキュメントがクエリに関連しているか。
これらをLLM-as-a-Judge（Claude 4 Sonnet）で自動評価している。評価用データセットは最低100問で、クライアントの実際のクエリログから抽出。RAGASフレームワークをベースにカスタマイズしたパイプラインで、CI/CDに組み込んで毎回の変更で品質をチェックしている。
本番運用の落とし穴トップ5
- ドキュメント更新の反映遅延。ソースドキュメントが更新されてもベクトルDBのembeddingが古いまま。差分更新パイプラインの実装が必須。2. チャンクの重複。同じ内容が複数チャンクに分散し、LLMが矛盾した回答を生成。deduplication処理を追加。3. メタデータフィルタリングの不足。全ドキュメントから検索するとノイズが増加。部署、日付、ドキュメント種別でフィルタリング。4. コンテキストウィンドウの浪費。関連度の低いチャンクがcontextを圧迫。リランキング+上位N件の厳選が必要。5. ユーザークエリの曖昧さ。「最新の情報」「前回の件」などの曖昧なクエリで検索精度が激減。クエリ書き換え（query rewriting）で対処。
KGAのRAGシステムでは、これら全てに対策を実装した結果、初期バージョンと比較してユーザー満足度（5段階評価）が2.8から4.3に向上した。