· — Dishant Sethi ·Jul 9, 2026·13 min read

How to Evaluate Voice AI Agents: Metrics Framework and Tooling

Five-layer voice AI evaluation framework: latency by stage, WER, barge-in handling, response quality, and call outcome rate — with Langfuse instrumentation and CI testing patterns.

Key Takeaways

  • A production voice AI evaluation framework requires five metric layers: end-to-end latency, transcription accuracy (WER), barge-in handling, response quality, and call outcome rate — measuring only LLM output misses 80% of what users actually experience
  • Barge-in false positive rate is the most undertracked metric: every time the agent incorrectly stops mid-sentence because of a background noise, user trust drops — and it never recovers in that call
  • End-to-end turn latency target is <1,000ms at p50 — budget: STT 100–300ms, LLM first token 200–500ms, TTS first audio 100–300ms
  • Prodinit instruments voice AI evals with Langfuse traces per turn, capturing per-stage latency and custom quality scores before each rollout gate

The standard LLM eval stack — hallucination rate, faithfulness, ROUGE scores — tells you almost nothing about whether a voice AI agent is usable. A response can score 4.8 out of 5 on faithfulness and still destroy user trust because it took 2.3 seconds to reply, or because the agent cut the user off mid-sentence.

A voice AI evaluation framework measures the full pipeline: STT accuracy, latency at each stage, VAD sensitivity, LLM response quality, TTS naturalness, and whether the call achieved its business purpose. Each layer fails independently. Each failure has a different fix.

Why Voice AI Evaluation Is a Different Problem

Voice AI evaluation differs from LLM evaluation in three structural ways: it is real-time, multimodal, and irreversible. A turn that takes 2.5 seconds feels broken to a phone caller even if the response is factually correct. A word mis-transcribed by STT creates a wrong LLM input that TTS then speaks confidently — the entire pipeline produces a hallucination from a transcription error, not an LLM error. And unlike chat, the user cannot scroll back; the wrong answer is already spoken and trust is gone.

Production voice AI runs four pipeline stages in sequence on every turn: VAD (voice activity detection) triggers STT, STT output feeds the LLM, LLM output feeds TTS, and TTS audio streams back to the caller. Every stage has its own failure modes and its own latency contribution. An eval framework that only measures the LLM stage is measuring one of four problems.

Running 90K+ calls/month across Cuebo's self-hosted LiveKit deployment, Prodinit tracks latency, WER, barge-in events, and call outcomes as first-class production metrics. The five layers below map directly to the failure modes we encounter most often.

The Five-Layer Voice AI Evaluation Framework

A complete voice AI evaluation framework covers five measurement layers: end-to-end latency, transcription accuracy (WER), barge-in handling, response quality, and call outcome rate. Each layer is independently measurable and independently debuggable — a regression in one does not necessarily indicate a problem in another, and fixing the wrong layer wastes weeks.

Layer 1 — End-to-End Latency Budget

End-to-end turn latency is the most user-visible metric. It is the time from when the user stops speaking to when the user hears the first word of the agent's response. The target for phone-channel voice AI is below 1,000ms at p50; above 1,500ms at p50, callers reliably perceive lag; above 2,000ms, conversations break down.

The latency budget breaks down by stage:

StageTechnologyTarget (p50)Target (p95)
STTDeepgram Nova-3100–200ms<350ms
LLM first tokenGPT-4o (streaming)200–400ms<700ms
TTS first audioElevenLabs / Azure TTS100–250ms<400ms
Network + bufferingWebRTC / SIP50–100ms<200ms
Total<1,000ms<1,650ms

Track at the turn level, not as session averages. A session average of 800ms can contain individual turns at 2,500ms — those are the turns users remember, and they are invisible in blended metrics.

In Langfuse, Prodinit creates a root trace per call with four child spans — one per pipeline stage — with explicit start_time and end_time. This gives per-stage latency histograms across real calls, making p50/p95 regressions visible within hours of a new deployment reaching production traffic.

Layer 2 — Transcription Accuracy (WER + Confidence Score)

Transcription accuracy determines the quality ceiling of everything downstream. The LLM cannot correct a STT error it never sees — it reasons from the transcript, not the audio. WER (Word Error Rate) is the percentage of words in the transcript that differ from the ground-truth utterance.

For English business voice AI, Deepgram Nova-3 achieves WER between 2–4% on clean speech (Deepgram Benchmarks, 2025). In real conditions — telephony compression, background noise, accents, filler words — WER typically rises to 6–12%. Track WER per call type, not as a single aggregate: a support call with product codes and SKUs has different failure modes than an appointment scheduling call.

