Orca Security Discovery AI 降低自然语言安全查询成本

Orca Security Discovery AI 现可将自然语言安全问题转换为 Sonar 查询，同时相比其初始设计减少 93% 的输入 token。Orca 还表示，在 Amazon Bedrock 上重构该系统后，查询成本降低了 90%，延迟缩短了 75%。

这些数据不只是一次常规的模型升级。Orca 用一个九阶段流水线取代了单一庞大提示词，由该流水线决定每项请求应由规则、检索、更小型的模型还是更深入的推理来处理。

这一结果对一种常见的企业 AI 策略提出了挑战：将所有模式、示例和指令放入一个大型上下文窗口。Orca 的经验表明，更多上下文可能会增加成本、削弱相关性，并拖慢应用程序速度。

其替代方案将语言模型视为受控查询编译器中的一个组件。确定性匹配处理明显的输入，检索提供经过验证的示例，验证机制则在返回前检查生成的筛选条件。

这一设计之所以重要，是因为自然语言安全查询所面对的是敏感且高度结构化的信息。当生成的筛选条件指向错误资产、跨越授权边界，或遗漏关键条件时，再流畅的回答也价值有限。

Orca 用生产级流水线取代单一庞大提示词

核心变化在于架构：Orca 不再要求一个模型在每次请求中理解其全部安全模式。

Orca 的 Sonar 查询系统覆盖超过 900 个云基础设施和应用模型。这些模型代表计算实例、存储桶、身份、漏洞等资源，以及它们之间的关联关系。

在 Discovery AI 之前，用户需要构建精确的 JSON 筛选条件。他们还必须了解准确的模型名称、处理嵌套关系，并在 18 种筛选运算符中做出选择。

这一要求为理解安全问题、但不熟悉 Sonar 完整模式的分析师制造了可用性障碍。因此，Orca 构建了一个自然语言界面，将分析师的请求转换为有效筛选条件。

最初的概念验证采用了最直接的生成式 AI 方法。Orca 将超过 900 个模型定义、关系类型和示例查询加载到一个用于大型模型的提示词中。

据该公司介绍，设计合作伙伴和内部用户认可输出质量。但该设计针对可比工作负载大约消耗了 200 万输入 token，耗时约 60 秒。

复杂请求也暴露了准确性限制。涉及多个资源模型、嵌套关系或多项条件的问题，往往需要额外调整。

随后，Orca 与 AWS 开发了生产级九阶段流水线。据报道，自 2026 年 3 月以来，该系统每天已处理数千条查询，响应时间约为 15 秒。

该流水线首先将请求与组织上下文结合。此类上下文可能包括已连接的云服务商、请求元数据，以及解读用户环境所需的详细信息。

接下来，确定性匹配器会查找结构化标识符，包括 IP 地址、CVE 标识符、文件哈希、资源名称、URL 和告警 ID。

匹配到的标识符可直接触发预定义筛选条件，无需进行昂贵的模型调用。这一路径可将可预测的工作排除在概率系统之外。

需要解释的请求会先通过一道护栏。Orca 表示，该阶段会在请求进入查询生成环节前，拦截提示词注入尝试、无关问题和不受支持的输入。

随后，系统会搜索经过验证的示例库。Amazon Titan embeddings 会检索 20 个语义相近的候选项，Cohere Rerank 3.5 再将其缩减为五个。

模型选择器会将 900 多个 Sonar 模型缩小至与当前请求相关的范围。生成器仅接收这一较小模型组及其关系的详细模式。

Anthropic Claude Haiku 4.5 为选择和生成阶段提供支持。对于 Orca 优先考虑更快、更低成本推理的护栏和验证任务，则由 Amazon Nova 2 Lite 处理。

生成的筛选条件仍不会自动成为最终结果。静态检查会根据所选模式解析每个模型、字段和运算符。

Orca 还会通过 Sonar API 检查筛选条件。验证失败时，错误会指出有问题的元素，并将其返回给生成器进行修正。

这一循环将生成转变为受约束的过程。模型可以提出筛选条件，但确定性系统决定该提议是否符合可用模式。

Orca Security Discovery AI 有意缩小上下文

Orca Security Discovery AI 通过选择上下文而非扩展上下文，改善了其报告的成本效益。

最初的原型将 Sonar 的完整模式视为必需上下文。由于模型需要理解数百种资源类型及其关系，这一选择看似合理。

问题在于，大多数问题只涉及其中一小部分模式。每次请求都发送全部定义会增加 token 使用量，却无法让每个定义都发挥作用。

