本想比较Claude与GPT高下，却意外试出了LLM裁判的信任边界

让一个大模型去评判另两个大模型的工作，这听起来像一场AI圈的内部考试。可当这份“裁判”打分表摆到手边时，真正让人意外的不是谁赢了，而是裁判自己的可信度突然成了比考试结果更值得追问的东西。

这件事的起点，要回到我上一篇文章里留下的那个开口问题。当时我拿Apache ZooKeeper项目里抽出来的500张Jira工单，跑了一整套预处理、TF-IDF向量化、K-Means聚类，再用余弦相似度揪出可能重复的单子。真正出彩的是第二步——把这些干巴巴的聚类结果和重复对，丢给Gemini 2.5 Flash，同时用三份经过选择性加权的RAG文件作地基：项目背景文档、发布说明，还有一份2026年的路线图主题。返回来的不再是关键词表格，而是带着清晰名称的聚类、带有产品经理视角的建议、结合工单年龄的重复判定，以及一份高管能直接读的摘要。整套流程跑下来很顺，顺到让人觉得“这大概就是正确答案”。

但冷静下来一想，就会踩到一个不舒服的点：从头到尾只有一个聚类方法、一个模型，没有任何对照。Gemini给出的簇名听上去很对路，究竟是因为它真的抓住了本质，还是因为房间里只有它一个声音，没有对手来叫板？这个问题不拆开，整套管道的说服力就只能停在“看着还行”的层面，经不起追问。

于是就有了这一轮的实验设计。核心思路很简单：把两个东西独立出来，让它们自由变动，看最终结果会往哪里跑。第一个独立变动的要素是聚类方式——一边走句子嵌入路线，另一边继续沿用TF-IDF，同一个文本集、不同的向量表达，等于是从地基就开始分岔。第二个独立变动的是大模型本身——Claude Sonnet 4.5和GPT-5.5，在完全相同的输入端和完全相同的RAG上下文中各自工作，谁也不比谁多看一行字。

这种双管道、双模型的结构，看似只是比上一轮多了几个组合，但它的意义在于，你可以开始说“管道A的聚类质量更高”或者“Claude在处理过期工单时推理更周延”这样的话，而不再是孤例撑起的猜测。只有把聚类方法和模型拆开，才能判断一个优势究竟来自文本表示，还是来自语言模型自身的理解能力。

具体怎么搭起来的，需要画一张简图才能看清楚，不过用文字也能把五阶段流水线讲明白。第一阶段，两份一模一样的500张工单数据，分别灌进管道A和管道B。管道A走句子嵌入，把每张工单的语义压缩成高维向量，管道B走TF-IDF，靠词频和逆文档频率把文字转成稀疏向量。两种方式对“什么是重要的词”的假设完全不同，后面的聚类行为自然也会跟着分叉。第二阶段，两个管道各自用K-Means对向量做聚类，但这次没有固定分几簇，而是让每个管道自己用肘部法则加轮廓系数来决定最终的K值。这一步很关键，等于拔掉了一个隐性的偏好按钮——如果硬性规定K=5，那其实是提前替某种聚类方法做了一个它未必认可的决定，现在交给数据自己说话，管道A和管道B各有多少簇，完全是各自向量空间里的合理结果。第三阶段，两个管道内部各自计算余弦相似度，从自己那批工单里拉出一份疑似重复的列表。第四阶段，两份聚类结果、两份重复列表，全部交给两个大模型去“增强”。Claude Sonnet 4.5先处理管道A的输出，接着处理管道B的；GPT-5.5也同样走一遍这两个管道的产出。第五阶段，每个模型在增强的时候，都要同时啃三份RAG上下文文件：项目背景文档把ZooKeeper的模块结构和功能边界交代清楚，发布说明提供历史变更的时间线索，2026年的路线图主题则给了一个远期演进的方向感。这些文件不是平均摊开的，而是根据每份参考资料与当前任务的相关度做选择性加权，确保模型在给簇命名、判断哪些工单该合并时，不是凭空编故事，而是踩在真实项目肌理上。

跑完一轮，出来的不是四个输出，而是十二个。这里容易让人犯晕，但数一下就会清楚：两个管道各自产生一套原始聚类结果和一套重复判定，这已经是四个独立产出；接着Claude分别对管道A和管道B的这两套产出做增强，同样GPT-5.5也做两遍，每轮增强都会给出带着簇名、推荐动作和重合度判断的完整报告。把所有这些摊在桌上，就是十二份可以直接互相比较的输出。

到这一步，真正棘手的问题才刚刚浮出来：谁来评判这十二份输出的质量？如果只是盯着哪个簇名更像人写的，哪个重复判定更符合直觉，那就绕回到老路上——评估者本身的偏好会成为新的隐藏变量。于是这一轮引入了一个第三方的LLM裁判，让它拿着一把打分标尺，对所有十二份输出逐项评分。裁判角色不参与前面的任何聚类或增强过程，它只负责读结果、对照评分维度、给出分数。与此同时，我自己也坐下来，手工把同样的十二份输出评了一遍，用的准则和维度尽量与LLM裁判保持一致。

老实说，在设计这个环节的时候，我内心的预期是：通过这种“让另一个模型当裁判”的方式，能够拿到一个相对客观的比较结论，至少可以笃定地说出Claude和GPT-5.5在这个任务上谁更强、哪种聚类方式更扛得住实际工单的复杂度。但真正把两套评分——LLM裁判的打分和我自己手工的打分——放在一起对照时，最刺眼的东西并不是模型之间的差距，而是裁判本身在哪些环节给出的判断靠得住，在哪些环节会悄悄偏航。

这个发现比比较两个模型本身更有价值。因为一旦我们开始把LLM当作自动评估工具来用——给生成质量打分、给摘要排名、给分类结果标好坏——那最关键的问题就不再是“被测模型好不好”，而是“裁判的判断能不能当作依据”。如果裁判在某个维度上给出的分数和人判断高度一致，那这个维度就适合自动化；如果裁判在另一个维度上给出的分数一会儿飘高一会儿飘低，甚至出现明显的系统性偏好，那这个维度就必须有人盯着，或者干脆不能用LLM去打分。换句话说，这次实验真正产出的不是一份“谁赢了”的排名，而是一张信任地图，上面标着哪些区域可以放手让LLM裁判说了算，哪些区域必须保留人工复核。

这也回答了上一轮留下的那个开口。单管道、单模型的弊端，不在于技术本身不漂亮，而在于它让所有判断都缺少对照，甚至连那个最终给出评价的裁判是否可靠都无从检验。双管道、双模型加上独立的LLM评分与人工评分的对撞，才能让人看清楚整条评估链里最脆弱的那一环到底藏在哪里。