Orca Security Discovery AI obniża koszt zapytań bezpieczeństwa w języku naturalnym

Orca Security Discovery AI przekształca teraz pytania dotyczące bezpieczeństwa zadawane prostym angielskim w zapytania Sonar, wykorzystując o 93% mniej tokenów wejściowych niż w pierwotnym projekcie. Orca podaje również, że po przebudowie systemu na Amazon Bedrock koszty zapytań spadły o 90%, a opóźnienie o 75%.

Liczby te opisują więcej niż rutynową modernizację modelu. Orca zastąpiła jeden ogromny prompt dziewięcioetapowym procesem, który decyduje, kiedy każde żądanie powinny obsłużyć reguły, wyszukiwanie, mniejsze modele lub bardziej pogłębione rozumowanie.

Wynik ten podważa powszechną strategię korporacyjnej AI: umieszczanie każdego schematu, przykładu i instrukcji w jednym dużym oknie kontekstowym. Doświadczenia Orca sugerują, że większy kontekst może zwiększać koszty, a jednocześnie osłabiać trafność i spowalniać aplikację.

Alternatywne podejście traktuje model językowy jako jeden z komponentów kontrolowanego kompilatora zapytań. Deterministyczne dopasowywanie obsługuje oczywiste dane wejściowe, wyszukiwanie dostarcza sprawdzone przykłady, a walidacja kontroluje wygenerowane filtry przed ich zwróceniem.

Ten projekt ma znaczenie, ponieważ zapytania bezpieczeństwa w języku naturalnym działają na wrażliwych i silnie ustrukturyzowanych informacjach. Płynna odpowiedź ma niewielką wartość, gdy wygenerowany filtr wskazuje niewłaściwy zasób, przekracza granicę uprawnień lub pomija krytyczny warunek.

Orca zastąpiła jeden ogromny prompt procesem produkcyjnym

Najważniejsza zmiana miała charakter architektoniczny: Orca przestała prosić jeden model o zrozumienie całego schematu bezpieczeństwa przy każdym żądaniu.

System zapytań Sonar firmy Orca obejmuje ponad 900 modeli infrastruktury chmurowej i aplikacji. Modele te reprezentują zasoby takie jak instancje obliczeniowe, kontenery pamięci masowej, tożsamości, podatności oraz relacje, które je łączą.

Przed Discovery AI użytkownicy musieli tworzyć precyzyjne filtry JSON. Musieli też znać dokładne nazwy modeli, poruszać się po zagnieżdżonych relacjach i wybierać spośród 18 operatorów filtrowania.

Wymóg ten tworzył barierę użyteczności dla analityków, którzy rozumieli pytanie dotyczące bezpieczeństwa, ale nie znali pełnego schematu Sonar. Orca stworzyła więc interfejs języka naturalnego, który przekształca żądanie analityka w prawidłowy filtr.

Pierwszy proof of concept wykorzystywał najbardziej bezpośrednie podejście generatywnej AI. Orca umieściła w jednym prompcie dla dużego modelu ponad 900 definicji modeli, typów relacji i przykładowych zapytań.

Według firmy partnerzy projektowi i użytkownicy wewnętrzni byli zadowoleni z jakości wyników. Projekt zużywał jednak około 2 milionów tokenów wejściowych dla porównywalnego obciążenia i zajmował około 60 sekund.

Złożone żądania ujawniły również ograniczenia dokładności. Pytania obejmujące kilka modeli zasobów, zagnieżdżone relacje lub wiele warunków często wymagały dodatkowego dopracowania.

Orca i AWS opracowały następnie produkcyjny dziewięcioetapowy proces. Według doniesień od marca 2026 roku obsługuje on tysiące zapytań dziennie, a czas odpowiedzi wynosi około 15 sekund.

Proces rozpoczyna się od połączenia żądania z kontekstem organizacyjnym. Kontekst ten może obejmować połączonych dostawców chmury, metadane żądania oraz szczegóły potrzebne do interpretacji środowiska użytkownika.

Następnie deterministyczny mechanizm dopasowywania wyszukuje ustrukturyzowane identyfikatory. Obejmują one adresy IP, identyfikatory CVE, hashe plików, nazwy zasobów, adresy URL i identyfikatory alertów.

