AI and automation
LLM
Large Language Model
A Large Language Model is a type of AI model trained on very large volumes of text to predict and generate coherent, contextually appropriate language.
Why LLM matters in a Microsoft estate
LLM matters when teams want AI support without losing control of identity, data, approvals, and audit evidence. In the EfficientEther portfolio, AI terms usually connect to governed workflows, Copilot readiness, or agentic packaging where humans still review important outputs.
How LLM shows up in practice
It's the underlying technology behind essentially every generative AI product relevant to a Microsoft estate, including Microsoft 365 Copilot, the models available through Azure AI Foundry, and the language capabilities built into Copilot Studio agents. Practically, an LLM works by learning statistical relationships between words and concepts across its training data at a scale large enough that it can produce genuinely fluent, contextually coherent text, answer questions, summarise documents, translate, and write code, without being explicitly programmed with rules for any specific one of those tasks.
What it produces is best understood as a highly sophisticated prediction of plausible next content based on patterns in its training data and whatever additional context, a document, a prompt, retrieved search results, it's been given at the time, not a database lookup of verified facts. That is the root cause of the behaviour generally called hallucination, where a model produces fluent, confident, and entirely incorrect information because incorrect but plausible-sounding text was statistically available to generate. This distinction matters directly for how organisations should treat LLM output operationally: content an LLM generates, whether a Copilot-drafted email, a Foundry application's response, or an agent's summary of a document, should be treated as a draft requiring human review proportional to its stakes, not as a verified answer.
This is especially true for anything involving numbers, dates, named individuals, or factual claims the model wasn't directly grounded on through retrieval-augmented generation or an explicit data connection. Different LLMs, GPT-4 class models, Microsoft's own smaller Phi models, and various open-source alternatives available through the Foundry Model Catalog, trade off capability, cost, latency, and context window size, how much text the model can consider at once, against each other. Model choice is a genuine engineering decision for custom AI applications rather than a default to leave unexamined, since a smaller, cheaper model is often entirely sufficient for a narrow, well-defined task and using an expensive frontier model by default is a common and avoidable source of unnecessary consumption-based cost in Azure AI Foundry applications.
Grounding, most commonly implemented as retrieval-augmented generation, where relevant organisational documents are retrieved and injected into the model's context before it generates a response, is the standard technique for making an LLM's output reflect an organisation's actual, current data rather than only its general training knowledge. It's the mechanism underpinning both Copilot's use of the Microsoft Graph and most custom Foundry applications that need to answer questions grounded in proprietary content the model was never trained on.