-推荐关注-
大语言模型(LLMs)通过整合外部数据(如检索增强生成RAG)显著提升任务完成能力。然而,不同查询难度对系统设计提出了独特挑战。本文将查询分为显性事实、隐性事实、明确推理依据及隐性推理依据四级,揭示问题复杂性递增对数据检索、逻辑推断及背景知识整合的需求。
Level-1 显式事实查询(Explicit Fact Queries) Level-2 隐式事实查询(Implicit Fact Queries) Level-3 明确推理依据的查询(Interpretable Rationale Queries) Level-4 隐性推理依据的查询(Hidden Rationale Queries) 给LLMs整合外部数据的三种主要形式 参考
-- 领取学习资料大礼包,见文末
大语言模型(LLMs)通过外部数据的增强后,在完成任务方面展现出了显著的能力。
外部数据不仅增强了模型的特定领域专业知识和时间相关性,还降低了幻觉现象的发生率,从而提高了输出的可控性和可解释性。
将外部数据整合到LLMs的技术,如检索增强生成(RAG)和微调,正受到越来越多的关注并广泛应用。然而,在各个专业领域中,有效部署经过数据增强的LLMs时,面临着重大挑战。
这些挑战涵盖了从检索相关数据、准确解释用户意图到充分利用LLMs的推理能力以完成复杂任务等一系列问题。
在实践中,表现不佳通常是由于未能正确识别任务的核心焦点,或者因为任务本质上需要多种能力的结合。
根据所需要的外部数据类型和任务的主要焦点将用户的查询任务分为四个级别:
显式事实查询、隐式事实查询、明确推理依据的查询和隐性推理依据的查询。
这4个查询级别可以根据提供的内容不同分为“提供事实”和“提供推理依据”两大类别,揭示了问题复杂性与所需外部数据内容之间的逐步递增关系。
“提供事实”专注于直接回答具体的问题,核心在于从外部数据中检索相关信息,依据其显性或隐性的程度进一步分级。
显性事实(L1)通常可以通过一个明确的文本片段直接回答问题,难度较低,依赖单一数据源即可解决;
隐性事实(L2)则需要整合多个数据来源,建立逻辑关联进行推断,这对信息的关联性与解释能力提出了更高要求。
相比之下,“提供推理依据”则更注重基于外部数据的逻辑分析和解释,不仅需要找到相关信息,还需结合具体场景进行合理推断。“提供推理依据”的难度明显高于“提供事实”,可分为两种类型:明确的推理依据和隐性推理依据。
明确推理依据(L3)需要基于明确的规则或条件,通过逻辑匹配得出结论,虽然复杂,但推理路径是透明和可验证的。
隐性推理依据(L4)涉及更加开放性和复杂的问题,例如预测经济趋势对企业发展的影响,这类问题往往需要从多维度数据中抽取潜在模式并进行深度分析,推理路径更加隐含且对背景知识的依赖性更强。
因此,“提供事实”和“提供推理依据”的区别在于答案获取方式:前者以直接数据检索为主,而后者需要逻辑分析与解释。
难度上,随着分级从显性事实到隐性推理递进,问题对信息整合、逻辑推断以及背景知识的要求逐步增强,对RAG系统的能力提出更高挑战。
Level-1 显式事实查询(Explicit Fact Queries)
这个级别的查询主要需要正确检索数据以提供准确的响应,无需任何额外的推理。这是最简单的查询形式。其中模型的任务主要是定位并提取信息。
例如,“2024 年夏季奥运会将在哪里举办?”针对的是外部数据中的一个事实。
由于其有效性、灵活性和相对较低的成本,RAG是处理此级别查询最常采用的技术解决方案。然而,即使使用 RAG,在构建一个强大且高质量的系统时仍然面临一些挑战,如:数据处理困难、数据检索困难、评估RAG的性能复杂
Level-2 隐式事实查询(Implicit Fact Queries)
这些查询涉及的数据依赖关系并不立即显而易见,所需的信息可能分散在多个部分,或需要简单的推断。
这一层次查询所需信息的集合可能超出单个检索请求的能力,因此需要将原始查询分解为多个检索操作,并将结果汇总成一个全面的答案。这一层次通常涉及常识推理,而不需要特定领域的专业知识。这类查询可能包括统计查询、描述性分析查询和基本聚合查询。例如,诸如计数、比较、趋势分析和选择性总结等操作,在“有多少”和“最什么”类型的查询中很常见
查询问题举例:
有多少实验的样本量大于 1000?(给定一组实验记录)
最常提到的三个症状是什么?(给定一系列医疗记录)
公司 X 和公司 Y 的人工智能策略有什么区别?(给定关于公司 X 和 Y 的最新新闻和文章)
在这个层次上,查询仍然围绕事实问题展开,但答案并没有在任何单一文本段落中明确呈现。相反,它们需要通过常识推理结合多个事实来得出结论
对于这个层次的查询,需要面对的问题主要包括以下几点:
信息分散:所需信息可能分散在多个数据段或文档中,无法从单一文本片段中直接获取答案. 复杂推理需求:需要进行常识推理或基本逻辑推断,才能从分散的信息中得出结论. 自适应检索量:不同问题需要检索的信息量不同,固定数量的检索可能导致信息不足或冗余. 推理与检索的协调:推理过程需要指导检索的重点,而检索到的信息又需要反馈到推理过程中,两者之间的协调较为复杂. 多跳推理:一些查询需要通过多跳推理才能得到答案,即需要多次检索和推理才能逐步接近最终答案.
为了解决这些问题,可以考虑以下几种方案:
迭代RAG:
规划驱动:在检索前或检索过程中生成逐步检索计划,逐步缩小知识差距,如ReAct、IRCoT和RAT等方法. 信息缺口填补驱动:先生成基于现有知识的答案,然后继续检索和生成以填补答案中的未知部分,如ITRG和FLARE等方法.
传统知识图谱:利用知识图谱来增强LLMs的理解能力,如Rigel-KQGA模型、Think-on-Graph和KnowledgeNavigator等方法. 数据块图/树:将文本块或数据块作为图或树的节点,利用边表示文本块之间的关系,如Knowledge-Graph-Prompting、MoGG和RAPTOR等方法.
Level-3 明确推理依据的查询(Interpretable Rationale Queries)
这些查询不仅要求对事实内容的把握,还要求具备理解和应用推理依据的能力,这些依据对于数据的上下文至关重要。通常在外部资源中明确提供,而且在通用大型语言模型的预训练阶段通常不存在或很少遇到。
例如,在制药领域,LLM 必须解读食品药品监督管理局指南,以评估特定药物申请是否符合监管要求。同样,在客户服务场景中,LLM 必须应对预定义工作流程的复杂性,以有效处理用户咨询。在医学领域,许多诊断手册提供权威和标准化的诊断标准,例如针对急性胸痛患者的管理指南。通过有效遵循这些外部依据,有可能开发出专门用于管理胸痛的 LLM 专家系统。
查询问题举例:
如何对胸痛患者及其特定症状描述进行诊断和治疗(给定胸痛管理指南)
如何在现实场景中回应用户的问题?(给定客户服务工作流程)
对于这个层次的查询,需要面对的问题主要包括以下几点:
提示优化成本高:优化提示的过程需要大量的时间和计算资源。不同的查询需要量身定制的背景知识和决策标准,这需要各种示例。手动设计的提示虽然有效,但劳动密集且耗时,而训练模型为各种查询生成量身定制的提示会产生显著的计算开销。 有限的可解释性:提示对 LLM 的影响是不透明的,通常无法直接访问 LLM 的内部参数,难以确定各种提示对模型的具体影响,这阻碍了对 LLM 响应的可解释性进行一致的理解和验证。 数据处理和检索问题:需要有效处理和解析非结构化、多模式的外部数据(如表格、图像等),并且要从海量外部数据中准确检索出所需的片段 多步推理的复杂性:可解释推理查询常常涉及多步推理,需要模型逐步收集信息,然后综合生成答案
为了解决这些问题,可以考虑以下几种方案:
提示调整技术:通过提示调整技术来增强 LLM 遵循特定推理的能力。例如,使用强化学习来设计提示,将提示的优化问题转化为一个强化学习问题,通过奖励机制引导模型发现最佳提示配置。此外,还可以采用基于编辑的方法,如 GrIPS,通过尝试各种提示修改(包括删除、交换、改写和添加)来迅速有效地确定最有效的提示配置。 链式思维(CoT)提示:引导模型进行多步骤的推理,通过手动设计或自动化生成 CoT 提示,使模型能够按照指定的逻辑和步骤进行推理。例如,Automate-CoT 通过从最小标记数据集中生成增强理性链,采用方差缩减策略来评估每个 CoT 链的重要性,从而促进最有效提示组合的选择。 利用 LLM 本身进行提示优化:使用 LLM 生成新的提示解决方案并对其进行评分,从而简化优化过程。例如,OPRO 通过 LLM 生成基于历史数据及其相关性能指标的新提示解决方案,并对这些提示进行评分。此外,Reflexion 框架引入了一种基于语言反馈的提示优化新方法,使用语言模型分析和存储对 LLM 输出的反思在情节记忆缓冲区中,利用积累的历史见解来完善决策过程和评估结果。 构建Agent工作流:以 LLM 为中心构建Agent工作流,将明确依据的推理整合到多个模块中,使Agent能够根据环境或人类反馈进行适应和迭代。例如,在客户服务和医学问答等领域,设计了复杂的代理系统,这些系统不仅提高了互动质量,还提高了响应的效率和准确性。
Level-4 隐性推理依据的查询(Hidden Rationale Queries)
这一类查询深入探究更具挑战性的领域,其中的推理依据没有明确记录,必须从外部数据中观察到的模式和结果来推断。这里的隐藏依据不仅在于隐含的推理链条和逻辑关系,还包括要识别和提取每个查询所需的外部依据,这非常具有挑战性。
例如,在 IT 运营场景中,云运营团队可能在过去处理过众多事件,每个事件都有其独特的环境和解决方案。LLM 必须擅长挖掘这一丰富的隐性知识库,以辨别隐含策略和成功决策过程。同样,在软件开发中,之前错误的调试历史可以提供大量的隐含见解。虽然每个调试决策的逐步依据可能没有系统记录,但 LLM 必须能够提取指导这些决策的基本原则。通过综合这些隐藏的依据,LLM 可以生成不仅准确而且反映经验丰富的专业人士所磨砺出的未言明专业知识和解决方法。
查询问题举例:
经济形势将如何影响公司的未来发展?(给定一系列财务报告,需提供经济和财务依据)
对于这个层次的查询,需要面对的问题主要包括以下几点:
逻辑检索困难:
外部数据的有用性不仅依赖于语义上的相似性,更关键的是逻辑上的一致性或与主题的对齐。传统的检索方法通常难以捕捉到查询的真正目标,或者无法识别在逻辑上相关的文本段落。例如,一个涉及法律案例分析的查询,系统不仅需要检索包含相同法律条款的文档,还需要找到逻辑上类似的判例或相关的法律解释。
数据不足:
外部数据可能并不直接包含解决当前查询的所有必要信息。相关信息通常散布在不同的知识领域中,或者通过示例间接体现。这种间接呈现要求模型具备强大的数据解释和综合能力,能够从分散的或间接相关的数据源中推导出连贯的答案。
为了解决这些问题,可以考虑以下几种方案:
离线学习:
通过离线分析数据集来识别和提取规则和指导。例如,一些工作如 STaR 和 LXS 使用 LLM 生成推理理由。其他方法如 GL 通过上下文学习识别错误,并将其概括为未来任务的指南;LEAP 通过生成错误、低级原则和高级原则来形成原则,将这些原则纳入提示中进行最终推理。
上下文学习 (ICL):
利用示例进行上下文学习,利用 LLMs 的少量样本学习能力。预训练的大型语言模型展现出相当大的上下文学习能力,可以通过基于相似性的示例检索来增强。例如,OpenICL 构建了一个 ICL 框架,探索了不同传统示例检索方法和推理技术对 ICL 效果的影响。
微调 (Fine-Tuning):
微调能够利用 LLM 在预训练期间获得的广泛基础性知识,同时使其能够迅速掌握新领域的理由。例如,通过指令微调,可以向 LLM 注入新能力,通常涉及使用配对的(指令,输出)数据进行监督微调。此外,一些方法如 Adapter Tuning、Prefix Tuning 和 Prompt Tuning 等,通过在模型中添加小的可训练组件来减少微调的成本。
给LLMs整合外部数据的三种主要形式
在开发针对 LLM 应用程序之前,作为领域专家,我们必须深入了解预期任务,确定相关查询的复杂性水平,并选择相应的技术方法作为解决方案。这些方法主要通过三种机制将知识注入到LLMs
a) 通过查询提取部分领域数据作为 LLM 的上下文输入,
b) 使用特定领域数据训练一个较小的模型,然后用这个小模型来辅助指导外部信息整合,并输入到 LLM 中,
c) 直接使用外部领域知识对通用大型语言模型进行微调,使其成为领域专家模型。
这三种策略在数据量、训练时间和计算资源的要求上各不相同,分别递增。
通过上下文进行知识注入提供了更好的可解释性和稳定性,但由于有限的上下文窗口和中间可能的信息丢失,面临着局限性,理想情况下适用于可以在较短文本中简洁解释的数据场景。然而,这种方法对模型的检索能力和知识提取能力提出了挑战。
小模型方法的优势在于减少训练时间和能够吸收大量数据,但其有效性取决于模型的能力,可能限制LLM在更复杂任务中的表现,并随着数据的增加而产生额外的训练成本。
微调很好的利用了具有广泛领域数据的大模型能力,但其对LLM的影响在很大程度上取决于所使用数据的设计。使用领域外的事实数据进行微调可能会无意中导致LLM生成更多错误输出,同时也有可能导致之前已知领域知识的丧失以及在微调过程中忽视未遇到的任务。
因此,选择合适的策略给LLM进行知识注入,需要对数据源有透彻的理解,并基于这一理解进行最优的决策。
参考
https://arxiv.org/abs/2409.14924
为什么提示词总出错?使用思维链(CoT)提升效果高达 78%!
有需要的,在公众号「AI取经路」发消息「学习资料」即可获取。
--END--
点亮“赞”和“在看”,“分享”好友一起看