Dataanalyse & Insights

Use-casen dækker brug af sprogmodeller som mellemled mellem et spørgsmål formuleret i naturligt sprog og en struktureret datakilde. Modellen oversætter spørgsmålet til SQL eller Python, fortolker resultatet og formulerer et svar. Den kan også foreslå, hvilken visualisering der passer til det udtræk, den lige har lavet.

Grænsen mod almindelig kodegenerering ligger i, at modellen her arbejder mod et konkret skema med konkrete data. Den skal kende tabelnavne, kolonnetyper og relationer, og den skal forholde sig til resultatet af sin egen query. Det gør opgaven mere afhængig af kontekst og mindre af generel programmeringsevne.

Grænsen mod klassisk BI er, at BI-værktøjer arbejder med foruddefinerede modeller og målinger. Her formuleres spørgsmålet frit, og der findes ingen godkendt definition af det, der spørges om. De to tilgange udelukker ikke hinanden, men de fejler på forskellige måder.

Første komponent er skemakonteksten. Modellen får en beskrivelse af de relevante tabeller, kolonner og relationer, ofte suppleret med kommentarer om, hvad felterne faktisk betyder. Ved store databaser hentes kun de relevante dele frem, typisk med en retrieval-mekanisme over skemadokumentation, fordi hele skemaet ikke kan være i context window.

Derefter genererer modellen en query. Den sendes gennem et valideringslag, der kan parse SQL'en, afvise skrivende operationer og estimere omkostningen før udførsel. Først når queryen er godkendt, rammer den databasen, og resultatet sendes tilbage til modellen som tekst eller tabel.

Sidste trin er fortolkningen. Modellen forklarer, hvad tallene viser, og foreslår eventuelt en graf. GPT-5.6 Sol og Claude Sonnet 5 klarer begge trin rimeligt, men kvaliteten afhænger mere af skemabeskrivelsen end af modelvalget. Er kolonnen dokumenteret som "status: 1=aktiv, 2=opsagt, 3=pauseret", bliver queryen rigtig. Hedder den bare status, gætter modellen.

Den alvorligste fejltype er den query, der kører fint og giver et forkert svar. Modellen joiner to tabeller på en nøgle, der ligner den rigtige, eller den glemmer et filter på soft-deletede rækker. Resultatet ser plausibelt ud, tallene er i rette størrelsesorden, og ingen opdager det. Det er sværere at fange end en query, der fejler med en syntaksfejl.

Næste problem er fortolkningen. En model, der får tolv datapunkter, vil ofte beskrive en tendens, også når variationen er tilfældig. Den mangler statistisk tilbageholdenhed, medmindre du eksplicit beder om den, og den har ingen adgang til viden om, hvad der ellers skete i perioden.

Endelig er der forventningsafstemningen. Brugere uden dataerfaring kan ikke vurdere, om svaret er rigtigt, og de kender ikke de spørgsmål, datasættet ikke kan besvare. Det flytter valideringsbyrden til dataholdet, som nu skal kontrollere ad-hoc-analyser, de ikke selv har lavet.

Tilgangen fungerer bedst til eksplorativ analyse, hvor et forkert svar opdages hurtigt og koster lidt. Du undersøger en hypotese, får et hurtigt tal og validerer det manuelt, før det bruges til noget.

Den fungerer dårligt til tal, der skal rapporteres videre uden mellemled. Omsætningstal til bestyrelsen eller KPI'er i et fast dashboard bør bygges på definerede og reviewede queries. Her giver det mere mening at bruge modellen til at udarbejde forslaget og lade et menneske godkende det som permanent metrik.

En realistisk implementering behandler derfor genererede queries som udkast, ikke som svar. Logning af alle queries og deres resultater gør det muligt at genfinde fejlkilden, når et tal senere viser sig ikke at holde.