LLM应用实战:当KBQA集成LLM

简介: 项目是关于一个博物馆知识图谱,上层做KBQA应用。实现要求是将传统KBQA中的部分模块,如NLU、指代消解、实体对齐等任务,完全由LLM实现,本qiang~针对该任务还是灰常感兴趣的,遂开展了项目研发工作

1. 背景

应项目需求,本qiang~这两周全身心投入了进去。

项目是关于一个博物馆知识图谱,上层KBQA应用。实现要求是将传统KBQA中的部分模块,如NLU、指代消解、实体对齐等任务,完全由LLM实现,本qiang~针对该任务还是灰常感兴趣的,开展了项目研发工作。

注意,此篇是纯纯的干货篇,除了源码没有提供外,整体核心组件均展示了出来。也是这两周工作的整体总结,欢迎大家查阅以及加关注(不强求哈~)

2. 整体框架

整体框架.jpg

整体思想还是遵循RAG策略,从图谱召回候选背景知识,让LLM进行润色回答

具体的流程如下:

(1) 用户提问:已发现的体重最大的肉食性恐龙是什么

(2) 对齐模块。

对齐模块的主要作用是针对问题与知识图谱中的实体、概念、关系、属性进行对齐。

其中候选概念、候选属性、候选关系在图谱中的数量是少量有限的,而实体的数量可多可少,因此候选概念、候选属性、候选关系可以在查询hugegraph后,直接拼到对齐prompt中(对齐的prompt预留了占位符),而实体则需要进行预筛选,筛选的方式是通过问题query与实体名进行语义相似度比较,通过语义相似度引擎实现,比如simbert, bge, gte等开源模型,预筛选后的少量实体可以拼接到对齐prompt。

对齐的prompt增加要求和few-shot示例,可以解决常见对齐问题,比如实体、概念、属性、关系存在缺字、多字、相似字等情况。

(3) 对齐模块经过LLM进行对齐,输出对齐结果。

本示例的对齐结果为:(属性-等于-体重)且(属性值-等于-最大); (属性-等于-食性)且(属性值-等于-肉食性);(概念-等于-恐龙)。

(4) 对齐校准模块。

对齐校准模块主要针对LLM对齐结果进行二次校对,解决的问题如下:

1) 一些LLM将概念与实体混淆的情况;

2) 与图谱中的实体、概念、属性、关系进行对齐匹配;

3) 实体名和概念名重复时,二者均进行召回等

(5) 解析及溯源模块

解析模块:

针对校准后的对齐结果,执行解析模块,解析模块会基于对齐结果进行判断,该执行如下哪种解析,候选的解析列表有:纯实体解析、纯概念解析、实体-属性解析、概念-属性解析、属性-属性值解析、属性-属性值-概念解析等。

(Ps: 候选解析列表是分析了大量数据之后,抽象出来的解析列表,常见的问答基本就涵盖在这些列表中)

每个解析模块会有不同的解析逻辑,例如:

1) 纯实体解析:会将查询hugegraph得到的实体作为背景知识提供给LLM,如介绍下霸王龙

2) 纯概念解析:会查询概念下有哪些实体,且仅列出实体名称作为背景知识提供给LLM,如恐龙都有哪些?

3) 实体-属性解析:会查询实体对应的属性或关系,并作为背景知识,如霸王龙有多重多高?

4) 概念-属性解析:会查询概念下实体的属性信息作为背景知识,如恐龙目下动物的体重分别是多少?

5) 属性-属性值解析:会查询属性对应属性值的信息,并作为背景知识,如肉食性的动物有?

溯源模块:主要功能就是从图谱中查询的结果,需要返回图谱对应的实体id、概念id、属性等

6) 问答模块

通过将解析后的背景知识以及用户的问题,经过问答prompt,然后调用LLM进行润色回答。

PS:

对齐prompt调用大模型是非流式输出,因为对齐结果不需要实时同步给用户;

问答prompt调用大模型是流式输出,因为问答结果需要实时同步给用户

3. 优缺点

(1) 优点

1) 整体架构简单,仅需要2个prompt,与LLM仅交互2次

2) 解析模块基于多数据集进行抽象,可覆盖多数查询场景

3) 针对未覆盖的场景,解析模块可支持快速扩展适配

4) 迁移新图谱时,业务只需要更改prompt即可,对业务相对友好

(2) 缺点

1) 首字响应时间主要耗时在对齐prompt与LLM的交互中,因为需要对齐完整输出结果

2) 概念、属性、实体对齐集中在1个prompt中,所以prompt的长度较长

4. 多轮问答实现

实现的思路如下:

1) 缓存历史问题以及缓存历史对齐的实体或概念,如可以缓存最近10轮的用户问题以及对齐结果

2) 针对指代消解、语义对齐prompt调优,且多轮问答的prompt也集成在对齐prompt中(因此,对齐prompt任务十分繁重)

具体示例如下(从对齐prompt截取了部分,第一次输入参考为空):

历史输入信息:

