RAGは検索拡張生成(Retrieval-Augmented Generation)の略で、中国語では一般的に検索拡張生成(Retrieval-Augmented Generation)と呼ばれます。 その核心は、モデルがすべての情報を記憶することではなく、まず外部の知識ベースで関連するコンテンツを検索してから回答し、その後大きなモデルがその情報に基づいて回答を生成することです。
どんな問題を解決するのでしょうか?
通常の大規模モデルは、研修で得た知識と現在の入力のみに依存しており、会社の方針、製品文書、契約条件、最新の資料に遭遇する際にミスをしやすいです。 RAGは「情報の発見」と「回答の書き方」を分離します。検索システムは関連する文書断片を見つける役割を担い、モデルはそれらを整理し、説明し、表現します。
RAGの基本的なプロセス
- 文書をより小さなセグメントに分割し、タイトル、出典、権限などのメタデータを保持します。
- Embeddingモデルを使って質問や文書の断片をベクトルに変換します。
- ベクターデータベースや検索エンジンを使って、最も関連性の高いセグメントを見つけましょう。
- クリップをプロンプトに挿入し、モデルに証拠に基づいて答えさせます。
- 必要に応じて、元のサイトに戻って手動で検証してください。
RAGは幻覚がないという意味ではありません
RAGは幻覚を減らすだけで、自動的に完全には消し去るものではありません。 検索が不完全だったり、スライスが不十分だったり、権限フィルタリングの誤りがあったり、クリップが古くなっていたり、プロンプトの要件が不明瞭だったりすると、回答がトピックから外れてしまいます。 多くのナレッジベースのQ&A失敗は、モデルの不備が原因ではなく、検索やドキュメントガバナンスが十分に行われていないことが原因です。
どのような状況に適していますか?
RAGはエンタープライズナレッジベース、カスタマーサービスのQ&A、ポリシー検索、紙の資料整理、製品マニュアルアシスタントに適しています。 モデルを無から作成したり、複雑な数学的推論が必要だったり、信頼できるデータソースが欠けている場合には適していません。 プロジェクトがRAGを使うべきかどうかを判断するには、こう問うかもしれません:答えは追跡可能な外部データの一括から来なければならないのか? もしそうなら、RAGの方が単純なプロンプトよりも安定していることが多いです。
