A dbt szerint 20-szoros tokenmegtakarítást hozhat a tömörített AI-kontextus

A nyers hívásadatok gyorsan kimerítették az API-keretet

A dbt Labs 2026. augusztus 17-én közzétett beszámolója szerint a Gong az egyik legértékesebb belső AI-kontextusforrásuk. Amikor a Claude használata bővülni kezdett, a csapatok a Gong nagy mennyiségű híváselőzményét is szerették volna elérni.

Az egyszerűnek tűnő megoldás egy, a Gong MCP-jét a Gong REST API-jához kapcsoló köztes réteg használata volt. Ez azonban nyers, modellezetlen adatot adott át, amelyet nehéz volt irányítani és továbbfejleszteni. Egyetlen ügyféltörténeti kérdés a list_calls eszközzel gyűjtötte össze a hívások azonosítóit, majd hívásonként körülbelül 8300 tokent fogyasztott. Egy nagyjából 30 hívásból álló ügyfél-előzmény így mintegy 240 000 tokennyi kontextust jelentett.

A dbt szerint az értékesítési részleg több ügyféllel végzett párhuzamos kutatása gyorsan elérte a Gong másodpercenkénti és napi API-korlátait. A vállalat arra jutott, hogy a fő probléma nem önmagában a Gong korlátozása, hanem az, hogy tranzakciós API-t használtak nagy áteresztőképességű AI-kontextusrétegként. A dbt állítása szerint az ilyen feladatokra az adatbázisok alkalmasabbak.

Az adattárházban tömörítették a hívások tartalmát

A Gong adatait a Fivetran folyamatosan a Snowflake adattárházba töltötte. A dbt Labs ezt a meglévő adatfolyamot használta arra, hogy a nyers forrás helyett modellezett adatot szolgáljon ki a dbt MCP-szerveren keresztül.

A vállalat szerint a hívásleiratok aktív tömörítése legalább 20-szorosára csökkentette az adatmennyiséget. Egy 60 perces hívás több mint 10 000 token helyett néhány száz tokenből álló kontextussá alakítható. A részletesebb leírás szerint egy tipikusan 10 000 tokenes leiratból 500 és 1000 token közötti, strukturált összefoglaló készülhet.

A dbt modelljei a hívásokból az üzlet szempontjából fontos pontokat, a megnevezett entitásokat, a hangulatot, a teendőket és a kifogástípusokat emelik ki. A feldolgozás inkrementális dbt-feladatként fut, amikor az új adat bekerül az adattárházba. Az inferencia költsége a Snowflake kreditjein, a Vertex batch árazásán vagy a Databricks AI Functions díjszabásán keresztül jelentkezhet.

A dbt Labs számai szerint az összefoglalók 74-szer kevesebb tokent igényelnek, és 99 százalékkal olcsóbban szolgálhatók ki AI-ügynököknek, miközben a kontextus minősége megmarad vagy javul. A vállalat példája alapján 1000 hívás kötegelt tömörítése alacsony tízdolláros nagyságrendbe kerül. A tömörítés egyszeri költség hívásonként, a megtakarítás viszont minden későbbi beolvasásnál jelentkezik.

A dbt összevetette a Gong MCP-megoldásait

A dbt Labs három megközelítést hasonlított össze: a Gong hivatalos MCP-jét, a Gong API-ját becsomagoló MCP-megoldást és a dbt MCP-szerverét. A hivatalos Gong MCP gyors, egyetlen ügyfélre vonatkozó, szerver által készített összefoglalókhoz hatékony. A köztes MCP-réteg nyers leiratok lekérésére használható, viszont a kérdések gyakran minden hívásnál azonosítókat gyűjtenek, majd egyenként kérik le a teljes szövegeket.

A dbt MCP-szervere ezzel szemben az adattárházban modellezett adatot adja át. A kérdéshez szükséges réteg lehet metaadat, rövid összefoglaló, részlet vagy teljes leirat, és a rendszer irányított mérőszámokat is kiszolgálhat. A dbt szerint így lehetőség nyílik tartalomszűrésre, például csak az árazással kapcsolatos részek lekérésére, továbbá CRM-, termék- és számlázási adatokkal végzett összekapcsolásra.

A vállalat költségpéldája Claude Opus árazására, egymillió tokenenként 5 dolláros bemeneti díjra és 15 dolláros kimeneti díjra, valamint hívásonként 8314 nyers és 112 összefoglaló tokenre épül. Egy 30 hívásos ügyfél-összefoglalónál a hivatalos Gong MCP körülbelül 1200 tokent, a dbt MCP-szerver összefoglaló oszlopa mintegy 30 hívásnyi adatot használ. A dbt számítása szerint egy árazási témára szűrt, szó szerinti lekérdezés a dbt MCP-szerverén körülbelül 20-szor olcsóbb lehet, mint a köztes MCP-rétegen keresztüli lekérés.

A minta más vállalati adatforrásokra is kiterjedhet

A Gong volt a dbt Labs első tesztesete, a vállalat szerint azonban ugyanez az architektúra használható más, sok tokent igénylő és tartós adatforrásoknál is. Példaként e-mail-archívumokat, Slack-csatornák naplóit, ügyfélszolgálati jegyeket, szerződéseket és marketinganyagokat említ.

A megközelítés lényege, hogy a forrásadat az adattárházba kerül, ott AI-funkciókkal strukturált és tömörített formát kap, majd a dbt MCP-szervere ezt az adatot ugyanazon a kapcsolaton keresztül szolgálja ki, amelyet az AI-kliensek a többi dbt-modellezett adathoz is használnak. A dbt Labs szerint ezzel az AI-ügynökök a nyers források helyett irányított, újrahasznosítható és olcsóbban lekérhető kontextust kapnak.