```

输入:盐都龙喜欢吃什么

参考:

输入:喜欢生活在什么地方

参考:盐都龙

输入:三角龙是植食还是肉食

参考:盐都龙

输入:有什么本事

参考:三角龙

输入:普尔塔龙多重

参考:三角龙

```

 

现在请回答:

输入: 吃什么

参考: 普尔塔龙

输出:

具体的效果可以查阅下面章节中的效果示例。

5. 效果

图谱三元组总量3000+,测试样例共计385条,其中单轮问答340条,多轮问答45条

(1) 单轮问答效果,准确率93%+

一阶问答

华阳龙的头骨化石是在哪里发现的

华阳龙的头骨化石是在中国四川省发现的。

判断问答

恐爪龙有4米长吗

恐爪龙的身长是3.5米左右,没有4米。

对比问答

三角龙和姜氏巴克龙谁更重

三角龙更重。

条件问答

化石在四川发现的恐龙有哪些

最大体型的长羽毛恐龙是二连巨盗龙。

组合问答

单爪龙身长体重多少?

单爪龙的身长是1~1.2米,体重约3.5千克。

(2) 多轮问答效果,准确率93%+

1) 示例1:缺字情况

问:普尔塔多重

答:普尔塔龙的体重是75吨。

问:吃什么

答:普尔塔龙是植食性的

2) 示例2:错字情况

问:河堤列龙生活在什么地方

答:河堤猎龙生活在英国的怀特岛和奇尔顿岭。

问:它是什么时候的恐龙

答:河堤猎龙是早白垩世,巴雷姆期的恐龙。

3) 示例3:较困难的指代消解

问:三角龙是植食还是肉食

答:三角龙是植食性的。

问:有啥本事

答:三角龙的能力是快速奔跑。

问:和肿头龙比,谁更长一些?

答:三角龙的身长为8米,而肿头龙的身长为4~6米。因此,三角龙更长一些。

问:那它的体重是多少?

答:三角龙的体重是6.1~12吨。

6. 答疑解惑

(1) 候选实体、候选概念、候选属性如何动态加载至prompt?

解:prompt预留占位符,代码解析时进行格式化

(2) 概念、属性数量有限,可以全部写在prompt,但如果实体有1W个呢?

解:基于sim进行候选实体召回策略

(3) 如何实现流式输出

解:基于tornado的websocket框架,结合异步框架asyncio以及python的yield、next等方法实现

(4) 非流式调用LLM出现网络不稳定导致超时,如何解决?

解:增加重试机制

(5) 对齐结果如何进一步保障?

解:增加对齐校准模块

(6) 如何减少频繁调用hugegraph

解:预先加载图谱至内存,然后使用python的lru_cache缓存机制

(7) 如何提高属性、概念、实体对齐的准确率,比如多字、缺字、相近字等?

解:对齐prompt增加要求以及few-shot

(8) 如何解决实体文字完全不一致,但指的同一个实体的情况,比如霸王龙和雷克斯暴龙?

解:通过图谱的别名维护,且当前别名与正式名地位相同

(9) 溯源是如何实现的?

解:在每个解析分支中,基于解析结果增加对应图谱的信息

(10) 如何实现最大、最小之类的查询,如体重最大的植食性恐龙是哪个?

解:对齐结果:(属性-等于-体重)且(属性值-等于-最大)且(概念-等于-恐龙)

解析逻辑:筛选恐龙概念下实体 -> 食性为植食性的实体 -> 其中体重最大的

(11) 如何实现关系的推理,比如鱼石螈演进关系的演进关系是?

解:原始图谱关系:鱼石螈 -> 演进关系 ->蜥螈 -> 演进关系 -> 异齿龙

对齐结果:(实体-等于-鱼石螈)且(属性-等于-演进关系);(属性-等于-演进关系)

答案:鱼石螈的演进关系是蜥螈,而蜥螈的演进关系是异齿龙。

(12) 为什么说解析模块便于快速扩展?

解:实体、概念、属性查询接口均封装为独立方法。

(13) 对比类、判断类的问题回答如何更加口语化?

解:问答prompt调优

(14) 如何快速定位问题?

解:增加debug机制,即接口调用时,debug机制会将每个阶段的处理结果均记录下来,并返回。

(15) 目前支持多少轮问答?

解:理论上支持N多轮,且N支持配置

(16) 如何提高指代消解的准确率?

解:对齐prompt增加历史的参考实体或概念

7. 遗留的问题

(1) 基于属性值查实体未实现,分析部分badcase,属于此类情况

(2) 路径查询未实现,因为当前图谱关系数量极少

8. 总结

一句话足矣~

本文主要是KBQA方案基于LLM实现,主要模块包括对齐、解析、润色、多轮问答等内容,而且基于业务测试集效果相对较好。

纯纯的干货篇!!

 

