mcpField
R
rag-agent-builder

rag-agent-builder

github.com/qodex-ai開発47251 回インストール42 週間前に更新
リポジトリ

rag-agent-builder について

rag-agent-builderは、外部ドキュメントを根拠に回答する検索拡張生成アプリを開発するためのスキルです。ドキュメント処理、ベクトル検索、複数のRAGパターン、検索と回答品質の評価を扱います。

主な機能

  1. 01文書の分割、埋め込み、検索パイプラインを構築
  2. 02ベクトルデータベースで情報源を管理
  3. 03ハイブリッド検索、再ランキング、フィルタリングを実装
  4. 04Agentic RAGとCorrective RAGのパターンを利用
  5. 05検索と回答の品質を評価

活用シーン

  1. 01PDF文書を対象にした質問応答を構築
  2. 02社内文書や企業データを検索
  3. 03特定分野向けの質問応答を作成
  4. 04RAG検索を評価して改善

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/qodex-ai/ai-agent-skills --skill rag-agent-builder

インストール後、Claude Code で/rag-agent-builderを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
examples/
agentic_rag.py
basic_rag.py
retrieval_strategies.py
scripts/
embedding_management.py
rag_evaluation.py
vector_db_manager.py

詳細

RAG エージェントビルダー

外部のナレッジソースで LLM の能力を強化し、正確で文脈に即した AI の応答を可能にする、強力な検索拡張生成(RAG)アプリケーションを構築します。

クイックスタート

サンプルとユーティリティを使って、RAG の実装を始めましょう。

  • サンプル:完全な実装については、examples/ ディレクトリをご覧ください。

    • basic_rag.py - チャンク化、埋め込み、検索、生成を行うシンプルなパイプライン
    • retrieval_strategies.py - ハイブリッド検索、再ランキング、フィルタリング
    • agentic_rag.py - 反復的に改善する、エージェント制御の検索
  • ユーティリティ:ヘルパーモジュールについては、scripts/ ディレクトリをご覧ください。

概要

RAG システムは、次の 3 つの主要なコンポーネントを組み合わせます。

  1. ドキュメント検索 - ナレッジベースから関連情報を見つけます
  2. コンテキスト統合 - 検索したコンテキストを LLM に渡します
  3. 応答生成 - 検索した情報に基づいて回答を生成します

このスキルでは、さまざまなフレームワークやアプローチを使用して、本番環境に対応した RAG アプリケーションを構築する方法を解説します。

基本概念

RAG とは?

RAG は外部データを使って LLM の知識を拡張します。

  • RAG なし:LLM は学習データに依存します(古くなっていたり、限られていたりする場合があります)
  • RAG あり:LLM はリアルタイムの独自の知識と学習データを使用します
RAG を使用する場面
  • ドキュメントへの Q&A:PDF、書籍、レポートに関する質問に回答する
  • ナレッジベース検索:社内ドキュメントやウィキを検索する
  • エンタープライズ検索:企業独自のデータを検索する
  • コンテキスト特化型アシスタント:カスタマーサポート、人事アシスタント
  • 事実が重視されるアプリケーション:法律文書、医療記録、財務データ
RAG が不要な場合
  • 一般知識に関する質問(ChatGPT のようなもの)
  • 絶えず変化するリアルタイムデータ(代わりにツールを使用)
  • 非常に単純な検索タスク(データベースクエリを使用)

アーキテクチャパターン

基本的な RAG パイプライン
Documents → Chunks → Embeddings → Vector DB
                                        ↓
User Question → Embedding → Retrieval → LLM → Answer
                              ↑         ↓
                         Vector DB    Context
高度な RAG パターン
1. エージェント型 RAG
  • エージェントが何をいつ検索するかを判断します
  • クエリを反復的に改善できます
  • 複雑な推論に適しています
2. 階層型 RAG
  • 複数レベルのドキュメント構造
  • 詳細度の異なるレベルで検索します
  • より柔軟に整理できます
3. ハイブリッド検索 RAG
  • キーワード検索(BM25)とセマンティック検索(埋め込み)を組み合わせます
  • 完全一致と意味の両方を捉えます
  • 多様な種類のクエリに適しています
4. Corrective RAG(CRAG)
  • 検索したドキュメントの関連性を評価します
  • 必要に応じて追加のソースを検索します
  • 高品質なコンテキストを確保します

実装コンポーネント

1. ドキュメント処理

チャンク化の方法:

# Simple fixed-size chunks
chunks = split_text(doc, chunk_size=1000, overlap=100)

# Semantic chunks (group by meaning)
chunks = semantic_chunking(doc, max_tokens=512)

# Hierarchical chunks (different levels)
chapters = split_by_heading(doc)
chunks = split_each_chapter(chapters, size=1000)

主な考慮事項:

  • チャンクサイズは検索品質とコストに影響します
  • オーバーラップはチャンク間のコンテキスト維持に役立ちます
  • セマンティックチャンク化は意味をより適切に保持します
2. 埋め込みの生成

