Volver al inicio

Triage-and-Voice: solución para alucinaciones de LLM

El patrón Triage-and-Voice resuelve el problema de alucinaciones en LLM separando análisis y generación de respuesta. Primera pasada extrae datos estructurados, backend sustituye hechos verificados, segunda forma voz. Aceleración por 2–3 veces, seguridad a través de código.

LLM dividido: Triage-and-Voice contra alucinaciones
Advertisement 728x90

El Patrón Arquitectónico de Triaje y Voz para Eliminar Alucinaciones en LLM

Un LLM en un chatbot analiza una conversación y, en lugar de proporcionar el número real de la línea de ayuda, inventa una línea de ayuda infantil. La instrucción "no inventes contactos" se ignora. La razón es un conflicto de tareas en una sola pasada: el análisis preciso y la respuesta empática compiten por tokens, lo que lleva a alucinaciones en datos críticos.

El Problema con la Arquitectura de Una Sola Pasada

En el esquema estándar de productos LLM, la entrada del usuario va directamente al modelo, que produce la respuesta final. El análisis requiere una salida JSON estructurada con hechos precisos: participantes, riesgos, objetivos. Formular la respuesta es una tarea creativa que involucra voz y tono.

Combinar esto en un solo prompt conduce a compromisos:

Google AdInline article slot
  • El modelo sacrifica precisión por estilo.
  • Las alucinaciones se enmascaran como texto convincente.
  • Es imposible distinguir programáticamente hecho de ficción.

Aumentar el poder del modelo (modelos de razonamiento, más tokens) reduce la frecuencia de errores pero no elimina el problema. En casos complejos con subtexto, incluso los mejores modelos confunden motivos y fabrican detalles. El riesgo concierne a datos confiables: precios, direcciones, dosis, contactos de servicio.

El Patrón de Triaje y Voz

Divide el procesamiento en dos pasadas LLM con un guardián backend entre ellas.

Pasada 1: Triaje. Análisis estructural sin estilo. El modelo extrae la señal en JSON:

Google AdInline article slot
{
  "estado_anímico": "ansiedad",
  "es_crisis": false,
  "tipo_crisis": null,
  "participantes": [...],
  "motivos": [...]
}

Ejemplo de crisis:

{
  "estado_anímico": "bandera_roja",
  "es_crisis": true,
  "tipo_crisis": "violencia"
}

Guardián backend. Código determinista verifica banderas:

if (triaje.esCrisis) {
    var contactos = await db.ObtenerContactosVerificadosCrisis(triaje.tipoCrisis);
    prompt = plantillaPromptCrisis.ConContactos(contactos);
}

Se insertan datos verificados de la base de datos. Enrutamiento por reglas: crisis → prompt especial.

Google AdInline article slot

Pasada 2: Voz. El modelo recibe entrada enriquecida y genera una respuesta en el tono deseado. No analiza ni inventa hechos.

Pruebas en DeepSeek V3.2 (docenas de casos de crisis): cero alucinaciones de contacto.

Ventajas de la Separación

  • Separación de responsabilidades. El triaje se enfoca en estructura (tokens para hechos). La voz se enfoca en estilo (tokens para empatía). La calidad en ambas dimensiones mejora (verificado en 40 casos de evaluación).
  • Caché. El análisis se hace una vez. Al cambiar la voz (perspectivas en un bot de Telegram), solo se vuelve a ejecutar Voz. Métricas: primera respuesta 30–45 s (vs 50–90 s), respuestas posteriores 15–20 s.
  • Seguridad. El control está en el código, no en el prompt. El modelo establece una bandera ("cuándo"), el backend decide ("qué"). Comprobable, predecible.

Escenarios de Aplicación

El patrón es relevante para productos LLM con:

  • Análisis de entrada + generación de salida.
  • Datos confiables (finanzas, referencias legales, medicina).
  • Casos límite (crisis, excepciones).
  • Múltiples perspectivas sin reanálisis.
  • Un punto de control necesario entre análisis y salida.

Principio: el modelo analiza → el código decide → el modelo formula.

Señal de refactorización: el prompt contiene "NO inventes [datos]".

Puntos Clave

  • Cambio arquitectónico: de una llamada a dos con un guardián, eliminando conflicto de tareas.
  • Métricas de rendimiento: el análisis se almacena en caché, Voz acelera 2–3 veces.
  • Seguridad: el backend determinista inserta hechos, el modelo no toca la base de datos.
  • Escalabilidad: aplicable a chatbots, análisis, productos con casos límite.
  • Verificado: 40 evaluaciones + docenas de ejecuciones de crisis sin alucinaciones.

Riesgos de la Arquitectura Ingenua

Una llamada = operación atómica sin validación. Carece de:

  • Validación de decisión del modelo antes de llegar al usuario.
  • Caché de análisis.
  • Enrutamiento de casos límite.
  • Inserción de datos verificados.

Confiar en la generación probabilística en lugares críticos es una vulnerabilidad. Triaje y Voz agrega control: +1 llamada, +1 guardián = pipeline verificable.

— Editorial Team

Advertisement 728x90

Leer después