推荐可信性保障
在引入对象化契约 （Proposal → Review Report → Decision）之后， 系统仍然面临一个关键问题：
如何判断一个 AI 建议
是否“足够可靠”可以继续？
LLM 的错误往往不会表现为明显失败， 而是看起来合理，却悄悄出错。
推荐可信性保障（Recommendation Assurance） 正是为了解决这一问题而存在。
业务系统中的 AI 风险特征
在真实系统中，AI 的问题通常是：
- 结构正确
- 表达自信
- 逻辑连贯
- 但业务上不成立
如果没有专门的保障层， 这些问题会被系统默默接受， 并逐步扩散。
保障的目标不是“零错误”，
而是可控的不确定性。
保障 ≠ 信任
一个常见误区是： 把模型的自信当作正确性的指标。
但 LLM 并不具备“自我校准”的能力。
推荐可信性保障明确拒绝：
- “看起来没问题”
- “模型说得很肯定”
- “之前也这么做过”
它关注的是：
- 校验了哪些规则？
- 依赖了哪些假设？
- 证据是否充分？
- 不确定性在哪里？
可信性保障流水线
在 BookiAI 中， 可信性保障是一条结构化评估流程， 其产出是 审阅报告（Review Report）。
常见评估阶段包括：
-
结构校验（Schema Validation）
确保建议在形式上完整 -
确定性规则校验
会计规则、业务约束、不变量 -
上下文一致性检查
与现有状态、历史记录是否冲突 -
置信度与风险评估
对不确定性进行显式标注 -
二次审阅（可选）
更严格的 AI 或人工复核
每一步都提供“证据”， 而不是直接做决定。
审阅报告是一等公民
可信性保障的输出 不是一个简单的“通过 / 不通过”。
而是一份 审阅报告，记录：
- 执行了哪些校验
- 结果如何
- 风险点在哪里
- 仍存在哪些不确定性
- 结论依据是什么
这份报告是：
- 可审计的
- 可回放的
- 机器可读的
并且，它刻意不包含执行指令。
失败是一种正常结果
在这个体系中， “未通过”不是异常。
常见情况包括：
- 置信度不足
- 上下文缺失
- 规则冲突
- 结果歧义
当保障未通过时：
- 系统不执行任何操作
- 原因被明确记录
- 是否继续由 Controller 决定
失败本身成为有价值的信息。
可信性保障如何支撑自动化
自动化并不是
本文由 ChatGPT 撰写，经 BookiAI 团队审阅。