完整题目
请描述构建一个用于语义检索的向量数据库的完整流程，包括文本预处理、嵌入模型选择、向量索引构建、存储方案及查询优化策略。
本文目录
答案要点
- 文本预处理的关键步骤（清洗、分块、元数据保留）
- Embedding模型选型依据（领域适配、多语言、维度权衡）
- 向量索引算法选择（HNSW、IVF、PQ的适用场景）
- 存储方案设计（向量+标量混合存储、分片策略）
- 查询优化手段（查询重写、重排序、缓存策略）
1. 文本预处理
- 清洗：去HTML标签、特殊字符、统一编码，保留语义关键信息
- 分块策略：按语义段落切分（非固定长度），重叠窗口保证上下文连贯；高德场景可考虑POI名称、地址等结构化字段单独处理
- 元数据关联：保留原始ID、时间戳、地理位置等过滤字段，用于后续混合查询
2. 嵌入模型选择
| 考量维度 | 选择建议 |
|---|---|
| 领域适配 | 通用场景用BGE/M3E，地图/POI场景考虑领域微调 |
| 多语言 | 高德需支持中英文混合，E5-Multilingual或BGE-M3 |
| 维度权衡 | 768/1024维平衡效果与存储，1024维以上收益递减 |
| 推理性能 | 小批量用ONNX/TensorRT加速，批量预计算 |
3. 向量索引构建
- HNSW：默认首选，构建慢、查询快，适合静态或增量更新场景
- IVF-PQ：十亿级数据用，内存友好，召回略低但可调参
- 增量更新：采用分层索引或分区策略，避免全量重建
4. 存储方案
- 混合存储：向量存Faiss/Milvus，标量字段存PostgreSQL/ES，用ID关联
- 分片策略：按地理区域或业务线分片，查询路由到指定分片
- 冷热分离：高频查询向量放内存/SSD，冷数据压缩归档
5. 查询优化
- 查询重写：Query2Doc扩展、同义词改写，解决语义鸿沟
- 两阶段检索：向量召回Top-K → 精排模型（Cross-Encoder）重排序
- 缓存策略：热门Query的向量结果缓存，Embedding结果缓存
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服系统，用户问“上次买的那个红色连衣裙还有吗”，你需要从海量商品描述里快速找到相关商品。你怎么构建这个向量检索流程？从文本清洗到最终返回结果，一步步说说。
层层追问
语义检索的向量数据库，你整体怎么搭建？……文本预处理那块，分块有什么讲究？……嵌入模型你怎么选，考虑哪些因素？……索引用哪种，HNSW还是别的？……存储和查询优化还有哪些坑？
直球架构
描述一下构建语义检索向量数据库的完整流程，包括文本预处理、嵌入模型选择、向量索引构建、存储方案和查询优化策略，每个环节的关键点是什么？
练习口述回答 · 约4分钟
- 本质是让机器理解语义并高效召回
- 文本预处理要保语义、留元数据
- Embedding模型选型看场景和效率
- 索引选HNSW，存储要混合
- 查询优化：重写+重排+缓存
这道题其实是在问，怎么让机器真正理解一段文本的意思，然后从海量数据里快速找到最相关的内容。我会从五个环节来讲，但重点放在那些容易踩坑的地方。
先说文本预处理。很多人上来就切固定长度，但语义检索最怕把一句话腰斩。我的做法是按语义段落切分，比如一个POI描述，我会把名称、地址、营业时间这些结构化字段单独处理，正文部分用重叠窗口保证上下文连贯。这里有个前提，[[分块]]粒度要跟你的检索场景匹配，如果是搜客服退款政策，块可以大一点，包含完整条款；如果是搜具体商品参数，块就得小，甚至按属性拆。另外元数据一定要保留，比如时间戳、地理位置，后面做混合过滤全靠它。
然后是[[Embedding]]模型选型。通用场景我会首选BGE或者M3，但如果业务有领域特性，比如地图POI或者医疗文档，最好在通用模型基础上做领域微调。维度上768或1024就够了，更高收益递减，存储和计算成本反而直线上升。真正落地时，我通常会同时跑一个轻量模型做初筛，再用大模型做精排，效果和成本之间取个平衡。
向量索引这块，我默认选[[HNSW]]，因为它查询快、精度高，对大多数场景够用。但如果数据量到十亿级，内存扛不住，我会用[[IVF-PQ]]做量化压缩。这里有个常见失败场景：很多人直接拿HNSW做高频增量更新，结果索引碎片化严重，召回率暴跌。我的做法是增量插入走独立小索引，查询时合并，定期全量重建。
存储方案上，向量和标量一定要分开存。向量丢到[[Faiss]]或Milvus里，标量字段比如订单号、用户ID放在PostgreSQL或ES里，通过ID关联。分片策略按业务线或者地理区域切，查询时路由到对应分片，避免全表扫。冷热分离也很有必要，高频向量放内存或SSD，冷数据压缩归档，能省不少成本。
最后是查询优化。第一步是查询重写，比如用户搜“退货运费谁出”，我会用Query2Doc扩展成“退款运费承担”，或者同义词改写，解决语义鸿沟。第二步是两阶段检索，向量召回Top-K之后，用[[Cross-Encoder]]做精排，这一步能显著提升精度，但延迟也高，所以K不能设太大。第三步是缓存，热门Query的向量结果和Embedding结果都缓存起来，能挡住大部分重复请求。
其实还有一个经常被忽略的点，评估。线上效果好不好，光看Recall@K不够，还要关注用户实际点击行为和业务指标。比如在客服场景，用户搜了之后有没有解决问题，比召回率更重要。这个评估体系怎么搭，我觉得比检索本身更考验工程能力。
所以整体来说，我会把[[向量数据库]]看成一个系统工程，每个环节都有trade-off，没有银弹。更倾向根据业务场景做组合方案，而不是套一个固定模板。