Orca 的模型选择器如今会基于可用模型的紧凑描述运行。每项描述概括模型的名称、用途、重要字段和重要关系。

选择器会识别一个问题需要哪些模型。随后，生成器仅接收这些入选模型的完整模式，以及连接它们所需的关系。

这一变化将可比工作负载的报告输入使用量从约 200 万 token 降至 14 万 token，即其所称的 93% 降幅。

Orca 将 90% 的成本下降归因于更低的 token 量和按阶段分配模型。不同任务不再默认使用可用的最大模型。

据报道，延迟从约 60 秒降至 15 秒，缩短了 75%。更快的路径仍包含多个阶段，这表明阶段数量本身并不决定响应时间。

一次漫长的单次推理可能比数个范围更窄的操作更慢。当系统识别出已知模式时，规则和检索也可绕过生成环节。

这正是报告中性能提升背后的核心机制。Orca 减少了需要深度推理的材料量，再将生成式工作留给请求中尚未解决的部分。

检索设计遵循同一原则。纯粹的 top-K 语义搜索速度很快，但 Orca 发现它经常返回近乎重复的示例。

这些重复项占用了上下文，却没有增加多少覆盖范围。最大边际相关性提高了多样性，但有时会让最相关的示例偏离顶部位置。

Orca 最终采用检索 20 个相近示例、再将其重排序为五个的方案。更大的首轮检索强调召回率，而重排序则让最终上下文聚焦于更强的匹配项。

高置信度匹配可直接复用已验证的筛选条件。否则，这五个示例会向生成器展示经过验证的问题此前是如何被转换的。

这一方法更接近基于案例的推理，而非不受限制的生成。模型基于紧凑的模式，以及从成功历史行为中提取的示例开展工作。

该架构还使模型选择具有可替换性。Amazon Bedrock 通过共享服务层提供多个模型系列，减少了单独的集成工作。

这种灵活性很重要，因为某个阶段最快或最准确的模型可能会变化。据报道，Orca 可在不重新设计整个应用程序的情况下替换某一阶段的模型。

更广泛的经验并非每个系统都需要九个步骤，而是上下文应当凭借价值获得进入生产提示词的资格。

即便模型支持大型上下文窗口，模式、示例和对话历史也会带来成本。无关材料还可能与真正重要的证据相互竞争。

自然语言安全查询仍需要严格边界

对话式界面可减少查询语言的使用阻力，但无法取代授权、验证或安全专业知识。

自然语言安全查询可帮助分析师将调查思路转化为结构化筛选条件。但它们无法保证问题本身已获授权或内容完整。

Orca 的流水线包括请求上下文、护栏筛查、受约束生成和两种形式的验证。这一流程承认，将模型输出视为可执行事实存在风险。

Amazon Bedrock 护栏评估可根据配置的策略检查提示词和响应。可用控制措施包括内容过滤器、禁止主题、敏感信息过滤器和提示词攻击检测。

不过，护栏并不是授权系统。它可以对输入进行分类，但仍可能缺乏做出访问决策所需的用户身份和资源权限信息。

AWS 的安全指南明确区分了两者。其授权控制措施建议在语言模型之外实施数据访问控制，并通过连接的系统传递用户身份。

这一分离对于云安全数据尤为重要。查询可能暴露资产名称、漏洞、账户关系、网络路径或内部配置细节。

拥有广泛后端访问权限的助手可能成为“混淆代理”。这种情况发生在权限较低的用户通过权限较高的中介获得信息时。

安全的架构必须约束哪些数据能够进入模型。它还必须确保最终的 Sonar 查询以适合请求用户的权限运行。

公开的架构说明称，Orca 会将请求与组织和云服务商上下文结合。该文章并未详细说明租户隔离或用户级授权执行方式。

这一遗漏并不能证明存在弱点。它只是意味着，不应将报告的性能结果解读为完整的安全评估。

验证构成了另一项重要边界。Orca 首先检查语法，再通过其 Sonar API 验证生成的筛选条件。

检查失败时，生成器会收到结构化错误。它可以修正特定字段、运算符或关系，而非重新进行一次不受约束的猜测。

这一方法减少了一类幻觉：引用不存在的模式元素。但它并不能证明每个有效查询都准确捕捉了分析师的意图。

筛选条件可以在语法上有效，却在语义上不完整。它可能选择了正确模型，但遗漏例外条件、关系、时间边界或环境条件。

当简短请求隐藏歧义时，这一问题会更加严重。“显示暴露的数据库”可能取决于对暴露、数据库类型、网络可达性和可接受风险的定义。

