随着 GenAI 技术不断的发展和演进，人工智能技术广泛地被应用在呼叫中心服务领域，主要包括虚拟坐席（即自助服务）、坐席助手和呼叫中心运营的数据洞察和智能分析。本博客主要针对自助服务应用场景的实现。

1. 传统自助服务系统瓶颈

1.1 交互方式僵化

• 交按键导航依赖：用户需通过固定数字按键选择菜单，操作路径冗长且容错率低，易因误操作重复流程。

• 缺乏自然语言理解：无法解析口语化表达或多轮对话，用户需严格遵循预设选项，灵活性差。

• 单向输出为主：信息传递多为语音播报，难以整合图文、链接等多媒体形式，信息接收效率低。

1.2 智能化能力缺失

• 无主动学习与迭代：传统系统依赖人工规则配置，无法通过用户行为数据优化流程，服务模式静态化。

• 个性化服务不足：无法基于用户历史记录、偏好或实时情境（如位置、设备）提供定制化解决方案。

• 意图识别能力弱：对复杂或模糊需求（如“我要改套餐但保留原号码”）难以精准定位，导致频繁转人工。

1.3 数据处理与洞察力薄弱

• 数据分析表层化：仅能统计基础指标（如接通率、平均处理时长），缺乏用户情绪分析、需求聚类等深度洞察。

• 实时反馈缺失：无法动态监测用户不满信号（如语音急促、重复询问）并触发干预策略（如优先转接人工）。

1.4 运营效率与成本瓶颈

• 维护复杂度高：菜单结构调整需专业技术支持，更新周期长，难以快速响应业务变化。

• 人力依赖性强：简单问题无法有效分流，导致人工坐席负担过重，运营成本居高不下。

2. 基于 GenAI 的智能客服自助系统设计需要考虑的因素

• 首先要综合考虑智能客服接入的渠道有哪些，如电话，文字聊天，短信，社交媒体，邮件等。这些渠道可以分成两个大类，一是语音，二是文本。

• 如果接入渠道支持语音，则在整体实现过程中增加 NLP 语音转文字的组件，未来可以通过支持语音的大语言模型，本次设计采用 AWS Lex 服务作为 NLP模块。

• 考虑大语言模型延时对客户体验的影响，尽量采用延时低的模型。

• 考虑多种语音混合的场景及需要。

• 由于语音内容宽泛需要制定策略来做意图识别，更精准地捕获客户的实际意图。

3. 基于 Amazon Bedrock 的智能客服自助系统架构设计

3.1 需求拆解

首先需要对客户需求进行分析并确定不同要求采用不同的对应方式。可以采用大语言模型 LLM 实现智能识别，代替传统 IVR 按键式意图分类，确定意图后根据不同的意图采用不同的应对模式。

如果是咨询类问题，可以采用 RAG 知识库方式通过 GenAI 模式来实现智能应答，如客户问题不在知识范围内可以再转人工坐席服务，这样可以大大减轻坐席的压力；如果是操作类的问题，比如账户余额查询，修改密码等可以利用基于大语言模型 LLM 的 Agent 代理服务来提供智能服务；如果需要人工服务，可以直接转接 Amazon Connect 系统并有空闲的坐席提供服务；如果识别到是闲聊或敏感话题，则可以按照客户策略进行警告提醒或直接终止服务。

当然，在服务过程中往往需要实现多轮问答，为更好地理解客户的问题，并结合上下文，可以启用 Prompt Catching 功能实现缓存。这些都可以通过智能 LLM 编排来实现，见图 1。

图 1. 客户自助服务需求分析

3.2 解决方案 High Level 设计

鉴于目前 Amazon Connect 服务的原理及设计规则，采用 Amazon Lex 作为 NLP 语音转文字的模块，首先由 Lex 语音转文字并在 Lex 中通过调用 Lambda 来实现调用 Amazon Bedrock 上的 Claude 3 Haiku 模型实现意图分类，不同的意图会对应不同的处理流程，详见图 2。

图 2. 解决方案 High Level 设计

