DataHub løfter i dag sløret for Context Intelligence, et nyt lag der bruger SQL‑query‑historik som semantisk hukommelse for AI‑agenter. Timingen er ikke tilfældig. Miro‑casen spøger stadig: da teamet lod agenter gå direkte mod Snowflake uden semantisk lag, var svarene forkerte i over 65 procent af tilfældene, skriver VentureBeat. Tallet er opsigtsvækkende.
Mange, der har koblet en agent på et warehouse, har set det samme: rod i joins, forvekslede tabeller og glidende forretningsdefinitioner. Det er sjældent modellens fejl – det er fravær af kontekst. DataHubs bud er at lade agenter genbruge den kontekst, analytikere allerede har indlejret i årevis af queries.
Miro‑eksemplet der satte ild til debatten
Ifølge VentureBeat pegede Miro deres agenter direkte på et Snowflake‑miljø med mere end 10.000 tabeller og uden semantisk lag til at guide routing. Resultatet: mere end 65 procent forkerte svar. Ikke fordi LLM’en var svag, men fordi den ikke vidste, hvilke tabeller der faktisk matchede forretningsspørgsmålet. Et menneske ved, at “orders_curated” sjældent er det samme som “orders_raw_v2_bkp”. En agent uden kontekst gætter.
Pointen gør ondt, fordi mange håber, at modelvalg alene retter kurven. Her var fejlen arkitektur. Ingen semantisk forankring, ingen dokumenterede, validerede joins at læne sig op ad. Vi har set det før: når alt ligner alt, svarer agenten pænt – og forkert.
Hvad DataHub lancerer
Context Intelligence bygger et semantisk indeks ud fra valideret SQL‑historik og gør det tilgængeligt for agenter via MCP, LangChain, Googles Agent Development Kit og CrewAI, ifølge VentureBeat. Laget placeres oven på DataHubs eksisterende query‑loginfrastruktur, der allerede har været brugt til lineage i produktion. Det vigtige er, at man genbruger gennemprøvet logekstraktion og parsing – ikke et helt nyt rørarbejde.
Integrationsfladen er bred fra start: MCP til redaktørnære agenter, LangChain og Google ADK til klassisk orkestrering, og CrewAI til hold‑opsætninger. Pointen er, at laget skal ind i den stack, teams allerede bruger.
Hvorfor query‑logs slår råt schema
Et råt schema fortæller, at “fact_sales” findes. Query‑historikken viser, hvordan dygtige mennesker faktisk har bundet “fact_sales” korrekt sammen med “dim_customer” og filtreret for returnerede ordrer. Det er et stærkere signal. Lineage‑grafer kortlægger flow og afhængigheder, men sjældent hvordan ARR beregnes, eller hvordan “skygge‑kunder” håndteres.
Med historik over tidligere succesfulde joins får agenten en praktisk huskeseddel, der forkorter vejen fra spørgsmål til korrekt SQL. Det er også her, Miros fejl siger noget generelt: uden routing mod tidligere validerede mønstre vil selv stærke modeller famle i et skema med 10.000+ tabeller.
Hvordan man miner query‑historik i praksis
I korte træk: udtræk logs fra warehouse, parse SQL, filtrér støj fra, normalisér og byg embeddings til et semantisk indeks. VentureBeat beskriver DataHubs tilgang som filtrering mod “golden queries” og inversion af SQL‑mønstre til semantiske ankre, som agenter kan slå op før de genererer ny SQL. Det matcher det, vi ser virker i felten.
Første implementeringsspørgsmål: kilder. VentureBeat noterer, at Postgres er den mest forbundne kilde i DataHubs udrulninger globalt, efterfulgt af MySQL, Oracle og de store warehouses som Snowflake og BigQuery. Dernæst normalisering: fjern personlige hints, aliasser og flygtige CTE‑navne, men bevar filtreringslogikken. Til sidst versionering: et mønster skal kunne overleve schema‑ændringer uden at gå i stykker – eller i det mindste give tydelige diffs.
Fra teori til drift – hvad ændrer sig i jeres pipeline
Vil I samme vej, så start med robust logindsamling. Batch kan dække langt det meste, men hav en realtime‑kanal til “high value” queries fra forretningskritiske dashboards. Et velfungerende hybridmønster: daglige aggregater for bredde og en letvægtskø for nye, vigtige forespørgsler, der skal ind i indekset inden for minutter.
Overvågning: sæt cost‑kontroller, så parsing ikke driver warehouse‑regningen op. Læg parsing uden for dyreste compute og cache normaliserede AST’er, hvor det giver mening. Test: lav en lille suite, hvor tre‑fem kerneforretningsspørgsmål måles før og efter indekset – fokus på join‑fejl og tid til første korrekte svar.
Hvad med mennesker i loopen
VentureBeat beskriver, at DataHub lægger et menneskelag ovenpå, hvor domænefolk kan gennemse foreslået kontekst, løse konflikter og simulere konsekvenser før publicering. Det er afgørende. Uden klar rollefordeling ender man med et uigennemsigtigt semantisk indeks, der stille forvitrer. Udpeg ejere for “validated joins” per domæne, og giv dem værktøj til at godkende, afvise eller markere som forældet.
Det kræver et rigtigt workflow: en kø af kandidat‑queries, review‑noter, audit‑log og et simpelt ratingfelt koblet til agentfeedback. Brugere skal kunne markere “rigtigt\/halvrigtigt\/forkert”, og de signaler bør tilbage i filtreringen. Ikke kønt, men effektivt.
Tradeoffs og begrænsninger
Historiske queries rummer bias. Hvis en afdeling altid ekskluderer en region, kan agenten lære samme vane. Logs støjer – midlertidige eksperimenter fylder ofte meget. Og så er der GDPR: query‑logs kan indeholde PII i klare tekststumper, især i WHERE‑betingelser. Man skal redigere eller maskere felter før indeksering. VentureBeat nævner filtrering af “golden queries”, men ikke præcise heuristikker. Det står åbent.
Skiftende datamodeller er endnu en knast. En “valideret” join kan knække ved en kolonneomdøbning. Semantiske ankre bør derfor versioneres, og publikation kobles til schema‑diffs. Ellers reproducerer man gamle, nu forkerte antagelser – med større selvtillid.
Marked og alternativer
DataHub står ikke alene. AWS beskriver i en teknisk gennemgang, hvordan NarrateAI bygger agentisk BI med Amazon Bedrock AgentCore, en to‑lags arkitektur med routing og validering. Beslægtet idé: split mellem batch (forberedt kontekst) og realtime (interaktion og routing). Andre vælger semantiske lag med metrics‑definitioner eller knowledge graphs. Skillelinjen er, hvor meget man baserer sig på historiske queries kontra håndskrevne semantiske definitioner.
DataHubs vinkel er interessant, fordi de allerede har infrastruktur til query‑logs i produktion. VentureBeat peger på en årelang base: open source‑projektet har over 15.000 bidragydere og cirka 3.000 deployment‑miljøer, grundlagt af holdet bag LinkedIns DataHub med CTO Shirshanka Das i spidsen. Det giver dem noget at stå på – i hvert fald i “plumbing”.
Hvad det betyder for teams – i praksis
Start ikke med at pege agenter direkte på jeres warehouse. Begynd med logindsamling og normalisering. Sæt et 30 dages PoC‑scope: vælg tre typiske spørgsmål, byg et første semantisk indeks og mål fejl i joins før\/efter. Gode KPI’er: “tid til første korrekte SQL” og “andel af svar markeret som sikre over et givent threshold”.
Arbejdsgange ændrer sig. Analytikere flytter sig fra ad hoc‑joins til at vedligeholde versionerede “trusted queries”. Det føles måske kedeligt, men det giver ro på sigt. De bedste forespørgsler bliver artefakter – dokumenterede, søgbare og genbrugelige. Som at få orden i kablerne under skrivebordet: man mærker forskellen, når det først er gjort.
Governance uden paragraffetid
Rollefordeling bør være klar: data engineering ejer logindtag, parsing og performance; domæneejere ejer semantiske ankre; agent‑\/ML‑teamet ejer routing, promptskabeloner og confidence‑scoring. Sikkerhed og compliance sætter PII‑sanering og auditkrav. Gør det konkret: et kort schema for, hvad der må ind i indekset, og hvad der afvises.
Driftsmæssigt ser vi to klassiske faldgruber: for dyr parsing og for løs kuratering. Den første løses med batch, cache og letvægts‑AST‑repræsentation. Den anden kræver månedlige gennemlugninger og alarmer, når en join holder op med at matche på rækker.
Tjekliste til en pilot
- Afgræns domæne og tre forretningsspørgsmål. Ikke hele virksomheden. Salg eller fakturering er ofte gode startere.
- Etabler batch logudtræk og en lille realtime‑kanal for nye højt prioriterede queries.
- Byg parser\/normalisering, fjern PII‑mønstre, dedupliker varianter. Gem AST’er til genbrug.
- Indeksér til en vektor‑ eller semantisk søgning. Eksponér via LangChain eller MCP – brug det, I allerede har i stacken.
- Definér review‑workflow for “candidate joins” med ejere og audit‑spor.
- Mål: join‑fejlrate, svartid, cost pr. forespørgsel og brugerfeedback pr. svar.
Niche, men nyttigt: score queries med simple heuristikker som konsistent brug af godkendte dimensionstabeller, fravær af cartesian joins og korrekt tidsfiltrering. Basalt, men effektivt.
Åbne spørgsmål vi stadig mangler svar på
VentureBeat beskriver filtrering for “golden queries”, men ikke præcist hvilke signaler der afgør kvalitet: brugerroller, succes downstream, fejlfrie kørsler over tid? Vi mangler også et billede af omkostningen ved kontinuerlig logudtrækning og parsing i store Snowflake\/BigQuery‑miljøer – er vi i promiller eller procenter af den samlede warehouse‑regning?
Hvor meget af Miros fejlrater skyldtes schemas kompleksitet versus fravær af routing\/metadata? Der er ingen offentlig post‑mortem med fejlkategorier. Hvordan håndteres PII i query‑logs til agent‑routing – anonymisering ved kilde, tokenisering eller regler i indekset? Og hvilken latency kan man forvente fra en ny query til den er slået op som semantisk anker? Det er operationelle detaljer, vi gerne ser belyst næste gang.
Vores vurdering – med jord under neglene
DataHubs træk giver mening. Ikke fordi alt løser sig, men fordi arkitekturen flytter agenter fra gætværk til genbrug af dokumenteret praksis. I vores projekter har vi set, at et lille sæt validerede queries kan halvere fejl på få uger – hvis nogen ejer dem. Uden ejerskab og versionering er man hurtigt tilbage ved start.
Det provokerende i Miro‑tallet er ikke 65 procent i sig selv. Det er, at mange stadig sætter agenter foran 10.000 tabeller uden et eneste skilt. Vi kalder det ikke hallucination – det er dårlig skiltning. Start med skiltningen (query‑historikken), og mål derefter modellen. Det er mere fair for alle.
Konklusion: Brug de logs, I allerede har, som første semantiske lag. Lad agenterne læse virksomhedens kollektive SQL‑hukommelse, før de opfinder endnu en join. Resten kan bygges på bagefter. Man opdager forskellen, når man har det i hænderne.
