LLM-functies in SQL (AI-functies)

Wat zijn LLM-functies in SQL?

Een LLM-functie in SQL is een functie die je in een gewone query oproept, net zoals SUM of UPPER, alleen doet een taalmodel het werk. Je wijst ze naar een tekstkolom en vraagt iets waar een model goed in is: elke rij in één van vijf categorieën steken, het ordernummer uit een klacht halen, een omschrijving vertalen, de toon van een review scoren, een lange notitie samenvatten, of namen en telefoonnummers maskeren voor de tabel naar een ander team gaat.

Hetzelfde idee bestaat voor dataframes in een notebook. In Microsoft Fabric schrijf je df["reviews"].ai.classify(...) in pandas of Spark en krijg je een nieuwe kolom terug. Elke leverancier geeft er een andere naam aan, AI functions, AI SQL, generative AI functions, maar ze bedoelen allemaal hetzelfde: één aanroep, één volledige kolom, geen modelcode van jezelf.

Voor deze functies bestonden, was de enige manier om een model over een tabel te halen een script dat de rijen ophaalde, er één voor één over liep, een API aanriep, de fouten opving en de antwoorden terugschreef. De functie verstopt dat allemaal achter een SELECT.

Hoe ziet zo'n query eruit?

De functienamen hieronder zijn generiek. Elk platform spelt ze anders, maar de vorm van de query is overal dezelfde.

SELECT
  ticket_id,
  ai_classify(tekst, 'facturatie', 'levering', 'defect', 'andere') AS categorie,
  ai_extract(tekst, 'ordernummer', 'product') AS velden
FROM supporttickets
WHERE aangemaakt_op >= '2026-08-01';

Twee dingen vallen op. De labels staan in de query zelf, dus wie de SQL leest ziet precies wat aan het model gevraagd is. En het resultaat is een kolom zoals elke andere: je kan erop groeperen, erop joinen, of ze wegschrijven met INSERT of CREATE TABLE AS.

Onder de motorkap doet het platform wat je script vroeger deed. Het stuurt rijen parallel naar een modelendpoint. De documentatie van Fabric spreekt over honderden gelijktijdige aanroepen waarbij elke rij apart blijft, en Databricks zegt dat zijn functies parallellisatie, retries en schaling zelf regelen, en vraagt je om de volledige dataset in één query te sturen in plaats van ze zelf in stukken te knippen. Rijen die het model niet aankan, komen terug als NULL of als een standaardwaarde, zonder dat de hele query faalt. Sommige platformen rapporteren gecachte tokens, zodat een herhaalde instructie niet op elke rij volledig aangerekend wordt.

Wat het platform niet voor je beslist, is hoeveel rijen je stuurt. Zolang je de output nog niet op een staal gezien hebt, zet je een LIMIT of een WHERE op de query. Een miljoen rijen is een factuur, geen test.

Waar kan je het vandaag gebruiken? (stand september 2026)

• Microsoft Fabric. AI functions draaien in notebooks (pandas en PySpark), als T-SQL-functies zoals AI_CLASSIFY, AI_EXTRACT en AI_TRANSLATE in een warehouse of SQL analytics endpoint (in augustus 2026 nog in preview), en als AI Prompt-kolom in Dataflow Gen2. Het standaardmodel is gpt-5-mini en het verbruik gaat van je Fabric-capaciteit af onder de meter Copilot and AI. Je hebt een betaalde capaciteit nodig, F2 of hoger.

• Databricks. AI Functions zoals ai_classify, ai_extract, ai_mask en ai_analyze_sentiment zijn algemeen beschikbaar in Databricks SQL, naast ai_query voor een eigen prompt tegen eender welk model dat je serveert. De taakfuncties draaien op serverless GPU-infrastructuur die Databricks beheert.

