利益:
- エンドツーエンドのエンタープライズ RAG アシスタントのコンポーネントとデータ フローの設計
- マルチソース データ (Wiki、チケット、PDF、データベース) を単一のアシスタントに結合する
- スケーラビリティ、キャッシュ、レイテンシーに関するアーキテクチャ上の決定を下す
前の単元では、埋め込み、ベクトル データベース、チャンキング、検索の各部分を 1 つずつ学習しました。次に、これらを組み合わせて、自社のデータと対話するアシスタントのエンドツーエンドのアーキテクチャを構築しましょう。目標は、従業員に「当社の休暇制度は何ですか?」と尋ねさせることです。人々が質問できるシステム。その回答は実際の内部文書や引用に基づいており、複数のデータ ソースを組み合わせています。このユニットは、アーキテクチャ全体、データ フロー、および運用レベルの決定を処理します。
エンドツーエンドのコンポーネント
企業 RAG アシスタントは 2 つの別々の行で構成されます。インデックス作成ライン (オフライン) がデータを準備します。クエリ行 (オンライン) が質問に答えます。
インデックス行コンポーネント:
- コネクタ: ソース (Wiki、チケット システム、ファイル ストア、データベース、電子メール) からデータを取得するコネクタ。
- 正規化: さまざまな形式 (PDF、HTML、DOCX) をクリーン テキストに変換します。ヘッダー/フッターのクリーニング。
- チャンキング + メタデータ: チャンキングとタグ付け (ソース、日付、典拠)。
- 埋め込み + 読み込み: ベクターとメタデータをベクター データベースに書き込みます。
クエリ パイプライン コンポーネント:
- クエリの前処理: 書き換え、分散化。
- 取得: ハイブリッド検索 + メタデータ フィルター + 再ランキング。
- プロンプトの作成: コンテキスト + 質問 + 指示をテンプレートに配置します。
- 生成: モデル + ソースからの根拠のある (コンテキストに基づく) 回答。
- 後処理: 引用の書式設定、セキュリティ チェック、ログ記録。
ヒント: インデックス行をクエリ行から物理的に分離します。インデックス作成は遅く、定期的です (夜間にバッチで実行されます)。質問は軽く、即座に行う必要があります。 2 つの行を混在させると、ユーザーが待機している間に重い処理が必要になります。
データフローの視覚化
[インデックス - オフライン]リソース → 正規化 → チャンク + メタデータ → 埋め込み → ベクター DB (wiki、チケット、PDF、DB)[クエリ - オンライン]ユーザーの質問 → 前処理 → 取得 (ハイブリッド + フィルター + 再ランク) → プロンプト (コンテキスト + 質問 + 説明) → モデル → 回答 + ソース → ユーザー
マルチソースデータの結合
実際の企業では、答えは 1 か所にとどまりません。 「顧客に返金するにはどうすればよいですか?」質問に対する答えは、ヘルプ記事 (手順)、チケット履歴 (実際の例)、およびポリシー PDF (ルール) の両方で見つけることができます。アシスタントは、1 つのプール内のすべてを検索する必要があります。
重要な点: リソースを単一のベクター ストアに結合する場合、各シャードは「source_tour」メタデータを保持する必要があります。したがって、それらをすべて検索し、必要に応じて「公式ポリシーのみを持ち込む」などのフィルターをかけることができます。また、ソースごとに信頼性のレベルも異なります。公式ポリシー > ヘルプ記事 > 従業員のチケットメモ。この優先度は、再ランキングまたはプロンプトで指定できます。
ソース
コンテンツタイプ
信頼
更新頻度
ポリシーPDF
公式ルール
高い
毎月
ヘルプ記事
手順
中～高
毎週
チケット履歴
本物のサンプル
中程度
継続的
ウィキ
ミックス/現在のノート
変数
継続的
スケーラビリティ、キャッシュ、レイテンシ
本番環境では 3 つの問題が目立っています。遅延: ユーザーが 2 秒を超えて待機すると、エクスペリエンスが低下します。解決策: 答えをストリーミング形式で表示します。答えは、モデルが書き込むときに画面に注がれます。キャッシュ: よくある質問や反復的なコンテキストについては、キャッシュによって速度が向上し、コストが削減されます。スケール: ユーザーが増加するにつれて、検索とモデル呼び出しを水平方向にスケールできる必要があります。
コスト面の経験則: 最もコストがかかるステップは、通常、より大きなモデルに送られるトークンの数です。したがって、再ランキングによってコンテキストを 4 つの良好な部分に減らすと、品質とコストの両方が向上します。一般的な設計は、単純な分類またはルーティングにはより小型/高速のモデルを使用し、最終的な回答にはより強力なモデルを使用することです (例: claude-opus-4-8)。
注意: インデックス作成を「一度実行したら忘れる」ように設定しないでください。ドキュメントが変更、削除、追加されます。インデックスの再作成戦略を確立します。変更されたドキュメントを検出し、それらのみを再処理します。インデックスが古いと、最新のように見える答えが生成されますが、間違っています。
弱いアーキテクチャ / 強いアーキテクチャ
弱い (単一のスクリプト、すべてが混在):
ユーザーが尋ねると、その瞬間にドキュメントを読み、細断し、埋め込み、検索し、回答します。 # 問題: すべてのインデックス作成が質問ごとに繰り返されます。数秒の遅延、 # ソース分離なし、フィルタなし、リフレッシュなし。
強力 (分割パイプ + メタデータ + キャッシュ + ストリーミング):
インデックス作成: バッチは夜間に実行され、変更されたドキュメントを更新します。クエリ: 軽量ライン — 前処理 → ハイブリッド取得 + フィルター → 再ランク → プロンプト → モデル (ストリーミング) → 引用 → ログ。よくある質問とソースがキャッシュされます。
ミニケース3個
ケース 1 — 回線が混乱し、大幅な遅延が発生します。あるスタートアップは、質問ごとに PDF を再処理するスクリプトを作成しました。各回答には平均 11 秒かかりました。インデックス行が分離され、データがベクター ストアに事前に転送されていた場合、クエリ時間は 1.3 秒に短縮され、ストリーミングでは「最初の単語」が 400 ミリ秒で表示されました。
ケース 2 — リソースが多すぎるため、優先順位が間違っています。サポート アシスタントは、ポリシーの PDF と古いチケットのメモを同等に重視しました。このモデルは、2 年前の従業員の誤った評価を公式ルールとして提示することがありました。 source_tour メタデータと「競合が発生した場合は公式ポリシーを考慮する」という指示をプロンプトに追加すると、誤った優先順位のエラーが 89% 減少しました。
ケース 3 — 古いインデックス。人事アシスタントは 3 か月間更新されなかったインデックスを使用していました。休暇の方針は変わりましたが、アシスタントは昔のことを言っていました。変更されたファイルを検出する毎日の更新をインストールすると、現在の応答率が 70% から 99% に増加しました。
よくある間違い
- インデックス作成とクエリ行の混合: ユーザーが待機している間に重い処理が実行されます。遅れが爆発する。
- ソースタイプをメタデータに含めない: 優先順位付けとフィルタリングは行われません。信頼できない情報源は公式のもののようです。
- リフレッシュ戦略を確立していない場合: インデックスが古くなります。現在のように見える間違った答えが生成されます。
- ストリーミングをスキップ: ユーザーは空白の画面を見ます。知覚される遅延が大きくなります。
- 各ステップで最大のモデルを使用すると、コストが不必要に増加します。ステアリングは小型モデルにお任せください。
要約すると
- 企業 RAG アシスタントは、オフライン インデックス作成とオンライン クエリという 2 つの別々のラインで構成されます。それらを物理的に分離します。
- インデックス付け = コネクタ + 正規化 + チャンク/メタデータ + 埋め込み/アップロード;クエリ = 前処理 + 取得 + プロンプト + 生成 + 後処理。
- マルチソース データは 1 つのリポジトリに結合されますが、source_type メタデータと信頼優先度は保持されます。
- レイテンシのためのストリーミングとキャッシュ、コストのためのコンテキスト スロットリング、およびモデルの選択が重要です。
- インデックスを再作成しないと、インデックスは古くなってしまいます。変更された文書を定期的に再処理します。
アプリケーションタスク
自分のチームのアシスタントのアーキテクチャ図を描きます。 (1) 少なくとも 3 つの実際のデータ ソースを特定し、それぞれのコネクタの必要性、更新頻度、信頼レベルを書き留めます。 (2) ボックスアローダイアグラムを使用して、インデックス線とクエリ線を別々に描画します。 (3) 「このアシスタントのレイテンシーとコストを削減するにはどうすればよいですか?」質問に対して少なくとも 2 つの具体的な決定を書きます。 (4) 更新戦略を一文で説明してください。どのリソースがどのくらいの頻度でインデックスを再作成されますか?
チェックリスト
- [ ] インデックス行とクエリ行を別々に、正しいコンポーネントを使用して描画できます。
- [ ] マルチソース データを、source_type および信頼優先度を使用して組み合わせることができます。
- [ ] レイテンシを考慮してストリーミング/キャッシュを決定し、コストを考慮してモデルを選択できます。
- [ ] インデックス再作成戦略がなぜ不可欠なのかはわかりました。
- [ ] 私のアーキテクチャで最もコストがかかるステップは、通常、より大きなモデルに送られるトークンであることを念頭に置いています。