在搜索框里输入“上次开会提到的那个客户反馈”，传统关键词检索容易卡住。它不知道“上次”指哪次会议，也不理解“客户反馈”和“用户意见”在语义上有多接近。语义检索试图补上这段距离：把文本转成向量，再比较向量之间的距离。问题随之而来——这些向量放在哪、怎么取、何时更新。向量数据库常被当作答案，但它更像一层基础设施，是否值得加入，要看检索链路里哪些环节真的需要它。
先看“相似”是不是主要需求
向量检索擅长处理模糊表达、跨说法匹配和多模态召回。用户输入一段描述，系统返回语义接近的内容，而不是只匹配相同字词。可如果查询本身有明确的编号、标签或时间范围，普通数据库的精确筛选往往已经够用。判断的起点不是“有没有AI功能”，而是查询是否经常无法用关键词表达、结果是否需要按语义接近程度返回。若答案可以由结构化条件确定，引入向量数据库只会多出一层需要维护的索引。
数据规模与更新节奏决定形态
数据量不大时，把向量放进内存索引或文件里也能完成近邻查询；数据持续增长、更新频繁时，才需要认真考虑独立存储。更新节奏常被低估：新增内容何时可见，删除后是否立即不可见，批量导入会不会拖慢查询，这些问题直接影响体验。另一个容易被演示遮住的环节是元数据过滤。业务查询往往同时要求语义相似和时间、类别、权限等条件，过滤与向量索引如何配合，需要在真实数据上验证，而不是只看一段顺畅的示例。
它不该替代原有检索
更务实的做法是把向量召回放进混合检索：关键词负责精确命中，向量负责语义补充，再由重排环节整理结果。向量数据库负责存储和近邻查询，不负责生成答案。把检索与生成分开，出问题时更容易定位：是召回没找到，还是模型读错了上下文。权限隔离、删除审计和访问控制也要在数据层想清楚。向量本身可能携带语义信息，删除原文并不等于删除所有可推断的内容，这部分边界需要在设计初期就留出位置。
一个务实的判断顺序
- 先明确查询类型：精确条件为主，还是语义描述为主。
- 估算数据量与增长方式，判断内存索引是否足够。
- 列出必须的过滤条件，确认删除与更新后的可见时效。
- 评估运维成本，再决定是否独立部署。
如果语义召回只是辅助能力，可以先在现有存储上做轻量向量索引，观察真实查询中的召回效果，再决定是否引入独立服务。向量数据库不是AI应用的入场券，它解决的是“相似性检索”的工程问题。把这个边界想清楚，再决定是否引入，通常比追着一个热门组件跑更稳妥。