-
赛题名称:Comprehensive RAG Benchmark Challenge
-
赛题类型:大模型、RAG
-
赛题任务:基于搜索引擎和图片的RAG
https://www.aicrowd.com/challenges/meta-comprehensive-rag-benchmark-kdd-cup-2024
赛题背景
研究表明,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 分。总体得分是对所有领域的宏平均,根据类型受欢迎程度和实体受欢迎程度加权(权重将不会公开)。
官方baseline:https://gitlab.aicrowd.com/aicrowd/challenges/meta-comprehensive-rag-benchmark-kdd-cup-2024/meta-comphrehensive-rag-benchmark-starter-kit/-/blob/master/docs/baselines.md
赛题分析
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。