Eliminación de alucinaciones en agentes virtuales basados en LLM

Aprende cómo Vonage AI Studio elimina las alucinaciones LLM utilizando campos de razonamiento estructurados y refinamientos de orden de esquema.

Introducción

Vonage AI Studio es una plataforma de bajo código para crear y gestionar agentes virtuales a través de canales de voz y digitales, con IA que opera entre bastidores para comprender a los usuarios e impulsar conversaciones inteligentes. Durante muchos años, esta plataforma ha evolucionado continuamente su motor NLUpasando de enfoques basados en palabras clave a modelos basados en incrustaciones y, en la actualidad, a la comprensión basada en LLM, a medida que se adoptaban nuevas tecnologías.

Nuestra plataforma de agentes virtuales permite a las organizaciones configurar agentes conversacionales que detectan intenciones, extraen parámetros, validan las entradas del usuario y guían las conversaciones. El LLM subyacente recibe el contexto de la conversación junto con las intenciones, parámetros y reglas de validación configurados, y devuelve una salida JSON estructurada que determina el siguiente paso de la conversación. A medida que el sistema crecía, nos encontrábamos repetidamente con alucinaciones del LLM, salidas que no se basaban en la configuración o en la entrada del usuario, y que causaban inestabilidad y un comportamiento impredecible.

Esta entrada de blog explica las mejoras introducidas para aumentar la precisión, estabilidad y fiabilidad de los resultados de LLM. Describe los retos a los que se enfrentó, los cambios aplicados y cómo estos ajustes mejoraron la calidad general de las respuestas del sistema.

Error rate comparison before and after introducing structured reasoning: 23.7% of responses were incorrect before changes, dropping to just 1.0% after.

Entender el problema: cómo las alucinaciones de los LLM hacen descarrilar a los agentes virtuales

Los LLM pueden generar respuestas fluidas que parecen correctas, incluso cuando no están fundamentadas en la configuración del sistema o en la entrada del usuario. Esto conduce a menudo a alucinaciones, situaciones en las que el agente acepta con confianza datos no válidos o inventa capacidades que no existen. Los siguientes ejemplos ilustran este problema.

Ejemplo 1: Cuando el agente acepta una entrada de usuario no válida

Descripción del problema:

El ID de reserva está definido para seguir un formato estricto:

3 letras mayúsculas seguidas de 3 cifras.

En este caso, el agente no aplica esta regla, mientras que el usuario sólo proporciona dos letras del ID en lugar de tres.

Conversación:

Usuario: Cancelar mi reserva

Agente: Para proceder con la cancelación, necesitaré su ID de reserva. Podría proporcionármelo, por favor?

Usuario: su ab1234

Agente: Veo que su ID de reserva es AB1234. ¿Es correcto?

En este caso, el agente normaliza incorrectamente y confirma un valor no válido en lugar de aplicar las reglas de formato definidas.

Ejemplo 2: Alucinar con intenciones y parámetros que no existen

Descripción del problema:

El sistema no incluye un intento de recuperar resultados de análisis de sangrey tampoco define ningún parámetro denominado ID para dicho flujo, pero el LLM sigue alucinando con la existencia de esta funcionalidad y parámetro.

Conversación:

Usuario: Me gustaría obtener los resultados de mis análisis de sangre

Agente: Sí, puedo localizar los resultados de su análisis de sangre reciente. Por favor, proporcione su identificación para que pueda proceder.

El agente fabrica tanto una capacidad soportada como un parámetro requerido, creando una interacción engañosa que puede afectar seriamente a la confianza del usuario.

A menudo, los LLM tienen que generar respuestas utilizando información procedente de diferentes partes de la petición, como instrucciones del sistema, entradas del usuario y reglas específicas de la tarea. Cuando este contexto está disperso, es incoherente o depende de datos dinámicos del usuario (como formatos de parámetros cambiantes), es más probable que el modelo cometa errores.

Por qué se producen las alucinaciones: Principales causas subyacentes

Para entender mejor por qué se producen estos fallos, podemos desglosarlos en varias causas subyacentes que surgieron repetidamente durante nuestro análisis.

Causa nº 1: Confusión por un contexto complejo o mixto

Es posible que los LLM no conecten correctamente todas las piezas necesarias. Los problemas más comunes son:

• Seleccionar la intención de usuario incorrecta.

• Aplicación incorrecta de la validación.

