この動画では、企業の80%が採用している400億ドル規模のAI技術「RAG（検索拡張生成）」について包括的に解説している。RAGは大規模言語モデルの知識の古さ、ハルシネーション、企業データへのアクセス不能といった根本的問題を解決する技術である。基本的な仕組みから企業レベルの実装まで、成功事例と失敗例の両方を交えながら、データ処理、チャンキング戦略、ベクターデータベース、メモリ管理などの技術的詳細を詳述している。また、RAGを使うべきでない場面についても警告を発し、将来の発展方向性についても考察している。
RAGが解決する根本的な問題
もしChatGPTが完璧な記憶力を持ち、決してハルシネーションを起こさなかったらどうでしょうか。これがRAGが業界に約束している400億ドルの価値なのです。RAGとは検索拡張生成のことです。
この動画では、RAGに関する現在の議論、ベストプラクティス、企業での実装方法、いくつかの成功事例、そして見逃してはならないRAGを使うべきでない場面について、ワンストップで解説いたします。実際に、RAGに過剰投資して深く後悔している企業もあるからです。
それでは詳しく見ていきましょう。根本的な問題は、LLMが優秀だが不完全だということです。これまでもお話ししてきましたが、致命的な欠陥があります。知識のカットオフ日があるため、知識が時間的に凍結されています。ハルシネーションや確信に満ちた嘘をつきます。そして明らかに企業のデータにアクセスできません。これは多くの場合、企業は気にしていないことですが。
RAGの解決策とその価値
解決策のプレビューとして、基本的にRAGと大規模言語モデルを組み合わせることで、AIにリアルタイム研究アシスタントの機能を与えることができます。
学習内容は、RAGシステムの構築方法、プロトタイプから数百万クエリの真のスケールまでの拡張方法、そして多くのRAGプロジェクトを破綻させる落とし穴の回避方法です。これは私がRAGについて行った実際の深い調査と多くの研究に基づいた、非常に包括的な内容です。ブックマークして、チャンクに分けて視聴することをお勧めします。
まず、なぜRAGがすべてを変えるのかについてお話しし、その後実際の仕組みについて説明します。
RAGは現在約20億ドルの市場ですが、あまりにも急速に拡大しているため測定が困難です。2035年までに400億ドル以上に達する軌道にあります。
非常に多くの企業がRAGを使用しています。概算では約80%です。そして彼らはファインチューニングよりもRAGを使用しています。なぜなら、より簡単だと認識しているからです。モデルのファインチューニングは、少なくとも現時点では、より困難だと認識されています。AIに取り組んでいる人々の73%が、リアルタイムデータアクセスが必要だと言っています。
ちなみに、これらの統計をどこから引用しているのか疑問に思われるかもしれませんが、私のSubstackにリンクのリストがあり、これらの背景にある実際のストーリーをすべて追跡できます。
成功事例の例として、LinkedInはRAGによってサポートチケットの解決時間を大幅に短縮しました。RAGによって自社のビジネスを理解できるようになったからです。これは、LLMがクローズドブック試験ではなくオープンブック試験を受けているようなものです。この話は公開されています。
RAGの仕組み
それでは、どのように機能するのでしょうか。魔法の正体は何でしょうか。
検索は、関連情報を知識ベースから探すことです。拡張は、クエリと取得した事実を組み合わせることです。生成は、LLMが実際のデータに基づいて回答を作成することです。
RAGは実際にどのように動作するのでしょうか。
第一に、エンベディングです。テキストは高次元空間で数値として埋め込まれます。例えば、「返金ポリシー」という語句は、一連の数値やベクトルとして埋め込まれるかもしれません。重要な洞察は、類似した意味は数学的にクラスター化されるということです。
大規模言語モデルがどのように動作するかについて私の以前の動画をご覧になったことがあれば、まったく同じことです。単語を取って、高次元ベクトル空間で数値としてエンコードしています。
次元数について知りたい場合、現在のベストプラクティスの一つは1,536次元です。これは非常に多くの次元です。
チャンキング戦略の重要性
次元があれば十分でしょうか。テキストを生のまま送るだけでよいのでしょうか。答えは「いいえ」です。
チャンキングが必要です。チャンキングとは、システムに与える大きなテキストブロックを、LLMが関係性と意味的意味を理解するのに役立つ方法で分割することを意味します。悪いチャンキングは多くのRAGプロジェクトを台無しにします。注意してください。
ここには4つの異なる戦略があります。固定サイズチャンクは危険な場合があり、文の途中で切れる可能性があります。文ベースのチャンクは境界を尊重します。セマンティックチャンクはトピック別にグループ化します。再帰的チャンクは階層構造でグループ化します。
重要なのは、ビジネスの観点から何を得たいかを理解し、それに基づいてチャンキング戦略を決定することです。
チャンク間の重複を計画する必要があります。ゼロゼロカットオフは避けたいものです。なぜなら、元のチャンクで遭遇したかもしれない類似チャンクでLLMが何かを見つける機会がなくなるからです。基本的に、少し重複させることで、非常に複雑な干し草の山でAIが必要なものを見つける可能性を最大化できます。
ベクトル空間での意味検索
ベクトル空間で物事を見る際、キーワードマッチングを行っているわけではありません。これはよくある誤解です。人々は「LLMはキーワードマッチを探している」と言いますが、そうではありません。意味をマッチングしようとしているのです。
実際にはコサイン類似度と呼ばれるものを探し、ベクトル空間で最近傍を見つけています。
例として、「お金を取り戻すにはどうすればよいですか」というクエリを顧客が入力したとします。これは、返金処理0.95類似度、返品ポリシー0.93類似度を見つけ、配送情報0.38類似度は取得されません。これは適合しません。
検索の処理方法について考える場合、実際のクエリが返ってくる方法に基づいて再ランキングでき、ビジネス目的で精度を大幅に向上させることができます。これは高度な技術ですが、この状況で、アイテムを返送する必要があるかもしれないため、「お金を取り戻すにはどうすればよいですか」で配送情報を取得したい場合、再ランキングを行って、いわゆるポストプロダクションでそれに到達できます。
RAGシステムの構築
RAGをどのように構築するかですが、非常にシンプルに、Llama Indexを使うことをお勧めします。Llamaがコマンドラインから提供する方法でドキュメントをロードし、インデックスを作成してクエリを実行します。これのスタックを取得するのは簡単です。高価ではありません。難しくありません。シンプルです。
RAGは迅速です。LangChainも使えます。これはスイスアーミーナイフで、すべてを行います。Llama Indexも使えます。これは特にRAG用に最適化されています。
他のベクターDB、Pine Cone、Chroma、Qdrantも、すべて機能します。マニュアルやハンドブックの保証期間のような簡単なものが欲しい場合、「EU購入で2年」のような正しい回答を非常に素早く得ることができます。2025年においては、シンプルなRAGを構築するのは難しくありません。
RAGのレベル別実装
課題は、ほとんどの人がシンプルなRAGだけを望んでいないことです。
レベル1の基本的なQ&Aが欲しい場合、企業でも1週間程度で完了できます。シンプルなベクトル検索、単一ソース、数秒のレイテンシ、内部FAQのみ、超高速です。基本的には少し高級なカスタムGPTです。
レベル2は、キーワードマッチと意味マッチの両方を組み合わせるハイブリッド検索です。これは少し複雑になります。確実により良い精度が得られます。キーワードを直接処理するため、場合によってはより高速になります。エッジケースの処理に役立ちます。ただし、実装はもっと複雑です。
しかし、そこからさらに複雑になります。
レベル3では、テキスト、画像、動画、音声を検索したいとします。マルチモーダルRAGです。かなり正確にできます。迅速にもできます。しかし、データ側とチャンキング側で大量の作業をする必要があります。テキストでチャンキングが複雑だと思いますか。テキスト、画像、動画、音声のチャンキング戦略を考え出そうとするまで待ってください。
一例として、Vimeoのタイムスタンプ付き動画検索があります。これは興味深いものです。
レベル4はエージェンシックRAGです。これは、エージェントが実際に入って多段階推論を行い、見つけたものを自己改善する場所です。待ち時間は長くなります。より正確な応答を得ることができます。完全なRAGを構築するだけでなく、その上にエージェントを構築する必要があります。
そして最後に、エンタープライズプロダクションが欲しい場合、多くのセキュリティ、多くのコンプライアンス、多くの監視があります。このものがどれだけ速く応答する必要があるか、複数のクエリがあるときにどのように負荷を処理するかについてのパフォーマンス期待値があり、100万、1000万、1億台のボックスに何かを置くために必要な追加のソフトウェアエンジニアリング作業がすべてあります。これは消えません。これは依然として複雑です。
AIが100万台、1000万台、1億台のボックスに住むソフトウェアを魔法のように簡単に配置することはありません。
データ処理の詳細
データについてかなり話しましたが、データが良いRAGシステムの鍵であるため、もう少し深掘りしましょう。
RAG用のドキュメントを見る際に、より遠くまで行くのに役立つ信頼できるツールチップとして心に留めておくべきことがいくつかあります。
第一に、PDFには terrible header and footer pollution（ひどいヘッダーとフッターの汚染）がよくあります。PDFをコピー＆ペーストしたことがありますか。システムはそのように見ており、それらの小さなフッターを読んで混乱し、奇妙なヘッダーを読んで混乱します。
スキャンドキュメントのOCRについて、光学文字認識は正しいと確信していますか。これが、Mistralがドキュメントスキャン専用の特別なOCRツールをリリースした理由です。デジタルの良いクリーンなテキストがなければ、良いRAGを得るのは困難です。
テーブルは特別な処理が必要になります。空間関係をエンコードする必要があるからです。チャンキングについて考える前に、ドキュメントのクリーンな定型文にたどり着く必要があります。PDFをチャンクしようとしてはいけません。まずクリーンな定型文にたどり着いてください。まずクリーンなマークダウンにたどり着いてください。
メタデータは、精度の処理方法として劇的に影響力のある選択になる可能性があります。各チャンクにソース、セクション、日付を追加すると、検索は大幅に改善されます。例えば、「ポリシー更新 3月20日」とあれば、システムはそれが2024年の更新であることを知ります。2025年の更新を見つけた場合、最新性ベースの検索を探していることを理解していれば、おそらく2025年の更新を選択するでしょう。
データ処理の10ステップ
これはどのように見えるでしょうか。10ステップです。適切なパーサーでテキストに変換し、セクションに分割し、ひどいヘッダーとフッターのような定型文を削除し、すべての空白を正規化し、セクションタイトルを抽出し、メタデータを追加し、重複でチャンクし、チャンクを埋め込み、サンプルを検証し、反復します。
これだけの作業量があります。そして、これは率直に言って、かなりシンプルな練習のためです。これが私がRAGは複雑になる可能性があると言う理由です。
高度なRAG技術
さらに高度になりましょう。これはそのような動画の一つだからです。グラフRAGについて話しましょう。
従来のRAGは単なる孤立したテキストチャンクです。グラフRAGはエンティティ関係を保存してRAGでエンコードします。LinkedInは、グラフRAGからの知識グラフで検索が大幅に改善されたことを確認しました。
興味深い別のハイブリッドアプローチは検索深掘りです。ベクトル空間を見るだけでなく、例えばエラーコードも見るハイブリッド検索で、正確なマッチやエラーコードをキャッチできますか。
最良のドキュメントは、多くの場合、異なる検索で異なる位置にランクされ、それは私たちのハイブリッド検索アプローチでこれらの異なる検索方法全体で最も高い検索回答が何であるかを探している順位選択投票のようなものです。それが1番になるかもしれません。
私たちが探しているエラーコードは、キーワード検索で非常に高くランクされ、意味検索ではそれほど高くランクされないかもしれませんが、チャンキング時に正しいメタデータを使用したため、まだそこにあります。すべてが洗い流されて1番として統合され、精度が向上します。
マルチモーダルでは、特に画像、テーブル、テキスト間の関係をどのように処理するかについて思慮深くありたいものです。請求書はこの良い例です。テーブルがよくあります。確実にテキストがあります。画像もあるかもしれません。
画像埋め込みにはCLIPのようなツールを使いたいものです。すべてのモダリティにわたって統合インデックスが欲しいものです。テキスト、画像、テーブルの統合インデックスです。正しく行えば、「Q3の収益テーブルを見せて」というクエリを送信できるはずです。インデックスが両方のモダリティで共通であるため、画像とデータの両方を取得するはずです。
MCP（Model Context Protocol）
ここでMCPについて言及します。MCPは、AI用のUSBポートのように機能するため役立ちます。AI データ接続を可能にするユニバーサルプロトコルであり、システムが他の方法ではアクセスできないデータにプラグインしてアクセスできるようにするのに非常に役立ちます。
内部企業データ用のRAGを持つ良いシステムは、MCPを使用して他のデータソースへの検索も比較的簡単に拡張できます。
メモリ管理
メモリ管理に取り掛かりましょう。メモリについて考える場合、私たちがここに至った理由の一部はメモリと、なぜメモリがAIにとって問題なのかということです。メモリを正しく取得する必要があります。
コンテキストウィンドウは作業メモリです。すべてのAIが出荷する際に付属しています。多くの場合、10万、20万、40万、おそらく100万トークンです。
ベクトルストアは長期メモリです。埋め込みについて話しました。長期メモリは、事実上無制限で、圧縮され要約されます。
これらすべてがどのように関連するかを考える場合、会話の古い用語を圧縮してメモリで要約できる立場にいることができます。会話自体でRAGを使用して以前の会話を取得できます。複数の抽象化レベルを持つことができます。
良い例の一つは、重要な事実を忘れないように、以前の長期間の会話の十分な部分をエンコードできることを確認することです。
例として、フライドポテトを注文しているとしましょう。フライドポテトの注文についてAIボットと話しています。2025年です。それは起こり得ます。DoorDashかもしれません。あなたが作業している注文にフライドポテトが十分にないと言及し、エクストラフライドポテトが欲しいと2番目のチャットで送信し、その後20回や30回のチャットの後、DoorDashと素晴らしい会話をしているからといって、私たち全員がそうしているように、フライドポテトがあることを忘れてしまうとしたらどうなるでしょうか。
以前の会話を忘れるあの内臓的な瞬間は、ほぼ全員がAIで経験したことがあり、RAGシステムではそれを経験する必要がありません。RAGシステムは効果的に高度なメモリマネージャーとして使用でき、コンテキストウィンドウが移動するにつれてメモリが消失するという感覚を減らすことができるからです。
企業がコンテキストウィンドウを長時間開いておくために行う多くの高級な作業は、基本的にこの高級なメモリ管理に要約されます。これが、OpenAIが実際にはより大きなコンテキストウィンドウを持っていないにも関わらず、より大きなコンテキストウィンドウを持っているように感じる理由の一つです。
彼らは正確に何をしているかを明かしませんが、基本的に会話をより長く流し続けるためにメモリ管理で高級な作業を行っています。一方、Claudeはかなりハードなメモリキャップがあり、少なくとも現在は、このような技術で会話を長く続けていません。そのため、Claudeでメモリ不足に非常に早く遭遇するでしょう。
興味深いことに、人々はそれがClaude has shorter context windows and shorter memoryを意味すると思っています。しかし、それは真実ではありません。OpenAIは、より高級なメモリ管理であなたを騙しているのです。
評価とテスト
評価とテストに取り掛かりましょう。呼び出したい4つのことがあります。
関連性：正しいチャンクを取得していますか。 忠実性：回答は実際のソースに基づいていますか。 品質：人間はそれを正しいと評価するでしょうか。 レイテンシ：これは十分に高速ですか。そのバーを設定する必要がありますが、多くの場合、数秒以下のようなものです。
この RAG のゴールドスタンダードと考える評価セット、質問セットを構築することから始める必要があります。エッジケース、困難なものを含めてください。簡単にしないでください。検索と生成の両方を測定したいものです。それを取得できるか、それをうまく書けるかです。
RAGシステムの改善をABテストしたいものです。ハイブリッド検索に移行する場合は、真剣に取り組んでください。例として、Notionは移行時にRAGシステムをABテストし、時間の経過とともに検索の改善された価値を証明でき、失敗を分析し、データと問題を修正できました。これは別の公開されている話です。
RAGが失敗する場面
RAGをどのように実行するかの例をいくつか示しました。RAGがどのように失敗するかについて話しましょう。
チャンキングが失敗し、文の途中でコンテキストが破綻することについて話しました。大きなチャンクでLLMが情報を見逃し、メモリで物事が失われることについて話しました。RAGを悪く設定すると、LMが情報を取得できないため、実際に途中で迷子になる可能性があります。RAGを悪く実装すると、実際にメモリ問題を悪化させる方法です。
ハルシネーションホラーストーリーがあります。コンテキストが利用可能であるにもかかわらず、RAGが事実を作り上げることがあります。これは、ラベルが不適切なコンテキストで発生する可能性があります。さまざまな理由で発生する可能性があります。
第4に、率直に言って、不正確なベクターDB設定があります。非常に高価になる可能性があります。
第5に、その中に古いデータや悪いデータがある可能性があります。更新パイプラインがなく、データが古くなって無用になります。
第6に、セキュリティリーク、PII露出、コンプライアンス失敗です。楽しくありません。
第7に、埋め込みのミスマッチです。インデックスとクエリで異なるモデルを使用すると、完全なでたらめにつながる可能性があります。
予防戦略
予想されるように、予防戦略はここで多くの意味を成します。
常にチャンクを重複させてください。本番のようなデータでテストしてください。「わからない」応答があることを許可してください。これはハルシネーションに本当に役立ちます。
オープンソースまたは安価なオプションから始めてください。これにより、間違ったベクターデータベースを持つことを防げます。コンクリートを流す前に、確認するだけです。
1日目に更新パイプラインを構築してください。後で構築しないでください。アーキテクチャでセキュリティレビューを開始前に行ってください。埋め込みバージョンを追跡して、インデックスとクエリ間で異なる埋め込みバージョンがあなたを台無しにしないようにしてください。
エンタープライズスケールでの課題
特に1000万クエリのようなエンタープライズおよびスケールシステムのような非常に大きなシステムで発生する課題に取り掛かりましょう。
ベクターDBをシャードして複製する必要があります。人気のあるクエリをキャッシュする必要があります。モデルをカスケードする方法を理解する必要があります。プロンプトを拡張してから、そこから別のモデルにプロンプトを処理させたい場合があります。
コスト最適化は、これらのものを実行するのが非常に高価であるため、数百万ドルを節約します。これが、モデルを削り、使用できる絶対的に最小のモデルは何か、クエリに応じてシステムで異なるモデルをどのようにトレードオフするかを理解する場所です。
他に類を見ないようなセキュリティ深掘りを行うことになります。アクセス制御フィルタリング、PII除去、監査証跡、コンプライアンス、HIPAA、GDPR、SOC 2など、頭字語を追加してください。多くあります。数ヶ月かかることを計画してください。しかし、それは価値があります。
別の例として、RBC銀行があります。彼らはサポートエージェント用のRAGを構築しました。これも公開されている話です。ポリシーをインデックス化し、過去のチケットをインデックス化し、より迅速な解決、より良い一貫性を実現し、最初に内部で展開してから顧客に展開しました。スケールでRAGを行うことは可能です。
RAG vs エージェンシック検索
この長いRAGの紹介の終わりに向かって、RAGとエージェンシック検索を少し見てみましょう。お付き合いいただきありがとうございます。
RAGとエージェンシック検索は大きな質問です。根本的に、RAGは単一の検索回答モダリティですが、エージェントは多段階で思考と計画を行い、より正確になる可能性がありますが、はるかに遅く高価です。
ドキュメンテーションのシンプルなQ&AにはRAGを使いたいものです。複雑な推論、マルチソースなどにはRAGとエージェントを使いたいものです。
RAGを使うべきでない場面
RAGについてのすべての動画であっても、RAGをいつ使わないかを言わないのは怠慢でしょう。RAG実装を後悔している企業を知っています。
RAGを使用したのは企業データではなく、LLMが他の方法では取得できないものではありませんでした。使用したのは本質的にLLMを一時的により賢くする方法でした。
非常に高価な50万ドル、100万ドルの実装の後に発見したのは、「あら、RAGを実装したが、次の汎用モデルは十分に賢く、関係なかった。十分に大きなコンテキストウィンドウがあり、関係なかった。まだRAGが必要だ。ただし、インテリジェントである必要がある。賢くある必要がある。データの処理方法、データのチャンク方法、なぜ使用するか、どのように設定するかについて、ここで概説したベストプラクティスに従う必要がある。」ということでした。
RAGを避けるべき場面
そのような間違いを避けるためにできることの例をいくつか示します。
第一に、ベースモデルがそれを知っているか、ほぼ知っているかをチェックしてください。それについてはすでに言及しました。
第二に、これは個人的なRAGシステム向けですが、ストーリーや詩や創作の場合、RAGは一般的にうまく機能しません。意味的意味が同じように機能しないからです。
第三に、ゲームシステムのように超超高速である必要がある場合、RAGを使わないでください。決してうまくいきません。データを取得する必要があり、時間がかかるからです。
株式ティッカーのような非常に変動性の高いデータがある場合、RAGを使わないでください。決してうまくいきません。
高いメンテナンスコストがあり、本当に明確な利益がない場合、小さなデータセットのような場合、RAGを使わないでください。
基本的な計算、基本的なフォーマッティングのような比較的シンプルな変換の場合、やることがあまりない場合、RAGを使わないでください。価値がありません。
プライバシーが重要な場合、ユーザーデータを保存できないことを確認する必要があります。保存した場合、トラブルになります。
RAGの未来
未来を見て何が起こるかを考える場合、壁にいくつかの明確な文字があると思います。
一つ、モデルはよりエージェンシックで賢くなっていくでしょう。これは、RAGがますますエージェンシック検索RAG、ますますエージェンシック検索プラスMCP RAGになることを意味し、メモリ側で積極的な進歩を遂げることになります。これにより、「メモリが解決されるのであれば、なぜRAGを使用しているのか」と私に尋ねることになります。
私の答えは、RAGは、少しの安定性、広範囲の良いトピック拡散を持ち、現在の会話を豊かにする方法でそのデータに対して実際にクエリできるデータと話す方法です。
実際には、会社の wiki 全体で魔法の1000万トークン作業メモリを入力したくないでしょう。回答が汚くなるだけだからです。欲しいのは、あなたのクエリに関連するより大きなデータセットの正確な画像を提供するため、時々検索拡張生成です。
RAGは、メモリが改善されてもその場所を持つでしょうが、賢く使用した場合のみです。
100万以上のコンテキストウィンドウがより多くのコンテキストウィンドウを期待し、典型的になるでしょう。モデルコンテキストプロトコルとMCPの急速な普及を期待してください。企業がRAGを自分たちのデータとAIモデルの世界を橋渡しする方法として使い始めるにつれて、巨大な市場成長を期待してください。モデルファインチューニングとRAGの間のはるかに洗練された関係を期待してください。
2025年にRAGが本当に一般的であるように、2026年にファインチューニングがはるかに民主化されることを期待しています。
まとめ
私たちは多くのことを歩いてきました。RAGの設定方法、RAGの落とし穴、RAGの動作方法、データの動作方法、チャンキングの動作方法を歩いてきました。これで終わりにしたいと思います。
RAGは、AIの最大の問題のいくつかを解決する方法です。ハルシネーション、古い知識、メモリの欠如です。数行のコードのようにシンプルに開始できます。15行のコードではありませんが、エンタープライズスケールまでスケールアップします。
これが非常に多くの企業やビジネスがRAGについて考え、RAGに向かって移動している理由です。うまく実装されれば、現実的な問題を解決します。ツールは今日存在します。この動画でそれらのいくつかを言及しました。
かなり広いRAG問題空間に適合する問題がある場合、開始しない言い訳はありません。私たちのほとんどは、ハルシネーション、古い知識、メモリの問題に遭遇しています。
しかし、やるつもりなら、小さなユースケースを選んでください。まずはプロトタイプを構築してください。コンクリートを流さないでください。影響を測定し、評価してください。評価して、学習し反復してください。
勝利する企業は、魔法的な最大のモデルを持つ企業ではありません。サイズは関係ありません。モデルの賢さは魔法ではありません。AIを統合して企業データと知識に取り込み、おそらくRAGで、最終的にAIがワークフローを前進させる能力です。
それが、あなたの状況でRAGについて考えることをお勧めすることです。あなたにとってRAG形の問題は何ですか。そして批判的に、RAGを使用することを避けたい問題は何ですか。この動画をここまで見てくれたなら、私がRAGがすべての解決策だと言おうとしていないことを知っています。
次回誰かがRAGについて話すときに驚かないように、それが何であるかを理解してもらいたいだけです。乾杯。このRAGの紹介を楽しんでいただけたことを願っています。
コメント