相談事例 /
rag-rescue
社内FAQ RAG の精度を 48% → 89% へ引き上げた事例
課題
社内向けFAQボット（ChatGPT API + Pinecone）の回答精度が低く、社員に使われない状態が続いていた。
解決策
評価データセット構築、チャンキング再設計、ハイブリッド検索導入、再ランキング追加、プロンプト改善を3ヶ月で実施。
成果
Answer Relevancy が 48% → 89% に向上。社員の利用率も 月100回 → 月3000回 に増加。
## ご相談時の状況
IT/SaaS 企業のお客様から「ChatGPT API と Pinecone で作った社内FAQボットの精度が低くて、社員から使えないと言われている。やめるのも惜しいので、改善できないか」というご相談をいただきました。
ボットは社内 Slack で稼働しており、社員が業務に関する質問を投げると、社内ドキュメント（Notion、Confluence、Google Drive にある約 2,000 文書）を検索して回答する仕組みです。導入当初は注目されたものの、3ヶ月後の利用は月100回程度まで落ち込んでいました。
社員からのフィードバックを集計すると、「回答が的外れ」「分からないと言われる」「関係ない文書を引いてくる」「回答が長くて読みにくい」といった声が多数。これでは確かに使われません。
## 第1ヶ月: 計測体制の構築
私たちはまず「現状の精度を数値で把握する」ことから始めました。これがないと、改善しても良くなったのか分からないからです。
社員に協力していただき、「実際に投げた質問」と「期待していた回答」のペアを 50 組収集。これに加えて、業務領域別に網羅的な質問を 50 組追加し、合計 100 組の評価データセットを構築しました。
評価指標として、Recall@5（上位5件に正解文書が含まれる率）、Answer Relevancy（回答の関連度）、Faithfulness（回答が引用文書に忠実か）の3つを採用。RAGAS という評価フレームワークで自動計測する体制を整えました。
初期評価の結果は厳しいものでした。Recall@5 = 41%、Answer Relevancy = 48%、Faithfulness = 62%。つまり「正解文書を取得できないことが半数以上」「取得した文書を使った回答も的外れ」という状態でした。
## 第2ヶ月: 検索精度の改善
検索精度を上げるため、以下を段階的に実施しました。
まずチャンキング戦略の変更。それまで「固定800字で分割」していたものを、「セマンティック チャンキング（LLMによる意味単位での分割）」と「階層的チャンキング（章 > 節 > 段落の階層構造を保持）」に変更。さらに、隣接チャンク間で 100字 のオーバーラップを持たせました。
次に埋め込みモデルの変更。OpenAI の text-embedding-ada-002 を text-embedding-3-large に変更。次元数も増やし、より精密な意味表現を取得できるようにしました。日本語に強い multilingual-e5-large も比較しましたが、結果としては text-embedding-3-large が最良でした。
そしてハイブリッド検索の導入。コサイン類似度（ベクトル検索）だけでなく、BM25（キーワード検索）も並行して実行し、両者の結果を Reciprocal Rank Fusion で統合。固有名詞や数値を含むクエリへの対応力が大幅に向上しました。
この段階で Recall@5 = 76% に。+35ポイントの改善です。
## 第3ヶ月: 生成品質の改善
検索で正しい文書を取れるようになったら、次は生成プロンプトの改善です。
第一に再ランキング（Reranking）の導入。検索で上位20件取得した後、Cohere Rerank で上位5件に絞り込みます。これにより、本当に質問に関連する文書だけが LLM に渡されるようになりました。
第二にプロンプトの構造化。それまで「以下の文脈を参考に答えてください」というシンプルなプロンプトだったものを、以下のように改善しました。
1. 「文脈に明確な答えがある場合のみ回答する」
2. 「文脈から推測できる場合は『〜と思われます』と表現する」
3. 「文脈に答えがない場合は『その質問の答えは社内文書にありません。担当者に確認することをおすすめします』と回答する」
4. 「回答末尾に [doc#XX] の形で引用元を明示する」
5. 「回答は3段落以内に収める」
第三にコンテキスト圧縮。長い文書をそのまま渡すと回答が散漫になるため、関連箇所を抽出してから渡す処理を追加しました。
最終評価では Recall@5 = 91%、Answer Relevancy = 89%、Faithfulness = 94% に到達。改善前と比べて、ほぼすべての指標で 2倍以上の向上です。
## 結果と効果
精度改善後、社員への再案内を実施したところ、月の利用回数が 3000回 まで増加。社員からは「やっと使えるようになった」「むしろ自分で検索するより早い」というフィードバックが多数寄せられました。
月額のOpenAI API費用は、最適化前の 3万円 → 改善後の 5万円 と若干増加しましたが、利用回数が30倍になっていることを考えれば、1リクエストあたりのコストは大幅に低下しています。さらに、社員が他のことに時間を使えるようになった効果は、お客様の概算で月100時間相当（人件費換算で月50万円相当）とのことでした。
## このプロジェクトから学べる教訓
第一に、「計測なくして改善なし」。漠然と「精度を上げる」のではなく、Recall や Faithfulness といった具体的な指標で測ることが、改善の出発点です。
第二に、RAGの改善は1箇所だけでは限界があります。チャンキング・埋め込み・検索・再ランキング・プロンプトを全方位的に改善することで、ようやく実用レベルに到達します。
第三に、ユーザー（社員）の声を聞くことが何よりも大事です。技術的に「精度95%」と言っても、ユーザーが「使えない」と感じていれば、その指標は意味がありません。
IT/SaaS 企業のお客様から「ChatGPT API と Pinecone で作った社内FAQボットの精度が低くて、社員から使えないと言われている。やめるのも惜しいので、改善できないか」というご相談をいただきました。
ボットは社内 Slack で稼働しており、社員が業務に関する質問を投げると、社内ドキュメント（Notion、Confluence、Google Drive にある約 2,000 文書）を検索して回答する仕組みです。導入当初は注目されたものの、3ヶ月後の利用は月100回程度まで落ち込んでいました。
社員からのフィードバックを集計すると、「回答が的外れ」「分からないと言われる」「関係ない文書を引いてくる」「回答が長くて読みにくい」といった声が多数。これでは確かに使われません。
## 第1ヶ月: 計測体制の構築
私たちはまず「現状の精度を数値で把握する」ことから始めました。これがないと、改善しても良くなったのか分からないからです。
社員に協力していただき、「実際に投げた質問」と「期待していた回答」のペアを 50 組収集。これに加えて、業務領域別に網羅的な質問を 50 組追加し、合計 100 組の評価データセットを構築しました。
評価指標として、Recall@5（上位5件に正解文書が含まれる率）、Answer Relevancy（回答の関連度）、Faithfulness（回答が引用文書に忠実か）の3つを採用。RAGAS という評価フレームワークで自動計測する体制を整えました。
初期評価の結果は厳しいものでした。Recall@5 = 41%、Answer Relevancy = 48%、Faithfulness = 62%。つまり「正解文書を取得できないことが半数以上」「取得した文書を使った回答も的外れ」という状態でした。
## 第2ヶ月: 検索精度の改善
検索精度を上げるため、以下を段階的に実施しました。
まずチャンキング戦略の変更。それまで「固定800字で分割」していたものを、「セマンティック チャンキング（LLMによる意味単位での分割）」と「階層的チャンキング（章 > 節 > 段落の階層構造を保持）」に変更。さらに、隣接チャンク間で 100字 のオーバーラップを持たせました。
次に埋め込みモデルの変更。OpenAI の text-embedding-ada-002 を text-embedding-3-large に変更。次元数も増やし、より精密な意味表現を取得できるようにしました。日本語に強い multilingual-e5-large も比較しましたが、結果としては text-embedding-3-large が最良でした。
そしてハイブリッド検索の導入。コサイン類似度（ベクトル検索）だけでなく、BM25（キーワード検索）も並行して実行し、両者の結果を Reciprocal Rank Fusion で統合。固有名詞や数値を含むクエリへの対応力が大幅に向上しました。
この段階で Recall@5 = 76% に。+35ポイントの改善です。
## 第3ヶ月: 生成品質の改善
検索で正しい文書を取れるようになったら、次は生成プロンプトの改善です。
第一に再ランキング（Reranking）の導入。検索で上位20件取得した後、Cohere Rerank で上位5件に絞り込みます。これにより、本当に質問に関連する文書だけが LLM に渡されるようになりました。
第二にプロンプトの構造化。それまで「以下の文脈を参考に答えてください」というシンプルなプロンプトだったものを、以下のように改善しました。
1. 「文脈に明確な答えがある場合のみ回答する」
2. 「文脈から推測できる場合は『〜と思われます』と表現する」
3. 「文脈に答えがない場合は『その質問の答えは社内文書にありません。担当者に確認することをおすすめします』と回答する」
4. 「回答末尾に [doc#XX] の形で引用元を明示する」
5. 「回答は3段落以内に収める」
第三にコンテキスト圧縮。長い文書をそのまま渡すと回答が散漫になるため、関連箇所を抽出してから渡す処理を追加しました。
最終評価では Recall@5 = 91%、Answer Relevancy = 89%、Faithfulness = 94% に到達。改善前と比べて、ほぼすべての指標で 2倍以上の向上です。
## 結果と効果
精度改善後、社員への再案内を実施したところ、月の利用回数が 3000回 まで増加。社員からは「やっと使えるようになった」「むしろ自分で検索するより早い」というフィードバックが多数寄せられました。
月額のOpenAI API費用は、最適化前の 3万円 → 改善後の 5万円 と若干増加しましたが、利用回数が30倍になっていることを考えれば、1リクエストあたりのコストは大幅に低下しています。さらに、社員が他のことに時間を使えるようになった効果は、お客様の概算で月100時間相当（人件費換算で月50万円相当）とのことでした。
## このプロジェクトから学べる教訓
第一に、「計測なくして改善なし」。漠然と「精度を上げる」のではなく、Recall や Faithfulness といった具体的な指標で測ることが、改善の出発点です。
第二に、RAGの改善は1箇所だけでは限界があります。チャンキング・埋め込み・検索・再ランキング・プロンプトを全方位的に改善することで、ようやく実用レベルに到達します。
第三に、ユーザー（社員）の声を聞くことが何よりも大事です。技術的に「精度95%」と言っても、ユーザーが「使えない」と感じていれば、その指標は意味がありません。