Dopasowany identyfikator może uruchomić wstępnie zdefiniowany filtr bez kosztownego wywołania modelu. Ta szybka ścieżka utrzymuje przewidywalne zadania z dala od systemu probabilistycznego.

Żądania wymagające interpretacji przechodzą przez mechanizm ochronny. Orca twierdzi, że ten etap blokuje próby prompt injection, nieistotne pytania i nieobsługiwane dane wejściowe, zanim dotrą one do generowania zapytań.

System następnie przeszukuje bibliotekę zwalidowanych przykładów. Osadzenia Amazon Titan pobierają 20 semantycznie podobnych kandydatów, a Cohere Rerank 3.5 redukuje ten zbiór do pięciu.

Selektor modeli zawęża ponad 900 modeli Sonar do tych istotnych dla bieżącego żądania. Generator otrzymuje szczegółowe schematy wyłącznie dla tej mniejszej grupy oraz ich relacji.

Anthropic Claude Haiku 4.5 obsługuje etapy selekcji i generowania. Amazon Nova 2 Lite realizuje zadania ochronne i walidacyjne, w których Orca priorytetowo traktuje szybsze i tańsze wnioskowanie.

Wygenerowany filtr nadal nie staje się automatycznie wynikiem końcowym. Kontrole statyczne rozwiązują każdy model, pole i operator względem wybranych schematów.

Orca sprawdza również filtr względem API Sonar. Gdy walidacja się nie powiedzie, błąd wskazuje problematyczny element i zwraca go generatorowi do poprawy.

Ta pętla przekształca generowanie w proces ograniczony regułami. Model może zaproponować filtr, ale systemy deterministyczne decydują, czy propozycja jest zgodna z dostępnym schematem.

Orca Security Discovery AI celowo zmniejsza kontekst

Orca Security Discovery AI poprawiła raportowaną efektywność ekonomiczną dzięki selekcji kontekstu, a nie jego rozszerzaniu.

Początkowy prototyp traktował pełny schemat Sonar jako obowiązkowy kontekst. Wybór ten wydawał się uzasadniony, ponieważ model musiał rozumieć setki typów zasobów i relacje między nimi.

Problem polegał na tym, że większość pytań dotyczyła tylko niewielkiej części tego schematu. Wysyłanie każdej definicji przy każdym żądaniu zwiększało użycie tokenów, nie czyniąc każdej definicji użyteczną.

Selektor modeli Orca działa teraz na podstawie zwięzłych opisów dostępnych modeli. Każdy opis podsumowuje nazwę modelu, jego przeznaczenie, ważne pola i ważne relacje.

Selektor identyfikuje modele wymagane przez pytanie. Generator otrzymuje następnie pełny schemat wyłącznie dla tych wyborów, wraz z relacjami potrzebnymi do ich połączenia.

Zmiana ta zmniejszyła raportowane użycie danych wejściowych z około 2 milionów tokenów do 140 000 dla porównywalnego obciążenia. Odpowiada to deklarowanej redukcji o 93%.

Orca przypisuje 90-procentową redukcję kosztów mniejszej liczbie tokenów i przydzielaniu modeli do poszczególnych etapów. Różne zadania nie korzystają już domyślnie z największego dostępnego modelu.

Według doniesień opóźnienie spadło z około 60 sekund do 15 sekund, czyli o 75%. Szybsza ścieżka nadal obejmuje wiele etapów, co pokazuje, że sama liczba etapów nie determinuje czasu odpowiedzi.

Jedno długie wnioskowanie może być wolniejsze niż kilka wąsko ukierunkowanych operacji. Reguły i wyszukiwanie mogą również pominąć generowanie, gdy system rozpozna znany wzorzec.

To podstawowy mechanizm stojący za raportowanymi korzyściami. Orca zmniejszyła ilość materiału wymagającego pogłębionego rozumowania, a następnie zarezerwowała pracę generatywną dla nierozstrzygniętych części żądania.

