2025全国大数据与计算智能挑战赛_基准参考

比赛网址：https://www.xir.cn/races/BDSSF2025/competition

今年以来大语言模型的相关技术得到了飞速的发展，通过参加比赛进一步整理相关经验，发现不足。这里对本次参赛过程进行小结。

一、赛道选择和初步分析

比赛一共8个赛道，我选择了其中三项（2类），具备各自的特点。

1.1 大模型驱动多粒度知识统一抽取

围绕（1）粒度错配：LLMs 通常按自然语言生成答案，难以直接给出层次化标签，需要通过额外提示与结构化后处理； （2）类型开放：大模型的“世界知识”远超静态标注集，必须动态接纳“从未见过”的实体并即时分层归类； （3）关系开放：实体间的语义连接存在动态组合性，需同时处理预定义关系类型和涌现式关联模式。

因此，本赛题要求参赛者综合利用大模型的语义泛化能力与可控微调/检索技术，在中英双语、跨领域文本中完成多粒度实体关系联合抽取。如图一所示，中间部分经过训练的大模型能够（1）未知类型与关系发现：对未见实体需给出合理细粒度名称并映射到本体，同时识别未见实体间的预定义关系； （2）结构化一致性：JSON 输出必须合法，实体与关系字段之间需一致且符合标签体系； （3）低资源迁移：限定可用标注 ≤ 5 万字；支持 few-shot / in-context 扩展； （4）幻觉抑制：不得输出沙盒外虚构实体与关系。

初步分析

这道题目是一道实体提取题目。目前在大语言背景下，实体提取技术获得了长足的发展。在后面具体的例子中能够看出，实际的效果是相当不错的。目前我提供的解决方案排名是50名（10月26日）

1.2 多类型异构论元事件抽取评测

赛题任务

本赛题的任务为对篇章级的长新闻文本进行多类型异构事件抽取。

具体要求包括：

1.从文本中，根据事件触发词、事件时间等要素实现事件检测与事件类型分类。

2.根据确定的事件类型从上下文中尽可能完整的抽取出定义的该事件类型的事件论元。

输入： 整篇新闻文本。

输出： 结构化的事件类型、事件时间和对应事件类型的论元。

初步分析

这道题目同样是一道实体提取题目，（1）信息冗余与价值稀释：个体Agent在面对海量信息源时，缺乏全局协同，导致信息选择和价值判断片面; （2）协同分工缺失：缺乏多智能体间的角色差异化与任务互补，无法高效整合多维视角与工具链反馈。 （3）知识生成碎片化：单体智能在推理、规划、验证、溯源链路上容易出现断层，难以形成系统化、可解释的“高价值信息”。

为此，本赛题提出“基于多智能体协同的高价值信息生成”挑战：通过• 检索Agent负责从POI数据库、路径规划数据库中抓取交通、酒店、景点等信息； • 规划Agent对约束条件进行建模并生成初步行程方案； • 环境反馈返回价格、时间等实际情况，触发冲突检测； • 验证Agent对不满足条件的方案进行回溯； • 协调Agent整合多方结果，最终生成既满足预算又兼顾体验的“高价值行程信息”。

这一循环“规划-调用-反馈-修正”的过程，正体现了多智能体协同从原始数据中提炼并生成对用户决策最有价值的信息的能力。

赛题任务

参赛队需构建智能体规划系统，在长时程规划+多维约束场景下完成复杂模型建立、规划代码生成与问题求解。系统应在输入用户查询后完成以下：

任务解析：解析问题输入，提取硬性需求，识别用户偏好。 符号化建模：构建多约束规划模型，将任务要素映射为带权重的数学关系式。 规划代码生成：基于LLM生成多约束规划模型的求解器代码，并与Poi数据库、路径规划数据库进行交互，获取酒店、景点、路径规划等数据。 反馈修正：整合环境反馈，≤ 3 轮自我修正并给出可行解。

评测将依据代码可执行性、求解准确率、实体覆盖率等指标综合排名。

初步分析

这道题目是一道代码生成题，其实这里所谓的“多agent"就是提供了多个数据访问接口而已，在官方补充的材料中，我们可以构建本地的mysql服务，才测试这里的接口，但是由于没有实际数据，所以是用不起来的。所以该部分的代码很大程度上都处于“双盲”的测试，前期进行了一些探索，目前提供的代码排名31名（10月26日）

