自然语言安全查询如何降低成本与延迟

安全分析师需要快速获得有关云基础设施的答案，而不必深入掌握领域专用查询语言。Orca Security 的工具覆盖了 900 多种云模型（即 Sonar 跟踪的资源类型，例如 Amazon Elastic Compute Cloud（Amazon EC2）实例或 Amazon Simple Storage Service（Amazon S3）bucket）。查询这些数据时，用户必须准确指定模型名称、逐层处理嵌套关系，并从 18 种运算符中选择合适的运算符（例如 equals 或 contains 这类用于过滤结果的比较函数）。

为解决这个问题，Orca Security 与 AWS 合作，在 Amazon Bedrock 上构建了自然语言查询 Agent——Discovery AI。Orca 为云、代码和 AI 提供能够感知上下文的安全能力，而 Sonar 是其领域专用查询系统，用户可以通过它在整个数据图中搜索、过滤和探索。

本文将介绍 Discovery AI 的架构与实际效果。它能将自然语言问题转换为 Sonar 查询。与最初的基线方案相比，Orca 将查询成本降低了 90%，输入 token 减少了 93%，延迟降低了 75%。

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

Orca Security 的 Sonar 查询系统支持 900 多种云基础设施和应用模型，这些模型之间存在复杂的关系。要查询这些数据，用户需要构造 JSON 对象，指定准确的模型名称，从 18 种运算符中进行选择，并处理跨云服务商的父子层级关系。要熟练完成这些操作，用户必须深入了解 Sonar schema。

为实现这项能力，Orca 团队着手构建一个自然语言接口，让用户只需输入普通文本，就能生成有效的 Sonar 查询。

最初的概念验证方案，将完整的 Sonar schema 加载到当时可用的最大模型的单个 prompt 中。其中包含 900 多个模型定义、所有关系类型，以及大量查询示例。输出质量很好，参与设计的合作伙伴和内部用户都给出了积极反馈，但在生产规模下，三个明显的问题逐渐浮现。

token 消耗效率不高，每个工作负载大约需要 200 万输入 token，推高了成本。延迟也较高，每个工作负载的端到端响应时间约为 60 秒。对于涉及多个模型的复杂查询，准确率仍然有限，因为嵌套关系和多条件查询往往需要进一步修正。

Orca 团队验证了这个思路确实可行。接下来的挑战，是让它在成本、速度和准确率上都达到生产要求。为此，Orca 团队基于 Amazon Bedrock 设计并部署了一套解决方案，每天处理数千次查询，响应时间为 15 秒。

Orca 将 Discovery AI 设计为 Amazon Bedrock 上的一套混合方案，把 Retrieval Augmented Generation（RAG）与能够理解 schema 的查询构建结合起来。系统通过多阶段流水线，将自然语言问题转换为有效的 Discovery 过滤条件，并为每个阶段匹配最合适的 Amazon Bedrock 模型。

Orca 选择 Amazon Bedrock，是因为它能通过单一 API 访问多个模型，让团队可以为流水线的不同阶段分配不同的 foundation model，而不必维护各自独立的集成。Amazon Bedrock 还通过 AWS Identity and Access Management（IAM）、virtual private cloud（VPC）端点和 AWS CloudTrail，继承了 AWS 的治理控制能力，满足 Orca 的安全要求。架构不依赖特定模型，这也意味着新模型版本推出后，团队可以直接替换，而无需重新设计流水线。

下图展示了这套九阶段流水线的架构。

图 1：Discovery AI 多阶段流水线架构，展示了如何利用 Amazon Bedrock 上的 foundation model，将自然语言输入转换为经过验证的 Discovery 过滤查询。

Discovery AI 流水线通过以下九个步骤，将自然语言请求转换为经过验证的 Discovery 过滤条件。

1. 请求接入与上下文准备： 流水线首先将用户的自然语言请求与相关上下文结合，包括用户所属组织、已连接的云服务商，以及请求元数据。这些上下文有助于流水线准确理解请求，并生成符合客户环境的 Discovery 过滤条件。

2. 快速确定性匹配： Quick Matcher 识别结构化输入，例如 IP 地址、Common Vulnerabilities and Exposures（CVEs）、ARNs、文件哈希、Amazon Machine Image IDs、Oracle Cloud Identifiers、EC2 IDs、URLs 和告警 IDs。它通过正则表达式和规则匹配，识别高置信度模式。如果找到匹配项，流水线就能走快速路径，返回预定义的 Discovery 过滤条件，无需进行 large language model（LLM）推理。如果没有找到匹配项，请求则进入下一步。

