OpenAI通过每次交互改进支持服务
摘要
OpenAI分享了如何使用AI重新设计其支持运营,每年处理数百万个请求,建立了一个每次交互都能改进下一次的运营模式。该方法整合了聊天、邮件和电话等多个渠道,持续改进知识库,并通过人工-AI评估循环使支持代表能够充当建设者并为产品改进提供信息。
了解OpenAI如何利用AI增强支持服务,缩短响应时间、提高质量,并扩展以满足高速增长的需求。
查看缓存全文
缓存时间:
2026/04/20 14:52
# 通过每次互动在 OpenAI 改进支持
来源:https://openai.com/index/openai-support-model/
*这是我们系列文章的一部分,分享 OpenAI 如何使用自身技术和 API 的内部示例。这些工具仅在 OpenAI 内部使用,在此分享作为前沿 AI 如何支持我们各团队用例的说明性例子。我们也分享了内部工具名称,以便更清楚地了解前沿 AI 如何帮助我们的团队完成工作。*
支持历来意味着队列、工单和吞吐量。但在 OpenAI,这还不够。我们为数亿用户提供服务,每年处理数百万个请求,并看到这个数量每年以倍数增长。
许多组织都在处理规模问题。但很少有组织同时处理规模**和**超高速增长。几乎没有组织同时面对这两个问题——同时还在构建可能改变这一局面的技术本身。这个独特的组合让我们有机会从头开始重新思考支持。
> "支持从来不只是回复工单。关键是人们是否得到了他们需要的东西,它是否真正为他们服务。"
Glen Worthington,用户运营负责人
支持不是一个数量挑战。它是一个工程和运营设计挑战。所以我们构建了不同的东西:一个运营模型,其中每次互动都改进下一次。
运营团队想要远超越使用聊天机器人来处理支持问题。该团队有一个愿景:将支持重新想象为一个不断学习和改进的 AI 运营模型。
中心有三个构建块:
- **交互界面。** 支持系统被交互的地方。聊天、电子邮件和电话,但越来越多的是直接嵌入产品内的帮助。
- **知识库。** 不仅仅是静态文档,而是从实际对话、政策和背景中提取的活的、不断改进的指导。
- **评估和分类器。** 由软件和人类共同建立的共享质量定义,以及测量、改进和突出反馈的工具。
这些部分不是孤立存在的。它们形成一个循环。在企业对话中发现的模式可以为开发者常见问题提供信息。为一个案例编写的评估可以为数千个其他案例增强模型。因为相同的原语为每个界面——聊天、电子邮件、语音——提供动力,改进会自动在各渠道扩展。
支持代表的角色正在改变。我们的目标是将模型从主要关注处理事务性工作转变为参与整体构建的一部分。他们有权为架构本身做出贡献,既可以直接通过自下而上地推送更改,也可以通过他们日常工作的自然流程间接地进行。
代表标记应成为测试用例的互动,在看到新模式时提议并推送分类器,甚至在几天内原型化轻量级自动化来关闭工作流缺口。培训也会转变,不仅仅涉及政策,还涉及评估互动、识别结构性缺口,以及反馈改进。
新方法致力于确保支持代表既是构建者也是响应者。
> "代理不仅仅是在回复工单。他们在为我们的知识库和政策提供信息。他们有我们没有的实地信息。"
Shimul Sachdeva,工程经理
结果是一个支持组织,其特点不是吞吐量,而是其进化的能力。每个人不仅在为用户服务,还在积极改进为*所有*用户服务的机制。
以这种方式构建支持只有在我们基于 OpenAI 堆栈的情况下才有可能。
- Agents SDK 默认为我们提供步骤级跟踪和可观测性。我们可以回放运行、检查工具调用并立即调试根本原因。
- Responses API 为音调、正确性和政策遵守性的分类器提供动力。
- Realtime API 使语音支持成为可能。
- OpenAI 的 Evals 仪表板使质量可测量并易于随时间可视化。
因为平台原语已经现成可用,我们花费更少的时间来拼接系统,花费更多的时间专注于重要的工作:定义好的样子、测量它和改进它。
我们从一个效果很好的简单问答回答器开始。使用 Agents SDK,我们迅速扩展到动态操作,如退款、发票、事件查询。随着模型继续通过更大的上下文窗口、Deep Research 和更强大的代理能力改进,我们可以立即采用这些进步。
Evals 将日常对话转化为生产测试。它们编纂了什么是"伟大"——不仅仅是解决问题,而是以礼貌、清晰和一致的方式解决。代表在这里发挥直接作用,标记强弱示例以成为评估,这些评估在生产中持续运行以指导模型行为。
"通常当你遇到问题时,你只是想尽快获得帮助。通过使用我们的 AI 工具,我们能够更快地获得这些响应——同样重要的是,我们知道模型何时不应该回答,"软件工程师 Jay Patel 说,支持自动化。
学习不在解决时停止。模式反馈到知识、自动化和产品设计中。系统复合:用户的更快答案、构建者的更紧密反馈循环,以及跨每个界面的一致更高的质量标准。
不仅仅是 AI 在学习。组织也在与它一起学习。专家看到模型的不足之处,塑造新的分类器,并为微调贡献数据集。可观测性仪表板使质量可测量,显示性能如何随时间改进。
最深刻的转变不是工具,而是人以及组织如何衡量成功。支持专家因解决问题而得到认可,也因完善知识、改进模型和扩展系统本身而得到认可。领导者寻找一种新型队友:一个将前线同理心与设计直觉相结合的人,结合支持工艺和改进系统的好奇心。
> "我们开始看到深厚工艺专业知识和深厚工程专业知识之间的这种结合。这是部门如何运作的未来。"
Glen Worthington,用户运营负责人
我们的愿景是支持不再是你去的目的地。它成为一个行动,融入每个产品界面。用户不会"开一个工单"。他们只是在需要的地方获得所需的东西。
开始作为对规模的回应已成为人和 AI 如何一起工作的蓝图:协作、自适应和不断改进。
相似文章
OpenAI Blog
OpenAI 推出了一个新系列,展示其如何在销售、支持、财务和产品团队中内部使用自己的 AI 模型和 API。该项目展示了真实的 AI 部署模式和工具,如 GTM Assistant、DocuGPT 和 Support Agent,旨在提高生产力和决策能力。
OpenAI Blog
OpenAI 开发了一个内部研究助手,它将仪表板与对话式 GPT-5 界面相结合,帮助团队在几分钟内分析数百万支持工单并生成洞察,而不是花费数周时间。该工具在整个团队中实现了数据分析民主化,允许非技术用户用自然语言提问并获得关于产品反馈、客户情感和趋势的可行性报告。
OpenAI Blog
# 在 OpenAI 将入站线索转化为客户 来源:[https://openai.com/index/openai-inbound-sales-assistant/](https://openai.com/index/openai-inbound-sales-assistant/) *这是我们分享 OpenAI 如何使用自有技术和 API 的内部案例系列的一部分。这些工具仅在 OpenAI 内部使用,此处分享作为说明前沿 AI 如何支持我们各团队用例的示范。我们还分享了内部工具名称以保持清晰*
OpenAI Blog
OpenAI推出GTM Assistant,这是一个建立在OpenAI自动化平台之上的内部AI工具,通过Slack交付,帮助销售团队减少准备工作量并集中化产品知识。该系统通过自动化客户研究、会议简报和产品常见问题解答,为销售代表带来了20%的生产力提升,同时在整个组织中推广最佳实践。
OpenAI Blog
Factory 推出了一个命令中心,用于软件开发,利用 OpenAI 的 o1、o3-mini 和 GPT-4o 推理模型,将工程周期加速 20-400%,将上下文切换减少 60%,并通过开发生命周期中的 AI 驱动代码理解和推理为开发人员每周提供 10 多小时的时间。