向量库要不要单独上：先看数据量和检索需求

搭建企业知识库时，很多方案默认要引入一套专门的向量数据库。对数据量大、检索要求高的项目这是对的，但对多数企业的内部文档规模来说，它可能只是多了一套需要运维的组件。

先估算规模

把文档总字数除以单块长度，得到块数。几千到几万块的量级，关系数据库的向量扩展通常完全够用，而且省掉了一套独立服务的部署、备份与监控。到了百万块以上，专用向量库在检索延迟和内存管理上的优势才明显体现出来。

估算时要按三年后的规模算，并且把「文档会被重复处理」考虑进去 —— 换一次切块策略或嵌入模型，整个库都要重建。

纯向量检索的盲区

向量检索擅长找意思相近的内容，但对精确匹配不敏感：产品型号、文件编号、人名、专有缩写，这些恰恰是企业场景里经常被问到的。用户问「XR-200 的接口定义」，向量检索可能返回一堆关于接口定义的通用内容，而漏掉那个具体型号的章节。

实用的做法是混合检索：关键词检索与向量检索各出一批结果，再合并排序。实现上并不复杂，但对带型号、编号的查询改善明显。很多「检索不准」的抱怨，根源就是只做了向量这一路。

元数据过滤比想象中重要

• 按部门、按文档类型、按生效日期过滤，能大幅缩小检索范围并提高准确率；
• 权限过滤必须在检索阶段完成，而不是检索出来再筛掉 —— 后者会导致召回数量不稳定，用户权限不同时结果质量差异很大；
• 选型时要确认目标存储是否支持带过滤条件的向量检索，部分实现的过滤是检索后再做，效果完全不同。

换嵌入模型的代价

不同嵌入模型产生的向量不能混用，换模型意味着全部重新生成。文档量大时这是一次有成本的批处理，而且期间检索质量会不一致。因此嵌入模型的选择应当比向量库本身更慎重，确定之后尽量不动。

如果确实需要更换，可行的做法是新旧两套并行一段时间，用同一份评测集对比后再切换。相关实施安排见企业知识库解决方案与平台与系统开发。