论向量数据库在项目中的应用
(1)概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
(2)简要概述向量数据库的特点和原理，以及向量数据库的优缺点。
(3)结合你的项目，阐述你如何在项目中使用向量数据库。
摘要
2025年，我所在公司启动了“企业智能知识与学习平台”建设项目，主要面向研发、售后和技术支持人员，对产品说明书、设计文档、故障记录、培训资料等非结构化知识进行统一管理，并提供自然语言检索、智能问答和学习辅助功能。我在项目中担任系统架构师，负责总体架构设计、技术选型、核心模块设计及关键技术问题解决。项目初期采用传统关键词检索，但实际使用中经常出现用户表达与文档用词不一致，导致相关资料无法准确召回。为解决该问题，我在系统中引入向量数据库Milvus，通过Embedding模型将文档片段和用户问题转换为高维向量，并结合元数据过滤、向量召回、重排序和RAG技术构建语义检索链路。同时使用PostgreSQL管理业务数据，MinIO保存原始文件。系统上线后，相关文档进入前十条检索结果的比例由约68%提升到91%，较好地解决了企业非结构化知识检索困难的问题。本文结合项目实践，论述向量数据库的原理、优缺点及具体应用。
一、项目概况及本人承担的主要工作
随着公司产品和项目数量增加，内部积累了大量PDF说明书、Word技术文档、故障记录、接口文档和培训材料。这些资料过去主要依赖文件目录和关键词查找。研发和售后人员往往只记得问题含义，却不知道对应文档名称，需要翻阅大量资料才能找到类似案例。
因此，公司决定建设企业智能知识与学习平台，将分散的技术资料统一管理，并利用大语言模型提供知识问答和辅助学习能力。系统采用前后端分离架构，后端按业务划分为用户权限、文档管理、知识处理、向量检索和智能问答等模块。我作为系统架构师，主要负责需求分析、总体架构设计、数据存储方案、向量检索方案以及RAG流程设计，并组织性能与准确率测试。
在存储层，我采用PostgreSQL保存用户、部门、文档、权限和版本等结构化数据，MinIO保存原始文件，Redis用于热点数据缓存，Milvus负责文档向量的存储与相似度检索。该方案使传统业务数据和语义检索数据各自使用适合的存储技术，避免为了使用向量数据库而替代原有关系型数据库。
二、向量数据库的特点、原理及优缺点
向量数据库是面向高维向量进行存储、索引和相似度查询的数据库。传统关系型数据库擅长通过字段值进行精确匹配、条件过滤和关联查询，而向量数据库更关注数据之间“是否相似”。
在自然语言处理中，可通过Embedding模型将一段文本映射成数百或数千维浮点向量。语义相近的文本，其向量在高维空间中的距离通常也较近。因此，当用户输入“设备升温速度很慢”时，即使知识库中的原文是“温控模块加热异常排查”，系统仍可能通过向量距离找到该内容。常用相似度计算方法包括余弦相似度、欧氏距离和内积。
当数据规模较小时，可以将查询向量与所有向量逐一计算距离；但当向量达到几十万甚至数百万条时，全量计算成本很高。因此向量数据库通常采用ANN近似最近邻搜索，通过HNSW、IVF等索引结构快速缩小候选范围，在性能和召回率之间取得平衡。
向量数据库的优点主要有三点：第一，突破关键词字面匹配限制，实现语义检索；第二，文本、图片、音频等非结构化数据都可向量化，适合统一相似度检索；第三，专业向量索引适合大规模高维数据查询，并可通过分片扩容提高处理能力。
其不足也比较明显。首先，向量本身缺乏直观可解释性，错误检索不容易像SQL条件那样直接定位原因；其次，高维浮点向量和索引会占用较多存储及内存资源；再次，不同Embedding模型的向量空间通常不能直接混用，更换模型往往需要重新生成已有向量；最后，向量数据库擅长相似度检索，但对用户编号、产品型号、权限、时间范围等精确条件并不具有天然优势。因此本项目没有用向量数据库替代关系型数据库，而是采用两者协同的混合存储架构。
三、向量数据库在项目中的具体应用
1. 建立文档向量化处理流程
用户上传PDF或Word文件后，系统首先将原始文件保存到MinIO，同时在PostgreSQL中记录文件名称、上传者、所属部门、文档分类、版本和权限范围等信息。随后由知识处理服务异步执行正文提取、清洗、切片、向量化和入库。
项目初期，我们曾按照固定1000字对文档机械切片，但测试发现一些完整的故障原因和处理步骤被拆分到两个片段中，导致召回内容缺少上下文。对此，我将切片策略调整为“标题层级+自然段+最大长度”的混合方式，优先保持章节和自然段完整，超过长度时再分割，并保留约15%的上下文重叠。这样既控制了单个知识块长度，又尽量保证语义完整。
切片后，系统调用Embedding模型将文本转换为向量写入Milvus，并同时保存文档ID、切片ID、知识分类、产品型号、部门和权限标签等元数据，为后续过滤查询提供依据。
2. 构建向量检索与RAG问答链路
用户提出问题后，系统首先使用与知识库相同的Embedding模型对问题进行向量化，然后在Milvus中检索语义最相近的知识片段。
例如用户输入“PCR设备运行时温度一直上不去怎么办”，知识库中可能没有完全一致的表述，但存在“温控模块升温异常排查方法”。传统关键词检索可能因为词语不一致而遗漏，而向量检索能够根据语义相似度将其召回。
在架构设计中，我没有直接把相似度最高的几条结果交给大语言模型，而是设计了“粗召回、业务过滤、重排序、上下文生成”四个步骤。Milvus首先召回Top20候选片段；随后根据用户部门、文档权限、产品型号等元数据过滤无权访问或业务不匹配的数据；再使用重排序模型对候选内容进行二次相关性排序；最后选取5至8个最相关片段组成上下文交给大语言模型生成答案。
通过这种方式，向量数据库负责快速寻找“可能相关”的内容，重排序模型进一步判断“真正相关”的内容，在速度和准确率之间取得平衡。系统同时返回来源文档和章节；若没有可靠知识片段，则提示依据不足，避免大语言模型脱离企业资料生成结论。
3. 解决权限隔离问题
企业知识库中不同部门和项目人员的资料权限不同。如果只按向量相似度查询，可能检索出用户无权访问的技术资料。
因此，我在向量记录中保存部门、文档级别和授权范围等元数据，并在检索阶段根据当前登录用户的权限生成过滤条件。用户权限本身仍由PostgreSQL统一维护，向量数据库只保存用于检索过滤的必要标签。这样既避免在Milvus中重复维护完整用户体系，又能够在召回阶段提前过滤无权限内容，减少敏感信息进入大语言模型上下文的风险。
4. 解决文档更新与数据一致性问题
向量数据不是一次生成后永久不变。技术文档经常修订，如果业务数据库中的文档已经更新，而向量数据库仍保留旧版本，就会导致模型引用过期资料。
对此，我为每份文档设计版本号和处理状态。用户上传或修改文件后，请求只负责完成文件保存和任务创建，后续的解析、切片、Embedding和向量写入由后台任务异步处理。新版本全部生成成功后，再将旧版本向量标记失效并删除，避免处理中途出现知识缺失。
同时，我为向量记录增加Embedding模型版本字段。当模型升级时，新旧向量存放在不同集合中，通过后台任务逐步重建知识向量，重建完成后再切换在线检索集合，从而减少模型升级对系统服务的影响。
5. 平衡准确率与查询性能
项目测试阶段发现，召回数量越多，找到正确内容的概率通常越高，但候选内容过多会增加重排序和大语言模型处理时间，还可能引入无关信息。
为此，我组织团队建立了约600条真实业务问题测试集，对不同切片长度、TopK、相似度阈值和索引参数进行对比。最终采用Milvus召回20条、重排序后保留5至8条的方案，并对高频问题使用Redis缓存检索结果。
在约8万余个知识切片规模下，大部分向量检索可以在百毫秒级完成。测试结果显示，相关资料进入前十条结果的比例由原关键词方案的约68%提升到91%，达到了项目预期。
四、项目实施效果与总结
系统上线后，研发和售后人员可以直接通过自然语言描述问题，不再需要准确记住文件名称或专业术语。向量数据库使企业文档检索从“按字找资料”转变为“按语义找知识”，并为大语言模型提供了更加准确、可追溯的企业上下文。
通过本项目我认识到，向量数据库的价值并不只是保存Embedding，而是为大规模非结构化数据建立语义检索能力。但它并不能替代传统数据库。实际系统仍需要关系型数据库负责业务关系和精确查询，对象存储负责原始文件，向量数据库负责语义召回，再结合重排序和大语言模型形成完整RAG链路。
系统架构设计的关键不是单纯追求新技术，而是根据业务特点，在检索准确率、性能、数据一致性、安全性和维护成本之间进行合理权衡。通过本项目的实施，我进一步加深了对向量数据库及智能知识系统架构设计的理解，也为公司后续建设智能化知识服务平台积累了实践经验。