亚马逊AWS官方博客
航班变更信息智能识别解决方案
摘要:本文详细介绍了如何基于Nova模型和Strands Agents开源框架,构建一套高效、精准且易于扩展的智能航班变更信息识别系统。通过将复杂的航班变更邮件解析为结构化的JSON数据,解决了传统人工处理成本高、规则引擎维护难、传统机器学习泛化能力弱等痛点。在部署和运维方面,充分利用了Bedrock AgentCore提供的无服务器托管能力、全链路的可观测性以及无监督的结果评估,形成持续迭代闭环。
一、前言
随着全球航空业的飞速发展,如何高效处理航班变更信息已成为旅行服务提供商日常运营中的关键环节。航空公司每日通过邮件、短信、接口等多种渠道,向旅行服务提供商推送大量关于航班延误、取消、时刻调整等变更通知。这类信息往往具有以下特点:
- 多种语言表达:涉及英语、中文、德语等多国语言,覆盖不同地区的航空公司
- 格式复杂多变:邮件模板、HTML结构乃至时间格式均缺乏统一标准,差异化明显
- 信息高度聚合:单封邮件可能同时包含多段航班信息,如往返行程或中转联程
[图1] |
面对如此复杂的业务场景,传统处理方式逐渐暴露出诸多痛点问题:
- 人工处理:不仅成本高昂、效率受限,更难以保证准确性与稳定性
- 规则引擎:依赖大量正则表达式和定制规则,难以灵活应对格式变化与拓展需求
- 传统机器学习:常需针对不同航司训练专属模型,维护成本高,泛化能力不足
随着生成式AI技术的兴起,也为航班变更信息识别提供了全新的解决思路。本文将介绍如何基于Nova模型,结合开源的Strands Agents框架与Bedrock AgentCore等相关服务,构建一套高效、精准且易于维护的智能航班变更信息识别系统。
二、解决方案概述
本文以亚马逊云科技的US-EAST-1区域为例进行部署,核心服务是采用Bedrock提供的Nova模型和Strands Agents框架,实现对航空公司发送的航班变更信息进行智能解析。进一步的,采用Bedrock AgentCore的观测能力,对执行过程进行全程跟踪,并实时监控关键指标;同时,利用其评估能力,对模型推理结果进行量化评估。以此持续推动在处理大规模航班变更信息时,实现长期稳定的推理效果和成本优化。
[图2] |
如架构图所示的核心服务及功能亮点如下:
- Amazon Nova Pro模型:作为方案的推理引擎,提供多语言理解、复杂HTML内容解析及结构化JSON输出能力,并通过Temperature、Top P等参数调优,实现稳定可控的推理效果。
- Strands Agents开源框架:通过Agent实现模型、工具与提示词的统一编排,简化智能体构建流程;通过装饰器将时间格式转换等复杂逻辑封装为工具函数,由模型自主决策调用时机,有效降低提示词复杂度并减少Token消耗。
- Bedrock AgentCore:提供无服务器的运行时托管能力,支持测试端点与生产端点的流量隔离;基于CloudWatch实现全链路可观测性,涵盖调用次数、延迟、Token消耗、资源用量等关键指标的实时监控;并提供无监督的结果评估能力,形成”解析、评估、优化”的持续迭代闭环。
开发/测试环境
(1)流量采样与脱敏:从生产环境的业务服务中,将航班变更信息相关的部分流量进行脱敏处理,并安全转发至测试环境,确保数据隐私的同时保留真实业务特征。
(2)数据清洗与归一化:在测试环境中,对接收到的航班变更信息执行清洗、格式归一化,并将处理后的标准化数据存储至S3存储桶,构建样本数据集。
(3)智能体开发与优化:基于S3中的样本数据,持续进行智能体的开发和提示词调优,提升信息提取的准确性与泛化能力。
(4)测试运行时调用:调用AgentCore运行时代理的测试端点,对解析服务全流程进行端到端验证,通过CloudWatch评估智能体的运行成本。
生产环境
(5)全量数据接入:将航班变更信息相关的流量,全部转发到生产环境的解析服务,实现规模化处理。
(6)生产运行时调用:调用AgentCore运行时代理的生产端点,对实际业务流量进行智能解析,通过CloudWatch监控智能体的性能指标,确保系统稳定运行。
三、核心技术实现
3.1 提示词设计
提示词作为大模型在推理时的行为规范和处理逻辑,决定了模型如何理解输入并生成预期输出。一份完整的提示词通常包括四个核心组成部分:角色定义、输入定义、解析规则定义和输出定义四部分。
本文以某航空公司的多种邮件类型作为测试样本,采用HTML格式的邮件内容作为输入,输出为JSON格式的变更后的航班信息数组。解析要点包括:
- 多航班信息识别:精准识别HTML中所有航班信息,包括原始航班、变更航班、往返航班、中转/联程航班等,确保信息不遗漏、不混淆。
- 航班号处理:提取HTML中展示的航班号,支持完整格式(如“E61234”)与部分信息(如仅数字“1234”),并依据规则补全为标准化格式。
- 机场代码识别:优先提取IATA三字母机场代码;若仅有机场名称,则依据上下文或内置映射关系推断对应的主要机场代码。
- 时间格式处理:将所有时间统一转换为“YYYY-MM-DD HH:mm:ss”格式。当邮件中时间信息不完整时(如缺少年份或时区),依据上下文或业务规则进行合理推断,确保时间字段的完整性与一致性。
3.1.1 特殊航司处理规则
在通用解析规则的基础上,针对不同航空航司的特有内容格式,可定义专门的处理规则。本文在对某航空公司的特殊处理规则中,增加了用于多种地区的时间格式识别和处理。
3.2 智能体实现
本文使用Strands Agents开源框架来构建智能体应用,该框架以轻量级和专注的智能体开发体验为核心理念,简化了基于大语言模型的应用构建流程。具体实现步骤如下:
- 模型初始化:根据业务需求配置Bedrock模型(如Nova Pro 1.0)及相关参数(如温度、Top P等),确保模型推理行为符合预期。
- 创建智能体:创建Agent实例,将初始化好的模型注入,同时配置系统提示词以及用到的工具(如日期处理函数)。提示词定义了智能体的角色与解析规则,工具则扩展了模型的能力边界。
- 调用智能体:调用Agent实例的推理方法,传入待解析的航班变更邮件内容(HTML格式)。智能体将依据提示词和工具,自动完成信息抽取与逻辑推理。
- 结果后处理:由于模型输出可能包含解释性文本,使用正则表达式从响应中精准提取JSON格式的航班信息数组,确保数据结构的完整性与可用性。
3.2.1 实现时间格式转换工具
在实现航班变更信息解析时,时间格式处理是一个重要规则。由于其时间表达方式多样,这就需要在提示词中为每种格式编写详细规则,既增加Token消耗,又难以覆盖所有变体。
通过Strands Agents的 @tool 装饰器,可以轻松定义工具函数,将时间格式转换逻辑从提示词中剥离,交由代码集中处理。其优势在于:
- 降低提示词复杂度:无需在提示词中穷举所有时间格式变体,只需告知模型“当遇到时间信息时,调用时间转换工具”,从而显著减少Token消耗,将更多容量留给其他规则。
- 利用代码处理格式多样性:使用代码函数判断多种时间格式,无需依赖大模型进行格式分类与转换,避免模型幻觉或格式误判。
- 模型自主决策调用时机:大模型会根据HTML内容中的上下文,自主判断是否需要调用时间工具,以及何时调用。
3.3 模型效果对比
为评估不同模型在航班变更信息解析任务中的表现,在使用本文提供的相同的样本数据集、提示词和技术框架下,对Nova系列的三款模型进行了对比测试。重点考察准确率、推理速度以及典型输出质量,结果如下:
| 模型 | 准确率 | 推理速度 | 典型用例 |
| Nova Premier 1.0 | 最高 | 20 ~ 30s | 能够精准解析多段联程航班、复杂嵌套表格,对模糊时间信息推断合理,但响应延迟较高。 |
| Nova Pro 1.0 | 优秀 | 6 ~ 7s | 对常见格式(如单程、往返)解析稳定,能正确提取航班号、机场代码和时间,输出JSON结构完整。 |
| Nova 2 Lite 1.0 | 较差 | 2 ~ 3s | 速度快但易出错,如未移除航班号中间的空格,无法根据名称推理机场代码,特定格式月/日识别错误等 |
综合考虑准确率与响应速度,Nova Pro 1.0模型在实时处理场景中表现最为均衡,因此被选为生产环境模型。为进一步提升输出的稳定性和一致性,将模型推理参数Temperature设置为0.2,在保证一定灵活性的同时,大幅降低随机性输出风险。
3.4 解析结果看板
为提升智能体开发和提示词优化的效率,本文还通过Kiro构建了航班变更信息解析结果看板,旨在帮助工程师更直观的对比原始邮件内容与模型解析输出的JSON结构,快速定位解析偏差并验证优化效果。主要功能包括:
- 基于React框架,实现解析结果列表的展示,并集成分页、排序及列显示控制功能。
- 详细内容查看面板,并支持分割条拖拽动态调整左右面板宽度,以适应不同分辨率需要。
- 增强用户交互,引入键盘导航,通过方向键控制记录切换和翻页,提升操作便捷性。
- 允许重新解析历史记录,并优化调用方式为查询参数,利用返回结果局部更新避免全量刷新。
- 支持多航班信息展示,增加展开/收起功能、航班数量标识,子行缩进。
[图3] |
3.5 模型成本评估
基于某航空公司约一周的邮件样本数据(包含单程、往返、多航段等多种场景),根据CloudWatch Model Invocations获取模型调用数据显示,对Nova Pro 1.0模型累计调用4007次,累计消耗输入Token 90.5M,输出Token 516.3K。据此计算,平均每次调用消耗输入Token约22.6K,输出Token约129。
[图4] |
根据Nova Pro 1.0模型在US-EAST-1区域的定价:
- 输入Token:$0.0008每1000 Tokens
- 输出Token:$0.0032每1000 Tokens
基于上述数据计算,单次调用的平均成本为:
( 22582 / 1000 × $0.0008 ) + ( 129 / 1000 × $0.0032 ) = $0.01848
结合生产环境流量推算日均调用量约920.5次,则每日模型调用成本为:
$0.01848 * 920.5 = $17.01每天
3.6 模型服务配额
模型的服务配额决定了系统的处理能力与扩展上限,Bedrock通过TPM(Tokens Per Minute,每分钟处理Token数)和RPM(Requests Per Minute,每分钟请求数)两个指标对模型调用进行限流,其具体大小因推理方式而异。
本文以Nova Pro 1.0模型的跨区域推理方式为例,其默认服务配额TPM为2M,RPM为500。根据单次调用所需的Token计算,每分钟可调用次数为:2000000 / ( 22582 + 129 ) = 88.06次。随着业务规模扩大,需要更高的并发处理能力时,可在Bedrock控制台的Quotas中进行增加。
[图5] |
四、服务部署和运维
完成智能体开发后,如何将智能体部署到生产环境并进行全生命周期管理,成为保障业务稳定运行的关键。Bedrock AgentCore提供了一系列无服务器的智能体托管服务,支持与主流模型及智能体框架无缝集成,覆盖从开发、构建、部署到运维的完整流程。本文中使用的能力包括:
- 运行时调用:通过AgentCore提供的测试端点与生产端点,对接开发环境和生产环境的解析服务,实现流量的安全隔离。
- 可观测性:利用AgentCore的观测能力,对每次智能体调用进行全程跟踪,记录模型输入/输出、工具调用链、异常信息等,并通过CloudWatch监控关键指标,确保系统健康运行。
- 结果评估:借助AgentCore的评估能力,对解析结果进行量化打分,形成“解析-评估-优化”的闭环,持续提升模型推理效果。
4.1 运行时代理
根据项目开发的不同阶段,Bedrock AgentCore运行时提供了多种灵活的接入方式,以满足从快速原型到深度定制化生产部署的不同需求。
- 使用agentcore-starter-toolkit:通过CLI工具实现项目创建、开发、调试和部署的全生命周期管理。适用于从头开始,快速开发、测试、构建和部署智能体项目,获得开箱即用的一站式体验。
- 自定义集成(无侵入式):在现有项目(如FastAPI应用)中,仅需实现/invocations和/ping两个HTTP端点,即可被Bedrock AgentCore托管。适用于已有代码或框架,希望最小改动的方式。
- 自定义集成(基于SDK,本文方案):在现有项目内引入Bedrock AgentCore SDK,并显式定义BedrockAgentCoreApp入口。适用于已有CI/CD流程,并希望充分利用AgentCore的核心能力。
运行时代理入口定义
Dockerfile镜像文件
4.2 可观测性
AgentCore将运行时代理采集到的度量、链路追踪和日志等数据统一存储于CloudWatch中,并通过专属仪表盘提供直观的可视化界面,实时查看智能体在不同时间、不同版本下的关键指标。包括不限于:
- 会话/调用:记录智能体被调用的次数
- 延迟时间:记录调用的响应时间
- Token消耗:记录输入/输出Token用量
- 资源消耗:记录vCPU/内存用量
[图6] |
[图7] |
通过启用运行时代理的Tracing选项,能够全面追踪每一次智能体调用的完整交互流程,并以可视化方式呈现请求详情。从而帮助快速识别性能瓶颈、精准定位错误根源,并为持续优化提供数据支撑,确保智能体在生产环境中稳定、高效运行。
[图8] |
4.3 结果评估
传统评估方式往往需要繁杂的数据整理、主观判断和持续的人力投入,且每次智能体更新或模型变更都会显著增加评估难度。AgentCore的评估功能提供了一种无监督的评估方法,无需预先设定标准答案或人工标注,即可对运行结果进行量化打分,更能形成解析、评估、优化的闭环,以持续推动解析效果的提升。
评估分数以CloudWatch指标形式发布,包括展示整体评估配置得分及相关类别分布。
[图9] |
在Trace视图中,还可以查看具体运行信息的评估器详细解释。
[图10] |
五、总结
本文详细介绍了如何基于Nova模型和Strands Agents开源框架,构建一套高效、精准且易于扩展的智能航班变更信息识别系统。通过将复杂的航班变更邮件(以HTML格式为主)解析为结构化的JSON数据,解决了传统人工处理成本高、规则引擎维护难、传统机器学习泛化能力弱等痛点。在部署和运维方面,充分利用了Bedrock AgentCore提供的无服务器托管能力、全链路的可观测性(CloudWatch)以及无监督的结果评估,形成持续迭代闭环。
同时,本方案的技术架构具备良好的通用性和扩展能力,不仅适用于航班变更信息识别,还可推广至更多业务场景。例如:酒店预订变更通知的智能解析、签证审批结果的自动提取、客服工单的自动分类等。随着多模态大模型的发展,还可进一步丰富对PDF、图片、语音等更多内容形态的解析,持续拓展方案的覆盖范围和业务价值。
综上所述,基于亚马逊云科技的生成式AI能力,为航班变更信息处理提供了一个高效、可扩展的技术范式。相信随着大模型技术的不断演进,此类方案将在旅行服务生态中发挥越来越大的价值。
➡️ 下一步行动:
相关产品:
- Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
- Amazon Nova — 提供前沿智能和最高性价比的基础模型
- Amazon Bedrock AgentCore — 加快代理投入生产的速度
- Amazon CloudWatch — 可观测性工具
- Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储
相关文章:
- 快时尚电商行业智能体设计思路与应用实践(六)借助 Amazon Bedrock AgentCore MCP Server,Amazon Bedrock,Strands Agents,Kiro 实现智能体极速研发
- 基于Strands Agents SDK和Amazon Bedrock AgentCore构建商品详情图广告词审查Agent
- 基于Strands框架和Bedrock AgentCore的SAP智能采购助手方案
- 快时尚电商行业智能体设计思路与应用实践(八)基于 WebSocket 的语音系统:Nova 2 Sonic, AgentCore, Strands Agents 企业级架构实践
- AI Agent 的迁移与现代化 — 使用 Amazon Bedrock AgentCore 将 OpenClaw 从单机改造为多租户 Serverless 架构 第二篇
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。
本篇作者
AWS 架构师中心:云端创新的引领者探索 AWS 架构师中心,获取经实战验证的最佳实践与架构指南,助您高效构建安全、可靠的云上应用 |
![]() |











