業務起点RAG設計―1.3万人規模のナレッジ基盤による実践―

社内ナレッジ活用の背景

現在、PwC Japanグループには約1万3,000人のプロフェッショナルが在籍し、業務を通じて日々膨大なナレッジを生み出しています。しかし、これらのナレッジが必要な人に必要なタイミングで届いているかというと、多くの課題があります。

典型的な例が、社内で日常的に発生する情報提供依頼です。クライアント向けの提案準備にあたり、類似事例や特定領域の知見を求めるメールが社内の広い範囲に送られますが、回答が集まるまでに時間がかかる上に、情報を持つ担当者も本業で忙しく、対応できないことが少なくありません。組織にナレッジは存在しているにもかかわらず、形式知のまま埋もれている状態です。

この課題を解消するために、PwC Japanグループでは職員自ら必要なナレッジにアクセスできる環境を目指し、全社のナレッジ検索基盤にRAG（Retrieval-Augmented Generation：検索拡張生成）を導入しました。これは、クライアント向け提案書や社内成果物等から関連情報を検索し、自然言語で回答を生成する仕組みです。

本稿では、このRAG基盤の初期設計で確認された課題と、それを踏まえた設計見直しの内容について、要件定義の考え方、検索精度・応答速度・コストのバランスを踏まえたアーキテクチャの設計判断を中心に解説します。

課題の構造

RAGを導入した検索基盤は技術検証を経て運用を開始しましたが、検索体験の品質に課題が残りました。応答速度の遅さ、検索結果の粒度が利用者の期待と合わないこと、そして最新のナレッジが検索対象に反映されないことが主な問題でした。

初期設計の課題は大きく2つに分類されました。

1つ目は、検索基盤が利用者の業務に沿った設計になっていなかったことです。初期設計はファイル検索の延長にとどまっており、利用者が求めていた「誰がいつどのクライアントにどのように提案したのかを一覧で把握できる」「必要な適性を持つ職員がすぐに表示される」といった業務要件に応えられていませんでした。

加えて、情報粒度と応答速度の問題がありました。初期設計では各ナレッジから複数のQ&Aを自動生成しベクトル検索の対象としていましたが、粒度が細かくなりすぎる傾向がありました。例えば、金融業界における生成AI活用事例を探した利用者に対して「この案件の支援期間は何年何月から何年何月です」といった断片的な情報が返される状態です。利用者が知りたいのは、どのような課題にどのようなアプローチで提案したかという全体像であり、探索意図と情報粒度が噛み合っていませんでした。

この背景には、ベクトル検索そのものの特性と、それを補完する手法の限界があります。一般的なベクトルデータ基盤に対してHyDE（Hypothetical Document Embeddings）のようなLLM（大規模言語モデル）によるクエリ拡張を適用すれば検索精度は向上しますが、検索のたびにLLM推論が発生するため応答速度が低下します。この応答速度の問題を回避するために、初期設計ではナレッジからあらかじめQ&Aを自動生成し、事前にembeddingしておく方式を採用していました。しかし、この方式にはアーキテクチャ上の原理的な課題がありました。ファイル数が膨大になるほど生成されるQ&Aが爆発的に増加し、断片的で細かい情報の中に重要で役立つ情報が埋もれてしまいます。加えて、検索対象の増大に比例して応答速度も低下するため、大規模環境ではスケールしない構造でした。これらの限界を根本的に解決するには、ベクトル検索の改善ではなく、業務要件に応じたデータマート設計への転換が必要でした。

2つ目は、情報鮮度の劣化です。ナレッジにはクライアント名や受注金額といった秘匿情報が含まれるため、専門部署による匿名化処理（クライアント名や金額等の秘匿情報を非特定化する処理）を経てから検索対象として公開する運用でした。スライドをそのまま閲覧可能な状態で提供する前提であったため、社内規定に基づく匿名化基準に沿って一枚一枚手作業で確認・匿名化する必要があり、かつ届いた順に処理されるため鮮度に応じた優先度付けもなく、処理の完了までに長い期間を要しました。その結果、鮮度の高い情報ほど利用者に届くのが遅れ、最新のナレッジが検索対象に反映されないという問題が常態化していました。

