Notranjost OpenAI-jevega internega podatkovnega agenta

Podatki poganjajo učenje sistemov, razvoj produktov in sprejemanje odločitev v podjetjih. Vendar je pridobivanje odgovorov hitro, pravilno in v ustreznem kontekstu pogosto bistveno težje, kot bi moralo biti. Da bi to poenostavili ob rasti OpenAI-ja, smo zgradili lasten namenski interni podatkovni agent UI, ki raziskuje in sklepa nad lastno platformo.

Naš agent je orodje po meri, namenjeno izključno notranji uporabi (ne gre za zunanjo ponudbo), zgrajeno posebej glede na podatke OpenAI-ja, dovoljenja in delovne tokove. Prikazujemo, kako smo ga zgradili in uporabljamo, da bi izpostavili konkretne in dejansko vplivne načine, kako lahko UI podpira vsakodnevno delo v naših ekipah. Orodja OpenAI, ki smo jih uporabili za izgradnjo in delovanje (Codex, naš osrednji model GPT‑5, Evals API⁠(odpre se v novem oknu) in Embeddings API⁠(odpre se v novem oknu)), so ista orodja, ki jih omogočamo razvijalcem povsod.

Naš podatkovni agent zaposlenim omogoča, da od vprašanja do vpogleda pridejo v nekaj minutah, ne v dneh. S tem se zniža prag za pridobivanje podatkov in izvajanje niansiranih analiz v vseh funkcijah, ne le v podatkovni ekipi. Danes se ekipe na področjih Engineering, Data Science, Go-To-Market, Finance in Research pri OpenAI-ju zanašajo na agenta pri odgovarjanju na podatkovna vprašanja z velikim vplivom. Na primer, pomaga lahko pri ocenjevanju lansiranj in razumevanju poslovnega zdravja, vse prek intuitivne oblike naravnega jezika. Agent združuje znanje na ravni tabel, ki ga poganja Codex, s produktnim in organizacijskim kontekstom. Njegov sistem spomina, ki se nenehno uči, pomeni, da se izboljšuje z vsakim pogovornim korakom.

V tem prispevku bomo razčlenili, zakaj smo potrebovali namenski podatkovni agent UI, kaj dela njegov s kodo podprt podatkovni kontekst in samoučenje tako uporabna ter katere lekcije smo se pri tem naučili.

OpenAI-jeva podatkovna platforma služi več kot 3,5 tisoč internim uporabnikom , ki delajo na področjih inženiringa, produktov in raziskav, ter zajema več kot 600 petabajtov podatkov v 70 tisoč naborih podatkov. Pri takšnem obsegu je že samo iskanje prave tabele lahko eden najbolj časovno potratnih delov analize.

Kot je povedal eden od notranjih uporabnikov:

»Imamo veliko tabel, ki so si precej podobne, in porabim ogromno časa, da ugotovim, v čem se razlikujejo in katero uporabiti. Nekatere vključujejo odjavljene uporabnike, druge ne. Nekatere imajo prekrivajoča se polja; težko je razbrati, kaj je kaj.«

Tudi ko so izbrane prave tabele, je lahko ustvarjanje pravilnih rezultatov zahtevno. Analitiki morajo sklepati o tabelaričnih podatkih in razmerjih med tabelami, da zagotovijo pravilno uporabo transformacij in filtrov. Pogosti načini odpovedi, kot so povezave mnogo-proti-mnogo, napake pri potiskanju filtrov in neobravnavane ničelne vrednosti, lahko neopaženo izničijo veljavnost rezultatov. Pri obsegu OpenAI-ja analitiki ne bi smeli porabljati časa za razhroščevanje semantike SQL ali zmogljivosti poizvedb; njihov poudarek mora biti na opredeljevanju metrik, preverjanju predpostavk in sprejemanju odločitev na podlagi podatkov.

Poglejmo, kaj je naš agent, kako oblikuje kontekst in kako skrbi za samoučenje.

