llmware レビュー: オンデバイス推論を前提にした RAG パイプライン構築フレームワーク

llmware が埋めようとしている隙間

RAG の部品はすでに揃っている。文書パーサ、埋め込みモデル、ベクトル DB、LLM の推論ランタイムは、それぞれ別のプロジェクトとして存在する。問題は、それらを繋ぐコードがアプリケーションごとに書き直されることだ。PDF をパースするライブラリを替えるとチャンクの持ち方が変わり、埋め込みモデルを替えると検索 API の呼び方が変わり、推論バックエンドを GGUF から OpenVINO に替えるとモデル読み込みの記述が全部書き換わる。llmware はこの接続部分を 1 つのパッケージにまとめ、替えたい部品だけを差し替えられるようにしている。対象読者は、クラウド API に社内文書を送れない制約のある企業の開発者と、ノート PC やエッジ端末で動かす前提のアプリを作る人だ。README は「AI PC and local laptop, edge and self-hosted deployment」を想定すると明記しており、汎用の RAG フレームワークというより、オンデバイス前提のツールキットとして位置づけられている。

Library が知識ベースの単位になる

llmware の中心にあるのは Library という入れ物だ。Library().create_new_library("my_library") を呼ぶと、テキストコレクション用の DB リソースと、llmware_data/accounts/{library_name} というファイル用のディレクトリが同時に作られる。取り込みは lib.add_files("/folder/path/to/my/files") の 1 系統で、README によれば pdf、pptx、docx、xlsx、txt、csv、md、json/jsonl、wav、png、jpg、html を受け付け、拡張子でパーサに振り分けたうえでテキストチャンク化とインデックス作成まで進む。ファイル形式ごとに前処理を書き分けずに済むのは、実務では大きい。埋め込みはライブラリ単位で後から差し込む設計で、lib.install_new_embedding(embedding_model_name="mini-lm-sbert", vector_db="milvus", batch_size=500) のように指定する。同じライブラリに 2 つ目の埋め込みを追加できる点も README が明示しており、たとえば汎用の mini-lm-sbert と、金融文書向けの industry-bert-sec を同じ文書集合に対して併存させ、クエリ側で使い分けられる。

検索は Query オブジェクトに集約される

Library をロードし、Query(lib) でクエリオブジェクトを作る。ここから text_query、semantic_query、text_query_with_document_filter といったメソッドを呼び分ける形になっている。text_query は exact_mode を切り替えられ、semantic_query は埋め込みベクトルによる近傍探索、text_query_with_document_filter は {"file_name": "selected file name"} のようなメタデータ条件で対象文書を絞ったうえでテキスト一致をかける。ライブラリに複数の埋め込みが載っている場合は、Query(lib, embedding_model_name="mini_lm_sbert", vector_db="milvus") のようにクエリ生成時点でどの埋め込みを使うか決める。検索方式とインデックスの選択が同じオブジェクトの引数に並ぶので、どの組み合わせで何を引いたかがコード上で追いやすい。一方で、README が示すのはメソッドの一覧と引数までで、スコアの算出方法やランキングの統合ロジックには触れていない。ハイブリッド検索の重み付けを自分で調整したい場合、そこはソースを読む必要がある。

ModelCatalog によるバックエンドの抽象化

推論側は ModelCatalog が窓口になる。ModelCatalog().load_model("llmware/bling-phi-3-gguf") のようにモデル名を渡すと、GGUF、OpenVINO、ONNXRuntime、ONNXRuntime-QNN、WindowsLocalFoundry、Pytorch のどれで動かすかを意識せずに済む。README はカタログに 300 以上のモデルがあり、そのうち 50 以上が SLIM、Bling、Dragon、Industry-Bert として RAG 向けに調整されていると説明している。呼び出しは my_model.inference(...) と my_model.stream(...) の 2 形態。add_context 引数に参照させたいテキストを渡すと、そのままモデルへの入力に混ぜられる。Prompt クラス経由なら Prompt().load_model("llmware/bling-tiny-llama-v0") に対して prompt_main("what is the future of AI?", context="...") と呼ぶだけで、検索結果の詰め込みと推論が 1 行にまとまる。推論技術の選択をモデル名の解決に押し込んだ設計は、プラットフォームごとに最適なバックエンドが違う状況では合理的だ。ただし抽象化の代償として、バックエンド固有の生成パラメータを細かく触りたいときは、この層を迂回する必要が出てくる。

導入コマンドと設定の勘所

