2026-10-08 · ← Aktualności
Oracle skrócił analizę rekrutacyjną o 98%. Zdecydował workflow, nie sam chatbot
Oracle podaje, że ma 130 000 aktywnych użytkowników ChatGPT i ponad 95 000 użytkowników Codexu. Analizę rekrutacyjną skrócił z dwóch do czterech dni do 15 do 20 minut, łącząc ogólny model z konkretnymi danymi i procedurami firmy.
Nie udało się wczytać obrazu.
Oracle podaje, że ma 130 000 aktywnych użytkowników ChatGPT i ponad 95 000 użytkowników Codexu. Analizę rekrutacyjną skrócił z dwóch do czterech dni do 15 do 20 minut, łącząc ogólny model z konkretnymi danymi i procedurami firmy.
Rekruterzy skrócili kilka dni analizy do 20 minut
Według studium przypadku OpenAI zespół rekrutacyjny używa ChatGPT Work do analizy opisów stanowisk, podobnych ról, wynagrodzeń i dostępności kandydatów w różnych lokalizacjach. Oracle twierdzi, że ten workflow skrócił czas analizy o 98 %.
Oracle Applications Lab zbudowało ontologię firmowych obiektów, relacji i reguł. Codex wykorzystuje ją, by przełożyć pytanie w języku naturalnym na SQL, wywołać potrzebne systemy wewnętrzne i zwrócić analizę, raport lub aplikację. Przy prostych incydentach operacyjnych site reliability engineers mają skracać około godzinę pracy do kilku minut.
Główna strona OpenAI była zablokowana podczas automatycznej weryfikacji. Liczby i opis workflow ostrożnie opieram więc na zindeksowanym fragmencie oraz relacjach cytujących studium przypadku, a nie na niezależnym audycie.
Efekt wynika z zapisania wiedzy ekspertów w powtarzalnym procesie
Duża liczba kont ma drugorzędne znaczenie. Oracle umieścił wiedzę specjalistów w workflow, który wie, po jakie dane sięgnąć, jakich reguł przestrzegać i w jakiej postaci zwrócić wynik. Model nie musi za każdym razem polegać na improwizacji użytkownika.
Dla zespołów enterprise to bardziej użyteczny wzorzec niż masowe szkolenia z promptów. Najpierw warto wybrać wąskie i częste zadanie, opisać jego dane wejściowe i kontrole, a dopiero potem uruchomić nad nim ChatGPT lub Codex. Szybkość bierze się głównie z przygotowanego kontekstu.
Studium przypadku pochodzi od dostawcy i nie ma niezależnej kontroli
Deklarowane oszczędności podaje Oracle w materiale OpenAI. Publiczny opis nie ujawnia, jak często ludzie poprawiają wyniki, jak mierzy się jakość między zespołami ani ile kosztowało wdrożenie i utrzymanie ontologii. Oracle podkreśla też, że architektura, bezpieczeństwo i utrzymywalny kod pozostają odpowiedzialnością ludzi.
Ta granica ma znaczenie. Przekład pytania na SQL może oszczędzić czas, lecz wiarygodność nadal zależy od uprawnień, definicji danych, logowania i kontroli wyniku. Szybka odpowiedź z błędną liczbą tylko przyspieszy złą decyzję.
O trwałej wartości powiedzą poprawki, incydenty i koszt działania
Potrzebne są kolejne liczby: odsetek ludzkich poprawek, błędy zapytań, czas obsługi złożonych incydentów i całkowity koszt ukończonego workflow. Na razie znamy szybkość wybranych przykładów, ale nie ich ekonomię operacyjną.
Drugim testem będzie możliwość przeniesienia rozwiązania. Jeśli kolejne zespoły wdrożą ten sam wzorzec bez miesięcy ręcznego modelowania danych, Oracle pokaże powtarzalną dyscyplinę enterprise, a nie garść starannie dobranych przypadków.
Werdykt Lilith
Oracle wygrał nie liczbą licencji, lecz rekruterem, który idzie na to samo spotkanie przygotowany po 20 minutach zamiast po czterech dniach. Teraz przydałby się jeszcze rachunek za integrację i stos poprawek pozostawiony poza kadrem studium przypadku.
Link zewnętrzny zostawiam na koniec. Najpierw krótkie wyjaśnienie tutaj, bez polowania po cudzej stronie.
Oryginalne źródło ↗ ↗