Orca Security Discovery AI Riduce il Costo delle Query di Sicurezza in Linguaggio Naturale
Orca Security Discovery AI ora converte domande di sicurezza espresse in inglese semplice in query Sonar, utilizzando il 93% in meno di token di input rispetto al progetto iniziale. Orca segnala inoltre costi delle query inferiori del 90% e una latenza ridotta del 75% dopo aver ricostruito il sistema su Amazon Bedrock.
Questi numeri descrivono più di un normale aggiornamento del modello. Orca ha sostituito un unico prompt enorme con una pipeline in nove fasi che decide quando affidare ciascuna richiesta a regole, recupero delle informazioni, modelli più piccoli o ragionamenti più approfonditi.
Il risultato mette sotto pressione una strategia AI diffusa nelle aziende: inserire ogni schema, esempio e istruzione in un'unica grande finestra di contesto. L'esperienza di Orca suggerisce che un contesto più ampio possa aumentare i costi, indebolire la pertinenza e rallentare l'applicazione.
La sua alternativa considera il modello linguistico come un componente all'interno di un compilatore di query controllato. Il matching deterministico gestisce gli input più evidenti, il recupero fornisce esempi comprovati e la validazione verifica i filtri generati prima di restituirli.
Questo progetto è importante perché le query di sicurezza in linguaggio naturale operano su informazioni sensibili e altamente strutturate. Una risposta fluente ha poco valore se il filtro generato punta alla risorsa sbagliata, oltrepassa un confine di autorizzazione o omette una condizione critica.
Orca Ha Sostituito un Unico Prompt Enorme con una Pipeline di Produzione
Il cambiamento centrale è stato architetturale: Orca ha smesso di chiedere a un singolo modello di comprendere l'intero schema di sicurezza a ogni richiesta.
Il sistema di query Sonar di Orca copre oltre 900 modelli di infrastruttura cloud e applicazioni. Questi modelli rappresentano risorse quali istanze di calcolo, bucket di storage, identità, vulnerabilità e le relazioni che le collegano.
Prima di Discovery AI, gli utenti dovevano costruire filtri JSON precisi. Dovevano inoltre conoscere i nomi esatti dei modelli, navigare relazioni annidate e scegliere tra 18 operatori di filtro.
Questo requisito creava una barriera di usabilità per gli analisti che comprendevano la questione di sicurezza ma non l'intero schema di Sonar. Orca ha quindi sviluppato un'interfaccia in linguaggio naturale che traduce la richiesta di un analista in un filtro valido.
La prima proof of concept utilizzava l'approccio più diretto all'AI generativa. Orca caricava oltre 900 definizioni di modelli, tipi di relazione ed esempi di query in un unico prompt per un modello di grandi dimensioni.
Secondo l'azienda, i partner di progettazione e gli utenti interni hanno apprezzato la qualità dell'output. Tuttavia, il progetto consumava circa 2 milioni di token di input per un carico di lavoro comparabile e richiedeva all'incirca 60 secondi.
Le richieste complesse hanno inoltre evidenziato limiti di accuratezza. Le domande che coinvolgevano diversi modelli di risorse, relazioni annidate o condizioni multiple richiedevano spesso ulteriori rifiniture.
Orca e AWS hanno quindi sviluppato la pipeline in nove fasi per la produzione. Secondo quanto riportato, da marzo 2026 gestisce migliaia di query giornaliere, con tempi di risposta intorno ai 15 secondi.
La pipeline inizia combinando la richiesta con il contesto organizzativo. Tale contesto può includere i provider cloud connessi, metadati della richiesta e dettagli necessari per interpretare l'ambiente dell'utente.
Successivamente, un matcher deterministico cerca identificatori strutturati. Tra questi figurano indirizzi IP, identificatori CVE, hash di file, nomi di risorse, URL e ID degli avvisi.
Un identificatore corrispondente può attivare un filtro predefinito senza una costosa chiamata al modello. Questo percorso rapido mantiene il lavoro prevedibile lontano da un sistema probabilistico.
Le richieste che necessitano di interpretazione passano attraverso un guardrail. Orca afferma che questa fase blocca tentativi di prompt injection, domande irrilevanti e input non supportati prima che raggiungano la generazione delle query.
Il sistema cerca quindi in una libreria di esempi validati. Gli embedding Amazon Titan recuperano 20 candidati semanticamente simili, mentre Cohere Rerank 3.5 riduce il gruppo a cinque.
Un selettore di modelli restringe gli oltre 900 modelli Sonar a quelli rilevanti per la richiesta corrente. Il generatore riceve schemi dettagliati solo per questo gruppo più ristretto e per le relative relazioni.
Anthropic Claude Haiku 4.5 alimenta le fasi di selezione e generazione. Amazon Nova 2 Lite gestisce le attività di guardrail e validazione, dove Orca privilegia un'inferenza più veloce e meno costosa.
Il filtro generato non diventa comunque automaticamente il risultato finale. I controlli statici risolvono ciascun modello, campo e operatore rispetto agli schemi selezionati.
Orca verifica inoltre il filtro tramite l'API Sonar. Quando la validazione non riesce, l'errore identifica l'elemento problematico e lo restituisce al generatore per la correzione.
Questo ciclo trasforma la generazione in un processo vincolato. Il modello può proporre un filtro, ma sono i sistemi deterministici a decidere se tale proposta è conforme allo schema disponibile.
Orca Security Discovery AI Riduce Deliberatamente il Contesto
Orca Security Discovery AI ha migliorato l'economia riportata selezionando il contesto, non ampliandolo.
Il prototipo iniziale trattava l'intero schema di Sonar come contesto obbligatorio. Questa scelta sembrava ragionevole perché il modello doveva comprendere centinaia di tipi di risorse e le loro relazioni.
Il problema era che la maggior parte delle domande riguardava solo una piccola parte di quello schema. Inviare ogni definizione a ogni richiesta aumentava l'uso di token senza rendere utile ogni definizione.
Il selettore di modelli di Orca ora lavora a partire da descrizioni compatte dei modelli disponibili. Ogni descrizione sintetizza nome, scopo, campi importanti e relazioni rilevanti di un modello.
Il selettore identifica quali modelli richiede una domanda. Il generatore riceve quindi lo schema completo solo per tali selezioni, oltre alle relazioni necessarie per collegarle.
Questa modifica ha ridotto l'uso di input riportato da circa 2 milioni di token a 140.000 per un carico di lavoro comparabile. Rappresenta la riduzione dichiarata del 93%.
Orca attribuisce la riduzione dei costi del 90% al minore volume di token e all'allocazione dei modelli per fase. Le diverse attività non ricorrono più automaticamente al più grande modello disponibile.
Secondo quanto riportato, la latenza è scesa da circa 60 secondi a 15 secondi, una riduzione del 75%. Il percorso più rapido contiene comunque più fasi, dimostrando che il solo numero di fasi non determina il tempo di risposta.
Una singola inferenza lunga può essere più lenta di diverse operazioni circoscritte. Regole e recupero possono inoltre aggirare la generazione quando il sistema riconosce un modello noto.
Questo è il meccanismo alla base dei miglioramenti riportati. Orca ha ridotto la quantità di materiale che richiede un ragionamento approfondito, riservando poi il lavoro generativo alle parti irrisolte della richiesta.
Il progetto di recupero segue lo stesso principio. La ricerca semantica pura top-K era veloce, ma Orca ha rilevato che spesso restituiva esempi quasi duplicati.
Tali duplicati occupavano contesto senza aggiungere molta copertura. La Maximal Marginal Relevance aumentava la diversità, ma talvolta spostava l'esempio più rilevante lontano dalla prima posizione.
Orca ha scelto di recuperare 20 esempi vicini e riclassificarli fino a cinque. Il primo passaggio più ampio enfatizza il richiamo, mentre il reranking concentra il contesto finale sulle corrispondenze più forti.
Una corrispondenza ad alta confidenza può riutilizzare direttamente un filtro già valido. In caso contrario, i cinque esempi mostrano al generatore come domande validate siano state tradotte in precedenza.
Questo approccio assomiglia più al ragionamento basato sui casi che a una generazione senza vincoli. Il modello lavora con uno schema compatto e con esempi tratti da comportamenti storici riusciti.
L'architettura mantiene inoltre sostituibili le scelte dei modelli. Amazon Bedrock fornisce accesso a diverse famiglie di modelli tramite un livello di servizio condiviso, riducendo il lavoro di integrazione separato.
Questa flessibilità è importante perché il modello più veloce o accurato per una fase può cambiare. Secondo quanto riportato, Orca può sostituire il modello di una fase senza riprogettare l'intera applicazione.
La lezione più ampia non è che ogni sistema necessiti di nove passaggi. È che il contesto dovrebbe meritarsi il proprio posto in un prompt di produzione.
Schemi, esempi e cronologia delle conversazioni impongono costi anche quando un modello supporta una grande finestra di contesto. Il materiale irrilevante può inoltre competere con le evidenze che contano.
Le Query di Sicurezza in Linguaggio Naturale Necessitano Ancora di Limiti Rigorosi
Un'interfaccia conversazionale riduce l'attrito del linguaggio di query, ma non può sostituire autorizzazione, validazione o competenza in materia di sicurezza.
Le query di sicurezza in linguaggio naturale possono aiutare un analista a passare da un'idea investigativa a un filtro strutturato. Non garantiscono che la domanda stessa sia autorizzata o completa.
La pipeline di Orca include contesto della richiesta, screening tramite guardrail, generazione vincolata e due forme di validazione. Questa sequenza riconosce il rischio di trattare l'output del modello come una verità eseguibile.
La valutazione dei guardrail di Amazon Bedrock può ispezionare prompt e risposte rispetto a policy configurate. I controlli disponibili includono filtri sui contenuti, argomenti negati, filtri per informazioni sensibili e rilevamento degli attacchi ai prompt.
Tuttavia, un guardrail non è un sistema di autorizzazione. Può classificare un input pur non disponendo dell'identità dell'utente e delle autorizzazioni sulle risorse necessarie per una decisione di accesso.
Le linee guida di sicurezza AWS rendono esplicita questa distinzione. I suoi controlli di autorizzazione raccomandano di applicare l'accesso ai dati al di fuori del modello linguistico e di propagare l'identità dell'utente attraverso i sistemi connessi.
Questa separazione è particolarmente importante per i dati di sicurezza cloud. Una query potrebbe esporre nomi di asset, vulnerabilità, relazioni tra account, percorsi di rete o dettagli di configurazione interna.
Un assistente con ampio accesso al backend può diventare un deputy confuso. Ciò accade quando un utente con privilegi inferiori ottiene informazioni tramite un intermediario con privilegi maggiori.
L'architettura sicura deve limitare quali dati raggiungono il modello. Deve inoltre garantire che la query Sonar risultante venga eseguita con autorizzazioni appropriate per l'utente richiedente.
L'architettura pubblicata afferma che Orca combina le richieste con il contesto organizzativo e dei provider cloud. Il post non fornisce un resoconto dettagliato dell'isolamento dei tenant o dell'applicazione dell'autorizzazione a livello utente.
Questa omissione non dimostra una debolezza. Significa semplicemente che i risultati di prestazione riportati non dovrebbero essere interpretati come una valutazione di sicurezza completa.
La validazione crea un altro confine importante. Orca verifica prima la sintassi, quindi controlla il filtro generato tramite la sua API Sonar.
Il generatore riceve errori strutturati quando un controllo non riesce. Può correggere il campo, l'operatore o la relazione specifici, anziché avviare un'altra ipotesi senza vincoli.
Questo approccio riduce una categoria di allucinazione: i riferimenti a elementi dello schema che non esistono. Non dimostra che ogni query valida catturi accuratamente l'intento dell'analista.
Un filtro può essere sintatticamente valido e semanticamente incompleto. Potrebbe selezionare il modello corretto ma omettere un'eccezione, una relazione, un limite temporale o una condizione ambientale.
Il problema diventa più serio quando una richiesta concisa nasconde ambiguità. “Mostra i database esposti” può dipendere dalle definizioni di esposizione, tipo di database, raggiungibilità di rete e rischio accettato.
Un'interfaccia efficace dovrebbe rendere esplicite le assunzioni o mostrare il filtro generato per la revisione. Il post AWS si concentra sulla generazione e sulla validazione dei filtri, non sull'intera esperienza di revisione.
I team di sicurezza dovrebbero quindi distinguere tra validità della query e correttezza investigativa. La prima è verificabile automaticamente rispetto agli schemi, mentre la seconda richiede spesso valutazioni di dominio.
Meritano attenzione anche le uscite deterministiche del sistema. Riutilizzare un esempio convalidato può ridurre la latenza, ma la soglia di corrispondenza deve impedire che domande solo superficialmente simili condividano un filtro inadeguato.
Orca afferma di instradare le query a bassa confidenza verso esperti di dominio. Questo processo di feedback è utile, anche se la sua efficacia dipende dal campionamento, dalla copertura delle revisioni e dalla qualità delle correzioni.
L'accesso tramite linguaggio naturale può ampliare la partecipazione alle indagini di sicurezza. Sposta però anche la responsabilità dagli autori delle query verso i progettisti della piattaforma che codificano queste misure di protezione.
Il vero avversario è la progettazione con un modello e un prompt
Il confronto più significativo per Orca non è con un altro fornitore, ma con il prototipo monolitico che ha sostituito.
I prodotti di IA generativa spesso iniziano come un prompt collegato a un modello capace. Questa struttura funziona bene per verificare se un modello comprende il compito.
Diventa più difficile da difendere quando l'applicazione affronta traffico reale, schemi in evoluzione, requisiti di latenza rigorosi e dati organizzativi sensibili.
Il riferimento iniziale di Orca ha messo in evidenza questa transizione. Il prototipo produceva risposte incoraggianti, ma inviava un vasto schema in ogni richiesta e faticava comunque con relazioni complesse.
Il sistema in produzione sposta diverse responsabilità al di fuori del generatore. Le espressioni regolari riconoscono identificatori esatti, il recupero trova esempi, il reranking riduce il rumore e i validatori rifiutano filtri malformati.
Questa divisione produce un'inversione importante. L'aggiunta di componenti ha ridotto il costo complessivo e la latenza perché tali componenti hanno evitato lavoro generativo superfluo.
La pipeline mette inoltre in discussione l'approvvigionamento incentrato sul modello. Scegliere il modello più grande non ha risolto da solo il problema di produzione.
Orca ha invece assegnato i modelli in base ai requisiti del compito. Le fasi più intensive sul piano del ragionamento hanno ricevuto Claude Haiku 4.5, mentre le fasi più circoscritte di screening e validazione hanno ricevuto Nova 2 Lite.
Amazon Titan ha creato gli embedding per la ricerca semantica. Cohere Rerank 3.5 ha valutato gli esempi recuperati prima della generazione.
Questa combinazione crea complessità operativa. I team devono monitorare diversi modelli, il comportamento del recupero, i cicli di validazione e le dipendenze anziché una singola chiamata API.
Tuttavia, un'architettura a chiamata singola nasconde la complessità dentro un prompt esteso. Non elimina la gestione degli schemi, la valutazione, l'autorizzazione o la gestione degli errori.
Un precedente lavoro AWS sulle indagini in linguaggio naturale ha mostrato un modello correlato per Amazon Security Lake. Un agente traduceva le domande degli analisti in SQL e supportava analisi successive sui log di sicurezza.
L'implementazione di Orca punta al proprio grafo di dati Sonar e a filtri specifici per il dominio. La sua caratteristica distintiva è la riduzione aggressiva di schemi ed esempi prima della generazione.
Questo modello può applicarsi oltre la sicurezza cloud. I sistemi aziendali espongono spesso centinaia di oggetti, campi, relazioni e operazioni consentite.
Le piattaforme di assistenza clienti, gli strumenti di analisi, i portali per sviluppatori e i sistemi di conoscenza affrontano la stessa tentazione di inserire ogni definizione nel prompt. Questo approccio può funzionare durante le dimostrazioni e fallire sotto le pressioni economiche della produzione.
L'alternativa assomiglia a una pipeline di compilazione. Il sistema analizza la richiesta, identifica le strutture pertinenti, recupera precedenti, genera una rappresentazione intermedia e la convalida.
Il modello linguistico gestisce l'ambiguità e la traduzione. I componenti deterministici gestiscono le regole applicabili.
Questa distribuzione rende anche più semplice individuare i fallimenti. Un team può stabilire se il recupero ha mancato un esempio pertinente, la selezione ha omesso uno schema o la validazione ha rifiutato un operatore.
Un singolo prompt spesso produce un segnale di errore meno utile. La risposta è semplicemente errata, costosa, lenta o una combinazione di tutte e tre le cose.
Orca afferma che il suo sistema di valutazione misura correttezza, completezza ed equivalenza semantica rispetto alle query di riferimento. Divide inoltre i risultati in segmenti basati sulle categorie di domande e modelli.
Questo è più informativo di un unico punteggio aggregato. Un sistema può ottenere buoni risultati complessivi pur fallendo nelle rare relazioni multi-cloud o nelle condizioni complesse di vulnerabilità.
Il progetto spinge gli altri team di IA aziendale a riportare risultati a livello di sistema. I soli punteggi dei benchmark dei modelli non possono spiegare la latenza dell'applicazione, la qualità del recupero, i tassi di validazione o i carichi di lavoro per le correzioni.
I numeri sono solidi, ma le prove sull'accuratezza sono incomplete
I miglioramenti di costo e latenza sono specifici, mentre l'affermazione pubblica sull'accuratezza non presenta lo stesso livello di dettaglio nelle misurazioni.
AWS e Orca forniscono dati chiari prima e dopo per token, costo e tempo di risposta. Non pubblicano il dataset di valutazione, la dimensione del campione, il tasso di superamento o il miglioramento esatto dell'accuratezza.
Il post afferma che l'accuratezza è migliorata per query complesse e multi-modello. Descrive inoltre un sistema LLM-as-judge che valuta correttezza, completezza ed equivalenza semantica.
Un LLM-as-judge usa un altro modello per valutare i risultati generati. Può supportare iterazioni rapide, ma le sue conclusioni dipendono dalla rubrica, dalle risposte di riferimento e dall'affidabilità del giudice.
Orca integra il punteggio automatizzato con specialisti interni e feedback dei clienti. Product manager, ingegneri del supporto e ricercatori di sicurezza possono segnalare gli output e aggiungere esempi corretti.
Secondo quanto riportato, le query di produzione a bassa confidenza entrano in una coda giornaliera di etichettatura. Le correzioni diventano disponibili per le successive esecuzioni di recupero senza richiedere un deployment software.
Il direttore dell'IA di Orca, Or Gabay, ha definito quell'interfaccia di etichettatura il più importante investimento a lungo termine del team nella qualità. L'affermazione mette in risalto un processo umano anziché un ulteriore aggiornamento del modello.
Questo processo è credibile come meccanismo di miglioramento. Lascia comunque diverse domande senza risposta per acquirenti esterni e team di ingegneria.
Il post pubblico non rivela con quale frequenza la generazione raggiunga il limite di tentativi. Non riporta quante richieste seguano percorsi deterministici o di riutilizzo degli esempi.
Non separa inoltre la latenza mediana da quella di coda. Una cifra di 15 secondi può descrivere un carico di lavoro tipico nascondendo al contempo richieste complesse più lente.
L'espressione “carico di lavoro comparabile” richiede maggiore definizione. Le riduzioni di token e costo dipendono dal mix di richieste, dai modelli selezionati, dal comportamento della cache, dalla lunghezza dell'output e dal numero di tentativi.
La riduzione dei costi riportata confronta inoltre la pipeline di produzione con il riferimento iniziale di Orca. Non è un benchmark rispetto ad altri prodotti di sicurezza cloud o sistemi di generazione delle query.
I lettori dovrebbero considerare le percentuali come risultati operativi riportati dall'azienda. Il case study AWS cofirmato fornisce dettagli tecnici, ma non è un audit indipendente.
La data di produzione di marzo 2026 e migliaia di query giornaliere offrono un utile segnale di adozione. Non rivelano il numero di utenti unici, i tassi di accettazione, l'abbandono o il tempo risparmiato dagli analisti.
Queste metriche aiuterebbero a determinare se il linguaggio naturale modifica il comportamento investigativo. Ridurre i costi di inferenza è importante, ma il valore per l'utente dipende in ultima analisi da decisioni di sicurezza migliori e più rapide.
Il ciclo di feedback del sistema introduce un ulteriore compromesso. Gli esempi di produzione migliorano la copertura, ma le correzioni possono codificare interpretazioni incoerenti se gli esperti non seguono una politica condivisa.
Una banca di esempi in crescita richiede inoltre una governance. I team hanno bisogno di versionamento, revisione della qualità, procedure di rimozione e protezione contro l'inserimento di informazioni sensibili negli esempi recuperati.
Le linee guida AWS per le applicazioni di IA generativa raccomandano di limitare i dati recuperati prima che raggiungano un modello. I suoi controlli di sicurezza sottolineano la propagazione dell'identità e l'applicazione dell'accesso a livello dei dati.
Queste preoccupazioni non annullano i risultati di Orca. Definiscono le prove necessarie prima che un'altra organizzazione tratti l'architettura come un modello riutilizzabile.
La conclusione pubblica più solida è circoscritta ma utile. Orca riferisce che la selezione del contesto, la specializzazione dei modelli, il recupero e la validazione hanno migliorato drasticamente il suo progetto originale.
Le prove non stabiliscono una riduzione universale per ogni agente con schemi complessi. I team devono misurare questo modello rispetto ai propri carichi di lavoro e requisiti di autorizzazione.
Cosa osservare dopo il deployment di Orca su Amazon Bedrock
Il prossimo test è se Orca riuscirà a preservare la qualità mentre schemi, comportamento degli utenti e versioni dei modelli continuano a cambiare.
Il primo segnale è il dettaglio pubblicato sull'accuratezza. Un futuro rapporto tecnico dovrebbe rivelare dimensione del dataset, categorie di query, soglie di superamento e accordo con la revisione umana.
I risultati a livello di segmento sarebbero particolarmente preziosi. Le query sulle relazioni multi-modello sembrano essere la categoria più difficile e il test più rigoroso dell'architettura di Orca.
Una valutazione più trasparente rafforzerebbe l'affermazione che il nuovo progetto ha migliorato l'accuratezza, non solo l'efficienza. L'aumento dei tassi di correzione o di nuovi tentativi indebolirebbe tale conclusione.
Il secondo segnale è un'adozione sostenuta in produzione. Orca afferma che Discovery AI gestisce migliaia di query giornaliere, ma i modelli di utilizzo nel lungo termine mostreranno se gli analisti si fidano dell'interfaccia.
Indicatori utili includono utilizzo ripetuto, filtri accettati, modifiche manuali, tempo risparmiato e quota di domande risolte senza escalation. Queste misure collegano il comportamento del modello alle operazioni di sicurezza.
Il terzo segnale riguarda il modo in cui la pipeline gestisce il cambiamento. Gli schemi di Sonar evolveranno, i clienti porranno domande non familiari e i modelli di fondazione riceveranno nuove versioni.
Il design indipendente dal modello di Orca dovrebbe rendere più semplici le sostituzioni. Tuttavia, ogni modifica richiede comunque test di regressione attraverso i confini di recupero, generazione, validazione e autorizzazione.
Il sistema di valutazione continua è quindi importante quanto l'architettura iniziale. Ogni prompt, modello, impostazione di recupero ed esempio può alterare il comportamento in segmenti inattesi.
Il sistema deve inoltre rimanere utile contro comportamenti di minaccia in evoluzione. Gli analisti possono mappare le indagini sul framework delle minacce cloud mentre gli aggressori adottano nuovi percorsi e combinazioni di risorse.
Una libreria statica di esempi decadrebbe in tali condizioni. Il ciclo di etichettatura degli esperti di Orca è pensato per mantenere la banca di recupero allineata alle domande emergenti.
Per i team di ingegneria, l'azione immediata è esaminare dove i prompt di grandi dimensioni contengano materiale che la maggior parte delle richieste non usa mai. Quel materiale potrebbe appartenere a un livello di selezione, recupero o instradamento deterministico.
I team dovrebbero inoltre separare tre verifiche: se una query è valida, se rappresenta l'intento dell'utente e se l'utente può accedere ai suoi risultati.
Orca Security Discovery AI offre un caso di produzione significativo per questo approccio a livelli. I miglioramenti di efficienza riportati sono sostanziali, ma il suo contributo più profondo è un cambiamento nella progettazione dei sistemi.
La domanda ora è se Orca pubblicherà prove operative sufficienti a dimostrare che questa efficienza resiste a schemi in evoluzione e a usi avversariali. Tali prove determineranno se il modello diventerà uno standard più ampio per gli agenti aziendali.
