Chunk 向量化与索引怎么选?

这道题其实问的是怎么在精度和成本之间做工程取舍，不是单纯罗列模型和数据库。我一般会从三个层面来看：[[嵌入]]模型选型、[[向量数据库]]选择，以及最终落地时怎么组合起来。

先说嵌入模型。中文场景下，我会优先考虑开源的 BGE 或者 M3E，因为它们对中文语义理解好，而且能本地部署，成本可控。如果是快速验证或者预算充足，用 OpenAI 的 text-embedding-3 也可以，但要注意数据隐私。这里有个边界：如果任务对细粒度匹配要求高，比如法律合同条款比对，那 [[ColBERT]] 这种延迟交互模型会更合适，但代价是检索延迟会高一些。实际工程中，我倾向于用开源模型做主力，用 OpenAI 做兜底或快速原型，不会只押一边。

再来看向量数据库。选型核心看数据规模和延迟要求。数据量在千万级以下，用 pgvector 就够了，因为它能复用 PostgreSQL 的事务能力，运维成本低；如果数据量上亿，就必须上分布式方案，比如 Milvus 或者 Pinecone。延迟方面，如果 P99 要求 50 毫秒以内，就得用内存型索引 [[HNSW]]，像 Qdrant 或者 Milvus 的内存模式；如果允许 100 毫秒以上，可以用磁盘型 [[IVF-PQ]] 来降低内存成本。举个例子，一个电商客服系统处理退款纠纷，知识库大概 500 万条退款政策和商品说明，我会选 Qdrant 加 HNSW 索引，因为延迟敏感、过滤条件也多，需要按商家、商品类型做元数据过滤。

到了实际落地，真正的挑战不是单个组件选型，而是怎么把关键词检索和向量检索融合起来。纯语义检索在遇到专有名词或订单号时经常翻车，比如用户问“退款到原账户”，但文档里写的是“原路返回”，语义相似度可能不高。所以我会用 [[Hybrid Search]]，把 [[BM25]] 关键词分数和向量相似度分数加权合并，这样既能保证高频词匹配，又能捕捉语义泛化。这里有个前提：必须做好分数归一化，否则不同检索方式的分数量纲不一致，合并结果会乱。

上线前我特别关注一个失败场景：索引更新时，如果直接修改图索引，召回质量会剧烈下降。所以我会用双缓冲策略，一个 base 索引负责线上查询，一个 delta 索引接收增量更新，定期合并重建。构建完用一批固定 query 回放，对比 Recall@K 和延迟，通过才原子切换，不通过就回滚。

其实还有个容易被忽略的点：当业务文档频繁更新时，比如每天新增几千条政策，增量索引的实时性和一致性很难同时保证。我一般会按更新频率做冷热分层，热数据用小索引高频更新，冷数据用大索引低频重建，但具体阈值怎么定，得看业务容忍度。

所以整体来看，我会把 [[RAG]] 向量检索看成一个系统工程，不是简单调个 API 就完事，更倾向于用开源组件自建，因为可定制性高，但前提是团队有运维能力。如果团队小、迭代快，全托管的 Pinecone 也是合理选择。