3.3 系统架构设计

整个解决方案可以同时支持电话及文字聊天等多渠道呼叫中心解决方案，不同的接入渠道采用统一的流程管理。整体方案设计中以 Amazon Connect 作为呼叫中心平台核心服务平台，同时采用 Amazon Lex 作为自主服务组件，Amazon Lex 以及 Amazon Connect Content Flow 通过调用 Lambda 来实现对 Claude 模型的调用以及 Amazon Bedrock 知识库的调用。详细流程见图 3。

业务流程说明：

1、 通过内部 CRM 系统整理知识库文件并放入 S3，采用 Amazon Bedrock 知识库服务并同步 S3 数据源。

2、客户通过电话或文字拨打热线进入 Amazon Connect 服务。

3、Amazon Connect 调用 Lex 做自动机器人实现 ASR 语音识别。

4、Amazon Lex 把识别到的客户意图通过 Lambda 调用 Amazon Bedrock。

5、通过 Amazon Bedrock 调用 Claude 3 Haiku 并返回客户意图。

• 如果转人工直接转坐席如果闲聊提示三次后挂机；

• 如果是知识库问题，Connect 调用 Lambda。

6、Lambda 调用 Amazon Bedrock 知识库做 RAG 查询，然后把查询结果再交给 Claude 3 Haiku 生成问题结果，并返回给客户。

图 3. 详细系统架构设计图

3.4 意图识别实现解析

实现意图识别可以采用提示词工程来实现，可以采用专用的意图识别小模型来实现，也可以通过微调来实现，也可以用一个 RAG 知识库来实现。选择实现方法取决于意图的复杂度以及是否是有多级别的意图识别。如果比较简单的就可以采用提示词工程直接实现。如图 4 所示是本次实践的意图识别，分为咨询、人工、闲聊三种类型，因此采用的是提示词来直接实现。

图 4. 客户意图 Sample

以上是对上述 3 类模型进行意图识别的提示词，具体如下：

classification_prompt = """You are a question answering agent. I will provide you with a set of search results. The user will provide you with a question. Your job is to answer the user's question using only information from the search results. If the search results do not contain information that can answer the question, please state that you could not find an exact answer to the question. Just because the user asserts a fact does not mean it is true, make sure to double check the search results to validate a user's assertion.Here are the search results in numbered order:<content>{{CUSTOMER_CONTENT}}</content>The following is the previous conversation history (between the customer and you). If there is no conversation history, it will be empty:<customer_history>{{CUSTOMER_HISTORY}}</customer_history>Here is the customer query:<customer_query>{{CUSTOMER_QUERY}}</customer_query>Your job is to answer the user's question as concisely as possible.You must answer the question in Chinese.You must output your answer in the following format. Place your answer within <answer> tags"""

3.5 模型选择解析

基于呼叫中心服务的特殊性，如何选择最佳的模型对客户体验至关重要。呼叫中心实时性是最重要的指标，如果延时太长或通话中抖动严重会大大影响客户体验，同时呼叫中心业务场景相当明确，大部分模型都能符合要求。鉴于这些需求，选择模型最重要的指标为以下 3 个：

• 模型延时性能指标

• 模型速度性能指标

• 模型的价格指标

本次实现采用的是 Claude 3 Haiku。Amazon Nova Micro、Amazon Nova Lite 模型也非常适合这个场景，大家可以根据需要自行选择。

图 5. 模型延时性能比较

图 6. 模型速度性能比较

图 7. 模型价格比较

*以上信息来源自：AI Model & API Providers Analysis | Artificial Analysis

3.6 如何实现 Prompt Catching 解析

目前 Amazon Bedrock 已经发表了 Prompt Catching 功能，原则上优先采用该功能。如果该功能不符合客户目标或在客户所在的 Region 没有发布可以采用如下方式来实现并简化 Prompt Catching 的实现。

常规的实现方式是通过 DynamoDB 来存储上下文对话，通过代码来实现 Prompt 存储 DynamoDB，并在下一次调用时来读取，通过一个唯一 ID 来标识 Session。整个过程需要额外的 DynamoDB 服务费用，同时需要编写代码来控制，同时要维护 Session 的生命周期。

