一个常见的内部知识库场景：员工输入“出差住宿标准怎么查”，关键词检索却返回一堆标题里带“住宿”的表格，真正讲差旅费用规则的那篇文档没有出现。文档标题写的是“费用管理办法”，正文里也没有连续出现“住宿标准”四个字。人一眼能明白意思，机器却卡在字面匹配上。
语义检索想解决的正是这类错位。做法不复杂：用嵌入模型把文档片段和查询都转成向量，再在向量空间里找距离近的内容。向量之间的距离，可以粗略理解为语义上的接近程度。文本长度、词序、同义表达不再完全决定结果。
它存的不只是向量
这时，向量数据库才进入视野。它不是嵌入模型，也不负责生成答案。它做的是把向量、原文片段、来源、时间、权限等元数据一起存起来，并在查询时完成近邻搜索和条件过滤。听起来像“存向量、查相似”，实际工程里还有不少麻烦：索引怎么建，更新时如何避免重建整库，删除一条文档后索引是否同步，过滤条件会不会拖慢召回，都是使用中会碰到的问题。
另一个容易被低估的环节是，向量检索的结果并不天然可靠。文档切分是否保留完整语义，会直接影响召回；只按固定字数切，容易把一句话拆断。嵌入模型是否理解业务术语，也会影响结果。一个通用模型可能把“工单升级”和“优先级调整”视为相近，却分不清内部流程里的两个不同状态。此时，元数据过滤和关键词检索仍然有价值。较稳妥的做法往往是混合检索：关键词负责精确命中，向量召回补上语义相近的表达，再通过重排或规则做二次筛选。
边界比想象中具体
所以，向量数据库更像检索链路里的一块基础设施，而不是一个可以单独交付的“智能搜索”。它适合处理表达多样、答案分散在长文本里的查询；遇到订单号、错误码、人名这类需要精确匹配的内容，传统关键词检索往往已经够用。若数据频繁变动，还要考虑索引更新带来的延迟与维护成本；若权限体系复杂，过滤逻辑必须在检索阶段就参与，而不是等结果返回后再删。
一个务实的起步方式，是先拿真实查询做小规模评测：看目标文档是否被召回，看误召回是否集中在某些类型的问题，再看切分长度、嵌入模型和过滤条件各自带来什么变化。评测集不需要很大，但要有代表性。很多问题在演示阶段被流畅的回答掩盖，到了真实使用中才暴露出来。
向量数据库值得关注，但它不是 AI 项目的捷径。把它放回检索系统里看，先明确要补的是语义召回、过滤效率还是数据规模，再决定是否引入。概念会降温，检索问题不会消失。