• Snowflake. Cortex AI SQL heeft AI_CLASSIFY, AI_EXTRACT, AI_SENTIMENT, AI_TRANSLATE, AI_REDACT en AI_COMPLETE, plus AI_FILTER voor een WHERE-voorwaarde in gewone taal. Snowflake stelt dat alle modellen achter die functies binnen de Snowflake-serviceperimeter draaien.

• Google BigQuery. BigQuery ML heeft AI.GENERATE en getypeerde varianten, en beheerde functies zoals AI.CLASSIFY, AI.IF en AI.SCORE, met Gemini-modellen erachter. Alles is algemeen beschikbaar, behalve een geoptimaliseerde batchmodus voor AI.IF en AI.CLASSIFY die op 2 september 2026 nog in preview zat.

• DuckDB. Geen ingebouwde AI-functie. De community-extensie open_prompt voegt een functie open_prompt() toe die tekst naar eender welk OpenAI-compatibel endpoint stuurt, ook naar een model op je eigen machine.

Wat verandert er voor een KMO?

De meeste bedrijven hebben al veel tekst in hun warehouse zitten waar niemand een query op schrijft: het vrije tekstveld van supporttickets, de omschrijvingslijn op aankoopfacturen, productomschrijvingen van leveranciers, notities van de verkopers, reviews van de webshop. Ze staan er, ze zijn geladen, en ze doen niets in een rapport, want een rapport wil kolommen.

Een LLM-functie maakt van die tekst kolommen. Drie voorbeelden die we het vaakst tegenkomen:

• Klachtcategorieën. Elke supportticket krijgt één label uit een lijst die jij bepaalt, en je kan klachten per categorie per maand naast de verkoop per product zetten.

• Productkenmerken. Een leveranciersfeed zegt "drinkfles inox 750 ml, vaatwasbestendig" in één veld. Haal materiaal, inhoud en vaatwasbestendig eruit als drie kolommen en de filter op de webshop werkt.

• Leveranciersnamen uit factuurtekst. Lijnen op een bankuittreksel en tekst uit gescande facturen kloppen zelden met je leveranciersstam. Een functie die de leveranciersnaam en het factuurnummer eruit haalt, brengt je een heel eind richting automatische matching.

De persoon die vandaag al SQL schrijft voor de rapporten, kan dit allemaal. Er is geen apart machine learning-project voor nodig.

Wat kost een miljoen rijen?

Je betaalt per rij, want elke rij is een modelaanroep. Een rekenvoorbeeld, afgerond, met prijzen van de leveranciers zelf op 3 september 2026.

Neem een miljoen supporttickets. Elke ticket telt ongeveer 120 tokens tekst, en de labels en instructies komen daar met zo'n 80 tokens per rij bovenop, want de labellijst gaat met elke rij mee, niet één keer. Dat is 200 miljoen inputtokens. Het antwoord is één label, zeg 5 tokens, dus 5 miljoen outputtokens.

Op een klein model via een API, Claude Haiku 4.5 aan 1 dollar per miljoen inputtokens en 5 dollar per miljoen outputtokens, is dat 200 dollar in en 25 dollar uit, ongeveer 225 dollar voor de run. Via de batch-API, aan halve prijs, ongeveer 110 dollar. Op het ingebouwde gpt-5-mini van Fabric is dezelfde run ongeveer 1,7 miljoen capacity unit-seconden voor de input en 0,3 miljoen voor de output, samen grofweg 560 CU-uren die van je capaciteit gaan.

En nu de fout. Zet je die functie in een view en leest een dashboard die view, dan draait elke refresh het model opnieuw over elke rij. Acht refreshes per dag is 1.800 dollar per dag voor een antwoord dat niet veranderd is. De warehouse-documentatie van Fabric zegt het zonder omwegen: bereken het resultaat vooraf en bewaar het in een aparte kolom of een staging-tabel. Draai de functie één keer over de achterstand, daarna elke dag over de nieuwe rijen, en sla het resultaat op.

