支持私有化部署
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


OneEval:OpenKG发布大模型知识增强综合能力评测榜单

发布日期:2025-04-12 05:26:59 浏览次数: 1575 作者:开放知识图谱
推荐语

OneEval评测榜单,专注评估大模型与知识库融合能力,推动知识增强型大模型发展。

核心内容:
1. OneEval评测榜单的成立背景与目的
2. 评测框架与任务设计,涵盖知识载体和关键领域
3. 评测流程和防作弊机制的介绍

杨芳贤
53A创始人/腾讯云(TVP)最具价值专家
OpenKG.SIGEval
大模型知识增强系统评测-OneEval






官网:http://oneeval.openkg.cn/











1. 引言









OneEval 是由OpenKG发起并组织的中立、公益、专业的大模型评测榜单。区别于多数聚焦于“LLM”基础能力评测的现有榜单,OneEval 更加侧重于“大模型 + 知识库(LLM+KB)”的融合能力评估,重点考察知识增强驱动下大模型的慢思维能力(即模型在复杂问题上的深度思考与分步推理能力)与神经符号混合推理能力(结合神经网络与符号逻辑的知识推理能力),助力大模型向“知识深、思维强”的方向持续演进。


随着大语言模型(LLMs)的快速发展,最新一代推理型模型(如 OpenAI o1、DeepSeek R1、Grok 3、Claude 3.7 Sonnet 等)在自然语言理解与推理任务中表现出显著进步。尽管已有多项研究[1-4]从不同维度对 LLM 能力展开评估,但这些评测体系主要集中在通用理解和基础推理层面,缺乏模型在处理多类型异构知识与跨领域复杂推理任务中的系统性评估。特别是在知识增强场景下,模型如何有效利用外部知识源进行高质量推理的能力评估仍是研究空白。


在此背景下,OpenKG 推出 OneEval,希望为知识增强场景下的大模型综合能力评估提供一个系统化框架。OneEval V1.0包含十个典型任务,涉及四类知识载体(文本、表格、知识图谱与代码)和六大关键领域(通用、医学、政务、科学、法律与编程),旨在深入衡量大模型对多种知识形态与多领域语境中的知识理解、知识利用与知识推理能力。整体评测框架如图1所示。

图1 OneEvali评测框架示意图

OneEval 由 OpenKG SIGEval 工作组持续维护,评测数据与结果将定期更新,评测流程也将逐步引入多元防作弊机制,包括样本变体生成、模型输出标准化、多次采样验证、时效性验证以及对抗性问题构建等技术手段,并在可行范围内公开评测细节,努力保障评测的科学性、透明性与公平性。











2. 相关工作









在LLM的能力评估方面,已有许多国内外基准测试和排行榜对广泛的任务进行了探索与测试。大多数现有的基准测试可以被分为四个类别:

(1) 知识考察型:以客观选择题和问答题等形式测试模型的学科知识掌握水平,包括MMLU[1]、CMMLU[2]、CEval[3]、AGIEval[4]等。

(2) 指令遵循型:以问答等形式评估模型对用户指令的遵循能力,包括LLMBAR[5]、Flan[6]、NaturalInstructions[7]等基准测试。

(3) 聊天对话型:使用多轮交互的问答数据测试模型的上下文理解和对话能力,包括CoQA[8]、MMDialog[9]、MT-Bench[10]和OpenAssistant[11]等。

(4) 安全风险型:以选择题和问答题等形式评估模型的安全与幻觉风险,例如DecodingTrust[12]、AdvGLUE[13]、StrongReject[14]、HarmBench[15]等。


与单一基准测试不同,现有的知名排行榜通过整合多个评测任务、整理广泛评估场景,采用多维度、多任务的评估方法,构建更全面的大模型能力画像。HuggingFace 的 Open LLM Leaderboard 整合了 MMLU-Pro、GPQA、MuSR、MATH、IFEval 和 BBH 等六个基准测试,综合考核模型在知识理解、推理、数学解题、信息抽取和复杂任务处理等方面的能力。上海AI Lab的OpenCompass(司南)[17]构建了包括考试、知识、语言、理解、推理和安全六个维度的评测框架,通过引入动态更新的评测数据集确保评估的时效性和广度。来自北京智源的FlagEval(天秤)整合了30多项能力维度与30个基准测试,构建了超10万条评测样本的大规模评测库,包含文本、图像、音频等多模态信息。除基于标准化数据集的评测外,基于人类偏好的比较性评测近年来也获得广泛关注。来自UCB的Chatbot Arena Leaderboard(聊天竞技场)[18]创新性地采用众包+Elo排名机制,让人类评估者对模型回复质量进行两两比较,累积得出模型间的相对实力排名。斯坦福大学的AlpacaEval[19]则引入“LLM-as-a-Judge”方法,利用大模型作为评判,通过比较待测模型与参考模型回复的优劣,将相对胜率作为排名依据,大幅提升了评测的规模与效率。


然而,现有的基准测试体系仍存在一些不足:(1)缺乏对复杂知识库推理能力的评估;(2)知识载体单一,尚未全面涵盖如知识图谱、代码、表格结构化知识的测试维度。针对上述问题,OneEval 首次构建了统一的跨知识源、多领域复杂知识库推理任务评测框架,力求在评估大模型知识增强能力方面实现更高的覆盖性与科学性。












3. OneEval评测数据集









OneEval主要基于OpenKG自建或整理的公开数据资源,并将周期性增加和更新。第一批OneEval V1.0包含十个面向多类型知识库的推理评测数据集,覆盖结构化与非结构化、显性与隐性等多种知识形态,具有更高的知识特异性任务复杂度。相较于 MMLU、BigBench 等侧重通识能力的评测基准,OneEval 更聚焦于大模型在多源异构知识库中的深层理解与综合推理能力评估,以更贴近真实应用场景的方式推动知识增强型模型能力评测。评测数据集来源信息如表1所示。

表1 OneEval评测数据集来源信息



以下将从知识库类型、任务类别和领域类别三个维度详细介绍OneEval评测体系。


3.1
知识库类型

