ベクトルDB実装(ChromaDB)

ChromaDBとは

ChromaDB は、[[ベクトルデータベース]] の実装のひとつです。埋め込みベクトルと元のテキスト・メタデータをまとめて保存し、「意味が近い文書」を取り出せます。

概念としてのベクトルDBが「何をするものか」を説明するのに対し、この記事は「実際に動かすと何が要るか」を扱います。

import chromadb

client = chromadb.PersistentClient(path="./store")
collection = client.get_or_create_collection("docs")

collection.add(
    ids=["doc-1"],
    documents=["Ollamaはローカルでモデルを動かす"],
    metadatas=[{"source": "note.md"}],
)

hits = collection.query(query_texts=["ローカル実行"], n_results=3)

サーバーを別途立てずに、ファイルへ永続化するだけで使い始められるのが特徴です。手元での試作や小〜中規模の [[RAG(検索拡張生成)]] で選ばれやすい理由がここにあります。

3つの構成要素

埋め込み関数は投入時と検索時で必ず同じものを使います。違うモデルで作ったベクトルは同じ空間に無いため、検索結果が意味をなしません。[[埋め込みとベクトル検索]] の前提がそのまま実装上の制約になります。

メタデータでの絞り込みは実務で効きます。「この出典のみ」「この日付以降」といった条件をベクトル検索と併用すると、無関係な文書が混ざる事故を減らせます。

実務での勘所

• チャンク分割 — 文書をどの粒度で切るかが精度を最も左右します。長すぎると無関係な部分が混ざり、短すぎると文脈が失われます
• 件数の指定 — 取り出す件数を増やすほど関連文書を拾えますが、プロンプトが膨らみます
• 更新の扱い — 元文書が変わったら、対応する id を上書きするか削除して入れ直します。放置すると古い内容が検索に出続けます
• 規模の限界 — 手軽さと引き換えに、大規模・高負荷の運用では専用サービスの検討が必要になります

[[LangChain]] からは retriever として組み込めるため、パイプラインの検索段を ChromaDB が担う構成が定番です。

近さの測り方(距離の指標)はコレクション作成時に決めます。埋め込みモデルが想定する指標に合わせるのが原則で、既定のまま使うなら投入と検索で同じ設定を保つことだけは崩さないようにします。ここがずれると、埋め込みモデルを揃えていても順位が期待どおりになりません。

初学者向けポイント

• まずは十数件の文書で投入と検索を往復し、期待した文書が返るかを目で確認します
• 精度が出ないときは、モデルを変える前にチャンク分割と取得件数を見直すほうが効果が大きいことが多いです
• 保存先ディレクトリを消せば作り直せます。試行錯誤の段階では作り直しを前提に進めると速く進みます

関連技術とのつながり

• [[ベクトルデータベース]] — 概念の記事。ChromaDB はその実装のひとつ
• [[埋め込みとベクトル検索]] — 投入時と検索時で同じ埋め込みモデルを使う前提の理由
• [[RAG(検索拡張生成)]] — 検索段を担う実体としてよく使われる
• [[LangChain]] — retriever として組み込み、パイプラインの一部にできる

Q: ChromaDBと「ベクトルデータベース」という語の関係はどれ?
- [ ] 同じものの別名
- [x] ベクトルデータベースという概念に対する実装のひとつ
- [ ] ChromaDBはリレーショナルデータベースの一種
解説: ベクトルデータベースは概念で、ChromaDB はその具体的な実装のひとつです。

Q: 埋め込み関数の扱いとして正しいものはどれ?
- [x] 投入時と検索時で同じものを使う必要がある
- [ ] 検索時だけ指定すればよい
- [ ] 毎回別のモデルを使ったほうが精度が上がる
解説: 異なるモデルで作ったベクトルは同じ空間に無いため、揃えないと検索結果が意味をなしません。

Q: RAGの精度が出ないとき、まず見直す価値が高いものはどれ?
- [ ] データベースの文字コード設定
- [x] チャンク分割の粒度と取得件数
- [ ] サーバーのポート番号
解説: どの粒度で文書を切り、何件取り出すかが精度を大きく左右します。モデル変更より先に確認する価値があります。