EN
JP
KRRAGシステムの精度を高めるためのチャンク設計と評価方法：データ更新運用まで解説
RAGシステムは、LLMに単独で回答させるのではなく、社内文書、FAQ、業務マニュアル、規程、契約書、問い合わせ履歴、製品資料などの外部知識を検索し、その検索結果を根拠として回答を生成する仕組みです。企業で生成AIを業務利用する場合、LLMの一般知識だけに依存すると、最新の社内ルール、個別業務の条件、顧客ごとの契約内容、製品仕様の変更などを正しく反映できないことがあります。そのため、RAGは社内ナレッジを活用するための現実的なアプローチとして注目されていますが、実際に運用すると「正しい文書が検索されない」「古い情報をもとに回答する」「回答は自然だが根拠が弱い」「文書を追加したら精度が下がった」といった課題が起こりやすくなります。
RAGの精度を高めるためには、モデル選定だけを見直しても不十分です。回答品質は、元データの品質、文書の分割方法、チャンクサイズ、オーバーラップ、メタデータ、検索方式、再ランキング、プロンプト、評価データ、更新運用が組み合わさって決まります。特に企業システムでは、単に「それらしい回答」を出すだけでなく、最新の正しい文書を参照し、権限外の情報を出さず、回答根拠を明示し、誤回答が発生したときに原因を追跡できることが重要です。本記事では、RAGシステムの精度を高めるために必要なチャンク設計、評価方法、データ更新運用までを、実務で使える観点から整理します。
1. RAGの精度をモデルだけで判断しない
RAGシステムの精度改善を考えるとき、最初にLLMやエンベディングモデルを変更したくなることがあります。しかし、実務で起こる精度問題の多くは、モデルそのものよりも、検索対象データの整理不足、チャンク分割の不適切さ、メタデータ不足、古い文書の混在、評価データの不足から発生します。高性能なLLMを使っても、検索されたチャンクが質問に合っていなければ、回答は正しくなりません。逆に、検索結果が正確であれば、比較的安定したモデルでも業務上十分に使える回答を生成できる場合があります。
1.1 検索精度と回答精度を分けて見る
RAGでは、まず「質問に対して正しい根拠文書が検索されているか」を確認し、その次に「検索された根拠を使って正しく回答できているか」を確認する必要があります。検索段階で正しいチャンクが取得できていない場合、プロンプトを調整しても根本的な改善にはなりません。例えば、社内規程の質問に対して旧版の規程が検索されている場合、LLMの回答表現をどれだけ改善しても、根拠が古いため正しい回答にはなりにくいです。一方で、正しい規程が検索されているのに回答が曖昧であれば、回答生成プロンプト、回答フォーマット、根拠の使い方を見直すべきです。
このように、RAGの精度を評価するときは、検索評価と回答評価を分けることが重要です。検索評価では、期待する文書やチャンクがTop Kに入っているか、ノイズが多すぎないか、最新文書が優先されているかを確認します。回答評価では、検索結果に基づいて正確に答えているか、根拠にない内容を推測していないか、ユーザーが業務で使いやすい形式になっているかを確認します。問題を分解して評価することで、改善すべき箇所がチャンク設計なのか、検索方式なのか、プロンプトなのか、元データなのかを判断しやすくなります。
1.2 精度低下の原因を分類する
RAGの回答が間違っている場合、その原因は一つとは限りません。文書が古い、同じ内容の文書が重複している、チャンクが小さすぎて文脈が欠けている、チャンクが大きすぎてノイズが多い、メタデータが不足して検索範囲を絞れない、検索クエリが曖昧、再ランキングが弱い、プロンプトが根拠外回答を許しているなど、さまざまな原因が考えられます。これらをすべて「RAGの精度が悪い」とまとめてしまうと、改善施策が場当たり的になります。
改善の第一歩は、失敗パターンを分類することです。例えば、正しい文書が検索結果に入っていない場合は検索設計の問題、正しい文書は入っているが順位が低い場合はランキングの問題、正しい文書が上位にあるのに回答が間違っている場合は生成プロンプトの問題、旧文書が検索されている場合はデータ更新運用の問題として整理します。この分類を行うことで、RAG改善は感覚的な調整ではなく、原因に基づいた改善活動になります。
1.3 業務リスクに応じて必要精度を変える
RAGシステムに求められる精度は、業務用途によって大きく異なります。社内FAQの下書き支援であれば、人間が最後に確認する前提で、多少の表現調整や確認作業を許容できる場合があります。しかし、顧客向け回答、法務確認、契約条件の照会、医療・金融・人事規程に関する回答では、誤った回答が大きなリスクにつながるため、根拠文書の正確性、最新版の使用、回答拒否の適切さが重要になります。
そのため、すべてのRAGに同じ評価基準を適用するのではなく、業務リスクに応じた精度基準を設計する必要があります。低リスク用途では、検索速度やユーザー体験を重視し、高リスク用途では、根拠表示、回答の保守性、承認済み文書のみの参照、権限制御、ログ監査を重視します。RAGの設計は、技術的な検索精度だけでなく、その回答が業務上どの程度の影響を持つかを踏まえて決めるべきです。
1.4 PoCと本番運用で評価観点を変える
PoC段階では、代表的な質問に答えられるか、ユーザーが便利だと感じるか、既存業務の一部を支援できるかを確認することが多くなります。しかし、本番運用では、データ更新、権限管理、ログ保存、誤回答対応、再評価、コスト管理まで含めて見る必要があります。PoCで少量の整理された文書だけを使って高精度に見えても、本番で大量の文書、旧版ファイル、重複資料、部署別権限が入ると、精度が大きく変わることがあります。
本番化を見据えるなら、PoCの段階から運用評価の一部を入れておくことが重要です。例えば、文書を追加したときに再インデックスが必要か、旧文書をどう除外するか、検索ログをどう保存するか、評価データをどう更新するかを確認します。RAGは一度作って完了するシステムではなく、データと業務の変化に合わせて継続的に調整するシステムです。その前提をPoC段階から持つことで、本番移行時の手戻りを減らせます。
2. チャンク設計の目的を明確にする
チャンク設計とは、長い文書を検索しやすい単位に分割する設計です。RAGでは、文書全体をそのまま検索対象にするのではなく、一定の意味単位に分けてベクトル化し、ユーザーの質問に近いチャンクを検索します。ただし、チャンクは小さくすれば精度が上がるものでも、大きくすれば文脈が保てるものでもありません。業務文書の構造、質問の粒度、回答に必要な情報量を見ながら、適切な単位を決める必要があります。
2.1 チャンクは検索対象の最小業務単位として考える
チャンクは単なる文字数のかたまりではなく、ユーザーの質問に答えるための最小業務単位として設計することが重要です。例えば、社内規程で「申請期限はいつか」と聞かれた場合、期限だけでなく、対象制度、申請条件、例外、申請先が必要になることがあります。期限の一文だけをチャンクにすると、検索にはヒットしても、回答に必要な文脈が不足する可能性があります。
そのため、チャンクには「質問に対して回答可能な情報のまとまり」を含めるべきです。FAQであれば質問と回答をセットにし、規程であれば条文と見出しをセットにし、マニュアルであれば一連の操作手順をセットにします。チャンク設計では、検索システムの都合だけでなく、業務担当者がその情報を読んで判断できる単位かどうかを確認することが重要です。
2.2 小さすぎるチャンクの問題を理解する
チャンクを小さくすると、検索結果はピンポイントになりやすくなりますが、文脈が欠けるリスクがあります。例えば「30日前までに申請してください」という一文だけが検索された場合、それが何の申請に関するものなのか、誰が対象なのか、例外条件があるのかが分かりません。LLMは不足した文脈を補おうとして、根拠にない内容を推測してしまう可能性があります。
小さすぎるチャンクは、特に規程、契約書、技術仕様書、業務マニュアルで問題になりやすいです。これらの文書では、一文だけでは意味が成立せず、前提条件や見出しとの関係が重要になるためです。改善策として、見出し、章タイトル、対象業務、前後の補足情報をチャンクに含める、またはメタデータとして保持する設計が必要です。
2.3 大きすぎるチャンクの問題を理解する
チャンクを大きくすると、文脈は残りやすくなりますが、検索精度が下がる場合があります。1つのチャンクに複数のテーマが含まれていると、質問に関係のない情報まで一緒に検索されます。その結果、LLMが不要な情報に引っ張られたり、回答が長く曖昧になったりします。例えば、休暇、残業、退職、懲戒が同じチャンクに入っている場合、「有給休暇の申請方法」を聞いているのに、残業や退職の情報まで回答文に混ざる可能性があります。
大きすぎるチャンクは、検索スコアの意味も曖昧にします。チャンク内の一部だけが質問に関連していても、チャンク全体としてはノイズを含むため、回答生成時に余計な情報が入り込みます。改善策として、文書構造に沿って章・節・FAQ・手順単位で分割し、1チャンク1テーマに近づけることが重要です。ただし、テーマを分けすぎて文脈を失わないよう、評価しながら調整します。
2.4 チャンク設計は評価しながら決める
チャンクサイズや分割方法には、すべての文書に共通する絶対的な正解はありません。FAQ、規程、製品マニュアル、議事録、問い合わせ履歴、契約書では、最適なチャンク単位が異なります。また、同じ文書でも、ユーザーが聞く質問の粒度によって適切な分割が変わります。そのため、チャンク設計は最初に一度決めて終わりではなく、評価結果を見ながら改善するものです。
実務では、複数のチャンク設計を比較するのが有効です。例えば、固定長分割、見出し単位分割、見出し＋オーバーラップ分割、FAQ単位分割、表保持型分割を用意し、同じ評価質問で検索結果と回答品質を比較します。検索ヒット率、ノイズ率、根拠忠実性、回答の使いやすさ、インデックスサイズ、処理コストを見ながら、業務用途に合う設計を選びます。
3. 文書種類ごとにチャンク戦略を変える
RAGシステムで扱う文書は一種類ではありません。FAQ、規程、マニュアル、議事録、契約書、問い合わせ履歴、製品仕様書など、それぞれ構造も用途も異なります。すべてのデータを同じルールで分割すると、ある文書ではうまくいっても、別の文書では精度が下がることがあります。チャンク設計では、文書種類ごとに分割ルールを変えることが重要です。
3.1 FAQは質問と回答をセットで保持する
FAQは、もともと「質問」と「回答」が一組になった検索向きのデータです。そのため、FAQをさらに固定長で細かく分割すると、質問と回答が分かれてしまい、検索精度が下がることがあります。例えば、質問部分だけが検索されても回答が含まれていなければ、LLMへ渡す根拠として不十分になります。逆に、回答部分だけが検索されても、どの質問に対する回答なのかが分かりにくくなります。
FAQでは、質問、回答、カテゴリ、対象サービス、更新日、公開状態をセットで1チャンクにする設計が基本です。回答が長い場合でも、無理に文単位で分割するのではなく、関連する補足情報を同じチャンクに含めるか、関連チャンクとして紐づける方が実務では使いやすくなります。FAQはRAGの初期導入に向いているデータですが、カテゴリや更新日を管理しないと古い回答が残りやすいため、メタデータ設計も重要です。
3.2 規程文書は章・条・項の構造を守る
社内規程や契約文書では、章、条、項、号といった構造が意味を持ちます。固定文字数で分割すると、条文の途中で切れてしまい、「ただし」「例外として」「次の場合を除く」といった重要な条件が別チャンクに分かれる可能性があります。これにより、回答が条件不足になったり、例外を無視したりするリスクが高まります。
規程文書では、条文単位を基本にし、長い条文は項単位で分割します。その際、文書名、章タイトル、条番号、更新日、版数をチャンク本文またはメタデータに保持します。回答時に「第3章 第12条に基づくと」のように根拠を示せると、業務利用での信頼性が上がります。RAGで規程を扱う場合は、回答の自然さよりも、根拠の正確性と最新版の使用が重要です。
3.3 マニュアルは手順のまとまりを保つ
操作マニュアルや業務手順書では、手順が途中で切れるとユーザーが実行できない回答になります。例えば、「管理画面にログインする」「設定メニューを開く」「対象ユーザーを選ぶ」「権限を変更する」「保存する」という流れのうち、途中だけが検索されると、回答が不完全になります。RAGでマニュアルを扱う場合は、手順の流れを崩さないチャンク設計が必要です。
改善策として、1つの目的を達成する手順を1チャンクに近い形で保持します。長い手順の場合は、「前提条件」「操作手順」「注意点」「エラー時対応」を別チャンクに分けつつ、同じprocedure_idや画面名で関連付けます。これにより、検索結果として複数チャンクが取得された場合でも、LLMが手順全体を再構成しやすくなります。マニュアルRAGでは、検索精度だけでなく、回答が実際に操作可能な形になっているかを評価する必要があります。
3.4 議事録や問い合わせ履歴は要約チャンクを併用する
議事録や問い合わせ履歴は、会話形式で情報が散らばりやすく、原文をそのまま固定長で分割すると検索ノイズが増えます。議事録では同じテーマが複数箇所に分散し、問い合わせ履歴では顧客の質問、担当者の確認、最終回答が別々に現れることがあります。そのまま検索対象にすると、断片的な情報だけが検索され、回答に必要な決定事項や結論が見つかりにくくなります。
このようなデータでは、原文チャンクに加えて、テーマ別要約チャンクを作る方法が有効です。議事録であれば「決定事項」「未決事項」「担当者」「期限」「リスク」を抽出し、問い合わせ履歴であれば「質問内容」「原因」「回答」「再発防止策」を整理します。要約チャンクは検索しやすく、原文チャンクは根拠確認に使えます。RAGでは、すべてのデータを同じ粒度で扱うのではなく、検索向けに再構成する発想が重要です。
4. オーバーラップ設計を適切に使う
チャンクオーバーラップは、前後のチャンクに一部の内容を重ねる設計です。文章の切れ目で文脈が失われる問題を緩和できますが、過剰に使うと同じようなチャンクが大量に生成され、検索結果が重複しやすくなります。オーバーラップは便利な補助機能ですが、文書構造を無視した分割を補う万能策ではありません。
4.1 オーバーラップは文脈切れを補うために使う
オーバーラップは、前のチャンクにある前提条件と、次のチャンクにある結論が分断されるようなケースで有効です。例えば、前半に「対象者は正社員と契約社員です」と書かれ、後半に「申請は30日前までに行います」と書かれている場合、後半だけが検索されると対象者が分かりません。一定のオーバーラップを入れることで、検索結果に必要な前提条件が含まれやすくなります。
ただし、オーバーラップを入れる前に、そもそも分割単位が適切かを確認する必要があります。見出しや段落を無視して機械的に切っている場合、オーバーラップを増やしても根本的な解決にはなりません。まずは文書構造に沿って分割し、それでも文脈が切れやすい部分にオーバーラップを使うのが実務的です。
4.2 オーバーラップが多すぎると検索結果が偏る
オーバーラップを大きくしすぎると、ほぼ同じ内容のチャンクが複数生成されます。その結果、検索Top Kが似たチャンクで埋まり、別の重要な根拠が入らなくなることがあります。例えば、同じ規程の同じ条文が少しずつ重なって複数チャンクに入っていると、検索結果の多様性が下がり、例外条件や関連手順を含む別チャンクが取得されにくくなります。
改善策として、検索後に重複排除や多様性制御を行います。同じsource_idや連続するchunk_idが多く含まれる場合は、代表チャンクを残して他のチャンクを除外する、または再ランキングでスコアを調整します。RAGでは、正しい情報が一つ入るだけでなく、回答に必要な複数の根拠がバランスよく取得されることが重要です。
4.3 見出し情報をオーバーラップより優先する
文脈を保つためには、単純に前後の文字を重ねるよりも、見出し情報をチャンクに付与する方が有効な場合があります。例えば「申請期限は30日前です」という本文に、「育児休業申請」「第2章 申請手続き」という見出しが付いていれば、文脈が明確になります。オーバーラップで前後文を増やすよりも、意味のある見出しを付ける方が検索にも回答にも効くことがあります。
実務では、文書名、章タイトル、節タイトル、条番号をメタデータとして保持し、必要に応じてチャンク本文にも含めます。ただし、すべての見出しを本文に入れると埋め込みの意味が見出しに偏ることがあるため、評価しながら調整します。見出しは、RAGの文脈補完において非常に重要な情報です。
4.4 オーバーラップ率も評価対象にする
オーバーラップ率は感覚で決めるのではなく、評価対象にするべきです。例えば、オーバーラップなし、10%、20%、30%のように複数パターンを作り、同じ評価質問で検索結果と回答品質を比較します。正解チャンクがTop Kに入る割合、重複チャンク率、回答正確性、インデックスサイズ、検索コストを見ます。
オーバーラップを増やすほどチャンク数が増え、ベクトルDBの容量、埋め込み生成コスト、検索コストが増加します。精度がわずかに上がるだけで運用コストが大きく増える場合は、見直しが必要です。RAGの設計では、精度、速度、コスト、運用性を同時に評価することが重要です。
5. メタデータ設計で検索精度を高める
RAGでは、チャンク本文だけでなく、メタデータ設計が精度と運用性を大きく左右します。文書名、カテゴリ、作成部門、更新日、版数、公開範囲、言語、対象製品、対象顧客、権限情報を持たせることで、検索対象を絞り込み、古い情報や権限外情報を除外しやすくなります。メタデータは、検索精度だけでなく、データ更新運用や監査にも関わります。
5.1 文書属性をメタデータとして持たせる
文書名、カテゴリ、文書種別、作成部門、更新日、版数、公開状態をメタデータとして持たせることで、検索結果の管理がしやすくなります。例えば、同じ「料金」という言葉でも、営業資料、契約書、FAQ、社内規程では意味が異なります。カテゴリや文書種別があれば、質問の意図に応じて検索対象を絞ることができます。
メタデータがないRAGでは、すべてのチャンクが同じ条件で検索されるため、ノイズが増えやすくなります。特に文書量が増えるほど、本文だけの類似度では正しい情報を選びにくくなります。企業向けRAGでは、メタデータを「後から付ける補助情報」ではなく、検索品質を支える設計要素として扱う必要があります。
5.2 権限情報をメタデータに含める
企業RAGでは、ユーザーが本来閲覧できない文書をAI経由で見られてしまうことが重大なリスクになります。そのため、部署、役職、プロジェクト、契約先、顧客ID、公開範囲などの権限情報をメタデータとして持たせる必要があります。検索時には、ログインユーザーの権限に応じて、検索対象チャンクを事前にフィルタリングします。
権限制御は、回答生成後に隠すのではなく、検索前または検索時点で制御することが基本です。権限外チャンクがLLMに渡ってしまうと、回答に出なくても情報漏えいリスクが残ります。RAGの権限設計では、データソースの権限、チャンク単位の権限、ユーザー属性、ログ監査を一体で考える必要があります.
5.3 更新日と版数を使って古い情報を除外する
RAGの誤回答で多いのが、古い文書を参照してしまうケースです。料金表、社内規程、製品仕様、FAQ、契約テンプレートは更新されるため、旧版と新版が混在していると、検索結果に古い情報が入る可能性があります。これを防ぐには、更新日、版数、有効開始日、有効終了日、activeフラグをメタデータとして持たせることが重要です。
例えば、旧料金表を物理削除できない場合でも、active=falseにして検索対象から除外できます。また、同じ文書の複数版がある場合は、versionが新しいものを優先するルールを検索スコアやフィルタに反映します。RAGでは、文書を取り込むことよりも、どの文書を検索対象にすべきかを管理することが重要です。
5.4 メタデータの入力ルールを標準化する
メタデータは設計するだけでは不十分で、入力ルールが統一されていなければ効果が出ません。部署名が「営業」「営業部」「Sales」と混在していると、フィルタリングが正しく機能しません。文書種別も「FAQ」「よくある質問」「Q&A」が混在すると、検索範囲の制御が難しくなります。
改善策として、メタデータ項目はできるだけマスタ化し、自由入力を減らします。文書登録画面で選択式にする、カテゴリ一覧を管理する、更新日や版数を必須にする、未入力の文書はインデックス対象にしないといった運用ルールを作ります。RAGの精度は、データ登録時のルールに大きく依存します。
6. 検索方式を用途に合わせて選ぶ
RAGの検索方式には、ベクトル検索、キーワード検索、ハイブリッド検索、再ランキングなどがあります。ベクトル検索は意味的に近い情報を探すのに強い一方、型番、エラーコード、規程番号、契約IDのように正確一致が必要な検索では弱い場合があります。用途ごとに検索方式を組み合わせることが重要です。
6.1 ベクトル検索だけに頼らない
ベクトル検索は、自然文の質問に対して意味的に近い文書を探すのに有効です。例えば「退職するときの手続きは？」という質問に対して、「退職申請」「最終出勤日」「貸与物返却」といった関連情報を検索できます。しかし、製品コード、エラー番号、契約IDのような正確な文字列が重要な質問では、ベクトル検索だけでは不十分な場合があります。
改善策は、検索対象の性質に応じてキーワード検索を併用することです。自然文の意味理解にはベクトル検索を使い、固有名詞、コード、番号、日付、バージョンにはキーワード検索やメタデータフィルタを使います。RAGでは「意味が近い」だけでなく「正確に一致する」ことが必要な場面が多いため、検索方式を固定しないことが重要です。
6.2 ハイブリッド検索を活用する
ハイブリッド検索は、ベクトル検索とキーワード検索を組み合わせる方法です。例えば「製品AのエラーE102の対応方法」という質問では、「製品A」「E102」はキーワードとして重要であり、「対応方法」は意味検索として重要です。ベクトル検索だけでは似たエラーが出る可能性があり、キーワード検索だけでは「対応方法」と近い表現の文書を拾いにくい場合があります。
ハイブリッド検索を使うことで、意味的な類似性と文字列一致の両方を活用できます。企業文書では、専門用語、コード、略称、製品名、部署名が多く登場するため、ハイブリッド検索が有効なケースは多くあります。ただし、スコアの統合方法や重み付けによって結果が変わるため、評価データを使って調整する必要があります。
6.3 再ランキングで検索結果を整える
最初の検索結果に正しいチャンクが含まれていても、順位が低い場合があります。そのまま上位数件だけをLLMに渡すと、正しい根拠が使われず、回答が誤る可能性があります。再ランキングは、広めに取得した候補の中から、質問により関連するチャンクを上位に並べ直すために使います。
例えば、ベクトル検索とキーワード検索で20件取得し、その後で質問との関連性、メタデータ一致、文書の新しさ、権限、カテゴリを考慮して上位5件へ絞ります。再ランキングは精度改善に有効ですが、処理時間やコストが増えるため、すべての質問に適用するのではなく、重要度の高い用途や検索結果が不安定なカテゴリから導入すると現実的です。
6.4 質問タイプに応じて検索範囲を切り替える
すべての質問で全データを検索すると、文書量が増えるほどノイズが増えます。例えば、操作方法を聞いているのに契約書や営業資料が検索されると、回答が不自然になります。質問の種類に応じて検索範囲を切り替えることで、精度を高められます。
改善策として、質問分類を前段に置きます。質問を「FAQ」「操作マニュアル」「規程」「契約」「技術仕様」「問い合わせ履歴」などに分類し、それぞれ適切な検索対象へルーティングします。分類はルールベースでもLLMでも可能ですが、まずは業務上のカテゴリを整理することが重要です。検索範囲を絞ることは、RAGの精度向上だけでなく、コスト削減にもつながります。
7. 評価データセットを作る
RAGの改善には、評価データセットが不可欠です。評価データがない状態でチャンクサイズや検索方式を変えても、改善したのか悪化したのか判断できません。評価データには、質問、期待回答、期待根拠、許容される回答表現、NG回答、ユーザー属性を含めると、検索評価と回答評価を分けて確認できます。
7.1 実際の業務質問を集める
評価データは、開発チームが想像した質問だけでは不十分です。実際にユーザーが聞く質問、問い合わせ履歴、FAQ検索ログ、社内チャット、サポートチケットから質問を集めることで、本番に近い評価ができます。ユーザーは必ずしも文書の見出し通りに質問するわけではなく、曖昧な言い方、略語、口語表現、条件付きの質問を使います。
例えば、「育児休業の申請期限は？」という整理された質問だけでなく、「子どもが1歳になる前に何か出す必要ある？」「男性社員も育休取れる？」「申請が遅れたらどうなる？」のような自然な質問を評価データに含めます。RAGが実務で使われるためには、文書に書かれている表現ではなく、ユーザーが実際に使う表現に対応する必要があります。
7.2 期待根拠を明確にする
RAG評価では、期待回答だけでなく、どの文書やどのチャンクを根拠にすべきかを定義します。回答が一見正しくても、古い文書や権限外文書を根拠にしている場合は不合格にするべきです。企業RAGでは、回答内容だけでなく、根拠の正しさが重要です。
例えば、料金に関する質問で正しい金額を答えていても、旧料金表を参照しているなら危険です。規程に関する質問で内容が合っていても、承認済みではないドラフト文書を根拠にしているなら運用上問題があります。期待根拠を定義することで、検索評価と回答評価を分けて行えるようになります。
7.3 難しい質問を評価に含める
簡単なFAQだけで評価すると、RAGの精度は高く見えます。しかし本番では、条件付き質問、複数文書をまたぐ質問、例外条件を含む質問、曖昧な質問が多く発生します。これらを評価に含めないと、本番で初めて弱点が見つかります。
例えば、「契約社員がリモート勤務中に残業した場合の申請方法」のような質問は、雇用区分、勤務形態、残業申請、承認フローの複数情報が必要です。このような質問を評価に入れることで、単純なチャンク検索だけでは足りない課題が見えます。RAGの評価データには、簡単な質問、標準的な質問、難しい質問、答えがない質問をバランスよく含めることが重要です。
7.4 評価データを継続的に更新する
評価データは一度作って終わりではありません。新しい文書が追加されたとき、制度が変わったとき、ユーザーから低評価が付いたとき、誤回答が発生したときには、評価データを更新する必要があります。評価データが古いままだと、現在の業務ルールに合った精度評価ができません。
運用では、誤回答や検索失敗が発生した質問を評価データに追加します。これにより、改善後に同じ失敗が再発していないかを確認できます。RAGの評価データは、品質保証のためのテストセットであると同時に、運用中に育てていくナレッジ資産です。
8. 検索評価の指標を決める
検索評価では、質問に対して正しいチャンクが検索結果に含まれているかを確認します。回答生成前の段階を評価することで、問題が検索にあるのか、生成にあるのかを切り分けられます。検索評価を行わずに回答だけを見ると、改善ポイントが曖昧になりやすくなります。
8.1 Top Kに正解根拠が入るか確認する
基本的な検索評価は、期待する根拠チャンクがTop Kに入っているかを見ることです。RAGでは通常、上位数件のチャンクをLLMに渡すため、正しい根拠がTop 3やTop 5に入ることが重要になります。正解チャンクがTop 20にはあるがTop 5にはない場合、検索自体は完全に失敗していなくても、回答生成には使われにくい状態です。
評価では、質問ごとに期待根拠を定義し、Top 1、Top 3、Top 5、Top 10のどこに入るかを測定します。チャンク設計、検索方式、メタデータフィルタ、再ランキングを変更したときに、この指標がどう変わるかを見ることで、検索改善の効果を定量的に確認できます。
8.2 ノイズ率を確認する
正しい根拠が検索結果に含まれていても、無関係なチャンクが多いと回答品質が下がります。LLMは与えられたコンテキストをもとに回答するため、ノイズが多いと回答が長くなったり、別テーマの情報を混ぜたりする可能性があります。特に大きすぎるチャンクや全社データを一括検索している場合、ノイズ率が高くなりやすいです。
ノイズ率を評価するには、Top Kの各チャンクに「関連」「一部関連」「無関係」のラベルを付けます。無関係チャンクが多い場合は、メタデータフィルタ、検索範囲、チャンクサイズ、再ランキングを見直します。RAGの検索評価では、正解が入っているかだけでなく、不要情報がどれだけ混ざっているかを見ることが重要です。
8.3 最新文書が優先されるか確認する
企業RAGでは、古い文書が検索されることが大きなリスクです。料金表、規程、製品仕様、FAQ、契約テンプレートは更新されるため、旧版が検索されると誤回答につながります。検索評価では、最新版の文書が上位に来るか、旧版が検索対象から除外されているかを確認します。
改善策として、更新日、版数、activeフラグ、有効期間をメタデータとして保持し、検索時に最新版を優先します。評価データには、旧版と新版が存在するケースを含めるとよいです。これにより、単に意味的に近い文書が検索されるだけでなく、業務上使うべき文書が選ばれているかを確認できます。
8.4 権限外文書が検索されないか確認する
RAGでは、ユーザーが閲覧できない文書が検索結果に含まれないことが重要です。権限外情報がLLMへ渡ると、回答に出力されなくても情報漏えいリスクがあります。企業向けRAGでは、検索精度と同じくらい権限制御の評価が必要です。
評価では、一般社員、部門管理者、人事担当、経営層、外部ユーザーなど複数のユーザー属性を用意し、同じ質問を投げたときに検索結果が適切に変わるか確認します。権限外チャンクが検索結果に含まれる場合は、メタデータ設計、認可ロジック、検索前フィルタを見直します。RAGの安全性は、検索段階の制御で大きく決まります。
9. 回答評価の指標を決める
回答評価では、検索された根拠を使ってLLMが正しく回答できているかを確認します。検索結果が正しくても、LLMが根拠を読み違える、条件を省略する、推測で補完する、回答形式が使いにくいといった問題が発生します。そのため、回答評価では正確性、根拠忠実性、使いやすさ、回答拒否の適切さを確認します。
9.1 回答の正確性を評価する
回答の正確性は、期待回答に対して必要な情報が含まれているかで評価します。完全一致でなくても、業務判断に必要な要素が揃っていれば合格とする場合があります。例えば、申請期限の質問に対して、期限だけでなく対象者、申請先、例外条件が必要な場合は、それらを評価項目として分けます。
正確性評価では、単に自然な文章かどうかではなく、業務上の判断に使えるかを重視します。RAGの回答は読みやすくても、条件が抜けていれば危険です。評価基準を細かく分けることで、「期限は正しいが例外条件が抜けている」「申請先は正しいが対象者が不足している」といった改善ポイントを明確にできます。
9.2 根拠忠実性を評価する
根拠忠実性とは、回答が検索された文書の内容に忠実であるかを確認する指標です。RAGでは、LLMが一般知識や推測で回答を補ってしまうと、根拠のない回答が発生します。特に企業システムでは、文書に書かれていないことを断定しないことが重要です。
評価では、回答内の各主張が検索結果のどの部分に基づいているかを確認します。根拠にない内容が含まれている場合は、プロンプトで「コンテキストにない情報は回答しない」「確認できない場合は不明と答える」と明示します。RAGの信頼性は、回答がどれだけ根拠に忠実かで決まります。
9.3 回答の使いやすさを評価する
回答が正確でも、長すぎる、結論が分かりにくい、手順が整理されていない、根拠が見つけにくい場合、業務では使われにくくなります。RAGは単に正しい情報を返すだけでなく、ユーザーが次の行動を取りやすい形で回答する必要があります。
改善策として、用途ごとに回答フォーマットを固定します。FAQでは結論先出し、操作手順では番号付きリスト、規程回答では根拠文書と条番号、問い合わせ支援では回答案と確認事項を分けます。回答評価では、正確性だけでなく、業務担当者がそのまま使えるか、確認しやすいか、誤解しにくいかを確認します.
9.4 回答拒否の適切さを評価する
RAGでは、根拠がない質問に対して無理に回答しないことも重要です。検索結果に十分な情報がないのにLLMが推測で答えると、誤回答になります。企業システムでは、「分からない」と適切に答える能力が安全性に直結します。
評価データには、あえて答えが存在しない質問を含めます。そのときに「該当する情報は見つかりません」「文書内では確認できません」「担当部門へ確認してください」といった適切な回答ができるかを確認します。RAGの評価では、正しく答える力だけでなく、答えるべきでないときに答えない力も見る必要があります。
10. プロンプト設計で検索結果の使い方を制御する
RAGでは、検索結果をLLMに渡すだけでは十分ではありません。LLMに対して、検索結果をどのように使うか、根拠がない場合にどうするか、回答形式をどうするか、矛盾する根拠がある場合にどう扱うかを指示する必要があります。プロンプト設計は、検索精度を回答品質へ変換するための重要な工程です。
10.1 根拠外の回答を禁止する
RAGの基本は、検索されたコンテキストに基づいて回答することです。しかし、LLMは一般知識や文脈推測で回答を補うことがあります。社内規程や契約条件のような領域では、文書にない内容を補うことは危険です。そのため、プロンプトで「提供されたコンテキストのみを根拠に回答する」「根拠がない場合は不明と答える」と明確に指示します。
この制御は、特に高リスク業務で重要です。例えば、法務、金融、人事、医療、顧客契約に関するRAGでは、推測による回答よりも、確認できないことを明示する方が安全です。回答の自然さを優先しすぎると、根拠のない断定が増える可能性があるため、業務リスクに応じてプロンプトの制約を強めます。
10.2 回答形式を固定する
回答形式が毎回変わると、ユーザーが確認しにくくなり、評価もしづらくなります。RAGの業務利用では、回答の型を決めることで、読みやすさと品質を安定させることができます。例えば、規程回答では「結論」「対象条件」「根拠文書」「注意点」、操作手順では「前提条件」「手順」「エラー時対応」、問い合わせ支援では「回答案」「確認事項」「社内メモ」のように分けます。
回答形式を固定すると、LLMが余計な説明を追加しにくくなり、ユーザーも必要な情報を見つけやすくなります。また、評価時にも「根拠が入っているか」「注意点が含まれているか」「結論が先にあるか」を確認しやすくなります。RAGシステムでは、回答フォーマットも品質管理の対象です。
10.3 複数根拠の矛盾を扱う
検索結果に複数の文書が含まれる場合、内容が矛盾することがあります。旧版と新版、部署別ルール、例外規定、顧客別契約条件が同時に検索されると、LLMがそれらを無理に統合してしまう可能性があります。これは誤回答の原因になります。
改善策は、矛盾がある場合に断定せず、更新日や版数を優先するルールをプロンプトに含めることです。例えば「複数の根拠が矛盾する場合は、最新版を優先し、判断できない場合は確認が必要と回答する」と指定します。RAGでは、複数情報をまとめる力だけでなく、矛盾を検知して安全に回答する力が必要です。
10.4 プロンプト変更を評価対象にする
プロンプトは少し変えるだけで回答傾向が変わります。回答が短くなったり、拒否が増えたり、根拠表示が弱くなったりすることがあります。そのため、プロンプト変更は感覚で本番反映するのではなく、評価データで確認する必要があります。
運用では、プロンプトにバージョンを付け、どのバージョンでどの評価結果だったかを記録します。問題があれば前のプロンプトへ戻せるようにします。RAGシステムでは、データ、チャンク、検索方式だけでなく、プロンプトも変更管理の対象として扱うべきです。
11. データ更新運用を設計する
RAGはデータが古くなると精度が下がります。社内文書、FAQ、規程、製品資料、問い合わせ履歴は日々更新されるため、データ更新、再チャンク、再埋め込み、再インデックス、再評価を運用フローとして設計する必要があります。データ更新運用が弱いRAGは、導入直後は使えても、時間が経つほど信頼性が下がります。
11.1 更新対象データを一覧管理する
まず、RAGに取り込んでいるデータソースを一覧管理します。文書名、保管場所、管理部門、更新頻度、公開範囲、最終更新日、最終取り込み日、責任者を管理しなければ、どのデータがRAGに反映されているか分からなくなります。特に複数部門の文書を扱う場合、データソース管理がないと古い情報や不要文書が混ざりやすくなります。
データ一覧は、単なる台帳ではなく運用管理の基盤です。どの文書が重要で、どの文書は月次更新でよく、どの文書は更新後すぐ再インデックスすべきかを判断するために使います。RAGの品質を安定させるには、データを「取り込んだら終わり」ではなく、ライフサイクルを持つ管理対象として扱う必要があります。
11.2 差分更新と全量更新を使い分ける
データ更新には、変更された文書だけを処理する差分更新と、全データを再処理する全量更新があります。差分更新は効率的ですが、削除や権限変更、メタデータ修正が漏れる可能性があります。全量更新は整合性を保ちやすい一方で、処理時間とコストが大きくなります。
実務では、通常は差分更新を行い、定期的に全量再インデックスを行う設計が現実的です。例えば、日次で差分更新、月次で全量確認、重要文書更新時は即時再インデックスという運用にします。RAGのデータ更新は、コストと正確性のバランスを見ながら設計する必要があります。
11.3 廃止文書と旧版文書を検索対象から外す
RAG運用で見落とされやすいのが、削除・廃止・旧版文書の扱いです。新しい文書を追加しても、古いチャンクがベクトルDBに残っていると、旧情報が検索される可能性があります。特に料金表、規程、手順書の旧版が残ると、ユーザーに誤った回答を返すリスクがあります。
改善策として、文書IDとチャンクIDを管理し、文書が廃止された場合は関連チャンクを検索対象から外します。物理削除するか、active=falseで論理的に除外するかは運用要件によりますが、少なくとも検索結果に出ない状態にする必要があります。RAGでは、データを追加する運用だけでなく、削除・廃止を反映する運用が重要です。
11.4 更新後に再評価する
データを更新した後は、RAGの検索結果や回答が変わる可能性があります。文書を追加したことでノイズが増える、旧版が残っていて検索順位が変わる、チャンク分割が変わって期待根拠がTop Kに入らなくなる、といった問題が起こります。そのため、データ更新後には評価データを使って影響を確認する必要があります。
すべての評価質問を毎回実行するのが重い場合は、更新されたカテゴリに関係する評価質問だけを実行します。例えば、人事規程を更新した場合は人事関連の評価セットだけを回します。これにより、データ更新による精度低下を早期に検知できます。RAGのデータ更新は、再インデックスだけでなく再評価まで含めて完了と考えるべきです。
12. データ品質を改善する
RAGの精度は、元データの品質に強く依存します。重複文書、古い文書、矛盾した説明、表記揺れ、PDF抽出ミス、不要なヘッダーやフッターがあると、検索精度も回答精度も下がります。RAGを高精度にしたいなら、モデルや検索方式だけでなく、元データを整える作業が欠かせません。
12.1 重複文書を整理する
同じ内容の文書が複数存在すると、検索結果が重複し、古い版やコピー文書が検索される可能性があります。社内ファイルサーバーやクラウドストレージでは、「最新版」「最新版コピー」「最終版」「最終版_修正済み」のようなファイルが残りがちです。これらをすべてRAGに取り込むと、検索結果の信頼性が下がります。
改善策は、文書の正本を決め、重複や旧版を検索対象から除外することです。文書ID、版数、更新日、承認状態を管理し、RAGへ入れる文書を明確にします。RAGでは、データ量が多ければ良いわけではありません。信頼できるデータだけを検索対象にすることが、精度向上の基本です。
12.2 表記揺れを整理する
同じ意味の用語が複数の表記で使われていると、検索精度が下がることがあります。例えば、「顧客」「お客様」「クライアント」「取引先」が同じ意味で使われている場合、質問と文書の表現が一致せず、検索スコアが下がる可能性があります。特に専門用語や社内略語が多い企業では、表記揺れがRAG精度に影響します。
改善策として、用語辞書や同義語辞書を整備します。検索クエリを拡張する、メタデータを統一する、文書作成ルールを整えることで、検索の安定性が上がります。RAGは単なるAIシステムではなく、社内ナレッジ管理の延長にあります。用語管理は、RAG精度を支える重要な運用です。
12.3 PDFや表の抽出品質を確認する
PDFからテキストを抽出する場合、表の列が崩れる、段組みが混ざる、ヘッダーやフッターが本文に混入する、注記が別の場所に移動するなどの問題が起こります。抽出テキストが壊れていると、どれだけ良いチャンク設計をしても、検索対象としての品質が低くなります。
改善策は、取り込み後のテキストをサンプリング確認することです。特に表、箇条書き、注記、改ページ部分、脚注、図表キャプションを確認します。重要文書では、PDFではなく元のWord、HTML、Markdown、構造化データから取り込むことも検討します。RAGでは、データ抽出の品質が回答品質に直結します。
12.4 不要情報を除去する
文書に毎ページ同じヘッダー、フッター、ページ番号、著作権表記、ナビゲーション文が含まれると、検索ノイズになります。これらがチャンクに含まれると、埋め込みにも影響し、関係のない情報が検索される可能性があります。特にWebページやPDFをそのまま取り込む場合、不要情報の除去が重要です。
改善策は、取り込み前にクレンジング処理を行うことです。ページ番号、定型ヘッダー、フッター、空行、重複文を除去します。ただし、注意書きや免責事項など業務上重要な情報まで削除しないように、文書種類ごとにルールを分ける必要があります。データクレンジングは地味ですが、RAG精度改善に大きく効く工程です。
13. ログとフィードバックを改善に使う
RAGシステムは、本番利用が始まってから得られるログとフィードバックが非常に重要です。ユーザーが何を聞き、どのチャンクが検索され、どの回答が低評価だったかを記録すれば、チャンク設計、検索方式、プロンプト、データ更新の改善に活用できます。ログを取らないRAGは、誤回答の原因を追跡できず、改善が感覚的になります。
13.1 質問ログを保存する
ユーザーの質問ログを保存することで、実際にどのような情報が求められているかを把握できます。開発時に想定した質問と、本番で使われる質問は異なることが多くあります。ユーザーは正式な文書名ではなく、業務上の言い方、略語、曖昧な表現を使うため、質問ログは評価データを改善する重要な材料になります。
ただし、質問ログには個人情報、顧客情報、機密情報が含まれる可能性があります。そのため、保存項目、マスキング、閲覧権限、保存期間を設計する必要があります。RAGログは改善のための資産ですが、同時に情報管理の対象でもあります。ログ設計は、精度改善とセキュリティの両方を考えて行います。
13.2 検索結果ログを保存する
質問に対して、どのチャンクが検索されたかを保存することは、RAG改善に非常に重要です。chunk_id、source_id、score、rank、metadata、検索フィルタ条件を保存すれば、誤回答が発生したときに原因を切り分けられます。正しいチャンクが検索されていなかったのか、検索されていたがLLMが使わなかったのかを確認できます。
検索結果ログがない場合、ユーザーから「回答が違う」と言われても、検索の問題なのか生成の問題なのか判断できません。RAGの運用では、回答ログだけでなく、検索過程のログを残すことが重要です。これにより、改善活動をデータに基づいて進められます。
13.3 ユーザーフィードバックを集める
回答に対して、役に立った、役に立たなかった、根拠が違う、情報が古い、回答が長い、回答が曖昧といったフィードバックを集めます。単純なGood／Badだけでも有効ですが、理由を分類できると改善に使いやすくなります。低評価の理由が「検索結果が違う」のか「回答形式が悪い」のか「文書が古い」のかで、改善策が変わります。
ユーザーフィードバックは、評価データの追加にも使えます。低評価が付いた質問を評価セットに入れ、改善後に同じ問題が再発していないかを確認します。RAGの本番運用では、ユーザーの反応を精度改善サイクルに組み込むことが重要です。
13.4 誤回答を再発防止に使う
誤回答が発生した場合、個別に修正して終わりにするのではなく、再発防止に使います。誤回答の質問、検索されたチャンク、回答内容、正しい根拠、原因、対応策を記録します。これにより、同じタイプの誤回答が再発しにくくなります。
例えば、古い文書が検索されたならデータ更新運用を見直します。正しいチャンクが検索されなかったならチャンク設計やメタデータを見直します。正しい根拠があったのに回答が誤ったならプロンプトや回答評価を改善します。誤回答はRAGの弱点を教えてくれる重要な情報です。
14. 運用体制と責任分担を決める
RAGシステムは、AIチームだけで品質を維持できるものではありません。データ所有者、業務部門、セキュリティ担当、IT運用、法務、サポートなどが関わります。責任分担が曖昧だと、古いデータが放置され、誤回答の修正が遅れ、運用負荷が特定の担当者に集中します。
14.1 データ所有者を決める
RAGに取り込む各データソースには、内容の正しさを判断できる所有者が必要です。人事規程は人事部、契約テンプレートは法務部、製品FAQはサポート部、営業資料は営業企画部のように、データの責任者を明確にします。AIチームは取り込みや検索基盤を管理できますが、文書内容の正しさまでは判断できないことが多いです。
データ所有者が決まっていれば、文書更新、誤回答修正、旧版除外、メタデータ確認がスムーズになります。逆に所有者が不明な文書は、古くなっても誰も直せず、RAGの信頼性を下げます。RAGの精度維持には、技術担当だけでなく、業務側の責任分担が欠かせません。
14.2 AI運用担当を決める
AI運用担当は、RAGの検索ログ、評価結果、誤回答、プロンプト変更、再インデックス、データ更新の状況を管理します。単なるインフラ担当ではなく、RAGの品質を継続的に改善する役割です。運用担当がいないと、RAGは公開後に放置され、精度が徐々に低下します。
AI運用担当は、業務部門と技術チームの橋渡しも行います。低評価回答の原因を確認し、データ修正が必要ならデータ所有者へ依頼し、検索ロジックの調整が必要なら開発チームへ連携します。RAGは継続改善型のシステムであるため、運用責任者を明確にすることが重要です。
14.3 セキュリティ責任を明確にする
RAGは社内文書を横断的に検索するため、権限管理とログ管理が重要です。誰がどのデータを取り込んでよいか、誰が検索ログを見られるか、機密文書をLLMへ渡してよいか、外部APIへ送信されるデータは何かを確認する必要があります。これらを曖昧にすると、情報漏えいリスクが高まります。
セキュリティ担当は、入力データ、検索対象、権限フィルタ、ログ保存、外部サービス利用条件を確認します。特にクラウドLLMや外部ベクトルDBを使う場合、データ保持、学習利用、処理地域、契約条件も確認する必要があります。RAGのセキュリティは、検索基盤、データ運用、外部サービス利用をまとめて設計します。
14.4 改善会議を定期化する
RAGの精度改善は、単発対応ではなく定期的に行う必要があります。月次または隔週で、利用ログ、低評価回答、検索失敗、データ更新、評価結果を確認します。改善会議には、AI担当、業務部門、データ所有者、セキュリティ担当、運用担当が参加するのが理想です。
改善会議では、単に「精度が悪い」という感想ではなく、評価データとログをもとに原因を確認します。チャンクを見直すのか、データを修正するのか、プロンプトを変えるのか、検索範囲を絞るのかを決めます。RAG改善は、技術だけではなく業務データの品質改善でもあるため、部門横断で進める必要があります。
15. 全社展開を見据えたRAG基盤にする
小規模PoCで成功したRAGを全社展開する場合、個別最適のままでは運用が難しくなります。部門ごとに別々のチャンク設計、評価方法、ログ形式、権限管理を作ると、品質がばらつき、保守コストも増えます。全社展開を見据えるなら、共通基盤と部門別カスタマイズを分けて設計する必要があります。
15.1 共通コンポーネントを整備する
複数部門でRAGを利用する場合、文書取り込み、チャンク分割、埋め込み生成、検索、再ランキング、ログ、評価、権限フィルタ、根拠表示を共通コンポーネント化します。毎回ゼロから作ると、部門ごとに品質がばらつき、同じ問題を繰り返すことになります。
共通基盤を作れば、新しい部門でRAGを立ち上げる際も、データとプロンプト、評価質問を用意すれば展開しやすくなります。RAGは単一のAIチャット機能ではなく、社内ナレッジ活用の共通インフラとして設計することで、全社的な再利用性が高まります。
15.2 部門別に検索範囲を分ける
全社データを一つの検索対象にすると、ノイズが増え、権限管理も複雑になります。人事、営業、サポート、法務、開発、経理では、使う文書も質問の種類も異なります。そのため、共通基盤を使いながら、検索範囲は部門や用途ごとに分ける設計が現実的です。
例えば、人事RAGでは規程や申請手順を中心にし、サポートRAGではFAQや問い合わせ履歴を中心にし、営業RAGでは提案資料や製品情報を中心にします。共通化する部分と個別最適する部分を分けることで、精度と運用性の両方を高められます。
15.3 評価基準を標準化する
部門ごとに評価方法が異なると、全社的に品質比較ができません。検索ヒット率、根拠忠実性、回答正確性、最新文書参照率、権限外検索ゼロ、ユーザー評価など、共通指標を定義します。そのうえで、部門固有の評価指標を追加します。
例えば、法務RAGでは根拠厳密性を重視し、サポートRAGでは回答速度と問い合わせ削減を重視し、営業RAGでは提案文の使いやすさを重視します。共通指標と部門固有指標を分けることで、全社基盤としての品質管理と現場適合の両方を実現できます。
15.4 全社RAGロードマップを作る
RAGを全社展開する場合、いきなりすべての文書を対象にするのではなく、段階的に広げるべきです。最初はFAQやマニュアルのように構造化され、所有者が明確なデータから始めます。その後、規程、問い合わせ履歴、営業資料、契約関連文書へ拡張します。
ロードマップでは、データ整備、権限設計、評価セット、運用担当、セキュリティ審査、コスト管理をセットで計画します。RAGはAI機能であると同時に、データ基盤、検索基盤、運用基盤でもあります。全社展開では、PoCの成功をそのまま広げるのではなく、再利用可能な基盤と運用ルールに変えることが重要です。
おわりに
RAGシステムの精度を高めるためには、LLMやエンベディングモデルの選定だけでなく、チャンク設計、メタデータ設計、検索方式、再ランキング、評価データ、ログ、ユーザーフィードバック、データ更新運用まで含めて考える必要があります。特に企業向けRAGでは、正しい文書が検索されること、最新版が使われること、権限外データが出ないこと、回答が根拠に忠実であること、誤回答が発生したときに原因を追跡できることが重要です。RAGは「AIに文書を読ませる仕組み」ではなく、社内ナレッジを検索可能・評価可能・更新可能な形で運用するためのシステムです。
チャンク設計では、固定サイズだけに頼らず、FAQ、規程、マニュアル、議事録、問い合わせ履歴など文書種類ごとの構造を考慮する必要があります。評価では、検索評価と回答評価を分け、Top Kに正解根拠が入るか、ノイズが少ないか、回答が根拠に忠実か、答えがない場合に適切に拒否できるかを確認します。そして、データ更新、廃止文書の除外、再インデックス、更新後の再評価、誤回答の再発防止まで運用に組み込むことで、RAGはPoCで終わらず、企業のナレッジ活用基盤として継続的に改善できるようになります。
