LLM应用实战:当图谱问答(KBQA)集成大模型(三)

简介: 本文主要是针对KBQA方案基于LLM实现存在的问题进行优化,主要涉及到响应时间提升优化以及多轮对话效果优化,提供了具体的优化方案以及相应的prompt。

1. 背景

最近比较忙(也有点茫),本qiang~想切入多模态大模型领域,所以一直在潜心研读中...

本次的更新内容主要是响应图谱问答集成LLM项目中反馈问题的优化总结,对KBQA集成LLM不熟悉的客官可以翻翻之前的文章《LLM应用实战:当KBQA集成LLM》、《LLM应用实战:当KBQA集成LLM(二)》。

针对KBQA集成LLM项目,该系列文章主要是通过大模型来代替传统KBQA的相关功能组件,实现知识图谱问答,以及如何针对问答效果、多轮对话、响应时间等优化工作总结,是妥妥的干货篇,感兴趣的客官可以持续关注!

本次的主要优化点在于如下

1. 响应时间

项目的验收标准是流式首字的响应时间在3s内,而当前服务的平均响应时间在5s-7s之间,不符合项目验收标准。

2. 多轮对话

由于当前多轮对话中的指代消解、默认实体或概念对齐均由大模型处理,由于基座大模型的不稳定性,存在偶现的多轮对话中的对象指代错误的情况

2. 响应时间优化

2.1 响应时间统计

基于前文展示的流程图,针对每个节点进行单次响应时间的统计,结果如下:

模块

耗时

图谱初始化

558ms(仅第一次会耗时)

候选schema召回

49ms

对齐prompt调用LLM完整响应时间

2800ms

对齐校准

15ms

对话prompt调用LLM首字响应时间

1800ms

 

可以发现两次调用大模型的响应时间耗时基本都在3s,因此重点对LLM调用环节进行优化。

优化方案包括三方面:prompt长度缩减、LLM输出结果简化、使用量化版LLM

2.2 prompt长度缩减

经过分析比对,不同文本长度,LLM的首字响应时间差别较大,尤其是增加安全机制的非公开LLM。

原因也众所周知,LLM推理过程是基于前文预测下一个token,纵然增加了KV缓存机制、FA2机制,较长的prompt首字响应时间必然大于较短prompt,因此可以针对prompt长度进行缩减,以提高LLM首字响应时间。

由于项目中对齐prompt的平均字符长度为5000字左右,且需要等待LLM全部输出结果后,方才进行后续流程,因此本次优化重点优化对齐prompt中的示例部分。

提供的fewshot示例大概40+条,且大部分示例和用户当前问题不相关,因此将fewshot示例向量化进行存储,当用户提问时,基于语义相似度将问题与fewshot示例进行pk,筛选出语义相似的10条示例作为对齐prompt中的fewshot,以达到缩减prompt长度的效果。

实验结果表明,将40条fewshot减小为10条,响应时间提高0.8s左右

对话prompt没有进行优化,因为对话prompt不需要等待全部结果输出,只需要首字响应并流式输出即可。

2.3 LLM输出结果简化

LLM输出结果越长,输出全部结果的时间就越长,所以针对对齐prompt的输出长度也做了一些优化,虽然响应时间提升不高

原始对齐prompt调用LLM的输出如下:

(属性-等于-体重)且(属性值-等于-最大);(属性-等于-食性)且(属性值-等于-肉食性);(概念-等于-恐龙)

主要优化点在于:

1) 属性、实体、概念、属性值分别用P, E, C, V表示

2) 属性、实体、概念中三元组删除“等于”

3) 属性值中的等于用eq代替

4) 且、或分别用&, |表示

因此优化后的LLM输出结果如下:

(P-体重)&(V-eq-最大);(P-食性)&(V-eq-肉食性);(C-恐龙)

2.4 大模型量化

先前使用的非量化版的LLM,更换了INT 8量化版的LLM后,LLM的首响及完整响应时间有了质的提升。