Našega agenta poganja GPT‑5.2 in je zasnovan za sklepanje na podatkovni platformi OpenAI. Na voljo je povsod, kjer zaposleni že delajo: kot agent v Slacku, prek spletnega vmesnika, znotraj IDE-jev, v Codex CLI prek MCP⁠(odpre se v novem oknu) in neposredno v OpenAI-jevi interni aplikaciji ChatGPT prek MCP priključka⁠(odpre se v novem oknu).

Uporabniki lahko postavljajo kompleksna, odprta vprašanja, ki bi sicer zahtevala več krogov ročnega raziskovanja. Vzemimo ta primer poziva, ki uporablja testni nabor podatkov: »Za vožnje taksijev v NYC, kateri pari poštnih številk prevzem–odložitev so najbolj nezanesljivi, z največjo razliko med tipičnimi in najslabšimi časi potovanja, in kdaj se ta variabilnost pojavi?«

Agent analizo izvede od začetka do konca, od razumevanja vprašanja do raziskovanja podatkov, izvajanja poizvedb in sinteze ugotovitev.

Ena ključnih prednosti agenta je način, kako razrešuje probleme. Namesto sledenja vnaprej določenemu skriptu agent ocenjuje lasten napredek. Če je vmesni rezultat videti napačen (npr. če ima nič vrstic zaradi nepravilne povezave ali filtra), agent razišče vzrok, prilagodi pristop in poskusi znova. V celotnem procesu ohranja poln kontekst in prenaša spoznanja med posameznimi koraki. Ta zaprtozančni, samoučeči se proces prenese iteracijo z uporabnika na agenta samega, kar omogoča hitrejše rezultate in dosledno višjo kakovost analiz kot pri ročnih delovnih tokovih.

Agent pokriva celoten analitični potek dela: od odkrivanja podatkov in izvajanja SQL do objave beležnic in poročil. Razume interno znanje podjetja, lahko izvaja spletno iskanje zunanjih informacij ter se sčasoma izboljšuje z uporabo in spominom.

Visokokakovostni odgovori so odvisni od bogatega, natančnega konteksta. Brez ustreznega konteksta lahko tudi zmogljivi modeli ustvarijo napačne rezultate, na primer bistveno napačno ocenijo število uporabnikov ali napačno razumejo interno terminologijo.

Da bi se izognili tem načinom odpovedi, je agent zasnovan okoli več plasti konteksta, ki ga trdno zasidrajo v podatke OpenAI-ja in institucionalno znanje.

• Utemeljevanje z metapodatki: agent se opira na metapodatke sheme (imena stolpcev in tipi podatkov), ki usmerjajo pisanje SQL, ter uporablja izvor in nadaljnjo uporabo tabel (npr. razmerja med nadrejenimi in podrejenimi tabelami), da zagotovi kontekst o tem, kako so posamezne tabele med seboj povezane.
• Sklepanje o poizvedbah: z vključevanjem zgodovinskih poizvedb agent razume, kako pisati lastne poizvedbe in katere tabele se običajno povezujejo.

• Kurirani opisi tabel in stolpcev, ki jih zagotovijo domenski strokovnjaki, zajemajo namen, semantiko, poslovni pomen in znane omejitve, ki jih iz samih shem ali preteklih poizvedb ni mogoče zanesljivo razbrati.Metapodatki sami po sebi niso dovolj.

Metapodatki sami po sebi niso dovolj. Za resnično razlikovanje med tabelami je treba razumeti, kako so nastale in od kod izvirajo.

• Z izpeljavo definicije tabele na ravni kode agent pridobi globlje razumevanje tega, kaj podatki dejansko vsebujejo. 
  • Niansirani vpogledi v to, kaj je shranjeno v tabeli in kako je to izpeljano iz analitičnega dogodka, zagotavljajo dodatne informacije. Na primer, agent lahko poda kontekst o edinstvenosti vrednosti, pogostosti posodabljanja podatkov v tabeli, obsegu podatkov (npr. ali tabela izključuje določena polja in kakšna je raven granulacije) itd.
