Language Models in Conversation Analysis
Vendors have replaced rule engines with language models. This genuinely improves some tasks, introduces new failure modes, and makes the system harder to audit.
Speech analytics platforms increasingly use large language models for summarisation, categorisation and scoring. The change is real and the trade-offs are not always disclosed.
What improves
Summarisation. Producing a call summary is a task language models do well, and it removes after-call work that agents genuinely dislike.
Categorisation of fuzzy topics. Where a rule needs twenty phrase variants, a model handles paraphrase without enumeration.
Handling variation. Customers describe the same problem in many ways.
Question answering over a transcript. Asking what the customer was promised, and getting an answer grounded in the text.
Zero-shot flexibility. Asking a new question of existing calls without building a rule first.
What gets worse
Explainability. A rule can be shown to an agent disputing a finding. A model's classification cannot be traced in the same way, and "the model determined" is not an answer in a disciplinary process.
Auditability. Compliance evidence needs to be reproducible. A model that is updated by the vendor produces different results on the same call, and the previous determination cannot be regenerated.
Consistency over time. Model updates change behaviour. A category trend spanning an update contains a discontinuity that looks like a business change.
Fabrication. A summarisation model can state something the customer did not say. In a call summary that becomes a CRM note that becomes the record of what was promised.
Cost and latency, which constrain real-time use.
A new dependency on the transcript, which is unchanged: the model reads text, and the text has errors.
The fabrication problem specifically
This is the failure mode that matters most in this application.
A summary that invents a commitment — a refund, a callback, a promise — becomes the account of the call. Later disputes are resolved against it.
It is plausible and fluent, so nobody reviewing it notices.
Mitigations: require summaries to quote or cite the transcript; keep the transcript alongside every summary; sample summaries for accuracy regularly; never let a summary replace the recording as the record.
Measure it. Take a hundred summaries, check each against the transcript, count the statements that are not supported. Most deployments have never done this and the rate is not zero.
Auditability for compliance
Do not use a model as the sole determiner of a compliance outcome.
Where a model flags a potential failure, a human confirms it against the audio, and the human's determination is the record.
Version everything. Which model, which version, which prompt, on what date. Without this, a determination from six months ago cannot be explained.
Keep the input. The transcript and the audio, so any finding can be re-examined independently of the model.
Questions for a vendor
Which components use a model, and which use rules? Frequently unclear.
Can we see the prompt? For a classification affecting people, the instruction given to the model is part of the method.
How are model updates handled? Are we notified, can we pin a version, are historical determinations restated?
What is the fabrication rate on summarisation, measured how?
Can a determination be explained to an agent in a way that survives a challenge?
Where does our data go, is it retained, is it used for training? This is a contractual question and it is the one most likely to have an unsatisfactory answer.
The workable arrangement
Models for summarisation, exploration and fuzzy categorisation, with sampling to check accuracy.
Rules for compliance determinations, because they are explainable and stable.
Humans for anything that reaches a person's record.
That division keeps the capability without putting an unauditable component in the path between a call and an employment consequence.
Testing summary fidelity
The check that matters most where language models generate call summaries that become the record.
Take one hundred summaries across queues.
Read each against its transcript.
Count statements in the summary not supported by the transcript. Commitments, amounts, dates and outcomes are the categories that matter.
Count material omissions — a promise made and not summarised.
Report the rate. It is not zero, and knowing it determines whether the summary can be treated as a record or only as a convenience.
Repeat after every model update, because the rate changes.
Where the rate is material, require the summary to cite the transcript and keep the transcript alongside it. A summary without its source cannot be checked by anyone downstream who relies on it.
More in this section
- Transcription Accuracy and What Degrades It
- The Accent and Dialect Accuracy Gap
- Categorisation and Topic Detection
- Sentiment Analysis: What It Measures
- Emotion Detection and the Science Problem
- Acoustic Measures: Silence, Talk-Over and Pace
- Redaction, PCI and Sensitive Data in Recordings
- Real-Time Analytics and Agent Assist
External reference: AI risk management guidance.