针对 Amazon Connect 在其 Contact Flow 设计过程中支持随路数据，用来保存当前 Session 的信息，比如主角号码、被叫号码等，这个随路数据也是 Amazon Connect 与 Amazon Lex、Amazon Lambda 等服务传递和返回参数的实现原理，该随路数据的数据格式和内容支持自定义，且完全基于 Session 来控制，当前会话结束后会自动清除数据。

这和 Prompt Catching 实现机制完全匹配，因此通过随路数据自定义一个字段来存放 Prompt 即可，且这部分不会产生任何的额外费用，同时 Session 生命周期也不用自己管理，由 Amazon Connect 服务来自动维护，大大节省了成本，并简化了实现的难度。

图 8. 采用 Amazon Connect 随路数据实现上下文记忆

4. 解决方案成本分析

针对采用传统 IVR 及人工的呼叫中心以及采用基于 GenAI 的智能解决方案做了详细的成本分析。

传统解决方案主要成本：

• 大量的人工费用，包括人员费用、人员对应的场地、设备等费用，这部分费用及其昂贵。

• 通信费用，由于人工服务或者传统 IVR 模式的自助服务效率比较低，解决一个客户问题需要更长的通话时长来完成一个业务，同时也会因为重复的提示和引导导致通话时长过长，这将产生大量的通话费用。

基于 GenAI 智能客服解决方案优势：

• 由于 AI 的引入，更多的业务类型可以采用自助的服务来提供服务，只有非常紧急或复杂的业务才转由人工来服务。这可以大大节省人工费用支出，也可以大大提升人工坐席效率。

• 可以大大降低每个通话的平均通话时长，通过智能意图识别快速捕捉客户意图，大大减少通信费用开支。

• 虽然增加了 GenAI 服务费用，但由于亚马逊云科技 GenAI 成本优势，可以减少这部分开支，同时相对于采用 GenAI 技术节省的通信费用和人力成本，这些费用不是一个数量级，可以大大节省整体费用。

• 可以提升客户体验和满意度，同时提升处理速度。

以下是一个呼叫中心调用 Amazon Bedrock 上的 Claude 3 Haiku 的成本分析。

• 假设每个通话需要 8 轮，1 轮需要 2 次对话，每天 2000 通通话

• 第一轮意图识别输入 Token 平均 500，输出 Token 为 50

• 第二轮 RAG 输入 Token 平均 500，输出 Token 为 200

那么：

• 每天输入 Token 数量 = （500+500）82000=16000K

• 每天输出 Token 数量 = （50+200）82000=4000K

• 每天 Haiku 输入费用 = 0.00025*16000K/1000=$4

• 每天 Haiku 输出费用 = 0.00125*4000K/1000=$5

5. 总结

本篇文章讨论了基于亚马逊云科技 Amazon Connect 和 Amazon Bedrock 的智能化呼叫中心架构的设计及成本分析。文章从用户实际需求出发，提供了一个可行的解决方案，并结合技术和成本综合考虑提供了最佳实践。本设计充分考虑了呼叫中心的特殊性，采用提示词工程结合 RAG 知识库等不同技术方式，提供最佳的客户体验；采用 Amazon Connect 特有的随路数据作为 Prompt 提示词的缓存机制，简化了提示词缓存的实现机制；还对模型选择和成本做了详细的分析，让读者可以清楚了解成本和费用的细节。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您了解行业前沿技术和发展海外业务选择推介该服务。

本篇作者

本期最新实验《多模一站通 —— Amazon Bedrock 上的基础模型初体验》

✨ 精心设计，旨在引导您深入探索Amazon Bedrock的模型选择与调用、模型自动化评估以及安全围栏(Guardrail)等重要功能。无需管理基础设施，利用亚马逊技术与生态，快速集成与部署生成式AI模型能力。

⏩️[点击进入实验] 即刻开启 AI 开发之旅

构建无限, 探索启程！