Orca Security用Amazon Bedrock打造自然语言安全查询，延迟降75%

云安全平台Orca Security正在尝试让安全分析师用日常语言提问，而不是花时间学习复杂的查询语法。这家公司基于亚马逊云科技的Amazon Bedrock构建了一个名为Discovery AI的自然语言查询代理，将普通英语问题自动转换为Sonar查询语句。根据官方披露的数据，这套系统相比最初的基线方案，查询成本降低了90%，输入token数量减少了93%，延迟降低了75%。

从自然语言到安全查询的翻译难题

Orca Security的核心能力建立在Sonar平台之上。Sonar是该公司推出的无代理云安全扫描引擎，能够跨云环境发现资产、配置和潜在风险。分析师通过Sonar查询语言来筛选和定位特定问题，例如查找某个区域内暴露的S3存储桶，或者追踪具有管理员权限的过度授权身份。

问题在于，Sonar查询语言虽然强大，但学习曲线陡峭。安全团队的新成员往往需要数周时间才能熟练编写查询，而资深分析师在紧急事件响应时也不愿意手动拼写复杂语句。Discovery AI的目标就是消除这层语法障碍，让用户直接用「哪些EC2实例暴露在公网且没有打补丁」这类问题来驱动查询。

Amazon Bedrock作为底层模型服务，提供了对多种基础模型的访问能力。Orca Security选择Bedrock的原因在于，它能够在单一平台上调用不同厂商的模型，同时满足企业对数据安全和合规的要求。根据AWS官方博客的介绍，Discovery AI的架构经过多轮迭代，最终在准确率、成本和响应速度之间找到了平衡点。

无代理（Agentless）云安全扫描是 Orca Security 的核心技术路线。传统云安全工具通常需要在每台主机、容器或虚拟机上安装轻量代理（Agent）来采集运行时数据，部署和维护成本高，且容易出现覆盖盲区。无代理方案则通过调用云厂商提供的原生 API——例如 AWS 的资源配置快照、EBS 卷快照、IAM 策略读取接口——从云平台侧「旁路」获取资产清单、配置状态和漏洞信息。这种方式的优势在于部署快、覆盖全、对业务系统零侵入，尤其适合多云和快速扩缩容的环境。代价是数据获取存在一定延迟，且对云厂商 API 的依赖较强。Sonar 平台正是建立在这一机制之上，因此它能拿到大量结构化的资产元数据，这也解释了为什么上下文压缩会成为 Discovery AI 的关键工程环节。

多阶段架构如何压缩93%的输入token

Discovery AI并没有把用户的原始问题直接扔给大语言模型。根据Orca Security工程团队的描述，系统采用了一个分阶段的处理流水线，每个阶段只把必要的信息传递给下一环节。

第一阶段是意图识别和查询分类。系统先判断用户的问题属于哪种安全查询类型——是资产发现、配置检查、合规审计还是威胁狩猎。这一步用较小的模型或规则引擎完成，避免大模型处理每个请求。

第二阶段是上下文压缩。安全查询往往需要引用大量的资产元数据、策略定义和历史记录。如果把这些上下文全部塞进模型的输入窗口，token消耗会迅速膨胀。Orca Security的做法是只提取与当前查询类型最相关的字段和少量示例，把输入规模压下来。这也是输入token减少93%的主要来源。

第三阶段才是查询生成。经过前两步筛选后的精简上下文被送入Bedrock上的模型，生成Sonar查询语句。生成结果还会经过语法校验和权限检查，确保不会产生无效或越权的查询。

这种多阶段设计的核心逻辑是：不是每个环节都需要最贵的模型和最全的上下文。把任务拆解后，大模型只负责它最擅长的部分——把结构化意图翻译成查询语法。

