ChatTuGraph:通过大模型“与图对话”
作者:范志东
使用 SQL(Structured Query Language)对数据库/数据仓库进行查询分析操作,几乎成了研发工程师和数据分析师的“家常便饭”,然而要写出高效、清晰、优雅的 SQL 脚本并非易事。随着大语言模型(LLM)技术的普及,借助大模型微调(Fine Tuning)等技术将自然语言自动翻译为 SQL 语句(NL2SQL/Text2SQL)便成了非常流行的解决方案,相关的工具框架(Chat2DB、DB-GPT等)也是层出不穷。
同样的,在图数据库领域也存在相似的问题,甚至更为严峻。相比于 SQL 相对成熟的语法标准(SQL2023),图查询语言尚未形成成熟的统一标准,目前是多种查询语法并存的状态(GQL、PGQ、Cypher、Gremlin、GSQL等),上手门槛高,因此更需要借助大语言模型的自然语言理解能力,降低图数据库查询语言的使用门槛。
1. 图表融合:SQL+GQL
TuGraph 计算引擎TuGraph Analytics创新性地设计了SQL+GQL融合语法,以解决图表混合分析场景的业务诉求,将图上的分析计算能力有机地融合到传统的 SQL 数据处理链路内,实现了图引擎上一体化的图数据建模、图数据集成、图存储、图交互式分析能力。
TuGraph Analytics 的 SQL+GQL 融合语法典型形式为**“SELECT-FROM-WITH-MATCH-RETURN”**结构,通过 GQL 语法的“MATCH-RETURN”语法单元,为 SQL 处理提供数据子视图,方便传统数据分析师对数据的进一步处理。
通过以上的语法设计,可以满足多样化的图表融合处理的诉求。点边数据源提供构图数据,Request 数据源提供图计算触发的起点集合。
不同的数据源处理模式的组合,形成了多种“流”与“图”的混合计算形态。而 SQL+GQL 的融合语法设计,可以很好地表达多样化的计算模式。
2. 与图对话:ChatTuGraph
我们不否认 SQL+GQL 融合语法是一个创见性的语言设计,但这并不能解决“新型图查询语言的高上手门槛”这个通病,因此,借助于 LLM 微调实现专有的图查询语言模型,通过自然语言的方式与图数据交互,实现“与图对话(Chat-to-Graph/Chat-TuGraph)”。
我们初步构想了面向未来的图数据库智能化能力,至少具备以下产品形态:
智能交互分析:通过 Agent 发送图查询指令,同步获取图数据结果。
智能数据变更:通过 Agent 发送图变更指令,修改图数据,获取修改状态(成功与否、影响行数等)。
智能任务处理:通过 Agent 发送图处理任务指令,触发异步图计算任务,获取图任务运行状态。
智能运维管控:通过 Agent 发送管控指令,实时获取图数据库状态(流量、负载、慢查询等),操纵图数据库实例(启停、伸缩、切流等)。
以上设想是一个比较长远的规划,仰望星空后,我们还是要脚踏实地,回归当下,从最基本的“智能交互探索”开始,构建 Text2GQL 能力。
3. 模型微调:Text2GQL
以下对话场景,便是我们希望第一阶段达成的目标。
Me: 查询蚂蚁集团研发的通过 TuGraph 支持的产品列表。
ChatTuGraph: match(a:company where a.name = '蚂蚁集团')-[e:develop]->(b:product)<-[e2:support]-(c:software where c.name = 'TuGraph') return b.name
3.1 语料生成
众所周知,要实现模型微调,构建语料是第一步,也是最关键的一步,语料的质量和丰富度会直接决定微调模型的预测效果。但是前面提到,由于图查询语言标准的不够成熟,想要获取现有的 GQL 语料是一件很困难的事情。另外,SQL+GQL 语法更是 TuGraph 的“独创”,业务语料的丰富度更低。这种情况下,我们只能“自力更生”想办法创造语料,于是就有了**“语法制导的语料生成策略”**。
该策略的具体思想如下:
GQL 抽象语法树(AST)展开后的基本形式就是表达式(Expr),常量(Literal)也是一种特殊的表达式。
通过设计表达式实例生成器,批量生成并组合出大量的 AST 实例,得到 GQL 语句样本。
特定的 AST 可以通过通用生成器产生对应的提示词模板,提示词模板随着 AST 实例化形成提示词文本。
特殊的不适合通过生成器生成的提示词模板可以通过人工构造。
初步生成的提示词文本可以借助 LLM(如 GPT-4)进一步泛化和翻译,生成多样的自然语言提示词文本。
3.2 模型训练
构建完语料后,参考OpenAI官方模型微调手册,可以轻松实现模型微调(当然,氪金是必不可少的……)。
这里我们基于模型gpt-3.5-turbo-1106
进行微调,首先需要将语料按照如下格式进行处理:
进入OpenAI模型微调页面,上传格式化后的语料文件(一般以.jsonl 结尾),设置模型前缀,创建微调任务。
模型微调完成后,可以看到最终的模型 ID,形如:ft:gpt-3.5-turbo-1106:personal:<Suffix>:<Id>
。
验证微调模型也很简单,调用 OpenAI 的 Chat Completion API 时传递微调的模型 ID 即可。
3.3 本地部署
如果不想“斥资”使用 OpenAI 的微调服务的话,我们也提供了开源的基于CodeLlama-7b-hf微调后的 Text2GQL 模型CodeLlama-7b-GQL-hf给大家测试使用(模型量化后可以在 Mac 上本地运行,没有 4090 的小伙伴也不用怕了^v^)。
首先,下载 HuggingFace 上的模型文件到本地(记得先安装git-lfs),如/home/huggingface
。同时为了方便大家快速部署本地大模型服务,我们提供了预先安装好 CUDA 的 Docker 镜像。
启动 Docker 容器,将模型文件目录挂载到容器目录/opt/huggingface
,并开放 8000 模型服务端口。
进入 Docker 容器,对模型文件进行转换,最终会看到转换后的模型文件ggml-model-f16.gguf
。
默认转换后的模型精度为 F16,模型大小为 13.0GB。正常情况下 Mac 本地内存无法支撑如此大的模型推理,需要对模型做精度裁剪(当然如果你有 4090/在带 GPU 卡的 ECS 上运行,可以跳过该步骤……)。
不同规格的量化参数对应的模型规模如下:
最后,启动模型推理服务,绑定0.0.0.0:8000
地址,否则容器外无法访问该服务。如果对模型做过量化,记得更新-m
参数的值。
服务启动完成后,可以对本地模型服务做简单的对话测试。
4. 平台接入:Console+LLM
TuGraph Analytics 的Console平台提供了初步的大模型能力的集成和对话能力,大家可以下载最新的代码部署体验。
登录 Console 后,切换到“系统模式”,进入**“系统管理-模型管理”**注册模型服务,模型类型可选择 OPEN_AI 或 LOCAL,分别对应上述的 OpenAI 微调模型和本地部署模型。注册完成后,可以做简单的可用性测试。
切换到“租户模式”,选择一个图查询任务,进入查询页面。点击“执行”按钮右侧的机器人图标,即可开启对话。对话回答的 GQL 语句可以点击复制按钮一键执行。
5. 借图发声:Graph+AI
截至此时,借助于大模型微调技术,实现自然语言转图查询,仅仅是一个开端。未来我们相信“图与 AI”还有更多的结合场景值得去探索和尝试。
首先,当前的模型微调训练语料仍不够完备,真实测试中还是会出现推理幻觉和不准确的问题。进一步丰富训练语料以及在 GQL 标准不完善的情况下,构建模型的有效性验证方案是亟待解决的问题。
其次,面向 GQL 查询分析场景的微调只解决了图上自然语言交互式分析的问题,对 SQL+GQL 融合语言中的数据变更、任务提交能力并未覆盖。当然这部分能力也需要 TuGraph 引擎能力不断迭代改进以获得支持,才能最大化地丰富自然语言操纵图数据库的场景。
再次,面向图数据库的智能化运维管控也是一个很值得研究的方向。在以 LLM 为基础,Agent 大行其道的环境下,借助 AI 能力释放基础软件的运维压力,也符合 ESG 的战略宗旨。
另外,借助于图计算技术,为大模型推理提供更准确的知识库,消除模型幻觉,也是当下 AI 工程技术 RAG 研究的热门方向。
最后,利用 AIGC 技术,为图应用场景生成更丰富的解决方案,提供高质量的内容输出,将技术红利带入到行业,对图计算技术的普及也大有裨益。
最后的最后,诚邀大家参与本周六(3.30)TuGraph 的社区 Meetup,大家喝喝茶、吹吹风,一起聊一聊图计算与 AI 技术。
评论