OneEval V1.0基准涉及以下4种类型的知识库,后续还将增强更多的知识库类型:

  • 文本知识库:涵盖非结构化文献与文档,测试模型在文本型知识的理解,以及复杂语境下的语义建构、信息抽取等能力。

  • 表格知识库:以结构化表格数据为基础,考查模型在结构化知识的理解,以及对数值、分类与层级信息的处理、比较与逻辑计算能力。

  • 知识图谱:基于实体-关系三元组构建的结构化语义网络,评估模型在图结构知识的理解,以及多跳推理、实体对齐与关系识别等任务中的表现。

  • 代码知识库:包含函数文档、源代码与API说明,聚焦模型在程序型知识的理解,以及代码补全、自然语言到代码生成等能力。

表2 OneEval评测数据集任务类型与统计信息


更新表2.png


3.2
任务类别

根据知识库的类型,OneEval V1.0基准的评测数据可以被分为以下四个任务类别:

  • 文本推理:基于从非结构化文本知识库(科学文献,法律文书)中检索到的上下文信息,进行语义理解与推理,以回答问题或判断陈述的真伪。

  • 知识图谱推理:借助从结构化知识图谱中检索到的三元组,对输入的问题进行多跳推理,或对错误三元组进行识别与纠正。

  • 表格推理:基于从格知识库中检索得到的上下文信息,对表中数据进行计算、比较、聚合等操作,以推理并回答输入的问题。

  • 代码推理:基于从代码知识库(如开源代码库、API文档等)中检索的相关代码,实现对输入自然语言描述的程序化理解与细粒度代码生成。


3.3
领域类别

OneEval V1.0覆盖通用、医疗、政务、科学、法律与编程六大关键知识领域,重点强调多源异构知识的广泛性与专业性,系统性评估LLM在复杂知识驱动任务中的推理与应用能力。具体类别信息如图2所示。

图2 OneEval评测数据集领域信息

  • 通用(Open-domain):基于百科全书与综合性知识资源,涵盖来自各类百科知识库的开放领域知识,考察模型对跨主题背景知识的理解与迁移能力。

  • 医疗(Medical):基于医疗诊断任务,融合生理学、药理学与临床医学等细分知识体系,评估模型对专业医学术语和复杂病例的理解与诊断推理能力。

  • 政务(Politics):基于中文政务文件与政府官网信息,聚焦政策条文、行政流程等结构化与半结构化知识,考验模型对规章制度的精准解析与政策应用能力。

  • 科学(Science):整合来自生物、材料科学公开文献及生物医药知识图谱的专业知识,涵盖实验事实、领域术语与科学推理模式,测试模型的科学推理与知识整合能力。

  • 法律(Law):源自真实法律文书,包含判决书、裁定书等法律事实与规则,突出模型对法律条文逻辑与案例事实的结合推理能力。

  • 编程(Code):来自GitHub的海量开源代码库,跨越300+依赖库和2000+ API 版本,强调模型对程序语言、函数接口及语义执行的深入理解与生成能力。


3.4
OneEval-Hard

为更精准地评估LLM在高难度推理场景下的表现,我们基于多轮筛选和专家评审人工构建了一个困难样本子集——OneEval-Hard,共计1285个样本,专门聚焦于模型在多步推理、隐式知识关联和跨域知识整合等推理任务中的薄弱环节。该子集不仅具备更高的判别性和难度,也为深入剖析LLM的知识盲区与推理瓶颈提供了重要测试依据,有助于推动更有针对性的LLM优化与能力提升。












4. OneEval评测框架









OneEval 评测框架(见图1)旨在系统化评估LLM在借助外部知识库完成推理任务时的表现,重点考察模型对各类知识库的理解能力及其有效运用方式。整个评测过程保持 LLM 参数不变,通过结合用户输入与检索到的外部知识构建提示,引导模型进行推理并按照任务的目标形式生成答案。


4.1
带知识上下文的提示

对于每个测试样本,模型接收的提示由以下三部分组成:

  • 任务指令:用于明确任务的输入输出格式及其映射关系;

  • 用户输入:经过标准化处理的用户原始请求,形式可能包括自然语言问题、陈述、代码片段或功能描述等;

  • 知识上下文:从相应类型的知识库中检索出的相关信息,包括文本段落、表格数据、代码片段或知识图谱三元组等。所有结构化数据均转换为文本格式以适配LLM输入接口。


4.2
外部知识检索范式

由于本评测框架重点在于评估LLM在对各种类型的知识理解和运用能力,而非检索知识的能力,因此,对于涉及外部知识的任务,采用统一的检索范式,获取与测试样本相关的上下文信息。具体而言,基于Dense Retrieval的思路,其核心在于按用户输入与知识片段(文本片段、代码片段、三元组子图等)的稠密向量(q,K)之间的相似度S进行排序,选取top-k知识片段作为知识上下文。S的计算公式如下:

S(q, K) = cos(q, K)

其中,qK分别表示由SentenceBERT模型编码得到的用户输入向量和知识向量。需要注意的是,通过上述方式检索获得的外部知识上下文中可能包含噪声。这种设置更贴近真实应用场景,为评估模型在面对不完美或冗余知识时的鲁棒性提供了有效的测试环境。


4.3
评测对象

本次版本的评测选择了多个国内外领先的研究团队和企业,涵盖开源与闭源、不同参数规模及不同技术路线的代表性LLM,详细信息如表3所示(按首字母排序)。

表3 评测对象统计信息


更新表3.png

鉴于评测资源与时间成本的限制,目前仍有部分表现优异的大语言模型尚未纳入 OneEval 榜单。随着 OneEval 评测工作的持续推进,未来将逐步覆盖更多主流及前沿的大语言模型,从而实现更全面、系统的性能对比与能力分析。


4.4
评测指标

评测采用多维度指标体系,包括:

  • 各任务评测指标:准确率(Accuracy,用于分类任务)、F1分数(平衡精确率与召回率,用于抽取和生成任务)、ISM@1(Identifier Sequence Match,用于代码生成任务)。具体指标分配详见表2。

  • 综合评分:为了均衡考虑模型在不同任务上的综合表现,我们规定:一个模型的总体评分(Overall Score)为该模型在每个评测数据集得分的平均值












5. 评测结果









5.1
OneEval实验结果

