Orca Security Discovery AI réduit le coût des requêtes de sécurité en langage naturel

Orca Security Discovery AI convertit désormais des questions de sécurité formulées en anglais courant en requêtes Sonar, tout en utilisant 93 % de tokens d’entrée en moins que sa conception initiale. Orca indique également avoir réduit les coûts des requêtes de 90 % et la latence de 75 % après avoir reconstruit le système sur Amazon Bedrock.

Ces chiffres décrivent davantage qu’une simple mise à niveau de modèle. Orca a remplacé une immense invite par un pipeline en neuf étapes qui décide quand des règles, la récupération d’informations, des modèles plus petits ou un raisonnement approfondi doivent traiter chaque demande.

Le résultat remet en cause une stratégie d’IA d’entreprise courante : placer chaque schéma, exemple et instruction dans une seule grande fenêtre de contexte. L’expérience d’Orca suggère qu’un contexte plus vaste peut accroître les coûts tout en réduisant la pertinence et en ralentissant l’application.

Son alternative traite le modèle de langage comme un composant d’un compilateur de requêtes contrôlé. La correspondance déterministe gère les entrées évidentes, la récupération fournit des exemples éprouvés et la validation vérifie les filtres générés avant leur renvoi.

Cette conception est importante, car les requêtes de sécurité en langage naturel portent sur des informations sensibles et très structurées. Une réponse fluide a peu de valeur lorsque le filtre généré cible le mauvais actif, franchit une limite d’autorisation ou omet une condition critique.

Orca a remplacé une immense invite par un pipeline de production

Le changement central était architectural : Orca a cessé de demander à un modèle unique de comprendre l’intégralité de son schéma de sécurité à chaque requête.

Le système de requêtes Sonar d’Orca couvre plus de 900 modèles d’infrastructure cloud et d’applications. Ces modèles représentent des ressources telles que des instances de calcul, des compartiments de stockage, des identités, des vulnérabilités et les relations qui les relient.

Avant Discovery AI, les utilisateurs devaient construire des filtres JSON précis. Ils devaient également connaître les noms exacts des modèles, naviguer dans des relations imbriquées et choisir parmi 18 opérateurs de filtrage.

Cette exigence créait une barrière d’utilisation pour les analystes qui comprenaient la question de sécurité, mais pas l’ensemble du schéma de Sonar. Orca a donc créé une interface en langage naturel qui traduit la demande d’un analyste en filtre valide.

La première preuve de concept utilisait l’approche d’IA générative la plus directe. Orca chargeait plus de 900 définitions de modèles, types de relations et exemples de requêtes dans une seule invite destinée à un grand modèle.

Selon l’entreprise, les partenaires de conception et les utilisateurs internes appréciaient la qualité des résultats. Toutefois, cette conception consommait environ 2 millions de tokens d’entrée pour une charge de travail comparable et prenait environ 60 secondes.

Les demandes complexes ont également révélé des limites de précision. Les questions impliquant plusieurs modèles de ressources, des relations imbriquées ou plusieurs conditions nécessitaient souvent un affinage supplémentaire.

Orca et AWS ont ensuite développé le pipeline en neuf étapes de production. Il aurait traité des milliers de requêtes quotidiennes depuis mars 2026, avec des temps de réponse proches de 15 secondes.

Le pipeline commence par combiner la demande avec le contexte organisationnel. Ce contexte peut inclure les fournisseurs cloud connectés, les métadonnées de la demande et les détails nécessaires à l’interprétation de l’environnement de l’utilisateur.

Ensuite, un outil de correspondance déterministe recherche des identifiants structurés. Il s’agit notamment d’adresses IP, d’identifiants CVE, de hachages de fichiers, de noms de ressources, d’URL et d’identifiants d’alerte.

Un identifiant correspondant peut déclencher un filtre prédéfini sans appel coûteux à un modèle. Ce chemin rapide éloigne les tâches prévisibles d’un système probabiliste.

Les demandes nécessitant une interprétation passent par une barrière de sécurité. Orca affirme que cette étape bloque les tentatives d’injection d’invite, les questions non pertinentes et les entrées non prises en charge avant qu’elles n’atteignent la génération de requêtes.