Voor snelheid geldt dezelfde logica. Fabric spreekt van enkele tientallen rijen per seconde voor zijn T-SQL-functies, dus een miljoen rijen duurt uren. Prima voor een nachtelijke job, onbruikbaar in een dashboardquery.

LLM-functie in SQL versus een aparte Python-pipeline

De dimensie die telt, is waar het werk draait en wie het kan onderhouden.

Bij een Python-pipeline draait het werk buiten het warehouse: een script of een notebook haalt rijen op, roept een model-API aan en schrijft de resultaten terug. Je kiest model en prompt vrij, je kan tussen de aanroep en het wegschrijven elke logica toevoegen die je wil, en je kan de goedkoopste aanbieder nemen. De prijs is dat het een tweede systeem is. Iemand moet het inplannen, de API-sleutel veilig bewaren, retries en rate limits afhandelen, en klaarstaan als het om drie uur 's nachts stukgaat. In een KMO is die iemand vaak één persoon.

Bij een LLM-functie draait het werk in het platform waar je al voor betaalt, het model is dat wat het platform aanbiedt, en de prompt staat in dezelfde SQL als de rest van de transformatie. De analist die het rapport beheert, kan ze lezen, een label aanpassen en opnieuw draaien. Je geeft modelkeuze op en een stuk controle over de kost, en je aanvaardt de limieten van het platform op tekstgrootte en doorvoer.

Een bruikbare regel: gebruik de SQL-functie als de opdracht een kolom is en de tekst ruim in één aanroep past. Stap over op een pipeline als je een model nodig hebt dat het platform niet aanbiedt, als de logica rond de aanroep meer is dan een labellijst, of als het volume zo groot wordt dat de tokenprijs van het platform de verkeerde deal is.

Waar moet je op letten bij LLM-functies in SQL?

Meet voor je vertrouwt. Neem een paar honderd rijen, label ze met de hand, draai de functie en tel de overeenkomsten. Beslis per functie hoeveel nauwkeurigheid genoeg is: 95 procent kan volstaan voor een klachtcategorie op een grafiek en is veel te weinig voor een factuurnummer dat een betaling aanstuurt. Fabric levert evaluatienotebooks voor precies die stap.

Voorzie altijd een restcategorie. Zet "andere" in elke labellijst en gebruik de foutstandaard van het platform, in Fabric T-SQL is dat DEFAULT 'andere' ON ERROR, zodat een rij die het model niet aankan in een bak belandt die je kan nakijken, in plaats van in NULL of in de verkeerde categorie.

Versioneer de prompt samen met de query. De labellijst en de instructies zijn code. Zet ze in versiebeheer naast de SQL, en als je ze wijzigt, draai dan het staal opnieuw en hou bij welke versie welke rijen gemaakt heeft. De ai_classify van Databricks heeft zelfs een expliciete versie-optie, zodat een upgrade van de functie je categorieën niet stilletjes verandert.

Weet waar de tekst naartoe gaat. Tenzij het model in het platform zelf draait, verlaten je rijen het warehouse richting een modelendpoint. De T-SQL-functies van Fabric roepen externe AI-API's aan; op een capaciteit buiten de VS of de EU-datagrens moet een beheerder eerst cross-geo-verwerking toelaten, en Fabric stelt dat het prompts, input en output niet logt of bewaart. De modellen van Snowflake draaien binnen zijn eigen serviceperimeter, maar sommige modellen zijn alleen via cross-region inference bereikbaar, en dat moet je account eerst toelaten. Lees de regio en de bewaartermijnen voor de precieze functie voor je ze op klantdata loslaat, en maskeer persoonsgegevens eerst als de voorwaarden niet duidelijk zijn.

Let op de tekstgrootte. Elk platform begrenst de input per rij, de T-SQL-functies van Fabric op 15 KB tekst in augustus 2026. Lange documenten moet je opsplitsen of met een documentfunctie behandelen, niet met een classificatiefunctie.