表4 OneEval评测榜单


更新表4.png

在 OneEval 评测中,Grok 3 以 55.82% 的平均得分位列榜首,展现出较强的知识库利用与综合推理能力。值得关注的是,国产模型如 QWQ-32B、Hunyuan Turbo 和 Qwen 2.5-72B 紧随其后,表现稳健,在多类型知识库利用与复杂推理任务中展现出良好的竞争力,凸显了国产大模型在知识增强场景下的持续进步势头。


相比之下,GPT-4o、DeepSeek R1 等主流大模型在该评测中未展现出明显优势,而 Baichuan2-7B、Llama3.1-8B 等中小规模模型得分偏低,进一步说明在复杂知识推理任务中,模型的知识广度与深度仍是影响性能的关键因素。


5.2
OneEval-Hard实验结果

表5 OneEval-Hard评测榜单



在 OneEval-Hard 子集评测中,各大语言模型整体得分相较原始 OneEval 有所下降,体现了该子集在推理难度与区分度上的显著提升。Grok 3 以 26.57% 的成绩位列第一,仍展现出较强的适应能力。OpenAI o1 和 Hunyuan Turbo 紧随其后,保持稳定表现。QWQ-32B、Qwen2.5-72B 等模型虽有一定回落,但在面对更具迷惑性与歧义性的任务中也展现出可提升的潜力。DeepSeek-R1-671B的表现相比在OneEval全集上的表现提升了一位。GPT-4o 下降了两名,反映其在复杂知识整合与深层推理方面仍有优化空间。多数中小规模模型如 Baichuan2-7B、Llama3.1-8B 得分低于 11%,提示其在高难度推理任务中仍面临挑战。总体来看,OneEval-Hard 为评估大模型在复杂、边缘化知识推理场景下的能力提供了更具挑战性的测试环境。


5.3
结各类知识库推理性能对比



图3 文本推理实验结果

在OneEval文本推理任务中,Hunyuan-turbo以78.76%的成绩领先,展现对非结构化文本知识库的理解与运用能力。文本推理的评测数据主要来自于中文医学文献和英文生物文献,这可能是Hunyuan-turbo的优势所在。相比之下,GPT-4o和Claude 3.7 Sonnet在该任务中表现中等,显示出在中文文本或特定领域文本推理上的短板。




图4 知识图谱推理实验结果

在 OneEval 的知识图谱推理任务中,Grok 3 以 42.53% 的成绩领先,展现出较强的多跳推理能力和结构化知识校验能力,在该类任务中表现尤为突出。DeepSeek-R1-671B 和 DeepSeek V3 紧随其后,展现出对三元组结构较强的理解能力。GPT-4o、QWQ-32B 和 Qwen 2.5-72B 在该任务中表现稳健,具备一定的结构化知识处理能力。相比之下,Hunyuan-turbo、GLM4-9B 等在文本类推理中表现出色的模型,在知识图谱推理场景中的得分相对较低,反映出不同模型在结构化与非结构化知识处理能力上的差异与特色。整体来看,知识图谱推理对LLM的逻辑链整合、多跳推理与结构化知识理解能力提出了更高要求。




图5 表格推理实验结果

在OneEval的表格推理任务中,Grok 3以76.50%的表现夺得第一,展现出强大的表格数据处理与逻辑推理能力。DeepSeek-R1-671B(74.30%)和QWQ-32B(70.50%)紧随其后,也具备较强的表格理解与计算能力。GPT-4o和DeepSeek V3表现稳定,准确率接近70%,说明这些模型在数值计算、条件筛选和多步聚合等操作上已有较高水准。相比之下,Claude 3.7 Sonnet(28.30%)和Baichuan系列模型(尤其是7B仅为4.80%)在该任务中表现较弱。整体来看,性能优异的模型往往具备更强的“类程序化”推理能力。




图6 代码推理实验结果

在OneEval的代码推理任务中,GPT-4o以66.50%的准确率位居榜首,展现出其在自然语言到程序语言转换、代码逻辑理解及生成方面的强大能力。DeepSeek-R1-671B(65.60%)与Grok 3(64.00%)紧随其后,也表现出优秀的程序化推理与代码检索结合能力。Doubao-pro和GLM4-9B同样取得不俗成绩,说明一些国产模型在代码理解方面已有显著突破。


5.4
不同领域推理性能对比



图7 通用领域表现排名

在通用领域任务中,Grok 3表现最佳,其次是DeepSeek-R1-671B和DeepSeek V3,表现优于GPT-4o。QWEN 2.5-72B和QWQ-32B虽然参数量相差一倍,但是表现基本持平。Llama3.1-70B、Doubao-pro与Claude 3.7 Sonnet得分在23–25%之间,处于中游水平,具备一定的开放领域能力。其余模型如Hunyuan-turbo、Qwen2.5-7B等得分一般(低于20%)。整体来看,模型规模与表现存在一定相关性,但也有部分轻量级模型展现出较优的性价比特征。



图8 医疗领域表现排名

医学任务中,Hunyuan-turbo以84.50%领先,远高于其他模型,显示出其在医疗知识上的深度训练。QWQ-32B和一系列模型如Qwen 2.5-72B、DeepSeek V3、GPT-4o均处于59%左右的中高水平。Qwen 2.5-72B、DeepSeek V3和GPT-4o得分均为59.50%,构成第二梯队,表现稳定,具备良好的医学推理能力。中游模型如Doubao-pro、Grok 3、DeepSeek-R1-671B和GLM4-9B得分接近,具备一定医学知识处理能力。整体来看,医学任务对模型专业知识储备和推理能力要求较高。



图9 政务领域表现排名

政务类任务上,各模型表现相对接近,Qwen2.5-7B、Grok 3、DeepSeek-R1-671B位列前三,说明即使是较小的模型(如7B)在政策类任务中也可能取得不错的效果,这类任务可能更依赖于语言模式识别和规则理解而非专业背景知识。Claude 3.7 Sonnet在该任务上排名最低,并显著低于其他模型,说明其在中文政务场景上的局限性。



图10 编程领域表现排名

