AWS Machine Learning Blog

Natural language security queries at Orca Security using Amazon Bedrock

6.9内容质量
Natural language security queries at Orca Security using Amazon Bedrock

TL;DR · AI 摘要

Natural language security queries at Orca Security using Amazon Bedrock Artificial Intelligence Natural language securit...

核心要点

  • 主题聚焦:Natural language security queries at Orca Securi
  • 来源:AWS Machine Learning Blog,建议结合原文判断细节。
  • AI 分析暂不可用,本条为保底评分与摘要。
#AI#编程#后端#云计算#安全
打开原文

Orca Security 使用 Amazon Bedrock 实现自然语言安全查询 | 人工智能

Orca Security 使用 Amazon Bedrock 实现自然语言安全查询

安全分析师需要快速了解其云基础设施的情况,而无需深入了解特定领域的查询语言。Orca Security 的工具可覆盖 900 多种云模型(Sonar 跟踪的资源类型,例如 Amazon 弹性计算云(Amazon EC2)实例或 Amazon 简单存储服务(Amazon S3)存储桶)。查询这些数据需要精确的模型名称、嵌套关系导航,并从 18 个操作符(如等于或包含等用于过滤结果的比较函数)中进行选择。

为了解决这一问题,Orca Security 与 AWS 合作开发了 Discovery AI,这是一个基于 Amazon Bedrock 的自然语言查询代理。Orca 提供面向云、代码和 AI 的上下文感知安全防护,而 Sonar 是其领域专用的查询系统,用户可通过该系统在完整数据图中进行搜索、过滤和探索。

在本文中,我们将分享 Discovery AI 的架构和成果,该系统可将自然语言问题转换为 Sonar 查询。作为结果,与初始基准相比,Orca 将查询成本降低了 90%,输入令牌数减少了 93%,延迟降低了 75%。

连接自然语言与结构化查询

Orca Security 的 Sonar 查询系统支持 900 多种云基础设施和应用模型,它们之间存在复杂的关联。要查询这些数据,用户需要构建 JSON 对象,指定精确的模型名称,从 18 个操作符中选择,并跨云提供商导航父子层级结构。要做好这一点,需要深入了解 Sonar 架构。

为了构建这一功能,Orca 团队致力于开发一个自然语言接口,能够从纯文本生成有效的 Sonar 查询。

他们最初的可行性验证将完整的 Sonar 架构加载到最大可用模型的单个提示中。这包括 900 多个模型定义、每种关系类型以及大量示例查询。输出质量较高(设计合作伙伴和内部用户反馈积极),但在生产规模下出现了三个显著缺陷。

令牌消耗效率低下,每个工作负载约消耗 200 万个输入令牌,导致成本上升。延迟较高,每个工作负载的端到端响应时间约为 60 秒。在处理复杂多模型查询时准确性有限,因为嵌套关系和多条件查询通常需要额外优化。

Orca 团队验证了该概念的可行性。下一个挑战是使其在生产环境中足够经济高效、快速且准确。为了解决这个问题,Orca 团队设计并部署了基于 Amazon Bedrock 的解决方案,该方案每天可处理数千个查询,响应时间仅需 15 秒。

解决方案概述

Orca 将 Discovery AI 设计为基于 Amazon Bedrock 的混合解决方案,结合了检索增强生成(RAG)与架构感知查询构建。该系统通过多阶段流水线将自然语言问题转换为有效的 Discovery 过滤器,每个阶段都匹配最合适的 Amazon Bedrock 模型。

Orca 选择 Amazon Bedrock 是因为它通过单一 API 提供了多模型访问能力,使团队能够为每个流水线阶段分配不同的基础模型,而无需管理单独的集成。Amazon Bedrock 还通过 AWS 身份和访问管理 (IAM)、虚拟私有云 (VPC) 端点和 AWS CloudTrail 继承 AWS 治理控制,满足 Orca 的安全需求。与模型无关的架构使团队能够在新模型版本发布时直接替换,而无需重新设计流水线。

以下图表展示了九阶段流水线架构。

图 1:多阶段 Discovery AI 流水线架构,显示了从自然语言输入到通过 Amazon Bedrock 上的基础模型生成验证后的 Discovery 过滤查询的流程

Discovery AI 流水线通过九个步骤将自然语言请求转换为验证后的 Discovery 过滤器。

  • 请求入口和上下文设置:流水线首先将用户的自然语言请求与相关上下文(包括用户组织、连接的云提供商和请求元数据)进行组合。这些上下文帮助流水线准确解释请求并生成符合客户环境的 Discovery 过滤器。
  • 快速确定性匹配器:快速匹配器识别 IP 地址、通用漏洞和暴露 (CVE)、ARN、文件哈希、Amazon 机器镜像 ID、Oracle 云标识符、EC2 ID、URL 和警报 ID 等结构化输入。它使用正则表达式和基于规则的匹配来检测高置信度模式。当找到匹配项时,流水线可以通过快速路径直接返回预定义的 Discovery 过滤器,而无需使用大语言模型 (LLM) 推理。当未找到匹配项时,请求将继续进入下一步。
  • LLM 安全防护筛选:防护组件检查请求是否安全、相关、技术性强且受支持。它在请求到达流水线其余部分之前阻止提示注入尝试、离题请求和不受支持的输入。未通过防护检查的请求将被拒绝并返回适当的错误信息。通过审核的请求将继续进入示例检索阶段。
  • 基于嵌入的语义候选召回:流水线使用 Amazon Titan 文本嵌入在向量存储中搜索相关且已验证的查询示例。它根据语义相似性从向量存储中检索最接近的 20 个示例。这些候选示例为流水线提供了类似自然语言请求之前如何转换为 Discovery 过滤器的示例。
  • 神经相关性重排序:使用 Amazon Bedrock 上的 Cohere Rerank 3.5 对检索到的候选示例进行重排序。它识别与当前请求最相关的示例,并选择信号最强的五个示例。当找到精确匹配或高置信度匹配时,流水线可以直接复用已知有效的过滤器。否则,重排序后的示例将传递到生成阶段。
  • 基于 LLM 的相关模型选择:模型选择器将 900 多个 Sonar 模型缩小到与请求相关的较小集合。它在选择适当模型时考虑用户的请求、连接的提供商和检索到的示例。所选模型通过适当的模式级别(从紧凑的微型模式到更详细的迷你模式)提供给生成器。这减少了不必要的上下文并提高了生成效率。
  • 工具增强型代理过滤器生成:生成器使用工具增强的代理来构建最终的发现过滤器。它会基于所选模型架构、检索到的示例、用户上下文和可用工具进行推理。代理可以随着向用户请求的有效表示推进,逐步优化过滤器。
  • 静态验证与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模型架构包含在每个提示中并不可行。即使使用长上下文模型,这样做也会降低成本和准确性。

结论

在本文中,我们分享了Orca Security如何基于Amazon Bedrock构建Discovery AI解决方案。与初始基准相比,该方案将查询成本降低了90%,输入令牌使用量减少了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机器学习博客的相关文章。

作者简介

'\"