Token 是大语言模型处理文本的基本计量单位，可以粗略理解为词或词的片段。模型服务的计费、上下文窗口上限以及推理耗时，通常都以 token 数量衡量。输入 token 指用户提示词和附加上下文所占的 token，输出 token 则是模型生成内容所占的部分。对于安全查询场景，如果每次都把完整的资产清单、策略定义和历史记录塞进提示词，输入 token 会迅速达到数万甚至更多，既推高成本又拖慢响应。因此，把「喂给模型的上下文」精简到只保留与当前任务强相关的字段，是成本优化的第一杠杆，也是官方所称 93% 输入 token 降幅的主要来源。

90%成本削减背后的工程取舍

Orca Security公布的90%查询成本降幅，需要放在具体语境中理解。官方所说的「初始基线」指的应该是早期版本，当时很可能采用了端到端的单模型方案：用户问题加上全部上下文一次性送入大模型，直接输出查询。这种方式实现简单，但token消耗和延迟都居高不下。

从工程角度看，成本削减主要来自三个方向。一是前面提到的输入token压缩，直接减少了计费单元。二是模型分层，意图识别和校验环节使用轻量模型或非模型方案，只有查询生成环节调用大模型。三是缓存和复用，相似的安全查询请求可以共享中间结果，避免重复计算。

延迟降低75%的逻辑也类似。输入token减少本身就缩短了推理时间，而多阶段架构中轻量环节的快速响应进一步改善了端到端体验。对于安全分析师来说，查询响应从「等待十几秒」变成「几秒内返回」，会直接影响他们使用自然语言查询的频率。

不过，这些数字都是Orca Security在自身场景下测试的结果。不同企业的云环境规模、查询复杂度和并发量都会影响实际表现。把这些指标当作参考基准比当作通用承诺更合适。

模型分层，也叫模型路由或大小模型协同，是指在同一个系统中按任务难度和重要性调用不同规格的模型。轻量模型参数量小、推理快、单位调用成本低，适合分类、意图识别、格式校验等相对确定的判断；大模型能力强但昂贵，适合需要复杂推理和生成的任务。Discovery AI 只把最终的自然语言到查询语句的翻译交给 Bedrock 上的大模型，前面的意图识别和后续的语法、权限校验则用更轻的方案完成。这种分工让昂贵算力集中在真正创造价值的一步，是 90% 成本削减和 75% 延迟下降的重要结构性原因。

自然语言安全查询能走多远

Discovery AI代表了一个更广泛的趋势：安全工具正在从「专家写给专家用」转向「自然语言驱动」。Splunk、Datadog等平台也在探索类似能力，让运维和安全人员用对话方式完成查询和分析。

这条路径的挑战不在于模型能不能生成语法正确的查询，而在于能不能理解安全语境中的隐含意图。比如「找出所有有风险的存储桶」——什么算风险？是公开访问、未加密、还是缺少版本控制？不同团队的定义可能完全不同。Discovery AI需要把这类模糊表达映射到企业自身的安全策略上，这往往需要额外的配置和调优。

另一个关键问题是可解释性。当系统生成一条查询并返回结果时，分析师需要知道为什么这条查询被这样构造。如果自然语言层完全遮蔽了底层的Sonar逻辑，安全团队可能对结果产生不信任，尤其是在误报或漏报发生时。

Orca Security的实践表明，Amazon Bedrock作为模型接入层可以支撑这类应用，但真正的价值来自围绕模型构建的工程架构。把自然语言翻译成安全查询，不是一个提示词工程问题，而是一个系统设计问题。

可解释性（Explainability） 在安全运营中是一个被反复强调的要求。分析师看到一条查询返回的资产或风险列表时，需要判断结果是否可信：这条查询到底筛选了哪些条件、为什么把某些资产包含进来、又为什么排除了另一些。如果自然语言层把底层的 Sonar 查询逻辑完全隐藏，用户就只能被动接受结果，一旦出现误报或漏报，很难定位是语义理解偏差还是策略配置问题。可行的做法包括回显生成的查询语句、标注被采纳的意图和上下文来源，以及提供一键修正并回写策略的入口，让自然语言层作为透明的翻译器而非黑箱。