これらの課題は、検索の技術的成立を設計のゴールとし、業務上の意思決定への寄与をゴールとしていなかったという共通の構造に起因しています（図表1）。

図表1：初期設計の課題構造

技術選定の前に確定させた2つの要件

私たちはこの構造を変えるにあたり、モデルやアルゴリズムの改善ではなく要件の再定義から着手しました。

1点目は、有用性の定義です。ここでは、検索結果を基に利用者が次の業務アクションに進めたかどうかを判定基準としました。案件検索であれば提案骨子の作成に移行できたか、人材検索であればアサイン検討に着手できたかという水準です。

2点目は、まずつなげることから始め、共有の範囲を段階的に広げていくという提供方針です。匿名化処理による統制要件と迅速な情報反映は一見トレードオフの関係ですが、全ての情報を同じタイミングで完全な形で提供する必要はありません。鮮度の高いナレッジについては、まず提案の概要・関与者・時期・対象領域といった情報をテキストベースのナレッジ概略として先行提供し、人手による匿名化完了後に元ファイルへのアクセスを開放する「段階的提供」の方針を定めました。プロフェッショナルサービスにおける形式知化の代表的手法であるスライド原本の提供にこだわらなければ、LLMで匿名化した上で速やかに情報を届けられるという仮説がこの方針の起点です。

設計の見直し

これら要件を基に、索引設計の転換と処理レーンの分離の2点で設計を見直しました。

第1に、索引設計の転換です。初期設計のQ&A自動生成による網羅的な検索方式を改め、対象ユースケースを案件情報の検索と人材情報の検索の2つに限定しました。案件情報の検索では、提案の概要・関与者・時期・対象領域・金額感といった項目を構造化データとして提供します。人材情報の検索は今回新たに追加したユースケースであり、必要な適性を持つ職員を一覧で表示する機能として設計しました。

この設計転換の技術的な核は、ベクトル検索だけに依存せず、業務エンティティごとのデータマートを設計した点にあります。全てのドキュメントに対して超詳細な情報抽出とembeddingを行い、検索時にも大規模なLLM推論をリアルタイムで実行すれば、検索応答の精度は上がります。しかし、その分だけ応答速度は低下し、運用コストも許容範囲を超えてしまいます。

このトレードオフに対する解が、業務エンティティごとのデータマート分割でした。一般的なベクトルデータ基盤がファイル単位の非構造データをそのままembeddingするのに対し、本設計ではドキュメントをプロジェクト単位で分解し、クライアント・関与者・提供ソリューションといった業務エンティティごとにデータマートを構造化しています（図表2）。利用者の検索クエリに必要な情報項目を業務要件から逆算し、その粒度でナレッジ概略を事前に生成・構造化しておくことで、検索時のLLM推論を最小限に抑えつつ、利用者が求める品質の応答を実用的な速度で返す設計です。

この設計の上位にはセマンティックレイヤーを配置しています。セマンティックレイヤーは、利用者の検索クエリに対してどのデータマートをどのように参照すべきかを定義する層であり、LLMがクエリ意図を解釈した上で適切なデータマートを動的に選択して検索を実行します。従来のベクトル検索にはこのセマンティックレイヤーに相当する仕組みがなく、構造化データを用意しても十分に活用できませんでした。LLMの推論能力の向上により、このセマンティックレイヤーが実用的に機能するようになったことが、本設計を可能にした技術的な前提です。

これらの構造化データはナレッジ概略としてテキストベースで利用者に提供します。また、この構造化により、類似案件のクラスタリングによるマネジメント層向け活用事例集の自動生成など、蓄積データの二次利用も可能になります。

