【要約】RAG ってそもそも何なのか — indexもchunkもretrieveも知らない人のための、ゼロから順番に積み上げるRAG入門 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
LLMを実務で利用する開発者は、モデルの知識限界に直面する。具体的には、以下の問題が発生する。
- ・ハルシネーションによる、もっともらしい嘘の生成。
- ・学習データに含まれない最新情報の欠如。
- ・社内文書などの非公開情報の参照不能。
- ・回答の根拠（出典）を示せない不透明性。
// Approach
開発者は、外部知識を検索して生成に組み込むRAGを採用する。RAGは以下の2つのフェーズで構成される。
1.準備フェーズ（Indexing）
- ・文書をテキスト化し、扱いやすい塊（Chunk）に分割する。
- ・文章を数値（Vector）に変換し、Vector DBに保存する。
2.使うフェーズ（Retrieval & Generation）
- ・質問に関連するChunkをVector DBから取り出す。
- ・取り出した情報をプロンプトに組み込み、LLMに回答させる。
// Result
RAGの導入により、LLMの回答精度と信頼性が向上する。特に以下の効果が期待できる。
- ・最新情報や特定ドメインの知識への対応。
- ・回答根拠の明示による、情報のトレーサビリティ確保。
- ・Long Context利用時と比較した、コストとレイテンシの最適化。
- ・用途に応じた、RAGとLong Contextの使い分け（ルーティング）の実現。
Senior Engineer Insight
> 実務では「Hybrid Search + Reranker」が標準構成となる。単なるベクトル検索では固有名詞に弱いため、キーワード検索との併用が不可欠だ。また、LangChain等のフレームワークは、過度な抽象化がデバッグを困難にする。API直叩きを基本とし、フレームワークは部品として薄く使う設計が、長期的な運用コストと保守性を高める。Long Contextの進化に伴い、単なる検索ではなく、クエリに応じた「ルーティング」の設計が重要になる。