El problema: por que los guardrails importan en voz
A diferencia de un chatbot de texto donde el usuario puede releer y cuestionar una respuesta, en una llamada de voz la informacion incorrecta se percibe con la misma autoridad que la correcta — no hay una barra de URL que inspeccionar, no hay formato que sugiera incertidumbre. Cuando un agente de voz le dice a un paciente que su cita es el martes a las 10 AM y la realidad es el miercoles a las 11 AM, las consecuencias son tangibles: citas perdidas, confusion, erosion de confianza. Los guardrails son la linea de defensa entre el LLM — que puede alucinar incluso con buenas instrucciones — y el usuario final.
Arquitectura de validacion post-generacion
El nucleo de nuestro sistema de guardrails opera como una capa de validacion entre el LLM y el modulo TTS. El flujo es: (1) el LLM genera una respuesta candidata en streaming; (2) cuando se acumula un turno completo o una clausula semanticamente completa, el validador se activa; (3) el validador contrasta la respuesta contra la base de conocimiento del negocio usando recuperacion vectorial (RAG); (4) si la respuesta supera el umbral de confianza, se envia a TTS; si falla, se sustituye por una respuesta de fallback segura. El diseno como efecto secundario puro sobre el flujo de bytes del agente garantiza que los guardrails no alteren el comportamiento del LLM y puedan actualizarse de forma independiente.
Validacion estructural: reglas deterministas
Antes de invocar modelos neuronales, aplicamos un conjunto de reglas deterministas que capturan alucinaciones obvias con latencia minima. Ejemplos: fechas mencionadas que no corresponden a ningun horario configurado, numeros de telefono con formato invalido, confirmaciones de servicios que el negocio no ofrece. Estas reglas procesan la respuesta candidata en menos de 5 ms y rechazan aproximadamente el 40% de las alucinaciones que llegarian al validador vectorial, reduciendo la carga sobre este ultimo.
Recuperacion aumentada por vectores (RAG) para validacion semantica
Para alucinaciones semanticas — donde el agente produce texto bien formado pero factualmente incorrecto para el contexto del negocio — la validacion estructural no es suficiente. Empleamos un indice vectorial de la base de conocimiento del negocio (horarios, servicios, FAQ, protocolos) y calculamos la similitud coseno entre la respuesta candidata y los fragmentos recuperados. Si la similitud supera un umbral configurable, la respuesta se aprueba; de lo contrario, se reemplaza. El umbral es un hiperparametro critico: muy alto genera muchos falsos positivos (respuestas correctas rechazadas), muy bajo deja pasar alucinaciones. En produccion usamos un umbral de 0.75 con revision periodica via datos de produccion anonimizados.
Clasificadores de confianza: la tercera capa
La tercera capa es un clasificador binario (alucinacion/no-alucinacion) entrenado con ejemplos del dominio. A diferencia de RAG — que mide similitud con el conocimiento existente — el clasificador puede detectar patrones de incertidumbre en el lenguaje del LLM: hedging excesivo, contradicciones internas, respuestas que asumen hechos no mencionados en el contexto. El clasificador anade aproximadamente 80 ms de latencia adicional y captura un 15-20% de alucinaciones que escapan a las dos capas previas. En verticales de alto riesgo (salud, finanzas), esta capa es mandatoria; en verticales de menor riesgo puede desactivarse para reducir latencia.
Compromisos de latencia y estrategias de mitigacion
La validacion de tres capas introduce entre 150 y 350 ms de latencia adicional por turno, dependiendo de la longitud de la respuesta y la carga del sistema. Para mantener el TTFS por debajo de 1.2 s, optimizamos mediante: (a) validacion en paralelo con la generacion de los primeros tokens (early exit), (b) cache de validaciones para respuestas frecuentes, y (c) ajuste dinamico del umbral RAG segun la carga del sistema. Con estas optimizaciones, el impacto neto en TTFS es de aproximadamente 80-120 ms en condiciones de carga normal.
Patrones de falla prevenidos y casos limite
Los guardrails previenen sistematicamente tres patrones de falla criticos: (1) confirmacion de citas inexistentes, (2) provision de informacion de precios incorrecta, y (3) respuestas que mezclan informacion de negocios distintos en configuraciones multi-tenant. Los casos limite mas desafiantes son las respuestas parcialmente correctas — donde la primera mitad es valida y la segunda alucinada — que requieren segmentacion semantica antes de la validacion. Actualmente procesamos respuestas como unidades atomicas por turno; la segmentacion a nivel de clausula es trabajo activo.