What is Voice Assistant?
Command and dialogue data for voice assistants, usually with intent annotation, covering the full chain from wake word to understanding to response.
Voice assistant data is speech collected for the command-and-response interaction pattern: a short request, often followed by a system reply and sometimes by a correction. It is close to speech commands but distinguished by the multi-turn structure.
What makes it its own category is the error case. Assistants are judged on how they handle a request they did not understand, and the data that trains that behaviour is the correction, the repetition and the reformulation, which a corpus of clean commands does not contain.
The uses are wake-word and command recognition, intent classification, and the recovery behaviour after a failed turn. The third is where most deployed systems are weakest and where the data is scarcest.
What buyers get wrong
What buyers actually need is intent plus slot annotation, not just audio and transcription. The intent taxonomy has to align with the schema the buyer already runs.
The specification detail that decides everything
Whether the intent schema comes from the buyer or is designed by us. This is the dividing line in the quote.
This is the line item that most often separates a dataset that works from one that gets re-ordered. It belongs in the specification before production starts, not in the delivery review.
How we source it
We do not hold inventory in this category. A requirement comes in, we match it to a producer who can meet the specification, and we agree the quality bar with both sides before recording begins. A pilot batch goes first so misalignments surface early.
Scenarios this covers
Buyers rarely ask for a category by name. They describe a situation, and the situation is what tells us whether this category is the right one. If yours is in the list, name it in the brief and it goes straight into the specification. If it is not, describe it anyway, because it usually means the requirement sits in a neighbouring category.
What good Voice Assistant looks like
Assistant data is judged on whether it contains the failure paths, because that is where deployed systems break.
-
Multi-turn structure preserved
The request, the response and any follow-up kept as a linked unit rather than as isolated utterances, because the interaction is the unit a system is trained on.
-
Correction and reformulation captured
The second attempt after a failed turn is the training material for recovery, and it is the first thing a cheap corpus leaves out.
-
Speaker distance and device conditions varied
Assistants are used across a room, and a corpus recorded at a fixed close distance does not describe that.
-
Wake word variants included
Mispronunciations and near-misses are what the detector has to reject, and they are absent from a corpus of clean invocations.
-
Intent labels with an explicit out-of-scope class
A corpus without a category for requests the system should decline produces a model that answers everything.
Public datasets in this category
These are openly documented resources, not products we sell. Each one covers part of the category, and knowing where each stops is usually what decides whether a project needs a collection of its own.
-
Snips
A crowdsourced corpus of assistant commands with intent and slot labels, collected for a now-discontinued voice platform. Widely used, and its recording conditions are crowd-sourced phone and laptop microphones rather than smart speakers.
-
SLURP
A spoken language understanding corpus covering home-assistant tasks, recorded with a range of speakers and scenarios. It is one of the few public sets that includes the far-field and multi-task conditions assistants actually face.
-
Fluent Speech Commands
Smart-home commands from 97 speakers with intent and slot annotation. Small, clean, and useful as a starting point rather than a production corpus.
-
Why the gap is structural
The largest assistant corpora belong to the companies that operate the assistants, and they are not released. Public sets are research-scale, which is why a production assistant is always trained on commissioned data.
Questions to ask a supplier
Questions that reveal whether the corpus was designed around the interaction or around the utterance.
- Are multi-turn sequences kept linked, including the follow-up after a failure?
- How many turns in the corpus are corrections or reformulations?
- What speaker distances and device conditions are covered?
- Are near-miss wake words included as negatives?
- Is there an out-of-scope intent class, and how is it populated?
The vague answer in this category concerns the wake word. A supplier who describes the command corpus without saying whether the wake word is included and separately labelled has merged two recognition problems that fail differently. A missed wake word and a misheard command have different costs, and a corpus that does not separate them cannot be used to tune either.
A verifiable answer states the device conditions, the distance bands, the wake word handling, and whether any near-miss audio was collected. Near misses are the utterances that resemble the wake word and are not it, and they are what determines the false-accept rate. A supplier who has never collected them has never measured the thing that matters most.
Technical attributes
The items below are the ones a specification can hold a producer to, and the ones that decide whether a delivery is usable for training rather than only present.
| Turn structure | Multi-turn sequences linked, with the turn count stated |
|---|---|
| Recovery cases | Corrections and reformulations labelled |
| Speaker distance | Range covered, documented per session |
| Device conditions | Documented and varied |
| Wake word negatives | Near-misses included as a labelled set |
| Delivery format | Audio with linked turns and intent labels including out-of-scope |
The distance band column decides field performance, and it is the one most often reduced to a single value. A smart speaker is used across a room, and the acoustic difference between one metre and four metres is larger than the difference between two microphone models. The bands have to be specified and counted.
The values come from the device and the room. A speaker in a kitchen, a phone in a car and a wearable on a wrist have different noise floors and different reverberation. The specification should describe the deployment room rather than the category, because the supplier has no way to guess it.
A mistake here is discovered by users rather than by tests. The model passes evaluation because the evaluation was recorded under the same single condition, and then it fails in the room it was built for. The remedy is a collection that includes the missing bands, which is a full cycle rather than an adjustment.
How Voice Assistant is collected
The design question is which failure paths to provoke, and it is answered before recording starts.
- Interaction script design. Prompts are written to produce not only successful requests but the failed turn and the correction that follows it.
- Device and distance setup. Recording covers the distances and devices the product will meet, because a fixed close-microphone setup produces a corpus that overstates accuracy.
- Negative wake word capture. Near-miss invocations and ordinary speech resembling the wake word are recorded deliberately, since these are what the detector has to reject.
- Multi-turn recording. Sessions are recorded as interactions rather than isolated utterances, so the turn structure survives into the corpus.
- Intent labelling with an out-of-scope class. Every turn is labelled, including requests that should be declined, and the out-of-scope class is populated deliberately rather than left empty.
After recording, the wake word and command segments are separated and labelled, the near-miss audio is verified as containing no commands, and the files are packaged with per-utterance metadata covering device, distance and room. The near-miss verification is the step that makes the false-accept rate measurable.
The pilot for an assistant corpus is a short run at the distances and in the rooms the specification names, because the property being tested is the acoustic difference between one metre and four metres, and a single-position run cannot show it. The pilot also establishes whether the near-miss utterances can be collected at all, since they have to be recorded deliberately and speakers do not produce them on request without prompting.
Acceptance is checked on the count per distance band and on the near-miss set, verified as containing no commands before the batch is accepted. The specification should state the bands and the near-miss count before recording starts. Where the pilot shows the near-miss set is thin, the elicitation is redesigned rather than the false-accept target lowered, since the target cannot be measured without that material.
How a delivery goes wrong
The defects below are the ones that recur across this category. Each is decided at collection or annotation time, which is why none of them can be repaired in delivery review.
-
Wake-word and command audio were mixed
The wake word and the command that follows are different recognition problems with different error costs. A corpus that does not separate them cannot be used to tune either one.
-
Device and distance were not recorded
A smart speaker at three metres in a kitchen behaves nothing like a phone held to the mouth. Without device and distance metadata, the corpus cannot be matched to the deployment, and the mismatch is the main source of field failure.
-
No false-trigger material
Corpora usually contain only successful commands. The audio that triggers a device by accident, which is ordinary conversation, is what determines the false-accept rate and it is almost never included.
Why this matters to buyers
The direct driver is that assistants fail in conversation rather than in single commands. A system that recognizes a clean request and then has no idea what to do when the user repeats it differently has failed at the point where the user notices.
The second driver is false activation. A wake word detector that fires on ordinary conversation is worse than one that occasionally misses, and training it requires negatives that only appear in a corpus built to include them.
An assistant that wakes when it was not addressed loses user trust faster than one that misses a command. The behaviour is noticed by everyone in the room and reported immediately, and the underlying cause is nearly always a corpus without near-miss audio. That material is cheap at collection time and impossible to reconstruct later.
The second cost is the interaction design. Once the wake-word threshold is raised to control false accepts, the product has to compensate with visual cues, longer listening windows or a second model, and that redesign costs more engineering time than the original corpus. Teams that collect the negatives up front avoid the whole chain.
An assistant corpus with counted distance bands and a verified near-miss set gives a wake-word threshold that can be set from data rather than by trial in the field. The product ships with a false-accept rate the team has measured, which is the difference between a launch and a support queue.
The second gain is that the room conditions are documented. A speaker in a kitchen and one in a car have different noise floors, and a delivery that records the rooms can be extended to a new deployment environment without re-recording the existing ones. That record is what lets a product line grow by room rather than by model.
Specification at a glance
| Category | Voice Assistant |
|---|---|
| Group | Speech data |
| Critical spec | Whether the intent schema comes from the buyer or is designed by us. This is the dividing line in the quote. |
| Included by default | Pilot batch, metadata schema, source and consent documentation |
| Pricing | Quoted from specification. No published rates |
Voice Assistant across languages
This category is available in every language we cover. The difficulty changes with the language, which is why each language page documents its own constraints.
Related categories
-
Call Center Speech
Customer-service calls, simulated rather than intercepted, capturing both the agent and the caller side, used for call center QC, intent recognition, and dialogue systems.
-
Conversational Speech
Speech from natural conversation between two or more people, on open or semi-structured topics, used for conversational AI, voice assistants, and small talk models.
-
Singing Voice
Vocal recordings with melody, in both a cappella and accompanied form, used for singing voice synthesis, music information retrieval, and lyric alignment.
-
Speech Commands
Targeted recordings of short command words or phrases, usually with many speakers reading each entry several times over, used for wake words and on-device command recognition.
-
Read Speech
Recordings of speakers reading specified text, with clear pronunciation and known text, the base material for TTS and ASR.
-
Podcast Speech
Long-form podcast and interview audio, either solo monologue or two-person conversation, used for long-form speech recognition and speaker modeling.
Questions about Voice Assistant
How is this different from speech commands?
Speech commands are isolated utterances. Voice assistant data preserves the interaction: the request, the system response, and what the user does when the response is wrong. That second part is where the recovery behaviour is trained.
Why does speaker distance matter?
Because assistants are used across a room, and far-field audio has reverberation and a lower signal-to-noise ratio than close-microphone audio. A model trained at a fixed close distance meets far-field audio as an unseen condition and degrades.
What are near-miss wake words for?
They train the detector to reject. A corpus containing only correct invocations produces a detector that fires on anything similar, and false activation is the failure users complain about most.
Do you label intents?
Yes, including an out-of-scope class for requests the system should decline. A corpus without that class trains a model that answers everything, which is a behaviour problem rather than an accuracy one.
Do you have Voice Assistant available now?
No. We do not hold inventory. Everything is produced against a specification. That means the timeline starts when the spec is agreed rather than immediately, and it also means the data matches your requirement instead of approximately matching something already built.
Can this be combined with other categories in one delivery?
Yes, and it is common. A single specification can cover several categories across several languages, with one pilot batch and one quality bar. It usually reduces total cost because contributor recruitment and project setup are shared.
What does the consent documentation cover?
Signed contributor consent stating the intended use, the collection methodology, and the annotation guideline the data was produced under. For projects involving EU data subjects the chain is built to satisfy GDPR, including the transfer mechanism. The terms for moving the data across a border.
Request Voice Assistant
Tell us the language, the hours, and what the data needs to look like. You will get a real number and a real timeline, not a range. If we cannot source it well, we will tell you that instead.
- Pilot batch before the full run, so problems surface early.
- Consent documentation delivered with the data.
- No medical or clinical data. No recorded telephone calls.
- You send the spec Language, hours, recording conditions, and the deadline.
- We reply within two business days A real number and a real timeline, not a range.
- You approve a pilot batch A small run first, so problems surface before the full order.
- Full run, then delivery with documents Audio, transcripts, and the consent record for every speaker.