论向量数据库在项目中的应用
(1)概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
(2)简要概述向量数据库的特点和原理，以及向量数据库的优缺点。
(3)结合你的项目，阐述你如何在项目中使用向量数据库。
摘要
2025年，我所在公司启动了”智能技术学习与知识服务平台”建设项目。
该平台主要面向企业内部研发、售后及技术人员，对产品说明书、研发文档、技术规范、培训资料以及历史项目文档进行统一管理，并利用大语言模型提供智能问答、资料检索和学习路径生成等功能。
我在该项目中担任系统架构师，主要负责需求分析、总体架构设计、技术选型、核心模块设计以及关键技术问题解决。
项目建设过程中，我们发现传统关系型数据库基于关键词的检索方式难以准确理解用户问题的语义。例如，用户搜索”设备温度过高如何处理”，而知识库中的文档标题可能是”仪器散热异常故障排查”，二者虽然语义相近，但关键词并不完全一致。
为提高知识检索准确率，并为大语言模型提供高质量上下文，我在系统中引入向量数据库，将文档内容转换为高维向量，并通过向量相似度实现语义检索。
在技术实现上，我们采用 Milvus 作为向量数据库，PostgreSQL 保存业务数据和文档元数据，MinIO 保存原始文件，并通过 Embedding 模型完成文本向量化。同时结合文档切片、元数据过滤、向量召回、重排序和权限控制等机制构建完整的 RAG 检索链路。
系统上线后，知识检索从过去的关键词匹配转变为语义检索。在内部测试数据集上，相关资料进入前十条检索结果的比例由约 68% 提高到 91%，同时大幅降低了大语言模型回答与企业知识无关问题时产生错误内容的概率。
实践证明，在非结构化知识规模不断扩大的情况下，向量数据库能够有效提升语义检索能力，但在索引维护、存储成本、结果可解释性和数据一致性方面也存在一定不足，需要结合传统数据库共同使用。
一、项目概况及本人承担的主要工作
随着公司产品种类逐渐增加，研发、生产和售后过程中产生了大量技术资料。
这些资料包括 PDF 说明书、Word 设计文档、故障处理记录、测试报告、接口文档和培训材料等。过去主要存放在文件服务器以及员工个人电脑中，虽然可以按照目录进行分类，但随着资料数量增长，员工越来越难快速找到需要的信息。
例如，售后人员遇到仪器通信异常时，往往需要在大量历史故障记录中查找解决方法；研发人员学习一个新模块时，也需要人工寻找相关设计文档、基础知识和前置技术资料。
因此，公司决定建设一套智能技术学习与知识服务平台，实现文档统一管理、全文检索、智能问答以及根据员工知识基础自动生成学习路径等功能。
我在项目中担任系统架构师，负责系统总体技术方案设计。经过分析，我将系统划分为以下模块：
- 用户与权限服务
- 文档管理服务
- 知识处理服务
- 向量检索服务
- 智能问答服务
- 学习路径服务
系统采用前后端分离架构。后端采用 FastAPI 实现服务接口，PostgreSQL 保存用户、文档、权限等结构化业务数据，MinIO 保存 PDF、Word 等原始文件，Redis 用于缓存热点查询结果，Milvus 负责保存文档 Embedding 向量。
在项目设计阶段，我重点负责向量检索架构、文档知识化处理流程以及大语言模型与企业知识库之间的 RAG 检索增强方案，并解决了文档切片、语义召回准确率、查询性能、知识更新以及用户权限隔离等问题。
二、向量数据库的特点、原理及优缺点
向量数据库是一种面向高维向量数据进行存储、索引和相似度检索的数据库。
它与传统关系型数据库最大的区别在于：传统数据库通常根据字段值进行精确匹配或范围查询，而向量数据库主要根据两个向量之间的距离判断数据之间的相似程度。
在自然语言处理场景中，可以使用 Embedding 模型将一句话、一段文字甚至一张图片映射成一个高维向量。例如，一段文本可能被转换成 1024 维浮点数组。
语义相似的文本在向量空间中的距离通常较近。因此，即使两段文字没有使用相同关键词，也可以通过计算余弦相似度、欧氏距离或内积找到语义相近的内容。
但是，如果每次查询都将查询向量与数据库中所有向量逐一比较，当向量数量达到几十万甚至数百万时，计算成本会迅速增加。
因此向量数据库通常采用近似最近邻搜索（ANN）技术，并通过 HNSW、IVF 等索引结构缩小检索范围，在检索精度和查询性能之间取得平衡。
2.1 向量数据库的优点
向量数据库具有三个比较突出的优点。
第一，能够进行语义检索。
传统关键词检索依赖字面匹配，而向量检索能够发现”仪器无法联网”和”设备网络连接失败”等表达不同但含义接近的内容，非常适合知识库、智能客服和 RAG 系统。
第二，能够处理大量非结构化数据。
文本、图片、音频经过特征提取后都可以表示为向量，因此向量数据库能够建立跨文档甚至多模态的相似性检索能力。
第三，适合大规模高维数据检索。
成熟的向量数据库能够建立专用向量索引，并支持分片、扩容和并行查询，比直接在普通关系型数据库中遍历计算大量向量更加高效。
2.2 向量数据库的不足
但向量数据库也存在不足。
一是，向量本身缺乏直观可解释性。
当检索结果不准确时，很难像 SQL 查询一样直接观察哪个条件出现了问题。
二是，存储和内存开销较大。
Embedding 向量会占用较大的存储空间，同时建立索引还会进一步消耗内存和磁盘资源。
三是，模型更换需要重新向量化。
不同 Embedding 模型生成的向量空间通常不能直接混用，一旦更换模型，已有知识数据往往需要重新向量化。
四是，不适合精确条件查询。
向量检索擅长寻找”相似内容”，但对于用户编号、产品型号、时间范围等精确条件查询并不适合。
因此我认为，向量数据库并不是传统关系型数据库的替代品，而应该作为数据库体系中的一种补充。
在本项目中，我们采用”PostgreSQL + Milvus“的组合方式，让关系型数据库负责业务关系和精确查询，让向量数据库负责语义检索。
三、向量数据库在项目中的具体应用
3.1 建立文档向量化处理流程
用户上传 PDF、Word 等文件后，系统首先将原始文件保存到 MinIO，并在 PostgreSQL 中记录文件名称、上传者、部门、知识分类、权限范围和文件版本等信息。
知识处理服务随后提取文档正文。由于一份文档可能包含数万字，而 Embedding 模型和大语言模型都有上下文长度限制，因此不能简单地把整个文档生成一个向量。
项目初期我们曾按照固定 1000 字进行机械切片，但测试发现，一些操作步骤和故障解决方案被切割到两个不同片段中，导致检索出的内容不完整。
为解决这一问题，我设计了”标题层级 + 自然段 + 最大长度“的混合切片方式：
- 优先保持章节和段落完整
- 仅当内容超过限制时再按照一定长度切分
- 保留约 15% 的上下文重叠
切片完成后，通过 Embedding 模型将每个文本块转换成向量，并写入 Milvus。
每条向量记录同时保存文档 ID、切片 ID、知识分类、部门和权限标识等元数据，使后续查询不仅可以按照向量相似度搜索，还可以进行业务条件过滤。
3.2 构建语义检索与 RAG 问答流程
用户提出问题后，系统首先对问题进行向量化。
例如用户输入：”PCR 设备运行过程中温度一直上不去怎么办？”
知识库中可能不存在完全相同的句子，但存在”温控模块升温异常排查方法”等内容。
传统关键词搜索容易遗漏，而向量检索能够根据语义相似度将相关内容召回。
我设计的查询流程并不是简单地取相似度最高的一条记录，而是：
- 首先从 Milvus 中召回相似度较高的 20 个候选文本块
- 然后根据用户所在部门、文档权限、产品型号等元数据进行过滤
- 再通过重排序模型进行二次排序
- 最终选择相关性最高的 5 至 8 个文本块作为上下文提交给大语言模型
这种”向量粗召回 + 业务过滤 + 重排序“的方式，在保证查询速度的同时明显提高了最终检索结果的准确率。
为了避免模型脱离企业知识自行生成答案，我还要求问答服务：
- 优先依据检索出的知识片段进行回答
- 返回引用文档名称及章节信息
- 若没有检索到足够相关的知识，则提示用户当前知识库中缺少可靠依据，而不是让模型强行生成答案
3.3 解决知识更新和数据一致性问题
向量数据并不是生成后永久不变。项目运行过程中，技术文档会不断修改，因此我们必须解决业务数据库、对象存储和向量数据库之间的一致性问题。
我没有采用用户上传文件后同步执行全部向量化任务。
因为一个几十页的 PDF 可能需要经过解析、切片、Embedding 和索引写入等多个步骤，处理时间较长。如果在 HTTP 请求中同步完成，不但用户等待时间过长，而且某一步骤失败还可能导致整个请求超时。
因此我将知识处理设计为异步任务：
- 文件上传成功后立即返回任务编号
- 后台按照”文件解析 — 文本切片 — 向量生成 — Milvus 写入 — 索引更新”的流程进行处理
- 并记录各阶段状态
文档发生修改时，通过文档版本号识别旧知识块，新的向量数据写入成功后再删除旧版本数据，从而避免更新过程中出现知识短暂缺失。
如果 Embedding 模型发生更换，则通过模型版本字段区分不同向量集合，并通过后台任务逐步重新生成向量，避免一次性重建整个知识库影响在线服务。
3.4 解决检索准确率与性能之间的矛盾
项目测试阶段，我们发现增加召回数量虽然能够提高找到正确答案的概率，但召回过多内容又会增加重排序和大语言模型处理时间，同时无关信息过多还可能干扰最终回答。
针对这一问题，我组织团队建立了一套包含约 600 条真实业务问题的测试集，通过调整向量索引参数、TopK 数量、相似度阈值以及文档切片大小进行对比测试。
最终系统采用先召回 20 条候选记录，再重排序保留 5 至 8 条的方案。
对于频繁查询的问题，我们同时使用 Redis 缓存检索结果，减少 Embedding 计算和向量数据库访问次数。
经过优化，在现有约 8 万余个知识切片的数据规模下，大部分向量检索可以在百毫秒级完成，满足内部知识问答场景的使用要求。
四、项目实施效果与总结
系统上线后，研发和售后人员不再需要完全依赖文件名称和目录结构查找资料，可以直接使用自然语言描述问题。
我们使用真实业务问题进行了上线前后对比测试：
- 在传统关键词检索方案中，相关文档进入前十条结果的比例约为 68%
- 采用向量数据库并结合重排序机制后，该比例提高到了约 91%
同时，通过 RAG 方式将检索到的企业知识作为大语言模型上下文后，模型回答的专业性和可追溯性也有明显提高。
通过本项目，我深刻认识到：向量数据库最重要的价值并不只是”保存 Embedding”，而是为非结构化知识建立一种基于语义关系的检索能力。
同时，向量数据库也并不能解决所有问题。实际架构设计中仍然需要：
- 关系型数据库负责结构化业务数据
- 对象存储保存原始文件
- 向量数据库完成语义检索
- 结合 Embedding 模型、大语言模型和重排序技术形成完整的知识服务体系
在系统架构设计过程中，只有根据实际业务特点合理选择技术，并在检索准确率、性能、成本、数据一致性和可维护性之间进行权衡，才能真正发挥向量数据库的价值。
这也是我在本项目实施过程中获得的最重要经验。