一、项目背景

我们当时面对的是 RAG 知识库从"几十万条"向"上千万条"规模扩张的过程。早期知识库体量小，直接用朴素暴力检索（flat）就能在毫秒内返回，团队也没太在意向量库选型。但随着某金融机构的合规文档、某制造企业的设备手册陆续接入，切片后的向量条目迅速突破千万级，问题集中爆发。

一是检索变慢。暴力检索的复杂度是 O(N·d)，条目上千万后单次查询从几毫秒涨到数百毫秒，高峰期甚至秒级，前端问答明显卡顿，用户体验直线下滑。二是召回质量下降。为了压延迟我们草率切到近似检索却没调参，召回率@10 从 0.95 掉到 0.7 以下，答案开始出现"答非所问"，合规场景下还可能漏掉关键条款，风险不可接受。三是写入和查询互相打架：知识库白天高频增量更新，构建索引会短暂锁表或占用大量 CPU，查询延迟同步抖动，监控曲线上能看到规律的毛刺。四是维度与成本的连锁反应：embedding 维度从 384 升到 768 后，向量体积翻倍，内存与磁盘开销同步放大，逼着我们重新审视索引选型而非一味加机器。

我们意识到，向量库不是"存进去查出来"这么简单，它是一个需要像传统数据库一样做选型、建索引、调参数、做读写隔离的工程组件。从索引算法的数学性质，到建表参数、查询期参数、读写拓扑，每个环节都有可量化的权衡。这是我们这个项目里复盘价值最高的一块，也是后续所有 RAG 接入都能快速复用的方法论来源。

二、落地场景

我们采用的 X 技术平台在向量数据库层同时支持 Milvus 与 pgvector 两种形态，便于按场景取舍。落地的检索场景大致三类：

一是高精度文档问答，要求召回率优先、延迟容忍在百毫秒级；二是实时客服的语义召回，要求延迟优先、可接受略低召回；三是混合检索，向量召回叠加关键词 BM25 做融合重排。我们针对不同的集合（collection）规模与查询 SLA，分别选用了 HNSW、IVF 类索引和 pgvector 的 ivfflat/hnsw，并在 RAG 流水线的"检索重排"环节做统一封装，让上层应用不感知底层索引差异。

三、关键技术挑战与解决思路

挑战一：索引类型选型（HNSW vs IVF）。 两者是近似近邻检索里最常被比较的两类，数学性质差异直接决定工程取舍。HNSW 基于多层可导航小世界图，查询走图上的贪心搜索，速度极快、召回高，但构建慢、内存占用大，且图结构对增量写入不够友好，适合查询密集、更新不频繁的热数据；IVF 类（如 ivfflat、IVF_PQ）先把向量聚类分桶，查询时只看最近若干桶，内存友好、构建快，IVF_PQ 还能用乘积量化把向量压到原来的几分之一，但召回对 nprobe 参数高度敏感，桶数 nlist 与簇均衡也影响质量。我们在 Milvus 中对千万级热知识库用 HNSW，对可容忍秒级延迟的冷数据用 IVF_PQ 压缩以省成本；pgvector 侧则按表规模在 ivfflat 与 hnsw 间切换，并保持 PostgreSQL 既有的备份与权限体系，运维成本最低。

-- pgvector 建 hnsw 索引示意（向量维度 768）
CREATE INDEX ON docs_embedding
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- 查询时调整 ef 以权衡召回与延迟
SET hnsw.ef_search = 40;

挑战二：维度与召回率权衡。 高维 embedding（如 1024 维）表达力强但距离区分度下降，近似检索更易误召回；降维能提速但损语义。我们的做法是：保持原始维度，用 ef_search/nprobe 这类查询期参数来控制召回—延迟跷跷板，而不是改维度。例如 HNSW 的 ef_search 从 20 提到 60，召回率@10 从 0.82 提升到 0.93，延迟只增加约 15ms，性价比远高于降维。

案例片段（已脱敏）：某制造企业设备手册库（约 1200 万条，768 维）最初用 ivfflat 且 nlist=100、nprobe=1，召回率@10 仅 0.68；调整为 HNSW（m=16, ef_construction=64）并将查询 ef_search=40 后，召回率@10 提升至 0.94，P95 检索延迟由 310ms 降至 45ms。

挑战三：写入与查询隔离。 知识库增量更新会触发索引重建或段合并，HNSW 增量写虽快但仍占 CPU，IVF 的 nlist 重聚类更是重量操作。我们把"写入通道"和"查询通道"在实例层面隔离：写节点负责 ingest 与索引构建，构建完成后以只读副本方式同步给查询节点；pgvector 侧则用单独的只读从库承接查询，主库只做写入，避免建索引的锁影响在线查询。再配合批量落库（每批 2000–5000 条）替代单条 insert，并错峰在低峰期做全量 rebuild，写入吞吐提升明显且查询延迟不再抖动。我们还对写入做了幂等去重，防止同一文档因多次同步产生重复向量、污染召回结果。

四、效果数据

以下为脱敏示意值，基于某客户约 1200 万条、768 维向量的知识库集群：

案例片段（已脱敏）：Grafana 监控看板文字摘要——索引切换后，检索 P95 曲线由改造前的"白天 200–310ms 规律性毛刺"变为"全天平稳 40–50ms"；召回采样任务（每日随机抽取 500 条 query 比对人工标注）的命中率由 0.68 升至 0.94；写入高峰期的查询延迟抖动（P99/P50）由约 8.5 倍收窄到约 2.1 倍。

五、可复用经验总结

第一，召回率与延迟是跷跷板，先按业务 SLA 定目标，再选索引，不要盲目追求"最快"。第二，查询期参数（ef_search、nprobe）是性价比最高的调优手段，优先在不动数据的前提下调它。第三，规模与更新频率决定选型：千万级热数据用 HNSW，冷数据或大表用 IVF_PQ/ivfflat 压缩；pgvector 适合已用 PostgreSQL 的团队做轻量起步。第四，务必做读写隔离，把索引构建开销从查询路径上剥离，否则高峰期必然抖动。第五，把索引参数和维度作为"可观测、可回归"的配置项管理，配合 Prometheus 监控检索延迟与召回采样，避免凭感觉调参。

这个项目让我们把向量库真正当成了数据库来运维，而非一个黑盒插件。后续新接入的知识库只需套用这套选型矩阵与参数模板，从选型到上线基本可以在一天内完成。