二、初步解法

2.1 大模型驱动多粒度知识统一抽取

首先要搞清楚的是这道题的数据体量和每一个原子数据的情况。同时，由于每一项数据之间没有相互关系，所以天然就可以并行处理，比如我这里将test1划分为10个部分。

def main():
    questoin_path = '/home/jsxyhelu/CODE/初赛/test1.json'
    data = load_json_file(questoin_path)
    file_count = 10
    split_size = 500
    # 分割并保存文件
    for i in range(file_count):
        # 计算当前文件的元素范围
        start = i * split_size
        end = start + split_size
        sub_data = data[start:end]
        # 生成输出文件名
        output_file = os.path.join("/home/jsxyhelu/CODE/spliteData", f"part_{i+1}.json")
        # 保存子文件
        with open(output_file, 'w', encoding='utf-8') as f:
            json.dump(sub_data, f, ensure_ascii=False, indent=2)
        print(f"已保存: {output_file} (包含 {len(sub_data)} 条数据)")

从反馈结果可以看出，test1中需要生成的有4962条

然后对比train1.json和test1.json，看每条数据：

train1.json

 {
    "source": "FabNER",
    "sentence": "Again , that was Matthew Chance reporting from Jerusalem .",
    "coarse_types": [
      "literature",
      "film information",
      "music",
      "person"
    ],
    "entities": [
      {
        "name": "Matthew Chance",
        "coarse_type": "person",
        "fine_type": "journalist"
      }
    ]
  },

test1.json

 {
    "id": "6970518d-dff7-5b9f-8dde-c793348d2624",
    "domain": "politics",
    "sentence": "她在1979年再次参选，并获得提名，但在1979年加拿大联邦选举和1980年加拿大联邦选举中被加拿大进步保守党候选人大卫·克伦比击败。",
    "coarse_types": [
      "事件",
      "组织",
      "政治",
      "人",
      "医学",
      "位置"
    ]
  },

