In Short: The LLM as a Pipeline Step
AI functions are Fabric's answer to a problem every data team recognises: the analytically valuable information trapped in text columns. Support tickets, survey comments, reviews, notes fields. The functions expose language model operations - summarise, classify, translate, extract, sentiment, similarity, generate - as single calls inside notebooks and dataflows, so turning a comments column into categories and scores becomes a transformation step rather than an ML project.
That convenience is real, and so are the two things it hides: a per-row model cost that bills against your capacity, and a mild non-determinism that ordinary transformations do not have. Both are manageable with pipeline design; neither should be discovered in production.
What Is in the Toolbox
- Summarise - condense long text into short summaries, per row
- Classify - assign text to categories you define: issue type, topic, intent
- Sentiment - score tone from text: the classic survey and review use case
- Translate - move text between languages at pipeline time
- Extract - pull named fields out of free text: amounts, dates, product names, entities
- Similarity - compare text semantically, useful for matching and dedupe
- Generate response - free-form generation from a prompt template applied per row
The pattern across all of them: text goes in as a column, structure comes out as a column, and the result is ordinary Delta data that semantic models and reports consume with no further ceremony.
The Use Cases That Pay First
Ticket and case triage. Classify support tickets by issue type and urgency at ingestion, and the operations dashboard everyone wanted becomes possible without anyone hand-tagging history.
Voice of customer. Sentiment plus summarisation over survey comments and reviews turns a column nobody read into a trend line executives follow. Pair the derived scores with the raw text so analysts can always audit what the score summarised.
Multilingual normalisation. Translation at pipeline time gives a single-language analytical layer over multi-market text data, which beats maintaining parallel logic per language.
Entity extraction from notes. Amounts, dates and references extracted from free-text fields recover data that should have been structured at entry, and frequently rescue a reporting requirement that was otherwise a system change request.
Engineering Around the Two Gotchas
Cost scales with rows times tokens. Every AI function call consumes capacity like other Fabric AI features. The difference from Copilot is that pipelines multiply: a function over ten million rows, re-run nightly on the full table, is an expensive habit. The disciplines that keep it sane are incremental processing (score new and changed rows only), text truncation where the tail adds nothing, and a capacity metrics review after the first full-volume run, not the tenth.
Output can wobble. Model output varies slightly between runs, and borderline classifications can flip. Constrain category sets tightly with clear definitions, keep raw text alongside derived columns, avoid rescoring history, and schedule a small human-reviewed sample as a quality control. Treat the derived columns the way you treat any modelled data: owned, monitored and documented, with the same seriousness as your data quality programme applies elsewhere.
Where AI Functions Sit in the Bigger Picture
AI functions are deliberately narrow: per-row text transformations. They are not agents, not conversational, and not a substitute for proper ML where a trained model on your own data would outperform a general one. Their job is the unglamorous middle of the estate: enriching tables so that downstream analytics, Copilot answers and agents all have more structure to work with.
Used that way - incrementally, cost-aware, with raw text retained - they are one of the highest-return AI features in Fabric, precisely because nobody has to change how they consume anything. The reports just quietly know more.
Sources and Further Reading
Frequently asked
Prebuilt functions that apply a language model to your data from inside notebooks and dataflows: summarising text, classifying it into categories you define, detecting sentiment, translating languages, extracting fields from free text, checking similarity and generating responses. One function call per column transformation, no model deployment required.
Turning text into structure at pipeline time: support tickets classified by issue type, survey comments summarised and scored for sentiment, product descriptions translated, entities pulled out of notes fields. The output lands in Delta tables like any other column and flows into semantic models and reports.
As Fabric capacity consumption: the underlying model calls draw capacity units like other Fabric AI features. Cost scales with rows processed and text length, so a function applied to millions of rows on every run is a very different proposition from one applied incrementally to new rows only.
Not perfectly. Language model output can vary between runs, and classifications near category boundaries can flip. Design for it: constrain categories tightly, process incrementally so history is not rescored, keep the raw text alongside the derived columns, and spot-check samples on a schedule.
AI functions run within the Fabric service boundary and inherit its governance, but classification and extraction over sensitive text still deserve a deliberate decision. Apply the same data handling review you would for any processing of that data, and lean on sensitivity labels and workspace policy.