Track two signals per STT response in production:

  • Word Error Rate on a sampled weekly validation set of 50–100 calls with human ground-truth transcripts
  • Confidence threshold rate — the % of turns where STT confidence falls below 0.75; route these to a human review queue or trigger an in-call clarification prompt

When Prodinit integrated Deepgram into Cuebo's five-pipeline architecture, per-pipeline WER tracking revealed that the Sarvam pipeline (Hindi support) had 3× higher error rates on product codes than the Azure Speech pipeline — a routing issue that was entirely invisible in aggregate WER metrics.

Layer 3 — Barge-In Handling (False Positive and Negative Rate)

Barge-in handling is the most undertracked metric in voice AI evals and one of the most visible failure modes to callers. When the user speaks while the agent is mid-sentence, the VAD should detect it and stop the agent. Two failures are possible:

False positive barge-in: the VAD triggers on something that was not an intentional interruption — background noise, a brief affirmation ("uh-huh"), or line noise stops the agent mid-sentence. User experience: the agent randomly stops talking.

False negative barge-in: the user speaks to interrupt, the VAD does not trigger, and the agent continues talking over them. User experience: the agent ignores you.

Both are trust killers, but they pull the VAD sensitivity parameter in opposite directions. Lower sensitivity reduces false positives but increases false negatives. The optimal point depends on the deployment environment: a noisy contact center needs different settings than a quiet inbound callback.

Track per session:

# Instrumentation pattern: tag every VAD event with energy and confidence
barge_in_events = count of VAD triggers per session
false_positive_rate = % triggers where energy_db < NOISE_FLOOR_THRESHOLD
false_negative_rate = % turns where user began speaking (detected in post-call review)
                      but agent did not stop within 500ms

For the ConversAI platform processing 10K calls/day, Langfuse tags every barge-in event with the VAD provider's confidence score. Prodinit uses the resulting distributions to tune VAD sensitivity thresholds between pipeline variants without running manual call reviews for each change.

Layer 4 — Response Quality (Faithfulness + Turn Completion Rate)

Response quality in voice AI has two dimensions: faithfulness (does the response accurately reflect the system prompt, knowledge base, and conversation context?) and turn completion rate (did the agent cover what this turn required without the user having to repeat themselves?).

For faithfulness, apply the LLM-as-judge pattern from the LLM evaluation rubric: score each turn on a 1–5 scale across faithfulness, relevance, and safety using a separate judge model — GPT-4o or Claude Sonnet — that receives the turn transcript and system context. Calibrate the judge on 50–100 human-labeled turns before deploying it to CI; target Cohen's kappa ≥ 0.75 per dimension before trusting automated scores in deployment gates.

Turn completion rate is distinct from session completion (whether the overall goal was achieved). A turn can be individually faithful — the agent said something correct — but miss the conversational goal of that exchange, forcing the user to rephrase or the agent to loop back.

Track both at the turn level. High faithfulness with low turn completion usually means the agent is technically correct but misses conversational intent. Low faithfulness with high completion suggests the agent is going off-script but users are not noticing — which matters for regulated industries where script adherence is audited.

Layer 5 — Call Outcome Rate

Call outcome rate is the business metric: the percentage of calls where the stated purpose of the call was achieved. For a scheduling agent, that is a confirmed booking. For a support agent, that is resolution without escalation to a human. For a sales qualifier, that is a completed lead disposition.

This metric is the final arbiter of whether the other four layers are calibrated correctly. You can have sub-500ms latency, 2% WER, zero false-positive barge-ins, and 4.8/5.0 faithfulness scores — and still have a 35% call outcome rate because the agent handles edge-case intents or multi-turn goal tracking poorly.

Track call outcome rate alongside the four preceding metrics in the same Langfuse dashboard. A drop in call outcome rate that does not correspond to regressions in layers 1–4 points to prompt, knowledge base, or conversation flow issues — not pipeline issues. That distinction saves significant debugging time.


Running Voice AI Evals in CI Without a Real Phone Line

The challenge with voice AI CI is that you cannot reproduce the full acoustic pipeline — telephony compression, network jitter, environmental noise — in a standard test harness. What you can test deterministically are the LLM reasoning and conversation flow layers through synthetic turn sequences.

Synthetic call simulation uses an LLM prompted to play a specific caller persona — a frustrated customer, a first-time user, an edge-case intent — that exchanges turns with the voice AI agent via text. STT and TTS are bypassed; you test faithfulness, turn completion rate, and multi-turn goal tracking on hundreds of scenarios automatically. Prodinit runs 200+ synthetic call scenarios per deployment on ConversAI, covering 12 caller archetypes and 6 edge-case intent categories. A deployment gate requires ≥ 92% scenario pass rate before proceeding.