强大的界面应揭示相关假设，或展示生成的筛选条件供用户审查。AWS 的文章重点关注筛选条件生成与验证，而非完整的审查体验。

因此，安全团队应区分查询有效性与调查正确性。前者可依据模式进行机器验证，而后者往往需要领域判断。

系统的确定性退出路径同样值得关注。复用已验证示例可以降低延迟，但匹配阈值必须避免表面相似的问题共用不适合的过滤器。

Orca 表示，它会将低置信度查询转交给领域专家。这一反馈流程有所帮助，但其效果取决于抽样、审查覆盖范围和纠正质量。

自然语言访问可以让更多人参与安全调查，同时也将责任从查询编写者转向负责实现这些安全机制的平台设计者。

真正的对手是“单模型、单提示词”设计

Orca 最有意义的比较对象并非另一家供应商，而是它所替代的单体式原型。

生成式 AI 产品通常始于一个连接到强大模型的提示词。这种结构很适合验证模型是否理解任务。

但当应用面对真实流量、不断变化的模式、严格的延迟要求以及敏感的组织数据时，这种结构就更难站得住脚。

Orca 的基线原型揭示了这一转变。该原型能够给出令人鼓舞的答案，但每次请求都要传入庞大的模式，且仍难以处理复杂关系。

生产系统将多项职责移出生成器之外。正则表达式识别精确标识符，检索查找示例，重排序减少噪声，验证器则拒绝格式错误的过滤器。

这种分工带来了一个重要转变。增加组件反而降低了总体成本和延迟，因为这些组件避免了不必要的生成式工作。

这条流水线也挑战了以模型为中心的采购思路。仅仅选择最大的模型，并不能单独解决生产环境的问题。

Orca 则根据任务需求分配模型。推理密集型阶段使用 Claude Haiku 4.5，而更狭窄的筛选与验证阶段使用 Nova 2 Lite。

Amazon Titan 为语义搜索创建嵌入向量。Cohere Rerank 3.5 则在生成前对检索到的示例评分。

这种组合带来了运营复杂性。团队必须监控多个模型、检索行为、验证循环和依赖关系，而不只是一次 API 调用。

然而，单次调用的架构只是将复杂性隐藏在大型提示词中。它并未消除模式管理、评估、授权或错误处理。

AWS 此前关于自然语言调查的工作，展示了 Amazon Security Lake 的类似模式。一个智能体将分析师问题转换为 SQL，并支持对安全日志进行后续分析。

Orca 的实现面向其自身的 Sonar 数据图谱和领域专用过滤器。其突出特点是在生成前大幅缩减模式和示例。

这一模式可应用于云安全之外的领域。企业系统通常会暴露数百个对象、字段、关系及允许的操作。

客户支持平台、分析工具、开发者门户和知识系统都面临同样的诱惑：将所有定义放入提示词中。这种方法可能在演示中奏效，却会在生产环境的经济性要求下失效。

替代方案类似于编译器流水线。系统解析请求、识别相关结构、检索先例、生成中间表示，并进行验证。

语言模型处理歧义和转换。确定性组件处理可执行的规则。

这种分布也使故障更容易定位。团队可以判断是检索遗漏了相关示例、选择遗漏了某个模式，还是验证拒绝了某个操作符。

单一提示词往往只会产生价值较低的故障信号：答案只是错误、昂贵、缓慢，或三者兼具。

Orca 表示，其评估框架会衡量与参考查询相比的正确性、完整性和语义等价性。它还会按照问题和模型类别对结果进行切片分析。

这比单一汇总分数更具信息价值。一个系统可能总体表现良好，却在罕见的多云关系或复杂漏洞条件下失败。

这一设计促使其他企业 AI 团队报告系统级结果。单独的模型基准分数无法解释应用延迟、检索质量、验证率或纠正工作量。

数字很亮眼，但准确性证据并不完整

成本和延迟改进数据很具体，但公开的准确性主张缺乏同等程度的测量细节。

AWS 和 Orca 提供了清晰的令牌、成本和响应时间前后对比数据。但它们没有公布评估数据集、样本量、通过率或确切的准确性提升幅度。

文章称，复杂的多模型查询准确性有所改善。它还描述了一个使用 LLM 作为评审者的系统，用于评估正确性、完整性和语义等价性。

LLM 作为评审者，是指使用另一个模型来评估生成结果。它可以支持快速迭代，但其结论取决于评分标准、参考答案和评审模型的可靠性。

Orca 以内部专家和客户反馈补充自动评分。产品经理、支持工程师和安全研究人员可以标记输出，并添加已纠正的示例。