Projekt wyszukiwania opiera się na tej samej zasadzie. Czyste semantyczne wyszukiwanie top-K było szybkie, ale Orca stwierdziła, że często zwracało niemal zduplikowane przykłady.

Duplikaty zajmowały kontekst, nie zwiększając znacząco zakresu pokrycia. Maximal Marginal Relevance zwiększało różnorodność, lecz czasem przesuwało najbardziej trafny przykład poza czołową pozycję.

Orca zdecydowała się na pobieranie 20 pobliskich przykładów i ponowne rankingowanie ich do pięciu. Szersze pierwsze przejście kładzie nacisk na kompletność, podczas gdy ponowne rankingowanie koncentruje końcowy kontekst na silniejszych dopasowaniach.

Dopasowanie o wysokiej pewności może bezpośrednio ponownie wykorzystać sprawdzony filtr. W przeciwnym razie pięć przykładów pokazuje generatorowi, jak wcześniej przetłumaczono zwalidowane pytania.

To podejście bardziej przypomina rozumowanie oparte na przypadkach niż nieograniczone generowanie. Model pracuje na zwięzłym schemacie i przykładach pochodzących z udanego historycznego działania.

Architektura pozwala też na wymienność wyborów modeli. Amazon Bedrock zapewnia dostęp do kilku rodzin modeli przez wspólną warstwę usługową, ograniczając oddzielną pracę integracyjną.

Ta elastyczność ma znaczenie, ponieważ najszybszy lub najdokładniejszy model dla danego etapu może się zmieniać. Orca może podobno zastąpić model danego etapu bez przeprojektowywania całej aplikacji.

Szersza lekcja nie polega na tym, że każdy system potrzebuje dziewięciu kroków. Chodzi o to, że kontekst powinien zasłużyć na swoje miejsce w prompcie produkcyjnym.

Schematy, przykłady i historia rozmowy generują koszty, nawet gdy model obsługuje duże okno kontekstowe. Nieistotny materiał może również konkurować z dowodami, które mają znaczenie.

Zapytania bezpieczeństwa w języku naturalnym nadal potrzebują twardych granic

Interfejs konwersacyjny zmniejsza trudności związane z językiem zapytań, ale nie może zastąpić autoryzacji, walidacji ani wiedzy eksperckiej z zakresu bezpieczeństwa.

Zapytania bezpieczeństwa w języku naturalnym mogą pomóc analitykowi przejść od pomysłu na dochodzenie do ustrukturyzowanego filtra. Nie gwarantują, że samo pytanie jest autoryzowane lub kompletne.

Proces Orca obejmuje kontekst żądania, kontrolę ochronną, generowanie ograniczone regułami i dwie formy walidacji. Ta sekwencja uznaje ryzyko traktowania wyników modelu jako wykonywalnej prawdy.

Mechanizm oceny zabezpieczeń Amazon Bedrock może sprawdzać prompty i odpowiedzi względem skonfigurowanych polityk. Dostępne mechanizmy kontroli obejmują filtry treści, zabronione tematy, filtry informacji wrażliwych i wykrywanie ataków na prompty.

Mechanizm ochronny nie jest jednak systemem autoryzacji. Może klasyfikować dane wejściowe, jednocześnie nie dysponując tożsamością użytkownika i uprawnieniami do zasobów potrzebnymi do podjęcia decyzji o dostępie.

Wskazówki AWS dotyczące bezpieczeństwa wyraźnie rozróżniają te kwestie. Ich mechanizmy kontroli autoryzacji zalecają egzekwowanie dostępu do danych poza modelem językowym oraz propagowanie tożsamości użytkownika przez połączone systemy.

To rozdzielenie jest szczególnie istotne w przypadku danych bezpieczeństwa chmurowego. Zapytanie może ujawniać nazwy zasobów, podatności, relacje między kontami, ścieżki sieciowe lub wewnętrzne szczegóły konfiguracji.

Asystent z szerokim dostępem do systemów zaplecza może stać się zdezorientowanym zastępcą. Dzieje się tak, gdy użytkownik o niższych uprawnieniach uzyskuje informacje za pośrednictwem pośrednika o wyższych uprawnieniach.