• Generar salidas que contradicen análisis anteriores, o alucinar con instrucciones o formatos de parámetros que faltan.

Cuanto más compleja y fragmentada sea la solicitud, más probabilidades habrá de que surjan estos problemas.

Causa nº 2: El razonamiento invisible conduce a fallos ocultos

Los LLM generan texto paso a paso, pero su razonamiento sigue siendo interno. Si hacen una suposición incorrecta al principio, el resultado final será erróneo, sin ninguna explicación visible. El ajuste por sí solo no basta para solucionar este problema. A menos que se obligue al modelo a mostrar su razonamiento, las alucinaciones no pueden rastrearse ni evitarse.

Causa nº 3: Equilibrar el control y la capacidad de razonamiento del modelo

Las Applications del mundo real requieren resultados estructurados y predecibles que puedan analizarse o ejecutarse. Al mismo tiempo, la investigación demuestra que restricciones de salida estrictascomo la coherencia del formatopueden suprimir la capacidad de razonamiento del modelo y reducir la precisión de la tarea. Encontrar el equilibrio entre control y flexibilidad es fundamental, pero sigue siendo un reto pendiente. Este equilibrio es especialmente importante en entornos empresariales, donde la fiabilidad y la seguridad de la ejecución son tan importantes como la creatividad del modelo.

La solución: Estructurar y ordenar el razonamiento LLM para obtener resultados fiables

1. Guiar a los LLM con campos de razonamiento auxiliares

Evitar que los LLM se salieran de la vía exigía algo más que un ajuste puntual. Tuvimos que cambiar cómo el modelo para generar una respuesta en primer lugar. En lugar de dejar que el LLM salte directamente a una respuesta, ahora lo guiamos para que razone el problema paso a paso, utilizando campos estructurados, antes de que produzca cualquier salida que el sistema realmente consuma.

Originalmente, el esquema de respuesta del LLM sólo incluía campos operativos, que el sistema procesaba posteriormente o devolvía directamente al usuario. Para reforzar el razonamiento del modelo y centrar su atención en las instrucciones más críticas de la solicitud del sistema, ampliamos el esquema para incluir campos de razonamiento explícitos y estructurados que deben generarse en primer lugar.

Estos campos de razonamiento son internos al motor del agente y nunca se exponen a los usuarios finales. El sistema no los consume directamente. Sin embargo, al exigir su presencia, animamos al modelo a analizar primero el contexto, identificar las restricciones clave y extraer las señales relevantes antes de producir el resultado final procesable. En la práctica, esto convierte el razonamiento previamente oculto en datos estructurados e inspeccionables y mejora significativamente la fiabilidad de los resultados.

A continuación, mostramos ejemplos del antes y el después que demuestran el impacto de este cambio.

2. Ordenación de esquemas: Pequeño cambio, gran impacto en el comportamiento de LLM

A primera vista, reordenar los campos JSON parece insignificante, ya que JSON no tiene noción semántica de orden. Pero los LLM no interpretan JSON estructuralmente. Lo generan como texto plano, un token cada vez, basándose en todo lo anterior.

Por eso, el orden de los campos es importante. Los primeros campos conforman el contexto interno del modelo y la ruta de razonamiento, mientras que los campos generados más tarde son más susceptibles de desviación o incoherencia. Al situar los campos de razonamiento al principio del esquema y controlar cuidadosamente el orden general de los campos, guiamos al modelo para que "piense antes de hacer".

Este pequeño cambio estructural tiene un efecto sorprendentemente grande. Se anima al modelo a analizar primero la entrada y las restricciones, y sólo después produce los campos operativos en los que se basa el sistema. Reordenar el esquema e introducir campos de razonamiento explícitos ayuda a alinear el proceso de generación del modelo con las expectativas reales del sistema, lo que se traduce en resultados más coherentes y predecibles.

Ejemplo mejorado 1: Aplicación eficaz de los formatos de parámetros

Conversación:

Usuario: Cancelar mi reserva

Agente: Para proceder con la cancelación, necesitaré su ID de reserva. Podría proporcionármelo, por favor?

Usuario: su ab1234

Agente: El ID de reserva debe contener 3 letras seguidas de 3 números. Proporcione un ID de reserva válido.

Lo que cambió:

• El agente ya no normaliza ni confirma los datos no válidos

• Las normas de formato se aplican estrictamente

