深夜翻看一个内部知识库的检索日志，会发现一个有趣现象：用户输入“报销单丢了还能补吗”，旧式关键词检索可能只盯着“报销单”，把流程说明、FAQ、附件模板一起抛出来；而语义检索会尝试理解“丢了”和“补”之间的关系。很多团队第一次认真考虑向量数据库，就发生在这样的时刻。
它做的事并不神秘。文本、图片或音频先经过嵌入模型变成一串浮点数，也就是向量。相似内容在向量空间里距离更近。向量数据库负责保存这些向量，并在查询时找出距离较近的若干条记录。听起来像“凭感觉”，实际依赖的是数学模型和索引结构。
它处理的是相似性，不是事实判断
很多人容易把语义检索理解成“更聪明的搜索”，但它并不负责判断哪条信息真实、哪段内容权威。它只是根据向量距离给出候选。候选是否可用，还要靠元数据过滤、权限控制、重排和业务规则。把向量数据库当成万能答案库，往往会失望。
工程上的麻烦，常从切分开始
真正接入系统后，问题很少停在“选哪个库”。文档怎么切分，表格要不要拆，标题和正文是否一起编码，更新频率多高，删除操作是否同步，都会影响结果。切得太碎，上下文丢失；切得太长，向量被稀释。元数据看似附属，却常常决定检索能否落到正确部门、正确版本。把向量数据库接进现有权限体系，也不是加一个字段就结束。
还有一个常被忽略的边界：向量检索擅长“意思相近”，不擅长精确匹配。订单号、错误码、人名、型号这类信息，仍需要关键词或结构化查询兜底。实际系统里，混合检索往往更稳妥，只是链路更长，调试也更琐碎。
有些场景可以晚点再上
如果文档量不大、问题集中在固定表单和流程，传统检索加人工整理FAQ可能已经够用。如果团队还没有稳定的内容更新机制，先把知识库梳理清楚，收益可能更直接。向量数据库不是项目启动的仪式，它更像一层检索基础设施，适合在语义匹配成为瓶颈时介入。
回到深夜那条日志。用户真正需要的不是“更炫的搜索”，而是一个能给出处、能翻页、能纠错的答案入口。向量数据库可以参与其中，但它替不了内容治理，也替不了产品判断。想清楚这一点，再决定要不要引入，可能比急着搭一套演示更接近问题的核心。