链载Ai

标题: 构建“生产就绪”的企业级RAG应用的6大优化考量【下】 [打印本页]

作者: 链载Ai    时间: 前天 11:11
标题: 构建“生产就绪”的企业级RAG应用的6大优化考量【下】


多模态文档处理

企业中有很多的知识并不总是简单的文字形态,很多是以半结构化与非结构化文档的形式存在,最常见的就是图、文、表混排的PDF文档。针对复杂PDF文档的解析、分割与向量化是常见的一种复杂知识处理需求,且在实际应用中达到的效果往往不尽如人意(有少量原因是一些文档自身排版与格式的过度随意与不规范)。
处理复杂多模态文档一般需要借助到第三方的PDF解析工具、多模态大模型、关联检索等技术。整体上的思路如下:

以最常见的复杂PDF处理为例:

1. 借助解析工具从PDF中分类提取Text、Table、Image不同形态内容;提取的Table内容一般用Markdown文本等表示,Image则提取成本地或网络文件。
2. 对不同形态的提取内容采用不同的索引与检索方法处理:
3. 在查询阶段,将上述检索出来的关联知识输入大模型进行生成,注意如果需要输入原始图片,则需要借助多模态模型进行响应生成。
上述流程中主要涉及到三种关键技术:

文档解析


主要针对半结构化/结构化的PDF文档解析与提取,考虑的工具为:

多模态模型 & OCR


多模态视觉模型可以借助在线的智谱GLM-4v,阿里qwen-vl,Openai的GPT-4o,或部署开源的Llava模型等。如果希望提取图像中的文本信息(如文字扫描图像),则需要结合OCR技术:

关联检索


在将多模态内容输入给LLM生成时,往往需要借助关联检索从向量检索出来的Chunk关联到原始的表格内容或者图片,这种关联检索在常见的两种框架中都有支持:

高级检索与查询重写

高级检索请参考独立文章:一文说清大模型RAG应用中的两种高级检索模式:你还只知道向量检索吗?
查询重写(也可以称作查询转换,或者查询分析等),已经成为大模型应用中一种很重要的工作环节。有时,用户查询可能不够明确或不够具体,这就需要查询重写以提高检索准确性。因此,查询转换是一种“检索前”的流程环节,用于将输入问题更换成一种或者多种其他形式的查询输入。
我们介绍RAG应用中常见的四种查询重写策略:

HyDE重写


HyDE(Hypothetical Document Embeddings,假设性文档嵌入)是一种已经被证明在很多场景下有着较好效果的查询改写技术。其基本过程是:
  1. 根据输入问题,生成一个假设性的答案。注意,这个答案来自LLM本身的知识,可能包含错误或者不够准确。
  2. 对该假设性的答案进行嵌入,并检索出具有相似向量的知识块(可以同时携带原问题)。
  3. 用检索出的知识块和原问题借助LLM生成最终答案。
HyDE方案被证明在很多场景下可以提高检索的准确率,但缺点在于假设文档有可能误导查询或者引入偏差,需要谨慎使用。

分步问题重写


分步问题重写的思想为:从初始的复杂查询开始,经过多步的查询转换与检索生成,直至能够完整的回答输入问题。每一次转换都基于之前的推理过程,提出下一步的问题,通常是为了解答原问题所需要的一个步骤中的问题。以一个例子说明:“2022年世界杯冠军球队的成员有哪些?”,那么基本过程如下:
  1. 分解出第一个问题:“2022年世界杯冠军球队是哪个国家队?”,然后首先查询出该问题的答案。
  2. 根据原问题以及之前的推理过程,分解出第二个问题:“2022年世界杯阿根廷国家队球员有哪些球员?”
  3. 对分解出的第二个问题进行查询,并得出最终答案。

分步问题重写过程有点类似Agent完成任务的推理过程:观察已有的过程,并根据原始问题,推理下一步的问题。

子问题重写


与分步问题重写类似的是子问题重写。子问题重写是在问答时通过生成与原问题相关的多个具体的子问题,帮助更好的解释与理解原问题,并有助于得出最终答案。其基本过程是:
  1. 将输入问题借助LLM生成多个相关的子问题,这些子问题可以是LLM自身可以回答,也可以是借助某个已有的RAG引擎能够回答。
  2. 对多个子问题进行查询,通过检索生成,得出子问题的答案。
  3. 根据多个子问题的答案与原问题,推理并合成,输出最终问题答案。

子问题重写也类似Agent在完成任务过程中的子任务分解 ,因此在实际应用中常常会利用Agent的思想:将一个问题推理分解成可以由多个RAG引擎(或Agent工具)回答的子问题,各自完成后合成答案。

后退问题重写


后退问题重写通常用来引导LLM从具体事例中提取出更加通用或关于基本原理的问题,再利用这些问题的答案重新推理原问题的答案。这种方法可以显著提高LLM遵循正确的推理路径解决问题的能力。其基本过程是:
  1. 借助LLM将原问题解释为一个更通用的后退问题。比如原问题是“Joe出生在哪个国家?在哪里度过了他的童年”。生成的后退问题可能是“Joe的生平经历有哪些”。
  2. 对重写的后退问题进行RAG检索与生成,获得相关的知识内容与答案。
  3. 将重写问题的生成答案、原问题输入(也可结合原问题检索的相关知识)再次通过LLM进行生成,输出最终答案。

RAG应用评估

在将一个软件投入应用与生产之前,传统软件过程中一个必不可少的流程环节是软件测试与评估,这是验证与衡量软件是否具备上线与生产条件的重要手段。具体到RAG应用(包括Agent),作为一种新的人工智能时代的应用形式,这个环节仍然举足轻重,甚至显得比传统应用更加重要,这源自于:
基于大模型的RAG应用与传统的软件应用还有一个很大的不同:传统应用软件的输出大多是确定且易于衡量的,比如输出一个确定的数值;而RAG应用中的输入输出都是自然语言,评估其相关性与准确性等都无法通过简单的定量判断,往往需要借助基于更智能的工具与评估模型来完成。

评估依据与指标


RAG应用评估的依据,也即评估模块的输入一般包括以下要素:
基于这些评估的依据,对RAG应用进行评估的常见指标有:
名称


相关输入


解释


正确性


correctness


answer


reference_answer


生成的答案与参考答案的匹配度。往往涵盖了回答的语意相似度与事实相似度。


语义相似度


Semantic Similarity


answer


reference_answer


生成的答案与参考答案在语义上的相似度。


忠实度


faithfulness


answer


contexts


答案与检索出的上下文的一致性。即答案内容是否能从检索出的context中推理出来。或者说,是否存在幻觉。


上下文相关性


Context


relevancy


contexts


question


检索出的上下文与用户问题之间的相关性。即上下文中有多少内容是和输入question相关。


答案相关性


Answer


relevancy


answer


question


答案与用户问题的相关性。即答案是否完整且不冗余地回答了输入问题,此次不考虑答案的正确性。


上下文精度


Context


precision


contexts


reference_answer


检索出的相关上下文中与正确答案相关的条目是否排名较高。


上下文召回率


Context


recall


contexts


reference_answer


检索出的相关上下文与正确答案之间的一致程度。即正确答案的内容是否能够归因到上下文。



RAG评估技术


RAG应用的评估可以借助开发框架自身的评估工具与模块:
也可借助第三方的评估框架,它们通常与上述框架具有较好的集成性,比如:








欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5