向量搜索

混合检索（Hybrid Search）将向量检索与BM25关键词检索的结果通过RRF（倒数排名融合）等算法合并，兼顾语义理解与精确匹配

向量搜索的核心机制是最近邻搜索，只要向量库非空，就一定会返回结果，没有内建的「无结果」分支。

执行 Cosmos DB 向量查询通常需要配合向量索引（如 DiskANN 索引）以保证性能，且向量查询会消耗较多 RU。

向量搜索是 Cosmos DB 支持的查询能力之一，用于在向量化数据中查找语义上最相似的结果；Cosmos DB 将向量存储在文档的数组属性中，并提供 VectorDistance 函数在查询中计算距离。

在E4012查询中，BM25将正确页面排第1（得分1/61），向量搜索排第14（1/74），RRF融合后正确页面得分约0.030，而E4021页面得分约0.016，正确页面得分几乎翻倍。

在自建测试集（120条真实查询，其中38条包含标识符）上，纯向量检索命中21/38条标识符查询，纯BM25（保留标识符分词器）命中36/38条，混合+RRF命中全部38条。

如果查询全是模糊的自然语言问题且不包含ID或术语，纯向量检索可能够用；如果知识库小到可以直接塞进提示词（Anthropic建议20万token以下），也可以先尝试直接放入。

纯向量搜索（embedding检索）容易丢失稀有而精确的token，如错误码、工单ID、SKU、函数名等，因为embedding将文本压缩成一个点时会模糊化稀有token。

向量搜索在需要精确关键词（如错误代码AUTH_403）的场景下，排名可能不够理想。

向量嵌入擅长文本相似度检索，但无法有效处理结构化图约束，例如同时满足地理距离、空余ICU床位、值班专科医生和过敏禁忌等多重条件。

向量表示是压缩后的语义摘要，会丢失精确标识符、否定词、数值边界等细节，也可能把语义相近但结论相反的文本排在前面

向量搜索将查询和文档映射为高维空间中的稠密向量，通过余弦相似度或点积衡量语义接近程度

Baruzzo的论述不是反对向量搜索本身，而是关于做事顺序：先建立可测量基线，让错误类型驱动技术决策。

向量搜索比较语义近似度，对精确匹配（如编号、日期、编码）天然不擅长，指向性查询是向量搜索的弱项。

没有基线时，增加向量搜索只能叫“变化”，不能叫“改善”；任何新增技术方案必须能超越基线才称得上改进。

当评估集显示词汇不匹配类错误占主导时，混合搜索（关键词加向量）才有充分理由，收益可以被量化。

语义检索（对存储知识进行向量搜索）和状态恢复（加载检查点工作流）解决的是不同问题；向量搜索可以浮现相关上下文，但绝不应作为恢复进行中任务确切状态的唯一机制。

向量搜索是把文本、图像等非结构化数据编码为高维向量（embedding），再用近似最近邻（ANN）算法检索语义相似项的技术，常用实现有FAISS、Milvus、Pinecone、pgvector。

向量搜索相比关键词倒排索引能捕捉语义相同但字面不同的表达，但需要额外的embedding服务和索引维护成本。

仅依赖向量搜索对精确匹配（如产品编号、错误ID、版本号和名称）无能为力，用户搜索'错误E4021'时向量搜索会丢失精确匹配。