返回实践

cat 03-bid-evaluation.md

智能评标:先认清对象,再谈评分

以业务本体为核心,贯通评审推理与溯源审计

海量材料只是表象,更深层的挑战来自语义、业务关系、条件逻辑和评价标准

场景 03建模深度 [###-]业务本体

ontoctl describe bid-evaluation

涉及哪些对象
招标要求、评审点、供应商、投标材料、设备与工况
依据在哪里
招标文件与投标文件中的具体页码、参数表和证明材料
规则如何适用
评分规则先治理,有歧义时由有权的人确认,再版本化执行
最终由谁确认
系统给出初评,专家复核定案,委员会形成最终结论

评标难在哪里

一个项目 24 家供应商、48 份投标文件、28,856 页,可提取文本约 489 万字符、430 万 token

  1. [1]材料多、类型杂技术、商务、资质、业绩、图纸混杂,PDF、扫描件、图片、表格并存
  2. [2]规则边界模糊“技术能力强得 2–4 分”,什么叫“强”?“先进”“合理”“较强”缺乏精确定义,还有大量隐含条件和业务常识
  3. [3]证据分散一个评审点的证据可能分布在合同、设备清单、发票、验收报告中,同一设备有不同名称、型号或简称,同一合同里出现“1 套”“3 台”“1 套”,不能直接相加
  4. [4]难以追溯高度依赖专家逐项阅读比对,不同专家理解可能不一致,结论依据分散,复核成本高,一旦遗漏或误判,就可能影响中标结果

用三层本体组织评标

评什么、凭什么、怎么评,分开建模,再由评审任务串起来

  • 招标本体定义评什么、按什么规则评
  • 投标本体把散落的材料组织成可核验的业务事实,已确认的关系与待核的候选关系分开标记
  • 评审任务逐家、逐评审点独立推理,共享同一套已核实的事实,但不直接复用其他评审点的结论和分数

评分规则本身也需要治理

  1. 招标原文
  2. 识别歧义
  3. 有权确认
  4. 版本化执行

[WARN]规则有歧义时,不由模型自行发明评分口径

tree bid-ontology

细看一个评审点:技术性能

同样写着“150% 额定负荷”,设备型号、冷却方式、环境温度和持续时间必须一一对应

技术评审不是比较孤立的数字,而是核验“本次设备在特定条件下具有什么能力”

招标文件第 132–133 页对一台变压器提出了两组工况要求:工况 A 为自然风冷(AN),工况 B 为风机辅助冷却(AF)

供应商 A 在技术卷第 50 页作出应答,第 51 页参数表给出型号 SCB13-2500/6、额定容量 2500kVA、冷却方式 AN/AF,系统逐项对照

系统输出:技术应答条件匹配 2/2 组,依据为招标要求第 132–133 页、投标技术应答第 50 页、投标参数表第 51 页

./compare.py --req p132-133 --resp p50-51

每格左侧为招标要求,右侧为投标应答

本体守住的四条边界

不矛盾
100% 和 150% 不是矛盾,而是分别适用于不同的冷却条件
不拆拼
两组性能声明必须分别保存,不能拆散后重新拼接
不借用
其他型号的性能不能借给本次设备,20℃ 下的能力不能证明 40℃,短时运行不能证明长期运行
不混淆
招标方的要求值和投标方的保证值必须区分,不能把要求误当成承诺

[NOTE]此处判断的是“技术应答条件是否匹配”,不等于已经完成设备实测性能鉴定,也不代表该项技术评分应得满分

谁负责什么

RAG 与解析
定位证据
大模型
复杂理解与综合评价
本体
把对象与条件关联起来
代码
逐组精确核验
专家
复核与裁定

系统先给出初评,专家复核定案,委员会形成最终结论;每一步采用的规则、引用的证据、模型与计算过程、人工决定都留有记录