AWS发布Bedrock Knowledge Bases理赔问答方案：用AgenticRetrieveStream查保险理赔并附带引用
AWS机器学习博客给出了一套用Amazon Bedrock Knowledge Bases构建理赔助手的技术步骤：把S3中的理赔文档和元数据索引进知识库，用AgenticRetrieveStream API做自然语言查询、多轮追问和元数据过滤，并加防护栏确保答案有据可查。该方案使用合成理赔数据，AWS明确表示不描述任何生产客户部署。
AI解读：这条新闻不是新产品发布，而是一份AWS官方技术教程，讲的是怎么把散落在理赔员报告、维修估价单、警方记录、付款台账和扫描附件里的理赔信息，变成一个能用大白话提问、还能给出出处的对话助手。技术底座是Amazon Bedrock Knowledge Bases。
真正解决问题的是检索环节。理赔问题有两类：保户想知道“CLM-100482的估价批没批、支票什么时候寄”，理赔员想找出“上个月所有金额超过 1 万美元的未结案车险理赔还剩什么活”。前者靠单条记录，后者要跨多条记录做组合筛选，这正是元数据过滤和AgenticRetrieveStream的用武之地。
对保险公司的客服和理赔团队来说，可用性取决于两点：答案必须能追溯到原始文档，因为理赔受监管；多轮追问要接得上，比如问完状态再问“负责这个案子的理赔员是谁”。AWS的方案把这两件事分别交给引用渲染和对话历史实现。
别把它当成经过验证的生产系统。AWS自己说明，文中使用的是合成理赔记录，不描述任何生产客户部署。给出的评测数据——40 个问题全部作答、90.5% 检索召回、81.2% 引用召回——是在 30 份合成文档上用Retrieve和RetrieveAndGenerate测的，不是AgenticRetrieveStream的基准，只能当作该语料和元数据结构的基线参考。
还有两个实际限制值得注意：元数据边车文件上限 10KB，日期要存成YYYYMMDD整数才能做范围比较，金额字段只能放一个可比值；startsWith过滤符只支持Amazon OpenSearch Serverless向量存储。想照做的团队需要先确认所在区域支持所选基础模型和Knowledge Bases。
AWS机器学习博客发布了一份技术教程，说明如何用Amazon Bedrock Knowledge Bases构建一个能回答自然语言理赔问题、并附带引用的对话助手。文章作者为Shreya Pawaskar。
文章描述的痛点很具体：理赔答案分散在理赔员日记、维修估价单、警方报告、付款台账和扫描附件中，而不是一个可搜索的字段。保户可能问某笔理赔是否批准，理赔员则可能要找出上个月所有金额超过 1 万美元的未结案车险理赔。
方案使用RAG（检索增强生成），由Amazon Bedrock负责解析、分块、生成嵌入和向量存储。文章给出的步骤包括：从Amazon S3摄取理赔文档和元数据；用AgenticRetrieveStream API以自然语言查询；进行多轮追问；用claim_id、claim_type等属性做元数据过滤限定检索范围；加入上下文接地防护栏，让答案绑定在记录上。
AWS明确说明，这份技术教程使用合成理赔记录，不描述任何生产客户部署。
文章还区分了三类提问者：保户要的是大白话状态更新，比如“CLM-100482的估价是否已批准，支票何时签发”；客服坐席需要在客户等待期间快速给出准确答案，不用转接电话；理赔员则要跨理赔做多部分提问，比如上个月哪些金额超过 1 万美元的未结案车险理赔、每笔还剩什么工作。
答案原本存放在PDF理赔报告、Word函件和文本笔记中，而非统一的数据库字段。记录之间可能冲突或覆盖早前版本——修订后的估价可能取代早先的估价，临时付款之后可能被冲回，助手必须判断哪份估价、付款或状态是最终有效的。由于理赔受监管，每个答案都必须有源文档支撑并附带引用，客服坐席可在复述前核对来源，主管可审计助手是如何得出结论的。
AgenticRetrieveStream如何规划和拆分多部分问题
检索路径由AgenticRetrieveStream承担：它先规划答案、把多部分问题拆成子查询，再执行一次或多次检索，在生成回答前检查证据是否充分。该API以流式返回trace事件、答案文本和引用。trace事件暴露检索计划，每条引用把答案的一部分映射到源理赔文档。
调用时请求分三部分：messages是对话轮次，每条消息带user或assistant角色和content.text；retrievers最多可指定五个知识库，每个可设元数据过滤器和maxNumberOfResults（1 到 100）；agenticRetrieveConfiguration设置规划模型和迭代上限，foundationModelType用MANAGED表示由服务托管模型，用CUSTOM加模型ARN指定具体模型，maxAgentIteration限制规划和检索轮数。
流中的事件分三类：traceEvent报告规划、检索、全文扩展、防护栏动作、状态和生成的子查询；responseEvent提供可逐步推送给用户的增量答案文本；result包含去重后的检索结果，以及generateResponse为True时的完整生成答案和引用。
引用渲染时，每条引用标出答案中的一个字符区间，并引用result事件results数组中的支撑条目，应用据此把显示文本关联到源文档，例如打印引用片段及其对应的x-amz-bedrock-kb-source-uri值。
- 请求中的retrievers最多五个知识库，每个可设maxNumberOfResults 1到 100
- maxAgentIteration限制规划加检索的轮数
- traceEvent可显示计划、子查询、全文获取和防护栏动作
元数据过滤：日期存整数、金额只留一个可比字段
过滤依赖与每份文档同名的 .metadata.json边车文件，例如CLM-100482.pdf对应CLM-100482.pdf.metadata.json。边车只含标量字符串、数字和布尔值，值类型决定可用过滤器。
文章以一笔车险理赔为例给出元数据示例：claim_id为CLM-100482，claim_type为auto，status为open，date_filed为 20260709，amount为 14250，region为us-west，adjuster为Martha Rivera，policyholder为Mary Major，policy_number为POL-AUTO-78432，customer_id为CUST-MM-1042，household_id为HHD-MM-1042，document_type为adjuster_report，carrier为Example Insurance，has_subrogation为true，has_litigation为false，complexity_tier为high。
文章给出两条存储规则：日期以YYYYMMDD整数存放，因为元数据过滤器比较的是数字而非日期字符串，这种格式支持“上个月提交”这类范围查询；amount只放一个可比较的货币值。储备金是为预估理赔成本预留的钱，暂扣是临时扣住，储备金、付款和暂扣应留在文档正文中，以保持标签清晰。边车文件上限为 10KB。
文章提醒，本文使用合成数据，不要在未配备必要控制和审批的情况下把真实的个人身份信息或受保护健康信息放入这些资源。
- claim_id字符串，用于单笔理赔查询的equals匹配
- claim_type字符串，按业务线做equals或in过滤
- status字符串，用in过滤活跃工作队列
- amount数字，做数值范围比较
- date_filed数字，以YYYYMMDD整数做日期范围
- region字符串，用于从会话做租户范围限定
- customer_id字符串，用于从会话做客户范围限定
- has_subrogation布尔值，用于追偿工作筛选
多轮追问与过滤运算符的边界
多轮追问依赖对话历史。回答状态后，保户可能追问“负责这个案子的理赔员是谁”，其中“它”的指代由传入messages的对话历史解析。应用侧保存对话，每轮后把用户问题和助手答案追加进去，下次调用时发送完整列表，服务据此把“它”解析为理赔CLM-100482并检索该理赔的理赔员。
元数据过滤器在语义检索之前限定文档范围，加在检索器的retrievalOverrides下。按claim_id直接查找用equals；查“2026 年 7 月提交的、金额超过 1 万美元的未结案车险理赔”则用andAll组合claim_type、status、amount和日期条件，由于可能命中多笔理赔，maxNumberOfResults设为 50，较小的上限可能让匹配的理赔被排除在摘要之外。
文章提醒，授权类过滤器应由服务端从已认证会话中推导，查询类过滤器用于相关性。支持的运算符包括equals、notEquals、数值比较、in、notIn、stringContains、listContains，以及逻辑andAll/orAll；startsWith仅限Amazon OpenSearch Serverless向量存储，使用前应确认运算符支持情况。如果过滤器返回空结果，应检测到并返回“没有理赔符合这些条件”之类的明确提示，而不是生成答案。
- 多轮对话历史由应用保存，每次调用发送完整messages列表
- 按claim_id查找用equals过滤器
- 多条件查询用andAll组合claim_type、status、amount、date_filed
- startsWith仅支持Amazon OpenSearch Serverless向量存储
前提条件与评测数据
开始前需要：具有Amazon Bedrock和Amazon S3 IAM权限的AWS账户；通过Amazon Bedrock模型访问开通的基础模型；支持所选基础模型和Knowledge Bases的AWS区域，文中示例使用美国西部（俄勒冈）us-west-2，部署前应查看Amazon Bedrock中按区域列出的支持模型；配置好凭证且版本支持所用API的Python Boto3；一个用于存放合成理赔文档和元数据的S3桶；以及Python和基本RAG概念的了解。
创建知识库时，knowledgeBaseConfiguration.type和embeddingModelType均设为MANAGED，由Amazon Bedrock选择和运行嵌入模型，无需配置向量存储。roleArn服务角色授予知识库读取S3桶和使用托管嵌入模型的权限；若要用客户管理的AWS KMS密钥加密托管向量存储，可在serverSideEncryptionConfiguration中传入其ARN。连接S3数据源时用inclusionPrefixes把摄取限制在claims/前缀。
评测方面，文章测量了一个 30 份文档的合成语料，使用的是Retrieve和RetrieveAndGenerate，而不是AgenticRetrieveStream，因此结果应视为该语料和元数据结构的基线，而非agentic检索的基准。40 道问题的测试集包含直接查找、比较、别名、被取代的记录、被冲回的付款和类似指令的文档文本，自动化基础模型评分使事实层面的结果只具方向性。
文章给出的总体结果：40 道问题全部作答，40 个答案全部带引用，平均每个答案 3.9 条引用，期望来源检索召回率 90.5%，期望来源引用召回率 81.2%，与所请求过滤器矛盾的文本块为 0。在 20 道对抗性问题上，检索召回率为 96.7%，引用召回率为 90.2%。文章说明，模型把名称相似的公司区分开，把指控保留为指控。
- 示例区域为us-west-2，需确认所选模型和Knowledge Bases的区域支持
- 知识库嵌入模型设为MANAGED，无需向量存储配置
- 评测语料为 30 份合成文档，40 道问题全部作答
- 期望来源检索召回率 90.5%，期望来源引用召回率 81.2%
- 20 道对抗性问题检索召回率 96.7%，引用召回率 90.2%