Le système recherche ensuite dans une bibliothèque d’exemples validés. Les embeddings Amazon Titan récupèrent 20 candidats sémantiquement similaires, et Cohere Rerank 3.5 réduit cet ensemble à cinq.

Un sélecteur de modèles restreint les plus de 900 modèles Sonar à ceux qui sont pertinents pour la demande en cours. Le générateur ne reçoit des schémas détaillés que pour ce groupe plus restreint et leurs relations.

Anthropic Claude Haiku 4.5 alimente les étapes de sélection et de génération. Amazon Nova 2 Lite prend en charge les tâches de barrière de sécurité et de validation, pour lesquelles Orca privilégie une inférence plus rapide et moins coûteuse.

Le filtre généré ne devient toujours pas automatiquement le résultat final. Des contrôles statiques résolvent chaque modèle, champ et opérateur par rapport aux schémas sélectionnés.

Orca vérifie également le filtre via l’API Sonar. Lorsque la validation échoue, l’erreur identifie l’élément en cause et le renvoie au générateur pour correction.

Cette boucle transforme la génération en processus contraint. Le modèle peut proposer un filtre, mais des systèmes déterministes décident si cette proposition est conforme au schéma disponible.

Orca Security Discovery AI réduit délibérément le contexte

Orca Security Discovery AI a amélioré ses performances économiques déclarées en sélectionnant le contexte, et non en l’élargissant.

Le prototype initial considérait le schéma complet de Sonar comme un contexte obligatoire. Ce choix semblait raisonnable, car le modèle devait comprendre des centaines de types de ressources et leurs relations.

Le problème était que la plupart des questions ne concernaient qu’une petite partie de ce schéma. Envoyer chaque définition à chaque demande augmentait l’utilisation des tokens sans rendre chaque définition utile.

Le sélecteur de modèles d’Orca fonctionne désormais à partir de descriptions compactes des modèles disponibles. Chaque description résume le nom, le rôle, les champs importants et les relations importantes d’un modèle.

Le sélecteur identifie les modèles requis par une question. Le générateur ne reçoit alors le schéma complet que pour ces sélections, ainsi que les relations nécessaires pour les connecter.

Ce changement a réduit l’utilisation déclarée de tokens d’entrée d’environ 2 millions à 140 000 par charge de travail comparable. Cela représente la réduction annoncée de 93 %.

Orca attribue la baisse des coûts de 90 % à un volume de tokens inférieur et à l’attribution de modèles par étape. Les différentes tâches ne recourent plus par défaut au plus grand modèle disponible.

La latence serait passée d’environ 60 secondes à 15 secondes, soit une réduction de 75 %. Le parcours plus rapide contient toujours plusieurs étapes, ce qui montre que le nombre d’étapes ne détermine pas à lui seul le temps de réponse.

Une longue inférence unique peut être plus lente que plusieurs opérations ciblées. Les règles et la récupération peuvent également contourner la génération lorsque le système reconnaît un motif connu.

C’est le mécanisme central des gains annoncés. Orca a réduit la quantité de contenu nécessitant un raisonnement approfondi, puis a réservé le travail génératif aux parties non résolues de la demande.

La conception de récupération suit le même principe. La recherche sémantique pure top-K était rapide, mais Orca a constaté qu’elle renvoyait souvent des exemples presque identiques.

Ces doublons occupaient du contexte sans apporter beaucoup de couverture supplémentaire. La pertinence marginale maximale augmentait la diversité, mais elle éloignait parfois l’exemple le plus pertinent de la première position.

Orca a choisi de récupérer 20 exemples proches puis de les reclasser pour n’en conserver que cinq. Le premier passage plus large privilégie le rappel, tandis que le reclassement concentre le contexte final sur les correspondances les plus solides.

Une correspondance à forte confiance peut réutiliser directement un filtre déjà éprouvé. Dans le cas contraire, les cinq exemples montrent au générateur comment des questions validées ont été précédemment traduites.

Cette approche ressemble davantage à un raisonnement fondé sur des cas qu’à une génération sans contrainte. Le modèle travaille à partir d’un schéma compact et d’exemples tirés de comportements historiques réussis.

L’architecture conserve également la possibilité de remplacer les modèles choisis. Amazon Bedrock donne accès à plusieurs familles de modèles via une couche de service partagée, réduisant le travail d’intégration distinct.

