客服同事在旧工单里搜“退款到账慢”，返回的却是“退款流程说明”。换成同义句也差不多。问题不在于字面匹配，而在于系统没把“到账慢”和“退款延迟”放进同一个语义空间。语义检索的需求常从这种小挫败里长出来，向量数据库也常在这时被提起。
它解决的是“像不像”，不是“对不对”
文本、图片、音频经过模型变成向量后，距离近通常意味着语义接近。向量数据库要做的，是在大量向量里较快找出近邻，并尽量把过滤、更新、分区这些工程问题一起接住。它擅长回答“哪些内容看起来相关”，但“这条退款政策是否仍有效”属于业务事实，得由元数据、权限和主数据系统判断。把相似度当答案，容易把检索结果误当成结论。
检索链路里，它只是其中一段
一个可用的语义检索链路至少包括：原始内容清洗、切分、向量化、写入索引、查询改写、过滤、重排和结果呈现。向量数据库位于写入与近邻查询这一段。它不负责决定文档怎么切，也不天然理解“只搜最近三个月”背后的业务口径。团队若把切分策略和权限过滤全推给它，后面往往要在应用层补更多胶水。
- 切分过碎，向量很多，召回看似丰富，上下文却断裂。
- 切分过大，语义被稀释，查询指向变得模糊。
- 过滤条件复杂时，先过滤还是先近邻，会影响延迟与召回。
- 内容频繁更新时，旧向量何时失效，需要明确策略。
边界之外，应用层还得自己兜住
是否引入向量数据库，可以先问三个问题：查询是否真的存在同义表达和跨模态需求；数据规模是否已经让内存或延迟吃紧；团队能否维护索引重建、备份和权限同步。若只是给几十条帮助文档加个搜索框，普通全文检索加同义词表也能覆盖一部分需求。若语义查询已经是产品主路径，单独管理向量、元数据和索引版本就有意义。向量数据库不是语义能力的起点，更像是把语义检索变成可运维服务的一层基础设施。
还值得留一道人工可解释的缝。让用户看见命中的原文、时间与来源，让运营能标记“不相关”，让开发能回放一次查询为何召回某段内容。语义搜索越像“猜意思”，越需要这些不猜的部分。