RAG パイプライン ドキュメント

本ドキュメントでは、LMS プラットフォームに組み込まれた RAG（Retrieval-Augmented Generation）基盤の アーキテクチャ、データ処理フロー、インデックス更新手順、ベストプラクティスについて解説します。 RAG 管理者エリア（/RagAdmin）と連携し、企業の社内ナレッジを活用した AI アプリケーションを構築できます。

1. 全体アーキテクチャ

本プラットフォームの RAG は以下のコンポーネントで構成されています。

  • Data Source：社内文書、SharePoint、Wiki、PDFアーカイブなど
  • Crawler：定期的に Data Source をクロールし、差分を検知
  • Preprocessor：テキスト化、クリーニング、正規化、チャンク分割
  • Embedder：ベクトル埋め込みを生成
  • Vector Store：検索用ベクトルデータベース（Azure AI Search 等）
  • Indexer：メタデータ・埋め込み・原文をまとめてインデックスへ投入
  • RAG Runtime：検索＋生成パイプライン（LLM）

これらは RagAdmin 画面で管理され、状態確認・手動実行・テストが可能です。

2. データフロー（クロール → インデックス → RAG）

① Crawler（取得）
  • 認証（OAuth / API Key / Cookie など）によりデータ取得
  • 差分検出（更新日 / ハッシュ比較）
  • 対応形式：PDF, Word, Excel, HTML, Markdown, TXT, JSON
② Preprocessor（前処理）

ナレッジの品質に大きく影響する工程です。

  • OCR（PDF/画像）
  • 不要要素除外（ナビゲーション / 目次 / ヘッダー・フッター）
  • 段落・文脈単位でのチャンク分割（標準：500〜1200文字）
  • メタデータ生成（タイトル / パス / タグ / 最終更新日）
③ Embedder（埋め込み）
  • OpenAI / Azure OpenAI（text-embedding-3-large など）
  • 句読点除去や正規化後にベクトル生成
④ Indexer（インデックス投入）
  • ベクトル + 文章 + メタデータをドキュメントとして Index に格納
  • 部分更新と全件再構築の両モードに対応
⑤ RAG Runtime（検索＋生成）

RAG の最終ステップとして、検索結果を LLM に渡します。

  • Top-k Search（標準 5〜10件）
  • Hybrid Search（ベクトル + キーワード）
  • Context Window 最適化（類似テキストの重複排除）

3. インデックス仕様

フィールド 説明
id 文書ごとの一意ID（UUID）
text チャンク化された本文テキスト
vector 埋め込みベクトル（float[]）
sourceType SharePoint / Web / PDF / Wiki / Other
sourcePath 取得元URL or パス
updatedAt 最終更新日時

4. ベストプラクティス

■ チャンク分割の最適化
  • 短すぎると検索精度が低下
  • 長すぎるとノイズが混ざる
  • 500〜800文字が最も安定
■ メタデータの充実
  • 部署名・文書タイプ・タグを付与すると検索精度が向上
  • タグは後から再付与可能
■ 更新頻度の制御
  • 毎日更新 → ドキュメント数が少ない場合
  • 週次 or 変更検知 → 大規模な場合

5. API と Webhook

RAG パイプラインは API と Webhook で外部システムと連携できます。

6. トラブルシューティング

  • クロールが途中で止まる → 認証期限切れ、IP 制限
  • インデックスが増え続ける → 差分検出ルールの見直し
  • 検索精度が不安定 → チャンク分割・メタデータ再構築を実施

次：API ドキュメントへ →