Filtering profanity in transcripts: where quality breaks
The standard solution looks simple: a dictionary of forbidden words at the output of recognition. On a studio recording with a single speaker, it works — and that is exactly why it seems that profanity filtering is done.
On a real stream, the rule misses a noticeable share of profanity and at the same time cuts neutral words, after which the transcript stops being a source trusted by quality control.
Noisy recognition recordings suffer the most: interruptions, on-hold music, telephone channel compression. The model substitutes a phonetically similar word, and profanity in the speech transcript either disappears or appears where it was not. The dictionary compares strings, not meaning, so it does not catch such a substitution.
The second layer is rule evasion. Profanity arrives in Latin characters, broken up by hyphens, asterisks, spaces inside a word, euphemisms, and the slang of a particular shift.
At the same time, the opposite error occurs: surnames, place names, and everyday words fall under the rule — and the operator gets a review of a phrase that was not there.
In a two-channel conversation, attribution is added. Voice separation on interruptions confuses roles, and the customer's utterance is attributed to the operator, although the assessment of work depends on exactly this.
This is where the quality of the contact center transcript breaks: the problem is not that the word is absent from the dictionary, but that the decision about it is made without the context of the conversation.
We analyze how this is addressed: a domain dictionary combined with context rules, a confidence threshold instead of strict string matching, marking of disputed fragments for spot-checking, and monitoring the false positive rate after each edit.
What managed speech processing delivers: measurable effects
Before filtering, the transcript lives in a mode of manual refinement: an operator proofreads the text and edits vocabulary — this is 20–30% of utterances in call center recordings.
When transcript cleanup happens inside recognition rather than on top of finished text, the share of manual transcript editing falls to single-digit percentages, and the recording goes into the system of record already fit for use.
The key metric by which we accept the work is the false positive rate on standard vocabulary.
Russian profanity is homonymous: surnames, place names, drug names, and colloquial "blin" or "khren" fall under the rule, so the filter is built not on a word list but on an exception dictionary, phrase context, and morphology. On the test set, we keep false positives below 0.5%, and missed real profanity within 1–2%.
A unified speech standard provides predictability: one processing policy works for telephony, a meeting room microphone, and webinar recordings — there is no need to maintain separate rule sets for each channel.
We take the open model Whisper as a basis and fine-tune it on the customer's domain dictionary so that names, abbreviations, and industry terms are not masked by the filter along with profanity.
We test speech recognition stability on long recordings where channel quality fluctuates: narrowband telephony, overlapping voices, background noise.
The metric here is the share of words requiring editing after processing and its spread across channels: if the telephone transcript and studio transcript differ by a factor of several, the policy is rebuilt until convergence.
Filtering in the recognition stream vs. post-processing: what to choose
The fork is simple: the rule triggers inside the decoder while audio is being converted into text, or already on the finished transcript. The first option does not add latency to the stream; the second sees the phrase as a whole and works with dictionaries and context.
The choice is dictated by the speech processing architecture: streaming subtitles and voice input on one side, final transcription for analytics and minutes on the other.
Separately, it is decided where the original is trimmed. Masking fragments in the stream leaves no 'raw' text, while post-processing of the transcript preserves the source and allows disputed triggers to be reviewed.
| Option | When it fits | Limitations |
|---|---|---|
| Rules at the recognition stage | Stream: subtitles, telephony, voice input — an unacceptable word must not appear in the output at all | The dictionary is built into the model: updating the list requires rebuilding and quality checks. Homophones and names suffer, recognition accuracy drops |
| Post-processing of the transcript | Analytics, minutes, long recordings where a delay of seconds is acceptable | Audio is unavailable: word merges and nonstandard spellings slip through. A second pass and a stable intermediate format are needed |
| Hybrid: decoder bias plus a text layer | Mass services where the word list changes and latency is critical | Two rule sets must be synchronized so masking does not trigger twice |
What exactly to mask with — asterisks, a placeholder tag, or omission — is decided at the same step and affects how search and analytics later read the transcript.
Implementation stages: from recording audit to handover of regulations
The work proceeds in iterations: first we look at real recordings, not demo examples, and only then choose the scheme. This way the filter does not start suppressing ordinary words or miss what it was installed for.
- Recording audit. We export an archive for a typical period: calculate the share of profanity, examine recording channels, background noise, and voice overlap. Without this, there is nothing to tune thresholds on.
- Processing scheme. We determine where the filter sits — before recognition, on the audio track, or after, on the text — and what happens when it triggers: muting, a signal, replacement, or a flag for a moderator.
- Annotation of the control corpus. We manually annotate several hours of recordings: where profanity is present, where it is not, and separately disputed cases and similar-sounding words. The corpus becomes the benchmark for all subsequent checks.
- Setup and calibration. We build dictionaries taking word forms into account, set thresholds separately for clean and noisy tracks. False positives at this stage are more important than misses: they break trust in the filter.
- Check on the control set. We run the annotated corpus and count how many were caught, how many were missed, and how many normal words were affected. We look at the worst fragments, not the average ones.
- Acceptance of recognition quality. We make sure the filter has not degraded the text itself: the meaning of phrases is preserved and latency is within acceptable limits. Acceptance is based on agreed metrics, not on listening.
- Handover of regulations. We provide documentation: how to add a word, update the dictionary, recheck changes on the same corpus, and connect a new recording channel. The corpus and rules remain with the customer.
What remains with the customer: dictionaries, rules, and regulations
The project is closed not with a demo but with a set of artifacts that the customer's team edits without us. Everything that affects filter behavior lives in version-controlled settings files, not inside the handler code — so a dictionary edit can be reviewed and rolled back.
- Term dictionaries. A base list of profane stems with normalization: case, transliteration, Latin homoglyphs, stretched repeated letters. As a separate block, a list of false positives so that legitimate words inside long tokens are not masked.
- Sensitivity profiles. Threshold sets for channels and scenarios: strict for broadcast and recording of customer conversations, soft for internal transcription, where transcript completeness matters more than text cleanliness.
- Fragment replacement rules. Character-by-character masking, replacement with a neutral label, word deletion while preserving time codes — the subtitle does not shift relative to the audio.
- Recognition confidence threshold. A word is masked only when the model is confident in the hypothesis; on noisy tracks, ordinary speech stops being replaced.
- Operating regulations. Who updates the dictionary, how often, how the check is run on the annotated set, and what to do in case of a false positive in the production loop.
- Documentation and handover. Description of settings file formats, audio flow diagram, procedure for deploying the profile, and rollback to the previous version.
We deliver it in your repository together with sample recordings and a set of test cases — reproducibility matters more than verbal agreements.
Case study: contact center, defect rate in transcripts before and after
A contact center with a flow of several thousand dialogues per day exported transcripts to quality control, shift manager reports, and a sample for annotation.
Unacceptable fragments remained in the raw text — profanity directed at the operator, insults in customer utterances — and they spread through internal documents together with the transcript.
Metrics before and after
| Metric | Before implementation | After |
|---|---|---|
| Share of unacceptable fragments in transcripts | 4.8% | 0.4% |
| False positives on normal vocabulary | 7.1% | 1.3% |
| Dialogues requiring manual editing | 21% | 4% |
What reduced false positives
The key was not expanding the dictionary but separating two modes: a confident match is masked immediately, while a disputed one is not cut out but flagged and sent for review.
Thresholds were tuned on our own annotated set: the open Common Voice corpus plus several thousand dialogues with double annotation, where disputed utterances were independently annotated by two reviewers.
Masking was made reversible: a service label remains in place of the fragment while preserving the utterance structure, so speech analytics on pauses and interruptions continues to work, and manual editing dropped from a fifth of dialogues to isolated cases. We handle similar flows the same way — from annotation to thresholds.
How does masking differ from deleting recording fragments?
The difference shows in what happens to the recording timeline. Masking leaves a similar-sounding replacement or a short marker in place of the profane word, so the fragment duration does not change and the recording timing remains original.
Deletion cuts out the segment entirely: the track gets shorter, and all subsequent time codes shift by the saved fractions of a second.
For an interview archive this is unnoticeable, but for analytics it is not: speech segmentation ties utterances to absolute time, and after deletion the speaker, subtitles, and video diverge.
Preserving the meaning of the phrase also depends on the method.
With masking, the context is restored from neighboring words; with deletion, intonation and connectors are broken, and a short utterance may collapse into an empty line — from such a transcript it is no longer possible to understand what was being discussed.
In terms of processing latency, masking wins: replacement runs through the dictionary on the finished transcript, without rebuilding the audio.
Deletion in the stream requires buffer recalculation and re-splicing of the sound — this adds latency and the risk of clicks at the joints.
In practice, together with speech recognition on Whisper, we more often deploy a hybrid: masking in the text, a short tone or signal of the same duration in the audio.
Then the recording contains no profanity, the timing matches the original, and utterance analytics works without manual time code edits.
Disputed cases: false positives, dialects, names
Homonyms and proper names cause false positives most often: a short word in a different context, or a surname similar in sound to a profane stem, cuts a normal utterance out of the transcript.
We do not decide based on a single match — the verdict is assembled from the phrase context, recognition confidence, and an allowlist of entities collected from reference books and the customer's database.
Disputed fragments are not deleted silently: they are flagged and queued for proofreading, so that a dictionary edit is a setting rather than a rewrite of already delivered results.
The customer's name sounds the same as a profane word — will the transcript suffer?
No. The allowlist of names, place names, and company names takes priority over the general dictionary: in case of a match, the decision is made based on the phrase context and model confidence, not on the fact that a substring occurs.
If confidence is low, the word remains as is with a flag — losing the meaning of an utterance is more costly than missing an isolated case.
What to do about accents, dialects, and mixed languages in one recording?
We expand the dictionary with phonetic pronunciation variants, connect a separate language model for each phrase language, and determine switching as the recording progresses — otherwise an insertion in another language inside a Russian utterance is recognized as a random set of sounds.
We check accented and dialectal forms on the customer's real recordings, not on synthetic data: this shows where the model errs systematically and needs additional tuning, and where it is enough to expand the dictionary.
Weak sound, room noise, and overlapping voices are the main source of errors in both directions: the filter either triggers on a harmless word or misses real profanity. Here, cutting off non-speech segments, leveling volume, and a second pass over less confident recognition hypotheses all help. We mask an offensive word rather than cut it out: the meaning and length of the utterance are preserved, analytics metrics are not broken, and the false positive rate stays below the threshold agreed with the customer.Let's discuss the task: we'll assemble rules for your recording flow
To come back with an estimate rather than generalities, we need your material: 20–30 minutes of real recordings with typical voices, noise, and slips of the tongue, plus a brief description of where the text goes after recognition.
From this data, it is clear where recognition errs most often and how many rules will have to be described manually.
- sample recordings — audio from different conditions: a phone call, a meeting room microphone, an outdoor recording;
- requirements for the result — what we consider unacceptable, what may be left in, and who approves disputed cases;
- exception dictionary — names, titles, and terms that must not be cut out;
- text route — where the cleaned transcript goes: to a report, to search, to an archive;
- processing mode — real-time stream or batch upload of already accumulated files;
- acceptance criteria — acceptable miss and false positive rates on your set.
From this we assemble an implementation plan: the order of work, setup timelines, and a pilot on your recordings. We launch the pilot on a limited set — you compare the result on your examples and decide whether to proceed to full scope.
Describe the task: send samples and requirements — we will come back with an estimate, plan, and timelines.