A Careem AI-ja percek alatt ír és tesztel dbt-modelleket

Több mint 5000 modellhez kellett gyorsabb folyamat

A Careem az Egyesült Arab Emírségekben működő szuperapp, amely fuvarrendelést, élelmiszer-kiszállítást, ételkiszállítást és pénzátutalást kínál. Adatplatformját karcsú mérnöki csapat üzemelteti, több mint 5000 modellel. A teljes technológiai stack házon belül készült, és a betöltéstől az üzleti intelligenciáig nyílt forráskódú megoldásokra épül, az átalakítási feladatokat pedig a dbt végzi.

A dbt Labs 2026. október 26-án közzétett beszámolója szerint a csapat korábban több mint 100 függőben lévő adatigénylést kezelt. Egy-egy kérés megválaszolása általában egy-két hetet vett igénybe, ezért elsőként egy nyelvi modellre bízták volna a modellek megírását. Ez önmagában nem bizonyult elég megbízhatónak. A mérnökök ugyanis gyakran csak mintázatok alapján nézik át az AI által készített kódot, így egyetlen rejtett kivétel is hibát okozhat az adatfolyamban.

A validáció a kódgenerálás előtt és után is dolgozik

A Careem erre egy négy pillérre épülő ügynöki architektúrával válaszolt. A kontextusréteg nyílt metaadatokra támaszkodva adja át az ügynöknek a táblák és oszlopok dokumentációját, az adatok eredetét, a belső szakkifejezéseket, valamint a központilag definiált metrikákat. Így az olyan rövidítések és fogalmak, mint az AOV vagy a GTV, nem maradnak értelmezés nélkül.

A specifikáció rögzítésekor az ügynöknek tisztáznia kell többek között az adatok részletességi szintjét, a metrika jelentését és a szűrőket. A Careemnél például a „bevétel” többféle dolgot jelenthet, például GTV-t, GMV-t vagy rendelésszámot. A rendszer ilyenkor kérdez, ahelyett hogy találomra választana.

A létrejövő változtatás minden esetben elkülönített fejlesztői környezetbe kerül, külön jogosultságokkal, tárhelyútvonalakkal és számítási erőforrásokkal. Az ügynök lefordítja, teszteli és materializálja a módosítást, majd a hibák alapján újra futtatja a folyamatot. A pull request csak sikeres futás után jut el az emberi ellenőrzésig.

A rendszer a hibákból is automatikusan javít

A dbt Summit 2026 egyik bemutatóján egy elemző angol nyelvű kérése, napi ételbevétel minden kereskedőhöz, percek alatt teljesen tesztelt és dokumentált dbt-modellé, majd pull requestté alakult. A folyamat közben két tesztfutás is sikertelen lett. Elsőként adattípus-eltérés jelentkezett, amelyet az ügynök kijavított. A második hibát az okozta, hogy a szükséges oszlop egy másik forrástáblában volt. A kontextusréteg segítségével a rendszer megtalálta az oszlopot, összekapcsolta a táblát, majd újra futtatta az ellenőrzést.

Az automatikus vizsgálatok a szokásos dbt-teszteknél tovább mentek. A rendszer ellenőrizte, hogy az adatok megfelelően jutnak-e el a bronz-, ezüst- és aranyrétegen keresztül, valamint azt is, hogy a modell a Careem domainkonvencióinak megfelelő helyen tárolódik-e.

A Careem különbséget tesz a teljesen felügyelt, összevont metrikáknak fenntartott aranyréteg és az egyszeri elemzői kérésekhez használt átmeneti réteg között. Az utóbbi elemei 30 napig maradnak meg, ezt követően megfelelő adatpiaccá alakítják őket, vagy automatikusan törlik. A csapat az elmúlt évben 3,6 petabájtnyi átmeneti adatot takarított el.

Órákra rövidült a metrikák elkészítése

A dbt Labs szerint a Careemnél a metrikák szállítási ideje két-három hétről órákra csökkent. Az új modellek nagyjából 90 százaléka már ezen a keretrendszeren keresztül készül, és a folyamat bevezetése óta nem történt sev0 vagy sev1 szintű incidens.

A rendszer a duplikált kéréseket is kezeli. Mivel minden módosítás a dbt-manifesten halad át, felismeri, ha egy már hozzáadott oszlopra érkezik új kérés, és egy hasonló, párhuzamos modell létrehozása helyett a meglévőhöz irányítja azt.

A Careem decemberben kezdte értékelni a dbt-t, márciusra felépítette a teljes infrastruktúrát, áprilisban vagy májusban pedig élesítette az ügynököt. A vállalat tapasztalata alapján a kódgenerálás önmagában kevés a megbízható adatfolyamatokhoz. A folyamat lényegét a dbt Labs által idézett Akash Srivastava így foglalta össze: „A bizalom a validációból származik, nem igazán a kódgenerátorból.”