RAGHub を採用する前に読む: リンク集であってライブラリではない

RAGHub が埋めようとしている穴は「選択肢の把握」であって「実装」ではない

RAG のツールは毎月のように新しい名前が出てくる。README の冒頭はその状況を「Each day, it feels like a new tool or framework emerges」と表現し、3か月前のフレームワークがまだ意味を持つのか、それとも古い概念を言い換えただけなのかを判断しにくいと書いている。RAGHub はこの判断を助けるために、フレームワーク、評価と最適化のフレームワーク、エンジン、リソースとサイト、モデルのリーダーボードという複数のカテゴリに分けて項目を並べる。読者はここで候補の名前と公式サイト、GitHub の URL を一度に得る。得られないのは、それぞれのツールが自分のユースケースで動くかどうかである。この切り分けを最初に理解しておくと、後述する限界の多くが納得できる。

リポジトリの実体は Markdown の表であり、インストールする対象がない

RAGHub にはパッケージマネージャから取得するライブラリも、起動するサーバもない。README には RAG Frameworks、RAG Evaluation and Optimization Frameworks、RAG Engines、RAG Resources and Sites、Model LeaderBoards という見出しがあり、その下に Name、Description、Website、Github、Stars、Activity の列を持つ表が置かれている。Stars 列は shields.io のバッジ画像を埋め込む形で、Activity 列には「1h ago」「9h ago」「1d ago」のような相対時間が入る。つまり更新の鮮度は、各プロジェクトのリポジトリの最終更新を表の作成者が手で写している可能性が高い。データが構造化ファイルではなく人手で維持された表である以上、機械的に検証する仕組みは期待できない。

README の FAQ は選定の観点を箇条書きで与えるが、判断は読者に返される

FAQ には「How do I choose the right RAG framework?」という問いがあり、Use Case、Scale、Complexity、Integration、Language の5つの要因が表で示される。Complexity の行では LangChain と LlamaIndex を full-featured、LightRAG を simple と対比し、Language の行では Python 系と TypeScript、Rust を分けている。ここで示されるのは比較の軸であって、軸ごとのスコアではない。同じ FAQ は Frameworks と Engines の違いも説明している。Frameworks はコードに組み込むライブラリ、Engines は RAGFlow や Dify のようにすぐ使える単体プラットフォームだと定義される。この区別は実際の導入判断で効いてくる。自前のパイプラインを書きたいのか、既成の画面で済ませたいのかで、見るべき表が変わるからだ。

入手方法は git clone と Pull Request であって pip install ではない

RAGHub を使い始める手順は、リポジトリを clone して README を読むことになる。コントリビューションの手順は README と CONTRIBUTING.md に書かれている。フォークし、該当セクションにエントリを追加し、既存の表の書式に合わせ、Pull Request を出すという流れである。設定キーや環境変数は存在しない。評価ツールの節に挙がっている ragas、Trulens、Phoenix、Deepchecks は別々のプロジェクトであり、それぞれに固有のセットアップが必要になる。RAGHub はそれらの導線を並べるだけで、インストール手順は各リポジトリに委ねる。ベクトルデータベースについても ChromaDB、Qdrant、Pinecone、Weaviate が用途つきで列挙されるが、接続設定の例は載っていない。

鮮度を保証する仕組みがないため、表の記述は現在形で信じてはいけない

最大の限界はここにある。表の Activity 列は相対時間で、README のクリーニング済みテキストからは取得時点が分からない。Stars 列はバッジ画像であり、記事執筆時点の数値を本文が持っているわけではない。Description 列の文言も、各プロジェクトの自己申告を短くしたものだ。たとえば Semantica の行は「Open-source framework for Context Graphs, GraphRAG, Decision Intelligence, Explainable Reasoning, Provenance, and AI Governance」と並べ立てているが、これが実際にどの程度実装されているかを RAGHub は検証していない。Dcup の行も「Connect your app to user data in minutes」と書くだけで、その主張の裏付けは示さない。ディレクトリとして正直なのは、裏付けを示さないこと自体を隠していない点である。

Awesome リストとの違いは分類の粒度と FAQ の有無にある

同じ領域の代替として、GitHub 上の awesome 系リストが挙げられる。典型的な awesome リストはタグや見出しで項目を並べるだけだが、RAGHub は Frameworks と Engines を分け、評価ツールを独立した節にし、モデルのリーダーボードやリソースサイトまで含める。さらに FAQ で選定の観点と、RAG のよくある課題と対処の対応表を提供する。たとえば「Context window limits」に対しては reranking で取得内容を減らす、「Latency」に対しては取得インデックスの最適化とストリーミングという形で、課題と対処が1行ずつ並ぶ。ただしこれは一般的な対処の列挙であり、特定のライブラリの API 名や設定値ではない。分類の粒度で優位に立つが、深さでは各プロジェクトの公式ドキュメントに劣るという関係になる。

ローカルモデルとライセンスの扱いから見える想定読者

FAQ には「Can I use RAG with local/self-hosted models?」という問いがあり、Ollama、vLLM、LM Studio、LocalAI が方法として並ぶ。つまりクラウド API を前提にしない構成も視野に入れている。ライセンスについては、RAGHub 自身が MIT であることが README の License 節に示されている。ただしディレクトリに掲載された各プロジェクトのライセンスはそれぞれ別であり、RAGHub の MIT はそれらに及ばない。ここは誤解しやすい点で、RAGHub が MIT だからといって、表に載っているツールを同じ条件で使えるわけではない。各エントリの GitHub リンクを開いて、そのリポジトリのライセンスファイルを確認する作業は省略できない。

維持コストは表の更新頻度に依存し、それは誰も保証していない

RAGHub を参照し続けるコストは、表が更新され続けるかどうかにかかっている。コントリビューションは誰にでも開かれており、フォークしてエントリを追加し Pull Request を出す手順が用意されている。これは裏返せば、更新が特定のメンテナの作業量に依存しない代わりに、更新の頻度も約束されないということだ。リポジトリはアーカイブされておらず、最終 push は 2026-07-28 と記録されている。リリースは取得できていないため、バージョン番号で内容の変化を追うことはできない。参照する側は、README の表を読むたびに、気になる行の GitHub リンクを開いて実際の最終コミット日時を確認する運用になる。手間はかかるが、表の Activity 列をそのまま信じるより確実である。

編集部の結論

RAGHub は、RAG の構成要素をこれから選び始める人、あるいは社内で候補リストを作る立場の人が、LangChain、LlamaIndex、Haystack、ragas、Trulens、RAGFlow、Dify といった名前をまとめて眺めるための入口として使うのが正しい。逆に、特定のベンチマーク結果やバージョン互換性、実際の導入事例を根拠に技術選定を確定したい人には向かない。README の表は Star バッジと Activity 列しか持たないため、採用前に必ず各プロジェクトのリポジトリで直近のリリースと依存関係の更新状況を自分で確認すること。RAGHub 自体は MIT ライセンスの文書リポジトリなので、ここから得られるのは候補の一覧であって、動作の保証ではない。

公式情報源

1. Andrew-Jang/RAGHub on GitHub
2. Issues
3. License: MIT
4. README