CrossER

CrossER 是一个用于上下文依赖的跨系统实体解析的基准数据集，其表面特征被故意设计为具有误导性。该数据集包含 688 个实体和 1,800 个实体对，分为匹配、不匹配和模糊三类。数据来源包括五个不同的系统，涵盖四种实体类型和两种语言（英语和德语）。数据集提供了三种评估模式：无上下文、原始上下文（包含 118 个企业文档）和 Oracle 上下文（包含 875 条结构化迁移记录）。此外，数据集还包含多个命名子集（CrossER-Easy、CrossER-Medium、CrossER-Hard 和 CrossER-Full），用于不同难度的评估。数据集结构包括实体文件、配对文件、训练/验证/测试分割、子集和上下文文档。适用于文本分类、实体解析、记录链接等任务，并支持多语言和跨系统匹配。数据集遵循 CC BY 4.0 许可协议。

原始信息汇总

数据集概述：CrossER

CrossER 是一个用于上下文依赖的跨系统实体消歧（Entity Resolution）的基准数据集，其核心特点是实体对的表面特征（如字符串相似度）具有误导性：匹配对的平均字符串相似度仅为 0.29，而非匹配对却高达 0.94。该数据集旨在评估模型在缺乏上下文信息时，依据属性进行判别的能力，以及在提供上下文（包括原始文档和结构化的迁移记录）后性能的提升。

数据集规模与组成

• 总实体数：688
• 总实体对：1,800
• 标签分布：匹配（Match）800 对 / 不匹配（No-Match）800 对 / 模糊（Ambiguous）200 对
• 源系统数量：5
• 实体类型数量：4
• 语言：英语、德语
• 信号文档（Signal Documents）：8 篇
• 噪声文档（Noise Documents）：110 篇
• 结构化上下文记录（Oracle Context Records）：875 条

数据集结构

数据集的目录结构如下：

data/ ├── entities.json # 688个实体（来自5个系统） ├── pairs.json # 1800个实体对（含难度等级标签） ├── splits/ # 训练集（40%）/ 验证集（20%）/ 测试集（40%） ├── subsets/ # CrossER-Easy, -Medium, -Hard, -Full 子集 └── context/ ├── raw/documents/ # 8篇信号文档 ├── raw/noise/ # 110篇噪声文档 └── structured/ # oracle_context.json（875条记录）

评估模式

评估模式	描述
无上下文（No Context）	仅使用实体对属性，评估从属性本身进行匹配的能力
原始上下文（Raw Context）	提供118篇企业文档（8篇信号 + 110篇噪声），模拟真实的RAG（检索增强生成）场景
理想上下文（Oracle Context）	提供875条结构化迁移记录，作为性能上限参考

命名子集

子集	实体对数量	描述
CrossER-Easy	257	简单匹配 + 明显负例；无上下文时的F1上限为1.000
CrossER-Medium	262	中等难度实体对；无上下文时的F1上限为0.776
CrossER-Hard	203	困难匹配 + 对抗性负例 + 模糊对；无上下文时的F1上限为0.000
CrossER-Full	722	所有测试实体对

源系统

系统	角色	命名风格
SAP_TC2	主ERP系统（北美总部）	正式英文名称
SAP_CFIN	财务合并系统	内部代码 / 缩写
SAP_APAC	亚太区域ERP	带区域前缀的缩写
LEGACY_ERP	已废弃的系统（2019年）	神秘的类别代码
SHAREPOINT	税务/合规参考系统	权威长名称

基准实验结果

方法	CrossER-Easy	CrossER-Full	CrossER-Hard
字符串匹配	0.741	0.363	0.000
模糊匹配	0.771	0.455	0.000
嵌入匹配	0.964	0.559	0.000
属性匹配	1.000	0.729	0.000
SBERT（多语言）	0.843	0.604	0.222
LLM零样本	--	0.090	0.000
LLM + RAG（BM25）	0.848	0.632	0.200
LLM + 理想上下文	1.000	1.000	1.000

在无上下文条件下，所有方法在难匹配对上的F1分数均为0.00；提供理想上下文后，性能差距完全消除；RAG机制仅能部分弥补性能差距，检索质量成为瓶颈。

配置与使用

数据集可通过 datasets 库直接加载训练/验证/测试分片： python from datasets import load_dataset ds = load_dataset("smurthy5/CrossER")

也可通过HTTP请求加载命名子集： python import json, requests easy = json.loads(requests.get("https://huggingface.co/datasets/smurthy5/CrossER/resolve/main/data/subsets/crosser_easy.json").text)

预测格式

预测结果应为JSON列表，每个元素包含 pair_id 和 predicted_label： json [ {"pair_id": "pair_0001", "predicted_label": "match"}, {"pair_id": "pair_0002", "predicted_label": "no_match"} ]

有效标签：match, no_match, ambiguous。

许可信息

• 代码：Apache 2.0
• 数据：CC BY 4.0

搜集汇总

数据集介绍

构建方式

CrossER数据集专为跨系统实体解析任务而设计，其构建过程独具匠心。研究团队整合了五个真实企业系统（包括SAP_TC2、SAP_CFIN、SAP_APAC、LEGACY_ERP及SHAREPOINT）中的688个实体，并精心筛选出1,800个实体对。其中，故意设计了800个正匹配对与800个负匹配对，以及200个歧义对。尤为关键的是，正匹配对的平均字符串相似度仅为0.29，而负匹配对却高达0.94，以此模拟现实场景中命名规则的巨大差异性。数据集还配备了八份信号文档与110份噪声文档作为上下文环境，并额外提供875条结构化迁移记录作为线索上限，形成了多层次、高难度的评估体系。