Bezpieczna architektura musi ograniczać dane docierające do modelu. Musi również zapewniać, że wynikowe zapytanie Sonar jest wykonywane z uprawnieniami odpowiednimi dla użytkownika składającego żądanie.

Opublikowana architektura wskazuje, że Orca łączy żądania z kontekstem organizacyjnym i kontekstem dostawców chmury. Wpis nie przedstawia szczegółowego opisu izolacji tenantów ani egzekwowania autoryzacji na poziomie użytkownika.

To pominięcie nie dowodzi słabości. Oznacza jedynie, że raportowanych wyników wydajności nie należy odczytywać jako pełnej oceny bezpieczeństwa.

Walidacja tworzy kolejną ważną granicę. Orca najpierw sprawdza składnię, a następnie weryfikuje wygenerowany filtr przez swoje API Sonar.

Gdy kontrola się nie powiedzie, generator otrzymuje ustrukturyzowane błędy. Może poprawić określone pole, operator lub relację zamiast zaczynać kolejną nieograniczoną próbę.

Podejście to zmniejsza jedną klasę halucynacji: odwołania do elementów schematu, które nie istnieją. Nie dowodzi jednak, że każde prawidłowe zapytanie dokładnie oddaje intencję analityka.

Filtr może być poprawny składniowo, a jednocześnie niekompletny semantycznie. Może wybierać właściwy model, ale pomijać wyjątek, relację, granicę czasową lub warunek środowiskowy.

Problem staje się poważniejszy, gdy zwięzłe żądanie ukrywa niejednoznaczność. „Pokaż wystawione bazy danych” może zależeć od definicji ekspozycji, typu bazy danych, osiągalności sieciowej i akceptowanego ryzyka.

Silny interfejs powinien ujawniać założenia lub pokazywać wygenerowany filtr do weryfikacji. Wpis AWS koncentruje się na generowaniu i walidacji filtrów, a nie na pełnym doświadczeniu przeglądu.

Zespoły bezpieczeństwa powinny zatem odróżniać poprawność zapytania od poprawności dochodzenia. Pierwszą można automatycznie zweryfikować względem schematów, podczas gdy druga często wymaga oceny eksperckiej.

Na uwagę zasługują również deterministyczne ścieżki wyjścia systemu. Ponowne wykorzystanie zweryfikowanego przykładu może skrócić opóźnienia, lecz próg dopasowania musi zapobiegać sytuacji, w której powierzchownie podobne pytania korzystają z nieodpowiedniego filtra.

Orca twierdzi, że kieruje zapytania o niskiej pewności do ekspertów dziedzinowych. Ten proces informacji zwrotnej jest pomocny, choć jego skuteczność zależy od próbkowania, zakresu przeglądu i jakości korekt.

Dostęp za pomocą języka naturalnego może poszerzyć udział w dochodzeniach bezpieczeństwa. Przenosi jednak odpowiedzialność z autorów zapytań na projektantów platformy, którzy wdrażają te zabezpieczenia.

Prawdziwym przeciwnikiem jest projekt „jeden model, jeden prompt”

Najważniejszym punktem odniesienia dla Orca nie jest inny dostawca, lecz monolityczny prototyp, który zastąpiła.

Produkty generatywnej AI często zaczynają jako prompt podłączony do wydajnego modelu. Taka struktura dobrze sprawdza się przy weryfikowaniu, czy model rozumie dane zadanie.

Trudniej jej bronić, gdy aplikacja musi obsłużyć rzeczywisty ruch, zmieniające się schematy, rygorystyczne wymagania dotyczące opóźnień i wrażliwe dane organizacyjne.

Pierwotne rozwiązanie Orca ujawniło tę zmianę. Prototyp generował obiecujące odpowiedzi, ale przesyłał ogromny schemat z każdym żądaniem i nadal miał trudności ze złożonymi relacjami.

System produkcyjny przenosi kilka obowiązków poza generator. Wyrażenia regularne rozpoznają dokładne identyfikatory, wyszukiwanie odnajduje przykłady, reranking ogranicza szum, a walidatory odrzucają błędnie sformułowane filtry.