Cette flexibilité est importante, car le modèle le plus rapide ou le plus précis pour une étape donnée peut évoluer. Orca pourrait remplacer le modèle d’une étape sans reconcevoir l’ensemble de l’application.

L’enseignement plus large n’est pas que chaque système a besoin de neuf étapes. C’est que le contexte doit justifier sa place dans une invite de production.

Les schémas, les exemples et l’historique de conversation entraînent des coûts, même lorsqu’un modèle prend en charge une grande fenêtre de contexte. Les éléments non pertinents peuvent aussi concurrencer les informations réellement importantes.

Les requêtes de sécurité en langage naturel nécessitent toujours des limites strictes

Une interface conversationnelle réduit les frictions liées au langage de requête, mais elle ne peut pas remplacer l’autorisation, la validation ni l’expertise en sécurité.

Les requêtes de sécurité en langage naturel peuvent aider un analyste à passer d’une idée d’investigation à un filtre structuré. Elles ne garantissent pas que la question elle-même soit autorisée ou complète.

Le pipeline d’Orca comprend le contexte de la demande, un filtrage par barrière de sécurité, une génération contrainte et deux formes de validation. Cette séquence reconnaît le risque de traiter la sortie d’un modèle comme une vérité exécutable.

L’évaluation des barrières de sécurité d’Amazon Bedrock peut examiner les invites et les réponses au regard de politiques configurées. Les contrôles disponibles comprennent des filtres de contenu, des sujets interdits, des filtres d’informations sensibles et la détection des attaques par invite.

Toutefois, une barrière de sécurité n’est pas un système d’autorisation. Elle peut classifier une entrée tout en ne disposant pas de l’identité utilisateur et des autorisations de ressources nécessaires à une décision d’accès.

Les recommandations de sécurité d’AWS établissent explicitement cette distinction. Ses contrôles d’autorisation recommandent d’appliquer l’accès aux données en dehors du modèle de langage et de propager l’identité de l’utilisateur dans les systèmes connectés.

Cette séparation est particulièrement importante pour les données de sécurité cloud. Une requête peut révéler des noms d’actifs, des vulnérabilités, des relations entre comptes, des chemins réseau ou des détails de configuration internes.

Un assistant disposant d’un large accès au backend peut devenir un mandataire confus. Cela se produit lorsqu’un utilisateur moins privilégié obtient des informations par l’intermédiaire d’un composant disposant de privilèges plus élevés.

L’architecture sûre doit limiter les données qui atteignent le modèle. Elle doit également veiller à ce que la requête Sonar résultante s’exécute avec des autorisations adaptées à l’utilisateur demandeur.

L’architecture publiée indique qu’Orca combine les demandes avec le contexte organisationnel et celui des fournisseurs cloud. L’article ne fournit pas de description détaillée de l’isolation des locataires ni de l’application des autorisations au niveau utilisateur.

Cette omission n’établit pas une faiblesse. Elle signifie simplement que les résultats de performance publiés ne doivent pas être interprétés comme une évaluation complète de la sécurité.

La validation crée une autre limite importante. Orca vérifie d’abord la syntaxe, puis contrôle le filtre généré via son API Sonar.

Le générateur reçoit des erreurs structurées lorsqu’un contrôle échoue. Il peut réviser le champ, l’opérateur ou la relation concernés au lieu de repartir d’une nouvelle hypothèse sans contrainte.

Cette approche réduit une catégorie d’hallucinations : les références à des éléments de schéma inexistants. Elle ne garantit pas que chaque requête valide reflète fidèlement l’intention de l’analyste.

Un filtre peut être syntaxiquement valide tout en étant sémantiquement incomplet. Il peut sélectionner le bon modèle, mais omettre une exception, une relation, une limite temporelle ou une condition environnementale.

Ce problème devient plus sérieux lorsqu’une demande concise masque une ambiguïté. « Affichez les bases de données exposées » peut dépendre des définitions de l’exposition, du type de base de données, de l’accessibilité réseau et du niveau de risque accepté.

Une interface robuste devrait révéler les hypothèses ou afficher le filtre généré pour examen. L’article d’AWS se concentre sur la génération et la validation des filtres, et non sur l’expérience complète de révision.