特点

CrossER最显著的特点是其对实体解析中“上下文缺口”的深刻刻画。数据集设计了三种评估模式：无上下文模式仅依赖实体对属性，揭示传统方法的极限；原始上下文模式引入118篇企业文档，模拟检索增强生成（RAG）的真实场景；线索上下文模式则提供了上界参考。实验结果显示，在无上下文条件下，硬配对上的F1得分为0.00，而采用线索上下文后可提升至1.000，这一巨大差异凸显了上下文信息的关键作用。此外，数据集涵盖英文与德文两种语言，以及四种实体类型，具备多语言、多领域的泛化能力。其结果有力证明，仅凭字符串相似度无法解决复杂的企业级实体匹配问题。

使用方法

使用CrossER数据集时，研究者可通过HuggingFace Datasets库直接加载预划分的训练、验证与测试集，代码简洁高效。更灵活的用法是加载命名子集，如CrossER-Easy、CrossER-Medium、CrossER-Hard及CrossER-Full，用以针对性评估在不同难度层级下的模型性能。预测结果需统一以JSON格式提交，每个条目包含pair_id与predicted_label字段，其中标签限定为match、no_match或ambiguous。数据集提供了完整的再现性支持，通过GitHub仓库中的generate模块，可一键复现全部数据，确保实验的公平性与可验证性。这一设计方便研究者在统一的基准上进行公平比较与创新。

背景与挑战

背景概述

在实体解析（Entity Resolution）领域，跨系统实体匹配长期依赖于字符串相似度或属性对齐等表层特征。然而，现实企业环境中，如将SAP系统中的'Product 4418'与LEGACY系统中的'Maltodextrin DE20 Grade A'匹配，往往需要依赖迁移手册、分类指南或企业内部通信记录等上下文信息。由Nihal Gunukula和Sameer Murthy于2026年NeurIPS评估与数据集轨道发布的CrossER基准数据集，正是为攻克这一核心困境而生。该数据集包含来自5个系统的688个实体与1800个配对，涵盖英文与德文，其设计的关键在于匹配对平均字符串相似度仅为0.29，而非匹配对相似度却高达0.94，从而彻底颠覆了传统基于表层特征的匹配假设。CrossER通过三种评测模式（无上下文、原始上下文与神谕上下文）系统性地衡量'上下文鸿沟'，为将大型语言模型与检索增强生成技术引入实体解析提供了标准化测试平台。

当前挑战

CrossER所应对的领域挑战在于，传统实体解析方法在面对伪装匹配（即名称相似但不同实体）和隐秘匹配（即名称相异但同一实体）时性能骤降。实验显示，基于字符串匹配、模糊匹配或嵌入匹配的方法在CrossER-Hard子集上的F1得分均为0.000，即便采用大语言模型零样本推理也无法突破此上限。这表明仅依赖属性或表面语义的范式已遭遇根本性瓶颈。在数据集构建过程中，研究团队面临的挑战在于，如何从真实企业系统（涵盖SAP TC2、CFIN、APAC、LEGACY_ERP与SHAREPOINT）中采集异质性命名风格的数据，并人工标注800个正例、800个负例及200个模糊案例。更为复杂的是，构建包含8个信号文档与110个噪声文档的上下文集合，以及875条结构化神谕记录，以模拟企业实际检索中信号混杂与知识分散的场景。这一过程要求严格区分零噪声的神谕上下文与带噪声的原始上下文，从而精准量化检索质量对实体解析性能的影响，使得CrossER成为评估上下文增强方法不可或缺的基石。

常用场景

经典使用场景

CrossER数据集专为上下文依赖的跨系统实体消歧任务而设计，其核心场景是在企业数据集成中，面对不同遗留系统间实体命名风格迥异的挑战，如将SAP_TC2中的“Product 4418”与LEGACY_ERP中的“Maltodextrin DE20 Grade A”正确匹配。该数据集通过提供易、中、难三级子集，并引入原始上下文文档与Oracle参考记录，系统性地评估模型在仅有表面特征误导时的鲁棒性，是检验实体解析系统能否超越字符串相似度、真正理解业务逻辑的权威标杆。

解决学术问题

CrossER直指传统实体解析方法的根本局限——当匹配对的平均字符串相似度仅0.29而非匹配对高达0.94时，现有基于名称或嵌入的模型在困难子集上的F1分数骤降为0.000。该数据集首次量化了“上下文鸿沟”这一核心学术问题，即模型在缺乏领域知识时无法在信息孤岛间建立正确关联。它推动了实体解析研究从静态属性匹配向动态知识检索的范式转变，凸显了检索增强生成在弥合上下文鸿沟中的关键作用，为端到端上下文感知的实体消歧研究提供了标准化的评估框架。

衍生相关工作

基于CrossER的评估框架，学界已衍生出一系列关键研究，包括面向企业文档的语义检索器优化、上下文窗口裁剪策略对实体消歧的影响分析，以及多语言环境下跨系统实体关联的领域自适应方法。进一步地，该数据集催生了“检索即推理”范式的探索，研究者利用其Oracle上下文提供的上限作为信息天花板，设计出渐进式上下文融合机制，并开发了面向噪声文档的鲁棒性增强算法。这些工作共同推进了将企业级知识图谱嵌入实体解析流水线的技术路线，为构建真正理解业务逻辑的自主数据集成系统奠定了理论基础。