19岁，大二，计算机专业。过去三个月做了一个招投标文档智能评估系统「标小智」，本文复盘其中最核心的一战：怎么让大模型打分这件事变得可信。> 项目地址：https://github.com/tlyyxjz## 一、先说一个所有用过LLM打分的人都遇到过的坑让大模型当评委，是很多人做AI应用的第一反应：把标书丢给它，prompt里写"请从100个维度给这份投标文件打分"，完事。我们最初也是这么干的。结果很稳定地离谱：同一份文件评三次能出三个分；换个措辞重述评分标准，分数又变了；最气的是，它会给一份明显漏了关键资质的标书打出90分，理由是"整体结构清晰"。最典型的一次：一份市政工程标书，项目经理的建造师证书在附件扫描件里，正文压根没提。模型直接判"未提供资质证明"扣了满分，但实际上证书就躺在第47页的附件里。更离谱的是同一份文件换个上传顺序再评一遍，分数差了8分——因为它每次"看"到的重点不一样。这就是所谓的 LLM评估幻觉：模型不是不会打分，而是它的打分没有可复现的标准。你要它"专业地评"，它就真给你表演一个"看起来专业"。## 二、v1：直接问模型，准确率88%第一版方案很朴素：我们把人工评审的评分表喂给模型做few-shot，让它模仿人类专家的评分习惯。在一批有专家标注结果的样本上测了一下：具体做法：用DeepSeek-V3做主模型，把评分标准整理成一份结构化prompt，给了3个人工标注的few-shot样例（分别对应高质量、中等、较差标书）。在120份有专家评分结果的标书上测试，以专家分差±5分以内为"对齐"标准，对齐率88.04%。88%，听起来还行？但做评估系统的人知道，这个数字意味着每10份文件就有1份被错误评价。在招投标这种真金白银的场景，1%的错误率都可能引发争议，10%根本不能用。更要命的是我们无法解释：为什么这份文件被扣分？模型的回答永远是车轱辘话。## 三、转折点：别让模型"自由发挥"，给它出选择题真正的转机来自一个很朴素的观察：**人类专家评审时，脑子里其实是一张检查清单，而不是一个"综合感觉"。**资深评标专家看到一份技术标，心里跑的是：项目经理资质有没有？类似项目业绩几份？工期承诺是否响应招标要求？——每一条都是可以客观验证的是非题。那为什么不让AI也这么干？于是架构彻底反转：不再让模型"给整份文件打分"，而是把评分拆成34条具体规则，每条规则就是一个可以用证据回答的问题，模型的任务从"评委"降级成"查证员"。v1：文档 → [LLM综合评估] → 分数（黑盒）v2：文档 → [34条规则逐条查证] → 每条规则的判定+证据 → 规则引擎汇总 → 分数（白盒）每一条规则长这样：json{ "rule_id": "R-Tech-017", "category": "技术资质", "question": "拟投入的项目经理是否具备一级建造师证书？", "evidence_required": true, "weight": 5, "scoring": "命中=满分 / 部分命中=半分 / 未命中=0分"}关键设计有三个：1. 强制引用原文：模型判定任何一条规则，必须给出标书中的原文出处。给不出出处的判定直接作废——这一招杀掉了大部分幻觉。2. 是非题代替开放题：模型不再输出"该文件技术方案较好"这种废话，只回答"第38页提到了项目经理证书，判定：命中"。3. 权重在代码里不在提示词里：34条规则的权重由规则引擎计算汇总，模型碰不到打分逻辑——它只负责找事实，算分是我们的事。## 四、88% → 93%：规则细化吃掉的第一波红利第一版34条规则上线后，准确率从88%升到了93%。提升主要来自两类规则的打磨：误判率最高的两条规则都是"模糊表述型"：案例1：“是否具备相关项目经验”——这条规则误判率高达23%。模型经常把标书里提到的任何工程项目都算作"相关经验"，不管是不是同类项目。后来改写成"是否列出≥2个2019年后完成的同类合同（合同金额≥500万）并附验收证明"，误判率直接降到4%。案例2：“工期承诺是否合理”——模型对"合理"的理解完全看心情。一份标书承诺工期180天，模型有时说"合理"有时说"偏紧"。改写成"工期承诺是否≤招标文件要求的上限天数"后，变成纯数值比较，误判率从18%降到2%。我们的经验是：规则写得越像"人话"，模型查证越不准；规则写得越像"检索指令"，准确率越高。比如"是否具备相关项目经验"这种模糊表述要改写成"是否列出≥2个2019年后完成的同类合同并附验收证明"。## 五、93% → 97.6%：剩下的4.6%全靠"边界case"前88到93是爽文节奏，93之后就是硬仗了。剩下的错误全部集中在边界情况：三个最棘手的：边界case 1：附件扫描件OCR错位。标书正文的页码和附件页码不连续，模型引用"第38页"时经常跳到附件区域找不到内容。解法：给每页打上全局递增页码标签，规则里增加"引用页码必须为全局页码"的约束。边界case 2：响应式写法绕关键词。有份标书写"本项目拟派负责人的执业资格证书详见后附材料"，故意不写"建造师"三个字。模型查"是否具备一级建造师证书"时判未命中，但实际证书在附件里。解法：新增一条补充规则"若正文提及’执业资格’但未写明具体类型，需检查附件中是否包含对应证书"。边界case 3：多方案并列冲突。一份标书同时报了两个方案（A方案和B方案），项目经理信息写在A方案章节里，B方案章节没写。模型评B方案时判"未提供项目经理信息"。解法：规则里增加"公共信息章节优先，各方案章节独立判断时需回溯公共信息"。这个阶段我们建立了一个笨但有效的机制：每一个误判案例都不放过，分析根因后要么新增一条规则、要么修订一条旧规则，然后跑全量回归确认没有引入新错误。34条规则就是这么一轮一轮被真实错误"喂"出来的——不是坐在那里凭空设计的。## 六、怎么证明97.6%不是自己骗自己评估系统最容易自欺欺人的地方：拿训练时见过的案例去报成绩。所以我们做了两件事：1. 建立了2435条测试基线构成：180份真实标书（涵盖市政、房建、信息化三类）× 平均每份13.5条规则 = 2435条判定记录。专家标注由3位评标专家独立打分，分歧项取多数。开发集（用于调规则表述）和测试集（只看最终成绩）完全隔离，开发集碰过的标书不计入最终97.6%的统计。2. 回归测试进CI每次改动规则或prompt，自动跑全量基线。任何一个case的判定结果翻转，都会在合并代码前被抓出来。这套机制后来救了我们无数次——很多"优化"在单点上变好，在全量上一片红。举一个真实被拦截的例子：有一次我把"同类项目经验"的判定阈值从"2个合同"改成"1个合同"，本以为更宽松会更准确，结果回归测试直接爆了7个case翻转——原来降低阈值后，一些本来不该得分的标书反而命中了。如果没有CI拦截，这个改动就会偷偷上线，准确率可能悄悄掉回94%。另外提一句工程侧的配套：为了排查"同一个文件两次评估结果不一致"的问题，我们给每次解析结果做了SimHash指纹+SHA-256存证，任何判定都能回溯到当时的输入快照——评估系统的可信度，一半来自算法，另一半来自这种可审计性。## 七、写在最后回头看这三个月，最大的认知升级其实是这句话：> LLM应用的核心竞争力，往往不在模型能力里，而在你怎么把一个模糊的业务问题翻译成模型可执行的确定性任务。"给标书打分"是个模糊问题，谁做都翻车；"按这34条规则逐条查证并引用原文"是个确定性问题，模型做得比人还稳。项目地址：https://github.com/tlyyxjz ，包含完整的规则引擎实现和HiveSwarm动态技能装配框架。欢迎交流，评论区必回。—作者：徐浚钊，上海建桥学院计算机科学与技术专业2025级。正在寻找AI产品/AI应用方向实习，可远程，每周3天以上。