在编程领域中,GPT-4o位居榜首,紧随其后的是DeepSeek-R1-671B和Grok 3,显示出这些模型在程序生成与理解方面的强大能力。尾部模型如Claude 3.7 Sonnet、Qwen2.5-7B、Llama3.1-8B及Baichuan2系列整体得分较低,说明在代码处理任务中存在明显短板。编程任务对模型的逻辑推理、上下文理解及语言精度提出较高要求,只有部分模型能在此类任务中维持高水平表现。



图11 科学领域表现排名

在科学领域中,领先模型为Llama3.1-70B和Grok 3,GPT-4o仅得48.75%,未能进入前五,说明科学推理可能依赖于复杂的知识整合能力,部分模型如Hunyuan、Qwen系列以及GLM4-9B表现优异,显示出较强的科学知识理解能力。整体上看,一些小参数量的LLM(如8B和9B)也在该领域上取得不错的结果。



图12 法律领域表现排名

在法律领域评测中,Hunyuan-turbo 以 83.87% 的准确率取得相对领先成绩,在法律专业知识的理解和应用方面表现稳健。Qwen 2.5-72B和 QWQ-32B的表现亦较为突出,体现了其在该领域任务中的良好适应能力。Grok 3、DeepSeek V3和Baichuan2-7B相对表现不足,说明在法律类任务中存在一定的短板。整体来看,该任务对模型的专业知识覆盖、事实准确性和条理性有较高要求,能够有效区分模型在专业垂直领域的实际应用能力。


5.5
模型多维度能力对比

图13 不同知识库类型下的模型表现

图13展示了多个LLM在文本推理、知识图谱推理、表格推理和代码推理四个维度的性能差异。不同模型在推理任务中各有优势:Hunyuan-turbo适合文本理解类任务,Grok 3知识图谱和表格推理方面表现较好,DeepSeek-R1-671BGPT-4o则在代码推理任务中具有很强的竞争力选择模型应根据具体应用场景和任务类型进行权衡。总体而言,这些LLM在理解和运用知识图谱的能力上还具有局限性。

图14 不同领域下的模型表现

图14展示了多个大型语言模型在六个不同领域任务中的表现差异。可以观察到,不同模型在通用知识与专业领域任务之间的表现存在差异。Hunyuan-turbo在医疗与法律领域取得了较好成绩,显示出其在中文专业任务中的适应能力;Grok 3在多个领域的任务中表现稳定,尤其在开放领域问答与代码相关任务中相对突出。同时,多数模型在中文政务类任务中的推理能力仍面临一定挑战,相关场景下的适配性有待进一步提升。












6. 案例分析









为了更深入地理解LLM在OneEval测试中的局限性,我们对实验结果进行了具体案例层面的分析,比较了不同LLM在推理过程中出现的错误,并尝试推测其可能的成因。由于篇幅限制,详细的案例(包括每个模型的实际输出)可以在OneEval官网中查阅:http://oneeval.openkg.cn/eval-case/


6.1
文本推理案例分析(ChineseLawFact)


测试用例


你是一名中经验丰富的中文法律专家,擅长法律事实核查验证,现在有一个情节和相关的法律声明,请根据专业知识判断其是否存在错误,并在最后输出结果`正确`或`错误`。

 
    1.必要时,可以输出法条进行推理
    2.提供详细的解释
    3.一步步思考后给出结论
    4.输出结果时请使用`结果`:`正确`或`错误`。
    5.输出结果后,立即结束,不需要额外输出解释
 
情节:`村集体雇了专业公司甲公司开飞机洒农药,飞机飞得低,且途经乙养鸡场。后乙养鸡场向丙履约,因为鸡的重量低于合同要求,损失10万元。乙养鸡场就认为是飞机把肉鸡吓得食欲下降饿瘦了,乙养鸡场和甲公司协商无果,将甲公司诉至法院。`
 
法律声明:`甲公司应当对没有因果关系承担责任`


相关知识:民法学\n第七编 侵权责任\n第四十六章 侵权行为与侵权责任\n第四节 侵权责任构成要件\n三、因果关系\n实行因果关系推定,就意味着受害人在因果关系的要件上,就不必举证证明,而是由法官实行推定。  \n因果关系推定适用的范围是:第一,环境污染和生态破坏案件。环境污染、生态破坏致人身伤害案件,即公害案件。对此,《民法典》第1230条已有明确规定。在环境污染和生态破坏责任确定中,只要证明企业已经排放了可能危及人身健康的有害物质,而公众的人身健康在排污后受到或正在受到危害,就可以推定这种危害是由该排污行为所致。第二,其他有必要适用推定因果关系的案件。因果关系推定原则适用于公害案件,在某些特定的场合,也可以有条件地适用。



## 标签 正确
解题思路:环境污染属于典型的适用无过错责任的案件类型,同时属于因果关系倒置的适用情形,因此原告应当就侵权行为和损害结果的事实承担证明责任,被告就无因果关系和存在减免责事由的事实承担证明责任。因果关系的事实因为证明责任倒置,应当由被告甲公司就无因果关系的事实承担证明责任。

模型
结果
说明
结论
Claude-3.7-Sonnet false
忽略了证明责任也是责任,被告需要承担因果关系证明责任
LLM未能识别证明责任在侵权法中的归责含义,导致推理错误
o1 false 推理基本正确,但是忽略了证明责任也是责任,被告需要承担因果关系证明责任 LLM在专业领域知识不全面,影响推理过程
GPT-4o false 忽略了外部知识中提到的环境污染,仅围绕噪声惊吓肉鸡进行推理 由于缺少外部知识,LLM缺乏一些隐式推理的能力,例如完全没有捕捉到洒农药和环境污染之间的关系
Deepseek-R1 false 没有分清被告关系,推理出乙需要承担因果关系证明责任,其中错误的一步是“但本案中的情况是否属于环境污染呢?喷洒农药通常可能涉及污染,但如果是因为飞行噪音或操作导致鸡受惊吓,这可能属于一般侵权行为,而非环境污染。” 推理过程中产生太多无关推理,进行自问自答,同时对小概率事件反复推理验证,导致推理方向走偏
QwQ-32B true 结合知识正确推理出甲是被告需要承担因果关系证明责任,其中关键的正确推理是,“喷洒农药可能是环境污染的一部分,这种情况下,甲公司需要证明与其无关,否则推定有因果关系。” 推理严谨,准确适用因果关系推定原则,识别出甲公司的归责基础
Grok-3 false 没有分清被告关系,推理出乙需要承担因果关系证明责任,甲无需担责 LLM在专业领域的相关概念上存在理解缺陷,有时不能正确分辨法律概念