Les équipes de sécurité doivent donc distinguer la validité d’une requête de son exactitude investigative. La première peut être vérifiée automatiquement par rapport à des schémas, tandis que la seconde exige souvent un jugement métier.

Les sorties déterministes du système méritent également l’attention. Réutiliser un exemple validé peut réduire la latence, mais le seuil de correspondance doit empêcher que des questions superficiellement semblables partagent un filtre inadapté.

Orca indique orienter les requêtes à faible niveau de confiance vers des experts du domaine. Ce processus de retour d’information est utile, même si son efficacité dépend de l’échantillonnage, de la couverture des revues et de la qualité des corrections.

L’accès en langage naturel peut élargir la participation aux investigations de sécurité. Il transfère aussi la responsabilité des auteurs de requêtes vers les concepteurs de la plateforme qui intègrent ces garde-fous.

Le véritable adversaire est la conception à un seul modèle et un seul prompt

La comparaison la plus significative d’Orca ne porte pas sur un autre fournisseur, mais sur le prototype monolithique qu’il a remplacé.

Les produits d’IA générative commencent souvent par un prompt connecté à un modèle performant. Cette structure convient bien pour vérifier qu’un modèle comprend la tâche.

Elle devient plus difficile à défendre lorsque l’application fait face à un trafic réel, à des schémas changeants, à des exigences strictes de latence et à des données organisationnelles sensibles.

Le système de référence d’Orca a révélé cette transition. Le prototype produisait des réponses encourageantes, mais envoyait un vaste schéma dans chaque requête et peinait encore à gérer des relations complexes.

Le système de production déplace plusieurs responsabilités hors du générateur. Des expressions régulières reconnaissent les identifiants exacts, la récupération retrouve des exemples, le reranking réduit le bruit et des validateurs rejettent les filtres mal formés.

Cette répartition entraîne un renversement important. L’ajout de composants a réduit le coût global et la latence, car ces composants évitaient des traitements génératifs inutiles.

Le pipeline remet également en question les achats centrés sur le modèle. Choisir le plus grand modèle n’a pas, à lui seul, résolu le problème de production.

Orca a plutôt attribué les modèles selon les exigences de chaque tâche. Les étapes exigeant davantage de raisonnement ont reçu Claude Haiku 4.5, tandis que les étapes plus ciblées de filtrage et de validation ont reçu Nova 2 Lite.

Amazon Titan a créé les embeddings pour la recherche sémantique. Cohere Rerank 3.5 a évalué les exemples récupérés avant la génération.

Ce mélange crée une complexité opérationnelle. Les équipes doivent surveiller plusieurs modèles, le comportement de la récupération, les boucles de validation et les dépendances, plutôt qu’un seul appel d’API.

Pourtant, une architecture à appel unique masque la complexité dans un grand prompt. Elle n’élimine ni la gestion des schémas, ni l’évaluation, ni l’autorisation, ni la gestion des erreurs.

Des travaux antérieurs d’AWS sur les investigations en langage naturel ont montré un modèle similaire pour Amazon Security Lake. Un agent traduisait les questions des analystes en SQL et prenait en charge l’analyse de suivi des journaux de sécurité.

L’implémentation d’Orca cible son propre graphe de données Sonar et des filtres spécifiques au domaine. Sa caractéristique distinctive est la réduction agressive des schémas et des exemples avant la génération.

Ce modèle peut s’appliquer au-delà de la sécurité cloud. Les systèmes d’entreprise exposent souvent des centaines d’objets, de champs, de relations et d’opérations autorisées.

Les plateformes de support client, les outils d’analyse, les portails développeurs et les systèmes de connaissances font face à la même tentation : placer chaque définition dans le prompt. Cette approche peut fonctionner lors de démonstrations et échouer face aux contraintes économiques de la production.

L’alternative ressemble à un pipeline de compilation. Le système analyse la requête, identifie les structures pertinentes, récupère des précédents, génère une représentation intermédiaire et la valide.

Le modèle de langage gère l’ambiguïté et la traduction. Les composants déterministes appliquent les règles contrôlables.

Cette répartition facilite également la localisation des défaillances. Une équipe peut déterminer si la récupération a manqué un exemple pertinent, si la sélection a omis un schéma ou si la validation a rejeté un opérateur.

