6月28日-29日， 2024 稀土开发者大会 在北京顺利举行，TiDB 生态系统架构师 王琦智 老师受邀参加，并在 RAG 与向量搜索 分论坛分享了《下一代 RAG：tidb.ai 使用知识图谱增强 RAG 能力》。
随着Chat GPT的流行，LLMs（大语言模型）再次进入人们的视野。但是在处理特定领域的查询时，大模型生成的内容存在信息滞后、不够准确等问题。此时，RAG（Retrieval-Augmented Generation）技术就像一个“外挂”，通过结合外部知识库，动态地为 LLMs 提供信息，从而解决了模型训练数据静态和生成信息准确性的问题。向量搜索作为 RAG 的关键组成部分，利用高维数据的向量表示进行高效的相似性搜索，使得相关信息的检索更为精确和快速。
在进入到更深度的业务场景中，RAG 技术的应用面临着从文件解析、数据融合、索引创建、向量数据库，到混合检索和 rerank 等系列难题，向量搜索在耗时、召回精度、存储成本等方面也面临着挑战。如何让 RAG 和向量搜索技术落地时，更好地满足企业需求？如何在向量之上构建全链路 RAG 服务，提升开发者效率，降低成本？这也是本次稀土开发者大会设立本分论坛想要跟大家一起探讨的。
资料下载专区
tidb.ai 使用知识图谱增强 RAG能力.pdf (15.8 MB)
亮点内容
在正式介绍 TiDB 如何使用图谱增强 RAG 能力之前，先和大家简单介绍下 tidb.ai， tidb.ai 是一个AI问答机器人，旨在解决TiDB社区用户提出的技术问题，提高响应速度和用户体验。在此之前， tidb.ai 面临了一些挑战：
- 社区用户之前需要等待技术支持工程师解答问题，过程可能耗时且效率不高。
- TiDB文档虽丰富，但用户难以快速获取全面认知。
而在 tidb.ai 的背后，就是一个简单 RAG 的实现方案。
从左上角开始看起，假设你有一堆文本，你需要首先把他们切分成一个个的文本块，然后丢进 embedding 模型里，生成 embedding 向量，最后和文本块一起存在 TiDB Serverless 里。这个过程在 RAG 的术语里叫做 Indexing，在你存储完成的时候，我们就已经完成 Indexing 了。
然后这个应用就可以使用了，当用户来问，“什么是 TiDB？”，我们就要把这个问题丢进 embedding 模型里，同样生成一个 embedding 向量。拿着这个向量，在 TiDB Serverless 里，使用一个内建的函数 Vec_Cosine_Distance 这个是计算两个向量的 Cosine 距离的一个函数。我们拿着这个结果去做比对，利用向量索引，取出 Top N 个最相近的文本，最后再使用大模型，生成一个结果出来。
Vector within TiDB > TiDB + Vector Database
这里也希望能解答一下为啥 Vector 在 TiDB 内，会好于 TiDB 加一个额外的 Vector Database？
首先来看看 TiDB Serverless 的简化架构
我们为什么要用 TiDB Serverless，当你在使用了 TiDB Serverless 之后，你的服务的架构会变得更简单。你不需要维护两份数据，分别在不同的数据库里，我们就不说事务级同步的问题了，你有时候最终一致都做不到。而且，你还要花费额外的精力去维护两份数据，在编写程序的时候也会是一个极大的负担。另外，在 MySQL 生态里，MySQL 用户们羡慕了 pg_vector 很久了，但是一直都没有一个可以与之媲美的东西，直到 TiDB Serverless 出现之后，这个情况才有所改观，我们可以直接在 MySQL 生态里使用 vector 了。
抛开语法问题，我们比 pg_vector 更好的是：
- 我们不限制数据的存量，你想存多少存多少，不用分库分表
- 你不用额外搭建一个分析型的数据库
- 你不用担心可用性问题，我们是分布式架构的数据库
- 你不需要负担一个更复杂的应用架构
而 TiDB Serverless 就是这样一个 All in one 数据库，它可以帮开发者减负，一方面是能降低开发者的心智负担，你不需要额外维护一套复杂的架构，另一方面，在预算方面也可以轻松实现帮助开发者减负。
用琦智老师的话来说，我们的 AI 将是未来可以仰望的天空，但是数据库是我们脚下的土壤。只有站得更稳，才能看得更远。
