安全分析师需要快速获得关于其云基础设施的答案，而无需深入熟悉特定领域的查询语言。 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 消耗效率低下，每个工作负载大约消耗 2 百万输入 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 模型缩小到与请求相关的少量模型。在选择合适的模型时，它会考虑用户的请求、已连接的提供商以及检索到的示例。所选模型以适当的架构级别提供给生成器，级别范围从紧凑的微型（micro）架构到更详细的迷你（mini）架构。这减少了不必要的上下文并使生成更高效。
- 工具增强的智能体过滤器生成：生成器使用工具增强的智能体来构建最终的 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 模型架构是不可行的。即使使用长上下文模型，这样做也会同时损害成本和准确性。
模型选择器解决了这个问题。它运行在 Anthropic Claude Haiku 4.5 上，针对每个模型的紧凑且语义丰富的表示（名称、用途、关键字段和关键关系）进行工作。给定用户的问题，它只返回生成器实际需要的模型。随后，生成器只接收这些所选模型的完整架构细节以及连接它们的关系。
评估方法
为了自信地进行迭代，Orca 团队在项目早期构建了一个持续评估框架。该框架结合了精选数据集、自动评分层和基于切片的度量方法，使团队能够在每次更改上线前予以信任。这些要素共同将评估变成例行步骤，而非事后补充。
这套经过策划的评估数据集涵盖了生产环境中出现的问题类型、模型系列和复杂度层级，因此能反映真实使用情况。一个 LLM-as-judge 评分层根据正确性、完整性以及与参考查询的语义等价性对生成的查询进行评分，从而为团队提供一致的质量信号。随后，测量方法会按切片细分差异变化，使团队能够准确识别回归发生在哪里以及需要修正什么。
对提示词、模型、检索参数或示例的每一次更改，在上线到生产环境之前都要经过该测试框架。
用于持续改进的领域专家参与式标注系统
随着客户环境不断演变和新的问题模式不断出现，要保持准确性所需要的远不止一次强大的初始部署。Orca 团队为产品经理、支持工程师和安全研究人员构建了一款内部标注工具。借助该工具，他们可以通过一个操作标记查询、纠正输出并将修正推入示例库。此外，系统会自动收集置信度较低的匹配示例的生产查询，并将其路由给相应的领域专家进行每日标注。下一次流水线运行会通过 Cohere Rerank 3.5 检索到新示例，该类问题的准确性即刻得到提升，无需任何部署。
“标注界面是我们在长期质量方面做出的最重要投资。它让 Discovery AI 从一个静态部署转变为一个活的系统，让我们的领域专家在日常工作中持续改进它。”
— Or Gabay，Orca Security AI总监
结合覆盖产品、工程和面向客户团队的端到端流水线可观测性和共享仪表板，这一反馈循环正是让 Discovery AI 在首次上线后持续改进的关键。
结果
在将 Discovery AI 部署到生产环境后，新解决方案在成本、延迟和准确性方面均超越了初始基线。输入 token 用量下降了 93%，从每个可比工作负载约 2 百万 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 机器学习博客.