让 LLM「判断」比「生成」更准：一篇论文戳中了很多团队还在犯的错

前天刷 arXiv 看到一篇国内学者发的论文，题目很长，核心问题很直白：让 LLM 做对话中的情绪-原因配对提取，到底是让它「生成」完整结果，还是让它「判断」单个候选？

直觉上两者差不多，毕竟大模型都能干。但论文结论很干脆：18 组对照实验里，pair-level judgement（逐对判断）全面碾压 dialogue-level generation（整段生成），没有例外。

先说一下这个任务。ECPEC（Emotion-Cause Pair Extraction in Conversation）的目标是，给你一段对话，找出「哪句话导致了哪句话的情绪」。A 说了一句伤人的话，B 随后表现出难过，模型要识别出这个因果关系。情感计算、对话分析、客服质检里都有用到。

以前的做法是让 LLM 一次性读完整个对话，然后输出所有情绪-原因配对。听起来合理—模型能看全上下文，一锅端出来。

论文认为这条路走不通。不是模型能力不够，是任务形式本身就有问题。用显式的逐对查询去问模型时，模型能识别出 92.7% 到 98.1% 的情绪-原因关系。LLM 其实看得懂、认得出来。问题出在「发现并返回完整集合」这一步—让它自己从对话里把所有配对捞出来，它就丢三落四。

这和很多开发者的实际体感吻合。让模型写一份完整报告，它经常漏东西；一个个问「这个对不对」，它判断得挺准。LLM 的召回能力远远落后于它的判别能力。 这篇论文等于把这个经验差异量化了，在具体任务上锁死变量做了严格对比。

基于这个诊断，作者加了一个轻量的辅助检索器，专门排查边界模糊的候选对。结果是在三个数据集上 F1 提升了 0.50 到 1.46 个点，推理时间涨到基线方案的 1.49 倍。不算惊艳，但务实——没有上更大模型或更复杂的 pipeline，找准了瓶颈打补丁。

触动我的是论文的视角。没有去卷新的 SOTA 架构，也没有堆 prompt 技巧，而是停下来问了一个基本问题：你用 LLM 做事的方式本身，是不是就已经决定了天花板？ 生成范式把「识别」和「检索」绑在一起，模型背了不该背的包袱；判断范式把包袱卸掉，模型的能力就释放出来了。

这个结论不止于 ECPEC。凡是需要 LLM 从一段上下文里提取结构化集合的任务，都值得重新审视一次：你是让它一次性生成，还是拆成判断单元一个个过？后者可能更慢，但准确率的收益能不能覆盖成本，需要具体算。论文给了 1.49x 这个参考值，算是一个有用的锚点。

当然也有边界没说清楚。辅助检索器的设计细节、对不同 LLM 基座的泛化能力、阈值的敏感性——论文里只是初步讨论，算不上成熟方案。但问题本身提得好，诊断比疗法更扎实。

如果你是做 Agent 工程或者信息抽取的，建议翻一下原文。不一定能直接抄进你的 pipeline，但会让你重新想一件事：你现在交给 LLM 的那个 prompt，到底是在让它发挥能力，还是在给它挖坑。