其中对齐prompt完整输出结果由先前的2.8s提升至1.6s,对话prompt的首响时间由1.8s提升至0.6s

由于使用的是私有化部署的量化版,中间没有安全审核机制,再加上量化的有效推理,所以响应时间提升非常明显。

2.5 思考

经过上述三方面的优化后,平均响应时间2.1s-2.9s之间,满足项目的验收标准。但引入的问题还是需要进一步验证。如prompt输入长度缩减、LLM输出结果长度缩减、切换量化版LLM是否引入问答准确性的降低呢?

针对该问题,基于先前整理的测试集,进行测试验证,准确率层面效果基本保持不变,说明以上优化方法有效!

3. 多轮对话效果优化

3.1 示例

怎么辨认慈母龙

它有啥能力

分布在那些地方?

海百合是百合么?

那它分布在哪里?

上述示例为多轮问答,在测试验证中,运行10次该多轮问答,其中会出现2次”那它分布在哪里?”中的指代到了慈母龙,而非正确的海百合,因为对齐prompt调用LLM后,输出了“(E-慈母龙)&(P-分布区域)”原因当然可以归咎于LLM的基础能力不足,但如何进行优化呢?

尝试了两种方案:a. 对齐prompt中增加历史参考内容;b. 当前问题与历史问题通过LLM比较,判定是否二者存在关联性。

3.2 历史参考内容

想法也非常简单,LLM直接针对历史的问题和答案进行总结,大概率会存在指代不清的问题,那么如果将历史的问题以及对应指代的实体或概念作为参考项,提供给LLM,那么LLM就多了一层参考,进而可以提高指代的准确性。

历史参考内容引入到对齐prompt部分内容如下:

第一个问题prompt, 历史输入为空,ref也为空

历史输入:

```

 

```

 

现在回答:

in: 怎么辨认慈母龙

 

out:

第二个问题prompt, 存在第1个问题及实体,当前问题的参考ref为慈母龙

历史输入:

```

in: 怎么辨认慈母龙

ref: 慈母龙

```

 

现在回答:

in: 它有啥能力

ref: 慈母龙

out:

第三个问题prompt, 存在第1,2个问题及实体,当前问题的参考ref仍为慈母龙

历史输入:

```

in: 怎么辨认慈母龙

ref: 慈母龙

in: 它有啥能力

ref: 慈母龙

```

 

现在回答:

in: 分布在那些地方?

ref: 慈母龙

out:

第四个问题prompt, 存在第1,2,3个问题及实体,当前问题的参考ref也为慈母龙,即将之前的实体继续带入下一轮,大模型会根据当前问题,结合历史输入,进行实体抽取

历史输入:

```

in: 怎么辨认慈母龙

ref: 慈母龙

in: 它有啥能力

ref: 慈母龙

in: 分布在那些地方?

ref: 慈母龙

```

 

现在回答:

in: 海百合是百合么?

ref: 慈母龙

out:

第五个问题prompt, 存在前四个问题及实体,ref当前为海百合

历史输入:

```

in: 怎么辨认慈母龙

ref: 慈母龙

in: 它有啥能力

ref: 慈母龙

in: 分布在那些地方?

ref: 慈母龙

in: 海百合是百合么?

ref: 海百合

```

 

现在回答:

in: 那它分布在哪里?

ref: 海百合

out:

这样即使是20轮以上的问答,LLM也能根据当前ref进行分析比较,保障当前问题描述的实体或概念

3.3 当前问题与历史问题关联性分析

理论上通过引入历史参考内容可以有效解决多轮对话中的指代消解问题,但由于LLM本身泛化能力问题,偶尔会出现ref引入错误的情况,例如,上述第二个问题,当前的ref引入为海百合、慈母龙,如何针对该问题进行优化呢?