目录
相关文章
|
5月前
|
SQL 人工智能 监控
SLS Copilot 实践:基于 SLS 灵活构建 LLM 应用的数据基础设施
本文将分享我们在构建 SLS SQL Copilot 过程中的工程实践,展示如何基于阿里云 SLS 打造一套完整的 LLM 应用数据基础设施。
1071 81
|
5月前
|
人工智能 自然语言处理 API
快速集成GPT-4o:下一代多模态AI实战指南
快速集成GPT-4o:下一代多模态AI实战指南
483 101
|
8月前
|
缓存 监控 安全
通义大模型与现有企业系统集成实战《CRM案例分析与安全最佳实践》
本文档详细介绍了基于通义大模型的CRM系统集成架构设计与优化实践。涵盖混合部署架构演进(新增向量缓存、双通道同步)、性能基准测试对比、客户意图分析模块、商机预测系统等核心功能实现。同时,深入探讨了安全防护体系、三级缓存架构、请求批处理优化及故障处理机制,并展示了实时客户画像生成和动态提示词工程。通过实施,显著提升客服响应速度(425%)、商机识别准确率(37%)及客户满意度(15%)。最后,规划了技术演进路线图,从单点集成迈向自主优化阶段,推动业务效率与价值持续增长。
372 8
|
7月前
|
人工智能 监控 数据可视化
BISHENG下一代企业AI应用的“全能型“LLM软件
杭州奥零数据科技有限公司成立于2023年,专注于数据中台业务,维护开源项目AllData并提供商业版解决方案。AllData提供数据集成、存储、开发、治理及BI展示等一站式服务,支持AI大模型应用,助力企业高效利用数据价值。
|
4月前
|
人工智能 自然语言处理 TensorFlow
134_边缘推理:TensorFlow Lite - 优化移动端LLM部署技术详解与实战指南
在人工智能与移动计算深度融合的今天,将大语言模型(LLM)部署到移动端和边缘设备已成为行业发展的重要趋势。TensorFlow Lite作为专为移动和嵌入式设备优化的轻量级推理框架,为开发者提供了将复杂AI模型转换为高效、低功耗边缘计算解决方案的强大工具。随着移动设备硬件性能的不断提升和模型压缩技术的快速发展,2025年的移动端LLM部署已不再是遥远的愿景,而是正在成为现实的技术实践。
|
4月前
|
存储 Prometheus 监控
136_生产监控:Prometheus集成 - 设置警报与指标选择与LLM部署监控最佳实践
在大语言模型(LLM)部署的生产环境中,有效的监控系统是确保服务稳定性、可靠性和性能的关键。随着LLM模型规模的不断扩大和应用场景的日益复杂,传统的监控手段已难以满足需求。Prometheus作为当前最流行的开源监控系统之一,凭借其强大的时序数据收集、查询和告警能力,已成为LLM部署监控的首选工具。
|
5月前
|
人工智能 Java API
Java与大模型集成实战:构建智能Java应用的新范式
随着大型语言模型(LLM)的API化,将其强大的自然语言处理能力集成到现有Java应用中已成为提升应用智能水平的关键路径。本文旨在为Java开发者提供一份实用的集成指南。我们将深入探讨如何使用Spring Boot 3框架,通过HTTP客户端与OpenAI GPT(或兼容API)进行高效、安全的交互。内容涵盖项目依赖配置、异步非阻塞的API调用、请求与响应的结构化处理、异常管理以及一些面向生产环境的最佳实践,并附带完整的代码示例,助您快速将AI能力融入Java生态。
848 12
|
4月前
|
机器学习/深度学习 人工智能 自然语言处理
12_机器翻译入门:多语言LLM应用
在全球化背景下,语言障碍一直是信息交流、商业合作和文化传播的重要阻碍。2025年,随着多语言大语言模型(LLM)技术的突破,机器翻译已经从简单的单词转换发展为能够理解上下文、处理复杂句式、适应文化差异的智能系统。本文将带您入门多语言LLM在机器翻译领域的应用,重点介绍使用mT5(多语言T5)模型实现英语到中文的翻译,并探讨文化适应等高级话题。
|
4月前
|
机器学习/深度学习 自然语言处理 算法
48_动态架构模型:NAS在LLM中的应用
大型语言模型(LLM)在自然语言处理领域的突破性进展,很大程度上归功于其庞大的参数量和复杂的网络架构。然而,随着模型规模的不断增长,计算资源消耗、推理延迟和部署成本等问题日益凸显。如何在保持模型性能的同时,优化模型架构以提高效率,成为2025年大模型研究的核心方向之一。神经架构搜索(Neural Architecture Search, NAS)作为一种自动化的网络设计方法,正在为这一挑战提供创新性解决方案。本文将深入探讨NAS技术如何应用于LLM的架构优化,特别是在层数与维度调整方面的最新进展,并通过代码实现展示简单的NAS实验。
|
4月前
|
机器学习/深度学习 人工智能 自然语言处理
15_批量处理文本:LLM在数据集上的应用
在大语言模型(LLM)的实际应用中,我们很少只处理单条文本。无论是数据分析、内容生成还是模型训练,都需要面对海量文本数据的处理需求。批量处理技术是连接LLM与实际应用场景的关键桥梁,它能够显著提升处理效率、降低计算成本,并实现更复杂的数据流水线设计。

热门文章

最新文章