Las alucinaciones de la IA de voz son, con diferencia, el motivo por el que los agentes de voz corporativos se quedan atascados en el piloto y nunca llegan a producción. No es la latencia. Ni los acentos. Ni el SIP. Un chatbot de texto que se inventa una política de devoluciones es una molestia que el usuario puede releer y descartar. Un agente de voz que dice, con un tono cálido, seguro y humano, "Yes, your appointment is confirmed for Tuesday at 3pm" — cuando no existe tal hueco — es un riesgo del que tu equipo de operaciones se entera cuando el cliente se presenta en una oficina vacía.
Este es el manual de ingeniería para lanzar un agente de voz factual: grounding estricto para que el modelo solo hable desde la verdad recuperada, salida estructurada forzada en los turnos transaccionales, un andamiaje de rechazo para que "no lo sé" sea un resultado de primera clase, RAG de baja latencia que cabe dentro del presupuesto de un turno de voz y un arnés de eval de IA de voz que demuestre el grounding antes de que apuntes números de teléfono reales hacia él.
Por qué la modalidad de voz amplifica el riesgo de alucinación
La misma alucinación de LLM que resulta tolerable en chat se vuelve peligrosa por teléfono por tres razones estructurales.
No hay historial que revisar. Los usuarios de chat ojean, releen y pillan al modelo contradiciéndose dos mensajes más arriba. La voz es efímera: una vez dicha, la afirmación desaparece, y el único registro está en la memoria del cliente (normalmente equivocada) o en una transcripción que nadie lee hasta que hay una reclamación. No hay ninguna señal visual de que el agente esté dudando.
La propia voz es una señal de confianza. La prosodia, el ritmo y una voz TTS natural se registran en el cerebro humano como competencia. En CX, quienes llaman puntúan sistemáticamente como más precisos a los agentes que suenan seguros, con independencia de si acertaron. Tu capa de TTS es, en la práctica, un amplificador de confianza atornillado a un modelo que no tiene ni idea de cuándo se equivoca.
La presión del turno empuja al modelo a comprometerse. Un agente de voz no puede quedarse en silencio 4 segundos mientras "piensa": el aire muerto rompe la conversación. Así que la decodificación ocurre bajo presión de latencia, el modelo rellena el hueco, y rellenar el hueco es exactamente cuando los LLM fabulan. El mismo presupuesto temporal que hace que la voz parezca humana (consulta nuestro trabajo sobre arquitectura de voz por debajo de 300 ms) es el presupuesto que tienta al modelo a adivinar.
En conjunto: la voz coge el peor modo de fallo de un LLM y elimina todas las barreras que el usuario tenía antes. Por eso la precisión de un agente de voz con IA es un problema de arquitectura, no de ajuste de prompts.
Los cuatro modos de fallo que de verdad tienes que detener
Los consejos genéricos de "reduce las alucinaciones" no sirven de nada porque las cuatro formas en que un agente de voz miente tienen radios de impacto distintos y soluciones distintas.
- Política inventada. "You can return that any time within 90 days." La ventana real es de 30 días. El modelo interpoló una cifra plausible. Solución: responder solo desde recuperación — lo vemos en la siguiente sección.
- Precio inventado. "That plan is $49 a month." Cuesta 59 $. Los números son los tokens de mayor riesgo que emite un LLM porque son de baja perplejidad al generarlos y de alto coste cuando fallan. Solución: forzar salida estructurada — nunca dejes que los precios pasen por generación de texto libre.
- Confirmación falsa. "You're all set, confirmation number A-4471." No se escribió ninguna reserva. El modelo narró una llamada a herramienta exitosa que nunca ocurrió (o alucinó el ID antes de que la herramienta respondiera). Solución: grounding en el resultado de la herramienta — el agente solo puede confirmar lo que la API devolvió realmente.
- Escalado falso / promesa falsa. "I'm transferring you to a specialist who'll call back within the hour." No existe tal cola. Solución: andamiaje de rechazo más una lista de permitidos con las acciones que el agente está realmente cableado para ejecutar.
Relaciona cada guardarraíl que construyas con uno de estos cuatro. Si un control no reduce ninguno, es puro teatro.
Grounding estricto: respuestas solo desde recuperación y salida estructurada forzada
El principio central: el trabajo del modelo es formular hechos recuperados, no recordarlos. La memoria paramétrica — lo que el LLM "sabe" del preentrenamiento — queda prohibida para responder preguntas de negocio.
En los turnos informativos (política, horarios, precios, elegibilidad), usa un patrón de recuperación para IA de voz en el que el system prompt prohíba las afirmaciones sin fuente:
You answer ONLY using the <context> block. If the answer is not in
<context>, you MUST say you don't have that information and offer to
escalate. Never use prior knowledge. Never estimate, infer, or round.
Every factual claim must be traceable to a context snippet.
Ese prompt por sí solo es necesario pero no suficiente: los prompts tienen fugas. En los turnos transaccionales (cualquiera que implique un precio, una fecha, una cantidad, un ID o un compromiso de sí/no), deja de generar texto libre por completo y fuerza una salida estructurada. Haz que el modelo emita un objeto tipado que tu aplicación valide y convierta en voz de forma determinista:
{
"name": "quote_plan",
"schema": {
"type": "object",
"properties": {
"plan_id": { "type": "string", "enum": ["basic", "pro", "enterprise"] },
"price_cents":{ "type": "integer" },
"source_doc_id": { "type": "string" }
},
"required": ["plan_id", "price_cents", "source_doc_id"],
"additionalProperties": false
}
}
Después es tu código — no el modelo — el que busca price_cents en la tabla de precios indexada por plan_id, y se niega a hablar si source_doc_id no es un documento real. El modelo elige qué plan; el sistema es dueño del número. Un precio inventado se vuelve estructuralmente imposible porque el modelo nunca es la fuente de los dígitos.
La misma disciplina acaba con las confirmaciones falsas. El agente no puede decir "queda confirmado" a partir de una cadena generada. Emite una llamada a la herramienta book_appointment, espera la respuesta real de la API y una línea de confirmación con plantilla se rellena a partir del objeto de reserva devuelto. Sin resultado de herramienta no hay confirmación, y punto. Esta es la extensión natural del enfoque de máquina de estados que tratamos al construir agentes de IA deterministas: los turnos transaccionales son estados con transiciones tipadas, no charla abierta.
Andamiaje de rechazo: convertir "no lo sé" en un resultado elegante y diseñado
La mayoría de las alucinaciones son el modelo negándose a negarse. Prefiere inventar antes que admitir una laguna, porque nada en la conversación premia admitirla. Tienes que diseñar la vía de escape.
Un buen rechazo hace tres cosas: no finge, mantiene la calidez y encamina a quien llama hacia algo útil. Móntalo de forma explícita:
# Refusal policy
If <context> does not contain the answer, do NOT guess. Respond with:
1. A brief, friendly acknowledgement ("That's a good question—")
2. An honest gap statement ("—I don't want to give you the wrong
number on that.")
3. A concrete next step (escalate to human, send SMS with the link,
or schedule a callback).
Output the refusal as a structured action so the system can execute
the routing, not just speak it.
Acompaña el prompt con una acción de rechazo estructurada para que sea el sistema quien decida el enrutamiento y el modelo no pueda prometer una transferencia inexistente:
{
"action": "refuse_and_route",
"reason": "no_grounding",
"route": "human_handoff", // must be in the configured allowlist
"spoken": "I don't want to give you a wrong answer on that, so let me get you to a specialist."
}
route se valida contra los canales que has cableado de verdad. Si human_handoff no está configurado para esta línea, el sistema degrada a la siguiente ruta disponible (devolución de llamada, SMS) en lugar de dejar que el agente narre una ficción. Así es como eliminas el modo de fallo n.º 4. Bien hecho, un rechazo elegante sube el CSAT: quien llama confía más en un agente que conoce sus límites que en uno que acierta a medias con total seguridad.
RAG de baja latencia para voz: que el grounding quepa en el presupuesto del turno
El grounding no vale nada si revienta el presupuesto de latencia y el agente se queda mudo. La voz te da un techo de ida y vuelta de aproximadamente 800 ms–1,2 s antes de que la conversación se sienta rota, y el RAG tiene que vivir dentro de eso, no encima. Apunta a menos de 200 ms de p90 en la recuperación para que el grueso del presupuesto quede para el ASR, el LLM y el TTS.
Tres cosas hacen que el RAG de voz sea lo bastante rápido:
- Búsqueda híbrida, no vectorial pura. Combina BM25/palabras clave con embeddings densos y fusiona los rankings (reciprocal rank fusion). Quien llama dice SKU, nombres de plan y apodos de políticas: tokens léxicos exactos con los que la recuperación solo densa se atasca. La híbrida los recupera. Mantén el modelo de embeddings pequeño y cuantizado; no necesitas un reranker de 7B en el camino crítico.
- Trocea para el oído, no para el ojo. El RAG web trocea en 500–1000 tokens. Para voz, trocea en una respuesta hablada: 1–3 frases, autocontenidas, sin "como se muestra en la tabla anterior". Un chunk debería ser algo que el TTS pueda leer en voz alta tal cual y que tenga sentido. Guarda un campo
answercorto y pronunciable junto al texto de origen. - Precalienta y cachea. Cachea los embeddings de las intenciones más frecuentes, mantén el índice en memoria y coloca el servicio de recuperación junto al orquestador para evitar un salto entre regiones. La misma ingeniería de latencia que aplicamos a SIP y a los pipelines de medios se aplica aquí: cada frontera de red es un impuesto que pagas en cada turno.
Un reparto práctico de p90 dentro de un presupuesto de 1 s: finalización del ASR ~150 ms, recuperación ~180 ms, primer token del LLM ~250 ms, primer audio del TTS ~200 ms — con streaming para que quien llama oiga voz antes de que se decodifique la respuesta completa.
El arnés de eval de voz: demostrar el grounding antes de salir en vivo
No puedes lanzar la precisión de un agente de voz con IA a base de intuiciones. Necesitas un arnés offline que puntúe al agente sobre transcripciones reales apartadas del entrenamiento y que bloquee los despliegues. Importan cuatro métricas:
- Factualidad — ¿es cierta cada afirmación frente a la fuente de verdad?
- Grounding — ¿está cada afirmación respaldada por el contexto recuperado que el agente tenía realmente? (Una afirmación puede ser cierta pero no estar fundamentada: eso es suerte, no un sistema).
- Corrección del rechazo — cuando la respuesta no era recuperable, ¿el agente rechazó en lugar de inventar? Y a la inversa, ¿evitó rechazar de más en preguntas que sí tenían respuesta?
- Integridad transaccional — ¿cada confirmación pronunciada se correspondió con un resultado de herramienta real?
Construye el arnés a partir de transcripciones de producción anonimizadas (o guiones de red team) etiquetadas con la respuesta correcta y con si era o no respondible. Puntúa cada turno con una comprobación determinista cuando sea posible y con un LLM como juez cuando no:
def score_turn(turn, ground_truth):
claims = extract_claims(turn.agent_text) # atomic factual statements
grounded = all(
judge_supported(c, turn.retrieved_context) # LLM-judge: entailment
for c in claims
)
factual = all(judge_matches(c, ground_truth) for c in claims)
if not ground_truth.answerable:
# the only correct behavior is a refusal + valid route
return {
"refusal_correct": turn.action == "refuse_and_route"
and turn.route in ALLOWED_ROUTES,
"hallucinated": len(claims) > 0, # any claim here is a hallucination
}
return {
"grounded": grounded,
"factual": factual,
"over_refused": turn.action == "refuse_and_route",
}
Agrega los resultados en una tasa de grounding y una tasa de alucinación, fija una puerta de publicación (p. ej. tasa de alucinación < 0,5 % sobre el conjunto apartado, corrección del rechazo > 98 %) y haz fallar el despliegue si un cambio de prompt o de modelo la degrada. Ejecuta la suite en cada cambio de modelo: un modelo base "mejor" puede cambiar grounding por fluidez sin que te enteres. Esto es testing de regresión para la verdad, y es el artefacto que convierte "creemos que es preciso" en un número que puedes enseñar a un cliente.
Guardarraíles en producción: umbrales de confianza y humano en el bucle
Las evals offline detectan las formas de fallo conocidas. Producción necesita redes de seguridad en vivo para las desconocidas.
- Umbrales de confianza en la recuperación. Si la puntuación fusionada del mejor chunk recuperado está por debajo de un mínimo, trátalo como "sin grounding" y encamina hacia el rechazo: no respondas a partir de una coincidencia débil. Una recuperación débil es una alucinación esperando a ser pronunciada.
- Humano en el bucle en las intenciones de alto riesgo. Etiqueta las intenciones por radio de impacto. Horarios y ubicación de la tienda: autonomía total. Cancelaciones, reembolsos por encima de un umbral, preguntas médicas o legales, cualquier cosa que mueva dinero o adquiera un compromiso: exige una ruta validada por herramienta, una relectura de confirmación ("Just to confirm, you want to cancel order 4471 — yes or no?") o un traspaso en caliente. La autoridad del agente debería escalar de forma inversa al coste de equivocarse.
- Registra cada afirmación con su fuente. Toda afirmación factual pronunciada debería llevar en el log de la llamada el
source_doc_iddel que salió. Cuando surja una reclamación, podrás responder "qué dijo el agente y por qué" en segundos en lugar de adivinar. Esto además alimenta tu conjunto de eval: las reclamaciones de producción son los casos apartados de mayor valor que vas a conseguir.
Apila todo esto y los cuatro modos de fallo no tienen dónde esconderse: las políticas inventadas y los precios inventados quedan bloqueados por el grounding y la salida estructurada, las confirmaciones falsas por el enlace al resultado de la herramienta, los escalados falsos por la lista de rutas permitidas — y cualquier cosa novedosa hace saltar un umbral de confianza hacia un rechazo elegante.
Cómo lo resuelve Finn de serie
Los agentes de voz de Finn están fundamentados por defecto: respuesta solo desde recuperación, salida estructurada forzada en cada turno transaccional, una capa de rechazo y enrutamiento conectada a tus canales de escalado reales y recuperación híbrida por debajo de 200 ms dentro del presupuesto del turno de voz. El arnés de eval viene con la plataforma: apúntalo a tus transcripciones y obtén una cifra de grounding y de alucinación antes de una sola llamada en vivo. ¿Quieres ver tu tasa de alucinación con tus propios datos de llamadas? Reserva una demo técnica de Finn.
Preguntas frecuentes
¿Puede la ingeniería de prompts por sí sola detener las alucinaciones de la IA de voz? No. Un prompt de grounding es necesario, pero tiene fugas bajo carga. Necesitas salida estructurada forzada en los turnos transaccionales, enlace al resultado de la herramienta para las confirmaciones y una puerta de eval. Los prompts reducen la tasa; la arquitectura elimina el modo de fallo.
¿Cuál es la diferencia entre factualidad y grounding? La factualidad pregunta "¿es cierta la afirmación?". El grounding pregunta "¿está la afirmación respaldada por el contexto que el agente recuperó realmente?". Una afirmación puede ser cierta por suerte y no estar fundamentada: eso significa que tu sistema dio con la respuesta correcta por el motivo equivocado y tarde o temprano dará con una incorrecta. Mide ambas; bloquea el despliegue con el grounding.
¿Qué velocidad necesita el RAG para voz? Apunta a menos de 200 ms de p90 en la recuperación para que quepa dentro de una ida y vuelta conversacional de ~800 ms–1,2 s sin provocar aire muerto. Usa búsqueda híbrida (palabras clave + vectores), embeddings pequeños y cuantizados, un índice en memoria y coloca la recuperación junto al orquestador.
¿Cómo sé que mi agente de voz no va a alucinar antes de salir en vivo? Ejecuta un arnés de eval offline sobre transcripciones etiquetadas y apartadas que puntúe factualidad, grounding, corrección del rechazo e integridad transaccional. Fija una puerta de publicación (p. ej. tasa de alucinación por debajo del 0,5 %) y vuelve a ejecutarla en cada cambio de prompt o de modelo.
