支持团队的知识通常散落在培训视频、旧工单、文档和个人经验中。生成式 AI 可以把这些非结构化信息转化为可检索的标准作业流程，再结合 Retrieval-Augmented Generation（RAG）辅助工单处理，并通过机器学习识别 SLA 风险、安排工作优先级。AWS 提供了覆盖数据处理、模型调用、检索和预测的一套云上技术组合。
一条贯穿支持运营的技术链路
可以把平台拆成四个阶段：
- 内容摄取：将培训视频上传到 Amazon S3，使用 Amazon Transcribe 生成带时间戳的文字稿。
- SOP 生成：调用 Amazon Bedrock 中的基础模型，把文字稿整理为步骤、前置条件、判断分支、升级条件和注意事项。
- 工单辅助：将 SOP、历史工单和产品文档切分并建立向量索引，在回答工单前检索相关内容，再让模型基于检索结果生成处理建议。
- SLA 预测：使用工单年龄、优先级、客户等级、队列积压、历史响应时长等特征训练模型，预测即将违反 SLA 的工单，并将结果反馈给调度系统。
这条链路的关键不在于单独部署一个聊天机器人，而在于把知识生产、知识使用和运营决策连接起来。模型生成的内容要能追溯到原始资料，预测结果也要能够解释和复核。
从视频生成结构化 SOP
培训视频适合人观看，却不适合搜索和自动化。视频处理流程可以先提取文字稿，再按主题或章节切分，最后生成统一格式的 SOP。一个实用的 SOP 结构可以包括：
- 适用场景和问题范围
- 前置条件与权限要求
- 操作步骤
- 每一步的验证方式
- 常见错误与处理分支
- 需要升级给二线或研发团队的条件
- 引用的原始视频时间点
下面是一个可以改造的 Python 示例。它读取本地文字稿，并调用 Amazon Bedrock Converse API 生成 JSON 格式的 SOP。运行前需要配置 AWS 凭证、区域，并确保账号已获得目标模型的访问权限。示例中的模型 ID 可以替换为所在区域可用的 Bedrock 模型。
import json
import os
from pathlib import Path
import boto3
AWS_REGION = os.getenv("AWS_REGION", "us-east-1")
MODEL_ID = os.getenv("BEDROCK_MODEL_ID", "anthropic.claude-3-haiku-20240307-v1:0")
TRANSCRIPT_PATH = Path(os.getenv("TRANSCRIPT_PATH", "training-transcript.txt"))
OUTPUT_PATH = Path(os.getenv("OUTPUT_PATH", "generated-sop.json"))
def generate_sop(transcript: str) -> dict:
client = boto3.client("bedrock-runtime", region_name=AWS_REGION)
prompt = f"""
You are a support operations analyst. Convert the transcript below into a practical SOP.
Return valid JSON only with these keys:
- title
- scope
- prerequisites: array of strings
- steps: array of objects with number, action, verification
- decision_points: array of objects with condition and next_action
- escalation_conditions: array of strings
- source_timestamps: array of objects with topic and timestamp
Do not invent product behavior. Mark uncertain information as \"needs_review\".
Transcript:
{transcript}
"""
response = client.converse(
modelId=MODEL_ID,
messages=[
{
"role": "user",
"content": [{"text": prompt}],
}
],
inferenceConfig={"temperature": 0.1, "maxTokens": 3000},
)
text = response["output"]["message"]["content"][0]["text"]
return json.loads(text)
def main() -> None:
transcript = TRANSCRIPT_PATH.read_text(encoding="utf-8")
sop = generate_sop(transcript)
OUTPUT_PATH.write_text(
json.dumps(sop, ensure_ascii=False, indent=2), encoding="utf-8"
)
print(f"Wrote {OUTPUT_PATH}")
if __name__ == "__main__":
main()
实际生产中，不能把模型输出直接发布为团队标准流程。可以增加 JSON Schema 校验、敏感信息检测和人工审批状态，例如 draft、reviewed、published。每一条 SOP 还应保留原始视频的对象版本、文字稿版本和时间戳，这样支持工程师可以快速回到原片段核对上下文。
用 RAG 辅助工单解决
RAG 的作用是让模型在回答之前查找企业自己的知识，而不是只依赖通用模型的训练内容。一次工单处理请求可以按以下顺序执行：
- 清洗工单标题、描述、对话记录和错误代码。
- 从知识库检索相关 SOP、产品文档和已验证的历史解决方案。
- 对检索结果按权限、产品版本、地区和文档状态进行过滤。
- 将证据和工单上下文传给 Bedrock。
- 返回建议回复、操作步骤、引用来源和置信度，而不是只返回一段无来源的答案。
可以使用 Amazon OpenSearch Serverless、Amazon Aurora PostgreSQL 的 pgvector，或其他与 AWS 集成的向量存储。技术选型应取决于现有数据平台、查询规模、权限模型和运维能力。
一个面向模型的提示词可以这样设计：
你是企业支持工程师助手。只根据 <evidence> 中的内容提出建议。
如果证据不足，明确回答“需要人工调查”，不要猜测。
输出 JSON：
{
"summary": "问题摘要",
"recommended_actions": ["按顺序排列的操作"],
"customer_reply": "可以发送给客户的回复草稿",
"escalation_required": true,
"citations": ["文档 ID 或 SOP ID"]
}
<ticket>
产品版本：{{product_version}}
优先级：{{priority}}
工单描述：{{ticket_text}}
</ticket>
<evidence>
{{retrieved_documents}}
</evidence>
检索结果不是越多越好。过多的相似片段会增加上下文成本，也可能把不同版本的解决方案混在一起。应优先使用版本匹配、状态为已发布、来源可靠的内容，并在索引元数据中保存 product、version、locale、owner 和 published_at 等字段。
用机器学习识别 SLA 风险
生成式 AI 适合处理语言和知识，SLA 预测则更适合交给传统机器学习模型。平台可以为每个开放工单计算风险分数，例如：
- 距离 SLA 截止时间的剩余分钟数
- 当前队列和负责团队的积压量
- 工单优先级、客户等级和产品类型
- 首次响应是否已经完成
- 最近一次客户回复距今的时间
- 历史上相似问题的平均解决时长
- 是否发生过重新分派、升级或等待客户确认
可以在 Amazon SageMaker 中训练分类或回归模型，也可以先使用规则与统计模型建立基线。关键是避免数据泄漏：预测时只能使用当时已经可见的信息，不能把工单最终解决时间等未来字段带入训练特征。
风险结果应进入现有队列，而不是停留在报表里。比如将高风险工单提升到值班组顶部，给即将超时的工单增加提醒，并为每次自动排序记录触发原因。支持主管需要能够回答“为什么这个工单被提前处理”，而不是只看到一个神秘分数。
落地时要守住的边界
这类平台会同时接触客户内容、内部文档和运营数据，权限与审计必须和模型能力一起设计：
- 使用 IAM、数据分级和细粒度文档过滤，防止模型引用用户无权访问的资料。
- 对客户个人信息、令牌、账号标识和内部机密做脱敏或访问控制。
- 对模型输出保存提示词版本、检索文档、模型版本和人工修改记录。
- 通过离线评测集检查事实准确率、引用覆盖率、拒答质量和不同语言的表现。
- 对自动回复、自动关闭工单和高影响 SLA 决策保留人工确认。
- 监控模型调用延迟、Token 成本、知识库新鲜度和预测模型的漂移。
可以按三个阶段推进：先把视频和文档转成可审核的 SOP；再将 RAG 建议嵌入工单界面；最后使用真实运营数据训练 SLA 风险模型。每一步都应定义可衡量的指标，例如 SOP 审核通过率、平均处理时长、一次解决率、引用正确率和 SLA 违约率。
结语：把 AI 放进流程，而不是只放进聊天框
AWS 上的生成式 AI 支持运营平台可以同时改善知识整理、工单处理和工作调度，但它的价值取决于数据质量、权限设计、来源可追溯性和人工反馈闭环。建议从一个产品线或一个高频问题域开始，先建立可靠的内容和评测基础，再逐步扩大模型的决策范围。对于高风险客户沟通和 SLA 操作，保留人工审批通常比追求完全自动化更稳妥。