原因可能是历史问题存在多个时,大模型偶尔无法按照指令针对历史问题进行语义分析,因此可以将当前问题与历史中最后一次出现实体或概念的问题进行关联性分析,比较是否描述的是同一个对象,进而基于分析结果,将ref中的内容进一步约束。即,如果当前问题与历史最后一次出现的问题的实体相关时,则引入历史的实体,否则不引入历史实体。

举个例子说明下,怎么辨认慈母龙分布在那些地方?存在关联性(默认第二个问题不存在实体,自动引用前一个问题的实体),则ref为慈母龙,而怎么辨认慈母龙海百合是百合么?不相关,则ref中只保留海百合

关联性分析也是通过prompt调用LLM实现,对应的prompt内容如下:

你是一个关于自然博物馆的多轮对话的识别器,主要用于识别当前问题与历史问题是否在讨论同一个或一组对象,以便进一步区分多轮对话的边界,请参考如下要求和示例进行输出:

1. 输出只能包含"是", "否",禁止输出其他内容;

2. 一定要结合历史的问题,与当前问题进行语义层面分析与比较,判断当前问题是否有历史的问题是否在讨论同一个或一组对象,如存在指代消解等;

3. 如果输出为"是",表示当前问题与历史问题存在关联性,则表示二者共同;

4. "q"表示问题,"a"表示输出;

5. 如果当前问题存在"它"或"它们",表示存在指代情况,则输出"是";

6. 如果当前问题没有明确任何询问的对象,表示默认使用历史讨论的对象,输出"是";

7. 如果当前问题存在具体的询问对象,且与历史问题不存在指代问题,则输出"否";

 

 

示例如下:

```

示例

q: 怎么辨认慈母龙

q: 有啥能力?

a: 是

示例

q: 怎么辨认慈母龙

q: 分布在那些地方?

a: 是

示例

q: 怎么辨认慈母龙

q: 海百合是百合么?

a: 否

示例

q: 海百合是百合么?

q: 那它分布在哪里?

a: 是

示例

q: 霸王龙的体长?

q: 梁龙有何生活习性?

a: 否

```

 

现在请根据上述要求及示例,针对以下问题进行关联性分析:

q: {}

q: {}

a:

 

4. 总结

一句话足矣~

本文主要是针对KBQA方案基于LLM实现存在的问题进行优化,主要涉及到响应时间提升优化以及多轮对话效果优化,提供了具体的优化方案以及相应的prompt

读者可以按照这套方案进行其他KBQA的构建尝试,如有问题,可私信沟通。

 


 

 