从上表中我们可以归纳出:

(1)部分LLM在侵权法等专业领域的知识覆盖仍不完善,难以准确识别“证明责任”等术语所蕴含的归责含义,容易混淆相关概念与归责原则,从而导致推理错误。

(2)某些LLM缺乏必要的先验知识,难以进行隐含前提的推理。例如,未能识别“喷洒农药”与“环境污染”之间的因果关系。

(3)在推理过程中,一些LLM生成大量无关内容,表现出自问自答的倾向,频繁验证低概率事件,偏离核心问题,影响推理效率与准确性。


6.2
知识图谱推理案例分析(AffairQA)


测试用例


根据以下三元组列表和您自己的知识背景,回答以下问题。你的答案应该仅包含用逗号分隔的答案。
 
三元组信息:

伊丽莎白·克里斯蒂娜 外甥女 尤莉亚妮·玛丽
卡尔一世 女儿 伊丽莎白·克里斯蒂娜·乌尔丽克
伊丽莎白·克里斯蒂娜 女儿 玛丽亚·特蕾莎
妈妈,不当你的女儿可以吗? 主要角色 早濑浩司
麻烦中的女人 主要演员 伊丽莎白·伯克利
伊丽莎白·克里斯蒂娜 女儿 玛丽亚·安娜
费迪南德·阿尔布雷希特二世 女儿 伊丽莎白·克里斯蒂娜
崩溃边缘的女人 主要演员 伊马诺尔·乌里维
汤姆·斯凯里特 参演 在大案要案的背后:媒体关注与司法审判的对白
妈妈,不当你的女儿可以吗? 主要演员 麻生祐未
伊丽莎白·莫斯 参演 使女的故事第四季
龙纹身的女孩 主要演员 约里克·范·韦杰宁根
龙纹身的女孩 主要演员 克里斯托弗·普卢默
亲爱的女魔 主要演员 帕贡·查博里拉
麻烦中的女人 主要演员 阿德琳妮·帕里奇
妈妈,不当你的女儿可以吗? 主要演员 南波瑠
美少女的谎言 主要配音 特莉安·贝利索里奥
美少女的谎言 主要演员 特莉安·贝利索里奥
伊丽莎白·克里斯蒂娜 父亲 费迪南德·阿尔布雷希特二世
妈妈,不当你的女儿可以吗? 主要演员 柳乐优弥
龙纹身的女孩 主要演员 克里斯汀·亚当斯
使女的故事 主要演员 克里斯蒂安·巴里利亚斯
红十字女人们的入伍通知单 主要演员 高田里穗
妈妈,不当你的女儿可以吗? 主要演员 坛蜜
妈妈,不当你的女儿可以吗? 主要角色 立原真纪
妈妈,不当你的女儿可以吗? 主要角色 后藤礼美
使女的故事 主要演员 伊丽莎白·莫斯
美少女的谎言 主要演员 科迪·克里斯蒂安
使女的故事第三季 主要演员 克里斯托弗·米洛尼
看见缘分的少女 主要演员 潘玥同
妈妈,不当你的女儿可以吗? 主要演员 齐藤由贵
美少女的谎言 主要演员 朱利安·莫里斯
伊莎贝拉·罗西里尼 女儿 艾莱特拉·罗塞里尼·韦德曼
我去世的吃醋女友 主要演员 伊娃·朗格利亚
妈妈,不当你的女儿可以吗? 主要角色 早濑显子
伊丽莎白·阿列克谢耶芙娜 姐姐 弗里德里克·卡罗利妮·威廉明妮
窗里的女人 主要演员 丽莎·科伦-萨亚斯
伊丽莎白·泰勒 女儿 伊丽莎白·弗朗西丝·托德
美少女的谎言 主要演员 贾娜尔·帕里希
红旗渠的儿女们 主要演员 于同云
伊丽莎白·阿列克谢耶芙娜 弟弟 卡尔·路德维希·弗里德里希
继母与女儿的蓝调 主要演员 长野里美
珍妮佛·提莉 参演 美国女孩:勇敢的克里莎
昨夜的咖喱明日的面包 主要演员 仲里依纱
埃米里奥·瑞弗拉 参演 别担心,他不会走远的
帕特里克·J·亚当斯 参演 美少女的谎言第一季
暴风雪中的白鸟 主要演员 克里斯托弗·米洛尼
美少女的谎言 主要演员 瑞恩·莫里曼
罗伯特·罗德里格兹 参演 立体小奇兵:鲨鱼男孩与岩浆女孩
罗伯特·罗德里格兹 执导 立体小奇兵:鲨鱼男孩与岩浆女孩

问题: 伊丽莎白·克里斯蒂娜的女儿的女婿是谁,同时他又是查理十世的哥哥?让我们一步一步思考!
 
## 标签 
路易十六
解题思路:检索回的三元组只包括(伊丽莎白·克里斯蒂娜\t女儿\t玛丽亚·特蕾莎)
与(伊丽莎白·克里斯蒂娜\t女儿\t玛丽亚·安娜)两个信息,
需要结合模型的内部知识,推测玛丽亚·特蕾莎与玛丽亚·安娜谁的丈夫,会是查理十世的哥哥。

