Az Uber a valódi felhasználói hibákból tanítja jobb működésre AI-ügynökeit

Egy pizza miatt derült ki a probléma

Az Arize Observe 2026 rendezvényén Aayush Agrawal, az Uber vezető AI-termékmenedzsere egy olyan esetről beszélt, amely jól megmutatta az ügynökök értékelésének nehézségeit. Egy anya az Uber hangalapú ügynökétől fuvart kért a San Francisco International Airport repülőtérre, miközben a gyereke azt mondta: „Én is pizzát szeretnék.” Az ügynök mindkét kérést hallotta, és a gyerek megjegyzését a háttérben elhangzó beszéd helyett önálló utasításként kezelte. Ezután egy közeli pizzázó felé kezdte átirányítani az utat.

A hiba átcsúszott az offline értékeléseken. A gyártási környezetben közvetetten vált láthatóvá, amikor az átlagos munkamenethossz négy-öt társalgási fordulatról akár 20-ra nőtt. Egy társalgástervező a nyomokat követve megtalálta a hibát, majd módosította, hogyan kezelje az ügynök a fuvarfoglaláshoz nem kapcsolódó kéréseket.

A nyomkövetés alapértelmezetté vált

Az Uber platformja különböző technikai felkészültségű csapatokat támogat, az első személyes produktivitási ügynököt fejlesztő műveleti csoportoktól az infrastruktúra- és fogyasztói termékcsapatokig. A platform modellhozzáférést, AI-védelmi korlátokat, újrahasznosítható készségeket és ügynököket, kódalapú SDK-kat, menedzselt telepítést, alacsony kódigényű fejlesztőeszközöket és értékelési platformot is kínál.

A vállalat tapasztalata szerint a csapatok ennek ellenére gyakran előbb építették meg az ügynököt, és csak később foglalkoztak az értékeléssel. Ezért az Uber a megbízható értékeléshez szükséges gyakorlatokat a fejlesztés alapértelmezett útvonalába építette.

A menedzselt rendszerben telepített ügynökök minden környezetben automatikusan nyomkövetést kaptak. A telepítés létrehozta a megfelelő Arize-környezetet és jogosultságokat is. A kódalapú SDK-t használó csapatok egy kisebb konfigurációs módosítással kapcsolhatták be ugyanezt.

A teljes nyom nemcsak a felhasználói bemenetet és a végső választ rögzíti. Láthatóvá teszi az eszközhívásokat, a dokumentumok lekérését, a terv módosítását, az újrapróbálkozásokat és a köztes kimeneteket is. Így a fejlesztők megkereshetik, melyik döntés vezetett a hibához.

A gyártási hibákból új tesztek készülnek

A nyomkövetés önmagában sok adatot termel, ezért az Uber olyan folyamatot alakított ki, amely ebből értékelési jeleket állít elő. A platform az ügynök konfigurációját, a gyártási nyomokat és a tervezett működésre vonatkozó információkat használja fel személyre szabott értékelők létrehozásához. Ezek folyamatosan lefuthatnak, az eredmények pedig például Slack-riasztásokként jelenhetnek meg.

Az Uber egyik csapata olyan értesítést kapott, amely szerint az ügynök az értékelt esetek nagyjából 30 százalékában ellentmondott az eszközök kimenetének. A jelzés közvetlenül vizsgálható termékproblémát mutatott, így a csapatnak nem kellett előbb megértenie a nagy nyelvi modellel végzett bírói értékelés technikáját.

Az Uber külön alapértelmezéseket használ az értékelési adatkészletek állapotától függően. Ha még nincs adatkészlet, a rendszer gyártási hibákat gyűjt, és ezekből kezdeti offline tesztkészletet állít össze. Meglévő készlet esetén az emberek felülvizsgálják a hibákat, a hasznos példákat pedig hozzáadják az offline készlethez. Összetett, többfordulós ügynököknél a rendszer az ügynök környezetét és reprezentatív gyártási nyomokat felhasználva szimulációkat is készíthet.

Így az éles működés folyamatosan javítja az offline tesztelést. A gyártás feltár egy gyengeséget, az ember ellenőrzi az esetet, a példa bekerül az adatkészletbe, az ügynök későbbi változatainak pedig bizonyítaniuk kell, hogy kezelik az adott helyzetet.