• To zagotavlja razširjen kontekst uporabe s prikazom, kako se tabela uporablja zunaj SQL v Spark-u, Python-u in drugih podatkovnih sistemih.
• Posledično lahko agent razlikuje med tabelami, ki so na videz podobne, vendar se razlikujejo v ključnih lastnostih. Na primer, lahko ugotovi, ali tabela vključuje zgolj lastniški promet ChatGPT‑ja. Ta kontekst se samodejno osvežuje, zato ostaja posodobljen brez ročnega vzdrževanja.

• Agent lahko dostopa do Slack-a, Google Docs-a in Notion-a, ki zajemajo ključni kontekst podjetja, kot so lansiranja, incidenti na področju zanesljivosti, interne kodne oznake in orodja ter kanonične definicije in izračunska logika ključnih metrik.
• Ti dokumenti se vnašajo, vdelajo in shranjujejo skupaj z metapodatki in dovoljenji. Storitev za pridobivanje ob času izvajanja upravlja nadzor dostopa in predpomnjenje, kar agentu omogoča učinkovito in varno pridobivanje teh informacij.

• Ko agent prejme popravke ali zazna nianse pri določenih podatkovnih vprašanjih, lahko ta spoznanja shrani za prihodnjo uporabo, kar mu omogoča stalno izboljševanje skupaj z uporabniki. 
  • Posledično se prihodnji odgovori začnejo z natančnejšega izhodišča, namesto da bi se vedno znova soočali z istimi težavami.
  • Cilj spomina je ohraniti in ponovno uporabiti neočitne popravke, filtre in omejitve, ki so ključni za pravilnost podatkov, vendar jih iz drugih plasti ni mogoče zanesljivo razbrati. 
  • Na primer, v enem primeru agent ni vedel, kako filtrirati določen analitični eksperiment (zanašal se je na ujemanje z določenim nizom, opredeljenim v eksperimentalnem prehodu). V tem primeru je bil spomin ključen, saj je agentu omogočil pravilno filtriranje, namesto da bi se zanašal na približno ujemanje nizov.
• Ko agentu posredujete popravek ali ko iz pogovora izlušči novo spoznanje, vas bo pozval, ali naj ta spomin shrani za prihodnjo uporabo. 
  • Spomine lahko uporabniki tudi ročno ustvarjajo in urejajo.
  • Spomini so razmejeni na globalno in osebno raven, orodja agenta pa omogočajo njihovo enostavno urejanje.

• Kadar za tabelo ni predhodnega konteksta ali so obstoječe informacije zastarele, lahko agent izvede sprotne poizvedbe v podatkovno skladišče ter tabelo neposredno pregleda in poizveduje. To mu omogoča preverjanje shem, razumevanje podatkov v realnem času in ustrezen odziv.
• Agent se lahko po potrebi povezuje tudi z drugimi sistemi podatkovne platforme (storitev metapodatkov, Airflow, Spark), da pridobi širši podatkovni kontekst, ki obstaja zunaj podatkovnega skladišča.

Njegove evalvacije temeljijo na kuriranih naborih parov vprašanj in odgovorov. Vsako vprašanje cilja na pomembno metriko ali analitični vzorec, pri katerem je pravilnost bistvenega pomena, in je povezano z ročno pripravljenim »zlatim« poizvedbenim stavkom SQL, ki ustvari pričakovani rezultat. Za vsako evalvacijo naravnojezikovno vprašanje pošljemo na končno točko za generiranje poizvedb, izvedemo ustvarjeni SQL ter izhod primerjamo z rezultatom pričakovanega SQL.

Evalvacija se ne opira na naivno ujemanje nizov. Ustvarjeni SQL se lahko sintaktično razlikuje, a je kljub temu pravilen, nabori rezultatov pa lahko vključujejo dodatne stolpce, ki na odgovor vsebinsko ne vplivajo. Da bi to upoštevali, primerjamo tako SQL kot tudi nastale podatke, te signale pa posredujemo ocenjevalniku OpenAI Evals. Ocenjevalnik ustvari končno oceno skupaj z razlago, pri čemer zajame tako pravilnost kot tudi dopustna odstopanja.