Ten podział prowadzi do istotnego odwrócenia sytuacji. Dodanie komponentów obniżyło całkowity koszt i opóźnienia, ponieważ zapobiegały one niepotrzebnej pracy generatywnej.

Pipeline podważa również podejście do zakupów skoncentrowane na modelu. Wybór największego modelu sam w sobie nie rozwiązał problemu produkcyjnego.

Orca przypisała natomiast modele zgodnie z wymaganiami poszczególnych zadań. Etapy wymagające intensywnego rozumowania otrzymały Claude Haiku 4.5, podczas gdy węższe etapy selekcji i walidacji powierzono Nova 2 Lite.

Amazon Titan tworzył embeddingi na potrzeby wyszukiwania semantycznego. Cohere Rerank 3.5 oceniał odzyskane przykłady przed generowaniem.

Taka mieszanka tworzy złożoność operacyjną. Zespoły muszą monitorować kilka modeli, działanie mechanizmu wyszukiwania, pętle walidacji i zależności zamiast jednego wywołania API.

Jednak architektura oparta na pojedynczym wywołaniu ukrywa złożoność wewnątrz dużego promptu. Nie eliminuje zarządzania schematami, ewaluacji, autoryzacji ani obsługi błędów.

Wcześniejsze prace AWS nad dochodzeniami w języku naturalnym pokazały podobny wzorzec dla Amazon Security Lake. Agent tłumaczył pytania analityków na SQL i wspierał dalszą analizę logów bezpieczeństwa.

Implementacja Orca jest skierowana do własnego grafu danych Sonar i filtrów specyficznych dla domeny. Jej cechą wyróżniającą jest agresywne ograniczanie schematów i przykładów przed generowaniem.

Ten wzorzec można zastosować poza bezpieczeństwem chmurowym. Systemy korporacyjne często udostępniają setki obiektów, pól, relacji i dozwolonych operacji.

Platformy obsługi klienta, narzędzia analityczne, portale dla deweloperów i systemy wiedzy mierzą się z tą samą pokusą, by umieścić każdą definicję w prompcie. Podejście to może sprawdzać się podczas prezentacji, a zawodzić w realiach ekonomiki produkcyjnej.

Alternatywa przypomina pipeline kompilatora. System analizuje żądanie, identyfikuje istotne struktury, wyszukuje precedensy, generuje reprezentację pośrednią i ją waliduje.

Model językowy obsługuje niejednoznaczność i tłumaczenie. Deterministyczne komponenty obsługują egzekwowalne reguły.

Taki podział ułatwia również zlokalizowanie awarii. Zespół może ustalić, czy wyszukiwanie pominęło istotny przykład, selekcja pominęła schemat, czy walidacja odrzuciła operator.

Pojedynczy prompt często generuje mniej użyteczny sygnał błędu. Odpowiedź jest po prostu błędna, kosztowna, wolna lub stanowi kombinację wszystkich tych problemów.

Orca twierdzi, że jej mechanizm ewaluacji mierzy poprawność, kompletność i równoważność semantyczną względem zapytań referencyjnych. Dzieli również wyniki na segmenty oparte na kategoriach pytań i modeli.

To dostarcza więcej informacji niż jeden zagregowany wynik. System może ogólnie działać dobrze, a jednocześnie zawodzić przy rzadkich relacjach wielochmurowych lub złożonych warunkach dotyczących podatności.

Projekt wywiera presję na inne zespoły korporacyjnej AI, by raportowały wyniki na poziomie systemu. Same wyniki benchmarków modeli nie wyjaśniają opóźnień aplikacji, jakości wyszukiwania, wskaźników walidacji ani nakładu pracy na korekty.

Liczby są mocne, ale dowody dotyczące dokładności są niepełne

Poprawa kosztów i opóźnień została opisana konkretnie, podczas gdy publiczna deklaracja dotycząca dokładności nie ma porównywalnego poziomu szczegółowości pomiarów.

AWS i Orca przedstawiają jasne wartości „przed i po” dla tokenów, kosztów i czasu odpowiedzi. Nie publikują jednak zbioru danych ewaluacyjnych, wielkości próby, wskaźnika zaliczeń ani dokładnej poprawy dokładności.