3. LLM Guardrail 筛查： Guardrail 组件检查请求是否安全、相关、属于技术范畴，并且在支持范围内。它会在请求进入流水线后续阶段之前，拦截 prompt injection 尝试、偏离主题的请求和不支持的输入。未通过 Guardrail 检查的请求会被拒绝，并返回相应错误。通过检查的请求进入示例检索阶段。

4. 基于 embedding 的语义候选召回： 流水线使用 Amazon Titan Text Embeddings，搜索之前已验证且与当前请求相关的查询示例。它根据语义相似度，从向量存储中检索最接近的 20 个示例。这些候选示例让流水线能够参考：类似的自然语言请求，过去是如何转换为 Discovery 过滤条件的。

5. 神经网络相关性重排序： 使用 Amazon Bedrock 上的 Cohere Rerank 3.5，对召回的候选示例重新排序。它识别与当前请求最相关的示例，并选出参考价值最高的 5 个。如果找到完全匹配或高置信度匹配，流水线就能直接复用已验证可用的过滤条件。否则，重排序后的示例会传递给生成阶段。

6. 由 LLM 驱动的相关模型选择： Model Selection 将 900 多种 Sonar 模型缩小到与当前请求相关的一小组模型。选择时，它会综合考虑用户请求、已连接的云服务商和检索到的示例。选中的模型会以适当的 schema 详细程度提供给 Generator，从精简的 micro schema 到更详细的 mini schema 不等。这减少了无关上下文，让生成过程更高效。

7. 借助工具的 Agent 过滤条件生成： Generator 使用配备工具的 Agent，构造最终的 Discovery 过滤条件。它结合选定模型的 schema、检索到的示例、用户上下文和可用工具进行推理。在逐步形成能够有效表达用户请求的过滤条件时，Agent 可以反复修正结果。

8. 静态验证与 API 验证： 系统检查生成的过滤条件在语法和语义上是否正确。流水线先执行静态验证，再通过 Orca 的 Sonar API 验证过滤条件。如果验证失败，验证错误会返回 Generator，让 Agent 修正过滤条件并再次尝试。如果达到最大重试次数后仍无法生成有效的过滤条件，流水线会返回过滤条件无效的响应。Generator 的生成范围受限于重排序后的示例和选定的 schema。静态验证会将每个模型、字段和运算符逐一对应到这些 schema 定义。每次验证错误都会标明出错的元素并返回 Agent，让重试重新依据明确的 schema 信息，而不是再次猜测。

9. 后处理与响应： 生成有效的过滤条件后，流水线会准备最终响应，无论该过滤条件来自 Quick Matcher、对已验证示例的复用，还是 Agent 生成。

团队根据各阶段的要求，为不同组件分配了 Amazon Bedrock 上的不同 foundation model。Anthropic Claude Haiku 4.5 驱动 Model Selector 和 Generator。这两个组件需要较强的推理能力，才能准确构建查询。Amazon Nova 2 Lite 负责 Guardrail 和 Validator，这些阶段更看重低成本和快速推理。Amazon Titan 为 Example Retrieval 组件中的语义搜索提供 embedding。Cohere Rerank 3.5 对检索到的候选示例进行重排序，尽可能提高相关性。有关各 AWS Region 的模型可用性，请参阅按模型划分的区域可用性说明。

兼顾示例检索的相关性与多样性

示例检索成为流水线中提升准确率最有效的单一手段。相比只提供 schema，优质示例能更高效地教会 Generator 如何将问题转换为 Sonar 查询，因此 Orca 团队在 Amazon Bedrock 上对多种检索策略进行了基准测试。每种策略都以不同方式权衡相关性、多样性和速度，直接比较这些策略后，团队找到了效果最好的组合。

单纯基于 Amazon Titan embedding 的 top-K 语义搜索速度很快，但往往会返回近乎重复的示例，导致 Generator 缺少多样化参考。Maximal Marginal Relevance（MMR）改善了多样性，但当排名第一的候选实际上就是正确答案时，它会牺牲相关性。先检索更大的候选集合，再进行重排序，则能从更广泛的候选池中，利用 reranker 选出最相关的子集。这指明了最终胜出方案的方向。

最终胜出的方案是：使用 Amazon Titan embedding 进行 top-20 最近邻检索，再用 Cohere Rerank 3.5 对结果重排序，保留排名前 5 的示例。这样，Generator 就能获得一小组兼具多样性和高度相关性的示例，无需在检索阶段强行权衡覆盖范围与精确度。

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

