リファレンスアーキテクチャ
参考例AIナレッジプラットフォーム
企業のドキュメントやシステムを対象とした質問に答える、検索拡張生成（RAG）プラットフォームです。引用の提示、権限を考慮した検索、完全なオブザーバビリティを備えます。
課題
業務上の知識が、ドキュメント、Wiki、チケット管理ツール、データベース、社内システムに分散している組織を想定します。担当者は適切な情報源を探すのに時間を費やし、それが最新かどうかを判断するのにさらに時間を費やします。キーワード検索が返すのは答えではなくページであり、情報の所在を知っている人がボトルネックになります。
言語モデル単体では、この問題は解決しません。モデルは組織のコンテンツについての知識を持たず、答えるべきでない場面でも自信を持って回答し、誰が何を閲覧できるのかという概念も持ちません。エンジニアリング上の課題は、モデルを組織自身の資料にグラウンディングさせ、その資料を最新に保ち、既存の権限を尊重し、すべての回答を検証可能にすることです。
設計が満たすべき要件
- すべての回答は、生成の根拠としたパッセージを引用しなければなりません。検索で関連する情報が見つからない場合、システムは回答を控える必要があります。
- 検索はソースシステムの権限を強制し、ユーザーが直接開くことのできないコンテンツを受け取ることがないようにしなければなりません。
- ソースシステムでの変更は、削除や権限変更を含め、定められた鮮度の時間枠内にインデックスへ反映されなければなりません。
- プロンプト、モデル、検索に対する変更をリリースする前に、継続的に保守される評価セットで回答品質を測定できなければなりません。
- アプリケーションを書き直すことなくモデルプロバイダーを差し替えられ、機微なデータは合意された境界の内側にとどまらなければなりません。
- すべてのリクエストをエンドツーエンドで追跡でき、レイテンシ、トークンコスト、検索結果がステップごとに記録されなければなりません。
設計
コンポーネント
取り込み
- 01
ソース
ドキュメント、データベース、社内API
- 02
パースとチャンク化
構造を保ったままテキストを抽出
- 03
埋め込み
バッチ処理、モデルはバージョン管理
- 04
インデックス化
ACL付きのベクトル・キーワードインデックス
クエリ
- 01
質問
認証済みユーザーとそのアクセス範囲
- 02
検索
ベクトルとキーワードのハイブリッド検索
- 03
リランキング
最も関連性の高いパッセージのみ残す
- 04
生成
引用付きの根拠ある回答
- 05
評価と記録
トレース、スコア、フィードバックを記録
取り込みとコネクター
コネクターは、スケジュールに従って、または変更イベントに応じて、ドキュメントストア、Wiki、データベース、社内APIからコンテンツを取得します。各ドキュメントは、ソース識別子、バージョン、アクセス制御リストを保持したままパイプラインを通ります。削除と権限変更は、次回のフルクロールのついでに処理するものではなく、第一級のイベントとして扱います。
パース、チャンク化、埋め込み
ドキュメントは、見出し、表、ページ参照を保ったままテキストにパースされ、コンテンツの種類に合ったサイズのチャンクに分割されます。埋め込みはバージョン管理された埋め込みモデルによってバッチで生成されるため、モデルが変わった際にはインデックスを計画的に再構築できます。チャンクのメタデータは、有用な引用を組み立てられるだけの情報量を保ちます。
ベクトルデータベースとキーワードインデックス
チャンクはベクトルインデックスに格納され、同じコンテンツに対するキーワードインデックスも併せて保持します。ハイブリッド検索は、どちらか一方の手法では弱いケースを補います。一方は正確な識別子や製品コード、もう一方は言い換えられた質問です。アクセス制御のメタデータは各チャンクとともにインデックス化されるため、フィルタリングはクエリの後ではなくクエリの内部で行われます。
LLMオーケストレーションサービス
専用のサービスが、プロンプトテンプレート、クエリの書き換え、検索、リランキング、モデルルーティング、ガードレールを担います。プロンプトはアプリケーションコードに散在する文字列ではなく、テストを伴うバージョン管理されたアーティファクトです。このサービスは小さく安定したコントラクトを公開するため、モデルプロバイダーと検索戦略を差し替え可能な状態に保てます。
エンタープライズAPI層
APIゲートウェイは、認証された単一のインターフェースを通じて、Webクライアント、チャットツール、その他の社内システムにプラットフォームを公開します。ユーザー単位およびアプリケーション単位でレート制限とクォータを適用し、長い回答でも応答性を感じられるようレスポンスをストリーミングします。記録システム（システム・オブ・レコード）に対する構造化された参照は、型付きツールとしてオーケストレーターに提供されます。
認証と認可
ユーザーは、OIDCまたはSAMLを用いて組織のIDプロバイダー経由でサインインします。ユーザーのIDとグループ所属は検索クエリに伝播され、各チャンクとともに保存されたアクセス制御リストと照合されます。サービス間の呼び出しには、共有キーではなく短命のクレデンシャルを使用します。
評価ハーネス
期待されるソースと参照回答を備えた、精選された質問セットを、変更候補のすべてに対して実行します。検索と生成は別々に採点します。両者は異なる理由で失敗し、修正する場所も異なるためです。本番で得られたユーザーフィードバックはレビューされ、時間をかけて評価セットに組み込まれていきます。
オブザーバビリティ
各リクエストは、クエリの書き換え、検索、リランキング、生成を網羅するトレースを生成し、取得されたチャンクの識別子、トークン数、レイテンシが付与されます。ダッシュボードでは、リクエストあたりのコスト、検索ヒットの品質、回答を控えた割合を追跡します。これによって、質の低い回答は単に報告されるだけのものではなく、原因を診断できるものになります。
トレードオフ
設計判断
| 判断 | 理由 |
|---|---|
| ファインチューニングよりも先に検索拡張生成を採用 | 企業のコンテンツは日々変化し、出典をたどれなければなりません。検索は鮮度、引用、権限を直接扱えますが、ファインチューニングは知識を重みに焼き込むため、引用することも選択的に取り消すこともできません。検索品質が確立した後であれば、文体やフォーマットの調整を目的としたファインチューニングは選択肢として残ります。 |
| リランキング段階を伴うハイブリッド検索 | ベクトル検索だけでは部品番号や条項参照のような正確な語句を取りこぼし、キーワード検索だけでは言い換えを取りこぼします。両方を実行し、統合した候補をリランキングすると追加のレイテンシが発生しますが、検索品質が回答品質の上限を決めるため、このコストは受け入れます。 |
| 権限は検索時に、インデックスクエリの内部で強制 | 生成後のフィルタリングでは遅すぎます。モデルはすでに制限対象のテキストを読んでしまっているためです。各チャンクにアクセスメタデータを保存するとインデックスサイズが増え、権限の同期が必須要件になりますが、構造上漏えいを防げる配置はこれしかありません。 |
| オーケストレーションサービスをアプリケーションから分離 | プロンプト、ルーティング、ガードレールを1つのサービスに集約すると、ネットワークホップが1つ増え、運用すべきコンポーネントも1つ増えます。その代わりに、複数のアプリケーションがテスト済みの単一の実装を共有でき、モデルやプロバイダーの変更は書き直しではなく、範囲の限定されたリリースで済みます。 |
| 根拠が弱い場合は回答を控える | 検索の関連度にしきい値を設けると、本来は回答できる質問の一部も拒否されることになります。それでも、裏づけとなる出典のない流暢な回答よりは望ましい選択です。プラットフォームへの信頼は、築かれるよりも速く失われるためです。 |
意図する成果
- 出典を引用し、レビュー担当者が検証できる回答
- 並行するアクセスモデルを新たに作らず、既存の権限に従う検索
- プロンプト、モデル、検索への変更をリリース前に評価できる体制
- 質の低い回答の原因を、特定の検索ステップまたは生成ステップまでたどれる状態
この設計が達成を目指すものです。参考例であり、クライアント案件の実測結果ではありません。
代表的な技術
- Python
- FastAPI
- TypeScript
- Next.js
- PostgreSQL
- pgvector
- OpenSearch
- Redis
- Kafka
- Kubernetes
- OpenTelemetry
- OIDC / SAML