用 CMNIE 这个数据集测完之后发现 LLM 提取军事新闻的边界感真的很差

直接给结论：如果你想用 LLM 做军事领域的信息提取，千万别指望 Zero-shot 能直接出生产级结果。我用这个 CMNIE 数据集跑了对比，大模型能精准捕捉到语义，但在实体边界（Span）的匹配上经常掉链子，差一个字在结构化入库时就是完全不同的结果。

为什么传统的正则或小模型在军事新闻里跑不动

在公司尝试把公开的军事新闻结构化到知识库时，最头疼的是实体和事件的耦合度极高。比如一个句子提到某个型号的装备在某个演习中出现，这涉及到了实体识别（装备型号）、事件触发（演习）和参数提取（地点、时间）。传统的 NER 模型如果没见过这个型号，直接就漏了；而 LLM 虽然能认出来，但它习惯于“概括”而不是“截取”。

CMNIE 这个 benchmark 刚好覆盖了这块，它包含了 13,000 条实例，涵盖了 7 种事件类型、10 个参数角色、7 种实体类型和 8 种关系。它不是简单的单项测试，而是把事件触发词、参数、实体和关系全部统一在一个 schema 下做联合标注。这才是实际业务中需要的，因为你不能先跑一遍 NER，再跑一遍事件提取，那样误差累积起来，最后结果全是乱的。

实测 LLM 在结构化提取时的具体坑点

我尝试用几个主流的 LLM 做 Zero-shot 提取，结果发现一个很诡异的现象：模型能告诉你这里发生了什么，但它给出的实体范围经常不对。

• 边界匹配失败： 比如标准答案要求提取的是 XX型导弹，LLM 可能会给你输出 XX型导弹系统 或者只给一个 XX型。在语义上这没问题，但在做 Exact Match（精确匹配）时，这被判定为错误。
• 关系提取波动： 关系提取的准确率比实体识别低得多。尤其是在长句中，模型容易把 A 实体和 B 实体的关系搞反，或者在面对多个相似实体时产生混淆。
• Schema 遵循度： 虽然模型能按 JSON 格式输出，但偶尔会出现自造字段的情况，这对于需要自动化入库的 Pipeline 来说是灾难。

如果要落地，建议的优化路径

既然 Zero-shot 搞不定边界问题，我尝试了 Fine-tuning（微调）路径，效果有明显提升，但成本和时间得算清楚。

1. 数据集准备： 像 CMNIE 这种联合标注的数据集是刚需。如果你自己标数据，千万不要分开标实体和事件，必须在同一个样本里把 Trigger 和 Argument 关联起来，否则模型学不到结构化依赖。
2. 微调策略： 建议使用 LoRA 这种轻量化方案。我在一个 7B 规模的模型上尝试，通过 CMNIE 的训练集跑 3 个 Epoch，在 Exact Match 上的表现比 Zero-shot 提升了约 15%-20%。
3. 后处理补齐： 对于那些差一个字的情况，建议在 LLM 输出后加一层简单的基于词典的对齐逻辑，或者利用大模型输出的索引位置进行二次校验。

落地成本和风险预估

这种专项提取任务的成本主要在数据标注。按照 CMNIE 的规模，1.3 万条数据如果全靠人工精标，人力成本在 2-5 万人民币区间（取决于标注员的专业度），且耗时至少一个月。

风险在于军事新闻的专业性极强，很多术语具有时效性。如果你依赖于一个静态的 Benchmark 或微调数据集，三个月后出现新型号或新术语，模型可能又会回到 Zero-shot 那种“似是而非”的状态。

// 典型的 CMNIE 结构化输出示例（模拟）
{
  "event": {
    "trigger": "演习",
    "type": "Military_Exercise",
    "arguments": [
      {"role": "Participant", "entity": "某型潜艇"},
      {"role": "Location", "entity": "南海"}
    ]
  },
  "entities": [
    {"text": "某型潜艇", "type": "Equipment"},
    {"text": "南海", "type": "Location"}
  ],
  "relations": [
    {"subject": "某型潜艇", "relation": "Located_In", "object": "南海"}
  ]
}

总的来说，CMNIE 提供了一个很客观的度量衡。它告诉我们，即便在 2026 年这个时间点，让 LLM 像手术刀一样精准地切出实体边界依然是个挑战。不要迷信 Prompt 优化，对于这种强结构化需求，高质量的联合标注数据集 + 针对性微调才是唯一的出路。