向量数据库的工作流程有哪些？请简述下
- 标签：AI、大模型、RAG、向量数据库
🏛 业务架构师
向量数据库的工作流程分"离线建库"和"在线查询"两段，对应业务的"知识管理"和"知识消费"：
离线写入流程：
- 数据接入：原始文档经解析、清洗、切块；
- 向量化：每个分块送 Embedding 模型生成向量；
- 写入：向量+原文+元数据（来源、部门、时间、权限）一起入库；
- 建索引：后台构建 HNSW/IVF 索引（异步过程，期间可查可写）。
在线查询流程：
- Query 向量化：用户提问用同一 Embedding 模型转向量（模型必须一致，否则语义空间对不上）；
- 过滤下推：先按元数据过滤（权限、时效）缩小候选集；
- ANN 检索：在索引中找 Top-K 相近向量，返回距离分数；
- 结果融合：与关键词检索等通道的结果合并、去重、重排；
- 交付：把 top 分块送入 LLM 生成答案。
业务视角：这套流程里最容易被忽视的是"元数据过滤"和"增量更新"——前者是权限合规的命门，后者决定知识库是"活资产"还是三个月后的"过期黄页"。选型评估时这两点要优先于跑分。
🏗 系统架构师
向量数据库的工作流程我分写入路径和查询路径——这是理解任何存储系统的标准切法：
写入路径（离线建库）：
- 文档解析 → 分块 → Embedding 模型向量化 → INSERT（向量 + 标量元数据 + 主键）；
- 写 WAL 保证持久性 → 异步构建/更新 ANN 索引（HNSW 插图或 IVF 重新分桶）→ 元数据建标量索引；
- 特性：多数向量库是最终一致——写成功到索引可查有毫秒~秒级可见性延迟，实时性敏感场景要确认这个窗口。
查询路径（在线检索）：
- query 向量化（同模型同度量）→ 带过滤条件的检索请求；
- 执行计划：标量 pre-filter 先裁剪候选空间（走标量索引）→ ANN 索引搜 Top-K（HNSW 贪心图遍历/IVF 桶扫描）→ 距离精算与重排 → 返回 ID + 距离 + 元数据；
- 高级特性：多路（混合检索）在融合层 RRF 合并。
架构师视角的三个考点：一是删除通常是标记式（tombstone），后台 compaction 才物理回收，高频增删场景要盯索引膨胀；二是 pre-filter 与 post-filter 的实现差异决定过滤检索性能（过滤后候选太少时有些库会退化为暴力搜）；三是副本与分片——按向量 ID 哈希分片，查询扇出到所有分片归并，规模上来后分片数影响 P99。
💻 全栈开发专家
向量数据库的工作流程分四段：
1. 写入（Upsert）：文档切块 → Embedding 模型批量向量化 → (id, vector, metadata, 原文) upsert 进 collection。用 upsert 而非 insert，靠业务主键（doc_id+chunk_id）保证幂等，重复导入不产生脏数据。
2. 索引构建：写入后台异步构建 ANN 索引（HNSW/IVF）。注意「写入即可查」和「索引就绪」之间有延迟窗口，大量灌数据时搜索性能会抖动——生产上灌库走低峰+分批。
3. 查询：query → 向量化 → ANN 搜索取候选（top 100~200）→ 标量过滤（metadata filter）→ 距离重排 → 返回 top K 及 score。
4. 更新与删除：文档更新 = 新 chunk 入库 + 旧 chunk 按 doc_id 删除（很多库支持 delete by filter 表达式），避免新旧并存产生「幽灵答案」。
离线: docs → parse → chunk → embed → upsert(+metadata)
在线: query → embed → ANN search → filter → top-k → rerank → LLM运维要点：监控索引内存与 segment 合并；备份要连同 collection schema 一起；冷热分层——过期数据下线到对象存储，重建时再灌。这条流水线任何一个环节的元数据不一致（比如 filter 字段名对不上），排查起来都极费劲，schema 要有迁移脚本管理。