主な埋め込みモデル:

  • OpenAI:text-embedding-3-small、text-embedding-3-large
  • オープンソース:all-MiniLM-L6-v2、all-mpnet-base-v2
  • ドメイン特化型:専門知識向けにドメイン固有のデータで学習した埋め込み

ベストプラクティス:

  • 検索とクエリには一貫した埋め込みモデルを使用します
  • 正規化されたベクトルとともに埋め込みを保存します
  • ドキュメントが変更されたら、埋め込みを更新します
3. ベクトルデータベース

人気の選択肢:

  • Pinecone:マネージド型、サーバーレス、簡単にスケール可能
  • Weaviate:オープンソース、セルフホスト可能、柔軟
  • Milvus:オープンソース、高パフォーマンス
  • Chroma:軽量、プロトタイプに最適
  • Qdrant:本番環境向け、高パフォーマンス

選定基準:

  • スケール要件(データ量、1 秒あたりのクエリ数)
  • レイテンシの要件(リアルタイムとバッチ)
  • コストの考慮事項
  • デプロイの選好(マネージド型とセルフホスト可能)
4. 検索戦略

検索方法:

# Similarity search (most common)
results = vector_db.query(question_embedding, k=5)

# Hybrid search (keyword + semantic)
keyword_results = bm25.search(question, k=3)
semantic_results = vector_db.query(embedding, k=3)
results = combine_and_rank(keyword_results, semantic_results)

# Reranking (improve relevance)
retrieved = initial_retrieval(query)
reranked = rerank_by_relevance(retrieved, query)

検索パラメーター:

  • k(結果数):コンテキストと関連性のバランスを取ります
  • 類似度のしきい値:関連性の低い結果を除外します
  • 多様性:最適な一致を返すか、多様な結果を返すか
5. コンテキストの統合

コンテキストウィンドウの管理:

# Fit retrieved documents into context window
def prepare_context(retrieved_docs, max_tokens=3000):
    context = ""
    for doc in retrieved_docs:
        if len(tokenize(context + doc)) <= max_tokens:
            context += doc
        else:
            break
    return context

プロンプト設計:

You are a helpful assistant. Answer the question based on the provided context.

Context:
{retrieved_documents}

Question: {user_question}

Answer:
6. 回答の生成

生成戦略:

  • 直接生成:LLM がコンテキストに基づいて回答します
  • 要約:最初に取得した複数のドキュメントを要約します
  • ファクトグラウンディング:回答に出典を引用させます
  • 反復的な改善:ユーザーからのフィードバックに基づいて改善します

実装パターン

パターン 1:基本的な RAG

最もシンプルな RAG の実装です。

  1. ドキュメントをチャンクに分割します
  2. 各チャンクの埋め込みを生成します
  3. ベクトルデータベースに保存します
  4. クエリに対して類似度の高い上位 k 件のチャンクを取得します
  5. コンテキストとともに LLM に渡します

メリット:シンプルで高速、単純な QA に効果的です
デメリット:関連するコンテキストを見逃す可能性があり、改善処理もありません

パターン 2:エージェント型 RAG

エージェントが検索を制御します。

  1. エージェントがユーザーの質問を受け取ります
  2. ドキュメントを検索するかどうかを判断します
  3. 検索クエリを作成します(元の質問とは異なる場合があります)
  4. 関連するドキュメントを取得します
  5. 反復処理やツールの使用が可能です
  6. 最終的な回答を生成します

メリット:複雑な質問に適しており、反復的に改善できます
デメリット:より複雑で、コストも高くなります

パターン 3:修正型 RAG(CRAG)

取得したドキュメントを検証します。

  1. 質問に対するドキュメントを取得します
  2. 各ドキュメントの関連性を評価します
  3. 関連性が低い場合:
    • 別の検索戦略を試します
    • 検索範囲を広げます
    • 別のソースから取得します
  4. 検証済みのコンテキストから回答を生成します

メリット:回答の質が高く、失敗に応じて適応します
デメリット:API 呼び出しが増え、処理も遅くなります

人気のフレームワーク

LangChain
from langchain.document_loaders import PDFLoader
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Pinecone
from langchain.chains import RetrievalQA

# Load documents
loader = PDFLoader("document.pdf")
docs = loader.load()

# Create RAG chain
embeddings = OpenAIEmbeddings()
vectorstore = Pinecone.from_documents(docs, embeddings)
qa = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(),
    chain_type="stuff",
    retriever=vectorstore.as_retriever()
)

answer = qa.run("What is the document about?")
LlamaIndex
from llama_index import GPTVectorStoreIndex, SimpleDirectoryReader

# Load documents
documents = SimpleDirectoryReader("./data").load_data()

# Create index
index = GPTVectorStoreIndex.from_documents(documents)

# Query
response = index.as_query_engine().query("What is the main topic?")
RAG を使用した CrewAI
from crewai import Agent, Task, Crew
from tools import retrieval_tool

researcher = Agent(
    role="Research Assistant",
    goal="Research topics using knowledge base",
    tools=[retrieval_tool]
)

