AI生成投标文件场景中的 Determinism 与 Probabilistic
“确定性”一词，随场而变。心之所向为信，事之所向为预，理之所向为定。
引子：技术方案里的“确定性”，从来不是词义问题，而是一条生死线
在 AI 生成技术标技术方案的语境里，“确定性”不是文学修辞，而是交付制度： 同样一句 “I’m sure”，在低容错的承诺文本与概率生成之间，可能意味着可靠交付，也可能意味着高置信幻觉。
技术方案往往被误解为“写得像就行”。但现实是：
- 评委看技术方案，本质上在看你是否理解需求、是否能组织资源兑现承诺、是否覆盖评分点且可核验。
- 技术方案里的“漂亮话”如果覆盖了关键字段（响应时间、人员配置、工期节点、验收指标、应急处置、合规标准等），一旦漂移或失真，就不再是文风问题，而是承诺风险与失分风险。
一、同一“确定”，三种世界
1) Certainty：模型的“确信”，不等于事实的“成立”
这里的 certainty 不是“语气坚定”，而是“看起来很确定”。LLM 最危险的能力之一，是能把不确定写得极其确定——用流畅、完整、无犹豫的措辞，制造一种“已经核实过”的错觉。
The model expresses certainty even when the evidence is missing. 模型在缺乏证据时也能表现得非常确定。
在技术方案场景，这种 certainty 往往直接变成风险源。典型例子：
- 响应承诺被“写出来”： “7×24 值守，5分钟到场，10分钟恢复。” 但招标文件写的是“到场”定义为“电话响应/远程响应/现场响应”？你到底是哪一种？现场 5 分钟是否受场地、门禁、驻场人数约束？
- 合规标准被“顺手引用”： “完全符合 GB/T ××××—××× 标准。” 你确定这个标准在该行业、该采购范围下适用？是强制性条款还是推荐性条款？是否已废止/被替代？
投标（尤其技术方案）的底线是：任何“确信”都必须被证据与机制接管。否则它就会变成“高置信幻觉”（high-confidence hallucination）。
在技术方案里，Certainty 必须被降权：写得越确定、越像真的，如果没有证据锚定，风险越大。
2) Predictability：流程可预期，不代表方案可交付
Predictability 指的是过程层面的稳定：模板稳定、风格稳定、产出节奏稳定。很多 AI 产品会把它当成“确定性”卖点：生成快、看起来统一、交付可预测。
A predictable pipeline can output the same “standard SLA clause” every time. 一个可预期的流水线可以每次都输出同一段“标准 SLA”，也可以每次都稳定地错。
流程稳，只能说明“生产线顺”，不能说明“内容真”。 技术方案的确定性不是“能预测会产出”，而是“能保证产出可审计、可兑现”。
3) Determinism：同一输入，同一关键结论——否则就是承诺漂移
Determinism 才进入机制层：相同输入必须推导出相同的关键输出。技术方案不要求全文逐字一致，但要求“硬承诺”不可漂移：
- 人员与班次不漂移（驻场人数、岗位、排班口径一致）
- SLA 指标不漂移（响应/到场/恢复/可用性/MTTR/升级路径一致）
- 工期与关键节点不漂移（里程碑、验收节点、交付物清单一致）
- 范围与边界不漂移（哪些做、哪些不做、接口责任不变）
- 合规引用与证据链不漂移（标准条款、制度依据、证明材料指向稳定）
We need deterministic outputs for the SLA and staffing sections. SLA 与人员配置章节必须确定，否则不是“写作波动”，而是“承诺漂移”。
但要注意：可复现（deterministic）≠ 可成立（correct/valid）。 系统完全可能稳定地产生一个稳定的误读、稳定的漏项、稳定的不合规。
所以，“确定性”必须继续深化：从词义辨析走向第一性原理—— 概率预测机怎样才能交付一份容错极低的技术方案？
二、第一性原理的碰撞：概率预测机遇上低容错的技术方案
两条基础事实，决定了这个命题的硬度：
- LLM 的本质：统计意义上的概率预测机（next-token prediction）。它擅长“合理的序列”，不天然擅长“可追溯的真相”。
- 技术方案的本质：不是抒情文本，而是“交付设计书”。它需要事实锚定、逻辑闭环、范围边界、指标可核验、并能与附件材料形成证据链。
冲突点在于：我们试图用一个天生带概率性的生成器，去完成一份容错极低的交付承诺文本。
解决方式不是“把诗人训练成工程总监”，而是建立制度： 让工程系统掌握事实与裁决权，让模型只负责措辞与表达。 这就是“确定性内核”（Firm Core）的来源。
三、从“可复现”走到“可交付”：技术方案的确定性内核
1) 投标的确定性首先不是文风，而是“事实主权”
用一个更可执行的三段论来落地：
- 大前提（Major）：凡属低容错承诺，关键事实必须可追溯且不可漂移。
- 小前提（Minor）：LLM 在生成中不具备事实主权，可能发生幻觉与漂移。
- 结论（Conclusion）：技术方案中的关键事实不得由 LLM 生成；LLM 只能读取并表达。
**关键事实（技术方案硬字段）**建议至少包括：
- 人员配置（岗位、数量、驻场/远程、排班口径、资质约束）
- SLA/服务指标（响应、到场、恢复、升级、可用性、MTTR/MTBF、窗口期）
- 范围边界（服务范围、接口边界、甲乙责任）
- 交付物与验收（交付清单、验收标准、验收证据）
- 进度与里程碑（关键节点、依赖条件、验收节点）
- 设备/工具/平台（型号、数量、能力参数、部署位置）
- 合规标准与制度依据（标准库、制度条款、适用性标注）
因此系统必须建立 Single Source of Truth（事实单一源），在技术方案里体现为：
- 人员来自“人员主数据 + 可用性日历 + 资质校验”
- SLA 来自“服务目录参数表（可配置）+ 招标约束提取”
- 里程碑来自“计划求解/约束排程结果（或项目模板）”
- 合规条款来自“标准/制度库（含适用范围与版本状态）”
正文只“渲染”，不“加工”。 让模型写话，但不让模型写数字、写边界、写承诺口径。
2) 一致性不是靠“记忆”，而是靠“状态与事务治理”
同样用三段论把系统层逻辑钉住：
- 大前提（Major）：凡需全局一致、可锁定、可回放的行为，必须依赖外部状态存储与事务规则。
- 小前提（Minor）：LLM 的注意力机制不具备 ACID 式事务锁定能力，无法天然保证全局一致。
- 结论（Conclusion）：技术方案生成必须外置状态（Facts/IR/变量库），用绑定与引用维持一致，而非让模型“记住”。
把“别前后矛盾”变成“结构上不允许矛盾”：
- 关键字段只在事实库中存在一次（例如
SLA_响应=10min） - 文档多处出现时，由变量展开/填槽透传
- 若正文出现未授权数值或主体变更，直接拦截
- 所有变更记录可审计、可回滚（谁改了 SLA、为何改、影响哪些章节）
一个足够真实的漂移案例（技术方案常见失分点）：
- 第一章概况写“10人服务团队”；实施方案里写“15人服务团队”；服务保障里写“30人服务团队”。 评委不会替你推理“哪个才算数”，他们只会判断：承诺口径不稳，组织能力存疑。 用事实单一源 + 变量透传，这类漂移会被系统性消灭，而不是靠反复人工校对。
3) 可交付不是“生成后检查”，而是“构建时限定 + 输出门禁裁决”
再用三段论给出制度性答案：
- 大前提（Major）：凡容错极低的交付物，其正确性必须在构建时注入，并在输出前由确定性门禁裁决。
- 小前提（Minor）：若先生成再靠重试求收敛，既不稳定也不经济，还可能稳定输出稳定错误。
- 结论（Conclusion）：技术方案系统必须以“确定性内核”为中心：构建时约束解空间，输出前门禁否决，模型不拥有最终裁决权。
这一步把“确定性”升格为生产制度（仅针对技术方案）：
-
构建时：抽取招标约束与评分点 → 生成 IR（结构化方案骨架）→ 关键参数由求解/规则判定
-
生成时：LLM 只在受限解空间内渲染表达（用已锁定的事实、边界、指标）
-
输出前门禁（建议至少三类）
- 符号校验：数值口径一致、区间合法、单位一致、时间链合理
- 事实比对：关键字段 bit-wise 对齐事实单一源（不允许“近似表达”改变口径）
- 覆盖率检查：评分点/强制条款逐条映射到章节与证据，不漏项
不通过时的输出原则必须反直觉： 宁可熔断，输出“缺口清单/需澄清项”，不可编一个看起来合理的答案。
四、技术方案的关键词应当升级：从 Determinism 到 Firm
在技术方案里，“确定性”不应仅指“模型输出稳定”，而应升级为四件事的组合：
- Determinism（确定性）：关键指标、边界、承诺口径由事实单一源透传，不经神经网络加工。
- Verifiability（可验证性）：每个关键结论能点回依据（招标条款、企业主数据、方案参数表、制度库/标准库）。无依据不生成。
- Reliability（可靠性）：系统敢于拒答/熔断，宁可暴露缺口，也不输出幻觉承诺。
- Completeness（完整性）：评分点与强制条款全覆盖，不漏项；且覆盖不是“提到了”，而是“落到指标/措施/证据”。
于是，“技术方案里的高质量确定性”可以压缩成一句话：
让 LLM 失去“事实写入权”，只保留“语言表达权”； 让系统获得“事实主权”和“裁决权”，并对输出进行门禁审计。
五、最终公式：AI 技术方案的 Firm 版本定义
把整篇文章压缩成一个对内对外可复述的公式（限定技术方案）：
**AI Technical Proposal（Firm） = Deterministic Facts & Constraints（事实与约束内核）
- Constrained LLM Rendering（受限渲染）
- Deterministic Validation & Governance（门禁校验与治理回放）**
换成更直白的承诺就是：
- 关键指标：零生成，仅渲染（人员/SLA/里程碑/验收口径/边界）
- 每个结论：可回指依据（条款/参数/标准/制度/附件）
- 任何缺口：宁可拒答，不可编造
- 任何输出：过门禁才能交付
到这一步，“确定性”不再是一句口号，而是一套秩序： 心之所向为信（表达可笃定），理之所向为定（事实有主权），事之所向为预（交付可预期）。 我们追求的也不再只是 Determinism 的“骨”，而是 Determinism + Verifiability + Reliability + Completeness 共同构成的“Firm”。