RAGLite: DuckDB か PostgreSQL で組む検索拡張生成の実装キット
🥤 RAGLite is a Python toolkit for Retrieval-Augmented Generation (RAG) with DuckDB or PostgreSQL
ひと目でわかる
- これは何？
- RAGLite は、キーワード検索とベクトル検索を DuckDB または PostgreSQL のネイティブ機能に任せ、チャンク化と検索の制御だけを Python 側に残した RAG ツールキットである。README から読み取れる設計と、採用前に確認すべき境界を整理する。
- 誰に向いている？
- 自前の文書集合を持ち、検索バックエンドを DuckDB か PostgreSQL のどちらかに固定できるチームには候補になる。逆に、既に LangChain や PyTorch 前提のパイプラインを運用していて、そこへ差し込む部品が欲しいだけなら、依存を意図的に避ける設計方針が噛み合わない。
- 商用利用できる？
- 条件付きでできます。MPL-2.0 は弱いコピーレフトのライセンスで、商用やクローズドソースのソフトウェアにも組み込めますが、このソフトウェア自体のファイルを改変して配布する場合は、その変更を同じライセンスで公開する必要があります。
- 今もメンテナンスされている？
- されています。最後のコミットは 30 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
RAGLite が引き受ける範囲と、引き受けない範囲
RAG の実装で厄介なのは、モデルを呼ぶ部分ではなく、文書をどう切って、どう検索して、その結果をどうプロンプトに詰めるかである。RAGLite はこのうち、文書の Markdown 変換、文分割、チャンク埋め込み、ハイブリッド検索、リランキング、そしてプロンプトの組み立てまでを担う。対象読者は、社内文書や技術文書を検索対象にした質問応答を、外部のマネージド RAG サービスに預けずに自前で組みたい開発者である。
一方で、RAGLite はオーケストレーションフレームワークではない。README の Features には、PyTorch や LangChain のような重量級依存を避けると明記されており、これは機能の網羅性より依存の軽さを優先するという宣言でもある。エージェントの分岐、ツール呼び出しのループ、複数ステップのワークフローを組みたいなら、RAGLite は土台ではなく一工程として使うことになる。
検索はデータベース側に寄せる: FTS と VSS の使い分け
RAGLite の構成で最も特徴的なのは、キーワード検索とベクトル検索の両方をデータベースのネイティブ機能に任せる点である。DuckDB を選ぶ場合は FTS 拡張と VSS 拡張、PostgreSQL を選ぶ場合は tsvector と pgvector を使う。アプリケーション側で転置インデックスや近似最近傍探索を実装しないため、検索の実体は SQL に落ちる。
両者を統合する方式として README は Hybrid search を挙げ、参照先に RRF（Reciprocal Rank Fusion）の論文を示している。つまり順位を融合して最終的な候補を作る。ここで実務上の差が出る。DuckDB は単一ファイルで完結するため、開発機や単発のバッチ処理では扱いやすい。PostgreSQL は同時接続と運用実績の面で勝るが、pgvector のインデックス設計とメモリ設定は別途調整が要る。README はどちらを使うべきかの判断基準までは示していない。
late chunking と文分割がチャンク品質に効く理由
チャンクの切り方で検索精度が決まる、というのは RAG ではよく言われる話だが、RAGLite はここに 2 つの具体策を入れている。ひとつは late chunking で、文書全体を先に埋め込んでからチャンク単位にプールする。もうひとつは contextual chunk headings で、チャンクに見出し情報を付けて文脈の欠落を補う。
文分割も独自で、wtpsplit-lite を使い、文の区切りを二分整数計画問題として解く。semantic chunking も同じく整数計画問題として解くと README は説明する。ここは評価が分かれるところだ。最適化問題として解く以上、文書の取り込み時に計算コストがかかる。大量の文書を一度に流し込む場面では、この処理が律速になる可能性がある。README には所要時間の記載がないため、実際の負荷は対象文書の規模に依存するとしか言えない。
インストールと設定: extras の選び方
基本の導入は pip install raglite の 1 行である。追加機能は extras で分かれており、ChatGPT 風のフロントエンドが要るなら raglite[chainlit]、PDF 以外のファイル形式を扱うなら raglite[pandoc]、検索と生成の評価を行うなら raglite[ragas] を指定する。Mistral OCR による高品質な文書処理を使う場合は mistralai を別途インストールする。
ローカルモデルを動かす場合、README は accelerated llama-cpp-python precompiled binary の導入を推奨している。環境変数 LLAMA_CPP_PYTHON_VERSION、PYTHON_VERSION、ACCELERATOR、PLATFORM を設定し、GitHub Releases の wheel を pip install で直接指定する形だ。README 自身が not every combination is available と注記しているとおり、この 4 つの組み合わせがすべて揃うわけではない。ACCELERATOR は metal、cu121 から cu124 まで、PLATFORM は macosx_11_0_arm64、linux_x86_64、win_amd64 が例示されている。
設定は RAGLiteConfig に渡す。README の例では remote 構成として PostgreSQL と LiteLLM 経由のモデルを指定する形が示されている。llama.cpp のモデルを使う場合は llama-cpp-python/<hugging_face_repo_id>/<filename>@<n_ctx> という形式の識別子を使い、n_ctx は省略可能なコンテキスト長の指定である。
適応的検索とプロンプト構造という地味な工夫
README が挙げる機能のうち、実運用で効いてくるのは adaptive retrieval である。LLM 自身が、そのクエリに対して検索すべきか、何を検索すべきかを判断する。挨拶や雑談のような入力で無駄な検索を走らせない、という発想だ。ただしこれは追加の LLM 呼び出しを意味する。レイテンシとコストのどちらを取るかは、クエリの性質次第で変わる。
もうひとつが prompt caching-aware なメッセージ配列構造で、これはコストとレイテンシの改善を狙うものだと README は説明する。加えて Anthropic の long-context prompt format を採用し、出力品質の向上を図るとしている。どちらも効果の数値は README には示されていない。プロバイダ側のキャッシュ仕様に依存する部分であり、使うモデルによって恩恵の度合いは変わる。
query adapter も見逃せない。src/raglite/_query_adapter.py に実装があり、直交プロクルステス問題を解くことで閉形式の線形写像を求める。クエリの埋め込みを検索対象の空間に合わせる補正であり、モデルを差し替えたときの精度落ちを埋める用途が想定される。
MCP サーバーと Chainlit フロントエンドの位置づけ
RAGLite には Model Context Protocol サーバーが同梱されており、Claude desktop のような MCP クライアントから接続できる。自前で API を立てずに、既存のデスクトップクライアントへ検索機能を生やせるという意味では実用的である。
フロントエンドが必要なら Chainlit を使う。README は web、Slack、Teams へのデプロイ先を挙げている。ただしこれらはすべて optional と明記されており、コアの RAG 機能はこれらなしで動く。逆に言えば、Chainlit を入れると依存が増え、軽量という売り文句からは離れる。フロントエンドを自前で作るのか、Chainlit に乗るのかは早い段階で決めたほうがよい。
向かないケースと、比較対象としての LlamaIndex
RAGLite が向かないのは、既存のパイプラインに検索だけ足したい場合である。PyTorch を避ける設計は、すでに PyTorch ベースの埋め込みモデルを自前で運用しているチームにとっては制約になる。また、PDF 以外の形式が中心で Pandoc の変換品質に依存するなら、extras を入れた上で変換結果を確認する必要がある。
比較対象として LlamaIndex を挙げる。LlamaIndex はデータコネクタ、インデックス種別、クエリエンジン、エージェントを一つの抽象の下に揃えており、対応するデータソースと検索戦略の数で RAGLite を大きく上回る。アプローチの違いは明確で、LlamaIndex は抽象化レイヤを厚くして組み合わせを増やし、RAGLite はデータベースのネイティブ機能に寄せて抽象化を薄くする。前者は試行錯誤の回数が多く、後者は検索の挙動が SQL と拡張機能の仕様に直結する。どちらが優れているかではなく、検索の内部を自分で把握したいかどうかの違いである。
ライセンスと保守の見取り図
ライセンスは MPL-2.0 である。ファイル単位のコピーレフトで、MPL の対象ファイルを改変して配布する場合はそのファイルのソースを開示する必要があるが、同じリポジトリ内の別ファイルまで及ぶわけではない。法的助言ではないため、自社製品へ組み込む際の判断は法務に確認してほしい。
保守の面では、リポジトリは archived ではなく、最終 push は 2026-08-17、直近のリリースは v1.1.1（2026-05-18）である。v1.0.0 が 2025-06-11、v0.7.0 が 2025-03-17 なので、1.0 到達後はマイナー更新が続いている段階と読める。ただし README にはアップグレード手順や破壊的変更の一覧は含まれていない。1.0 以降のマイグレーションコストを事前に見積もるには、リリースノートを別途追う必要がある。
編集部の結論
自前の文書集合を持ち、検索バックエンドを DuckDB か PostgreSQL のどちらかに固定できるチームには候補になる。逆に、既に LangChain や PyTorch 前提のパイプラインを運用していて、そこへ差し込む部品が欲しいだけなら、依存を意図的に避ける設計方針が噛み合わない。採用前に確認すべきは、RAGLiteConfig に渡す database と llm の組み合わせが自分の環境で成立するか、そして取り込み対象の PDF が pdftext と pypdfium2 の変換で実用に足るかである。この 2 点は README の記述だけでは判定できず、手元の文書で試すしかない。
コミュニティノート