据称，低置信度的生产查询会进入每日标注队列。纠正结果无需进行软件部署，即可供后续检索运行使用。

Orca 的 AI 总监 Or Gabay 将该标注界面称为团队最重要的长期质量投资。这一表述强调的是人工流程，而非又一次模型升级。

作为改进机制，这一流程具有可信度。但对于外部采购方和工程团队而言，它仍留下了几个未解问题。

公开文章并未披露生成过程达到重试上限的频率，也未报告有多少请求走确定性路径或示例复用路径。

它也没有区分中位延迟与尾部延迟。15 秒这一数据可能描述的是典型工作负载，却掩盖了较慢的复杂请求。

“可比工作负载”这一表述还需要更明确的定义。令牌和成本的降低取决于请求组合、所选模型、缓存行为、输出长度和重试次数。

所报告的成本降低也是将生产流水线与 Orca 自身最初的基线进行比较，而非与其他云安全产品或查询生成系统的基准对比。

读者应将这些百分比视为公司自行报告的运营结果。这份由 AWS 共同撰写的案例研究提供了技术细节，但并非独立审计。

2026 年 3 月的生产上线时间以及每日数千次查询，提供了有价值的采用信号。但它们并未揭示独立用户数、接受率、放弃率或分析师节省的时间。

这些指标有助于判断自然语言是否改变了调查行为。较低的推理成本固然重要，但用户价值最终取决于更好、更快的安全决策。

系统的反馈循环也引入了另一项权衡。生产示例可以提升覆盖范围，但若专家未遵循共同政策，纠正结果可能会编码不一致的解释。

不断增长的示例库同样需要治理。团队需要版本管理、质量审查、移除流程，以及防止敏感信息进入被检索示例的保护措施。

AWS 对生成式 AI 应用的指导建议，在数据到达模型前限制被检索的数据。其安全控制措施强调在数据层实施身份传递和访问控制。

这些担忧并未否定 Orca 的成果。它们界定了在另一家组织将该架构视为可复用模板之前所需的证据。

最有力的公开结论虽有限，但仍具价值。Orca 报告称，上下文选择、模型专业化、检索和验证显著改进了其原始设计。

这些证据并不能证明每个模式密集型智能体都能获得普遍性的成本降低。团队必须根据自身工作负载和授权要求衡量这一模式。

Orca 部署 Amazon Bedrock 后值得关注什么

下一项考验是：随着模式、用户行为和模型版本持续变化，Orca 能否保持质量。

第一个信号是公布准确性细节。未来的技术报告应披露数据集规模、查询类别、通过阈值和人工审查一致性。

切片级结果将尤其有价值。多模型关系查询似乎是最困难的类别，也是对 Orca 架构最有力的测试。

更透明的评估将增强这样一种主张：新设计不仅改善了效率，也提升了准确性。不断上升的纠正率或重试率则会削弱这一结论。

第二个信号是持续的生产采用。Orca 表示 Discovery AI 每日处理数千次查询，但更长期的使用模式将显示分析师是否信任该界面。

有用的指标包括重复使用率、被接受的过滤器、人工编辑、节省的时间，以及无需升级处理便能解决的问题占比。这些衡量指标将模型行为与安全运营联系起来。

第三个信号是流水线如何应对变化。Sonar 的模式会演进，客户会提出陌生问题，基础模型也会推出新版本。

Orca 的模型无关设计应当让替换更容易。但每项变更仍需跨检索、生成、验证和授权边界进行回归测试。

因此，持续评估框架与初始架构同样重要。每个提示词、模型、检索设置和示例，都可能在意料之外的切片中改变行为。

该系统还必须在不断变化的威胁行为面前保持实用。分析师可能会将调查映射到云威胁框架，而攻击者则会采用新的路径和资源组合。

静态示例库会在这些条件下逐渐失效。Orca 的专家标注循环旨在让检索库与不断涌现的问题保持一致。

对于工程团队而言，立即可采取的行动是检查大型提示词中有哪些内容从未被大多数请求使用。这些内容或许应置于选择、检索或确定性路由机制之后。

团队还应分离三项测试：查询是否有效、它是否代表用户意图，以及用户是否有权访问其结果。

Orca Security Discovery AI 为这种分层方法提供了一个值得注意的生产案例。其报告的效率提升幅度可观，但更深层的贡献在于系统设计的改变。

现在的问题是，Orca 是否会公布足够的运营证据，以证明这种效率能够经受不断演进的模式和对抗性使用的考验。这些证据将决定该模式能否成为企业智能体更广泛的标准。