ChromaDB 向量数据库指南
ChromaDB 适合那种“先把检索链路做出来，再慢慢加复杂度”的项目。你如果正在做本地知识库、小型 RAG、训练营 demo 或内部原型，它上手确实很顺。
把 ChromaDB 想成“给文本建的图书馆”，只不过它不是按书名排架，而是按语义接近程度排。真正麻烦的地方也不在数据库本身，而在你怎么切文档、怎么打标签、怎么判断召回到底准不准。
#为什么很多人先用 ChromaDB
- 本地启动简单，原型成本低
- Python 生态顺手，和常见 RAG 脚本能直接接
- 不需要一开始就上更重的向量基础设施
如果你只是想验证“这批文档能不能被稳定召回”，ChromaDB 足够快。
#它最适合什么场景
- 个人知识库问答
- 课程资料、内部文档这类中小规模检索
- 先做离线或本地原型，再决定是否换到更重的服务
我不太建议把它当作“所有 RAG 项目的默认终点”。更现实的用法是：先用它验证检索策略，后面再看规模和并发是否需要迁移。
#学习顺序
这个顺序最好别跳。因为很多检索问题看起来像模型问题，其实是集合设计或 metadata 根本没想清楚。
#真正影响效果的，不只是数据库
RAG 表现不稳时，我更先查下面这些：
- 文档切块是不是过粗或过碎
- metadata 字段有没有为过滤留足空间
- 嵌入模型是不是前后混用了不同维度
- 检索评估是不是只靠“感觉还行”
这些问题不解决，你换更贵的模型也未必有用。
#一个更像真实项目的推进顺序
- 先跑通
入库 -> 检索 -> 输出 - 再补 metadata 和过滤条件
- 然后用真实问题集做回测
- 最后才考虑 embedding A/B 或数据库迁移
顺序反过来，通常只会多花时间。
#生产化前先想清楚
- embedding 模型要不要固定版本
- 文档更新后是否要全量重建索引
- 删除、归档和重新入库怎么做
- 检索效果用什么业务问题来验收
如果这些问题还没回答，先别急着讨论“要不要换数据库”。
