RAG / 検索拡張

ragflowRAG / 検索拡張

文書をデータセットに取り込むと、どこで区切られたかがチャンク単位で画面に並び、おかしな箇所はその場で書き換えられます。回答には根拠となったチャンクが出典として付き、エージェントを組むキャンバスや取り込み処理を組み替えるパイプラインも同じ製品に含まれます。ただし文字認識・表構造認識・レイアウト解析のモデルが働くのはPDFと画像だけで、Word、Excel、PowerPointは構造をそのまま読む方式のため、公式ドキュメントもDOCXに同じ解析をかけたいならPDFへ変換するよう案内しています。動かすにはElasticsearch、MySQL、MinIO、Redisを含むDocker Compose構成を運用することになり、必要環境は4コア・16GB以上、解析の遅さは公式FAQ自身がLangChainと比べて認めています。すでに整ったテキストしか扱わず、自分のPythonアプリに検索処理を組み込みたいだけなら、LlamaIndexやHaystackのほうが軽く済みます。

Doclingデータ取込

テキスト抽出との違いは構造が残る点です。ページの版面、読み順、表のセル、コードブロック、数式が、平坦な文字列ではなく単一の文書表現の一部として出てきます。報告書の中の表がエージェントに届く時点でも表のままかどうかは、ここで決まります。処理は完全にローカルで実行でき、外部と切り離された環境でも動きます。その忠実さの代償は計算量です。各ページに機械学習モデルを走らせるため、その場で呼ぶ高速な変換器ではなく、見積もっておくべき処理として扱う必要があります。

AnythingLLMRAG / 検索拡張

ワークスペースにファイルを置けば、取り込みから分割、検索までが1つのアプリの中で完結し、ベクトルデータベースや埋め込み用のサービスを別に用意する必要はありません。新しいワークスペースは最初からエージェントモードで動くため、Web検索やSQL問い合わせ、MCPサーバーの呼び出しが同じ画面から使え、ノーコードで組んだエージェントフローも標準機能と同じように呼び出せます。ただし添付した文書は既定で全文がそのままモデルへ渡り、コンテキスト長を超えたところで初めて分割と埋め込みを促される設計なので、扱う文書が増えるほど埋め込み後の検索設定を詰める作業が必要になります。加えてDocker版にはデスクトップ版のような同梱モデルがなく、マルチユーザーに切り替えると単独利用へは戻せないため、どの形態で運用するかを最初に決めておくのが安全です。

LlamaIndexRAG / 検索拡張

多くのフレームワークがエージェントのループから出発するのに対し、これはデータから出発します。取り込み、インデックス戦略、そして回答が実際に根拠を持つかどうかを決める検索パターンを中心に据えています。問題の難所が推論ではなくコーパス側にある場合に選ぶ価値があります。

LibreChatワークフロー

1つのデプロイで、OpenAI・Anthropic・Google・Bedrock・任意のOpenAI互換エンドポイントを単一のログインの向こうに並べられます。エージェントビルダーを使えば、指示文・ツール・ファイル検索・コード実行・MCPサーバーをプログラミングなしで組み合わせ、ユーザー・グループ・ロール単位のアクセス制御付きで共有できます。LDAP・OIDC・SAMLの企業向け認証も揃っています。代償は運用の重さで、標準構成の時点でコンテナが6個動き、コード実行とWeb検索はそれぞれ追加のサービスか外部キーを要します。1人でコンテナ1個なら今もAnythingLLMの方が簡単で、LibreChatは複数ユーザーで運用するための選択肢です。2025年11月にClickHouseが買収し、ライセンスはMITのままだと表明しています。

LightRAGRAG / 検索拡張

索引時にLLMが全チャンクを読み、エンティティと関係を知識グラフへ抽出して、ベクトル埋め込みと並べて保持します。問い合わせは5つのモードから選びます。特定エンティティの事実はlocal、文書をまたぐテーマはglobal、両者の併用がhybridとmix、ただのチャンク検索がnaiveです。付属サーバーはREST APIとグラフ可視化つきのダッシュボードに加え、チャットUIからOllamaのモデルに見えるAPIも提供します。判断の分かれ目はコスト構造で、グラフ構築はチャンクごとにLLM呼び出しを消費し、ローカルで抽出するならおよそ30Bクラスのモデルが下限だとプロジェクト自身が述べています。既定のストレージ構成も本番向けではないと明記されています。安いチャンク検索で足りる用途なら、naiveモードの存在自体が示すとおり、普通のRAGで済みます。

GraphRAGRAG / 検索拡張

通常の検索は質問に似たチャンクを探すため、答えがどのチャンクにも書かれていない問い、たとえば全体の主題や2人の人物の関係といった問いには答えられません。GraphRAGは各文章から実体・関係・主張を抽出し、できたグラフをコミュニティに分割して要約し、その要約から回答します。代償は索引の構築時に支払われます。すべてのテキスト単位に対して、さらにすべてのコミュニティに対してモデルを走らせるため、構築コストは質問の回数ではなくコーパスの規模に比例します。

PageIndexRAG / 検索拡張

ベクトル検索が見つけるのは質問に似た文章ですが、似ていることと関係があることは別です。長い規制文書では、答えにあたる段落が質問とほとんど語彙を共有していないことがよくあります。PageIndexはベクトルの保存先を使いません。文書の実際の構造を節ごとに木として組み立て、人が目次を使うのと同じ手順でモデルにそこをたどらせます。範囲を絞り、答えがありそうな箇所を開き、読む、という流れです。文章を機械的に分割することはなく、答えは必ずどの節から来たかを示します。引き換えは1問あたりの費用です。検索が参照ではなく推論になるためで、想定されているのは短い文書を大量に持つ状況ではなく、長い個別の文書です。

