3 reglas para que tu LLM no invente justificaciones

En el artículo anterior te conté que el bug estaba en la rúbrica, no en el modelo. El modelo quedó bien.

Ahora bajamos un nivel: qué le exijo exactamente al modelo cuando evalúa una llamada, y qué tiene que devolver. Este es el prompt del juez que corre contra una operación de 45 agentes.

No tiene veinte reglas. Tiene tres, y hacen casi todo el trabajo. Te las muestro con salidas reales del modelo, porque un prompt sin ejemplo de salida buena es una promesa.

El contrato de salida

El modelo devuelve solo JSON. La API lo fuerza con json_schema en modo estricto y temperature=0, así que no puede desviarse del contrato:

{
  "scores": [
    {
      "criterion_key": "escucha",
      "value": 4.0,
      "confidence": 0.82,
      "evidence": "cita textual exacta de la transcripción",
      "rationale": "por qué ese puntaje, en una o dos frases"
    }
  ]
}

Cuatro campos. value es el puntaje. confidence es cuánto sostiene la evidencia ese puntaje, no cuán seguro se siente el modelo. Los dos que hacen el trabajo real son evidence y rationale: uno para verificar, el otro para entender.

Regla 1 — Sin cita, no hay punto

El problema de un LLM como juez no es que escriba mal: es que escribe bien. Genera justificaciones convincentes para puntajes que no tiene respaldados, y cuando el argumento suena bien, el supervisor deja de mirar y acepta el número.

Por eso evidence no puede ser una descripción. Tiene que ser una cita literal, palabra por palabra, que se pueda buscar en la transcripción.

Salida mala:

{
  "criterion_key": "escucha",
  "value": 4.0,
  "confidence": 0.86,
  "evidence": "El agente dejó hablar al cliente antes de responder.",
  "rationale": "El agente se mostró atento durante toda la conversación."
}

El evidence dice "durante toda la conversación". Si la transcripción muestra lo contrario, el error es invisible: el modelo estaba seguro y la justificación era convincente. Ese es el peor escenario: el supervisor deja de verificar.

La regla, textual:

Cada puntaje DEBE citar evidencia textual EXACTA de la transcripción. Si no podés citar un fragmento que demuestra el puntaje, el criterio no se cumplió: bajalo al mínimo de la escala y explicá por qué en el rationale.

El corolario: si no hay cita, no se "opina" un 3. Se baja al mínimo de la escala y se explica. El modelo no tiene permiso de puntuar por simpatía.

Salida buena:

{
  "criterion_key": "escucha",
  "value": 4.0,
  "confidence": 0.88,
  "evidence": "CLIENTE: ... y encima me lo cobraron dos veces. AGENTE: Dale, lo verifico ahora.",
  "rationale": "El cliente termina su turno y el agente responde después, sin interrumpir."
}

Misma confianza, mismo puntaje, y ahora el supervisor puede discutirlo: mira la frase y ve si el 4 se sostiene.

Regla 2 — Si hay evidencia en contra, el puntaje es bajo

Acá el problema es otro, y es el que vuelve inútil un sistema de QA: el modelo promedia.

Un modelo entrenado para sonar razonable ve un criterio que se cumple en la mitad de la llamada y le pone un 3 o un 4. El 4 de un agente mediocre y el 4 de uno bueno son el mismo 4. Y si tu reporte dice "agente con score 4", no podés hacer nada con eso.

La regla:

Un criterio no se cumple "parcialmente sin evidencia". Si hay una cita que lo contradice, el puntaje es bajo, aunque en otro momento de la conversación haya estado bien.

Salida mala:

{
  "criterion_key": "plazos",
  "value": 3.0,
  "confidence": 0.75,
  "evidence": "AGENTE: Te lo mando hoy antes de las 18.",
  "rationale": "El agente comunizó un plazo concreto en la primera parte de la conversación."
}

El modelo tomó el momento bueno y lo promedió. Salida buena, sobre la misma conversación:

{
  "criterion_key": "plazos",
  "value": 2.0,
  "confidence": 0.90,
  "evidence": "AGENTE: Y después te aviso.",
  "rationale": "El cierre queda sin plazo concreto. El deadline del inicio no alcanza: el criterio se cumple solo si el último plazo comprometido tiene hora o fecha."
}

