大模型应用的数据增强技术综述
大模型应用落地现状
大模型人工智能技术在个人消费场景得到快速验证后,企业级市场正在广泛的探索应用落地的可能性,涵盖了从客服、营销、运营、招聘与人力资源管理、供应链、产品研发、办公效率等企业各个职能领域,数据来自红杉中国对241位CEO、CIO、CTO、CDO等高级管理层或科技及数据部门负责人的问卷调查。
易观分析2024企业AI应用行动指南指出,从更一般化的技术应用角度,数据分析和决策支持、知识搜索与管理、流程和文档自动化、多模态内容生成、应用开发工程智能辅助等活动成为大模型典型场景,大模型技术有望突破传技术产品和解决方案的瓶颈,满足企业多样化和动态化的业务需求
在企业级场景中,数据是各类业务活动的基石。从高频的售前、售后客服问答,到复杂且周期较长的业务分析和报告生成;从日常运营管理、到短期规划调整,再到中长期战略决策,都深度依赖不同来源、不同类型的专业数据。同时,由于企业级场景涉及重大的经济利益或社会影响,对应用输出结果的准确性、可解释性以及安全性要求很高,直接基于基座大模型无法有效解决实际业务场景中的各种需求。因此,需要通过增强技术,特别是数据增强技术来提升其能力。
相关领域知识介绍
商业智能(BI)旨在将大量数据转化为可供决策的信息洞察,以支持明智的决策制定。典型的 BI 工作流程包括数据准备、分析和可视化等多个阶段。它需要数据工程师、科学家和分析师使用各种专门工具进行协作,这可能非常繁琐且耗时。因此,现代组织需要先进的技术来自动化和优化这一工作流程。而企业级场景下大模型技术主要落地于各种数据类任务场景、需要针对大模型技术的特点更有效的处理多源异构数据。因此企业级的数据分析场景属于商业智能的范畴。基于大型语言模型 (LLM) 的自主智能体提供了简化 BI 工作流程的潜力。通过接收自然语言 (NL) 指令,基于 LLM 的代理可以在可执行环境中执行任务规划、推理和操作。这可以显著降低许多 BI 任务的复杂性,例如代码生成 、文本到可视化的翻译和自动化洞察发现 。
下面按照企业级场景下应用大模型技术时面向的两大类数据类型来探讨企业级的数据增强任务:
结构化数据是企业级数据处理中最常见的形式,广泛存在于关系型数据库、电子表格以及数据仓库中,其核心特征是具有明确的行列结构和固定的数据模式,非结构化数据有,如PDF文档、Word文档、图片、音视频等多种模态。
对于结构化数据,最为主要的是自然语言到SQL(NL2SQL)技术的研究,同时还有自然语言到API(NL2API)、NL2Code(代码解释器)等技术不断发展提供支持。
NL2SQL任务是将用户的自然语言转换为数据库可以执行的SQL,并且SQL语义与用户的意图一致。这也是当前最主要,最热门的研究方向。
NL2API是使用者输入自然语言,系统借助 LLM 将使用者的输入问题转化为对 API 工具的调用,包括 API 的名称与提取的参数。根据 LLM 的响应调用指定的 API,取得返回的数据。
NL2Code(自然语言生成代码)进行数据处理是伴随着大模型的发展而受到广泛关注的新兴领域,根据用户的自然语言输入生成Python代码等,对诸如表格数据等进行数据分析。
对于非结构化数据,通常使用的数据增强技术有RAG检索增强生成,其实广义上来说,这里所讲的所有数据增强技术都属于rag,因为都是检索数据来增强大模型的生成内容的过程。我们这里主要狭义的将对非结构化数据的RAG,具体技术包括向量生成、向量索引、向量检索等技术,还可以使用一些传统的搜索算法。
NL2SQL介绍
这是一个最简单的NL2SQL流程,用户的问题经过简单预处理后,拼接上数据库的结构信息一起发送给大模型,大模型生成SQL语句查询数据,随后再将取出的数据提供给大模型进行回复生成。
NL2SQL原理上的难点有:
1.自然语言查询通常的不确定性:
词汇歧义:当一个单词有多个含义时,就会出现这种情况。例如,“bat”这个词可以指动物或棒球棒(名词),也可以指挥动的动作(动词)。
句法歧义:当一个句子可以用多种方式解析时,就会发生这种情况。例如,在句子“玛丽看见那个拿着望远镜的男人”中,短语“用望远镜”可以表示玛丽用望远镜看见那个男人,也可以表示那个男人有望远镜。
规格不足:语言表达缺乏足够细节来清晰传达特定意图或含义的情况。例如,“2023 年的劳动节”在美国指的是 9 月 4 日,但在中国指的是 5 月 1 日。
2.复杂的数据库和脏内容:
- 表之间的复杂关系:数据库通常包含数百个具有复杂相互关系的表。nl2sql解决方案在生成sql查询时必须准确理解和利用这些关系。
- 属性和值的歧义:数据库中模糊的值和属性会使nl2sql系统识别正确上下文的能力变得复杂。
- 特定领域架构设计:不同领域通常具有独特的数据库设计和架构模式。不同领域的架构设计各不相同,因此很难开发出通用的 nl2sql解决方案。
- 大而脏的数据库值:高效处理大型数据库中的海量数据至关重要,因为将所有数据作为输入进行处理是不切实际的。此外,如果管理不当,脏数据(例如缺失值、重复或不一致)可能会导致错误的查询结果(例如影响WHERE子句)
3.罕见和复杂的SQL操作:
- 一些SQL查询在具有挑战性的场景中涉及罕见或复杂的操作和语法,例如嵌套子查询、外连接和窗口函数。这些操作在训练数据中不太常见,对文本到 SQL 系统的准确生成提出了挑战。设计可推广到各种 SQL 操作(包括罕见和复杂场景)的模型是一个重要的考虑因素。
NL2SQL的难度分级:
NL2SQL的研究方向:
首先,预处理步骤在NL2SQL过程中至关重要。
1.通过匹配增强,模式链接旨在识别与给定NL查询相关的表和列,以确保在有限输入下准确映射和处理关键信息;
2.通过提示增强,数据库内容检索(数据召回)侧重于高效提取特定SQL子句(如WHERE)的单元格值。高效地检索相关单元格值对于NL2SQL系统的性能至关重要,尤其是大型数据集。索引是通过更快访问相关单元格值来提高检索效率的关键方法之一。
3.通过语义增强,整合特定领域的知识来丰富上下文。即附加信息获取,这可以提高对查询上下文的增强理解,并纠正错误以防止其传播;
4.提示工程作为提升模型性能的关键步骤,通过精心设计提示内容显著影响了模型的生成质量。为了提高模型对SQL查询生成的准确性,采用多样本提示(few-shot prompting)已成为一种有效的优化方法。具体而言,通过提供多样化的高质量示例(金句)或SQL骨架,使模型具备处理复杂查询的能力。
其次是生成过程。
即大模型推理过程是指大模型通过输入得到输出的过程,对裸模型的优化提升,通常是经过预训练和微调的方法,但有着数据、计算资源需求量大,大模型闭源等问题,对于众多企业级数据分析并不适用。
链式思维提示(CoT)提高了生成结果的准确性和可解释性。在NL2SQL任务中,链式思维[109]增强了模型性能,并确保生成的SQL语句更符合人类预期。此外,将CoT与其他技术相结合可以增强NL2SQL模型的性能。这些技术包括在上下文中学习,逻辑合成,带提示校准,和多智能体系统。
分解策略将NL2SQL任务分解为顺序子任务,允许每个子模块专注于特定的生成步骤,从而提高准确度、质量和可解释性。
最终是后处理部分。
由于大模型的固有局限性,必然会存在检索生成结果语法错误、准确性不足的问题。以下是一些现有的解决方法
1.使用SQL矫正方法。由NL2SQL模型生成的SQL可能包含语法错误或不必要的关键字,如DESC、DISTINCT和聚合函数。虽然sql矫正专注于修复语法错误,但它们往往忽略了语义错误,例如不正确的表连接、对齐条件或不准确的汇总等,
2.引入了自我一致性。为了提高输出的一致性而引入,原理为基于复杂推理任务可能有多个有效的路径到一个正确的答案的想法。自一致性方法通过提高temperature参数并使用多数投票来选择最终结果,从而增强LLM输出的多样性,并选择最一致的答案来改善输出质量
3.通过执行结果进行判断。SQL 查询的执行结果校验提供了对 NL2SQL 翻译准确性的关键反馈。例如,在执行结果中的错误或空值可以指示SQL查询中存在的潜在问题。执行引导策略根据执行结果细化SQL,以确保查询正确检索数据。
4.使用其他模型进行重排序。N-best 重新排序会重新排序 top-k的模型输出,通常利用更大的模型或其他知识来源。例如,微调基于 BERT 的重新排序器。
NL2API介绍
对于NL2API,当前其自动化查询生成存在的固有问题大部分与NL2SQL类似,包括自然语言的不确定性、API库的庞大及复杂性、API格式生成的准确性,特别的是,核心分析逻辑 API 实现,需要极高的业务理解与抽象能力,同时,灵活性与扩展能力差,受限于已经实现与开放的API库。
现有难点:
不同标准的API架构差异大:如RESTFul API 标准和Graph API 标准;
缺乏泛化能力:企业内部的API一般采用私有格式,微调解决方案不适合大型应用程序的一般化数据访问;
长上下文问题:在进行提示词拼接时需要附带所有候选的API格式说明文档隐私保护问题当调用非己方的大模型时,提示词中的API文档易造成隐私泄露
现有研究很缺乏:目前知名的仅有不到十篇文献
现有研究:使用向量压缩检索解决长上下文问题;使用API文档格式化模块进行API注释、简化缓解长上下文问题;
代表性工作:LLM-powered GraphQL Generator :介绍了一种基于LLM的GraphQL查询生成器,接受自然语言输入和复杂的API模式,并自动生成所需的GraphQL或REST查询语句RESTful-Llama::最新的NL2API框架,使用向量检索减少API文档的长度,介绍一种构造微调数据集的方法。
NL2CODE介绍
NL2CODE:现有技术通常是基于LLM构建数据分析智能体,多智能体协作构成一个数据分析流程。
现有难点:
1.多智能体协作的复杂性:多智能体系统中的协作任务需要不同的模型或智能体高效配合。然而,这种协作模式面临幻觉累积的问题——单个智能体的错误可能在整个系统中传播并放大,最终导致不可控的结果。多智能体协作会增加token消耗,导致更高的计算成本。频繁的反馈交互还可能引入显著的延迟,降低用户体验和任务完成效率。这些挑战使得多智能体协作在大规模系统中的应用变得困难。
2.企业级数据分析任务通常涉及复杂的数据类型和多样化的需求。生成的代码需要能够精准处理这些数据,同时满足业务目标。然而,现有LLM智能体生成的代码往往不够精确。在复杂任务中,仅依赖训练数据中的知识往往难以生成高质量的代码。引入外部知识(如领域知识库或实时数据)能够显著提升生成结果的准确性,但当前模型在这一方面的能力仍然有限。这种不足不仅影响代码的准确性,还加剧了幻觉问题。
3.多智能体系统和复杂任务的执行需要大量计算资源和较长的交互时间。这种高资源需求显著提高了系统运行成本,尤其是在需要频繁调用LLM的情况下。此外,用户对响应速度和任务完成效率的期望也使得高延迟成为一个关键问题。如何在确保高效、准确地完成任务的同时降低成本和延迟,是当前基于LLM技术面临的主要挑战之一。
现有的研究方向有:
1.多智能体协作。在大量有效性工作中,作者们不约而同地使用多智能体协作作为智能体的主要改进方向。多智能体协作能有效改善对单个LLM的依赖,降低最终结果出错的概率。同时,多智能体协作进行任务分解,能有效提高对复杂企业级任务操作的准确性以及复杂代码生成的正确性。在LAMDBA[134]工作中,程序设计员和检查员两个核心智能体分别负责代码生成和错误评估。用户提交指令后,程序设计员编写代码并在系统内核中执行,若出现错误,检查员介入提供改进建议,形成迭代循环直至代码无误或达到最大尝试次数。
2.资源复用。资源复用能减少智能体的重复生成,降低成本,以及降低复杂任务的总计算时间。如本图中将成功案例进行本地保存。工作部署阶段,智能体结合历史数据,避免重复生成代码。
代表性工作:
Data-Copilot:基于大型语言模型的数据自动化工作流智能体,通过自行编写代码接口设计和调度,实现数据查询、处理和可视化。
Data Interpreter:数据分析agent框架,基于图进行任务分解,调用工具和代码生成进行数据分析。