可以看出，主要的数据就是待提取文本(sentence)，初步分类(coarse_type)，待输出的结果是实体(entities)，具体包括实体名称(name)，粗分类(coarse_type)，并生成详细分类(fine_type)，这里的语言是以待提取文本(sentence)为标准的，简单来说就是区分中文英文。所以可以获得提示词如下(这里是豆包优化版本）

SHOT_INSTRUCT = '''
你是一名专业实体提取专家，需严格按照以下流程与规则处理任务：
接收信息：获取待分析的文本文档(Sentence)，以及指定的实体类型列表（coarse_type）。
核心任务：从文本中精准识别出所有属于指定实体类型列表的实体，为每个识别出的实体补充完整信息：
提取实体名称（name）；
标注对应的实体大类（coarse_type，需与给定列表完全匹配）；
推测并标注该实体的细分类型（fine_type，需贴合实体属性与文本语境）。
约束规则：
最终生成的所有结果文本，需与待分析文本文档的语言保持一致（如文档为中文，结果全部用中文；文档为英文，结果全部用英文）。
输出要求：以清晰的结构化形式（如表格、列表）呈现结果，确保 name、coarse_type、fine_type 一一对应，无遗漏、无冗余。
'''

SHOT_SAMPLES = """
输入：
Sentence: SH2D1A protein levels are up - regulated by CD40 cross - linking and down - regulated by B cell receptor ligation 
Coarse_types:['vehicle information','organization','time','biology','person','food','restaurant information','politics']
输出:
```json
{"entities": [
    {
        "name": "SH2D1A protein",
        "coarse_type": "biology",
        "fine_type": "gene"
    },
    {
        "name": "CD40",
        "coarse_type": "biology",
        "fine_type": "gene"
    },
    {
        "name": "B cell receptor",
        "coarse_type": "biology",
        "fine_type": "gene"
    }
]}
```
"""

然后，很重要的就是要让整个抽取框架跑起来。这个时候，我重点是参考“基于多智能体协同的高价值信息生成”，提供的一个基本可用的运行框架。

如果能够多线程运行，还可以提高运行效率，比如下图这样：

后面继续优化的思路，包括提示词的进一步优化，基础模型框架的更换，以及异常情况的处理等。充分利用每天三次的提交机会，然后寻找到一种最优解法。

这道题是一道有指向性的实体提取，不过说到提取，我似乎

这里提供的prompt1-5，分别对应了不同风格的代码，虽然主体是一致的，但是相互之间都略有差距。然后我是选择相对比较短的id_3作为few_shot的提示词来构建提示词和代码：

CODE_INSTRUCT = '''#你是一个精通Pyomo和运筹学的代码生成专家,擅长将旅行规划问题转化为混合整数规划模型。请你理解预定义规则，参考下面的案例将问题转换为python代码进行求解。
#预定义规则
1. 每日应选择一个景点、三个餐饮、一个住宿以及住宿和景点间的交通方式
2. 每天固定两次市内通勤，即住宿和景点的往返
3. 最后一天无住宿，最后一天的交通为前一晚酒店与最后一天景点间的交通
4. 每日活动时间<840分钟
5. 出发/返程火车乘坐时间不计入每日活动时间
6. 火车费用计入对应日期
7. 问题中说明第一天上午出发，最后一天返程，以及目标函数的选择
8. 房间均为双人间、默认合租
9. 打车一次可载4人
10. 忽略出发城市的市内通勤过程
api:
"http://localhost:12457/cross-city-transport/?origin_city={origin_city}&destination_city={destination_city}":获取origin_city通往destination_city的火车车次的乘坐时长、票价
"http://localhost:12457/attractions/{city_name}":获取某个城市内的所有景点的评分、花费、游玩时长
"http://localhost:12457/accommodations/{city_name}":获取某个城市内的所有酒店的评分、花费
"http://localhost:12457/restaurants/{city_name}":获取某个城市内的所有饭店的评分、花费、游玩时长
"http://localhost:12457/intra-city-transport/{city_name}":获取某个城市内的景点和酒店之间的公交和打车的花费和时间
#输出必须遵守以下规则:
1.请你输出求解问题的完整python代码,并保证代码可以执行
2.通过api与POI数据库进行交互,获取必要的数据
3.请你使用pyomo框架进行求解
4.代码运行结束，必须使用print将完整计划输出,输出格式参考样例代码
5.注意优化代码，使其可以处理数据缺失和API不可用等情况，增加异常控制
6.代码必须以```python开始,以```结束
'''

这个地方我有两处修改，一个是特别添加了“注意优化代码，使其可以处理数据缺失和API不可用等情况，增加异常控制”，因为目前是否能够正确运行，是无法通过本地进行验证的，只是给大模型多要求一点；二个是，我把原文的```code_begin ```code_end直接改成了```python，其原因是因为这样更符合通用的惯例。

三、一些经验

3.1 首先要确保所有的test都被跑完

这里的test数据很多，而且最终结果肯定就是来比对test数据的，所以首先要确保所有的test都会被跑完，这点可有通过错误控制等来解决，对于确实不能处理的情况，要把ID打印出来再进一步观察。

比如这里，我将需要放在循环外面的try_catch，放置在了循环内部，这样当有具体问题出错的时候，就会跳过去处理下一个，直到全部处理成功。

3.2 有效进行错误控制

在使用大语言模型进行实体提取的时候，出现了一些意想不到的的界面，这些都是需要换一种方法解决，并且进行相关错误控制，其中的细节还比较多。

把过程的数据统一打出来进行观测。

3.5 稳定的大模型算力也很重要

本次比赛中广泛采用了多线程运算，应该说对算力的消耗是很大的，鉴于免费算力的能力和效率，我还是购置并跑空了3个算力包。

所以这里对于算力的估算、有效的利用调度，以及好用算力平台的选择都是需要的。可能最后还是需要依托开源算力来做很多工作。

四、下步工作

其实需要做的事情有很多，但是区分主次应该包括如下几条：

①找到实体提取和代码生成的测算标准，通过这个标准来验证现有算法和流程。我需要做的是坚定不移地使用开源平台；

②鉴于当前的业务链是完整的，那么验证成功的标准应该能够用于内部实践【这里就存在基础环境对齐问题】；

③对于具体解决问题的工具，比如langchain或langextract，是否存在提高效率的可能？

 

那么就说这么多，这一次应该说我通过比赛对这两类具体的问题有了认知。那么通过内部强化学习，应该能够获得更多的经验知识。