模型
结果
说明
结论
o1 true
正确识别出玛丽亚·特蕾莎是伊丽莎白·克里斯蒂娜之女,进一步通过历史知识推理出其外孙女玛丽·安托瓦内特嫁给路易十六,路易十六是查理十世的哥哥
模型具有较强的历史知识和多跳推理能力,能够成功完成复杂谱系推理任务
Deepseek-R1 false 错误认为查理十世的哥哥是路易十八,混淆历史事实,导致推理路径出错 历史背景知识混淆,人物识别和谱系推理能力不足,未能正确匹配王室成员关系
QwQ-32B false 仅表面匹配“卡尔一世→女儿→伊丽莎白·克里斯蒂娜·乌尔丽克”,未进行实际有效的谱系推理 缺乏跨人物与历史背景的深入推理,仅使用浅层三元组链接,推理链条断裂
Claude-3.7-Sonnet false 错误认为“费迪南德·阿尔布雷希特二世”为查理十世之兄,人物关系错乱,逻辑错误 对谱系三元组结构理解错误,人物身份混淆,缺乏准确的谱系关联能力
GPT-4o false 推理路径起步正确,但因不确信信息来源完整性,未能完成最后推理,选择空答案 模型采取保守策略,在缺乏强关联三元组支持时不给出答案,表现出不确定性处理倾向
Grok-3 false 正确识别玛丽亚·特蕾莎为伊丽莎白·克里斯蒂娜之女,推断其丈夫为弗朗茨·斯蒂芬,但未能进一步联想到玛丽·安托瓦内特与路易十六的关系 具有一定历史知识和初步谱系推理能力,但在多跳关系推理中未能完成完整链条

从上表中我们可以归纳出:

(1)大部分LLM在推理过程中主要依赖浅层的三元组链接,难以构建连贯的推理链条,导致推理结果片段化,结论存在断裂或跳跃。

(2)LLM在处理具有复杂历史背景的信息时,容易混淆不同的时间线或朝代背景,对谱系类三元组结构的理解存在偏差,进而引发人物身份混淆和关联错误。


6.3
表格推理案例分析 (WTQ)


测试用例


Date       | Site             | Winning team   | Winning team | Losing team    | Losing team | Series
September 6| 1980 Fort Collins| Colorado State | 21           | Air Force      | 9           | AFA 11–7–1
October 3  | 1981 Colorado Sp.| Air Force      | 28           | Colorado State | 14          | AFA 12–7–1
October 16 | 1982 Colorado Sp.| Colorado State | 21           | Air Force      | 11          | AFA 12–8–1
September 3| 1983 Fort Collins| Air Force      | 34           | Colorado State | 13          | AFA 13–8–1
September 29| 1984 Colorado Sp.| Air Force     | 52           | Colorado State | 10          | AFA 14–8–1
October 19 | 1985 Fort Collins| #10 Air Force  | 35           | Colorado State | 19          | AFA 15–8–1
September 27| 1986 Colorado Sp.| Air Force     | 24           | Colorado State | 7           | AFA 16–8–1
September 26| 1987 Fort Collins| Air Force     | 27           | Colorado State | 19          | AFA 17–8–1
September 3 | 1988 Fort Collins| Air Force     | 29           | Colorado State | 23          | AFA 18–8–1
September 30| 1989 Fort Collins| Air Force     | 46           | Colorado State | 21          | AFA 19–8–1
September 1 | 1990 Colorado Sp.| Colorado State| 35           | Air Force      | 33          | AFA 19–9–1
September 7 | 1991 Fort Collins| Air Force     | 31           | Colorado State | 26          | AFA 20–9–1
October 17  | 1992 Colorado Sp.| Colorado State| 32           | Air Force      | 28          | AFA 20–10–1
September 11| 1993 Fort Collins| Colorado State| 8            | Air Force      | 5           | AFA 20–11–1
September 3 | 1994 Colorado Sp.| Colorado State| 34           | Air Force      | 21          | AFA 20–12–1
September 16| 1995 Colorado Sp.| Colorado State| 27           | Air Force      | 20          | AFA 20–13–1
November 2  | 1996 Colorado Sp.| Colorado State| 42           | Air Force      | 41          | AFA 20–14–1
September 20| 1997 Fort Collins| Air Force     | 24           | Colorado State | 0           | AFA 21–14–1
September 17| 1998 Colorado Sp.| Air Force     | 30           | Colorado State | 27          | AFA 22–14–1
November 18| 1999 Fort Collins| Colorado State| 41           | Air Force      | 21          | AFA 22–15–1
November 11| 2000 Colorado Sp.| Air Force     | 44           | Colorado State | 40          | AFA 23–15–1
November 8  | 2001 Fort Collins| Colorado State| 28           | Air Force      | 21          | AFA 23–16–1
October 31  | 2002 Colorado Sp.| Colorado State| 31           | Air Force      | 12          | AFA 23–17–1
October 16  | 2003 Fort Collins| Colorado State| 30           | Air Force      | 20          | AFA 23–18–1
November 20 | 2004 Colorado Sp.| Air Force     | 47           | Colorado State | 17          | AFA 24–18–1
September 29| 2005 Fort Collins| Colorado State| 41           | Air Force      | 23          | AFA 24–19–1
October 12  | 2006 Colorado Sp.| Air Force     | 24           | Colorado State | 21          | AFA 25–19–1
October 13  | 2007 Fort Collins| Air Force     | 45           | Colorado State | 21          | AFA 26–19–1
November 8  | 2008 Colorado Sp.| Air Force     | 38           | Colorado State | 17          | AFA 27–19–1
October 31  | 2009 Fort Collins| Air Force     | 34           | Colorado State | 16          | AFA 28–19–1
October 9   | 2010 Colorado Sp.| Air Force     | 49           | Colorado State | 27          | AFA 29–19–1
November 26 | 2011 Fort Collins| Air Force     | 45           | Colorado State | 21          | AFA 30–19–1
September 29| 2012 Colorado Sp.| Air Force     | 42           | Colorado State | 21          | AFA 31–19–1
November 30 | 2013 Fort Collins| Colorado State| 58           | Air Force      | 13          | AFA 31–20–1

Please use the context to answer the following question. List all the answers divided with a comma in the last line of your output. Your answer should include only the answers divided by a comma.


Question: what is the most consecutive games won by air force in the trophy era? Let's think step by step!


## 标签 7

解题思路:需要识别出包含Air Force胜利的行有哪些,并统计最大连续的行有几行。

