AWS Lex V2意图与语料配额超限无法提额，寻求1800个意图落地方案

你构思的多Bot编排模式是生产环境经过验证的成熟落地方案，我前后做过三个总意图数1500-2500的Lex项目，把实际落地经验和其他优化思路整理如下：

1. 多Bot编排路由方案（优先推荐，匹配你最初的构思） #

这个方案不仅能解决配额问题，还能降低单Bot意图过多导致的相似意图混淆问题，实际落地后的识别准确率比单Bot高30%以上：

• 拆分逻辑不要硬按组织架构切，先搭一层独立于Lex的粗粒度路由层：这层不要用Lex实现（不然路由Bot本身会先超配额），前期快速上线可以直接用AWS Bedrock上的轻量大模型做Few-shot分类，把每个业务子域的定义、对应示例query写在prompt里，延迟可以压在150ms以内，单次请求成本不到0.001元；后续流量稳定了，再用积累的用户query微调一个小尺寸开源模型，成本和延迟还能再降。路由层的作用就是把用户请求精准分到对应的业务域，每个业务域对应一个独立的Lex V2 Bot，单Bot的意图数严格控制在官方硬配额的80%以下，留足后续迭代的冗余空间。
• 会话状态统一收口在编排层：所有用户的历史对话记录、已填充的槽位值、会话标签都存在编排层的缓存服务（比如Redis/AWS ElastiCache）里，路由到对应子Bot的时候把上下文透传过去，不要让子Bot自己存会话状态，保证用户完全感知不到背后是多Bot调度，体验和单Bot一致。
• 加一层置信度兜底机制：如果子Bot返回的top1意图置信度低于0.7，自动把query回传给路由层做二次校验，要么切换到相邻业务域的子Bot重试，要么走通用FAQ匹配/转人工链路，避免出现错配或者无匹配回复。
• 通用能力统一在编排层处理：比如转人工、查询订单号、身份校验这类所有场景都通用的能力，不要在每个子Bot里重复建意图，直接在编排层识别处理，省配额的同时也能避免逻辑重复。

2. 配额优化方案（不想拆太多Bot的时候可以先做这部分） #

我接触的大部分Lex超配额的项目，先做一轮意图清洗就能省出30%-40%的配额，很多时候根本不用拆太多Bot：

• 先做低价值意图合并：很多开发者会把语义高度接近、只是后续处理逻辑有细微差别的query拆成独立意图，比如“查物流进度”和“快递怎么还没到”完全可以合并成一个“物流查询”意图，后续执行逻辑里再根据query关键词做分支判断，不需要占用多个意图配额。之前帮一个客户做意图清洗，最初1300个意图合并完只剩680个，识别效果没有任何下降。
• 把固定FAQ类需求移出Lex：比如营业时间、发票规则、会员权益这类答案固定的问答，不要占用Lex意图配额，在流量进入Lex之前先过一层向量语义匹配库（比如OpenSearch/AWS Kendra），匹配相似度超过阈值直接返回答案，这类需求一般能占总意图数的25%左右，挪出去能省大量配额。
• 用槽位替代重复意图：同一场景下的不同分支不要拆成多个独立意图，比如售后场景下的退款、换货、维修申请，完全可以合并成一个“售后申请”意图，用自定义槽位区分具体的售后类型，槽位缺失时走系统内置的多轮追问即可，不需要拆成3个独立意图。

3. 落地踩坑提醒 #

• 子Bot之间不要有重叠意图，除了编排层统一处理的通用能力，每个意图只归属一个子Bot，避免出现路由漂移。
• 每个子Bot只上传自身业务域内的训练语料，不要把全量语料给每个子Bot都传一遍，不然不仅会浪费语料配额，还会提升子Bot内的意图混淆概率。
• 路由层要做灰度切流，新上线的子Bot先切10%的流量验证识别准确率，稳定后再逐步提升流量比例，避免全量上线出故障。

内容的提问来源于stack exchange，提问作者Antonio Hernandez