Chroma 向量数据库概念

Chroma 向量数据库概念

层级对应关系(类比 MySQL)

Chroma	MySQL	说明
persist_dir(存储实例)	database	整个数据存放的根目录
collection	table	检索的基本单位,一次 similarity_search 只能在一个 collection 内进行
一条 chunk 记录	row	包含 embedding + document + metadata
metadata 字段(domain、book_id)	column	用于 where 过滤,不是表名/库名

collection 的隔离特性

• 结构上是"表"级别,多个 collection 共享同一个 persist_dir。
• 行为上隔离更彻底,接近"库"级别:collection 之间不能跨库检索,不像 SQL 能 JOIN 或跨库查询。
• 想同时查多个 collection,只能分别查询再自己合并结果。

metadata 过滤(如 domain)的作用

• 起到"表内软隔离"的效果,用于检索时限定范围(如 where={"domain": "agriculture"})。
• 用途:
  1. 检索结果溯源:标记 chunk 来自哪个领域/哪本书
  2. 定向查询:按需过滤到某个子集,避免无关内容干扰召回
  3. 数据管理:可按字段精确删除/更新某一批数据(如 book_id),无需清空整个 collection
  4. 多层过滤:domain(粗粒度)+ book_id(细粒度)组合使用

数据成规模后的问题

单个collection真正会随规模下降的是检索效率与召回率,原因:

• 向量索引建立在整个 collection 之上,不是按 metadata 分开建索引
• 检索流程通常是:先在全量索引做近似最近邻(ANN)搜索拿到候选集 → 再用 metadata 条件过滤
• 若目标 domain 在 collection 中占比很小,候选集里命中该 domain 的数量可能不足,导致返回结果数少于预期、召回率下降

何时该拆分为多个独立 collection

出现以下情况时,拆分优于继续依赖单 collection + metadata 过滤:

• 单一 domain 检索经常召回数量不足
• 查询延迟随数据量增长明显变长

本质是性能优化手段,而非"隔离不够安全"——拆分后每个索引更小、更纯粹,避免"大池子里过滤"的精度损耗。