Belief System 分析 · 发布于 .
演示并不定义服务
成功的演示表明，在某些条件下，结果是可能的。它不会自动说明获得此结果的频率、针对哪些用户或使用哪些控件。当公开演讲消除这些条件时，就会出现声誉风险。实验功能变成通用能力；援助变成自主；选定的结果成为代表性的表现。
我们的出发点是回顾动词。 “帮助编写”、“检测”、“建议”和“决定”描述了不同的职责。对于每个配方，产品团队必须明确系统实际执行的操作以及用户仍需要验证的操作。然后，传播部门可以构建一个可以理解的承诺，而不让读者自己发明限制。
将每个承诺与使用场景相关联
NIST 的自愿人工智能风险管理框架解决了系统整个生命周期中的信任问题。针对生成人工智能的简介完善了针对这些用途特定风险的方法。这些文件并不构成对公司正在推广的产品的认证。 [1] [2]
对于编辑工作，我们建议将断言与用户、任务、环境以及发生错误时可能的后果相关联。用于准备草稿的可接受的功能可能不适合自动提供引人入胜的响应。这种区别应该反映在公开例子、支持文件和领导干预中。公司叙述不应承诺一定程度的自主权，但使用条款却会谨慎地取消该自主权。
组织从证据到故事的过渡
承诺表可以包括公布的结果、评估协议、观察到的限制、计划的人工控制以及能够解释测量的人员。这不是公布所有技术细节的问题。这是关于选择一个团队知道如何捍卫其范围的方案。如果使用比较，读者必须能够理解测试的参考和条件。
负面或不完整的结果对于沟通工作也很有用。它们指出了面试前要准备的问题以及不宜进行的做法。承认特定限制的消息通常比“负责任的”人工智能的一般主张提供更多信息。 Precision让公众能够评估该解决方案是否满足自己的需求。
在宣布之前准备事件
不准确的响应、不适当的输出或意外行为可能会成为广泛传播的屏幕截图。第一个响应应该确定实际发生的情况、受影响的版本以及受影响的人员。我们必须避免以未预见到事件为由否认该事件，或立即将示例推广到该服务的所有用途。
通信、产品、安全和相关功能必须有资格电路。谁证实了这一事件？谁决定暂停一项功能？谁回应用户？什么时候可以公布更正？公众的反应必须区分已经采取的保护措施、正在进行的调查和尚待检验的改进。如果事件显示出持久的限制，则必须纠正最初的承诺。
示例：从节省时间到承担真正的责任
让我们想象一个发布者引入了一个能够准备对投诉的响应的向导。该示例纯属虚构。该演示显示了令人信服的草案，但该服务有时依赖于不完整的文档并且需要验证。宣布“自动索赔处理”可能会产生组织无法满足的期望。 “准备回复供顾问审核”描述了一个不同的、更具体的功能。
传播部门可以通过解释所使用的文档、顾问的角色以及如何报告错误来丰富这一表述。它还可以让定义评估的专家发言。这项工作为思想领导力提供了更多实质内容：演讲涉及已解决的问题及其处理的条件，而不是一般性的破裂承诺。
发布前的编辑审查
| 问题 | 得到什么 |
|---|---|
| 该系统实际上做了什么？ | 精确的使用范围 |
| 我们怎么知道？ | 协议和情境化结果 |
| 他哪里会出错呢？ | 可向用户解释的限制 |
| 谁来承担责任？ | 人类角色和决策回路 |
| 出错后会发生什么？ | 有组织的回应和纠正 |
此次发布并没有结束本次审查。模型、数据或产品的更改可能会改变现有承诺的含义。因此，参考页面必须有一个更新管理器，就像技术文档一样。
对于Belief System来说，人工智能公司的权威在于其解释自己能做什么、展示其如何评估自己以及解决差异的能力。沟通就成为持久信任的工具，因为它使支持创新的责任变得可见。