Language Model
The component that turns retrieved material into a sentence somebody can read. It is the most talked-about part of an assistant and the least decisive one.
The component that turns retrieved material into a sentence somebody can read. It is the most talked-about part of an assistant and the least decisive one.
What it does
A language model is what writes the reply. It takes the question, the material retrieval found, the personality you configured and the limits you set, and produces a sentence in the language the question was asked in.
It is worth being precise about what it does not do, because this is where most of the confusion in the market lives. It is not where your answers come from — that is your material. It is not what makes an answer correct — that is retrieval. And it is not what stops the assistant saying something it should not — that is the check that runs on the finished reply. The model composes; the rest of the system decides.
That distinction matters commercially, because vendors compete loudly on which model they use, and the choice of model is one of the smaller variables in whether a deployment works. An assistant with an excellent model and disorganised material will be confidently wrong. An assistant with a modest model and well-organised material, grounded answers and a real check on the output will be useful and safe. We have measured both, and the second wins.
Where it shows up in a conversation
Composing the reply
Turning retrieved passages into one clear answer rather than a list of extracts.
Matching the language
Answering in the language the question was asked in, in the register you configured for it.
Holding the personality
Tone, formality and length, set per agent and per language.
Saying it does not know
Declining cleanly when the material does not cover the question, rather than filling the gap.
Summarising for handover
Compressing a conversation into something a colleague can read in ten seconds.
Rephrasing on request
Explaining the same answer more simply when somebody asks — a small thing that matters more than it sounds.
Why it is harder in two languages
Most models are strongest in English by a wide margin, because that is what most of their training material is. Arabic performance is usually adequate on formal written text and weaker on the dialect and mixed-language sentences your customers actually write — and a vendor quoting one accuracy figure is almost always quoting the English one.
The practical consequence is that Arabic output needs to be judged by a native speaker on your own questions, not accepted on a benchmark. A reply can be grammatically correct and still read as though it was written in English first, and that is a judgement no score captures.
Register is the second issue. Arabic carries a wider range of formality than English does, and the wrong choice reads as either distant or over-familiar. This is why the personality is written per language here rather than written once and translated — a translated personality reads correct and foreign at the same time.
What to look for when you evaluate it
| Arabic judged separately | By a native speaker, on your own questions. An overall figure hides the language that needs the most attention. |
|---|---|
| Behaviour at the limit | What it does when the material does not cover the question. Declining cleanly is the behaviour worth paying for. |
| Register control | Whether tone and formality are actually configurable per language, or set once and translated. |
| Consistency | The same question twice should not produce two materially different answers. |
| Speed to first word | Under a second is what feels immediate. Total time matters less than the wait before something appears. |
| Cost behaviour | Whether cost tracks conversation volume in a way you can predict and budget for. |
Where it should not be trusted alone
A language model should never be the thing that decides whether an answer is allowed. Instructions written into a personality are suggestions to it, and a sufficiently pointed question gets around them. What holds is a deterministic check on the finished reply, and that check is not the model.
Nor should it be the source of facts. A model asked a question with no material behind it will produce something plausible, because producing plausible text is precisely what it does. This is the single most expensive misunderstanding in the market: treating fluency as knowledge.
And it should not be treated as the variable that decides a project. Model choice is real but small next to the quality of your material, the accuracy of retrieval, and whether escalation to a person works. We have measured same-model reruns that varied more than two different models did — which means a single comparison run is not a measurement at all.
How this fits the whole
No single capability answers a question on its own. A conversation passes through several in sequence — understanding what was asked, finding the relevant material, composing a reply, checking it before it is sent — and the quality of the result is set by the weakest link rather than the strongest.
That has a practical consequence for evaluation. Vendors tend to demonstrate their strongest component, and a system with excellent retrieval and weak language handling will demo beautifully and disappoint in production, because the demo was conducted in the language and phrasing the system handles best.
It also explains why grounding matters more than raw capability. A more capable model that answers from its own training rather than from your material produces confident, fluent, unsupported answers — which is a worse outcome than a less capable one that retrieves correctly and declines when it cannot. Capability without grounding increases the cost of being wrong rather than reducing it.
The pieces are described separately here because that is how they are evaluated and configured. They are not experienced separately: a customer asking a question encounters one system, and judges it as one.
Where this sits in a conversation
- Something arrivesA typed message, a spoken sentence, an uploaded document. The first job is establishing what was actually received — which language, which script, whether it is legible, whether it is one question or several.
- It is interpretedWorking out what is being asked rather than what words were used. The same question arrives phrased twenty different ways, in two languages, often mixed, frequently misspelt, sometimes as a fragment.
- Material is retrievedThe relevant part of your own approved content is found. This is where answer quality is largely decided: a correct answer assembled from the wrong source is still wrong.
- A reply is composedIn the language of the question, in the configured tone, from the retrieved material and nothing else. Where the material is silent, the reply says so rather than filling the gap.
- It is checkedBefore sending, the reply is examined for claims the retrieved material does not support and for personal data that should not be repeated back. This runs on every reply.
- It is deliveredAs streamed text, as speech, or as a structured response — and the conversation is recorded so that what happened can be reviewed later.
Why this is built rather than bought in
Every capability described here could, in principle, be obtained by calling somebody else's service. That is how most assistants in this market are assembled, and it is why so many of them cannot answer the question that decides regulated procurements: where does the data go.
When a component is a call to an external provider, every question that passes through it leaves the organisation. That may be perfectly acceptable for a retailer answering questions about opening hours. It is usually not acceptable for a bank explaining a transaction, a hospital confirming an appointment, or a public body handling a citizen case — and the constraint is architectural, so it cannot be configured away later.
The second consequence is control over behaviour. A capability obtained as a service behaves the way the provider decides, changes when the provider changes it, and cannot be tuned for the specific way your customers speak or write. A capability that runs inside your own estate can be adjusted for dialect, for your terminology, and for the particular failure modes your material produces.
The third is continuity. External services are deprecated, repriced and withdrawn. A deployment whose core capability depends on somebody else's roadmap inherits that roadmap, including the parts nobody announced in advance.
Measuring this component honestly
| Measured in which language? | Nearly every published benchmark in this field was developed against English. An overall figure that averages across languages hides exactly the gap that matters in this market. |
|---|---|
| Measured on what input? | Clean or realistic. Read speech or spontaneous speech. Typed text or phone-typed text with autocorrect. The difference between these is usually larger than the difference between vendors. |
| Measured by whom? | Self-reported figures with an undescribed method are marketing. Ask for the test set and the procedure. |
| What counts as correct? | A surprising number of published figures count a partially correct answer as correct. Ask what the scoring rule was. |
| How does it fail? | A component that degrades gracefully is worth more than one with a higher headline figure that fails silently and confidently. |
| Does it report uncertainty? | A component that surfaces low confidence lets the system confirm rather than guess. One that hides it produces confident errors downstream. |
What to ask about this specifically
Ask for the Arabic figure
Not the overall figure. Nearly every published benchmark in this field was developed against English, and the gap between the two languages is where deployments disappoint.
Ask how it was measured
Against what test set, by whom, on what kind of input. A number without a described method is marketing rather than measurement.
Ask what it does when uncertain
Whether uncertainty is surfaced or hidden. A component that hides low confidence produces confident errors downstream.
Ask about real conditions
Noisy audio, poor scans, dialect, informal phrasing, mixed languages. Laboratory conditions are not predictive of contact-centre reality.
Ask where processing happens
For any component touching personal data, this is a procurement question rather than a technical curiosity in regulated sectors.
Ask what is retained
What data this component keeps, for how long, and whether it is used to improve anything.
Common questions
We treat that as an implementation detail rather than a selling point, and deliberately so: it changes as better options appear, and it is not what decides whether your deployment works. What matters is that answers are grounded in your material, checked before they are sent, and judged in both languages on your own questions.
Not reliably. In a grounded assistant, answer quality is dominated by the quality and organisation of your own material. We have measured cases where the run-to-run variation of the same model exceeded the difference between two different models.
Any language model can. That is why answers are built from your material, why a check runs on the finished reply against that material, and why the honest question to ask any vendor is not "how accurate is it" but "show me what it does when it does not know".
No. Your material is used to answer the question that came with it, and nothing else. This is a question worth asking every vendor explicitly, and worth getting in writing.
Yes — tone, formality, length and what it must not discuss, set per agent and written separately for each language rather than translated from one.
The correct behaviour is to say so rather than degrade quietly. A clear refusal under load is far better than a deteriorating answer, and that is a design decision taken in advance.