• El usuario es guiado para corregir la entrada antes de que el flujo continúe

Ejemplo mejorado 2: Bloqueo de intenciones y parámetros alucinados

Conversación:

Usuario: Me gustaría obtener los resultados de mis análisis de sangre

Agente: Lo siento, no puedo recuperar resultados de pruebas médicas ni solicitar identificación para esta acción. Puedo ayudarle a gestionar sus citas y, para cualquier otra solicitud, puedo dirigirle directamente a la clínica.

Lo que cambió:

• El agente ya no inventa capacidades no soportadas

• No se solicitan parámetros indefinidos (como "ID")

• La respuesta se ajusta a las capacidades reales del sistema

Y si te estás preguntando cómo se ve esto entre bastidores:

Esquema paralelo: alucinación propensa frente a razonamiento consciente

Antes del esquema de respuesta JSON (Alucinación-Prona)

{
  "detected_intent": {
    "id": null,
    "name": null
    
  },
  "generated_answer": 
  {
    "answer": "Yes, I can locate your recent blood test results. Please provide your ID so I can proceed."
    
  }
}

Después del esquema de respuesta JSON (con campos auxiliares de razonamiento)

{
  "detected_intent": {
    "id": null,
    "name": null
    
  },
  "generated_answer": {
    "evidence_from_prompt": "Supported intents: Book Appointment Reschedule Appointment, Cancel Appointment, Manage Appointments."
    "intents_i_am_familiar_with": [
      "Book Appointment",
      "Reschedule Appointment",
      "Cancel Appointment",
      "Manage Appointments"
    ],
    "out_of_scope_request": true,
    "answer": "Sorry, I’m not able to retrieve medical test results or request identification for this action. I can help you manage your appointments, and for any other requests, I can route you directly to the clinic."
  }
}

Añadiendo los nuevos campos de razonamiento evidence_from_prompt,intents_i_am_familiar_with, out_of_scope_requestel LLM debe analizar la entrada del usuario y la configuración antes de de producir la respuesta final. Esto obliga al modelo a pensar en las restricciones, comprender los límites del escenario y fundamentar su respuesta en pruebas explícitas, lo que da lugar a respuestas más claras, precisas y controladas.

Validación de parámetros: Perfeccionamiento de esquemas para que los usuarios introduzcan datos precisos

Antes del esquema de respuesta JSON (Primero la respuesta, después el análisis)

{
  "generated_answer": {
    "answer": "I see that your booking ID is AB1234. Is that correct?",
    "answer_refer_to_parameter_id": "Booking_id",
    
  },
  "message_content": "its ab1234",
  "parameters": [
    {
      "parameter_id": "Booking_id",
      "parameter_value": "AB1234",
      
    }
    ]
}

Después (campos Modificar orden y Añadir motivación)

{
  "user_messages_analysis": {
    "message_content": "its ab1234",
    "current_intent": "Cancel_Reservation",
    "parameters": [
      {
        "parameter_id": "Booking_id",
        "parameter_value_format": "3 letters followed by 3 numbers (e.g., ABC123)",
        "parameter_value_format_regex": "^[A-Z]{3}[0-9]{3}$",
        "parameter_extracted_part": "ab1234",
        “simulate_regex_execution”:false
        
      }
      ]
    
  },
  "generated_answer": {
    "evidence_from_prompt": "Booking_id format: 3 letters followed by 3 numbers (e.g., ABC123).",
    "answer": "The booking ID should contain 3 letters followed by 3 numbers. Please provide a valid booking ID.",
    "answer_refer_to_parameter_id": "Booking_id",
    
  }
}

Juntos, estos campos requieren que el modelo valide el parámetro extraído, lo compare con el formato esperado y declare explícitamente si el valor es aceptable antes de producir la respuesta final. Esto garantiza que la respuesta esté totalmente fundamentada en los pasos de razonamiento del modelo y evita casos en los que el LLM confirma con confianza un parámetro no válido o hace avanzar la conversación basándose en suposiciones incorrectas.

Estábamos satisfechos con los resultados de estas acciones, pero nos seguían preocupando las posibles desviaciones en la validación del formato de los parámetros. Para solucionarlo, introdujimos una capa de validación medible que supervisa las tasas de extracción y detecta los casos en los que el LLM sigue malinterpretando las reglas de formato en lenguaje natural.

Formatos de parámetros precisos con validación Regex

