面试题 · 文档处理
搜索「隐私」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在RAG系统中，如何将文本块（chunk）转换为向量表示并构建高效的检索索引？请列举常用的文本嵌入模型和主流向量数据库，比较它们的特点及适用场景，并说明在实际工程中如何进行技术选型。
核心步骤
| 模型 | 特点 | 适用场景 |
|---|---|---|
学习内容与项目面试，在同一条路上。
| 语义质量高，API易用，按token计费 |
| 快速验证、中小规模、预算充足 |
| BGE/M3E（开源） | 中文优化好，可本地部署，成本可控 | 大规模生产、隐私敏感场景 |
| E5/GTE | 长文本支持好，学术benchmark领先 | 长文档检索、技术报告类场景 |
| ColBERT | 延迟交互模型，细粒度匹配能力强 | 高精度要求、可接受更高延迟 |
选型要点：中文场景优先BGE；成本敏感选自研/开源；需要解释性考虑ColBERT类模型。
| 数据库 | 核心特点 | 最佳场景 |
|---|---|---|
| Milvus/Zilliz | 云原生、分布式架构成熟、GPU加速 | 十亿级规模、企业级生产环境 |
| Pinecone | 全托管、零运维、自动扩缩容 | 快速上线、团队运维资源有限 |
| Weaviate | 原生支持混合检索（向量+BM25）、GraphQL接口 | 需要关键词+语义联合召回 |
| Qdrant | Rust实现、内存效率高、过滤性能强 | 元数据过滤复杂、内存敏感 |
| pgvector | PostgreSQL插件、事务支持好 | 已有PG生态、数据量<千万级 |
关键权衡维度
数据规模
1亿：必须分布式方案（Milvus集群或Pinecone）
延迟要求
检索模式
成本结构
字节场景的特殊考量：内部通常自研或基于Faiss二次开发，追求极致性能与成本控制，同时需要与推荐系统基础设施打通。
掌握常见嵌入模型（如BERT、Sentence-BERT）和向量数据库（如FAISS、Milvus）的基本原理与对比维度，结合RAG流程理解向量化与检索的协同机制。
场景切入
假设你在做一个电商客服RAG系统，商品FAQ文档切成块后要快速检索。你打算怎么把这些文本块转成向量？选什么嵌入模型和向量库？要注意什么？
层层追问
RAG里文本块怎么变成向量、怎么建索引，你一般怎么做？……那嵌入模型你用过哪些？……如果数据量上亿，你选哪个向量数据库？怎么权衡？
直球架构
说一下RAG系统中文本块向量化和检索索引构建的完整流程，包括常用的嵌入模型和向量数据库，以及技术选型时要考虑哪些因素。
这道题其实问的是怎么在精度和成本之间做工程取舍，不是单纯罗列模型和数据库。我一般会从三个层面来看：[[嵌入]]模型选型、[[向量数据库]]选择，以及最终落地时怎么组合起来。
先说嵌入模型。中文场景下，我会优先考虑开源的 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 也是合理选择。