目录
相关文章
|
2月前
|
数据采集 自然语言处理 供应链
LLM安全新威胁:为什么几百个毒样本就能破坏整个模型
数据投毒通过在训练数据中植入恶意样本,将后门永久嵌入大模型,仅需数百份毒样本即可触发数据泄露、越狱等行为,防御需结合溯源、聚类分析与自动化检测。
266 2
LLM安全新威胁:为什么几百个毒样本就能破坏整个模型
|
2月前
|
机器学习/深度学习 缓存 监控
139_剪枝优化:稀疏模型压缩 - 分析结构化剪枝的独特速度提升与LLM部署加速实践
随着大语言模型(LLM)规模的不断增长,模型参数量已从最初的数亿扩展到数千亿甚至万亿级别。这种规模的模型在推理过程中面临着巨大的计算和内存挑战,即使在最先进的硬件上也难以高效部署。剪枝优化作为一种有效的模型压缩技术,通过移除冗余或不重要的参数,在保持模型性能的同时显著减少计算资源需求。
|
3月前
|
SQL 人工智能 监控
SLS Copilot 实践:基于 SLS 灵活构建 LLM 应用的数据基础设施
本文将分享我们在构建 SLS SQL Copilot 过程中的工程实践,展示如何基于阿里云 SLS 打造一套完整的 LLM 应用数据基础设施。
774 59
|
2月前
|
人工智能 自然语言处理 TensorFlow
134_边缘推理:TensorFlow Lite - 优化移动端LLM部署技术详解与实战指南
在人工智能与移动计算深度融合的今天,将大语言模型(LLM)部署到移动端和边缘设备已成为行业发展的重要趋势。TensorFlow Lite作为专为移动和嵌入式设备优化的轻量级推理框架,为开发者提供了将复杂AI模型转换为高效、低功耗边缘计算解决方案的强大工具。随着移动设备硬件性能的不断提升和模型压缩技术的快速发展,2025年的移动端LLM部署已不再是遥远的愿景,而是正在成为现实的技术实践。
|
2月前
|
缓存 物联网 PyTorch
使用TensorRT LLM构建和运行Qwen模型
本文档介绍如何在单GPU和单节点多GPU上使用TensorRT LLM构建和运行Qwen模型,涵盖模型转换、引擎构建、量化推理及LoRA微调等操作,并提供详细的代码示例与支持矩阵。
641 2
|
2月前
|
机器学习/深度学习 缓存 PyTorch
131_推理加速:ONNX与TensorRT深度技术解析与LLM模型转换优化实践
在大语言模型(LLM)时代,高效的推理加速已成为部署高性能AI应用的关键挑战。随着模型规模的不断扩大(从BERT的数亿参数到GPT-4的数千亿参数),推理过程的计算成本和延迟问题日益突出。ONNX(开放神经网络交换格式)和TensorRT作为业界领先的推理优化框架,为LLM的高效部署提供了强大的技术支持。本文将深入探讨LLM推理加速的核心原理,详细讲解PyTorch模型转换为ONNX和TensorRT的完整流程,并结合2025年最新优化技术,提供可落地的代码实现与性能调优方案。
|
2月前
|
机器学习/深度学习 PyTorch 算法框架/工具
118_LLM模型量化与压缩:从理论到2025年实践技术详解
大型语言模型(LLM)在自然语言处理领域取得了前所未有的成功,但模型规模的快速增长带来了巨大的计算和存储挑战。一个典型的大型语言模型(如GPT-4或LLaMA 3)可能包含数千亿甚至万亿参数,需要数百GB甚至TB级的存储空间,并且在推理时需要大量的计算资源。这种规模使得这些模型难以在边缘设备、移动设备甚至资源有限的云服务器上部署和使用。
|
2月前
|
机器学习/深度学习 人工智能 自然语言处理
12_机器翻译入门:多语言LLM应用
在全球化背景下,语言障碍一直是信息交流、商业合作和文化传播的重要阻碍。2025年,随着多语言大语言模型(LLM)技术的突破,机器翻译已经从简单的单词转换发展为能够理解上下文、处理复杂句式、适应文化差异的智能系统。本文将带您入门多语言LLM在机器翻译领域的应用,重点介绍使用mT5(多语言T5)模型实现英语到中文的翻译,并探讨文化适应等高级话题。
|
3月前
|
存储 缓存 负载均衡
LLM推理成本直降60%:PD分离在大模型商业化中的关键价值
在LLM推理中,Prefill(计算密集)与Decode(访存密集)阶段特性不同,分离计算可提升资源利用率。本文详解vLLM框架中的PD分离实现及局限,并分析Dynamo、Mooncake、SGLang等主流方案,探讨KV缓存、传输机制与调度策略,助力LLM推理优化。建议点赞收藏,便于后续查阅。
1794 1
|
2月前
|
机器学习/深度学习 存储 缓存
115_LLM基础模型架构设计:从Transformer到稀疏注意力
大型语言模型(LLM)的架构设计是其性能的核心决定因素。从2017年Transformer架构的提出,到如今的稀疏注意力和混合专家模型,LLM架构经历了快速的演进。本文将全面探讨LLM基础架构的设计原理,深入分析Transformer的核心机制,详细介绍稀疏注意力、MoE等创新架构,并展望未来架构发展方向。通过数学推导和实践案例,为构建高效、强大的LLM提供全面指导。