Aderant用Amazon Nova Lite搭建工单分诊系统，2.5 周处理 109 张工单、准确率约 96%
Aderant的SierraOps团队用Amazon Bedrock上的Nova Lite自动完成工单上下文收集、分类、路由和知识补充，首 2.5 周路由准确率约 96%，估算每周回收 8–14 个工程小时，系统月成本不到 30 美元。
AI解读：Aderant为法律行业提供业务管理软件，其 38 人的SierraOps团队要维护分布在 268 个客户环境中的Expert Sierra。团队每周平均处理 34–40 张支持工单，但每张工单在开始解决前都需要 15–25 分钟人工调查：理解请求、找客户环境信息、判断归属、查文档和工单历史，然后才决定分给谁。这些调查动作重复度高，正是这套系统针对的痛点。
Aderant用Amazon Bedrock上的Amazon Nova Lite搭建了Intelligent Ticket Analyzer，由单个AWS Lambda函数编排，工作日每小时通过EventBridge触发，只处理CloudOps队列中新建且未分配的工单。
它会从Jira、Confluence、Amazon Athena和Microsoft SharePoint收集上下文，给出团队归属建议和解决起点，并在置信度达标时自动执行路由、通知和沟通动作；低置信度的工单转人工复核。
首 2.5 周（2026 年 6 月 30 日至 7 月 17 日）的生产数据显示：分析 109 张工单，路由准确率约 96%（4 张错分）。按部署前 15–25 分钟/张的人工基线估算，每周回收 8–14 个工程小时（每月 32–56 小时），系统总月成本低于 30 美元，其中Bedrock推理成本低于 1 美元/月。
Aderant说选Nova Lite是因为在相同工单内容、环境数据和解决历史下，它给出的解决步骤更具体、关联历史问题更有效；同时它与Bedrock Converse API、IAM权限、AWS SDK和现有AWS环境原生集成，不需要再签外部模型供应商；成本也低到可以分析常规工单，而不是只处理高优先级案例。
系统只使用内部运营工单数据、运营元数据和内部知识源，不访问、处理或存储客户事项数据或客户应用业务数据。Aderant也明确表示这 2.5 周是早期生产结果，不应被当作长期性能基准。对运维团队来说，这套方案的价值在于把重复调查工作自动化，同时保留低置信度决策的人工审查；对想复制这条路径的团队，需要注意的是它依赖已有的工单、文档和环境元数据质量。
Aderant是一家面向法律行业的全球业务管理软件提供商。该公司用Amazon Bedrock上的Amazon Nova Lite构建了一套Intelligent Ticket Analyzer，用来自动完成支持工单分诊中的上下文收集、分类、路由和知识补充工作。Aderant与AWS机器学习博客联合发布了这一案例。
这套系统支持Aderant的 38 人SierraOps团队。该团队在全球 268 个客户环境中运营Expert Sierra。分析器在工作日按每小时一次的调度周期，检查新提交且未分配的工单。
据发布内容，在 2026 年 6 月 30 日至 7 月 17 日的首个 2.5 周生产期内，分析器检查了 109 张工单，路由准确率约为 96%。Aderant根据团队在自动化前测量的人工分诊基线估计，该系统每周可回收 8–14 个工程小时，总运行成本低于每月 30 美元。
SierraOps团队平均每周处理 34–40 张支持工单。在自动化之前，每张工单需要 15–25 分钟人工调查才能开始解决工作：工程师要理解请求、查找客户环境细节、确定归属、搜索文档和工单历史，然后分配或转交。
该分析器只使用内部运营工单数据、运营元数据和内部知识源。发布内容明确说明，它不访问、处理或存储客户事项数据或客户应用业务数据。
每小时触发一次的五阶段工作流
Intelligent Ticket Analyzer是一个无服务器工作流，由单个AWS Lambda函数编排，工作日通过Amazon EventBridge每小时触发一次。对CloudOps队列中的每张未分配工单，流程分为五个阶段：
识别（Identify）：从Jira获取未分配工单。
补充（Enrich）：从Amazon Athena收集客户元数据，从Confluence和SharePoint提取相关知识，从Jira查找可比较的已解决工单。
分类（Classify）：将工单和汇集后的上下文通过Amazon Bedrock Converse API发送给Amazon Nova Lite，进行结构化分类并给出建议的下一步。
行动（Act）：发布分析和确认信息，重新分配错误路由的工单，通知相应的Microsoft Teams频道，并对支持可解决的场景应用预定义动作。
观察与改进（Observe and improve）：将运营指标发布到Amazon CloudWatch，并将低置信度分类转人工审查。当置信度达到配置的阈值时，路由和重新分配决策可以自主执行；置信度较低的工单会被标记供人工审查。团队监控置信度、错误路由和处理延迟，每周审查路由修正，并用这些发现完善提示词和路由逻辑。
- 触发：Amazon EventBridge按小时触发AWS Lambda，仅工作日运行。
- 数据源：Jira、Amazon Athena、Confluence、Microsoft SharePoint、Microsoft Graph API。
- 模型：Amazon Nova Lite，经Amazon Bedrock Converse API调用。
- 执行动作：发布分析、重新分配错误路由、通知Microsoft Teams、应用预定义动作。
- 监控：Amazon CloudWatch；DynamoDB支持跨工单模式追踪。
- 部署：全部通过单个AWS Serverless Application Model（AWS SAM）和AWS CloudFormation模板部署。
为什么选Nova Lite：运营具体性、AWS原生集成、成本
Aderant通过Amazon Bedrock用真实工单数据评估了多个基础模型，最终选择Amazon Nova Lite，有三个原因。
运营具体性：在使用相同工单内容、环境数据、运行手册和解决历史进行比较时，团队发现Nova Lite提取的解决步骤更具体，关联过往问题也更有效。
AWS原生集成：Nova Lite与Amazon Bedrock Converse API、AWS Identity and Access Management（IAM）权限、AWS SDK以及现有AWS环境集成，减少了额外引入外部模型供应商或供应商合同的需要。
工单规模下的经济性：该模型的成本结构使分析常规工单变得可行，而不仅限于高优先级案例。在初始生产期，系统总成本低于每月 30 美元，Bedrock推理成本低于每月 1 美元。
首 2.5 周生产数据
Aderant发布的首个生产期指标如下，测量期为 2026 年 6 月 30 日至 7 月 17 日。
路由准确率的测量方式，是将分析器的分配结果与最终解决每张工单的团队进行比较。时间节省则基于部署前四周的基线：每张工单人工分诊 15–25 分钟。
发布内容说明，回收的产能被重新投入到复杂故障排查、基础设施改进和需要人工判断的主动工作上。这些发现代表早期生产阶段，应被理解为初步运营结果，而不是长期性能基准。
- 分析工单数：109
- 路由准确率：约 96%（4 张错误路由）
- 平均工单量：每周 34–40 张
- 人工分诊基线：每张 15–25 分钟
- 估算回收工程时间：每周 8–14 小时
- 估算每月回收时间：32–56 小时
- 系统总成本：低于每月 30 美元
- Amazon Bedrock推理成本：低于每月 1 美元
三个生产案例和一个知识循环
发布内容给出三个生产中的例子。第一，一张描述Azure DevOps站点 404 错误的工单进入了CloudOps AWS队列。分析器将其归类为CloudOps Azure问题，更新了团队字段，并通知请求者改道。
第二，对于一项非工作时间远程访问配置请求，分析器结合客户环境数据和一篇相关Confluence文章，将操作步骤作为内部评论发布。工程师第二天早上在不到 30 分钟内完成了任务，没有额外研究。
第三，对于一项需要PowerShell脚本和服务验证的部署请求，分析器提供了命令、预期输出、故障排除指导和相关参考资料。工程师当天解决了该请求，没有升级给高级工程师。
分析器还会检测运行相同软件版本的客户之间的重复问题模式。当达到配置阈值时，工作流会记录该模式，更新专门的Confluence跟踪页面，监控已解决工单以确认修复，并将未来匹配的工单链接到已记录的解决方案。
在分析器之前，不熟悉的工单类型通常需要人工搜索Confluence或向高级工程师求助。现在自动化工作流会在工程师开始工作前，把客户环境上下文、匹配的知识文章和建议步骤直接放进工单。发布内容明确说明，这不能替代工程判断，而是给新工程师一个更强的起点，帮助他们更早在入职过程中处理不熟悉的场景，让有经验的工程师把更多时间花在复杂工作上。
- 案例 1：Azure DevOps 404错误工单被识别为CloudOps Azure问题并重新路由。
- 案例 2：非工作时间远程访问配置请求附带Confluence操作步骤，工程师次日 30 分钟内完成。
- 案例 3：需要PowerShell脚本的部署请求附带命令和故障排除指导，当天解决，未升级。
- 知识循环：检测重复模式→记录到Confluence→确认修复→关联未来匹配工单。
从概念到生产用了五周
Aderant没有直接跳到自主行动，而是采用了渐进式验证。最初用Jira自动化规则建立路由概念，但该规则无法纳入AWS上下文、工单历史或模型推理。
随后，已有的Amazon Quick CloudOps Helper代理证明运营数据可以支持有用的路由和解决方案建议。团队用AWS Lambda和Amazon Nova Lite实现工作流，Kiro支持集成脚手架、架构验证和测试生成。
在监控模式下，分析器对真实工单运行了约两周，将其分类与人工决策进行比较，并完善提示词和路由逻辑。该系统于 2026 年 6 月 30 日正式上线，距离最初概念五周。
后续计划
Aderant列出的后续方向包括：更深入的客户历史分析，连接随时间变化的相关工单，以提供客户正在进行工作的更广泛视图；改进知识匹配，评估Amazon Bedrock Knowledge Bases以在工单和文档术语不一致时进行语义匹配；分层AI支持，继续用分析器做定时分诊，同时保留CloudOps Helper机器人用于更深入的按需调查和后续问题。