La adición de parámetros de razonamiento auxiliares y la reordenación del esquema aportaron mejoras significativas. Aun así, perseguíamos dos objetivos adicionales:

1. lograr una precisión cercana al 100% en la aplicación del formato de los parámetros, y

2. obtener una sólida supervisión de la producción para detectar cuándo puede ser necesario un ajuste adicional.

Para alcanzar estos objetivos, utilizamos un proceso de validación en varias fases.

Paso 1: LLM genera un Regex a partir de la descripción

Como se ha explicado en la sección anterior, parte de los campos de razonamiento auxiliares requieren que el LLM los produzca:

• parameter_value_format: Una descripción legible por humanos

• parameter_value_format_regex: Un patrón regex generado a partir de la descripción de texto libre

• simulate_regex_execution: La evaluación del LLM de si el valor extraído satisface el patrón regex.

Esto obliga al LLM a traducir el lenguaje natural a un formato comprobable por la máquina.

Paso 2: LLM valida su propio Regex (simulación)

Como parte de su razonamiento, el modelo responde "simulate_regex_execution": true | falseindicando si cree que que la expresión regular funciona. Esto ya ha aumentado significativamente la precisión.

Paso 3: La comprobación final de la expresión regular en el sistema garantiza la precisión

Para garantizar la precisión, tras recibir la respuesta del LLM se añadió otra capa de verificación: el sistema vuelve a ejecutar de forma independiente la regex generada a partir del campo parameter_value_format_regex (con guardrails para evitar patrones inseguros). Si el regex no coincide, aunque el LLM haya dicho que debería hacerlo, el agente rechaza el valor y guía al usuario para que lo corrija.

Este enfoque híbrido, consistente en combinar el razonamiento LLM con la validación programática, produjo una precisión casi perfecta en la aplicación del formato de los parámetros y resolvió las últimas incoherencias que observamos.

Esta validación nos proporciona una métrica medible para controlar el rendimiento del LLM a lo largo del tiempo. Siempre que el LLM predice que la expresión regular debería coincidir (simulate_regex_execution = true) pero la ejecución de la expresión regular en el sistema falla, detectamos inmediatamente la discrepancia. Esperamos que estos casos sigan siendo extremadamente raros, y si aparece una tendencia al alza, sirve como indicador temprano de una deriva o degradación en el comportamiento del LLM.

Evaluación: ¿En qué medida han ayudado los cambios?

Para evaluar el efecto del nuevo esquema de razonamiento, creamos un agente virtual para una clínica médica y generamos 97 frases intencionadamente fuera de ámbito. Para todas ellas, el comportamiento correcto fue:

• intent = null, y

• La respuesta generada debe rechazar amablemente la solicitud

• Minimizar los casos en los que simular_ejecución_regex = true pero la ejecución regex del lado del sistema falla.

Realizamos una comparación para evaluar el impacto de la introducción de campos de razonamiento:

No perjudicar a los verdaderos positivos

También validamos casos en los que el agente virtual debe detectar una intención. La detección de verdaderos positivos sin cambios: sin caídas ni degradaciones. La nueva capa de razonamiento reduce las alucinaciones sin que debilita la detección de intenciones correctas.

Antes y después

No hubo ningún caso en el que el LLM predijera simular_ejecución_regex = true mientras que la ejecución regex del lado del sistema falló. En otras palabras, todas las mejoras las consiguió el propio LLM.

Se observaron patrones similares en otras tareas que el LLM debe generar.

Resultados: Lo que aprendimos y lo que cambió

La introducción de campos de razonamiento explícitos, la reestructuración del esquema de respuesta y la adición de la ejecución de expresiones regulares en el sistema tuvieron un efecto positivo significativo en el comportamiento general del LLM. Estos cambios redujeron sustancialmente las alucinaciones y las respuestas fuera de alcance, al tiempo que preservaron la capacidad del modelo para identificar correctamente las entradas válidas. Como resultado, los resultados del LLM fueron más coherentes, predecibles y se ajustaron mejor a la configuración y la lógica previstas.

A medida que este trabajo evoluciona, seguimos investigando formas de hacer que el razonamiento y las decisiones de nuestro sistema sean más explicables, tanto para respaldar casos de uso en el mundo real como para mantener una sólida gobernanza de la IA.

A high-level overview of the reasoning structure and validation pipeline added to improve LLM response reliability and reduce hallucinations.