Te evalvacije so podobne enotskim testom, ki se med razvojem neprekinjeno izvajajo, v produkciji pa služijo kot kanarčki za zaznavanje regresij; to nam omogoča, da težave ujamemo zgodaj in zanesljivo iteriramo, ko se zmogljivosti agenta širijo.

Naš agent se neposredno vklaplja v obstoječi varnostni model in model nadzora dostopa OpenAI-ja. Deluje izključno kot vmesniški sloj ter podeduje in uveljavlja enaka dovoljenja in varovalne mehanizme, ki urejajo podatke OpenAI-ja. 

Ves dostop agenta je strogo posredniški, kar pomeni, da lahko uporabniki poizvedujejo le po tabelah, do katerih že imajo dovoljen dostop. Kadar dostop manjka, agent to izpostavi ali pa uporabi nadomestne nabore podatkov, za katere je uporabnik pooblaščen.

Pa še to: izdelan je tudi za preglednost. Tako kot vsak drug sistem se lahko tudi zmoti. Svoj proces sklepanja razkrije tako, da ob vsakem odgovoru povzame predpostavke in korake izvajanja. Ko se poizvedbe izvedejo, se neposredno poveže na osnovne rezultate, kar uporabnikom omogoča pregled surovih podatkov in preverjanje vsakega koraka analize.

Razvoj našega agenta iz nič je razkril praktične lekcije o tem, kako se agenti vedejo, kje imajo težave in kaj jih pri velikem obsegu dejansko naredi zanesljive.

Na začetku smo agentu omogočili dostop do celotnega nabora orodij in hitro naleteli na težave zaradi prekrivajočih se funkcionalnosti. Čeprav je takšna redundanca lahko koristna v specifičnih prilagojenih primerih in je človeku očitnejša pri ročnem priklicu, agente zmede. Da bi zmanjšali dvoumnost in izboljšali zanesljivost, smo nekatere priklice orodij omejili in konsolidirali.

Ugotovili smo tudi, da zelo predpisujoče pozivanje poslabša rezultate. Čeprav si številna vprašanja delijo splošno analitično obliko, se podrobnosti dovolj razlikujejo, da toge usmeritve agenta pogosto potisnejo na napačne poti. Ko smo prešli na usmerjanje na višji ravni in se zanašali na sklepanje GPT‑5 pri izbiri ustrezne poti izvajanja, je agent postal robustnejši in je ustvarjal boljše rezultate.

Sheme in zgodovina poizvedb opisujejo obliko in rabo tabele, vendar njen pravi pomen živi v kodi, ki jo ustvarja. Logika cevovoda zajema predpostavke, zagotovila glede svežine podatkov in poslovni namen, ki se nikoli ne razkrijejo v SQL ali metapodatkih. S pregledovanjem izvorne kode s Codexom agent razume, kako so nabori podatkov dejansko konstruirani, in lahko zato natančneje sklepa o tem, kaj posamezna tabela v resnici vsebuje. Na vprašanji »kaj je v tej tabeli« in »kdaj jo lahko uporabim« odgovarja bistveno natančneje, kot bi to omogočali zgolj signali iz podatkovnega skladišča. 

Našega agenta nenehno izboljšujemo tako, da povečujemo njegovo zmožnost obravnave dvoumnih vprašanj, krepimo zanesljivost in natančnost z močnejšimi validacijami ter ga globlje integriramo v delovne tokove. Prepričani smo, da se mora naravno vključiti v obstoječe načine dela, namesto da bi deloval kot ločeno orodje.

Čeprav bodo naša orodja še naprej imela koristi od temeljnih izboljšav na področjih agentskega sklepanja, validacije in samopopravljanja, ostaja poslanstvo naše ekipe nespremenjeno: brezšivno zagotavljati hitro in zaupanja vredno analizo podatkov v celotnem podatkovnem ekosistemu OpenAI-ja.