摘要
随着大模型技术快速落地，RAG 检索增强生成、语义检索类业务需求持续增多。传统关系型数据库擅长精确匹配与事务处理，无法高效完成高维向量相似度检索。向量数据库专门面向高维向量存储、近似最近邻检索场景，为非结构化数据的语义检索提供底层支撑。本文结合我参与的企业内部知识库智能问答平台项目，论述向量数据库的原理、关键技术，介绍向量库选型、数据管道设计、系统集成方案，分析落地遇到的问题与解决办法，并总结向量数据库的适用边界。在项目中我担任系统架构师，负责整体架构设计、向量检索模块方案选型与落地优化，最终平台实现企业文档智能问答，显著提升内部资料检索效率。
关键词：向量数据库；RAG；近似最近邻；Embedding；语义检索
一、项目概述
我所在公司是一家面向政企的软件服务商，企业内部沉淀大量 PDF 手册、需求文档、运维日志、会议纪要等非结构化文档。原有文档系统只能做关键词检索，存在明显缺陷：关键词匹配无法理解语义，同义词、转述提问检索不到结果；用户提问口语化时检索命中率低；大模型直接基于全部文档做上下文，容易产生幻觉，且上下文窗口有限。因此我们启动企业知识库智能问答平台项目，基于 RAG 架构，将文档转为向量存入向量数据库，实现语义检索 + 大模型问答。
我作为系统架构师，承担的主要工作：需求分析、整体技术架构设计、向量数据库选型、文档处理数据管道设计、向量检索模块开发集成、性能调优与质量验证。平台分为文档接入层、文本切片与向量化层、向量存储检索层、大模型问答服务层、前端交互层。用户输入问题，系统将问题转为向量，在向量库检索相似文档片段，把检索结果作为上下文送入大模型生成答案。
二、向量数据库基本原理、关键技术，优缺点与适用边界
向量数据库核心目标：存储高维 Embedding 向量，支持快速相似度检索。文本、图片等非结构化数据，通过 Embedding 模型编码为固定维度高维向量；语义相近的原始内容，对应的高维向量在向量空间距离更近。向量数据库不再做精确等值查询，而是根据向量距离，查找与查询向量最相似的 Top-K 向量，即近似最近邻检索 ANN。
关键技术
- 向量 Embedding：将文本、图片等非结构化数据映射为高维稠密向量，保留原始数据语义特征，是向量入库的前置步骤。
- ANN 近似最近邻索引。暴力遍历计算距离准确率最高，但海量向量下速度极慢。向量数据库采用索引结构加速检索，常见：IVF 倒排索引、HNSW 层次导航小世界索引、FAISS 的 Flat/LSH 索引。牺牲极小检索召回率，换取上万倍检索性能提升。
- 相似度度量：常用三种。欧氏距离、余弦相似度、内积。文本语义检索场景，一般选用余弦相似度。
- 元数据过滤：向量除向量本体外，附带文档 ID、来源、时间、文档类型等元数据。检索时可先按元数据过滤，再做向量检索，缩小检索范围。
- 召回与重排：向量库粗召回 TopN 候选片段，再通过重排模型做精细化排序，提升最终结果相关性。
优点
- 支持语义层面相似检索，突破关键词检索局限，理解同义、转述类查询；
- ANN 索引可在百万 / 千万级向量规模下，实现毫秒级向量检索；
- 原生支持向量增删改查，支持向量生命周期管理，适配 RAG、图片检索、推荐场景；
- 支持向量 + 元数据联合过滤，可做业务条件筛选。
缺点
- 属于近似检索，存在召回率损耗，无法做到 100% 精确检索；
- 高维向量存储开销大，内存占用高，大规模场景硬件成本高；
- 不擅长强事务、复杂多表关联查询，不适合替代传统关系数据库；
- 检索效果高度依赖 Embedding 模型质量，向量质量差则检索结果无效。
适用边界
✅适合场景：RAG 知识库问答、图片检索、音视频检索、内容推荐、日志语义检索； ❌不适合场景：强事务、精确等值查询、复杂关联统计、传统业务主数据存储。
三、项目中向量数据库选型、数据管道、集成方案，问题与解决，应用效果
1. 向量数据库选型
候选方案：FAISS、Milvus、Chroma、Qdrant。
- FAISS：仅检索库，无独立服务，需要自己封装服务、持久化、分布式能力，运维成本高；
- Chroma：轻量，适合原型验证，不适合生产大规模数据；
- Milvus：分布式，支持海量向量，运维复杂，资源开销大；
- Qdrant：轻量高性能，支持 HNSW 索引，支持元数据过滤，部署简单，支持单机 / 集群，适合企业知识库百万级向量规模。
本项目文档总量预估百万级文本切片向量，并发量中等，最终选型Qdrant。
2. 数据管道设计
完整数据管道：文档采集 → 文档解析 → 文本清洗 → 文本分块切片 → Embedding 生成向量 → 向量入库。
- 文档采集：对接企业网盘、文件服务，定时抓取新增 PDF、Word、Markdown 文档；
- 文档解析：使用 PDF 解析库提取文本，去除页眉页脚、空白、乱码；
- 文本清洗：过滤无效字符，去除重复段落；
- 文本切片：按固定长度 + 重叠窗口做文本分块，避免切断语义，重叠保证上下文不丢失；
- Embedding：调用 BGE 文本嵌入模型，把每一段文本生成 768 维向量；
- 写入 Qdrant：向量 + 元数据（文档名称、来源、章节、时间）一并存入向量集合。
查询阶段管道：用户提问 → 问题文本清洗 → Embedding 编码为查询向量 → Qdrant 执行 ANN 检索 + 元数据过滤，召回 Top5 相关片段 → 重排模型排序 → 把片段作为上下文交给大模型生成答案。
3. 嵌入现有系统方案
原有系统基于 SpringBoot 后端 + Vue 前端。向量库独立部署为 Qdrant 服务，通过 REST API 与业务后端交互。业务后端不直接存储向量，只管理文档元数据。新增独立向量服务模块，封装 Embedding 调用、向量入库、检索接口。业务系统与向量服务之间解耦，通过 HTTP 调用。文档增量更新采用消息队列，文档变更触发消息，异步执行切片、向量化、向量库更新，避免同步阻塞主业务。
4. 实施遇到的问题以及解决办法
问题 1：文本切片不合理，过长片段语义混杂，过短片段缺少上下文，检索结果相关性差。 解决：不使用固定长度硬切。采用语义感知切片，在段落、章节边界切分，设置切片重叠窗口。同时做切片质量评估，对长文档自动拆分，提升召回片段质量。
问题 2：向量检索召回率不足，部分相关文档检索不到。 解决：①调优 HNSW 索引参数，增加 ef 参数提升检索候选数量；②优化 Embedding 模型，替换为领域微调后的 BGE 模型，适配企业运维文档专业术语；③增加多路召回策略，向量检索 + 关键词检索混合召回，融合结果。
问题 3：新增文档入库慢，大批量文档向量化、入库耗时久，并发写入压力大。 解决：异步化处理，使用消息队列做任务解耦；向量化任务多实例并行处理；批量写入向量，减少单次网络请求；定时合并索引，避免实时建索引消耗大量资源。
问题 4：向量库内存占用高，Qdrant 在百万向量场景内存压力大。 解决：开启向量量化，使用标量量化，降低向量存储维度与内存占用；冷热分离，低频访问文档向量存入磁盘索引，高频向量驻留内存。
5. 应用效果
项目上线后，企业内部文档问答系统正式投入使用。相比原来关键词检索，问答命中率从 42% 提升至 85%；用户查找资料平均耗时从 15 分钟缩短至 2 分钟；大模型幻觉问题明显降低，答案都附带原文来源片段，支持溯源。向量检索平均响应时间控制在 80ms 以内，满足业务并发需求。
四、总结
向量数据库作为专门面向高维向量存储与相似度检索的数据库，是 RAG、语义检索系统的核心底座。它依靠 Embedding、ANN 索引、相似度计算等技术，解决传统数据库无法处理的语义检索问题，但并不适合替代关系数据库。在本企业知识库项目中，基于 Qdrant 搭建向量检索链路，通过优化切片策略、Embedding 模型、索引参数，解决召回率、性能、资源开销等问题，落地了 RAG 智能问答平台。
在项目实践中我也认识到，向量数据库不是万能银弹。检索效果高度依赖文本切片质量与 Embedding 模型。后续优化方向：构建多模态向量能力，支持图片、表格内容向量化检索；优化向量库分布式集群，支撑千万级向量规模。向量数据库将在智能问答、智能推荐等场景持续发挥价值，在架构设计中需要合理评估业务场景，把握适用边界，与传统数据库互补使用。