OnyxRAG / 検索拡張

旧Danswerで、企業が個別に組み上げがちな範囲を丸ごと備えています。チャット画面、50を超える情報源からの索引付け、独自の指示と操作を持つエージェント、レポートを返す多段の調査モード、Web検索、コード実行、成果物の生成までが対象で、1コマンドで配備でき、自己ホストでも商用でも任意のモデルプロバイダに向けられます。判断材料は2つです。完全構成は索引・ワーカー・推論サーバー・キャッシュ・オブジェクトストアからなるスタックであること、そしてeeという名前のディレクトリはMITではなく別の商用ライセンスであることです。

Graphitiメモリ / コンテキスト

多くのメモリ層は上書き方式で、新しい事実が古い事実を置き換え、昨年時点の答えは取り出せなくなります。Graphitiは古い関係を「もう成立していない」と日付付きで印を付けるため、現在の真と当時の真の双方に問い合わせられます。さらに、出来事が起きた時点と、システムがそれを知った時点を区別します。遅れて届いた情報が過去を書き換えてしまわないのはこの仕組みによります。検索はベクトル類似度、全文検索、グラフ探索を組み合わせます。費用は具体的です。グラフデータベースを併走させる必要があり、取り込みのたびに実体と関係の抽出でモデルを呼びます。

semantic-kernelフレームワーク

手元のクラスのメソッドにカーネル関数の目印を付け、プラグインとしてまとめてカーネルに登録する——この流れが中心にあり、カーネルにはモデルへの接続も一緒に入るので、OpenAIからAzure OpenAIやOllamaへ移すときに書き換えるのは登録部分だけで済みます。OpenAPIの定義があれば社内の既存APIをそのまま道具にでき、フィルターという仕組みで呼び出しの前後に記録や伏せ字を挟むこともできます。弱点は品質ではなく方向性で、Microsoftは新機能の大半を後継のAgent Frameworkで作ると明言しているため、これから新規に始める案件よりも、すでにこのSDKで書かれた資産を保守し育てていく現場に向いています。

haystackフレームワーク

Haystackは、文書の取り込みから検索、モデルの呼び出しまでを1つずつコンポーネントとして置き、パイプラインの上で出力と入力を名前で指定してつないでいくフレームワークです。型の合わない組み合わせはつないだ瞬間にエラーになり、条件による分岐も、回数の上限つきで前のコンポーネントへ戻すループも、同じパイプラインの中に書けます。Agentもコンポーネントの一つなので、ツール呼び出しの繰り返しをパイプラインへ組み込んだり、別のAgentのツールとして渡したりできます。裏を返せば配線はすべて自分で書くことになり、PDFを置くだけで対話システムができあがる近道はありません。ライブラリなので自分のプロセスの中で動き、パイプラインをHTTPの窓口やMCPサーバーとして公開するには別プロジェクトのHayhooksを使うか、受け口を自分で用意することになります。

pgvectorベクトルDB

ベクトルが列の型になり、そこから先はPostgresがすでにできることがそのまま使えます。近傍検索はORDER BYとLIMIT、絞り込みは同じプランナが評価するWHERE句、埋め込みとその元になる行は1つのトランザクションで書かれ、既存のバックアップ・レプリカ・ロールがベクトルにも適用されます。引き換えに手放すのは、専用エンジンが備える運用機構です。コレクションのシャーディングやテナント分離はここにはなく、索引の構築は同じマシン上で他の処理と資源を奪い合います。

WeaviateベクトルDB

素の索引との違いは3点あります。オブジェクトを属性ごと保存するため絞り込みが検索の一部になり、後段のフィルタではなくなること。ベクトライザーモジュールが書き込み時に埋め込みを生成でき、ずれがちな別パイプラインを持たずに済むこと。そしてマルチテナンシーが正式な構成要素で、テナントごとに専用のシャードを持ち、停止状態やオブジェクトストレージへの退避を選べることです。ただし自分で運用するデータベースではあります。1プロセス内に埋め込む索引が欲しいだけなら、必要以上の機構になります。

Ragas可観測性

検索を使う仕組みで最も多い失敗は、外から見えません。答えは読みやすいのに、引いてきた文書のどこにも根拠がない、という状態です。Ragasはそれを直接測ります。処理を2つに分け、必要な内容を含む文書を引けていたか、生成された答えがその範囲に収まっているかを別々に採点します。手持ちの文書から試験用のデータを作ることもできるため、最初の評価のために質問を100件手書きするところから始めずに済みます。ほとんどの指標自体がモデルの呼び出しである点は、あらかじめ織り込んでおくべきです。一通り走らせれば費用がかかり、同じデータで2回実行しても数値は完全には一致しません。

LangChain4jフレームワーク

看板機能はAI Servicesです。Javaのインターフェースを宣言してアノテーションを付けると、プロンプトの組み立て、モデルの呼び出し、返り値の型へのマッピングまでを実装として提供してくれます。その下には素のChatModel APIがあり、宣言的な層が邪魔になったときはいつでも降りられます。RAG、ツール呼び出し、Spring Boot・Quarkus・Micronaut・Helidonとの統合はいずれも公式提供です。名前は似ていますがPython版の移植ではないため、あちらの資料はそのままは通用しません。