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 模式有深入的了解。

为了构建这一能力，Orca 团队着手构建一个自然语言接口，可以从纯文本生成有效的 Sonar 查询。

他们最初的概念验证是将完整的 Sonar 模式加载到一个提示词中，使用当时可用的最大模型。其中包括 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 过滤器。
快速确定性匹配器：快速匹配器（Quick Matcher）识别结构化输入，例如 IP 地址、常见漏洞与暴露（CVE）、ARN、文件哈希、Amazon Machine Image ID、Oracle Cloud Identifier、EC2 ID、URL 和告警 ID。它使用正则表达式和基于规则的匹配来检测高置信度模式。当找到匹配时，流水线可以通过快速路径返回预定义的 Discovery 过滤器，而无需使用大语言模型（LLM）推理。当未找到匹配时，请求将继续进入下一步。
LLM 护栏筛查：护栏（Guardrail）组件检查请求是否安全、相关、具有技术性且受支持。它会在提示注入尝试、离题请求和不受支持的输入进入流水线其余部分之前将其拦截。未通过护栏检查的请求会被拒绝并返回相应的错误。通过检查的请求将继续进行示例检索。
基于嵌入的语义候选召回：流水线使用 Amazon Titan Text Embeddings 搜索相关的、先前已验证的查询示例。它基于语义相似度从向量存储中检索出 20 个最近的示例。这些候选示例为流水线提供了类似的自然语言请求先前如何被转换为 Discovery 过滤器的参考。
神经相关性重排序：检索到的候选示例使用 Amazon Bedrock 上的 Cohere Rerank 3.5 进行重排序。它识别出与当前请求最相关的示例，并选出信号最强的五个示例。当找到精确或高置信度匹配时，流水线可以直接复用已知良好的过滤器。否则，重排序后的示例将被传递给生成阶段。
LLM 驱动的相关模型选择：模型选择环节将 900 多个 Sonar 模型缩减为与请求相关的一小部分。它在选择合适的模型时会考虑用户的请求、已连接的提供商以及检索到的示例。所选模型会以适当的 schema 级别提供给生成器，从紧凑的 micro schema 到更详细的 mini schema 不等。这减少了不必要的上下文，使生成过程更高效。
工具增强的智能体过滤器生成：生成器使用工具增强的智能体来构建最终的 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）真正需要的模型。然后，生成器只接收这些被选中模型的完整 schema 详情，以及连接它们的关系。

评估方法

为了充满信心地进行迭代，Orca 团队在项目早期就构建了一个持续评估工具。该工具结合了精选数据集、自动评分层和基于切片（slice）的度量方法，使团队在每次变更上线前都能信任它。这些要素共同将评估变成了常规步骤，而非事后补救。

精选的评估数据集涵盖了生产环境中出现的各类问题类型、模型家族和复杂度层级，因此能反映真实使用情况。LLM 作为评判者的评分层对生成的查询在正确性、完整性和与参考查询的语义等价性方面进行打分，为团队提供一致的质量信号。度量方法随后按切片分解差异，使团队能够准确识别回归发生在哪里以及需要修正什么。

对提示词、模型、检索参数或示例的每一次更改，都会在上线到生产环境之前经过该评估工具的处理。

领域专家参与式标注系统，实现持续改进

随着客户环境不断演进、新的问题模式不断涌现，要保持准确性，仅靠一次成功的初始部署是不够的。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 能够将一个可运行的原型转化为既运行成本更低又更加准确的生产级解决方案。

要开始构建类似的解决方案，请探索用于基础模型（FM）访问的 Amazon Bedrock、用于检索优化的 Amazon Bedrock 上的 Cohere Rerank，以及用于嵌入的 Amazon Titan。要了解有关 Orca Security 云安全工具的更多信息，请访问 orca.security。

要了解有关 Orca Security 如何在其框架中应用 AI 的更多信息，请参阅 Orca 如何通过 AI 推动安全成果以及 Orca 如何保护 AI 采用（包括 Amazon Bedrock）。

要了解更多本文所使用的技术，请阅读 AWS 机器学习博客上的相关文章。