Oracle zkrátil náborový průzkum o 98 %. Rozhodující byl workflow, ne samotný chatbot

Oracle uvádí 130 000 aktivních uživatelů ChatGPT a přes 95 000 uživatelů Codexu. Náborový průzkum zkrátil z dvou až čtyř dnů na 15 až 20 minut, protože obecný model napojil na konkrétní firemní data a postupy.

Náboráři stáhli několik dnů rešerší na 20 minut

Podle případové studie OpenAI používá náborový tým ChatGPT Work k analýze pracovních popisů, srovnatelných pozic, odměňování a dostupnosti lidí v různých lokalitách. Oracle říká, že tento postup zkrátil čas potřebný na průzkum o 98 %.

Oracle Applications Lab zase vytvořila ontologii firemních objektů, vztahů a pravidel. Codex díky ní převádí běžně formulovaný dotaz na SQL, volá potřebné interní systémy a vrací analýzu, report nebo aplikaci. U jednoduchých provozních incidentů mají site reliability engineers stáhnout práci z přibližně hodiny na několik minut.

Primární stránka OpenAI byla při automatickém ověření blokovaná. Čísla a popis workflow proto opatrně přebírám z jejího indexovaného výňatku a ze zpráv, které případovou studii citují, nikoli z nezávislého auditu.

Výsledek stojí na převodu expertizy do opakovatelného postupu

Velké počty licencí jsou vedlejší údaj. Podstatné je, že Oracle vložil znalosti specialistů do workflow, které ví, na jaká data sáhnout, jaká pravidla dodržet a v jakém tvaru vrátit výsledek. Model se tak nemusí pokaždé spoléhat na improvizaci uživatele.

Pro enterprise týmy je to praktičtější vzor než plošné školení promptů. Nejdřív je potřeba vybrat úzkou a častou práci, popsat její vstupy a kontroly a teprve potom nad ní pustit ChatGPT nebo Codex. Rychlost vzniká hlavně z připraveného kontextu.

Případovou studii dodal prodejce a chybí jí nezávislá kontrola

Uvedené úspory pocházejí od Oracle v materiálu OpenAI. Zveřejněný popis neříká, kolik výstupů lidé opravují, jak se měří kvalita napříč týmy ani kolik stála integrace a údržba ontologie. Oracle zároveň zdůrazňuje, že architektura, bezpečnost a udržovatelný kód zůstávají odpovědností lidí.

To je důležitá hranice. Převod dotazu na SQL může ušetřit čas, ale spolehlivost stojí na oprávněních, datových definicích, logování a kontrole výsledku. Rychlá odpověď se chybným číslem by jen urychlila špatné rozhodnutí.

O kvalitě rozhodnou opravy, incidenty a náklady po nasazení

Další užitečná čísla budou míra lidských oprav, chybovost dotazů, čas u složitých incidentů a celkové náklady na jeden dokončený workflow. Bez nich známe rychlost vybraných ukázek, ale ne jejich provozní cenu.

Druhou zkouškou je přenositelnost. Pokud další týmy dokážou stejný vzor nasadit bez měsíců ručního modelování dat, Oracle ukáže skutečně opakovatelnou enterprise disciplínu, ne jen několik dobře vybraných případů.

Lilithin verdikt

Oracle nevyhrál počtem licencí, ale náborářem, který jde na stejnou schůzku připravený za 20 minut místo čtyř dnů. Teď ještě potřebujeme vidět účet za integraci a hromadu oprav, kterou případová studie nechala za dveřmi.