模型
结果
说明
结论
o1 true
准确识别出1983–1989和2006–2012两个七连胜,逻辑清晰、推理完整
推理过程严谨,能够准确统计连续胜场,体现出良好的时间线推理能力
Deepseek-R1 true 逐年判断胜负并正确统计最大连续胜场次数为7,思路清晰,细节处理到位 能够结合数据完成多步统计推理任务,具备较强的事件序列理解与整合能力
QwQ-32B true 正确找到两个七连胜区段,并给出时间范围与场次,表述简洁但信息完整 具备较强的表格数据读取与时序分析能力,能完成逻辑一致的总结
Claude-3.7-Sonnet false 连续胜场统计错误,最多只识别到2连胜,明显遗漏多个连续胜记录 时间线分析能力较弱,对时序性事件缺乏整体性理解
GPT-4o true 正确分析并识别出两个最长七连胜,推理过程清晰、分析全面 表现稳定,能够结合结构化数据进行逻辑归纳,体现了良好的数据理解能力
Grok-3 true 正确识别出1983–1989和2006–2012两个七连胜区段,逐年分析胜负并统计最大连续胜场为7,推理清晰且准确 具备优秀的时间序列分析和数据统计能力,能够从结构化数据中提取关键信息并完成多步推理任务

从上表中我们可以归纳出:

(1)对于较为简单的时间线分析类表格推理任务,大多数大型推理模型展现出可靠且稳定的时间序列分析能力。然而,Claude-3.7在对表格中所展示事件序列的整体理解方面仍存在明显不足。


6.4
代码推理能力分析 (VersiCode)


测试用例


This code generates random data frames, adds rows from a second data frame to the first one,
creates a line chart using the first data frame, adds rows from the second data frame to the line chart,
and finally creates a Vega-Lite line chart using the first data frame and adds rows from the second data frame to it.

##期望答案
#Core-Token: _legacy_add_rows
#潜在逻辑:
#1.生成两个DataFrame,并且将第二个DataFrame的数据添加到第一个中
#2.创建线图和Vega-Lite图表,并且正确添加数据行
#3.正确使用Core-Token
df1 = pd.DataFrame(\n   np.random.randn(50, 20)
columns=('col %d' % i for i in range(20)))
my_table = st._legacy_table(df1)
df2 = pd.DataFrame(
  np.random.randn(50, 20),
     columns=('col %d' % i for i in range(20)))
# Core-Token,即希望模型根据版本信息生成的代码中包含该API
my_table._legacy_add_rows(df2)
my_chart = st._legacy_line_chart(df1)
my_chart._legacy_add_rows(df2)
my_chart = st._legacy_vega_lite_chart({
  'mark': 'line',    
  'encoding': {'x': 'a', 'y': 'b'},
  'datasets': { 'some_fancy_name': df1},
  'data': {'name': 'some_fancy_name'},
}),
my_chart._legacy_add_rows(some_fancy_name=df2)  
# <-- name used as keyword\n
模型
结果
说明
结论
Deepseek-R1 0.5
推理基本正确,模型大致实现了描述的功能,但生成代码中并未包含对应版本的API
大模型本身对API的版本信息不够敏感,代码中没有包含版本限定的API
GPT-4o 0.5

推理基本正确,模型大致实现了描述的功能,但生成代码中并未包含对应版本的API

生成的代码功能逻辑正确,但对于版本等细节信息不够敏感。
o1 0.5 核心功能实现正确,生成代码中并未包含对应版本的API 生成的代码步骤功能正确,但对于版本等细节信息不够敏感。
QWQ-32B 1.0 核心功能实现正确,生成代码中包含对应版本的API,但并未按照指令中的标记分割代码块 在思考过程较长时,模型并不能很好的处理到每一个思考到的内容,例如思考中明确给出输出代码应包含在<start><end>中,但实际输出并未实现。
Grok-3 0.5 推理基本正确,模型大致实现了描述的功能,但生成代码中并未包含对应版本的API 大模型本身对API的版本信息不够敏感,代码中没有包含版本限定的API
Claude-3.7-Sonnet 1.0 思考过程合理,首先分析代码功能,明确实现步骤,给出代码,最后解释代码,但是代码部分不符合格式要求。 输出格式并不符合指令要求

从上表中我们可以归纳出:

(1)模型普遍未能识别或明确指定API的版本依赖,生成的代码中缺乏必要的版本限定,可能导致兼容性问题。

(2)虽然思考过程中能提到特定格式或输出要求(如用 <start><end> 标记代码区域),但实际在较长的推理链时输出未能严格遵循,反映出执行层面对细节关注不足。

(3)在执行明确格式指令时未能完全匹配预期输出格式,表现出对指令理解与执行的一致性不足。












7. 分析与讨论









在对 OneEval 案例的分析基础上,我们尝试归纳出当前大语言模型在知识类推理任务中可能面临的五个关键问题。希望本研究中的一些观察和思考,能够为相关领域的持续研究提供一定参考,并与学界和业界共同探讨更多改进方向。


(1)长推理链导致用户指令遗忘

  • 长推理链在提升逻辑覆盖的同时,也增加了模型遗忘用户指令的风险。

  • 如 QwQ-32B 会在推理过程中自定义规则重构问题空间(如代码推理任务中的指令:“用 <start><end> 标记代码区域”),导致最终结果在格式上与用户初始设定不一致。

(2)过度思考引入边缘假设干扰

  • 一些推理大模型如Deepseek-R1 在某些问题中原本判断合理(如文本推理任务中“产生环境污染导致法律责任”),但在长链推理中引入低概率假设(如“还有可能是飞机噪音惊吓动物”),导致偏离高概率解释路径,最终结论错误。

  • 反映出模型缺乏推理路径选择的概率敏感性,容易被边缘假设干扰。

(3)缺乏对细粒度外部知识的理解能力

  • 多数模型在完成一些细粒度的推理任务时(如版本敏感的代码生成)未能体现对细粒度上下文知识(如API版本限定或特定框架依赖)的把握,说明其对细粒度技术偏好的建模能力有限。

  • 即使使用较长且细致的上下文知识,也未能显著提升模型对版本、框架、设计模式等细粒度偏好信息的遵循性。

(4)难以构建知识图谱中的深层推理链

  • 多数大模型在知识图谱推理过程中主要依赖浅层的三元组链接,难以构建连贯的推理链条。

  • 这导致推理结果往往表现为片段化,缺乏连贯的逻辑结构,结论之间存在跳跃或断裂

