AIナレッジベースからRAGへ
AIアプリケーションを構築する際、「AIがタスク中のデータを見たことがない」という問題に直面します。例えば、企業にとってAIは各顧客の情報を把握できず、個人にとってAIは個人情報やプライバシー情報をあまり理解していません。AIの能力が非常に高くても(理想的な世界モデルも例外ではありません)、具体的なタスクのデータが欠けていると、「具体的な問題を具体的に分析する」能力を失います。
1 RAGとは何か
外部資料を検索することで生成AIモデルの正確性と信頼性を向上させる技術が、検索強化生成技術(Retrieval-Augmented Generation)です。大規模言語モデル(LLM)がタスクを完了する過程を試験に例えるなら、RAGを持つ大規模モデルはオープンブックテストに相当し、RAGのサポートがない場合はクローズドブックテストのようです。RAGはLLMが資料を検索することで、生成効果を向上させる技術です。
RAGはPatrick Lewisらによってこの論文で初めて提案され、彼らが所属する会社がCohereです。この会社は現在、EmbeddingやRerankモデルを含むAPIサービスを提供しており、性能も非常に優れています。
2 なぜRAGが必要なのか
RAGの登場は、大規模言語モデルがアプリケーションで直面するいくつかの問題と不足を解決するためです。最も顕著な点は大規模モデルの幻覚問題であり、これは大規模モデルの出力が事実と一致しないか、答えを捏造することです。また、LLMを訓練するためのデータが古く、LLMが新しい資料を全く知らない可能性があります。
RAGはLLMが最新またはカスタムの資料にアクセスできるようにし、ユーザーがLLMの情報源を検証できるようにして、その正確性を確保します。RAGが検索するデータは公開されているもの(検索エンジンなど)もあれば、非公開のもの(企業資料、個人の機密データなど)もあります。この点がRAGに広い応用の可能性を与えています。RAGはすでに広く使用されており、例えばNVIDIAのNeMo Retrieverは企業内部資料を読み取り、月の暗面のKimi Chatは検索エンジンを利用して回答しています。
黄仁勋がGTC2024で紹介したNeMo Retriever3 RAGを中心に構築されたナレッジベース
AIナレッジベースはAIが「オーダーメイド」できるようにする重要なツールです。ナレッジベースを通じてAIがタスクをより良く完了できるようにするために、現在のAIナレッジベースの構築方法には以下の3つがあります:
- プロンプトエンジニアリング (Prompt Engineering)
- 微調整 (Fine Tuning)
- 埋め込み (Embedding)
プロンプトエンジニアリングは、プロンプト内にナレッジベースを直接構築し、すべての資料をプロンプトに入れる方法です。この方法は小規模での使用に適していますが、現在のAIモデルの入力トークン数ではこの実装方法を満たすことは基本的にできません。実際、AIが発展し、ある日AIの入力ウィンドウが一般的なナレッジベースを収容できるほど十分に大きくなったとしても、ナレッジベースを構築することには依然として価値があります。なぜなら、入力の内容の長さがAIの性能に影響を与えるからです(少なくとも現在のモデルではそうです)。具体的にはNeedle In A Haystack - Pressure Testing LLMsを参照してください。
微調整は学界でよく見られる形式で、特定のタスクデータを使用して事前訓練モデルを微調整します。この方法は実際には業界共通の大規模モデルを作成するのに適しています。例えば、法律業界の大規模モデル、医療大規模モデルなどです。一方で、微調整には多くの訓練データが必要で、コストも高いです。また、微調整はあまり柔軟ではなく、1、2つのドキュメントに基づいて即座に調整することはできません。微調整の過程は実際には訓練データを学習し、一般化することであり、内容を記憶するというよりも、特定の分野の能力を強化することです。
したがって、現在最も主流のナレッジベースの構築方法は、Embeddingの方法を採用しています。そして、この形式のナレッジベースもRAGと組み合わせる必要があります。
4 RAGの基本構成
クラシックで基本的なRAGの構成は以下の図のようになっています。
RAGシステムは主にインデックス、検索、生成の3つの段階を含みます。4.1 Embedding 埋め込み
このプロセスでは、ユーザーは最初にドキュメントをアップロードし、システムはアップロードされたドキュメントをEmbeddingを通じてベクトルデータベースに保存します。Embeddingは、意味が類似したテキストを距離が近いベクトルに変換することであり、このプロセスは俗にベクトル化と呼ばれます。
4.2 Retrieval 検索
ユーザーがLLMに質問すると、質問の内容はEmbeddingを経てベクトルデータベースで一致し、一連の内容が検索されます。これが第一段階の検索です。
4.3 Rerank 再順位付け
ベクトルデータベースで直接検索された内容は完璧ではない可能性があり、結果が検索内容と一致しないことがよくあります。したがって、第二段階の検索、つまりRerankが必要です。この段階では、Rerankモデルが前の段階で検索された内容を再順位付けし、関連性に基づいて結果を出力します。Rerankが完了した後、Top Kを取得して後の生成段階で使用できます。
5 5行コードでRAGを実装
代入文が1行と数える
|
|
RagTokenizer
はテキストのトークン化に使用され、RagTokenForGeneration
はRAGモデルの生成部分であり、RagRetriever
は検索を担当する部分です。RagTokenizer.from_pretrained("facebook/rag-token-nq")
は、事前に訓練されたトークナイザーをロードし、テキストをモデルが理解できる形式(トークン化)に変換します。RagTokenForGeneration.from_pretrained("facebook/rag-token-nq", retriever=retriever)
は、事前訓練されたRAGモデルをロードします。facebook/rag-token-nq
はモデルとトークナイザーの名称で、Natural Questionsデータセットで事前訓練されています。
6 オープンソースのRAG実装
DifyはLLMアプリケーション開発プラットフォームで、すでに10万以上のアプリケーションがDify.AIを基に構築されています。Backend as ServiceとLLMOpsの理念を融合し、生成AIネイティブアプリケーションを構築するために必要なコア技術スタックをカバーしています。内蔵RAGエンジンを含む。Difyを使用すると、任意のモデルに基づいてAssistants APIやGPTsの能力を自動展開できます。このプロジェクトは蘇州の会社によって主催されており、SasSサービスを提供しています。
Langchain-Chatchatは、ChatGLMなどの大規模言語モデルとLangchainなどのアプリケーションフレームワークに基づいて実装された、オープンソースでオフラインデプロイ可能な検索強化生成(RAG)大規模モデルナレッジベースプロジェクトです。最初はChatGLMモデルのみをサポートしていましたが、その後多くのオープンソースモデルやオンラインモデルのサポートが追加されました。
両社の機能比較は以下の表の通りです:
Dify-api | ChatChat | |
---|---|---|
外部機能 | 一般的なドキュメント読み取り | 一般的なドキュメント 画像OCR |
データソース | ドキュメントテキスト内容 ベクトルデータベース |
検索エンジン ベクトルデータベース |
モデルサポート | オンラインembeddingモデル オンラインrerankモデル オンラインLLM |
オンラインembeddingモデル オフラインembeddingモデル オフラインLLM |
高度な機能 | ESハイブリッド検索 | 無 |
高度なRAG | サポートしない | サポートしない |
実際には、現在のオープンソースプロジェクトが完全にカバーしていない機能もいくつかあります。例えば:
- マルチモーダル能力
- 伝統的なリレーショナルデータベースのサポート
- 複数のデータベースの統合/クロスデータベースの資料取得
- 引用機能
- 高度なRAG
- 評価指標