Wpis podaje, że dokładność poprawiła się dla złożonych zapytań obejmujących wiele modeli. Opisuje również system LLM-as-a-judge, który ocenia poprawność, kompletność i równoważność semantyczną.

LLM-as-a-judge wykorzystuje inny model do oceny wygenerowanych wyników. Może wspierać szybkie iteracje, ale jego wnioski zależą od rubryki oceny, odpowiedzi referencyjnych i wiarygodności sędziego.

Orca uzupełnia automatyczne ocenianie specjalistami wewnętrznymi i opiniami klientów. Menedżerowie produktu, inżynierowie wsparcia i badacze bezpieczeństwa mogą oznaczać wyniki oraz dodawać poprawione przykłady.

Zapytania produkcyjne o niskiej pewności mają podobno trafiać do codziennej kolejki oznaczania. Korekty stają się dostępne dla kolejnych procesów wyszukiwania bez konieczności wdrażania oprogramowania.

Dyrektor AI Orca, Or Gabay, nazwał ten interfejs oznaczania najważniejszą długoterminową inwestycją zespołu w jakość. To stwierdzenie podkreśla proces z udziałem ludzi, a nie kolejną aktualizację modelu.

Proces ten jest wiarygodnym mechanizmem poprawy. Nadal pozostawia jednak kilka pytań bez odpowiedzi dla zewnętrznych nabywców i zespołów inżynieryjnych.

Publiczny wpis nie ujawnia, jak często generowanie osiąga limit ponownych prób. Nie podaje też, ile żądań trafia na ścieżki deterministyczne lub ponownego wykorzystania przykładów.

Nie rozdziela również mediany opóźnień od opóźnień w ogonie rozkładu. Wynik 15 sekund może opisywać typowe obciążenie, jednocześnie ukrywając wolniejsze, złożone żądania.

Określenie „porównywalne obciążenie” wymaga dokładniejszego zdefiniowania. Redukcja tokenów i kosztów zależy od mieszanki żądań, wybranych modeli, zachowania cache, długości wyników i liczby ponownych prób.

Raportowana redukcja kosztów porównuje też pipeline produkcyjny z własnym pierwotnym punktem odniesienia Orca. Nie jest benchmarkiem wobec innych produktów bezpieczeństwa chmurowego ani systemów generowania zapytań.

Czytelnicy powinni traktować te procenty jako zgłoszone przez firmę wyniki operacyjne. Współautorskie studium przypadku AWS zawiera szczegóły techniczne, ale nie jest niezależnym audytem.

Data wdrożenia produkcyjnego w marcu 2026 roku i tysiące codziennych zapytań stanowią użyteczny sygnał adopcji. Nie ujawniają jednak liczby unikalnych użytkowników, wskaźników akceptacji, rezygnacji ani oszczędzonego czasu analityków.

Te wskaźniki pomogłyby ustalić, czy język naturalny zmienia sposób prowadzenia dochodzeń. Niższe koszty inferencji mają znaczenie, ale wartość dla użytkownika ostatecznie zależy od lepszych i szybszych decyzji dotyczących bezpieczeństwa.

Pętla informacji zwrotnej systemu wprowadza kolejny kompromis. Przykłady produkcyjne poprawiają pokrycie, lecz korekty mogą zakodować niespójne interpretacje, jeśli eksperci nie stosują wspólnej polityki.

Rosnący bank przykładów również wymaga nadzoru. Zespoły potrzebują wersjonowania, kontroli jakości, procedur usuwania oraz ochrony przed trafianiem wrażliwych informacji do odzyskiwanych przykładów.

Wskazówki AWS dotyczące aplikacji generatywnej AI zalecają ograniczanie odzyskiwanych danych, zanim trafią one do modelu. Ich mechanizmy kontroli bezpieczeństwa podkreślają propagację tożsamości i egzekwowanie dostępu na warstwie danych.

Te kwestie nie podważają wyników Orca. Określają dowody wymagane, zanim inna organizacja potraktuje tę architekturę jako szablon nadający się do ponownego użycia.

