先介绍下赛题：
![]()
赛题背景
研究表明，GPT4对快速变化事实的准确性通常低于35%。LLM（大型语言模型）基于AI代理可能出现幻觉性回应的频率取决于多种因素，包括训练数据中的偏见、缺乏上下文理解以及知识表示的限制。这些幻觉可能导致模型生成不准确或误导性信息。解决这一挑战对于确保LLM在提供准确信息方面的可信度至关重要。
![]()
为了提高LLM的准确性和可信度，可以考虑以下几种方法：
- 微调和校准：对LLM在特定领域或任务上进行微调可以提高其准确性并减少幻觉性回应。此外，校准模型以提供不确定性估计与回应可以帮助用户评估生成信息的可靠性。
- 外部知识整合：将外部知识源整合到LLM中可以帮助增强其理解能力并减少对幻觉性回应的依赖。检索增强生成（RAG）是一种利用外部资源提供有根据的答案的方法，从而提高生成响应的准确性。
尽管检索增强生成（RAG）具有潜力，但仍面临许多挑战，如选择最相关的信息来支撑答案、减少问答延迟和综合信息以回答复杂问题，这促使该领域的研究和开发工作。Meta Comprehensive RAG Challenge（CRAG）旨在提供一个具有清晰度量和评估协议的良好基准，以便对RAG系统进行严格评估、推动创新并推进解决方案的发展。
赛题任务
这个挑战包括三个旨在改进问答系统（QA）的任务。
![]()
任务1：基于Web的检索摘要
参与者每个问题收到5个网页，可能包含相关信息。目标是衡量系统将这些信息识别并概括为准确答案的能力。
任务2：知识图和Web增强
这项任务引入了模拟API，用于访问底层模拟知识图谱（KGs）中的信息，结构化数据可能与问题相关。参与者使用模拟API，输入从问题中派生的参数，以检索相关数据用于答案制定。评估重点是系统查询结构化数据和将信息从各种来源整合到全面答案的能力。
任务3：端到端RAG
第三个任务通过为每个问题提供50个网页和模拟API访问，遇到相关信息和噪音，增加了复杂性。它评估了系统从更大数据集中选择最重要数据的能力，反映了真实世界信息检索和整合的挑战。
评价指标
RAG系统使用一种评分方法进行评估，该方法衡量了对评估集中问题的响应质量。响应被评定为完美、可接受、缺失或不正确：
- 可接受：响应提供了对用户问题的有用答案，但可能包含轻微错误，不影响答案的有用性。
- 缺失：答案没有提供请求的信息。例如，“我不知道”，“很抱歉，我找不到……”或类似的句子，没有提供问题的具体答案。
- 不正确：响应提供错误或不相关的信息来回答用户问题。
分数如下所示：完美 = 1 分，可接受 = 0.5 分，缺失 = 0 分，不正确 = -1 分。总体得分是对所有领域的宏平均，根据类型受欢迎程度和实体受欢迎程度加权（权重将不会公开）。
赛题分析
CRAG基准测试包括五个领域、八种问题类型、变化的答案时间线和一系列实体流行度，包括头部、躯干和尾部事实以及简单和复杂的问题格式，以测试推理和综合能力。每个查询有30秒的时间预算，这也对候选解决方案提出了效率挑战。
三个赛题逐个递进，越往后越接近真实应用场景。第一个任务只涉及单一形式的多文档信息融合，而第二第三个涉及非结构化和结构化多源数据融合，后两个赛题的方案可以合并，并兼容第一个赛题的解决方案，对应结构化数据未覆盖时的兜底策略。
冠军方案
冠军来自北大的db3团队。该团队的解决方案在三个任务中均获得了第一名，分别达到了28.4%、42.7%和47.8%的得分。
任务一
![]()
数据预处理：
BeautifulSoup库从原始HTML中提取文本内容；
用LangChain的CharacterTextSplitter将文本分割成块；
用LangChain的ParentDocumentRetriever来管理父子块分割，保持包含关系；
retriever：bge-base-en-v1.5。由于相对较小的块有更好的检索精度，而较大的块保留更多信息，较小的子块，如单个句子，用于检索，而较大的父块，通常包含这些检索到的子块，整个段落被送入RAG系统。比赛中，较大的父块大小将为LLM提供更大的上下文，导致更多的推理时间，为平衡性能问题，选择parent_chunk_size=700，child_chunk_size=200作为基线。在提交的约束条件下，调整这些超参数，发现parent_chunk_size=500,1000,2000也是可以接受的。
reranker：bge-reranker-v2-m3。
为考虑性能问题，retriever召回数50。对于喂给LLM的chunk数，根据parent_chunk_size设定。例如，如果parent_chunk_size=2000，取5个chunk；如果parent_chunk_size=1000，取10个chunk。
收集公共数据做额外的信息增强。这些信息被预处理成段落，与网络搜索的内容结合起来，帮助LLM回答问题。不同领域的这些信息构建方式不同。对于电影领域，我们预处理了奥斯卡奖信息和完整的MovieLens数据。对于金融，我们预处理了美国每只股票当前的市盈率、市值和每股收益统计数据。对于音乐，我们预处理了格莱美奖信息。由于其他领域的信息有限，没有进行预处理。
具体来说，我们使用结构"The [entity attribute] is [value of the entity attribute]"将实体的表格/JSON数据序列化为自然语言格式。例如，对于特定的电影，预处理的格式是：标题是"雨人"。导演是Barry Levinson。主演是Dustin Hoffman和Tom Cruise。发行年份是1988年……我们使用相应实体作为key来存储预处理的信息，然后使用LLM通过上下文学习定位查询实体。
具体来说，我们首先根据领域提示定位问题领域：
![]()
因为开放领域问题通常包含其他领域内容，我们使用"other"而不是"open"。接下来，我们为不同领域设计不同的提示以查询实体。例如，对于电影实体提示：
![]()
![]()
关于LLM回答中实体与数据集中实体的匹配程度，根据问题域的特点，匹配标准从严格到宽松不等，包括精确字符匹配、子串包含或使用embedding模型计算相似度。
根据竞赛规则，正确答案将获得1分，错误答案将被罚1分。因此，竞赛期间的一个重要挑战是减少幻觉和处理无效问题。我们将介绍我们的LLM推理模块以应对这两个挑战。基础模型。我们按照竞赛说明使用LLama系列LLM。考虑到有限的运行时间，我们使用Llama-3-8B-instruct模型作为基础模型。
我们使用以下basic prompt来生成答案：
![]()
其中token_limit是我们想要控制的答案限制（因为超过75个token的答案将被截断），query_time是提问的时间，这在实时问题中至关重要，context_str是通过结合公共检索和网页检索的数据使用<doc>标记形成，然后根据最大token限制4000进行截断（请注意，之前的检索器的块大小是基于字符的，而这里是基于token的），query_str是查询。
幻觉可以通过prompt设计部分控制。提示中的某些指令可以阻止LLM生成错误事实。例如，我们可以使用以下受控提示来生成更高质量的答案：
![]()
对幻觉问题有一定改善，但仍不够好。因此，我们用SFT，基本原则是如果问题本身就不对，则拒绝回答；如果LLM自身都不包含这个知识，或者检索增强的结果里也没包含相关的知识，则让模型老老实实回答不知道，否则就学习groud truth的答案。训练数据构建如下：
考虑到有限的计算资源，使用LoRA对基础模型进行微调。
![]()
使用LoRA模型还有一个优势。我们可以微调几个LoRA模型，每个模型负责一个子任务。由于LoRA参数与LLM参数相比非常小，因此在子任务之间切换非常容易，节省时间。我们在训练集上对基础模型进行了2-3次迭代的微调。
最后用vLLM加速推理过程，但存在兼容性问题。
任务二和任务三
![]()
从网页中提取的信息比来自模拟API的信息噪声更大。因此，我们的框架将基于模拟API的结果和网页分开，优先考虑基于模拟API的结果。一旦基于模拟API内容的结果不是"我不知道"，我们就接受结果并直接输出。由于任务3有50个网页，考虑时间预算，为每个网页提供了一个页面片段。reranker根据片段找到前五个相关的网页，然后按照任务1中使用的方法进行处理。此外，我们没有在任务2和任务3中使用公共数据，因为它基本上被模拟API覆盖了。
知识图谱检索模块的主要思想是使用LLM生成一系列API调用，这些调用提取查询所询问的特定信息。API的规范化。对于每个query，只生成一个（或几个）API。从生成的规范化API中，我们使用解析系统获取生成的结果。然后，结果被转换为自然语言，形成我们检索模块的输出。以电影领域为例。原始电影API包括以下API调用：
![]()
这实际上在后台形成了一个关系数据库。有两个关系表：PERSON表和MOVIE表。例如，PERSON表有列：name，birthday，MOVIE表有列：title，release_date，original_title，original_language，budget，revenue，rating，genres，year。还有三个额外的表，它们有引用PERSON表和MOVIE表的外键，记录了人与电影之间的关系：CAST表，CREW表和OSCAR表。可以使用API调用构建这五个表的每个实体。因此，从理论上讲，我们可以使用SQL语言从这个关系数据库中查询信息，典型的text2sql任务。然而，由于时间预算，我们不可能多次调用API来形成一个关系数据库并在其上执行SQL。因此，我们设计了一种新型的规范化API，它易于解析和执行，并利用了关系数据库的特点。对于电影领域，我们设计了以下API：
![]()
使用这三个规范化API，大多数查询想要的信息可以通过几个API调用提取出来。更重要的是，这些API对LLM来说更容易生成，因为本质上，LLM只需要通过模板选择和提取实体名称。不涉及复杂的代码或SQL生成，这可能会带来更好的性能。我们为五个不同的领域设计了不同的API，但设计选择都是相似的。这些API的详细信息可以在我们的发布代码中找到。回答竞赛中的一些问题需要稍微修改上述API系统。例如，查询最新的斯皮尔伯格电影实际上需要排序功能。对于某些后续处理问题，涉及到数值计算。为了满足这些要求，我们在设计语料库中有其他一些生成词：
我们可以使用cmp (key_name,value_name)来设置条件。这里的cmp可以是neq, eq, ge和le，分别代表不等，等于，大于，小于。例如，eq(gender,male)，表示性别为男性的条件。条件可以是多个条件的列表，例如，[eq(gender,"male"),eq(character,"batman")]。
我们可以使用["len"]来获取结果的输出长度，我们可以使用AVG来获取输出的平均数值。
我们可以使用sort(condition,sort_key_name)来获取满足该条件的排序列表，列表使用sort_key_name进行排序。如果我们要降序排序，我们可以使用-sort_key_name。
这些都是编码函数或SQL中的函数的简化运算符。其他功能包括使用来表示上一个查询的输出，在另一个查询中使用，类似于SQL中的子列表功能。这可以完美适应多跳查询场景。遗憾的是，由于竞赛时间有限，我们没有完成这部分，我们期待在未来的系统中开发这样的功能。
我们手动开发了解析器以满足开发集中大多数查询的要求。这可能会影响该系统的泛化能力，因此如果提供了关系数据库，使用标准SQL执行引擎可能是一个更好的选择。解析器的输出被转换为自然语言，以便即使提取了不相关信息，LLM也可能意识到这一点并拒绝回答。新规范化API的示例。以下是电影领域中新规范化API的三个理想示例：
![]()
API生成prompt如下：
![]()
在这里，Schema_info是对底层关系数据库模式的一些描述，限制LLM生成关系表中的键名，API_rules是上面小节中描述的生成API的规则，query_str是问题，ICL_examples是一些手动选择的查询和API对的上下文学习示例。在这里，上下文学习示例是手动迭代选择的。首先选择一些示例，然后我们使用LLM生成100个示例。然后，将生成错误示例的查询添加到示例中。值得注意的是，在这种情况下选择相关的ICL示例可能极其有效，因为对于类似的查询，只需要替换实体名称。我们还没有实现这个功能，但我们相信它可能会取得很好的结果。不同领域的这个提示的详细信息可以在源码中找到。
API生成的微调。通过实验，我们观察到使用提示仍然需要LLM具有相对较强能力。强大的LLM，例如GPT-4，比本地Llama3 8B表现更好。因此我们希望微调本地LLM可以提高API生成的性能。对于微调真值数据，我们使用GPT-4和提示生成第一版ground truth API。然后，我们手动标记ground truth API以获得更高质量的数据。我们还使用LoRA对基础Llama3模型进行微调，因为我们需要在时间预算下高效地切换不同的LoRA参数。
sft参数和LLM推理部分同任务一。
评价
冠军队伍学术背景跟数据库比较相关，所以技术方案上我们发现有大量专家经验的API重设计，prompt设计，sft也是利用更高级LLM辅助制作训练数据，以及利用公开数据增强。整体上看方案上非常接地气，没有太多花里胡哨的“炫技”。实际上LLM相比几年前的bot，技术能力确实大大提高，解决方案的标准化程度也大大提高，但真正要准确可靠的解决实际业务问题（除了容错性高的部分领域，如文字创作等），还差“最后一公里”。本文给了一个很好的范例/缩影，那些在做LLM ToB方向的公司或者大厂部门，为传统企业做数字化转型升级，以及数据分析Agent相关场景，到底都在怎么优化，才能真正让LLM达到实用状态。
附录
比赛地址：https://www.aicrowd.com/challenges/meta-comprehensive-rag-benchmark-kdd-cup-2024
论文：https://arxiv.org/pdf/2410.00005
代码：https://gitlab.aicrowd.com/jiazunchen/kdd2024cup-crag-db3
备注：进群，进入大模型技术群
![]()
微信号：baobaogpt，记得备注呦
