员工在内部搜索框里敲下“退货流程改过哪一版”，翻了几页没找到。问题未必在表达，而在检索方式只认字面：文档里写的是“售后逆向处理调整”，字面匹配自然对不上。语义检索试图补上这一步——把文本片段转成向量，找意思相近的内容。向量数据库负责保存和检索这些向量，听起来像给搜索加了一层“记忆”。但记忆和判断是两件事。
相似不等于相关
向量把一段话压成坐标。坐标近，说明表达在模型看来接近；是否相关，还要看业务语境。企业文档带着权限、版本、生效时间，检索结果若绕开这些约束，语义再接近也可能带来麻烦。一个销售看到旧版政策，一个客服引用未生效条款，这类风险不靠相似度解决。实际系统里，关键词检索保证精确命中，向量检索补充语义召回，权限和状态过滤放在结果返回之前。三件事各管一段，混在一起谈容易失真。
把它放回索引层
把向量数据库放回索引层看，很多争论会清楚些。原文、权限、版本仍应留在文档系统或关系型存储里；向量索引保存的是片段坐标，可以重建，也需要维护。文档频繁修改时，增量同步、删除策略、片段切分常常决定体验；相似度参数只是其中一项。索引脏了，搜出来的内容再“像”也不可用。这里的工作更像管道维护，不像装上一个组件就结束。
边界出现在具体问题里
问“合同里交付节点是什么”，结构化字段和关键词查询往往够用；问“售后政策对二次销售怎么界定”，语义检索才有发挥空间。结果呈现也要克制：给出原文片段、出处和更新时间，让使用者自己判断，别把相似度分数当结论。成本同样要算，嵌入生成、存储和查询延迟都会进入链路。数据规模不大时，先拿一个文档集做小范围验证，再决定铺开范围。
所以，问题不在于是否上向量数据库，而在于企业是否愿意把“找得到”拆成召回、过滤、呈现几件事。向量只承担其中一段。名字叫数据库，容易让人把它当成知识库本身；放回系统里看，它更像一层语义索引。索引有用，但索引不替人做决定。