research_task = Task(
    description="Research the topic: {topic}",
    agent=researcher
)

ベストプラクティス

ドキュメントの準備
  • ✓ テキストをクリーンアップして正規化します(ヘッダー、フッターを削除します)
  • ✓ 可能な限りドキュメントの構造を保持します
  • ✓ メタデータを追加します(ソース、日付、カテゴリ)
  • ✓ スキャンされた PDF には OCR を使用します
  • ✓ ドメインに合わせてチャンクサイズをテストします
埋め込み戦略
  • ✓ インデックス作成とクエリに同じ埋め込みモデルを使用します
  • ✓ ドメイン固有のニーズに合わせて埋め込みをファインチューニングします
  • ✓ 一貫性を保つために埋め込みを正規化します
  • ✓ 埋め込み品質の指標を監視します
検索の最適化
  • ✓ ユースケースに合わせて k(結果数)を調整します
  • ✓ 品質向上のために再ランキングを使用します
  • ✓ 関連性によるフィルタリングを実装します
  • ✓ 検索精度と再現率を監視します
  • ✓ 頻繁に取得されるドキュメントをキャッシュします
生成品質
  • ✓ 回答に出典を含めます
  • ✓ LLM に確信度を示すようプロンプトで指示します
  • ✓ 特定のドキュメントを引用するよう求めます
  • ✓ 長いコンテキストの要約を生成します
  • ✓ コンテキストに照らして回答を検証します
監視と評価
  • ✓ 検索指標(精度、再現率、MRR)を追跡します
  • ✓ 回答の品質と関連性を監視します
  • ✓ 改善に役立てるため、検索に失敗したケースを記録します
  • ✓ ユーザーからのフィードバックを収集します
  • ✓ 失敗に基づいて反復的に改善します

よくある課題と解決策

課題:関連性の低い検索結果

解決策:

  • チャンク分割の戦略を改善します
  • より優れた埋め込みモデルを使用します
  • クエリにドキュメントのメタデータを追加します
  • 再ランキングを実装します
  • ハイブリッド検索を使用します
課題:コンテキストが大きすぎる

解決策:

  • チャンクサイズを小さくします
  • 取得する結果数を減らします(k を小さくします)
  • 取得したコンテキストを要約します
  • 階層型検索を使用します
  • 関連性スコアでフィルタリングします
課題:情報不足

解決策:

  • k を増やす(より多く検索する)
  • 埋め込みモデルを改善する
  • 前処理を改善する
  • 複数の検索戦略を使用する
  • ドキュメントの階層構造を追加する
課題:パフォーマンスの低下

解決策:

  • マネージドベクトルデータベースを使用する
  • 埋め込みをキャッシュする
  • ドキュメントをバッチ処理する
  • チャンクサイズを最適化する
  • 高速化のために、より小型の埋め込みモデルを使用する

評価指標

検索指標:

  • 適合率:検索されたドキュメントのうち、関連性のあるものの割合
  • 再現率:関連性のあるドキュメントのうち、検索されたものの割合
  • MRR(Mean Reciprocal Rank):最初の関連結果の順位
  • NDCG(Normalized DCG):ランキングの品質

回答品質指標:

  • 関連性:回答は質問に答えていますか?
  • 正確性:回答は事実に基づいて正確ですか?
  • 根拠性:回答はコンテキストによって裏付けられていますか?
  • ユーザー満足度:ユーザーは回答を役立つと感じますか?

高度なテクニック

1. クエリ拡張
# Expand query with related terms
expanded_query = query + " " + synonym_expansion(query)
results = retrieve(expanded_query)
2. ドキュメント圧縮
# Compress retrieved docs before passing to LLM
compressed = compress_documents(retrieved_docs, query)
context = format_context(compressed)
3. アクティブ検索
# Iteratively refine retrieval based on LLM output
query = user_question
while iterations < max:
    results = retrieve(query)
    answer = generate_with_context(results)
    if answer_complete(answer):
        break
    query = refine_query(answer)
4. マルチモーダルRAG
# Retrieve both text and images
text_results = text_retriever.query(question)
image_results = image_retriever.query(question)
context = combine_multimodal(text_results, image_results)

リソースと参考資料

主要論文
  • "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"(Lewis et al.)
  • "REALM: Retrieval-Augmented Language Model Pre-Training"(Guu et al.)
フレームワーク
ベクトルデータベース
埋め込みモデル

次のステップ

  1. 技術スタックを選ぶ:フレームワーク(LangChain、LlamaIndexなど)を決めます
  2. ドキュメントを準備する:ナレッジベースを処理し、チャンクに分割します
  3. 埋め込みを選択する:対象分野に適した埋め込みモデルを選びます
  4. ベクトルDBを選ぶ:規模に適したストレージソリューションを選択します
  5. パイプラインを構築する:検索と生成を実装します
  6. 評価する:サンプルの質問でテストし、反復して改善します
  7. モニタリングする:本番環境で品質指標を追跡します

コメント