(5)常识性因果关系的利用不足

  • 一些模型在特定案例中未能识别问题背景中潜在的因果关系(例如:喷洒农药可能导致环境污染)。这类关系虽然未在上下文中明确出现,但应属于常识性知识。

  • 这一现象反映出模型在常识性的先验知识的掌握上仍显不足,或未能有效调用已有的知识进行推理。












8. 总结与展望









OneEval是一个侧重于“大模型 + 知识库(LLM+KB)” 的融合能力评估的评测体系。第一批发布的V1.0包含十个核心任务数据集,涵盖了文本、表格、知识图谱、代码等四种类型的知识形态,以及通用、医疗、政务、科学、法律与编程等六大领域数据集。基于模型在 OneEval 各项任务中的表现,我们进一步归纳出当前大语言模型在知识推理类任务中可能面临的五个关键问题,为理解其能力边界及未来研究方向提供有益参考依据。


展望未来,OneEval 将持续进行周期性更新,纳入更多由OpenKG自主研发的评测方法与数据集,重点关注大模型在知识增强驱动下的慢思维与神经符号集成的混合推理能力,以期支持大模型向“知识深、思维强”的方向不断演进,并为理解力与思维能力的提升提供有益探索与参考


众所周知,构建一个完全客观、公正、可重复的大模型评测榜单本身就是一项极具挑战的工作。我们也充分意识到当前评测框架仍有很多不足。受限于时间与资源,本次评测可能存在个别结果的偏差、模型覆盖范围有限、知识检索机制相对简单,防作弊策略等方面也有待进一步完善。我们期待未来能与更多研究者携手,共同推进评测体系的持续优化,促进大模型在知识增强与推理能力方面不断进步。












9. 评测组织









OneEval 评测由 OpenKG.SIGEval(官网:http://openkg.cn/sigeval/)组织发起,参与单位包括东南大学认知智能研究所、浙江大学知识引擎实验室、同济大学知识计算实验室以及苏州大学自然语言处理实验室、东南大学未来法治与数智技术创新实验室。详细人员列表如下所示:


>>>>

组织人

漆桂林   教授   东南大学

陈华钧   教授   浙江大学

王昊奋   教授   同济大学

陈文亮   教授   苏州大学


>>>>

主要评测人

陈永锐   博士后   东南大学 邮箱:yongruichen@seu.edu.cn

丁科炎   研究员   浙江大学

王奕淞   硕士   同济大学

张   文   副教授   浙江大学

吴天星   副教授   东南大学

毕   胜   讲师   东南大学


>>>>

技术支持与维护

邓鸿杰   浙江大学


>>>>

数据贡献与实验

刘治强   浙江大学

喻   靖   浙江大学

吴桐桐   Monash University

胡   楠   东南大学

戴鑫邦  东南大学

任   林  东南大学

康家溱  东南大学

刘佳俊  东南大学












参考文献









[1] Hendrycks D, Basart S, MuJavidy M, et al. Measuring Massive Multitask Language Understanding[C]// ICLR. 2021.

[2] Li H, Zhang Z, Zhang B, et al. CMMLU: Measuring massive multitask language understanding in Chinese[C]// ACL. 2023.

[3] Huang Y, Yue Y, Yuan Z, et al. C-eval: A multi-level multi-discipline chinese evaluation suite for foundation models[C]// NeurIPS. 2023.

[4] Zhong W, Zhou S, Yao J, et al. AGIEval: A Human-Centric Benchmark for Evaluating Foundation Models[C]// NAACL. 2024.

[5] Zeng Z, Shen K, Liu Z, et al. Evaluating Large Language Models at Evaluating Instruction Following[C]// ICLR. 2024.

[6] Longpre S, Hou L, Beever A, et al. The flan collection: Designing data and methods for effective instruction tuning[C]// ICML PMLR. 2023.

[7] Mishra S, Khashabi D, Baral C, et al. Cross-Task Generalization via Natural Language Crowdsourcing Instructions[C]// ACL. 2022.

[8] Reddy S, Chen D, Manning C D. Coqa: A conversational question answering challenge[J]. TACL. 2019.

[9] Feng J, Zhang Z, Li X, et al. MMDialog: A Large-scale Multi-turn Dialogue Dataset Towards Multi-modal Open-domain Conversation[C]// ACL. 2023.

[10] Zheng L, Chiang W, Ying H, et al. Judging llm-as-a-judge with mt-bench and chatbot arena[C]// NeurIPS. 2023.

[11] Köpf A, Kilcher Y, von Werra L, et al. Openassistant conversations-democratizing large language model alignment[C]// NeurIPS. 2023.

[12] Wang B, Chen H, Zhang Z, et al. DecodingTrust: A Comprehensive Assessment of Trustworthiness in GPT Models[C]// NeurIPS. 2023.

[13] Wang B, Chen H, Xu C, et al. Adversarial GLUE: A Multi-Task Benchmark for Robustness Evaluation of Language Models[C]// NeurIPS. 2023.

[14] Souly A, Sreedhar K, Das S. A StrongREJECT for Empty Jailbreaks[C]// ICLR Workshop. 2024.

[15] Mazeika M, Phan L, Stoker A, et al. HarmBench: a standardized evaluation framework for automated red teaming and robust refusal[C]// ICML. 2024.

[16] Fourrier, Clémentine, et al. Open LLM Leaderboard v2. 2024, Hugging Face,https://huggingface.co/spaces/open-llm-leaderboa

[17] OpenCompass Contributors. OpenCompass: A Universal Evaluation Platform for Foundation Models. 2023, https://github.com/open-compass/opencompass. 

[18] Chiang, Wei-Lin, et al. "Chatbot arena: An open platform for evaluating llms by human preference." ICML. 2024.

[19] Dubois, Yann, et al. "Length-controlled alpacaeval: A simple way to debias automatic evaluators." arXiv preprint arXiv:2404.04475 (2024).





OpenKG


OpenKG(中文开放知识图谱)旨在推动以中文为核心的知识图谱数据的开放、互联及众包,并促进知识图谱算法、工具及平台的开源开放。

点击阅读原文,进入 OpenKG 网站。


53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询