高度なRAG:LongRAG、Self-RAG、GraphRAGを解説
LongRAG、Self-RAG、GraphRAG - 次世代の技術
検索拡張生成(RAG) は、単純なベクター類似度検索を大きく超えた進化を遂げています。 LongRAG、Self-RAG、GraphRAGは、これらの機能の最先端を代表しています。
モダンなRAGシステム は、大規模なドキュメントの処理、複雑なエンティティ関係の理解など、多くの課題を処理する必要があり、さらに多くの能力を要求されます。
この美しい画像は、AIモデル Flux 1 dev によって生成されたものです。
基本的なRAGを超えた進化
従来のRAGシステムは、ドキュメントをチャンクに分割し、それらをベクターに埋め込み、コサイン類似度によって類似チャンクを検索し、それをLLMに渡すというシンプルなパターンに従います。多くのユースケースで効果的ですが、このアプローチは以下の3つの重要なシナリオでは苦戦します:
検索、ディープサーチ、ディープリサーチの違いを理解することは、なぜ複雑な情報検索タスクには高度なRAG変体が必須なのかを明確にするのに役立ちます。これらの概念をより深く理解するには、検索 vs ディープサーチ vs ディープリサーチ をご覧ください。
- 長距離依存性: 重要なコンテキストは、複数のチャンクにまたがる何千ものトークンにわたって展開される場合があります
- 検索信頼度: システムは、検索された内容が実際に関連しているかどうかを評価する手段を持っていません
- 関係性の複雑さ: ベクトル類似度では、エンティティ間の繊細なつながりを捉えることはできません
高度なRAG変体は、特定の課題に合わせて調整された専門的なアーキテクチャにより、これらの制限に対処します。
LongRAG: 拡張コンテキストの克服
アーキテクチャ概要
LongRAGは、拡張コンテキストウィンドウ(32K、100K、または1Mトークンなど)を持つLLMを活用することで、チャンク分割戦略を根本から見直します。ドキュメントを512トークンの小さなチャンクに分割する代わりに、LongRAGは階層的なアプローチを使用します:
ドキュメントレベルの埋め込み: 全体のドキュメント(または非常に大きなセクション)を単一のユニットとして処理します。ドキュメントレベルの埋め込みは全体の意味論的な意味を捉えつつ、下流の処理のために完全なテキストを保持します。
最小限のフラグメンテーション: チャンク分割が必要な場合、LongRAGはより大きなチャンク(4K-8Kトークン)と大幅なオーバーラップ(20-30%)を使用します。これにより、ナラティブのフローが保たれ、コンテキストの断片化が減少します。
コンテキストアセンブリ: 検索時、LongRAGは散在するフラグメントではなく、完全なドキュメントまたは大きな一貫したセクションを返します。LLMは、構造的および意味論的な関係を保持する連続的なコンテキストを受けます。
実装戦略
以下は、Pythonと最新の埋め込みモデルを使用して概念的な実装を示します:
from typing import List, Dict
import numpy as np
class LongRAGRetriever:
def __init__(self, model, chunk_size=8000, overlap=1600):
self.model = model
self.chunk_size = chunk_size
self.overlap = overlap
self.doc_embeddings = []
self.documents = []
def create_long_chunks(self, text: str) -> List[str]:
"""Create overlapping large chunks"""
chunks = []
start = 0
while start < len(text):
end = start + self.chunk_size
chunk = text[start:end]
chunks.append(chunk)
start += (self.chunk_size - self.overlap)
return chunks
def index_document(self, doc: str, metadata: Dict):
"""Index document with hierarchical embedding"""
# Embed entire document
doc_embedding = self.model.embed(doc)
# Create large chunks with overlap
chunks = self.create_long_chunks(doc)
chunk_embeddings = [self.model.embed(c) for c in chunks]
self.doc_embeddings.append({
'doc_id': len(self.documents),
'doc_embedding': doc_embedding,
'chunk_embeddings': chunk_embeddings,
'chunks': chunks,
'full_text': doc,
'metadata': metadata
})
self.documents.append(doc)
def retrieve(self, query: str, top_k: int = 3) -> List[Dict]:
"""Retrieve relevant long-form content"""
query_embedding = self.model.embed(query)
# Score at document level first
doc_scores = [
np.dot(query_embedding, doc['doc_embedding'])
for doc in self.doc_embeddings
]
# Get top documents
top_doc_indices = np.argsort(doc_scores)[-top_k:][::-1]
results = []
for idx in top_doc_indices:
doc_data = self.doc_embeddings[idx]
# For each document, find best chunks
chunk_scores = [
np.dot(query_embedding, emb)
for emb in doc_data['chunk_embeddings']
]
best_chunk_idx = np.argmax(chunk_scores)
# Return extended context around best chunk
context_chunks = self._get_extended_context(
doc_data['chunks'],
best_chunk_idx
)
results.append({
'text': ''.join(context_chunks),
'score': doc_scores[idx],
'metadata': doc_data['metadata']
})
return results
def _get_extended_context(self, chunks: List[str],
center_idx: int) -> List[str]:
"""Get extended context around relevant chunk"""
start = max(0, center_idx - 1)
end = min(len(chunks), center_idx + 2)
return chunks[start:end]
ユースケースとパフォーマンス
LongRAGは、コンテキストが重要なシナリオで卓越しています:
- 法的ドキュメント解析: 契約書や法的論述書では、数十ページにわたる依存関係を持つことがよくあります
- 研究論文の検索: メソドロジーを理解するには、孤立した段落ではなく一貫したセクションが必要です
- コードリポジトリ: 関数やクラスは、そのモジュールのコンテキストの中で理解される必要があります
パフォーマンス特性:
- レイテンシ: 大きなチャンクの処理が必要なため、高くなります(標準RAGの2-5倍遅い)
- 精度: 長文QAベンチマークで15-25%向上
- メモリ: コンテキストウィンドウのために3-4倍のメモリが必要です
Self-RAG: 反省型検索
核心原則
Self-RAGは、RAGシステムにメタ認知的な層を導入します。盲目的に検索し生成するのではなく、システムは特別なリフレクショントークンを通じて、自身のプロセスに能動的に反省します。この自己反省的であり、反復検索を行うという考え方は、セルフホスト型のDeep Researchシステムにおいてアプリケーションレベルで再登場します — Local Deep Researchやlukeswade/deep-researchのようなツールが、どのようにして自身のエビデンスのギャップを評価し、次に何を検索するかを決定するかについては、セルフホスト型 Deep Research システム: 12ツールの比較 をご覧ください:
Retrieve Token: 与えられたクエリに対して検索が必要かどうかを決定します Relevance Token: 検索されたドキュメントが実際に関連しているかを評価します Support Token: 生成された答えが検索された内容によって支持されているかを確認します Critique Token: 生成されたレスポンス全体の質を評価します
アーキテクチャ構成要素
Self-RAGのアーキテクチャは、3つの交互に行われるフェーズで構成されています:
class SelfRAGSystem:
def __init__(self, retriever, generator, critic):
self.retriever = retriever
self.generator = generator
self.critic = critic
def generate_with_reflection(self, query: str,
max_iterations: int = 3):
"""Generate answer with self-reflection"""
# Phase 1: Decide if retrieval needed
retrieve_decision = self.critic.should_retrieve(query)
if not retrieve_decision:
# Direct generation without retrieval
return self.generator.generate(query)
# Phase 2: Retrieve and evaluate relevance
retrieved_docs = self.retriever.retrieve(query)
relevant_docs = []
for doc in retrieved_docs:
relevance_score = self.critic.assess_relevance(
query, doc
)
if relevance_score > 0.7: # Threshold
relevant_docs.append(doc)
if not relevant_docs:
# Fallback to generation without retrieval
return self.generator.generate(query)
# Phase 3: Generate and verify support
best_answer = None
best_score = -1
for _ in range(max_iterations):
# Generate candidate answer
answer = self.generator.generate(
query, context=relevant_docs
)
# Evaluate support and quality
support_score = self.critic.check_support(
answer, relevant_docs
)
quality_score = self.critic.assess_quality(answer)
total_score = 0.6 * support_score + 0.4 * quality_score
if total_score > best_score:
best_score = total_score
best_answer = answer
# Early stopping if high quality achieved
if total_score > 0.9:
break
return {
'answer': best_answer,
'confidence': best_score,
'sources': relevant_docs,
'reflections': {
'retrieved': retrieve_decision,
'relevance': len(relevant_docs),
'support': support_score
}
}
リフレクションメカニズムのトレーニング
Self-RAGでは、クリティッカーコンポーネントが信頼できる評価を行うようトレーニングする必要があります。これには通常、以下のことが含まれます:
- 教師ありファインチューニング: 関連性の判断でアノテーションされたデータセットでの学習
- 強化学習: 正確な予測に対する報酬を用いた学習
- 対比学習: 支持されている主張と支持されていない主張の区別を行うための学習
リフレクショントークンは、以下のように実装できます:
- 語彙内の特別なトークン(例:
[RETRIEVE],[RELEVANT]) - モデル上の独立したクラッシーファイヤーヘッド
- 外部クリティッカーモデル(アンサンブルアプローチ)
本番環境での検討事項
本番システムにSelf-RAGを展開する際:
レイテンシのトレードオフ: 各リフレクションステップは、推論オーバーヘッドを20-40%追加します。徹底性とレスポンスタイムの要求とのバランスを調整してください。
信頼度のしきい値: ユースケースに基づいてリフレクションのしきい値を調整します。法的または医療アプリケーションは、一般的なチャットボットよりも高い信頼性を必要とします。
監視: リフレクションの決定を追跡してパターンを特定します。検索がほとんど必要ない場合、よりシンプルなアーキテクチャがメリットをもたらす可能性があります。
GraphRAG: 知識グラフ增强型検索
概念的基礎
GraphRAGは、検索問題をベクトル類似度からグラフのトラバースに変換します。意味的に類似したテキストチャンクを見つけるのではなく、GraphRAGは関連する接続されたエンティティと関係のサブグラフを特定します。
エンティティ抽出: 固有のエンティティ、概念、それらのタイプを特定します 関係マッピング: エンティティ間の関係(時間的、因果的、階層的)を抽出します グラフ構築: エンティティをノード、関係をエッジとする知識グラフを構築します サブグラフ検索: クエリに基づき、関連する接続されたサブグラフを見つけます
グラフ構築パイプライン
非構造化テキストから知識グラフを構築するには、いくつかの段階が必要です:
class GraphRAGBuilder:
def __init__(self, entity_extractor, relation_extractor):
self.entity_extractor = entity_extractor
self.relation_extractor = relation_extractor
self.graph = NetworkGraph()
def build_graph(self, documents: List[str]):
"""Build knowledge graph from documents"""
for doc in documents:
# Extract entities
entities = self.entity_extractor.extract(doc)
# Add entities as nodes
for entity in entities:
self.graph.add_node(
entity['text'],
entity_type=entity['type'],
context=entity['surrounding_text']
)
# Extract relationships
relations = self.relation_extractor.extract(
doc, entities
)
# Add relationships as edges
for rel in relations:
self.graph.add_edge(
rel['source'],
rel['target'],
relation_type=rel['type'],
confidence=rel['score'],
evidence=rel['text_span']
)
def enrich_graph(self):
"""Add derived relationships and metadata"""
# Compute node importance (PageRank, etc.)
self.graph.compute_centrality()
# Identify communities/clusters
self.graph.detect_communities()
# Add temporal ordering if timestamps available
self.graph.add_temporal_edges()
グラフを用いたクエリ処理
GraphRAGのクエリは、知識グラフをまたぐマルチホップ推論を含みます:
class GraphRAGRetriever:
def __init__(self, graph, embedder):
self.graph = graph
self.embedder = embedder
def retrieve_subgraph(self, query: str,
max_hops: int = 2,
max_nodes: int = 50):
"""Retrieve relevant subgraph for query"""
# Identify seed entities in query
query_entities = self.entity_extractor.extract(query)
# Find matching nodes in graph
seed_nodes = []
for entity in query_entities:
matches = self.graph.find_similar_nodes(
entity['text'],
similarity_threshold=0.85
)
seed_nodes.extend(matches)
# Expand subgraph via traversal
subgraph = self.graph.create_subgraph()
visited = set()
for seed in seed_nodes:
self._expand_from_node(
seed,
subgraph,
visited,
current_hop=0,
max_hops=max_hops
)
# Rank nodes by relevance
ranked_nodes = self._rank_subgraph_nodes(
subgraph, query
)
# Extract and format context
context = self._format_graph_context(
ranked_nodes[:max_nodes],
subgraph
)
return context
def _expand_from_node(self, node, subgraph, visited,
current_hop, max_hops):
"""Recursively expand subgraph"""
if current_hop >= max_hops or node in visited:
return
visited.add(node)
subgraph.add_node(node)
# Get neighbors
neighbors = self.graph.get_neighbors(node)
for neighbor, edge_data in neighbors:
# Add edge to subgraph
subgraph.add_edge(node, neighbor, edge_data)
# Recursively expand
self._expand_from_node(
neighbor,
subgraph,
visited,
current_hop + 1,
max_hops
)
def _format_graph_context(self, nodes, subgraph):
"""Convert subgraph to textual context"""
context_parts = []
for node in nodes:
# Add node context
context_parts.append(f"Entity: {node.text}")
context_parts.append(f"Type: {node.entity_type}")
# Add relationship information
edges = subgraph.get_edges(node)
for edge in edges:
context_parts.append(
f"- {edge.relation_type} -> {edge.target.text}"
)
return "\n".join(context_parts)
MicrosoftのGraphRAG実装
MicrosoftのGraphRAGは、コミュニティ要約を生成する独自のアプローチを取っています:
- LLMベースのエンティティ/関係抽出を使用してドキュメントから初期グラフを構築
- Leidenアルゴリズムまたは同様のアルゴリズムを使用してコミュニティを検出
- LLMを使用して各コミュニティの要約を生成
- 階層構造: コミュニティ抽象化の複数のレベルを構築
- クエリ時: 関連するコミュニティを検索し、特定のエンティティにトラバース
このアプローチは、特に以下の場合に効果的です:
- 探索的なクエリ(「このコーパスの主要なテーマは何ですか?」)
- マルチホップ推論(「AはBを介してCとどのように接続されていますか?」)
- 時間的分析(「このエンティティの関係はどのように進化しましたか?」)
比較分析
各変体の使用タイミング
LongRAGを使用する場合:
- ドキュメントが強い内部的な一貫性を持っている場合
- LLMのコンテキストウィンドウが大きな入力をサポートしている場合(32K+)
- クエリの答えに長距離依存性の理解が必要な場合
- 構造化されたドキュメント(報告書、論文、書籍)で作業している場合
Self-RAGを使用する場合:
- 精度と信頼性が重要な場合
- 説明可能な検索決定が必要である場合
- 無関係な検索からの偽陽性がコスト高的である場合
- クエリの複雑さが大きく変動する場合(一部のクエリは検索が必要、他のクエリは不要)
GraphRAGを使用する場合:
- ドメインに豊富なエンティティ関係がある場合
- クエリにマルチホップ推論が関与する場合
- 時間的または階層的な関係が重要な場合
- エンティティ間のつながりを理解する必要がある場合
パフォーマンス指標の比較
| 指標 | 標準RAG | LongRAG | Self-RAG | GraphRAG |
|---|---|---|---|---|
| インデクシング時間 | 1x | 0.8x | 1.1x | 3-5x |
| クエリレイテンシ | 1x | 2-3x | 1.4x | 1.5-2x |
| メモリ使用量 | 1x | 3-4x | 1.2x | 2-3x |
| 精度 (QA) | ベースライン | +15-25% | +20-30% | +25-40%* |
| 解釈可能性 | 低 | 中 | 高 | 高 |
*GraphRAGの向上幅はドメインに強く依存します
ハイブリッドアプローチ
最も強力な本番システムは、多くの場合、複数の技術を組み合わせています:
LongRAG + GraphRAG: グラフ構造を使用して関連するドキュメントクラスタを特定し、フラグメントではなく完全なドキュメントを検索します
Self-RAG + GraphRAG: グラフトラバースの決定(どのパスを進むべきか、いつ拡張を止めるべきか)にリフレクションメカニズムを適用します
3段階パイプライン: 初期のエンティティベースの検索にはGraphRAG → 関連性フィルタリングにはSelf-RAG → コンテキストアセンブリにはLongRAGを使用
実装上の考慮事項
埋め込みモデル
異なるRAG変体には、異なる埋め込み要件があります:
LongRAG: ドキュメントレベルとチャンクレベルの両方で良く機能する埋め込みが必要です。長文列での対比学習で訓練されたモデルを検討してください。
Self-RAG: 細粒度の関連性評価のために意味的なニュアンスを捉える埋め込みが有益です。
GraphRAG: エンティティ認識型埋め込みが必要です。エンティティリンクリングタスクでファインチューニングされたモデルの方がパフォーマンスが良いです。
埋め込みモデルの選択は、パフォーマンスに大きく影響します。ローカルモデルで作業する場合、Ollamaのようなツールを使用すると、本番環境へのデプロイメントにコミットする前に、異なる埋め込みモデルの実験を素直に行うことができます。
チャンク分割戦略の再考
従来の固定サイズチャンク分割では、高度なRAGには十分ではありません:
意味論的チャンク分割: 自然な境界(段落、セクション、トピックの転換)で分割 再帰的チャンク分割: 親子関係を持つ階層的なチャンクを作成 スライディングウィンドウ: 境界でコンテキストを保持するためにオーバーラップするチャンクを使用 構造認識型: ドキュメント構造(Markdownヘッダー、XMLタグ、コードブロック)を尊重
Pythonベースの実装では、LangChainやLlamaIndexのようなライブラリが、これらのチャンク分割戦略 のための組み込みサポートを提供します。
リランキング統合
リランキングは、すべてのRAG変体で検索の品質を劇的に向上させます。初期の検索後、専門的なリランキングモデルがクエリ-ドキュメント相互作用の特徴に基づいて結果を再スコアリングします。これは、慎重に統合される限り、最小限のレイテンシ影響で大幅な精度向上(10-20%)をもたらします。
本番環境へのスケーリング
インデクシングパイプライン:
- 大規模なドキュメントコーパスには分散処理(Ray, Dask)を使用
- リアルタイム更新のために増分インデクシングを実装
- 埋め込みを最適化されたベクトルデータベース(Pinecone, Weaviate, Qdrant)に保存
クエリ最適化:
- 頻繁なクエリとその結果をキャッシュ
- クエールーティングを実装(異なるクエリタイプに対して異なるRAG変体を使用)
- サブ線形スケーリングのために近似最隣接点検索を使用
監視:
- 検索関連性スコアを追跡
- Self-RAGでのリフレクション決定を監視
- グラフトラバースのパスと深さを測定
- 信頼度スコアとユーザーフィードバックをログに記録
リアルワールドでの応用
技術ドキュメント検索
ある大手クラウドプロバイダーが、そのドキュメントのためにGraphRAGを実装しました:
- エンティティ: APIエンドポイント、パラメータ、エラーコード、サービス名
- 関係: 依存関係、バージョン互換性、移行パス
- 結果: サポートチケット35%減、解決時間45%高速化
法的ディスカバリ
あるリーガルテック企業が、Self-RAGとLongRAGを組み合わせて使用しました:
- Self-RAGが無関係なドキュメントを早期にフィルタリング
- LongRAGが保持されたドキュメント内でコンテキストを保持
- 弁護士による偽陽性のレビューが60%減少
- 重要なコンテキストの保持が71%から94%に向上
研究文献レビュー
ハイブリッドアプローチを使用する学術検索エンジン:
- GraphRAGが引用ネットワークと研究コミュニティを特定
- LongRAGがメソドロジーのコンテキストを維持しながら完全なセクションを検索
- 関連論文の発見が40%向上
- 文献レビューにかかる時間が数週間から数日に短縮
高度なトピック
マルチモーダルRAG
画像、テーブル、コードを処理するためにこれらの変体を拡張すること:
- ビジュアルグラウンディング: テキストエンティティをドキュメント内の画像にリンク
- テーブル理解: 構造化データをグラフ形式に解析
- コード解析: コードベースから依存関係グラフを構築
アダプティブRAG
クエリの特性に基づくRAG戦略の動的選択:
- クエリ複雑度クラッシーファイヤー
- ドキュメントタイプ検出器
- 戦略選択のためのコストベネフィット最適化器
プライバシー保護RAG
プライバシー制約付きでこれらの変体を実装すること:
- データサイロ間の連合検索
- 埋め込みにおける微分プライバシー
- 暗号化された類似度検索
入門
Pythonによるクイックスタート
これらの技術を実装したい方のために、堅固なPythonの基礎から始めることが不可欠です。機械学習のためのPythonの豊富なエコシステムは、RAG開発にとって自然な選択です。
実験のためのシンプルな出発点です:
# Install dependencies
# pip install sentence-transformers faiss-cpu langchain
from sentence_transformers import SentenceTransformer
import faiss
import numpy as np
# Basic setup for experimenting with long chunks
model = SentenceTransformer('all-MiniLM-L6-v2')
documents = [
# Your long-form documents here
]
# Create embeddings
embeddings = model.encode(documents)
# Build FAISS index
dimension = embeddings.shape[1]
index = faiss.IndexFlatL2(dimension)
index.add(embeddings.astype('float32'))
# Query
query = "Your question here"
query_embedding = model.encode([query])
distances, indices = index.search(
query_embedding.astype('float32'), k=3
)
フレームワークの選択
LangChain: 迅速なプロトタイピング、幅広い統合に最適 LlamaIndex: ドキュメントインデクシングと検索に最適化 Haystack: 本番環境対応、強力なパイプライン抽象化 カスタム: 完全なコントロールと最適化が必要な場合
評価フレームワーク
本番環境へのデプロイメント前に、厳密な評価を実装します:
検索指標:
- Precision@K, Recall@K, MRR (平均相互逆ランク)
- NDCG (正規化割引累積利得)
生成指標:
- テキスト類似度のための ROUGE, BLEU
- 意味類似度のための BERTScore
- 品質評価のための人間による評価
エンドツーエンド指標:
- タスク成功率
- ユーザー満足度スコア
- レイテンシパーセンタイル (p50, p95, p99)
結論
RAGシステムの景色は、基本的なベクトル類似度検索を大きく超えて成熟しました。LongRAG、Self-RAG、GraphRAGはそれぞれ、従来のアプローチの特定の制限に対処しています:
LongRAG は、拡張コンテキストウィンドウと最小限のチャンク分割 を採用することにより、コンテキストの断片化問題を解決します。ドキュメントの一貫性が重要であり、大きなコンテキストを処理するための計算リソースがある場合の定番の選択です。
Self-RAG は、検索システムに不可欠な自己認識を追加します。自身の決定に反省することで、偽陽性を減らし、信頼性を高めます。これは、速度よりも精度が重要なハイリスクアプリケーションに不可欠です。
GraphRAG は、構造化知識表現の力を解放します。あなたのドメインがエンティティ間の複雑な関係を包含する場合、グラフベースの検索は、ベクトル類似度が完全に取りこぼしてしまうつながりを表面化させることができます。検索前に知識をどのように構造化するかというより深い問い — そしてなぜ表現が検索と同じくらい重要か — は、知識システムにおける検索 vs 表現 で探索されています。
RAGの未来は、これらの変体の強みを組み合わせるハイブリッドアプローチを伴う可能性が高いです。本番システムでは、関連するエンティティクラスタの識別にGraphRAGを、検索のフィルタリングと検証にSelf-RAGを、LLMのための一貫したコンテキストのアセンブリにLongRAGを使用するかもしれません。
LLMが継続的に改善され、コンテキストウィンドウが拡大するにつれて、さらに洗練されたRAG変体の登場を見ることになるでしょう。鍵は、特定のユースケースの要件 — ドキュメント構造、クエリパターン、精度の要求、計算制約 — を理解し、適切な技術またはその組み合わせを選択することです。
ツールエコシステムは急速に成熟しており、LangChain、LlamaIndex、Haystackのようなフレームワークは、これらの高度なパターンに対してますます洗練されたサポートを提供しています。強力なローカルLLMランタイムと埋め込みモデルと組み合わせることで、プロダクショングレードのRAGシステムの実験とデプロイはかつてなく容易になっています。
基本から始めて、パフォーマンスを厳密に測定し、要件が示すようにアーキテクチャを進化させてください。ここでカバーした高度なRAG変体は、その進化のためのロードマップを提供します。
便利なリンク
- 埋め込みモデルによるリランキング
- LLMと構造化出力: Ollama, Qwen3 & PythonまたはGo
- クラウドLLMプロバイダー
- LLM比較: Qwen3:30b vs GPT-OSS:20b
- ステップバイステップのRAGチュートリアル
- RAGにおけるチャンク分割の比較
- RAGのためのベクトルデータベース比較
外部参考文献
- Microsoft GraphRAG: A Modular Graph-Based Retrieval-Augmented Generation System
- Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
- LongRAG: Enhancing Retrieval-Augmented Generation with Long-context LLMs
- Retrieval-Augmented Generation for Large Language Models: A Survey
- FAISS: A Library for Efficient Similarity Search
- LangChain Documentation: Advanced RAG Techniques
- HuggingFace: Sentence Transformers for Embedding Models
- RAG Survey: A Comprehensive Analysis of Retrieval Augmented Generation