Telonic文档
中文

治理与控制

变更如何上线

对您的 AI 智能体的每一项变更从申请到发布所经过的流程、由谁审批、每个版本如何保留并可撤销,以及紧急变更如何处理。

本页内容
  1. 六个步骤
  2. 谁可以审批变更
  3. 每一项变更都有记录,并且可以撤销
  4. 比较两个版本
  5. Telonic 所做的变更
  6. 紧急变更
  7. 技术细节
  8. 实际应用
  9. 您的团队掌控的内容
  10. 相关内容

对您的 AI 智能体的每一项变更,都遵循同一条成文的流程:提出申请、在测试环境中构建、测试、由您指定的人员审批、发布,然后记录。无论变更来自您的团队(例如一条新的升级规则),还是来自 Telonic(例如一个较新的语言模型,即理解对话并撰写答复的 AI 组件),都是如此。每一项变更都有记录,并且可以撤销。贵机构始终清楚自己的智能体在做什么、为什么这样做,以及从何时开始这样做。

六个步骤

步骤具体内容执行者
1. 申请提出变更,并说明理由您的团队,通过控制台(您的团队使用的 Telonic 网页应用)或通过您的 Telonic 联系人提出;或由 Telonic 为某项改进或平台变更提出
2. 构建变更在测试环境中进行,绝不直接在生产环境中进行您的团队负责其掌握的控制项;Telonic 负责构建工作
3. 测试用您所在行业的测试集、回归测试套件进行测试,在已配置的情况下还会使用模拟对话;您的团队亲自试用Telonic 和您的团队
4. 审批您指定的人员审阅变更和测试结果,并审批通过您指定的审批人
5. 发布变更在约定的时间进入生产环境Telonic;控制台中的控制项由您的团队发布
6. 记录记录新版本,包括由谁申请、由谁审批以及何时上线记录在控制台中

谁可以审批变更

您在实施期间按角色指定审批变更的人员。不同类型的变更可以由不同的审批人审批。一家保险公司可能会要求,凡对范围、限制或经审批答复的变更都须经其合规团队审批,凡更换服务商都须经其 IT 安全团队审批。

审批人在做出决定之前,可以看到变更的内容、原因以及测试结果。未获审批的变更不会上线。每一次审批都会被记录。参见您的团队掌握的控制权。

每一项变更都有记录,并且可以撤销

您的 AI 智能体处于版本控制之下(记录智能体配置的每一个版本,以便恢复任何较早的版本)。每一项变更都会创建一个新版本,之前的版本会被保留。

如果某项变更上线后未能按预期运作,获得授权的人员可以恢复之前的版本。恢复版本本身也是一项变更:它会被记录,包括由谁执行以及原因。每个智能体的变更历史都会显示每一个版本、变更了什么、由谁申请和审批,以及何时上线。参见审计日志与决策记录。

比较两个版本

A/B 测试让一个智能体的两个版本并行运行,各自处理一部分对话,以便您在将其中一个定为标准版本之前比较两者的结果。当确实无法确定哪种做法效果更好时,这种测试很有用,例如解释付款计划的两种方式,或首次报案中提问的两种顺序。

两个版本在比较开始前都要经过测试和审批。A/B 测试在实施期间为您希望使用它的工作流进行配置。

Telonic 所做的变更

Telonic 持续改进平台和行业模型,其中一些改进会进入您的部署环境。这些改进遵循同一流程:发布前经过审阅和测试,包括用您所在行业的测试集进行测试。

针对您的部署环境的任何模型或服务商更换,都要在发布前获得贵机构的审批;只有当新模型在您所在行业的测试集上的表现至少与现有模型相当时,才会被采用。在您的智能体的行为方式或其运行平台发生任何重大变更之前,您都会收到通知。紧急安全修复在完成测试后即会应用,并会告知您变更了什么。

紧急变更

当某些内容需要紧急更改时,您有两个完全无需发布的选项。您可以在您自己的电话系统中或在控制台中,把某个渠道转回给您的团队。或者,如果某份来源文档有误,您可以在源头更正,智能体的知识会与您的文档保持同步。参见实践中的人工监督。

对于智能体本身的变更,流程会缩短,但不会跳过。变更在测试环境中构建,并用与之相关的测试进行测试。它由您指定的紧急审批人审批、发布,并在事后与您一起复盘。它会像其他任何变更一样被记录。

技术细节

问题答案
什么算作变更?对智能体的配置、工作流、规则、限制、知识来源、经审批的答复、语气、模型或服务商的任何更改
变更在哪里进行?在测试环境中。只有在经过测试和审批之后,变更才会进入生产环境
如何恢复版本?由获得授权的人员恢复之前的版本,这本身也会作为一项变更被记录
对您文档的更改是否视为版本发布?您的文档由您自行更新。当您的文档发生变化时,智能体的知识会重新建立索引(重新读取并整理以便检索),因此它的答复会跟随您最新审批通过的内容
重大变更会提前多久通知?按您的协议中的约定

实际应用

迪拜开发商 Sahel Crest Properties 在其交房热线上运行智能体。

  1. 客户服务负责人注意到,有买家报告公寓受潮。她希望这些情况直接转给交房团队,以便由工作人员预约检查。
  2. 她在控制台中提出变更,并说明理由。
  3. 变更在测试环境中构建。房地产测试集、回归测试套件以及一组用阿拉伯语和英语发送消息的模拟买家,全部通过。
  4. 该开发商要求升级规则的变更须经合规部门审批。合规经理阅读测试摘要后审批通过。
  5. 变更在周日清晨、交房热线变得繁忙之前发布。第 23 版上线,第 22 版保留。
  6. 一周后,团队复盘新规则产生的转交情况,决定保留这条规则。

您的团队掌控的内容

  • 由谁审批每一类变更,包括紧急变更。
  • 何时发布。
  • 是否恢复之前的版本。
  • 哪些工作流使用 A/B 测试。