第2に、情報の秘匿度合いに応じて共有方法にグラデーションをつけることで、速度と統制を両立する処理レーンの分離です。初期設計の匿名化プロセスを廃止するのではなく、並行する形で新たなレーンを追加しました（図表3）。図表2の構造化データマートは、先行提供レーンでLLMが生成する匿名化済みナレッジ概略の格納先として機能します。

先行提供レーンでは、OCR（光学文字認識）で抽出したテキストにLLMによる自動匿名化を適用し、ナレッジ概略として構造化データマートに格納した上で速やかに検索対象へ反映します。確認後提供レーンでは、従来どおりの専門部署による匿名化処理を経てスライドを含む元文書を提供します。

この設計のポイントは、初期設計の匿名化プロセスを置き換えずに、並行して動く新たなレーンを加えた点です。専門部署による匿名化の品質を維持したまま、先行提供レーンでLLMにより速やかにテキスト情報を届けることで、利用者が新鮮な情報にアクセスするまでの時間を短縮します。ナレッジ概略で該当案件を特定し、必要に応じて匿名化完了後の原本で詳細を確認する2段階の利用フローは、実務上の情報探索行動とも整合しています。

図表3：転換後の処理アーキテクチャ

なお、ナレッジ検索基盤の構築にあたっては、AIアシスタント機能を備えた既製の検索ソリューションの活用も検討しました。しかし、ナレッジの構造化、匿名化処理のレーン分離、ナレッジ概略の生成方式といった点でパラメータやコンテキストの細かな調整が必要であり、既製ソリューションでは対応しきれないと判断し、業務要件に応じた独自の設計を採用しています。

設計見直しの意義と期待される効果

今回の見直しは、RAG基盤の運用で陥りやすい問題を構造的に回避するものでもありました。

1つ目は、検索品質が低い時に課題を技術問題として捉え、モデルの高度化から着手してしまう問題です。本設計では、技術選定の前に利用者の業務行動と判断場面を定義し、そこから要件を逆算することで回避しました。

2つ目は、検索の網羅性を優先するあまり、情報粒度の設計が後回しになる問題です。本設計では、ナレッジ概略という利用者が求める粒度の提供形態を先に定義することで回避しました。

3つ目は、秘匿度合いの異なる情報を全て単一の処理フローで扱おうとする問題です。本設計では、先行提供レーンと確認後提供レーンを分離し、情報特性に応じた提供経路を設けることで回避しました。

4つ目は、既存の匿名化プロセスを新しい仕組みで置き換えようとする問題です。本設計では、初期設計の匿名化プロセスを維持したまま並行するレーンを追加する方針としたことで、関係部署との合意形成を円滑に進めることができました。

本設計は現在本番展開準備の段階であり、効果検証はこれからです。最も期待しているのは、業務エンティティごとのデータマート分割により検索結果の粒度がユーザーの求める情報粒度と合致し、検索体験の品質が向上することです。加えて、先行提供レーンの導入により鮮度の高いナレッジが速やかに検索対象へ反映されるようになり、利用者が類似案件の有無を確認するまでの初動時間は大幅に短縮される見込みです。効果は本番展開後に定量・定性の両面で検証していく予定です。

まとめ

本稿では、PwC Japanグループの全社向けナレッジ検索基盤の設計見直しについて解説しました。HyDEや事前Q&A生成といった従来手法の限界を踏まえ、業務エンティティごとのデータマート分割とセマンティックレイヤーによる動的選択で検索品質とコスト・速度を両立し、既存の匿名化プロセスとLLMによる先行提供レーンの並行稼働で情報鮮度と統制を両立する設計としました。

組織のナレッジは全てがデータ化されているわけではなく、データ化されている情報にも活用には限界があります。PwCではその限界を前提とした上で、利用者の目的に立脚し、データの認可やガバナンスを損なうことなくテクノロジーで課題を解決するという姿勢を重視しています。本稿が同様の課題に取り組む方々の参考となれば幸いです。