Orca Security 使用 Amazon Bedrock 进行自然语言安全查询 | Amazon Web Services
在 Orca Security 使用 Amazon Bedrock 实现自然语言安全查询
安全分析师需要快速获取有关其云基础设施的答案，而无需深入了解特定领域的查询语言。Orca Security 的工具覆盖了 900 多个云模型（Sonar 跟踪的资源类型，例如 Amazon Elastic Compute Cloud（Amazon EC2）实例或 Amazon Simple Storage Service（Amazon S3）存储桶）。查询这些数据需要精确的模型名称、嵌套关系导航，以及从 18 个运算符（用于筛选结果的比较函数，如 equals 或 contains）中进行选择。
为解决这一问题，Orca Security 与 AWS 合作构建了 Discovery AI，这是一个基于 Amazon Bedrock 的自然语言查询智能体。Orca 为云、代码和 AI 提供上下文感知安全，而 Sonar 是其领域特定的查询系统，用户可以在其中搜索、筛选和探索整个数据图谱。
在本文中，我们分享 Discovery AI 的架构和成果，该系统可将自然语言问题转换为 Sonar 查询。因此，与初始基线相比，Orca 将查询成本降低了 90%，输入 token 减少了 93%，延迟降低了 75%。
连接自然语言与结构化查询
Orca Security 的 Sonar 查询系统支持 900 多个云基础设施和应用模型，且模型之间存在复杂关系。要查询这些数据，用户需要构建 JSON 对象，指定精确的模型名称，从 18 个运算符中进行选择，并跨云提供商导航父子层级结构。要做好这一点，需要深入了解 Sonar schema。
为构建这一能力，Orca 团队着手构建一个自然语言接口，能够从纯文本生成有效的 Sonar 查询。
他们最初的概念验证将完整的 Sonar schema 加载到最大可用模型的单个提示中。这包括 900 多个模型定义、每种关系类型，以及大量示例查询。输出质量很强（设计合作伙伴和内部用户反馈积极），但在生产规模下出现了三个显著缺点。
Token 消耗效率低下，每个工作负载大约需要 200 万输入 token，这推高了成本。延迟很高，每个工作负载的端到端响应时间约为 60 秒。复杂多模型查询的准确性有限，因为嵌套关系和多条件查询通常需要额外优化。
Orca 团队验证了该概念可行。下一个挑战是使其足够具有成本效益、快速且准确，以满足生产要求。为解决这一问题，Orca 团队设计并部署了一个解决方案，使用 Amazon Bedrock 每天处理数千次查询，响应时间为 15 秒。
解决方案概述
Orca 将 Discovery AI 设计为 Amazon Bedrock 上的混合解决方案，结合了检索增强生成（RAG（检索增强生成））与模式感知的查询构建。该系统通过多阶段流水线将自然语言问题转换为有效的 Discovery 过滤器，每个阶段都匹配最合适的 Amazon Bedrock 模型。
Orca 选择 Amazon Bedrock 是因为它通过单一 API（应用程序编程接口） 提供多模型访问，让团队能够为每个流水线阶段分配不同的基础模型，而无需管理单独的集成。Amazon Bedrock 还通过 AWS Identity and Access Management (IAM)、虚拟私有云 (VPC) 终端节点和 AWS CloudTrail 继承 AWS 治理控制，满足 Orca 的安全要求。模型无关的架构意味着团队可以在新模型版本可用时直接替换，而无需重新架构流水线。
下图展示了九阶段流水线架构。
图 1：多阶段 Discovery AI 流水线架构，展示了从自然语言输入到使用 Amazon Bedrock 上的基础模型生成经过验证的 Discovery 过滤器查询的流程
Discovery AI 流水线通过九个步骤将自然语言请求转换为经过验证的 Discovery 过滤器。
请求入口与上下文设置：流水线首先将用户的自然语言请求与相关上下文结合，包括用户所在组织、已连接的云提供商以及请求元数据。这些上下文有助于流水线准确解释请求，并生成与客户环境匹配的 Discovery 过滤器。
快速确定性匹配器：快速匹配器识别结构化输入，例如 IP 地址、通用漏洞与暴露 (CVE)、ARN、文件哈希、Amazon Machine Image ID、Oracle Cloud Identifier、EC2 ID、URL 和告警 ID。它使用正则表达式和基于规则的匹配来检测高置信度模式。当找到匹配项时，流水线可以通过快速路径返回预定义的 Discovery 过滤器，而无需使用大语言模型 (LLM（大语言模型）) 推理。当未找到匹配项时，请求继续进入下一步。
LLM 护栏筛查：护栏组件检查请求是否安全、相关、技术性且受支持。它会在请求到达流水线其余部分之前阻止提示注入尝试、偏离主题的请求和不支持的输入。未通过护栏检查的请求会被拒绝并返回相应的错误。已批准的请求继续进入示例检索。
基于嵌入的语义候选召回：流水线使用 Amazon Titan Text Embeddings 搜索相关的、先前已验证的查询示例。它根据语义相似度从向量存储中检索最近的 20 个示例。这些候选示例为流水线提供了类似自然语言请求先前如何被转换为 Discovery 过滤器的示例。
神经相关性重排序：检索到的候选示例使用 Amazon Bedrock 上的 Cohere Rerank 3.5 进行重排序。它识别与当前请求最相关的示例，并选择五个最高信号示例。当找到精确或高置信度匹配时，流水线可以直接复用已知良好的过滤器。否则，重排序后的示例会被传递到生成阶段。
LLM 驱动的相关模型选择：模型选择将 900 多个 Sonar 模型缩小到与请求相关的一小部分。它在选择合适模型时会考虑用户请求、已连接的提供商以及检索到的示例。所选模型以适当的模式级别提供给生成器，范围从紧凑的微模式到更详细的迷你模式。这减少了不必要的上下文，使生成更加高效。
工具增强的智能体过滤器生成：生成器使用工具增强的智能体来构建最终的 Discovery 过滤器。它基于所选模型模式、检索到的示例、用户上下文和可用工具进行推理。智能体可以在朝着用户请求的有效表示推进的过程中迭代优化过滤器。
静态和 API 支持的验证：生成的过滤器会检查语法和语义正确性。流水线首先应用静态验证，然后根据 Orca 的 Sonar API 验证过滤器。当验证失败时，验证错误会返回给生成器，以便智能体可以修正过滤器并重试。如果在达到最大重试次数后仍未生成有效过滤器，流水线会返回无效过滤器响应。生成器被约束在重排序后的示例和所选模式范围内。静态验证会将每个模型、字段和操作符解析回这些模式定义。每个验证错误都会连同有问题的元素一起返回给智能体，因此重试是重新定位而非重新猜测。
后处理与响应：在生成有效过滤器后，无论是通过快速匹配器、复用已知良好示例还是智能体生成，流水线都会准备最终响应。团队根据每个阶段的需求，在 Amazon Bedrock 上为各组件分配了不同的基础模型。Anthropic Claude Haiku 4.5 为模型选择器和生成器提供支持。这些组件需要强大的推理能力来准确构建查询。Amazon Nova 2 Lite 处理护栏和验证器，这些场景优先考虑以更低成本实现快速推理。Amazon Titan 为示例检索组件中的语义搜索提供嵌入。Cohere Rerank 3.5 对检索到的候选示例进行重排序，以最大化相关性。有关按 AWS 区域划分的模型可用性，请参阅按模型划分的区域可用性。
在示例检索中最大化相关性和多样性
示例检索成为流水线中最大的单一准确性杠杆。强示例比仅靠模式更能有效地教会生成器如何将问题转换为 Sonar 查询，因此 Orca 团队在 Amazon Bedrock 上对多种检索策略进行了基准测试。每种策略在相关性、多样性或速度方面以不同方式进行权衡，直接比较它们可以显示哪种组合效果最佳。
在 Amazon Titan 嵌入上进行纯 top-K 语义搜索执行速度快，但往往会返回近乎重复的示例，使生成器缺乏多样性。最大边际相关性 (MMR) 提高了多样性，但当最佳候选实际上是正确答案时，它会牺牲相关性。检索更大的候选集然后重排序可以引入更广泛的候选池，并使用重排序器选择最相关的子集，这指向了获胜的方法。
获胜方法是使用 Amazon Titan 嵌入进行 top-20 最近邻检索。Orca 随后使用 Cohere Rerank 3.5 将这些结果重排序至前五名。这种方法为生成器提供了一组小型、多样且高度相关的示例，而不会在检索时迫使覆盖率和精确率之间进行权衡。
将 900 多个模型加载到上下文中
一个核心约束塑造了该架构。将 900 多个 Sonar 模型模式包含到每个提示中是不可行的。即使使用长上下文模型，这样做也会降低成本和准确性。
Model Selector 解决了这个问题。它运行在 Anthropic Claude Haiku 4.5 上，针对每个模型的紧凑、语义丰富的表示（名称、用途、关键字段和关键关系）进行工作。根据用户的问题，它只返回 Generator 实际需要的模型。然后，Generator 仅接收这些选定模型的完整 schema 详细信息以及连接它们的关系。
## 评估方法
为了自信地迭代，Orca 团队在项目早期就构建了一个持续评估工具链。该工具链结合了精选数据集、自动化评分层和基于切片的测量方法，使团队能够在每次变更发布前对其充满信心。这些要素共同将评估转变为常规步骤，而非事后考虑。
精选的评估数据集涵盖了生产环境中出现的各种问题类型、模型家族和复杂度层级，因此能够反映真实使用情况。LLM-as-judge 评分层根据正确性、完整性和与参考查询的语义等价性对生成的查询进行评分，为团队提供一致的质量信号。测量方法随后按切片分解差异，使团队能够精确定位回归发生的位置以及需要纠正的内容。
对提示词、模型、检索参数或示例的每一次变更，在发布到生产环境之前都会经过该工具链。
## 领域专家在环标注系统，实现持续改进
随着客户环境不断演变和新问题模式的出现，要保持准确性，仅靠强大的初始部署是不够的。Orca 团队为产品经理、支持工程师和安全研究人员构建了一个内部标注工具。借助该工具，他们可以标记查询、纠正输出，并通过一次操作将纠正结果推送到示例库中。此外，系统会自动收集低置信度匹配示例的生产查询，并将其路由给相应的领域专家进行每日标注。下一次流水线运行会通过 Cohere Rerank 3.5 检索新示例，该类问题的准确性在同一时刻得到提升，无需部署。
> “标注 UI 是我们为长期质量所做的最重要投资。它将 Discovery AI 从静态部署转变为活的系统，我们的领域专家在日常工作流程中持续改进它。” — Or Gabay，Orca Security AI 总监
结合端到端流水线可观测性和跨产品、工程及面向客户团队的共享仪表板，这一反馈循环正是 Discovery AI 在初始发布后持续改进的关键。
## 结果
在将 Discovery AI 部署到生产环境后，新解决方案在成本、延迟和准确性方面均优于初始基线。输入 token 使用量下降了 93%，在可比工作负载下从约 200 万 token 降至 140,000。总体成本下降了 90%，这得益于更低的 token 消耗以及通过 Amazon Bedrock 进行的逐阶段模型分配。
延迟也有所改善，端到端响应时间下降了 75%，从约 60 秒降至 15 秒。复杂多模型查询的准确性也有所提升，通过团队的评估工具链持续测量。
自 2026 年 3 月起，Discovery AI 目前在生产环境中每天处理数千次查询，内部主题专家和客户反馈验证了其质量。
结论
在这篇文章中，我们分享了 Orca Security 如何在 Amazon Bedrock 上构建 Discovery AI。与初始基线相比，该解决方案将查询成本降低了 90%，输入 token 使用量减少了 93%，延迟降低了 75%。该解决方案结合了多项关键技术，包括基于 RAG 的示例检索与 Cohere Rerank 3.5、跨 Anthropic Claude Haiku 4.5 和 Amazon Nova 2 Lite 的分阶段模型分配，以及由 Amazon Titan 提供支持的语义搜索。此外，持续的人工在环标注系统提供了持续改进。这种组合使 Orca 能够将可用的原型转变为生产级解决方案，既运行成本更低，又更加准确。
要开始构建类似的解决方案，请探索 Amazon Bedrock 以获取基础模型（FM）访问、Amazon Bedrock 上的 Cohere Rerank 以进行检索优化，以及 Amazon Titan 用于嵌入。要了解有关 Orca Security 云安全工具的更多信息，请访问 orca.security。
要了解有关 Orca Security 如何在其框架中应用 AI 的更多信息，请参阅 Orca 如何利用 AI 推动安全成果，以及 Orca 如何保障 AI 采用（包括 Amazon Bedrock）。
有关本文所用技术的更多信息，请阅读 AWS Machine Learning Blog 上的相关文章。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文作者：Deniz Yilmaz；如有侵权，请联系管理员删除。
