一个常见的场景是：同事在内部知识库里搜“报销多久到账”，系统只返回标题里带“报销”的文档；换成“打款周期”又搜不到。关键词匹配没有坏，它只是不擅长处理同义表达。语义检索想补上的，正是这层意思上的接近。
做法通常是把文本切成片段，用嵌入模型转成向量，再在向量集合里找距离较近的片段。这里的关键不是“存向量”，而是“在可接受的时间内，从大量向量里找出足够相关的那一小部分”。向量数据库承担的，就是索引、近邻查询、过滤和更新这些基础工作。
它处理的是检索路径，不是理解本身
把向量数据库放进系统后，检索链路会变成：查询先转成向量，再按相似度召回候选片段，最后交给上层重排或生成。它不负责判断内容真假，也不自动理解业务规则。如果切片粗糙、嵌入模型与语料不匹配，索引本身补不回来。换句话说，它更像一段路，不是目的地。
小规模场景里，未必需要单独引入一套服务。数据量不大、更新不频繁时，在现有搜索引擎或关系库上增加向量字段，也能跑通验证。真正需要独立组件时，往往是因为写入吞吐、索引维护、多租户隔离或横向扩展开始变得麻烦。先确认瓶颈在哪里，再决定是否引入，能减少选型反复。
召回、过滤和成本，很难同时放松
向量检索通常需要在召回和延迟之间做取舍。近似索引能加快查询，但可能漏掉部分近邻；提高召回又会带来更多计算。带条件过滤时，问题还要细一层：先过滤再检索，还是先检索再过滤，会影响结果和性能。业务上常见的“按部门、时间、权限筛选后再做语义匹配”，并不是加一个参数就结束，需要把过滤字段和索引策略一起设计。
还有一个容易被低估的成本是更新。文档会改，权限会变，切片策略也会调整。向量数据库如果只被当成一次性导入的“黑盒”，后续删除、重建和版本切换就会变成运维负担。把数据来源、切片版本、嵌入模型版本记录下来，后续排查才有依据。
什么时候该考虑混合检索
纯语义检索并不总能覆盖关键词检索擅长的部分。编号、专有名词、精确短语，往往还是字面匹配合适。实践中可以把关键词召回和向量召回并列，再做合并与重排。这样做的代价是链路变长，但能减少“意思相近却答偏”的情况。是否需要混合，取决于查询里精确词和模糊表达的比例，而不是看别人上了什么。
如果一定要给判断顺序，我会先看三件事：查询是否真的存在大量同义表达；数据规模和更新频率是否已经让现有方案吃力；团队是否能维护嵌入模型、索引和评测集。三件事里有两件说不清，先做小范围离线评测，成本可控。向量数据库不是智能本身，它只是把“按意思找”这件事工程化。想清楚检索目标，再决定要不要为它增加一个组件。