El rationale dice por qué ese texto define el puntaje, aunque en el mismo criterio haya un momento bueno. Si no lo dice, el supervisor tiene que buscar el contraargumento él: ahí empieza la tasa de rechazos que nadie sabe explicar.

Regla 3 — La confianza es cuánto sostiene la evidencia el puntaje

Esta es la que más se malinterpreta, porque el nombre invita a leerla como "certeza del modelo". No lo es.

Un modelo que no sabe nada de una transcripción truncada igual responde confidence: 0.95. No porque mienta: porque el campo no significa eso. Y si usás ese número para decidir a qué caso va a un humano, terminás haciendo lo contrario de lo que querés: mandás a revisión los casos que el modelo sabía.

La definición que uso:

• 0.9 a 1.0: evidencia directa y clara, el criterio es inequívoco.
• 0.6 a 0.9: hay evidencia, pero admite lectura alternativa.
• 0.3 a 0.6: evidencia parcial o ambigua.
• menos de 0.3: casi no hay evidencia. Cualquier puntaje ahí va a revisión humana.

Y la regla que la acompaña, la que frena las transcripciones reales:

Si la transcripción está truncada, tiene ruido o no permite [evaluar el criterio], evaluá el criterio con la información disponible y bajale la confianza. No completes lo que falta.

Con la transcripción cortada, la salida es:

{
  "criterion_key": "escucha",
  "value": 3.0,
  "confidence": 0.42,
  "evidence": "AGENTE: ¿Me pasás el número de cuenta? CLIENTE: Sí, es 1234.",
  "rationale": "Hasta donde llega la transcripción, el cliente termina su turno. Con la evidencia disponible no se puede afirmar que el agente no interrumpió en el resto de la llamada."
}

Acá la confianza hace el trabajo: el puntaje sale del medio, no de la certeza del modelo. Ese 0,42 manda el caso a revisión humana.

Dónde aterriza esto: la capa humana

Las tres reglas no reemplazan la revisión humana: la hacen posible. Con confidence definida sobre evidencia, el ruteo es mecánico: todo lo que está por debajo de 0,75 va a revisión, más una muestra aleatoria del 20% del resto.

Y cuando el supervisor revisa deja dos cosas: la decisión (approve, reject o needs_review) y, si le cambia el número, el adjusted_mean:

curl -X POST http://localhost:8000/recordings/1/review \
  -H "Content-Type: application/json" \
  -d '{"reviewer":"supervisor-1","decision":"approve","adjusted_mean":3.8}'

De ahí sale la desviación entre el modelo y el humano, que es el único número que te dice si el sistema sirve. Y, más importante, te cambia la pregunta: cuando un supervisor rechaza, dejás de discutir "el modelo se equivoca" y podés preguntar qué criterio, en qué transcripción, con qué evidencia. Ahí adentro está el bug.

Si querés arrancar hoy

Con esto y nada más:

1. Pedí JSON con esquema estricto y evidence obligatorio. Si tu proveedor no lo soporta, parseá con regex: es peor, pero funciona.
2. temperature=0.
3. Revisá a mano las primeras 50 salidas, leyendo la evidence contra la transcripción. No el puntaje: la evidencia. Si en algún evidence no reconocés la frase, ese puntaje no existe.

Con eso ya tenés un juez auditable. Lo demás —transcripción, diarización, reportes— es plumbing.

El kit

El prompt completo con el porqué de cada regla, y la guía de rúbrica con los 12 criterios que uso, están en el Kit QA con IA (MIT, US$79): https://kit-qa-con-ia.surge.sh/. Si no lo necesitás, las tres reglas de arriba están para copiar tal cual.

Artículo 2 de la serie **QA con IA. El anterior: Tu IA no está mal. Tu criterio de evaluación está mal.

Si tu operación tiene un sistema de evaluación con IA corriendo, te dejo una pregunta: ¿cuál de las tres reglas te está rompiendo el sistema hoy — la cita obligatoria, la evidencia en contra, o la confianza mal definida? Contame en los comentarios y armamos el caso de esa en particular.