Un prompt unique produit souvent un signal d’échec moins utile. La réponse est simplement erronée, coûteuse, lente, ou une combinaison des trois.

Orca indique que son harnais d’évaluation mesure l’exactitude, l’exhaustivité et l’équivalence sémantique avec des requêtes de référence. Il répartit également les résultats en segments selon les catégories de questions et de modèles.

C’est plus informatif qu’un score agrégé unique. Un système peut bien fonctionner globalement tout en échouant sur de rares relations multi-cloud ou des conditions de vulnérabilité complexes.

Cette conception pousse les autres équipes d’IA d’entreprise à communiquer des résultats au niveau du système. Les scores de benchmark des modèles ne suffisent pas à expliquer la latence applicative, la qualité de récupération, les taux de validation ou les charges de correction.

Les chiffres sont solides, mais les preuves de précision restent incomplètes

Les améliorations de coût et de latence sont précises, tandis que l’affirmation publique sur la précision ne présente pas le même niveau de détail de mesure.

AWS et Orca fournissent des chiffres avant-après clairs concernant les tokens, le coût et le temps de réponse. Ils ne publient pas l’ensemble de données d’évaluation, la taille de l’échantillon, le taux de réussite ni l’amélioration exacte de la précision.

L’article indique que la précision s’est améliorée pour les requêtes complexes et multi-modèles. Il décrit également un système de LLM-as-judge qui évalue l’exactitude, l’exhaustivité et l’équivalence sémantique.

Un LLM-as-judge utilise un autre modèle pour évaluer les résultats générés. Il peut favoriser des itérations rapides, mais ses conclusions dépendent de la grille d’évaluation, des réponses de référence et de la fiabilité du juge.

Orca complète la notation automatisée avec des spécialistes internes et les retours des clients. Les chefs de produit, ingénieurs support et chercheurs en sécurité peuvent signaler des sorties et ajouter des exemples corrigés.

Les requêtes de production à faible confiance seraient intégrées à une file d’étiquetage quotidienne. Les corrections deviennent disponibles pour les cycles de récupération suivants sans nécessiter de déploiement logiciel.

Le directeur de l’IA d’Orca, Or Gabay, a qualifié cette interface d’étiquetage d’investissement le plus important de l’équipe pour la qualité à long terme. Cette déclaration met en avant un processus humain plutôt qu’une nouvelle amélioration de modèle.

Ce processus paraît crédible comme mécanisme d’amélioration. Il laisse néanmoins plusieurs questions sans réponse pour les acheteurs externes et les équipes d’ingénierie.

L’article public ne précise pas à quelle fréquence la génération atteint la limite de tentatives. Il n’indique pas combien de requêtes suivent des chemins déterministes ou de réutilisation d’exemples.

Il ne distingue pas non plus la latence médiane de la latence de queue. Un chiffre de 15 secondes peut décrire une charge de travail typique tout en masquant des requêtes complexes plus lentes.

L’expression « charge de travail comparable » nécessite davantage de précisions. Les réductions de tokens et de coûts dépendent du mélange de requêtes, des modèles sélectionnés, du comportement du cache, de la longueur des sorties et du nombre de tentatives.

La réduction de coût annoncée compare également le pipeline de production au système de référence initial d’Orca. Il ne s’agit pas d’un benchmark face à d’autres produits de sécurité cloud ou systèmes de génération de requêtes.

Les lecteurs devraient considérer ces pourcentages comme des résultats opérationnels déclarés par l’entreprise. L’étude de cas AWS rédigée conjointement fournit des détails techniques, mais ne constitue pas un audit indépendant.

La date de mise en production de mars 2026 et les milliers de requêtes quotidiennes offrent un signal d’adoption utile. Elles ne révèlent ni le nombre d’utilisateurs uniques, ni les taux d’acceptation, d’abandon ou le temps économisé par les analystes.

Ces métriques aideraient à déterminer si le langage naturel modifie les pratiques d’investigation. La baisse des coûts d’inférence est importante, mais la valeur pour l’utilisateur dépend en définitive de décisions de sécurité meilleures et plus rapides.

La boucle de retour du système introduit un autre compromis. Les exemples de production améliorent la couverture, mais les corrections peuvent intégrer des interprétations incohérentes si les experts ne suivent pas une politique commune.

