AWS 发布 KnowledgeForge 架构：用大模型从 ITSM 工单挖掘知识库

AWS 在官方机器学习博客上发布了一篇架构方案文章，介绍名为「KnowledgeForge」的解决方案：利用 Amazon Bedrock 中的大语言模型（Anthropic Claude Sonnet 4.5），从企业 IT 服务管理（ITSM）系统里堆积的已解决工单中挖掘知识，自动生成并持续维护知识库文章。整套方案同时引入 Amazon S3 Vectors 做向量去重与相似检索，并借助 AWS Step Functions 编排流程，构成一个闭环的知识库生命周期。

解决的两端问题

文章指出，企业支持团队每月处理成千上万张工单，每张工单都包含症状、根因与处置过程，但这些知识往往只停留在工单历史里，下一位遇到相同问题的工程师无法直接检索到。同时，传统的知识库却走向另一个极端——文章越积越多、重复严重、内容过时，质量参差不齐。

KnowledgeForge 被设计成同时处理这两端：

• 生成端：把聚类后的工单转写成新的草稿文章；
• 维护端：对现有文章按类型分类、去重、质量评分、改写弱内容。

最终结果进入 ServiceNow，由知识经理人工审批后再上线，保证「人」仍然掌握最终发布权。

核心 AWS 组件

文章列出了 KnowledgeForge 依赖的关键 AWS 服务，并解释了选型理由：

• Amazon Bedrock：承担内容生成与改写，使用 Claude Sonnet 4.5，并通过响应流式（response streaming）让容器在 token 到达时即开始组装文档，避免等待完整响应。
• Amazon S3 Vectors：用于工单和文章的向量存储与相似检索，支撑去重检测和生成阶段的 RAG 上下文。
• AWS Step Functions：编排分类、去重、评分、改写四个步骤的工作流，运行在 Lambda 上。
• Amazon ECS on AWS Fargate：承载工单聚类生成任务，因为单次生成需要较长的运行时间，不适合函数计算。
• Amazon SQS、DynamoDB、KMS、Cloud Development Kit（CDK）：分别负责事件触发、审批回写、加密与基础设施即代码部署。

闭环工作流

KnowledgeForge 被描述为一个由两个子系统相互喂数据的闭环：

• 生成（Generation）：上游流程按主题对已解决工单聚类，结果以 JSON 写入 S3。S3 事件触发 SQS 队列，Fargate 容器拉取任务，对每个主题检索客户向量索引中最相似的五篇已有文章作为参考上下文（典型的 Retrieval Augmented Generation，即 RAG 模式），再调用 Claude Sonnet 4.5 生成两类结构化文档——知识库文章（含标题、症状、根因、解决步骤、预防措施等）和根因分析文档（含执行摘要、5 Why 分析、纠正预防措施、时间线等）。
• 策展（Curation）：对每篇文章依次执行分类、去重、质量评分、改写四步，最终把富化后的文章送往 ServiceNow 供知识经理审批，并把审批结果写回 DynamoDB。

闭环的关键在于：策展阶段为每篇文章生成向量写入 S3 Vectors，下一轮生成时再读取这些向量作为 RAG 的参考，既减少重复，也保证新文章的术语与既有库一致。

生成阶段选用容器而非函数

文章专门用一节解释为什么把生成任务放在 ECS Fargate 容器上而非 Lambda：工单聚类生成一次通常会持续较长时间，且需要为同一客户的多个主题并发处理，容器模型在执行时间和并发控制上更适合这种负载形态。Lambda 则保留给策展阶段短小、可独立调度的步骤。

部署前提

文章在 Prerequisites 章节给出可复现该方案的最低要求：

• 启用 Amazon Bedrock，并开通 Claude Sonnet 4.5 与 Amazon Titan Text Embeddings V2；
• 具备创建 S3 桶与 S3 Vectors 索引、Step Functions 状态机、Lambda 函数、ECS Fargate 服务、DynamoDB 表、SQS 队列、Bedrock Guardrails 与 KMS 密钥的权限；
• 本地安装 AWS CDK，并对 Bedrock、Step Functions、ECS、向量嵌入有一定熟悉度；
• 拉取 aws-samples/sample-knowledgeforge 仓库代码。

对于正在搭建大规模生成式 AI 文档处理流水线的团队，文章表示可以直接复用这套模式：S3 作为数据汇入点，向量索引提供去重与上下文，Step Functions 串联治理步骤，并在关键审批节点保留人工介入。