A Checkr percekről órákra csökkentette a metrikák vizsgálatát
A Checkr AI-ügynöke korábban ugyanarra a kérdésre többféle hibás választ adott, mert nem ismerte a vállalati metrikák jelentését. A dbt és az Omni segítségével a vállalat olyan kontextust épített köré, amellyel egy órákig tartó vizsgálat percek alatt elvégezhető.
- A Checkr dbt-projektje és Snowflake-példánya több mint 6000 modellt tartalmaz.
- Az AI-ügynök korábban ugyanarra a kérdésre eltérő hibás válaszokat adott.
- Az Omni öt strukturált mezővel egészíti ki az adatmodellek AI-kontextusát.
- A Checkr automatikus tesztekkel és szakértői ellenőrzéssel javítja az ügynök hibáit.
- A túl sok kontextus lassíthatja a válaszokat és növelheti a tokenköltségeket.
A táblák önmagukban nem adnak elég információt
A Checkr Snowflake-példánya és dbt-projektje több mint 6000 modellt tartalmaz. Sarah Fischbach, a Checkr staff analytics engineere a dbt Summit 2026 egyik beszélgetésében arról beszélt, hogy a vállalat kis központi analitikai mérnöki csapattal és nagyjából 50, az egyes üzleti területekbe beágyazott elemzővel dolgozik.
Amikor egy AI-ügynököt közvetlenül a Snowflake-hez kapcsoltak egy MCP-n keresztül, és ugyanazt a kérdést többször feltették neki, minden alkalommal más hibás választ adott. Fischbach ezt metrikadriftnek nevezte. A probléma oka az volt, hogy az ügynök csak a mezőneveket és a táblák szerkezetét látta, az üzleti logikát nem.
Példaként a Checkr működésében fontos FRT-t, vagyis a First Reply Time mutatót hozta fel. Az operációs csapat teljesítményét ehhez az SLA-hoz mérik. A „mely sorok miatt került az FRT 90 százalék alá?” kérdésre az ügynök nem tudta, mit jelent az FRT, mi az a sor, és mire vonatkozik a 90 százalékos küszöb.
Három réteg készíti fel az adatokat az AI használatára
Fischbach szerint az AI-ra kész adatplatform három rétegből áll. Az adattárház minden létező adatpont szótára. A szemantikai réteg határozza meg az érvényes összekapcsolásokat, számításokat és metrikákat, ezzel megelőzve a metrikák elcsúszását. A harmadik réteg az AI-kontextus, amely a társalgási kapcsolatot teremti meg az üzleti nyelv és az adatok között.
Az Omni ezt az utolsó réteget öt strukturált mezővel kezeli. A szinonimák az üzleti kifejezéseket a mezőnevekhez kapcsolják. A mintaként megadott értékek segítik az ügynököt abban, hogy a természetes nyelvű kérdéseket érvényes szűrőkké alakítsa. A mezőleírások, amelyek gyakran már a dbt-projektben is rendelkezésre állnak, az adatok jelentését rögzítik. A szabad szöveges viselkedési útmutatók a kivételes eseteket kezelik, az előre elkészített mintalekérdezések pedig az összetett, több lépésből álló kérdésekhez adnak támpontot.
A Checkr nem új dokumentációt akar mindenáron létrehozni. A vállalat a Confluence-oldalakon, megbeszélések leirataiban, termékkövetelmény-dokumentumokban és Slack-beszélgetésekben már meglévő kontextust használja fel.
A célzott javítás pontosabb választ hozott
A Checkr automatizált visszacsatolási folyamatot épített. Egy aranyteszt-készlet valódi stakeholder-kérdéseket és a hozzájuk tartozó helyes lekérdezési terveket futtatja az Omni ellen. Egy Claude-alapú ügynök csoportosítja a hibákat, egy másik készség a vállalati tudás vektortárából releváns kontextust keres és javítást készít, egy harmadik pedig újrafuttatja a sikertelen teszteket. Ha a javítás működik, a rendszer merge requestet nyit szakértői ellenőrzésre.
Ennek kézi változata is használható. Egy Confluence-oldalt vagy megbeszélésleiratot a releváns dbt-modell kódjával együtt kell beilleszteni egy AI-asszisztensbe, majd az abból kinyert szinonimákat és viselkedési útmutatókat felülvizsgálni és hozzáadni az Omnihoz.
Amikor Christian, a Checkr egyik operációs vezetője azt kérdezte, mely sorok miatt került az FRT 90 százalék alá, az ügynök a korábban rögzített szinonimák, csatornánkénti SLA-célok és kivételszabályok alapján azonosította a gyengébben teljesítő hetet. Ezután sor és csatorna szerint bontotta le az eredményt, kizárta a mindenki által gyanúsított, nagy forgalmú sort, és a nemzetközi sorokra mutatott rá.
Christian szavai szerint: „Ami órákig tartott volna, percek alatt elkészült, ráadásul elegendő iránymutatást adott ahhoz, hogy ténylegesen változtassunk a válaszunkon.”
A dbt beszámolója szerint a kontextus bővítését nem célszerű minden modellre egyszerre kiterjeszteni. Az OutSchool egyik adatipari szakembere arról számolt be, hogy a túl széles körű kiegészítés lassította az ügynök válaszait, és nagyjából megduplázta a tokenköltségeket anélkül, hogy javította volna a pontosságot. A Checkr és az Omni ezért azt javasolja, hogy a javítás mindig konkrét hibához kapcsolódjon, a ritkán használt mezőket töröljék, és a kontextust mérhető pontossági vagy visszahívási probléma esetén, célzottan adják hozzá.
dbt Labs: How Checkr cut an hours-long metrics investigation to minutes by engineering AI context on dbt and Omni