一个核心约束决定了架构的设计方向：无法在每个 prompt 中都放入 900 多种 Sonar 模型的 schema。即使使用长上下文模型，这样做也会增加成本、降低准确率。

Model Selector 解决了这个问题。它运行在 Anthropic Claude Haiku 4.5 上，使用每种模型的精简但语义信息丰富的表示，包括名称、用途、关键字段和关键关系。收到用户问题后，它只返回 Generator 真正需要的模型。随后，Generator 只会获得这些选定模型的完整 schema 细节，以及连接这些模型的关系。

评估方法

为有把握地持续迭代，Orca 团队在项目早期就构建了一套持续评估框架。它将精心整理的数据集、自动评分层和按切片衡量的方法结合起来，让团队在每次变更上线之前都能确认其效果。这些要素共同让评估成为日常流程，而不是事后补做的工作。

经过整理的评估数据集覆盖了生产环境中出现的问题类型、模型类别和复杂度层级，因此能够反映真实使用情况。LLM-as-judge 评分层会根据正确性、完整性，以及与参考查询的语义等价性，对生成的查询评分，为团队提供一致的质量信号。随后，衡量方法会按不同切片拆解指标变化，让团队能够准确找出退化发生在哪里，以及需要修正什么。

任何针对 prompt、模型、检索参数或示例的变更，都必须先经过这套评估框架，才能发布到生产环境。

让领域专家参与标注，实现持续改进

随着客户环境不断变化、新的问题模式不断出现，要持续保持准确率，仅靠一次出色的初始部署还不够。Orca 团队为产品经理、支持工程师和安全研究人员构建了一款内部标注工具。通过这款工具，他们只需一次操作，就能标记查询、修正输出，并将修正结果加入示例库。此外，系统还会自动收集匹配示例置信度较低的生产查询，每天将它们交给合适的领域专家进行标注。流水线下一次运行时，就能通过 Cohere Rerank 3.5 检索到新示例，让这一类问题的准确率立即得到改善，无需部署。

“标注 UI 是我们为长期质量所做的最重要的一项投入。它让 Discovery AI 从一次静态部署变成一个不断演进的系统，我们的领域专家可以在日常工作流程中持续改进它。”

——Or Gabay，Orca Security AI 总监

再结合流水线的端到端可观测性，以及覆盖产品、工程和面向客户团队的共享仪表板，这套反馈闭环让 Discovery AI 在首次上线后仍能持续改进。

Discovery AI 部署到生产环境后，新方案在成本、延迟和准确率方面都超过了最初的基线方案。对于可比的工作负载，输入 token 用量从约 200 万降至 14 万，减少了 93%。token 消耗的减少，加上在 Amazon Bedrock 上按阶段分配模型，使总体成本降低了 90%。

延迟也得到改善，端到端响应时间从约 60 秒缩短至 15 秒，降低了 75%。涉及多个模型的复杂查询，其准确率也有所提升，团队通过评估框架持续衡量这一指标。

自 2026 年 3 月起，Discovery AI 已在生产环境中每天处理数千次查询，内部领域专家和客户反馈共同验证了其质量。

本文介绍了 Orca Security 如何在 Amazon Bedrock 上构建 Discovery AI。与最初的基线方案相比，这套方案将查询成本降低了 90%，输入 token 用量减少了 93%，延迟降低了 75%。方案结合了几项关键技术，包括使用 Cohere Rerank 3.5 的 RAG 示例检索、在 Anthropic Claude Haiku 4.5 和 Amazon Nova 2 Lite 之间按阶段分配模型，以及由 Amazon Titan 驱动的语义搜索。此外，持续运行的 human-in-the-loop 标注系统提供了不断改进的能力。这些能力结合起来，让 Orca 将一个可用的原型转变为生产级方案，运行成本更低，准确率也更高。

如果你想开始构建类似方案，可以了解 Amazon Bedrock 提供的 foundation model（FM）访问能力、Amazon Bedrock 上用于优化检索的 Cohere Rerank，以及 Amazon Titan 的 embedding 能力。如需进一步了解 Orca Security 的云安全工具，可以访问 orca.security。

如需了解 Orca Security 如何在其整个框架中应用 AI，可以阅读有关 Orca 如何借助 AI 改善安全成效，以及如何保障包括 Amazon Bedrock 在内的 AI 应用安全的介绍。

如需进一步了解本文使用的技术，可以阅读 AWS Machine Learning Blog 上的相关文章。