一个团队做内部知识库，最先被演示打动的地方往往是“搜意思”。输入“权限申请多久通过”，系统能返回“账号审批周期说明”，哪怕两份文档没有同一个词。于是他们接入嵌入模型，把文档切块、向量化，再放进向量数据库。演示很顺，上线后问题才来：有人搜工单号，返回一堆语义相近但无关的段落；有人搜刚更新的制度，旧版本仍然排在前面；问“某位同事提交的申请”，系统分不清人名和普通名词。
这些故障不全是向量数据库的错。它做的事其实很窄：保存高维向量，并在其中找距离较近的邻居。所谓“理解语义”，来自嵌入模型把文本映射成向量，数据库只负责存和查。把两者混为一谈，就容易把检索问题当成买一个组件就能收尾的工程。
它处理的是“相似”，不是“正确”
向量检索的用处，是在表达不同、意图接近的文本之间搭桥。客服问法千变万化，产品文档写法固定，这种场景里它能补上关键词匹配漏掉的表达。但它给的是相似度，不是事实判断。工单号、设备编号、人名、版本号这类精确标识，倒排索引或结构化字段过滤通常已经够用。把精确查询硬塞进向量检索，结果往往看起来“相关”，实际不能用。
另一个容易被忽略的限制是切分。文档切成多大、是否保留标题层级、表格怎么处理，会直接改变召回结果。切得太碎，上下文丢失；切得太长，一个向量混进多个主题，相似度被稀释。嵌入模型也有适用边界：通用模型对行业术语未必敏感，换模型又意味着重新生成全部向量。这套组件在这里不背锅，但它的索引结构、过滤能力和更新策略会影响整个链路的可用性。
先看检索链路，再看数据库
如果团队正准备引入向量数据库，一个可行的做法是先用小范围真实问题做评测集，记录哪些该召回、哪些不该召回；同时保留关键词检索，做混合排序；把时间、部门、文档类型等元数据放进过滤条件，而不是全交给相似度。规模不大时，先用内存里的暴力计算或现有搜索引擎的向量插件也能验证需求，不必急着上独立服务。
我的判断是，向量数据库的价值不在“让搜索变聪明”，而在把高维向量的存储、索引、过滤和扩缩容做成可运维的基础设施。它适合语义召回占主导、数据持续更新、过滤条件复杂的场景；如果查询主要是精确匹配、报表统计或强事务，传统数据库和搜索索引往往已经够用。真正决定效果的，往往是切分策略、嵌入模型、混合检索和评测闭环，而不是数据库这个名字。
回到开头那个知识库，可能先补的是文档治理和评测，而不是再换一个检索组件。先把“什么算搜对了”说清楚，再决定要不要用它，会减少不少反复。