Audio regression testing replays a fixed set of 50–100 recorded real-call audio clips through the full STT pipeline on every build. Compare the new transcript against the reference transcript from the previous build. Any WER increase above 0.5% on the validation set triggers a build failure. This catches STT regressions from model updates, configuration changes, or dependency upgrades before they reach users.

Latency canary runs deploy the new build to 1–2% of live traffic, measure per-stage latency via Langfuse, and compare to the previous build's p50/p95 baseline. If any stage regresses by more than 100ms at p95, the rollout halts automatically. This is the same progressive rollout pattern Prodinit used for the ConversAI distillation deployment — the same gate logic that kept five rollout stages clean on first attempt.

Together these three gates catch the majority of regressions before they reach users: conversation logic regressions (synthetic simulation), STT regressions (audio replay), and latency regressions (canary).

Instrumentation Stack: Langfuse for Turn-Level Tracing

Langfuse is the observability layer that makes voice AI evaluation data actionable across thousands of calls without manual review. Every production call produces a root trace with four child spans (VAD, STT, LLM, TTS) and custom scores attached per turn: faithfulness (from the LLM judge), confidence (from the STT provider), and task_complete (from the agent's self-reported disposition).

The core Langfuse instrumentation pattern for a voice AI turn:

from langfuse import Langfuse
from langfuse.decorators import observe, langfuse_context

langfuse = Langfuse()

@observe(name="voice-turn")
async def process_turn(session_id: str, audio_bytes: bytes) -> str:
    # STT span
    langfuse_context.update_current_observation(name="stt-stage")
    transcript, confidence = await stt_client.transcribe(audio_bytes)

    # LLM span
    langfuse_context.update_current_observation(name="llm-stage")
    response = await llm_client.stream(messages=build_messages(transcript))

    # Attach turn-level scores
    trace_id = langfuse_context.get_current_trace_id()
    langfuse.score(trace_id=trace_id, name="stt_confidence", value=float(confidence))
    langfuse.score(trace_id=trace_id, name="low_confidence_flag", value=1 if confidence < 0.75 else 0)

    return response

The faithfulness judge runs asynchronously after the turn completes, posting a score back to the same trace. This keeps the real-time turn path under 5ms of instrumentation overhead while still producing a per-turn quality record queryable across the full call corpus.

Prodinit uses weekly Langfuse dataset exports for two purposes: feeding the distillation pipeline (high-quality turns with faithfulness ≥ 4 and confidence ≥ 0.80 become training examples for the next fine-tuning run) and populating the synthetic call scenario library (low-confidence turns that still resolved correctly become regression test cases). The evaluation framework compounds value across every retraining cycle.

Get Prodinit's AI engineering guides in your inbox

Deep-dives on production LLMs, voice AI, and MLOps — published weekly. No sales emails.

Frequently Asked Questions

WER (Word Error Rate) is the percentage of words the STT model transcribes incorrectly relative to the ground-truth utterance. It matters because STT errors propagate uncorrected through the pipeline — the LLM reasons from the transcript, not the audio. A 10% WER on product names or key entities causes downstream LLM errors that score low on faithfulness and directly reduce call outcome rate.

Sub-1,000ms at p50 is the production target for phone-channel voice AI. At 1,500ms, callers notice lag; above 2,000ms, the conversation feels broken. Track latency per pipeline stage — STT under 300ms, LLM first token under 500ms, TTS first audio under 300ms — so you can isolate which stage caused a spike rather than debugging a single blended end-to-end number.

Instrument every VAD event with the audio energy level and the VAD provider's confidence score in your trace logs. Flag events where energy is below your noise floor threshold but a barge-in was recorded — these are likely false positives. Review flagged events weekly to calibrate VAD sensitivity. A false positive rate above 5% per session measurably degrades caller trust and call outcome rate.

Yes — using synthetic turn simulation (an LLM plays the user, bypassing STT and TTS to test conversation logic and multi-turn goal tracking) and audio regression replay (pre-recorded clips run through STT on every build to catch transcription regressions). These two gates together catch LLM reasoning failures and STT regressions. Full acoustic path testing requires live traffic and is better handled by 1–2% canary deployments with automated latency gates.

Recalibrate your WER validation set and LLM judge quarterly, or whenever you change the STT model, LLM version, or TTS provider. Recalibrate barge-in thresholds whenever the deployment environment changes — different telephony provider, new call center noise profile, or new user locale. Call outcome rate should be reviewed weekly; it is the leading indicator of pipeline drift before it shows up in individual metric regressions.

Stay ahead in AI engineering.

Get the latest insights on building production AI systems, be the first to explore approaches that actually work beyond the demo.

Start a Project →