Milvus Liteを試す ─ SQLite-RAG比較とRESTで広がる応用

Milvus Liteを試す ─ SQLite-RAG比較とRESTで広がる応用 HowTo
2025.09.09

最近は「SQLite-RAG」でローカルにサクッとベクトル検索を組み込む例が増えています。ただ、件数が増えると遅く感じることも…。そこで今回は、ベクトルデータベース専用の Milvus Lite を導入して、SQLiteとの比較ベンチを回してみました。REST API対応でUI化も容易という点も、現場利用には魅力です。

軽量RAGの現実解：SQLite-RAG × LM Studio 実践と運用の勘どころ
軽量RAGの代表例「SQLite-RAG」をLM Studioと組み合わせて実践。完全ローカル環境での構築手順から、精度・応答速度の制約、適したユースケースまでを整理する。ベクトルDBとの比較や運用上の勘どころも解説。
b.aries67.com
2025.09.03

Milvusとは？

  • ベクトル検索専用DBの代表格。
  • 分散スケール可能、近似探索（HNSWなど）に強い。
  • Lite（ローカルSQLiteバックエンド）から分散クラスタまで同一API。
  • REST / gRPC の両対応。アプリ開発のしやすさも売り。

SQLite-RAGと比較する理由

  • SQLite-RAGは「埋め込みをそのままsqliteに入れて検索」できる超軽量手法。
  • 小規模なら十分だが、検索部分はnumpyブルートフォースなので線形時間。
  • MilvusはHNSWインデックスで探索を高速化。件数が増えるほど差が開くとされます。
  • そこで、既存のSQLite-RAGデータベース（就業規則PDFから作成した121件/384次元）をそのままMilvusに流し込み、実測比較しました。

環境構築（ハマりどころも）

  1. Docker Desktop (WSL2バックエンド) を導入
  2. Milvus公式 milvus-standalone-docker-compose.yml を取得して docker compose up -d
    • etcd/minioも一緒に立つ。
    • docker logs -f milvus-standalone で Milvus server is ready を確認。
  3. Python側は pymilvus を利用。
    • connections.connect(host="127.0.0.1", port="19530")
  4. スキーマ作成時に注意
    • VARCHARの max_length デフォルト2048 → 今回は8192に延長。
    • それでも超過するレコードは [:8000] でトリム。

ベンチマークコード（抜粋）

# 接続
connections.connect(host="127.0.0.1", port="19530")

# スキーマ定義
fields = [
    FieldSchema(name="id", dtype=DataType.INT64, is_primary=True),
    FieldSchema(name="text", dtype=DataType.VARCHAR, max_length=8192),
    FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=384),
]
schema = CollectionSchema(fields)
col = Collection("docs_bench", schema)

# データ投入
MAXLEN = 8000
ids   = [r[0] for r in rows]
texts = [(r[1] or "")[:MAXLEN] for r in rows]
embs  = [deserialize_vector(r[2]) for r in rows]
col.insert([ids, texts, embs])
col.flush()

# 検索（HNSW）
res = col.search(queries, "embedding", search_params={"metric_type": "L2", "params": {"ef": 64}}, limit=5)

SQLite側は numpy.linalg.norm による総当たり比較。

実測結果

件数 = 121, 次元 = 384, クエリ = 100, TopK = 5

Milvus Lite (HNSW)  : 平均 2.59 ms/クエリ
SQLite (numpy brute): 平均 5.04 ms/クエリ
Speedup ≈ 1.94x
  • データ件数が少ないにも関わらず、約2倍の速度差。
  • 1万件以上の規模になると、差はさらに拡大する見込み。
  • RAGの全体体感ではLLM応答が律速だが、検索部分が確実に軽くなるのは意味がある。

Milvusを使うメリット（まとめ）

  • SQLite-RAGより検索は高速＆スケーラブル。
  • REST API対応で簡易UIや外部サービス連携がすぐできる。
  • LiteでPoC → Standalone/DockerでREST化 → 本番クラスタ、とシームレスに拡張可能。

今後の展開

  • REST UI化：Docker Standaloneを前提に検索UIを用意、現場投入イメージを検証。
  • 顔検索/画像類似検索：RAG以外の応用を別記事で。動画フレームから人物検索などは絵映えする。
  • リコール検証：近似探索（HNSW）がどこまでブルートフォースと一致するかも追加で確認予定。

結論

SQLite-RAGは「まず試す」には最高ですが、スケールや応用を考えるならMilvus Liteは強力な選択肢です。今回の比較でも小規模で約2倍、RESTやUI化まで視野に入れれば、次の一歩にちょうど良いと感じました。

参考リンク