我要投稿

浅谈Agent、信息召回与语义索引

发布日期：2025-10-25 18:59:55 浏览次数： 1537

作者：孔某人的低维认知

微信搜一搜，关注“孔某人的低维认知”

本文是来填之前挖的一个坑，语义索引。这个东西的使用场景与Agent、RAG召回等强关联，就放在一起谈。

由于一些原因，本文不会做太具体方案的讨论，但我尽量让读者明白我的认知角度。

（根据我的经验，即使说得很清楚，也会有一大帮人觉得这不够具体。基本上是否能看懂我的这个思路，和是否能实际应用的相关度很高。所以中间这部分的工作量我就可以省了）

1、Agentic Search

与2023年的传统RAG不同，目前前沿LLM模型厂的Chatbot已经在逐渐实装Agentic Search的模式，就是OpenAI o3模型web版本开始使用的方案，目前GPT-5 Thinking也是如此。其最主要特点是：Agent会自主进行多轮的召回，每轮召回的query是模型根据已有信息自己进行推理得到的。

2、当我说索引的时候我在讲什么

（由于过去搜广推算法和工程的普及，导致在互联网和IT领域中的索引这个词掺杂了太多搜广推本身的特性。所以我有必要介绍一下我所说的索引的概念。）

2.1、一般意义上的索引

广义来说，索引可以指一切符合下列条件的方案：当需要从一个完整的数据集中，根据query召回一部分内容，并且该过程访问的数据量复杂度低于O(N)，其中N为数据总数。也就是说，所有对于给定query的召回，不需要全量遍历（或渐进复杂度等同于全量遍历）的方案。

当然这里实际上包括了检索过程、索引数据的表示、索引数据的更新方案等，后两者统称我所说的索引方案，当然一般检索过程也是与具体索引结构进行配合设计的，所以其实也很难完全剥离。

索引的类型其实有很多，除了目前大家熟悉的倒排索引、embedding索引外，现代数据库中其实有很多样的索引结构，针对于不同的数据结构和不同的问题，大家有兴趣可以去学习了解。

这里仅仅举一个例子，我认为它能很好地帮助读者在更一般的索引的层面进行思考，就是目前数据库中的Geo数据的空间索引。Geo数据包括：空间中的点、线、多边形等等，常见的数据是物理世界中的位置，一般以经纬度描述。常见的query类型有：获取一个点周围一定距离范围内的Geo对象，召回与一个Geo对象相交的所有Geo对象，判断两个Geo对象是否有相交等。

Geo数据的索引在各个数据库大致是在2000年前后逐步引入支持的，PostgreSQL一直是通过PostGIS插件进行支持，该插件在2005年达到1.0.0正式版。MySQL是在2004年开始通过扩展支持，在2015年正式在InnoDB引擎上支持。

但实际上到目前为止，大部分工程类岗位的同学对于这类Geo索引的实现方式也知之甚少，有一些是作为用户使用过这类索引。这个大家都不熟悉该索引内部实现的案例，能够更好地帮助这类读者去思考更一般性的索引的需求和使用方案。

当然有兴趣的读者也可以去研究一下这类索引的实现方式，每种数据-查询场景的索引实现方式其实都有所不同，能够开阔读者的视野。

2.2、索引的数学意义

但以上讨论都过于纠结于底层实现，不好理解索引的本质目标。所以本节试图给一个我心中的类似“几何解释”、“有物理图像”的解释。

索引的本质功能是对于特定的query不必遍历所有数据。那么一种思路就是在数据中构建一些快速通路，在各种算法中一般被称为（图上的）shortcut。

大家可以想象成是北京的市内高速路。你沿着高速路可以快速从一个位置触达到大部分区域，然后在目标区域再降低到低等级道路，向着目标去趋近。这个层级体系之所以有用，是因为实际的成本是通行时间而不只是距离。

在算法的角度上，我们为了能够更快地触达对应的目标，也需要一种成本更低的快速shortcut，而成本一般是跳转的次数（和缓存的未命中率），这里的跳转可以理解为是抽象意义上的指针解引用。所以我们就需要对于特定类型的query，有一种shortcut体系，能够降低从query起点到目标对象的跳转的次数。也就是我们构建了一个在该类型query下，相似内容距离更近的shortcut体系，能够更快地从query出发触达目标对象。

与实际道路不同的是，我们不能只依赖一种shortcut体系。因为实际的query可能关注的方面/维度是各种各样的，而一种shortcut体系（的实例）经常只能覆盖少数类型的请求。所以为了满足各种各样的query类型/角度，我们也需要针对于各种各样目标的索引实例，甚至是多种完全不同类型的索引。

3、语义索引

我选择对索引这个词冠一个【语义】的前缀，就是为了表明它不是传统的keyword类精确匹配的检索，措辞/token表示不同，但意思相似的内容也要被召回。

（目前的embedding类模型可以作为一种简单而较为通用的语义索引方式。但它太过于简单，以至于会给新方案设计者以强烈的误导说语义索引只能这样。）

反思我们平时遇到的一些需求，我们能够发现其中并不是对于整个文本段的语义相似度计算，而是对于其中某些信息维度有极大的侧重。例如说：项目管理类场景更关注区分和检索具体的项目，医疗场景更关注科室、病人、疾病等维度，教育场景更关注学科、学生等。我们可以使用这些通用的embedding方案直接作为索引/召回方案，但它们的效果并不够好。

传统To B RAG场景下已经演化出了应对的方式，对于重要的维度、keyword等构建专门的独立索引来帮助召回。对于直接keyword召回不合适的场景，还可以定义和挖掘内容中的各种entity来构建独立索引。这其实就是前面不同索引关注不同角度的具体案例。

但基于keyword、entity等的方式仍然相对狭窄，它们无法满足以下类型的query：

过去1个月的会议中，哪些会议出现了争吵。
过去1个月的公众号文章中，哪些文章不是标题党。

在Agent时代和语义内容处理时代，其实有各种各样的需求，它们无法靠传统方案进行满足，但对于LLM-native index来说，它们并非不能实现。

甚至说其实我们可以实现对单个用户需求所特化的索引，该索引该角度只服务该用户一人。例如说给一个HR岗位的用户，构建一个哪些会议出现了争吵的索引。LLM是一个通用的语义提取和处理工具，为单个用户特化的语义索引的构建成本其实没有很高，至少在用户愿意承担索引构建时所使用的LLM推理成本的情况下，该类功能其实不难实现。

甚至在不远的将来，我认为该类对于text字段的定制语义索引会直接集成在数据库中。