做 RAG 的团队常在两个节点卡住：一是刚起步，不知道该挑托管服务还是自己搭一套；二是知识库涨到几十万条以后，召回开始变慢变飘，不确定是库的问题还是切片和检索参数的问题。这篇不替你拍板，只给一套判断维度和逐项核对的动作，让你能拿着自己的数据量、延迟底线和运维人力，把候选缩到两三个再动手测。
做 RAG 的团队通常在两个时间点卡住。第一个是刚起步，手里还没有数据，面对一堆名字不知道从哪下手；第二个是跑了一段时间，知识库涨到几十万条，召回开始变慢、结果变飘，不确定是库不行了还是切片和检索参数的问题。这两种情况需要的动作完全不同，前一种是把候选缩下来，后一种往往压根不该换库。
这篇不替你选谁，只给一套可执行的判断路径：先把四个硬性数字写下来，再用它们砍候选，最后拿同一批测试题对比剩下的两三个。具体单价、性能量级这类会变的数字，一律到站内对应页面看当时的，别用别人文章里的旧数。
先定维度，再看产品
选型最容易犯的错是先看产品列表再倒推需求，结果看哪个都好。反过来做：落库之前先写下四个数。这四个数写不出来，说明需求还没想清楚，这时候挑任何库都是碰运气。把它们写在纸上，候选会自动掉一半。
| 维度 | 要写的数 | 不适用的情况 |
|---|---|---|
| 数据规模 | 向量条数上限、单条维度 | 条数稳定在几万且不涨，规模就不是决定项 |
| 延迟底线 | 可接受的首字延迟和召回延迟 | 只做离线批处理、不面向用户时，延迟可以让步 |
| 运维形态 | 有没有专人长期维护 | 团队已经有一套成熟的数据库运维能力时，这条可以放宽 |
| 过滤需求 | 要不要按租户、来源、时间做条件过滤 | 全局单租户、从不做条件筛选的场景可以简化 |
四条里最容易踩坑的是过滤能力。RAG 里十有八九要按租户或文档来源做条件过滤，选之前先确认过滤是走索引还是先召回再后置筛选——后置筛选在数据量大、过滤条件苛刻的时候会把召回量吃掉一大截。更新与删除同理：文档频繁改动、要求删除即生效的场景，和一次灌库基本不动的场景，对引擎的要求完全不是一回事。
- 运维形态是第一道分水岭：完全不想碰运维就只筛托管型，愿意自己扛再把可自托管的开源方案纳进来
- 已有云资源但想控成本的团队，可以看是否已有数据库提供了向量扩展，少维护一套组件
- 过滤条件先想清楚选几个字段、过滤后预期还剩多少条，这决定要不要强依赖索引过滤
- 删除和更新的频率写清楚，要求删除即生效的场景要专门验证，别只测写入
把候选缩到两三个的实操
维度定完，接下来是筛人。别一次列十个，按形态分三类——托管服务、可自托管、已有数据库的向量扩展——每类留一到两个，总数控制在两三个。要横向看名单和形态分类，到站内的向量数据库目录按维度过一遍，比在搜索里翻帖子快得多。
- 按形态各留一到两个托管、自托管、向量扩展三类，每类先各挑最多两个，超过就说明前一步的四个数没写清楚
- 准备同一批测试题整理二三十条真实问句，人工标出期望命中的文档，这批题后面所有候选都用它，别换题
- 关键词和向量两条链路都跑很多场景是混合检索，只看向量召回会误判；两条链路的命中位置都要看
- 统一延迟口径同一批次、同一并发下测检索耗时，别拿不同机器上的单条测试互相比，可比性很差
成本只算相对量级就够了。把存储、写入、查询三类费用按你自己的数据量折算成一个粗略比例，够用来排序即可。具体单价到站内的价格追踪页面核对当时的数字，这个数字会变，写死在文章里没意义，也可能已经过时。
接入前必须验的几件事
候选定了两三个之后，不要直接看文档就决定。写最小可用脚本把主流程跑一遍，四步全过再谈迁移。这一步通常只花半天，但能提前发现客户端兼容、认证方式、字段类型这些文档里不会强调的问题。
# 伪代码顺序，按你自己的客户端替换
create_collection(dim=你的维度, metric=你的距离度量)
upsert(约100条带metadata的记录)
query(按租户或来源做条件过滤, top_k=10)
delete(其中一条, 再查一次确认已消失)- 嵌入模型和向量库的维度和距离度量必须对齐，换嵌入模型基本等于重新入库，这条要在选型阶段就想明白
- 检索参数和库选型要分开评估：先固定参数测库，再固定库调参数，不然出了问题定位不了
- 做一次小规模压测，用目标并发跑几分钟看错误率和耗时曲线，而不是只看单次耗时
- 确认降级路径：库挂了或超时的时候，应用是返回空结果还是走兜底检索，这个要在接入前定
压测和参数评估的具体做法，站内工具有对应的速度测试页面可以参照，注意它测的是当时的量级，不是给你抄的绝对值。你自己环境里的数字才算数。
什么情况下先别换库
这一类问题在 RAG 项目里出现频率不低：召回质量掉了，第一反应是库不行了。但多数时候，切片方式、嵌入模型和重排这三者带来的差异，比换库大得多，而换库恰恰是最贵的一步。先按下面这个顺序排查，排完还是不行再谈迁移。
| 现象 | 先查什么 | 什么情况下才考虑换库 |
|---|---|---|
| 召回结果不相关 | 切片长度和重叠、嵌入模型是否匹配语料 | 切片和嵌入都调过、评测集上仍无改善 |
| 召回变慢 | 过滤条件是否命中索引、返回条数是否过大 | 数据量已远超预期、压测确认是引擎侧瓶颈 |
| 删除不生效 | 客户端调用是否走了异步删除、索引重建周期 | 确认接口语义后仍不符合合规要求 |
| 延迟抖动 | 并发是否超过目标值、是否有重排拖尾 | 目标并发下持续超时且扩资源也压不住 |
- 数据量还在几万条以内、延迟够用时，换库收益很低，把清洗和评测集做扎实更划算
- 团队没有专人维护数据库时，别因为性能数字好看就选自托管，运维成本会在半年后显现
- 已经跑通且没有明确瓶颈的项目，精力放在评测集和检索链路上，而不是每隔一个季度重挑一次库
- 要换就带着评测集换，同一批题在旧库和新库上各跑一遍，用差值说话而不是感觉
召回差先怀疑切片和嵌入，库往往是最后才该动的那一环。下一步：拿名单去对照带着你写下的四个数和两三个候选，到站内的向量数据库目录核对形态与适用场景，再到价格追踪页面看当时的数字，用你自己的数据量折算一遍，比看任何评测结论都准。→
常见问题
向量数据库和传统数据库的向量扩展该怎么选？
看两点：数据量级和过滤复杂度。条数不大、过滤条件就是普通字段、又已经在用某款关系型数据库时，直接用它的向量扩展最省事，不用多养一套系统。条数上百万、过滤维度多且要求高并发时，再考虑独立向量库。判断不准就先拿几万条做一轮召回测试再定。
自托管和托管服务到底差在哪？
差在运维归属和成本结构。托管服务省掉部署、扩缩容、备份，换来的是一定程度的锁定和按量付费；自托管省钱但要有人管升级、磁盘和故障。团队里没人能长期盯这套东西，就不要选自托管，哪怕单次测试性能更好。
换了嵌入模型，原来的库还能用吗？
不能直接混用。不同嵌入模型的维度和语义空间不一样，同一批文档必须用同一个模型重新向量化后整体写入，通常做法是新建一个集合并行跑一段，比对召回结果没问题再切流量，别在原集合上原地覆盖。
