导读
本文将分享 TiDB 是如何利用知识图谱增强 RAG 能力的。（
pingcap/tidb.ai 现已重命名为 pingcap/autoflow，2.1k stars，GitHub 全站 Trending Repository of The Day #2, HackNews #2.
）
1.
tidb.ai 是什么
2.
简单 RAG 的实现方案
3.
为什么需要 Rerank
4.
知识图谱助力 RAG
5.
Vector type within TiDB > TiDB + Vector Database
6.
All in one 数据库帮助开发者减负
7.
Ending
8.
展望：下一代 AI 搜索系统
9
. 问答环节
分享嘉宾｜
王琦智
PingCAP
TiDB Ecosystem Software Architect / Senior Developer Advocate
编辑整理｜
蔡郁婕
内容校对｜李瑶
出品社区｜
DataFun
tidb.ai
是什么
TiDB 是一款分布式数据库，兼容 MySQL 语法，无需分库分表即可存储数十亿数据，支持线上业务与分析业务查询，且新增了向量搜索功能。AI 即人工智能。tidb.ai 是一个了解 TiDB 知识的 AI 问答机器人，基于 TiDB Serverless 构建的服务，用于回答 TiDB 相关问题。
这是 tidb.ai 的小 Demo，问题是 TiDB 中 TiKV 与 TiFlash 有什么区别。这个问题在原生 Vanilla RAG 中是难以回答的，因其涉及不同实体的比较。
在 tidb.ai 上线前，团队存在一些问题。一是技术支持人力不足，作为数据库厂商，技术支持人员有限，社区免费用户依靠社区支持小组轮班回答问题。二是技术回答间隔长，用户提出的问题，技术支持工程师需要逐一解决，若用户提供信息不足，还需反复询问，多轮对话耗时更久。三是 TiDB 文档丰富，但数量过多，用户难以全面认知，不知阅读哪篇。
tidb.ai 可以帮助用户看文档、写代码、回答问题，解放技术支持工程师人力，减少多轮对话等待时间。
简单 RAG 的实现方式
RAG 由 Retrieval、Augmented、Generation 三个单词组成，即检索增强生成。
其架构为，先将文档切分成 chunks（因 token 大小有限制），通过 embedding 模型将其转换为向量后存入 TiDB，此过程为 indexing。
用户提问时，问题也会通过 embedding 模型转换为向量，之后利用 TiDB 中的 VEC_Cosine_Distance 进行语义搜索，获取最相近的三个 chunks，放入大模型，生成 answer。
-
降低幻觉，增强大模型在 token size 内的注意力。
-
-
突破上下文窗口限制，虽窗口不断增大，但按 token 收费，将素材全部传入成本过高。
为什么需要 Rerank
使用 Rerank 时，先从数据库抽取内容（可使用 Vector search 或 BM 25 等稀疏向量方式），取出 top n 个关联的 documents，再用 Reranker 按关联度排序。
Rerank 专注于语言关系而非文本相似性，例如问“你吃了吗”，回答应是“我吃了”或“我没吃”，而非问题本身。Rerank 是在第一次 Retrieve 信息之后，再进行一个排序的操作。
在前面提到的 indexing 阶段，token 是有限制的，可能会在不应该截断的地方截断文字，造成文本混淆或信息丢失，还可能造成数据关联的丢失。
所以 RAG 加上 Rerank 后仍存在问题，除了 indexing 阶段上下文窗口限制的问题， chunks 之间还可能没有关联，或忽略了文档结构关系。
这些问题如何解决呢？这就引出了本次分享的主题，利用知识图谱来增强 RAG。
知识图谱助力 RAG
知识图谱助力 RAG 并非我们原创，而是依据微软、LinkedIn 等的论文实现并改良。
其思路是用户提问时，先找到 top n 个命中节点，再向外扩散 k 个度，获取所有节点和其间的连线信息，再生成 answer。知识图谱中，每个节点有 weight 表示其重要性，节点间连线表示 relationship，知识则存储于其中。
构建知识图谱需知识储备，我们基于丰富的文档和社区问答，使用 LLM 构建知识图谱。微软原方向是用 NLP 分词后手工构建图再抽取，我们是使用 DSPy 库，它可规范数据输出，定义节点和边的抽取方法，自动填入数据并抽取。数据存入 TiDB Serverless 集群，检索时使用 Vector Search 在该集群中搜索最近邻的 top n 个节点，再用 SQL 向外扩展 n 个度，这样就完成了扩散到所有节点的步骤。
TiDB 有着丰富的文档，其中英文 Markdown 文档 1276 篇，中文 Markdown 文档 1098 篇，均为手工维护，跟随版本更新。
TiDB 拥有成熟的社区，pull request 超过 96000 个，论坛主题 24000+，帖子 285000+，拥有超过 2300 位贡献者。
上图中的二维码提供了一个抽取知识图谱的代码示例，一步步地演示了如何从维基百科文档中抽取出图。抽取完成后的图是如上图右侧所示的一个 summary graph。
与微软论文中的 instance graph 相比，summary graph 性能稍逊，但更适合我们，二者都能提升 retrieve 的召回率约二十个百分点。
知识图谱抽取后，entities 和 relationships 需要 embedding，需选择数据库保存，且该数据库还要承担向量检索的工作。TiDB Serverless 既可存储正常业务数据，又可存储向量数据，并且不限数据量级，是解决存储问题的完美选择。
存储之后，下一步就是检索。检索过程为，先将用户问题 embedding，得到特征向量，可以用 OpenAI 或 Gina AI 等 embedding 模型翻译为 Vector；之后在 TiDB Serverless 数据库中，使用 VEC_Cosine_Distance 函数对问题的 embedding 和节点的 embedding vector 进行排序，从语义最近到语义最远，取出 top n（上图示例中取 n = 1），再进行 k 度搜索（此处 k =
1），最后取出所有关联节点和它们之间的连线喂给 prompt，再提供给 LLM，即可得到回答。
这里需要指出的是，为何不用图数据库？原因有三点，一是图数据库查询语句与 TiDB 不同（如 Cipher 或 GQL）；二是图数据库数据存于额外实例，查询至少需两次；三是遵循“如无必要，不增实体”的原则。
Vector within TiDB > TiDB + Vector Database
下面来解释一下为什么要将 vector 做在 TiDB 里面，而非外挂一个专业的向量数据库。
从开发者角度看，使用两个数据库，在读写时都需要读或写两遍，数据同步还可能存在问题，无法保证最终的一致性；而只使用 TiDB，逻辑非常简单，只需读写它即可。TiDB 支持 MySQL 语法，可直接使用 MySQL 的 Connector 或 ORM，我们希望在 MySQL 生态中有自己的 pg_vector，TiDB Serverless 出现后实现了这一点，我们可以在 MySQL 的生态中使用 vector。
与外挂数据库相比，TiDB 不限制数据存量，无需搭建额外分型数据库，也不用担心可用性问题，更无需负担更为复杂的应用架构。这就是接下来要介绍的 All in one 数据库的概念。
All in one
数据库帮助开发者减负
All in one 数据库融合多种功能，可帮助开发者减负，降低其心智负担和经济负担。
回顾过去 20 年，数据类型不断增加，从关系型、文档型到列式存储、全文检索、Vector 等，业务开发者需维护多种数据库，复杂度不断增加，数据存储对业务架构的侵入日益明显。
再来看一下经济上的减负。使用 TiDB 的 Serverless 服务，有免费的 2.5 亿 RU，约 205.21QPS 可坚持一个月。不同 QPS 收费不同，如 OSM 拥有者数据库 QPS
1200 时每月约付 $121。2009 年的 Twitter QPS 2400 时每月约付 $267。
Ending
原生 RAG 可降低幻觉、给予额外知识、突破 Retrieve 阶段上下文窗口限制，但仅考虑问题与答案相似度，忽略了语言关系；RAG 加上 Rerank 后，可提高回答的生成质量，但 Indexing 阶段上下文窗口仍有限制，且 chunks 无关联；加知识图谱后，可增加 Retrieve 的关联性，但需要额外维护知识图谱，增加了解决方案的复杂度。
数据库技术栈中，直接使用 RDB 简单可用，但数据量有限制，需分库分表，且可用性较低，需要额外补充一些 HA 组件，也没有 Vector 和分析能力；外挂 Vector Database，向量计算性能高，但需数据同步，可能存在一致性问题，架构复杂，需要不同的语法；外挂图数据库，操作逻辑直观，但同样存在数据同步、一致性、架构复杂和语法不同等问题。
再来比较两种 TiDB。TiDB 是开源的，如果自部署，可以享受到其数据量无限制、可用性高和分析能力等优点，但运维复杂、无 Vector 能力、需自行运维大量虚拟实例。使用 TiDB 的 Serverless 服务，同样数据量无限制、可用性高、有分析能力，还具备 Vector 能力、价格足够便宜，但持续高负载时价格比自部署贵。Serverless 服务之所以价格便宜，是因为利用了 AWS 临期打折的策略，购买临期实例，所以价格比自部署还要便宜。
需强调，没有技术是万能的，大家应根据实际情况选择合适的技术栈。
最后，以一句话结尾：AI is the Sky，Database is the Earth。我们要站得更稳，才能看得更远。
（
pingcap/tidb.ai 现已重命名为 pingcap/autoflow，2.1k stars，GitHub 全站 Trending Repository of The Day #2, HackNews #2.
）
展望：下一代 AI 搜索系统
在 TiDB 现有 RAG 架构的基础上，我们正在开发下一代 AI 搜索系统，目标是提供一个统一的 AI 搜索框架（Unified AI Search Framework）。这一框架可视作 AI 应用的 “V8 引擎”，不仅能够让数据查询更加高效，同时实现智能化的执行计划与搜索编排。
未来，我们将引入更加智能的功能，包括全文本检索（Full Text Search）、优化的智能执行计划（Smart Execution Plans）以及任务编排（Task Orchestration）。这些功能的实现将进一步提升开发者效率，为 AI 应用提供更为强大的支持。
问答环节
Q1
：知识对齐能否借助大模型解决？知识库构建后，知识关系点变化时如何维护和更新大量点边关系？若不做，检索质量和关联知识可能受影响，如何看待这个问题？
A1：这两个问题可归结为知识图谱的维护。知识图谱不是静态的，新的知识进来时有 merge 过程，可通过大模型完成，当两个节点相似度超 0.8 时可 merge 为一个。维护方面，我们采用 Hybrid search，将 graph 与 LLaMA Index（普通 Vanilla RAG）合并搜索，返回足够信息进行 rank，这样可减少人力投入，避免与目的背道而驰。
Q2
：能否描述在 Difi AI 文档检索场景中定义的基本规范？采取了 instance 还是 summary 方式？提取的边上信息如何在向量化或检索过程中保证比传统 RAG 有更好效果？如何利用有向信息增强临近空间表现和与问题的相关度，找到更靠近答案的知识图谱相关信息？
A2：我们适配了 Defi 的最简单 Vanilla
RAG 搜索方式，希望社区完成 Graph RAG 实现方式。在搜索更好节点和关系方面，Graph 与普通 Indexing 不同，如在 LLaMA Index 中节点无联系，而 Graph 中节点间有关系，可利用此在有限情况下提升 retrieve 性能。关于 DSTY 库的使用方式，可扫描相关二维码查看 step by step 的示例。
Q3
：是否有 tidb.ai 使用 Graph RAG 后，与朴素 RAG 对比的评测结果？Graph RAG 存储结构复杂，节点生成构建过程也复杂，后续如何调优？
A3：性能对比可参考香港大学的论文 LightRAG，其在基准数据集上对比了 Vanilla、Hybrid dance、稀疏索引、稠密索引、Graph RAG 等的性能，Graph RAG 的 retrieve 召回率可从 60% 提升到 80%
- 85%，但不同行业性能有差异。
持续调优方面，新数据进来时可进行 merge 操作，将相似度高的节点合并，并增大 weight，对于离群节点应驱逐掉，避免其影响扩散，更细的策略需根据具体思路优化，DSTY 库的使用可查看相关示例。
