Azure AI Search 是微软全新的搜索服务，它的前身是 Azure 认知搜索，借助该服务可以帮助我们对大量的信息实现安全的检索服务。

同时该服务也是微软在当今大语言模型 RAG 应用领域，推出的一个解决方案。

单纯的向量数据库是靠向量搜索查找语义相似性文本段落，但光靠向量检索来搭建生产级别的RAG 应用是不太够的，除非你就只是做做 Demo。

而微软的 Azure AI Search 在提供这种语义搜索的前提下，还提供了很多增强扩展功能，来提高搜索结果的可靠相关性，比如通过混合检索和排序能力实现比单纯向量检索效果更好的搜索方式。

今天我们就来重点聊聊 Azure AI Search 的混合搜索。

默认的大语言模型无法提供外部最新知识或公司专属知识，并且容易出现幻觉问题。

RAG 架构是经过市场上很多落地应用场景验证过的，能够解决该问题的主流技术架构。

通过 RAG 架构，许多企业制作了 AI 客服，知识库等等大语言模型的产品。

下图是一个 RAG 问答的架构，当用户输入问题后，系统不会直接把问题提交给 LLM，而是先把用户输入的问题在外部数据源的知识库中进行向量检索，匹配找到相关的段落。

然后再将用户原始问题和检索到的相关段落一起提交给 LLM。从而让 LLM 拥有足够多的上下文背景知识来提供可靠的回答结果。

之所以这样做的原因在于每一个 LLM 本身有自己的局限性，他肯定不知道你公司的内部数据，因为这些信息都没有在网络上公开，也就没办法提前学习。

就比如 LLM 是一个软件开发大牛，你想让他来解决你的一个项目问题，他必须也要提前看看你的项目文件等数据，才能更好的回答你的项目问题。

而 RAG 解决的就是这个事情，让 LLM 临时查阅一些跟你所问问题相关的知识，从而更好的回答用户的问题。

但如果这个 LLM 找知识的时候就找错了，那自然无法准确回答用户的问题。

目前主流的 RAG 检索方式都采用的是向量检索，通过语义相似度的方式来进行文本段落的匹配。

要想实现向量检索，需要先将外部知识库的文档进行拆分，拆分时要尽可能确保被拆分后的文本段落有完整的语义。再将拆分后的文本通过 Embedding 转化为多维向量。

用户在提问时，将问题同样转化为向量，计算机通过对比已有文本段落向量和用户问题向量的相似性进行检索，将相关性更高的文本段落返回给用户，用户通过结合这个段落和原本的问题一起再丢给 LLM 回答。

这种向量检索的方式是可以实现相近的语义理解，多语言理解，多模态理解，并带有容错率的。

比如你提问：大鱼吃小鱼，这时候它和文本段落“大鱼抓捕小鱼”的相关性就要比 “我爱吃大米”的相关性高。

但向量检索也不是万能的，因为它并没有传统关键词检索的优势。

比如你想要进行精准的搜索某个订单 ID，搜索某个品牌，某个地址的时候向量检索的准确性就要远差于关键词检索了。

另外如果用户的问题很简短，只是输入一些单词，这时候语义的效果也并不好。

下图中就是在 Azure AI Search ，通过向量搜索的方式检索 $45.00 。

虽然向量检索会返回3个段落，但实际上这三个段落都没有包含 $45.00 这几个文本。

下图是 Azure AI Search 进行的关键词检索，这时就能得到包含 $45.00 的文本段落。

所以对于 RAG 来说，最关键的是要能够保障最相关的文本段落一定要出现在搜索的候选结果当中。

这时候单独用向量检索或者关键词检索都无法满足要求，因此混合检索出现了。

混合检索中，我们需要在数据库中提前建立向量索引和关键词索引，在用户问问题的时候，分别通过两种检索模式去查找相关文档。

下图是 Azure AI Search 中，使用混合检索的方式，通过这种方式也能检索到包含 $45.00 的文本段落。