Une base d’exemples grandissante exige également une gouvernance. Les équipes ont besoin de versionnage, de contrôle qualité, de procédures de suppression et de protections contre l’introduction d’informations sensibles dans les exemples récupérés.

Les recommandations d’AWS pour les applications d’IA générative préconisent de limiter les données récupérées avant qu’elles n’atteignent un modèle. Ses contrôles de sécurité mettent l’accent sur la propagation de l’identité et l’application des contrôles d’accès au niveau des données.

Ces préoccupations n’annulent pas les résultats d’Orca. Elles définissent les preuves nécessaires avant qu’une autre organisation ne considère l’architecture comme un modèle réutilisable.

La conclusion publique la plus solide est restreinte, mais utile. Orca rapporte que la sélection de contexte, la spécialisation des modèles, la récupération et la validation ont considérablement amélioré sa conception d’origine.

Les éléments disponibles n’établissent pas une réduction universelle pour chaque agent riche en schémas. Les équipes doivent mesurer ce modèle par rapport à leurs propres charges de travail et exigences d’autorisation.

Ce qu’il faut surveiller après le déploiement d’Orca sur Amazon Bedrock

Le prochain test consiste à savoir si Orca peut préserver la qualité à mesure que les schémas, les comportements des utilisateurs et les versions des modèles évoluent.

Le premier signal est la publication de détails sur la précision. Un futur rapport technique devrait divulguer la taille de l’ensemble de données, les catégories de requêtes, les seuils de réussite et l’accord avec les revues humaines.

Les résultats par segment seraient particulièrement utiles. Les requêtes de relations multi-modèles semblent être la catégorie la plus difficile et le test le plus exigeant de l’architecture d’Orca.

Une évaluation plus transparente renforcerait l’affirmation selon laquelle la nouvelle conception a amélioré la précision, et pas seulement l’efficacité. Une hausse des taux de correction ou de nouvelle tentative affaiblirait cette conclusion.

Le deuxième signal est une adoption durable en production. Orca affirme que Discovery AI traite des milliers de requêtes quotidiennes, mais les tendances d’utilisation à plus long terme montreront si les analystes font confiance à l’interface.

Les indicateurs utiles comprennent l’utilisation répétée, les filtres acceptés, les modifications manuelles, le temps économisé et la part des questions résolues sans escalade. Ces mesures relient le comportement du modèle aux opérations de sécurité.

Le troisième signal concerne la manière dont le pipeline gère le changement. Les schémas de Sonar évolueront, les clients poseront des questions inédites et les modèles de fondation recevront de nouvelles versions.

La conception indépendante des modèles d’Orca devrait faciliter les remplacements. Toutefois, chaque changement exige encore des tests de régression portant sur la récupération, la génération, la validation et les frontières d’autorisation.

Le harnais d’évaluation continue est donc aussi important que l’architecture initiale. Chaque prompt, modèle, paramètre de récupération et exemple peut modifier le comportement sur des segments inattendus.

Le système doit également rester utile face à l’évolution des comportements de menace. Les analystes peuvent rattacher leurs investigations au cadre de menaces cloud tandis que les attaquants adoptent de nouveaux chemins et de nouvelles combinaisons de ressources.

Une bibliothèque d’exemples statique se dégraderait dans ces conditions. La boucle d’étiquetage par experts d’Orca vise à maintenir la banque de récupération alignée sur les questions émergentes.

Pour les équipes d’ingénierie, l’action immédiate consiste à examiner les grands prompts qui contiennent des éléments que la plupart des requêtes n’utilisent jamais. Ces éléments pourraient relever de la sélection, de la récupération ou du routage déterministe.

Les équipes devraient également séparer trois vérifications : si une requête est valide, si elle représente l’intention de l’utilisateur et si celui-ci est autorisé à accéder à ses résultats.

Orca Security Discovery AI offre un cas de production notable pour cette approche en couches. Ses gains d’efficacité rapportés sont substantiels, mais sa contribution plus profonde réside dans une évolution de la conception des systèmes.

La question est désormais de savoir si Orca publiera suffisamment de preuves opérationnelles pour démontrer que cette efficacité résiste à l’évolution des schémas et aux usages adversariaux. Ces éléments détermineront si ce modèle devient une norme plus large pour les agents d’entreprise.