Najmocniejszy publiczny wniosek jest wąski, ale użyteczny. Orca podaje, że selekcja kontekstu, specjalizacja modeli, wyszukiwanie i walidacja radykalnie poprawiły jej pierwotny projekt.

Dowody nie ustanawiają uniwersalnej redukcji dla każdego agenta intensywnie wykorzystującego schematy. Zespoły muszą zmierzyć ten wzorzec względem własnych obciążeń i wymagań autoryzacyjnych.

Na co zwracać uwagę po wdrożeniu Orca w Amazon Bedrock

Kolejnym testem będzie to, czy Orca zdoła utrzymać jakość, gdy schematy, zachowania użytkowników i wersje modeli będą nadal się zmieniać.

Pierwszym sygnałem będą opublikowane szczegóły dotyczące dokładności. Przyszły raport techniczny powinien ujawnić wielkość zbioru danych, kategorie zapytań, progi zaliczenia i zgodność z oceną dokonywaną przez ludzi.

Wyniki na poziomie segmentów byłyby szczególnie wartościowe. Zapytania dotyczące relacji między wieloma modelami wydają się najtrudniejszą kategorią i najsilniejszym testem architektury Orca.

Bardziej przejrzysta ewaluacja wzmocniłaby twierdzenie, że nowy projekt poprawił dokładność, a nie tylko wydajność. Rosnące wskaźniki korekt lub ponownych prób osłabiłyby ten wniosek.

Drugim sygnałem będzie trwała adopcja produkcyjna. Orca twierdzi, że Discovery AI obsługuje tysiące zapytań dziennie, ale długoterminowe wzorce użytkowania pokażą, czy analitycy ufają temu interfejsowi.

Przydatne wskaźniki obejmują powtarzalne użycie, zaakceptowane filtry, ręczne edycje, zaoszczędzony czas i odsetek pytań rozwiązanych bez eskalacji. Miary te łączą zachowanie modelu z operacjami bezpieczeństwa.

Trzecim sygnałem będzie sposób, w jaki pipeline radzi sobie ze zmianą. Schematy Sonar będą ewoluować, klienci będą zadawać nieznane pytania, a modele bazowe otrzymają nowe wersje.

Niezależny od modelu projekt Orca powinien ułatwiać zastępowanie komponentów. Każda zmiana nadal wymaga jednak testów regresji w obszarach wyszukiwania, generowania, walidacji i granic autoryzacji.

Ciągły mechanizm ewaluacji jest zatem równie ważny jak architektura początkowa. Każdy prompt, model, ustawienie wyszukiwania i przykład mogą zmieniać zachowanie w nieoczekiwanych segmentach.

System musi również pozostać użyteczny wobec zmieniającego się zachowania zagrożeń. Analitycy mogą mapować dochodzenia na framework zagrożeń chmurowych, podczas gdy atakujący przyjmują nowe ścieżki i kombinacje zasobów.

Statyczna biblioteka przykładów degradowałaby się w takich warunkach. Pętla eksperckiego oznaczania Orca ma utrzymywać bank wyszukiwania w zgodzie z pojawiającymi się pytaniami.

Dla zespołów inżynieryjnych bezpośrednim działaniem jest sprawdzenie, gdzie duże prompty zawierają materiał, którego większość żądań nigdy nie wykorzystuje. Materiał ten może należeć do warstwy selekcji, wyszukiwania lub routingu deterministycznego.

Zespoły powinny także rozdzielić trzy testy: czy zapytanie jest prawidłowe, czy odzwierciedla intencję użytkownika oraz czy użytkownik może uzyskać dostęp do jego wyników.

Orca Security Discovery AI oferuje istotny przypadek produkcyjny takiego warstwowego podejścia. Raportowane zyski wydajności są znaczące, lecz jego głębszym wkładem jest zmiana w projektowaniu systemów.

Pytanie brzmi teraz, czy Orca opublikuje wystarczająco dużo dowodów operacyjnych, aby pokazać, że ta wydajność utrzymuje się przy ewoluujących schematach i wrogim użyciu. To właśnie te dowody przesądzą, czy wzorzec stanie się szerszym standardem dla agentów korporacyjnych.