跳至交互体验

02 / 验证

数字没错⁠。 问题答偏了⁠。

答案生成的速度,早已超过人核验的速度⁠。数字越像真的,错误越难察觉⁠。给出答案时,也要给出核验的依据⁠。

说它正确,要有依据。

交互体验虚构案例
02 / 验证

向下探索,亲手操作。

先读问题, 再核对答案⁠。

销售负责人要决定是否接下一笔交期紧迫的大额订单,先问数据问答智能体:上个月的按期交付率是多少?智能体回答 94%。同样的问题以前答偏过一次,修正还存在记忆里。这个答案能不能用,由你来核对。

  1. 02核对计算:按答案的口径,重算 100 笔订单。
  2. 03核对口径:把答案的口径和记忆中的修正对照。
  3. 04用两种口径各算一次,改写答案。
  4. 05接不接由人决定,决定留下记录。

每一步都等你来按,上一步完成后,下一步才会打开。

虚构情境订单、人物和数字都是为演示设计机制编造的。不是真实客户数据,不代表实测的效率提升,页面上也没有运行中的 AI。

01同一个问题,又是 94%。

一周后,另一笔大额订单带来了同一个问题。智能体又回答了 94%。记忆里还留着上次的修正,但这不代表答案会遵守它。

做决定前,分开查两件事:算得对不对,答的是不是这个问题。

02算得对吗?

按答案采用的口径,重新统计上个月的 100 笔订单。

03回答了这个问题吗?

把答案采用的口径,与记忆中的修正逐项对照。

还未核对计算。 先核对计算

04用两种口径,各算一次。

同样的 100 笔订单,分别按工厂承诺交期和客户要求交期统计。

还未核对计算。 先核对计算

05接不接,由人决定。

答案连同口径和依据,一起交给销售负责人。这笔交期紧迫的大额订单,接不接?

还未核对计算。 先核对计算

算得对, 不代表答得对⁠。

设计原则

把验证拆成两步:计算是否正确,口径是否符合问题。口径不明,就明确说不明。决定交给人,决定本身也要留下记录。

发生了什么

答案从 94% 变成了 79%,计算却从头到尾没有错。变的是口径:同样 100 笔订单,从按工厂承诺交期改为按客户要求交期,15 笔订单的判定随之改变。

为什么重要

口径错了的答案,看起来和正确的答案一样可信:数字精确,算法也查得通。只核对计算,它就会被放行;而接不接这笔订单,正是依据这个数字决定的。

如何用到其他判断

面对 AI 给出的任何数字,都分开问两件事:算得对吗?答的是这个问题吗?口径不明时,就说明不明,把可能的口径和各自的结果一起列出来,交给提问的人选择。

同样的问题到处都有:「活跃用户」按登录算,还是按操作算?「收入」含不含退款?「准时」按哪一个日期?

这个答案,靠什么成立⁠?

随你在上方的每一步更新:核对过的进入证据,当作成立却没核对的留在假设,这份数据回答不了的列为未知。

从第 02 步开始:核对计算

证据

0

在本页核对过

还没有。核对之前,94% 只是一个说法。

假设

3

当作成立,没有核对

  • 计算没有错。第 01 步
  • 答案用的口径,就是问题要的口径。第 01 步
  • 这 100 笔就是上个月的全部订单,日期都记录准确。第 01 步

未知

0

这份数据回答不了

还没有列出。用两种口径各算一次之后,才看得出这份数据回答不了什么。

这是一个虚构的简化示例,用 100 笔模拟订单验证一个问题。两组比例均由页面中的订单数据实际计算得出。真实验证还需要核对口径的来源和统计范围。

常见问题

这些是真实公司的数据吗?

不是。订单、人物和数字都是虚构的。94% 和 79% 也不是写死的:页面每次都用这 100 笔虚构订单实际计算出来。

页面上有 AI 在运行吗?

没有。「智能体的答案」是事先写好的情境。页面演示的是一种设计机制:把核验拆成两步,让答案带着它的依据交出去。

这能说明效率或准确率提高了吗?

不能。页面没有测量任何效率或准确率。它只展示一件事:只核对计算的时候,会放过什么。

口径已经修正过一次,为什么还会答偏?

修正存进了记忆,不等于下一次的答案会遵守它。所以每次都要拿答案对照问题,而不是相信上次已经修好。 看记忆如何把结果带回来

问题本身的口径不明确,怎么办?

明确说出它不明确。把可能的口径和各自的结果一起列出来,交给提问的人选择;系统不替人做这个选择。

怎么用到自己团队的 AI 回答上?

从最近一个被拿来做决定的数字开始:它按什么口径算?这个口径和提问的意思一致吗?哪些部分核对过,哪些只是假设,哪些还不知道?把这三栏和数字一起交出去。