当然也没有规定混合检索一定是关键词+向量，其他搜索方式混合在一起使用，也可以叫做混合检索。因为最终的目标都是对各个检索方式进行互补，从而提高检索的准确度。

光有检索的能力还不够，检索到的结果还需要能够有一个更好的排序。这个排序的目的是对混合检索的结果合并，并将更加符合用户问题语义的的结果排在前面。

下图是默认的混合检索，没有重新排序。

我们想得到的结果位于排序的第三位，虽然也能检索得到。

但实际上如果你的检索方式更好，他应该排序在第一个位置。

下图是 Azure AI Search 中通过混合检索 + 语义重排后，对于同样一个问题得到的结果。

可以看到结果本身原本排在三位的 someof the lessons covered 经过 Reranker 后评分排在了第一位。

下图是微软对几种搜索方式的实验数据测试结果，包括了关键词检索，向量检索，混合检索，混合检索+语义重排。

可以看到 混合检索+语义重排的效果在不同数据集的结果都是最好的。

除了数据集的测试外，微软还针对不同的问题类型对几种检索方式进行了测试。

可以看到只有针对关键词的查询问题时，关键词检索的评分最高，向量检索评分最低。

其他种类的查询问题都是混合检索的评分最高。

以下是这几种查询类型的简单介绍：

Concept seeking queries 概念性抽象的问题查询

释义：要用多个句子才能回答的抽象问题

例子：为什么使用语义搜索来对结果进行排名？

Exact snippet search 精确片段搜索

释义：问题较长且与原始文本段落完全相同

例子：通过提供相关信息，使您能够最有效地最大限度地提高 LLM 投资的质量和价值

Web search-like queries 类似 Web 搜索的查询

释义：类似于我们在用网页搜索引擎时，输入的较短的文字

例子：最佳检索概念

Low query/doc term overlap 查询/文档术语重叠率低

释义：问题和原始文档使用了不同的单词和短语

例子：问题是“最伟大的排序技术” 想要检索到的文档是“Azure AI 搜索具有对内容进行排名的最佳模型”

Fact seeking queries 事实查询

释义：具有单一且明确答案的问题

例子：介绍了语义排名的文档有多少个

Keyword queries 关键词查询

释义：只包含某个重要关键词的简短问题

例子：semantic ranker

Queries with misspellings 拼写错误查询

释义：问题本身拼写错误了

例子：Ho w mny documents are samantically r4nked

Long queries 长查询

释义：问题本身过长，超过20个 token

例子：这是一个非常长的查询，在其组成和结构中使用了大量 token，因为它很冗长

Medium queries 中查询

释义：问题本身一般长，在5-20个 token

例子：这是一个非常长的查询，在其组成和结构中使用了大量 token，因为它很冗长

Short queries 短查询

释义：问题本身少于 5 个 token

例子：Short query

除了检索和排序方法外，文档块的拆分方式也会影响到问答效果。

因为在针对长文本处理时，LLM 能处理的上下文有字数限制，所以召回时也要确保多个相关文本段落之和，加上提示词不能超过上下文数量。

在向量搜索的时候，本质是搜索相似文本片段，这个片段也是由长文本拆分后的结果。

文本段落的拆分，并不是单个文本块中包含越多文字效果越好。

在微软的测试中，将4096个 token 为一个文本块，以及将 512个 token 为一个文本块两种情况分别进行了测试。

除了每个文本块的 token数量外，在拆分块时还有个重叠文本的概念。因为拆分时会有截断的位置，比如你按照200个文字拆分成一个块，当200个字符结束后，很可能并不是一个完整句子的结尾。

此时语义就不会完整，所以你不能简单的按照字符数来进行文本拆分，最好是包含每个截断位置前后的一定文本。

下面的表格是微软对于不同拆分方式的测试，可以看到当有25%重叠文本时，效果最好