本文旨在深入探讨语义索引这一关键概念，其应用场景与Agent、RAG召回等技术紧密关联，因此将一并进行讨论。

受限于具体方案的复杂性，本文将侧重于阐释作者的认知角度，而非深入探讨具体实现细节。

1、Agentic Search

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

2、索引：定义与本质

2.1、一般意义上的索引

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

索引实际上涵盖了检索过程、索引数据的表示及更新方案，其中后两者统称为索引方案。通常，检索过程与具体的索引结构紧密配合，难以完全分离。

索引的类型多种多样，除了目前大家熟悉的倒排索引、embedding索引外，现代数据库中也存在许多不同的索引结构，针对不同的数据结构和问题。有兴趣的读者可以深入学习了解。

本文仅以Geo数据的空间索引为例，旨在帮助读者从更广义的层面思考索引的需求与应用方案。Geo数据，如空间中的点、线、多边形等，通常以经纬度描述物理世界位置。常见的查询类型包括：获取某点周围特定距离范围内的Geo对象、召回与某一Geo对象相交的所有Geo对象，以及判断两个Geo对象是否相交。

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

然而，迄今为止，大多数工程岗位的从业者对这类Geo索引的实现方式仍知之甚少，即便有些曾作为用户使用过。这个不为大众熟知的索引实现案例，能够更好地帮助读者从更广义的视角思考索引的需求与应用方案。

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

2.2、索引的本质与数学意义

然而，上述讨论过于侧重底层实现，可能不利于理解索引的本质目标。本节将尝试提供一个更具“几何解释”或“物理图像”的比喻性阐释。

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

读者可以将其想象为城市高速公路。沿着高速路，可以快速从一个位置到达大部分区域，随后在目标区域转入低等级道路，趋近最终目的地。这种层级体系之所以有效，在于实际成本是通行时间，而非仅仅距离。

从算法角度看，为了更快地触达目标，同样需要一种成本更低的“快速通道”（shortcut）。此处的成本通常指跳转次数（及缓存未命中率），跳转可理解为抽象意义上的指针解引用。因此，对于特定类型的查询，需要构建一种快捷体系，以降低从查询起点到目标对象的跳转次数，即建立一个使相似内容距离更近的快捷体系，从而加速从查询触达目标对象的过程。

与实际道路不同的是，不能仅依赖单一的快捷体系。因为实际查询可能关注的方面或维度多种多样，而单一快捷体系往往只能覆盖少数类型的请求。因此，为满足多样化的查询类型和角度，需要针对不同目标构建多种索引实例，甚至多种完全不同类型的索引。

3、语义索引

选择为“索引”一词冠以“语义”前缀，旨在强调其并非传统关键字类的精确匹配检索，即便是措辞或token表达不同，但含义相似的内容也应被召回。

回顾实际应用需求，可以发现并非总是对整个文本段进行语义相似度计算，而是对某些特定信息维度有高度侧重。例如，项目管理场景更关注项目的区分与检索，医疗场景侧重科室、病人、疾病等维度，教育场景则关注学科、学生等。虽然可以直接使用通用Embedding方案作为索引或召回方案，但其效果往往不尽理想。

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

但基于关键字、实体等的方式仍然相对狭窄，它们无法满足以下类型的query：

• 过去1个月的会议中，哪些会议出现了争吵。

• 过去1个月的公众号文章中，哪些文章不是标题党。

在Agent时代和语义内容处理时代，存在各种传统方案难以满足的需求，但对于LLM-native索引来说，这些并非不可实现。

甚至可以实现针对单个用户需求进行特化的索引，该索引仅服务于特定用户的特定视角。例如，为HR岗位的用户构建一个能够识别“哪些会议出现了争吵”的索引。LLM作为通用的语义提取和处理工具，使得为单个用户特化语义索引的构建成本不高，尤其在用户愿意承担索引构建所需LLM推理成本的情况下，此类功能实现起来并不困难。

甚至在不远的将来，此类针对文本字段的定制语义索引有望直接集成至数据库系统。

结语与展望

本文旨在帮助读者突破对索引认知的固有局限。

交流与合作

如需交流讨论、参与相关讨论群或建立合作，请通过微信联系，详细方式请点击专栏简介及联系方式 2024。