Chunk 向量化与索引怎么选?
RAG 中 Embedding 模型与向量数据库对比及选型指南
原题：在RAG系统中，如何将文本块（chunk）转换为向量表示并构建高效的检索索引？请列举常用的文本嵌入模型和主流向量数据库，比较它们的特点及适用场景，并说明在实际工程中如何进行技术选型。
文档处理 · 字节真题
回答与解析
一、文本块向量化流程
核心步骤
- Chunk策略：先按语义段落和结构边界切分，再把多组固定长度与重叠窗口作为候选；由模型输入限制、文档结构和同一评测集上的证据完整率、召回与成本决定
- 嵌入模型编码：将文本映射为稠密向量（通常768或1024维）
- 索引构建：选择ANN算法（HNSW、IVF-PQ等）建立可高效检索的数据结构
二、常用嵌入模型对比
| 模型 | 特点 | 适用场景 |
|---|---|---|
| OpenAI text-embedding-3 | 语义质量高，API易用，按token计费 | 快速验证、中小规模、预算充足 |
| BGE/M3E（开源） | 中文优化好，可本地部署，成本可控 | 大规模生产、隐私敏感场景 |
| E5/GTE | 长文本支持好，学术benchmark领先 | 长文档检索、技术报告类场景 |
| ColBERT | 延迟交互模型，细粒度匹配能力强 | 高精度要求、可接受更高延迟 |
选型要点：中文场景优先BGE；成本敏感选自研/开源；需要解释性考虑ColBERT类模型。
三、主流向量数据库对比
| 数据库 | 核心特点 | 最佳场景 |
|---|---|---|
| Milvus/Zilliz | 云原生、分布式架构成熟、GPU加速 | 十亿级规模、企业级生产环境 |
| Pinecone | 全托管、零运维、自动扩缩容 | 快速上线、团队运维资源有限 |
| Weaviate | 原生支持混合检索（向量+BM25）、GraphQL接口 | 需要关键词+语义联合召回 |
| Qdrant | Rust实现、内存效率高、过滤性能强 | 元数据过滤复杂、内存敏感 |
| pgvector | PostgreSQL插件、事务支持好 | 已有PG生态、数据量<千万级 |
四、工程选型决策框架
关键权衡维度
数据规模
- <1000万：pgvector或单机Milvus足够
1亿：必须分布式方案（Milvus集群或Pinecone）
延迟要求
- P99<50ms：内存型HNSW索引（Qdrant、Milvus）
- 可接受100ms+：磁盘型IVF-PQ降低内存成本
检索模式
- 纯语义：任意向量库均可
- 需过滤+排序：优先Weaviate、Qdrant的过滤下推能力
成本结构
- 自托管：人力成本高，硬件成本可控
- SaaS：按量付费，适合波动负载
字节场景的特殊考量：内部通常自研或基于Faiss二次开发，追求极致性能与成本控制，同时需要与推荐系统基础设施打通。
学习建议
掌握常见嵌入模型（如BERT、Sentence-BERT）和向量数据库（如FAISS、Milvus）的基本原理与对比维度，结合RAG流程理解向量化与检索的协同机制。
口语版讲法(约4分钟)
- 本质是精度与成本的工程平衡
- 嵌入模型选型：中文场景开源优先
- 向量数据库：规模与延迟决定方案
- 落地关键：混合检索与风险控制
- 可延伸点：增量更新的常见坑
这道题其实问的是怎么在精度和成本之间做工程取舍，不是单纯罗列模型和数据库。我一般会从三个层面来看：嵌入模型选型、向量数据库选择，以及最终落地时怎么组合起来。
先说嵌入模型。中文场景下，我会优先考虑开源的 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 也是合理选择。
关键一句:增量更新场景下，实时性与召回质量的矛盾，以及冷热分层策略
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做一个电商客服RAG系统，商品FAQ文档切成块后要快速检索。你打算怎么把这些文本块转成向量？选什么嵌入模型和向量库？要注意什么？
- 问法 2 · 层层追问
RAG里文本块怎么变成向量、怎么建索引，你一般怎么做？……那嵌入模型你用过哪些？……如果数据量上亿，你选哪个向量数据库？怎么权衡？
- 问法 3 · 直球架构
说一下RAG系统中文本块向量化和检索索引构建的完整流程，包括常用的嵌入模型和向量数据库，以及技术选型时要考虑哪些因素。