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）与 schema 感知的查询构建相结合。该系统通过多阶段流水线将自然语言问题转换为有效的 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 标识符、EC2 ID、URL 和告警 ID。它使用正则表达式和基于规则的匹配来检测高置信度模式。当找到匹配项时，流水线可以通过快速路径返回预定义的 Discovery 过滤器，而无需使用大语言模型 (LLM) 推理。当未找到匹配项时，请求继续进入下一步。
LLM 护栏筛查：护栏组件检查请求是否安全、相关、技术性且受支持。它会在请求到达流水线其余部分之前阻止提示注入尝试、偏离主题的请求以及不受支持的输入。未通过护栏检查的请求会被拒绝并返回相应的错误。通过检查的请求继续进入示例检索。
基于嵌入的语义候选召回：流水线使用 Amazon Titan Text Embeddings 搜索相关的、先前已验证的查询示例。它根据语义相似度从向量存储中检索最接近的 20 个示例。这些候选示例为流水线提供了类似自然语言请求先前如何被转换为 Discovery 过滤器的示例。
神经相关性重排序：检索到的候选示例使用 Amazon Bedrock 上的 Cohere Rerank 3.5 进行重排序。它识别出与当前请求最相关的示例，并选出五个信号最强的示例。当找到精确或高置信度匹配时，流水线可以直接复用已知良好的过滤器。否则，重排序后的示例会被传递到生成阶段。
LLM 驱动的相关模型选择：模型选择将 900 多个 Sonar 模型缩小到与请求相关的一小部分。它在选择合适模型时会考虑用户的请求、已连接的提供商以及检索到的示例。所选模型会使用适当的模式级别提供给生成器，范围从紧凑的微模式到更详细的迷你模式。这减少了不必要的上下文，并使生成更加高效。
工具增强的智能体过滤器生成：生成器使用工具增强的智能体来构建最终的 Discovery 过滤器。它基于所选模型 schema、检索到的示例、用户上下文和可用工具进行推理。智能体可以在朝着用户请求的有效表示推进的过程中迭代优化过滤器。
静态与 API 支持的验证：对生成的过滤器进行语法和语义正确性检查。流水线首先应用静态验证，然后针对 Orca 的 Sonar API 验证过滤器。当验证失败时，验证错误会返回给生成器，以便智能体修正过滤器并重试。如果达到最大重试次数仍未生成有效过滤器，流水线将返回无效过滤器响应。生成器被约束在重排序后的示例和选定的 schema 范围内。静态验证会将每个模型、字段和运算符都解析回这些 schema 定义。每个验证错误都会连同出错的元素一起返回给智能体，因此重试是重新定位而非重新猜测。
后处理与响应：在生成有效过滤器后，无论是通过快速匹配器、复用已知良好的示例，还是通过智能体生成，流水线都会准备最终响应。团队根据各阶段的需求，在 Amazon Bedrock 上为不同组件分配了不同的基础模型。Anthropic Claude Haiku 4.5 为模型选择器和生成器提供支持。这些组件需要强大的推理能力来准确构建查询。Amazon Nova 2 Lite 负责护栏和验证器，这里优先考虑以更低成本实现快速推理。Amazon Titan 为示例检索组件中的语义搜索提供嵌入。Cohere Rerank 3.5 对检索到的候选进行重排序，以最大化相关性。有关各 AWS 区域的模型可用性，请参阅按模型划分的区域可用性。

最大化示例检索中的相关性和多样性

示例检索成为流水线中最大的单一准确性杠杆。强示例比仅靠 schema 更能教会生成器如何高效地将问题转化为 Sonar 查询，因此 Orca 团队在 Amazon Bedrock 上对多种检索策略进行了基准测试。每种策略在相关性、多样性或速度上以不同方式做出权衡，直接比较它们揭示了哪种组合效果最佳。

基于 Amazon Titan 嵌入的纯 top-K 语义搜索执行速度快，但往往会返回近乎重复的示例，使生成器缺乏多样性。最大边际相关性（MMR）提高了多样性，但当排名最高的候选实际上是正确答案时，它会牺牲相关性。检索更大的候选集然后重排序，可以拉入更广泛的候选池，并使用重排序器选择最相关的子集，这指向了最终胜出的方法。

胜出方案是使用 Amazon Titan 嵌入进行 top-20 最近邻检索。然后 Orca 使用 Cohere Rerank 3.5 将这些结果重排序至前五名。这种方法为生成器提供了一组小而多样、高度相关的示例，而无需在检索时在覆盖率和精确率之间做出权衡。

将 900 多个模型加载到上下文中

一个核心约束塑造了架构。将 900 多个 Sonar 模型 schema 包含在每个提示中是不可行的。即使使用长上下文模型，这样做也会降低成本和准确性。

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 降至 14 万。整体成本下降了 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 机器学习博客上的相关文章。

关于作者

Deniz Yilmaz

Deniz 是 AWS 生成式 AI 创新中心的机器学习工程师。她与 EMEA 地区的企业客户合作，设计并部署生产级生成式 AI 解决方案，从概念验证到规模化部署。她的工作重点是智能体架构、检索增强生成以及用于在生产环境中构建可靠 AI 系统的评估方法。

Natalie Tarasova

Natalie 是 AWS 自定义模型优化团队的机器学习工程师。她专注于 LLM 微调、持续预训练和训练后优化。她是 SWE-InfraBench 的作者，这是一个针对基础设施即代码的 LLM 基准测试。

Julia Wagner

Julia 是 AWS 生成式 AI 创新中心的高级 AI 策略师。她与多个行业垂直领域的大型企业和创新初创公司合作，定义并实施生成式和智能体 AI 战略与产品。凭借十多年的产品和技术领导经验，她帮助组织自动化复杂工作流程、加速研发，并构建规模化 AI 采用所需的组织能力。

Barak Tarab

Barak 是 Orca Security 的 AI 团队负责人，推动先进人工智能能力的开发。他的专业重点集中在构建可扩展的 AI 解决方案和稳健的基础设施。

Saurav Hiremath

Saurav，Orca Security 的软件工程师。在 Orca 领导并构建了 API 安全套件，现在转向为企业客户构建智能体 AI 系统。偶尔参与 OSS 贡献（此前为 Facebook 的 Jest、React Hermes）