ファインチューニングなしでLLMにデータへのアクセスを可能にします。RAGは、汎用言語モデルとドメイン固有の知識との間のギャップを埋めます。

組織のドキュメント(契約書、ポリシー、ナレッジベース、製品ドキュメント、医療記録など)に関する質問に答えるAIアシスタントを構築したいと考えている場合。LLMをデータに基づいてファインチューニングすることは、高価で時間がかかり、トレーニング時点から固定されたモデルを作成することになります。LLMがクエリ時に最新のドメイン固有の情報にアクセスし、その情報源を引用し、ドキュメントに存在しない事実のハルシネーションを避けることができるアーキテクチャが必要です。RAG(Retrieval-Augmented Generation)は、その実現方法です。
Explore more design patterns and system architectures
MicrocosmWorks は RAG パイプラインにおける競合解決を、ソース権威ランキング、タイムスタンプに基づく最新性重み付け、そして各取得パッセージがその主張をどれだけ強く支持するかを評価する信頼度スコアリングを通じて実装しています。矛盾するパッセージが取得された場合、当社のパイプラインは最も権威のある回答を提示し、ユーザーが情報に基づいた意思決定を行えるよう、不一致と出典を透明に表示します。また、ドメインエキスパートが不正確な解決策にフラグを立てられるフィードバックループを構築しており、これにより時間の経過とともに取得ランキングが向上します。
MicrocosmWorksは、ドキュメント構造に基づいて異なる戦略を適用するコンテンツアウェアなチャンキングを使用しています。具体的には、散文にはセマンティックな段落分割、ヘッダーコンテキストを保持したテーブルには行レベルまたはセクションレベルのチャンキング、そしてインポートステートメントを付加したコードには関数レベルのチャンキングを適用します。私たちは各チャンクに、ドキュメントタイトル、セクション階層、コンテンツタイプなどのメタデータで情報を付加することで、検索ステージでタイプ固有のスコアリングを適用できるようにしています。このアプローチは、私たちのクライアントプロジェクトにおける検索関連性ベンチマークにおいて、素朴な固定サイズチャンキングを25〜40%一貫して上回っています。
MicrocosmWorksは、RAGパイプラインを3つの側面からテストする評価ハーネスを構築しています。すなわち、検索の関連性(適切なチャンクが見つかっているか)、回答の忠実性(生成された回答が実際に検索されたコンテンツを反映しているか)、そして回答の完全性(質問全体に対応しているか)です。私たちは、既知の回答を持つクエリ、敵対的なエッジケース、複数ドキュメントの統合を必要とする質問を含む、ドメインエキスパートと共にゴールデンテストセットを作成します。この評価はCI/CDで自動的に実行されるため、すべてのパイプラインの変更はデプロイ前に基準品質メトリクスに対してベンチマークされます。
MicrocosmWorks は、お客様の規模、クエリパターン、運用要件に基づいて vector database を選定します。マネージドのシンプルさには Pinecone、ハイブリッドなキーワード・vector 検索には Weaviate、すでに PostgreSQL に投資しているチームには pgvector、高スループットなセルフホスト型デプロイメントには Qdrant を推奨しています。1,000万 vector 未満の規模では、ほとんどの選択肢が 100ms 未満の latency を実現しますが、数億 vector の規模になるとその差は顕著になり、index type、quantization、および sharding strategy が極めて重要になります。私たちはアーキテクチャ設計フェーズで、お客様の実際の embedding dimensions とクエリパターンを候補となるオプションに対してベンチマークします。
MicrocosmWorksは、ソースドキュメントリポジトリの変更を監視し、変更されたセクションのみをre-chunkおよびre-embedし、完全なreindexを必要とせずにvector storeを更新する、漸進的な取り込みパイプラインを構築しています。当社は、セクションレベルでコンテンツの変更を検出するdocument fingerprintingを実装しているため、1つの段落の編集で200ページ全体のドキュメントの再処理がトリガーされることはありません。リアルタイムの鮮度要件を持つクライアントには、変更されたばかりのドキュメントをソースシステムに直接問い合わせ、その結果をvector searchのヒットとマージするライブリトリーバルレイヤーを追加します。
RAGは、ナレッジベースから取得されたコンテキストでLLMの生成を強化します。クエリ時に、システムはユーザーの質問をembeddingに変換し、ベクトルデータベースで意味的に類似するドキュメントチャンクを検索し、最も関連性の高いチャンクをLLMプロンプトのコンテキストとして含めます。これにより、モデルの応答が実際のドキュメントに基づき、情報源の引用が可能になり、再トレーニングなしでナレッジベースを更新可能に保ちます。プロダクションRAGパイプラインは、取り込み(解析、チャンキング、embedding)、検索(vector search、reranking、hybrid search)、および生成(プロンプト構築、ストリーミング、ガードレール)を処理します。
このアーキテクチャには2つのパイプラインがあります。取り込みパイプラインは、ドキュメントを解析(PDF、DOCX、HTMLからの抽出)、チャンキング(セマンティックまたはオーバーラップ付きの固定サイズ)、embedding(embeddingモデル経由)、およびストレージ(vector database + document store)を通じて処理します。クエリパイプラインは、ユーザーの質問を受け取り、クエリembeddingを生成し、vector databaseから候補チャンクを取得し、関連性についてそれらをrerankし、上位のチャンクをコンテキストとしてプロンプトを構築し、情報源の引用付きでLLM応答をストリーミングします。
text-embedding-3-large、Cohereのembed-v4、またはオープンソースの代替(BGE、E5)のようなモデルを使用します。取り込みにはバッチ処理、検索にはシングルクエリ処理を行います。| レイヤー | テクノロジー |
|---|---|
| ドキュメント解析 | Unstructured, Apache Tika, LlamaParse, Docling, カスタムOCR (Tesseract, AWS Textract) |
| Embedding | OpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2 |
| Vector Database | Milvus, Pinecone, Qdrant, Weaviate, pgvector (小規模向け) |
| キーワード検索 | Elasticsearch, OpenSearch, PostgreSQL full-text search |
| Reranking | Cohere Rerank, BGE Reranker, ColBERT v2, FlashRank |
| LLM | Claude (AI Gateway経由), GPT-4, Gemini — AI SDK経由でプロバイダーに依存しない |
| オーケストレーション | LangChain, LlamaIndex, またはカスタムパイプライン (MWのプロダクション向け推奨) |
| 利用すべきケース | 避けるべきケース |
|---|---|
| ユーザーが組織の特定のドキュメントに基づいた回答を必要とする場合 | ナレッジベースが50ページ未満の場合 — システムプロンプトに直接含める |
| ドキュメントが頻繁に更新され、AIが最新情報を必要とする場合 | モデルに新しいスキル/行動を学習させる必要があり、新しい事実へのアクセスではない場合(代わりにファインチューニング) |
| 情報源の引用と監査可能性が要件となる場合(法律、コンプライアンス、ヘルスケア) | 質問が純粋に会話的であり、事実に基づいた根拠を必要としない場合 |
| 複数のユーザーグループが異なるドキュメントサブセットへのアクセスを必要とする場合(権限フィルター付きRAG) | 事実の正確さが目的ではない、クリエイティブライティングツールを構築している場合 |
MWは、検索品質からRAGパイプラインを構築します — LLMプロンプトに手を加える前に検索精度をベンチマークします。平凡な検索能力と優れたLLMを持つRAGシステムは、自信に満ちた誤った回答を生成します。当社の標準パイプラインには、検索評価ハーネスが含まれています。これは、既知の関連ドキュメントを持つテストクエリのセットであり、MRR@5とNDCG@10で測定されます。チャンキング、embeddingモデル、rerankingを、生成を最適化する前に検索メトリクスが目標しきい値に達するまで繰り返し行います。当社は、法律文書レビュー、ヘルスケアナレッジベース、多言語カスタマーサポートなど、さまざまな分野でRAGシステムを構築してきました。そこで得られた共通の教訓は、回答品質の80%は検索品質に依存しているということです。
1万個のベクトルであれば、埋め込み検索は容易です。しかし、1億個のベクトルで100ミリ秒未満のP99を達成しようとすると、それはインフラストラクチャの問題となり、このパターンがそれを解決します。