配布は PyPI 経由で、パッケージ名は llmware。README のバッジは Python 3.10 から 3.14 までを対象として示している。インストール後、最初に触るのは ModelCatalog で、ModelCatalog().list_all_models() を実行するとカタログに登録されたモデル名の一覧が取れる。ここに並ぶ名前をそのまま load_model に渡すのが基本の流れだ。ライブラリ側は Library().create_new_library("my_library")、lib.add_files("/folder/path/to/my/files")、lib.install_new_embedding(embedding_model_name="mini-lm-sbert", vector_db="milvus", batch_size=500) の 3 段階で、埋め込みのバッチサイズは batch_size で指定する。ベクトル DB は引数で選ぶ方式なので、milvus や chromadb を別途動かしておく必要がある。状態の確認は Library().get_library_card("my_library") で文書数、チャンク数、画像、表、埋め込みレコードをまとめて取れる。どのモデル名とどの vector_db の組み合わせが実際に自分の環境で通るかは、README の例だけでは判断できない。list_all_models の出力と、手元の DB の稼働状況を突き合わせてから本番のコードを書くほうが安全だ。

小さいモデルを選ぶという制約をどう見るか

llmware の設計は「smallest possible compute footprint」という方針に貫かれている。これは利点であると同時に、明確な制約でもある。Bling や tiny-llama のような小型モデルは、複雑な推論や長い文脈をまたぐ統合を要する質問では、クラウドの大規模モデルに及ばない。README 自身、OpenAI、Anthropic、Google のクラウドモデルも扱えると書いているので、両方を同じ ModelCatalog の下で混ぜることはできる。だが、その場合はデータが端末の外に出る時点で、ローカル完結という前提は崩れる。つまり llmware を選ぶ理由の中心は、モデルの性能ではなく、どこで推論を走らせるかを自分で決められる点にある。性能要件が先に立ち、データの持ち出しに制約がない案件では、このフレームワークを挟む意味は薄い。逆に、文書が端末から出られない案件では、モデルの絶対性能が落ちることを受け入れる代わりに、選択肢が現実的に存在する。

LangChain との違いは抽象化の層にある

比較対象として挙げやすいのは LangChain だ。LangChain はプロンプト、チェーン、ツール呼び出しといった構成要素を組み合わせてアプリケーションを組むための部品群で、推論バックエンドは外部のランタイムに委ねる。llmware は逆で、ModelCatalog が GGUF や OpenVINO といったローカル推論の実行形式を吸収し、Library がパースから埋め込みまでを抱え込む。どちらか一方が上位という話ではなく、抽象化している対象が違う。LangChain でローカル推論を扱う場合、llama-cpp-python や ONNX Runtime を自分で繋ぎ、量子化形式ごとの読み込み差分を自分で吸収することになる。その自由度が要るなら LangChain のほうが素直だ。llmware はその差分をカタログ側に寄せた代わりに、対応するバックエンドの範囲内でしか動かない。対応形式は GGUF、OpenVINO、ONNXRuntime、ONNXRuntime-QNN、WindowsLocalFoundry、Pytorch と README に列挙されているので、自分のターゲット環境がこのどれかに当てはまるかを最初に確認するのが判断の出発点になる。

ライセンスと更新の追い方

ライセンスは Apache-2.0 で、リポジトリは archived ではない。直近のリリースは v0.4.6 が 2026 年 4 月、その前が v0.4.5 で 2026 年 2 月、v0.4.4 が 2026 年 2 月と、数か月間隔で版が上がっている。0.x 系が続いている点は意識しておきたい。マイナー番号の更新で API の引数や既定値が動く可能性は残る。ModelCatalog に登録されるモデル名はカタログ側の更新で増減しうるので、コードにモデル名を直書きしている箇所は、更新時に list_all_models の出力と突き合わせる作業が発生する。Apache-2.0 は特許条項を含む寛容なライセンスだが、同梱されるモデルの重みはそれぞれ別のライセンスで配布されていることが多く、llmware 本体のライセンスがそれらを覆うわけではない。モデルごとの条件は Hugging Face 上の各リポジトリで確認する必要がある。ここは法務判断の領域なので、導入前に自組織の確認を通しておくべき項目として挙げておく。

編集部の結論

自社の文書を外部 API に出せない、あるいはノート PC やエッジ端末で完結させたいチームに向く。逆に、最先端のクラウドモデルの性能をそのまま引き出したい場合や、すでに LangChain とベクトル DB で組み上げた経路がある場合に、置き換える理由は薄い。導入前に確認すべきは 3 点で、対象プラットフォームで GGUF か OpenVINO のどちらのバックエンドが動くか、lib.install_new_embedding で指定する vector_db が自分の環境で用意できるか、そして Library().create_new_library が作る llmware_data/accounts/{library_name} 配下のファイルを誰が管理するかである。

公式情報源

1. License: Apache-2.0
2. llmware-ai/llmware on GitHub
3. Project website
4. README
5. Releases