DEV Community: Gecko2087

Your LLM''s evidence is not evidence: verify every quote before you trust a score

Gecko2087 — Fri, 13 Nov 2026 03:01:56 +0000

Last week I shipped a small feature to a QA pipeline I maintain: before a score is stored, the model has to quote the transcript it claims to be scoring.

That sounds trivial. It is not, and the reason is worth a full article, because "make the model cite its evidence" is advice that feels sufficient and is not.

The failure mode nobody measures

The standard advice for LLM-as-judge systems is: require a literal quote alongside each score. The reasoning is sound — if every score comes with a quote, a human can check it in seconds instead of minutes.

But nobody checks whether the quote exists.

I reviewed the code of a pipeline I was about to adopt, and this is what the persistence layer looked like:

score = Score(
    value=float(item["value"]),
    confidence=float(item.get("confidence") or 0),
    evidence=(item.get("evidence") or "")[:4000],
    rationale=(item.get("rationale") or "")[:4000],
)
session.add(score)

The prompt said, in bold, that every score must cite exact evidence. The code stored whatever string came back. If the model paraphrased, if it summarized, if it hallucinated a sentence that was never said, the pipeline would have stored it and displayed it with a confidence of 0.91 next to a number a supervisor was expected to trust.

The prompt is an instruction. The string is data. Instructions are not controls.

What it looks like in practice

Here is the kind of output you get from a good model asked for literal evidence:

{
  "criterion_key": "plazos",
  "value": 2.0,
  "confidence": 0.90,
  "evidence": "AGENTE: Y después te aviso.",
  "rationale": "The closing statement has no concrete deadline."
}

And here is the same model, asked the same way, on a worse run:

{
  "criterion_key": "plazos",
  "value": 2.0,
  "confidence": 0.88,
  "evidence": "The agent did not provide a specific timeframe.",
  "rationale": "The closing promise was vague."
}

Both look reasonable to a reader. The second one is worthless: it is a description of an absence, which is exactly what a model produces when it cannot find a quote. It reads like evidence but contains no words from the transcript.

A human reviewer skimming it might approve it. The whole point of the quote was to make review cheap. A paraphrase puts the review cost back where it started, while looking like it was solved.

The check is cheap

The verification does not need an embedding model, a second LLM call, or a vector store. It is a substring check against the transcript you already have.

The naive version breaks immediately: models quote with different capitalization, smart quotes, and they join two fragments with an ellipsis. So normalize first, then compare every fragment:

import re
import unicodedata

ELISION = re.compile(r"\s*\.\.\.\s*|\s*…\s*")


def _normalizar(texto: str) -> str:
    plano = unicodedata.normalize("NFKD", texto)
    plano = "".join(c for c in plano if not unicodedata.combining(c))
    plano = plano.lower().replace("“", '"').replace("”", '"')
    plano = plano.replace("‘", "'").replace("’", "'")
    return re.sub(r"\s+", " ", plano).strip()


def evidencia_sostenida(evidencia: str | None, transcripcion: str | None) -> bool:
    if not evidencia or not transcripcion:
        return False
    base = _normalizar(transcripcion)
    if not base:
        return False
    fragmentos = [f for f in ELISION.split(_normalizar(evidencia)) if f]
    if not fragmentos:
        return False
    return all(fragmento in base for fragmento in fragmentos)

Note the last line: every fragment has to appear. A model that quotes one real sentence and appends a fabricated one fails the check, which is the correct outcome.

Stripping accents is deliberate. Transcript pipelines produce inconsistent diacritics — ASR output, diarization labels, and imported captions do not agree on spelling, and a strict comparison would flag correct quotes as false. If you strip accents for matching, you also have to strip them from the quote, which is what _normalizar does.

The behavior change matters more than the check

Now the interesting part. A check that only records a warning changes nothing. The check has to change what happens to the score.

Two decisions carried most of the weight:

1. Unsupported evidence drops the confidence to zero. Not to "low" — to zero. Confidence in that system means "how much does the evidence support this score". If the evidence does not exist, the evidence supports nothing, and the correct confidence is zero. This also makes the routing automatic, because a zero-confidence score is below any sane review threshold and goes to a human. No new code path, no new flag.

2. The evidence keeps the failure attached. When the check fails, the stored evidence is the model's string plus a marker:

if not evidencia_sostenida(evidencia, recording.transcript):
    confianza = 0.0
    evidencia = (evidencia + " " + NO_VERIFICADA).strip()

Do not silently discard the model's answer. You want to see what it claimed, because the pattern of the failures is diagnostic: a model that paraphrases on one criterion and quotes correctly on another is telling you something about that criterion's wording.

The metric that makes it visible

A check that only logs is a check nobody reads. The pipeline now reports the rate of unverifiable citations:

def calidad_evidencia(session) -> dict:
    total = session.scalar(select(func.count(Score.id))) or 0
    if not total:
        return {"puntajes": 0, "no_verificadas": 0, "tasa_no_verificada": None}
    no_verificadas = session.scalar(
        select(func.count(Score.id)).where(Score.evidence.like(f"%{NO_VERIFICADA}%"))
    ) or 0
    return {
        "puntajes": int(total),
        "no_verificadas": int(no_verificadas),
        "tasa_no_verificada": round(no_verificadas / total, 3),
    }

That single number tells you whether your evaluation system is auditable. If the rate is near zero, the model is quoting and the review layer is cheap. If it is high, the scores are prose, and the numbers in your dashboard are decoration.

In my experience this rate correlates with how vague the rubric is. A criterion that says "the agent explains the procedure properly" gives the model nothing to quote, so it describes. A criterion that says "the agent states the return window in days and the shipping cost" gives it a quote to find. Fixing the rubric fixes the evidence rate — which is the same lesson as always, arriving from a different direction.

What this does not solve

Two things, so you do not over-engineer around them:

A quote can be real and still irrelevant. The model may quote a sentence that exists but does not support the score it assigned. String matching catches fabrication, not misattribution. That needs human review, which is the part of the system you were never trying to remove.
Paraphrase-heavy transcripts break matching. If the "transcript" is a summary rather than a verbatim record, nothing will match. Verify at the boundary: assert that the transcript you store is the verbatim source, not a cleaned-up version.

If you build one thing from this

Add the check and the zero-confidence rule. It is about fifteen lines and one metric, and it converts an instruction into an enforcement.

The prompt can tell the model to quote. Only code can tell you whether it did.

This is part of the QA with AI series. The kit I use for this, with the judge prompt, the rubric guide and the deviation reports, is here: https://kit-qa-con-ia.surge.sh/ (MIT license, US$79). If you only want the idea, the check above is the whole thing.

One question for you: if you have an LLM scoring pipeline in production right now, what percentage of the stored evidence strings would survive a literal substring check against your transcripts? I would bet it is lower than you expect, and I would like to hear the real number.

3 reglas para que tu LLM no invente justificaciones

Gecko2087 — Fri, 13 Nov 2026 02:17:28 +0000

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:

Pedí JSON con esquema estricto y evidence obligatorio. Si tu proveedor no lo soporta, parseá con regex: es peor, pero funciona.
temperature=0.
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.

Tu IA no esta mal. Tu criterio de evaluacion esta mal.

Gecko2087 — Thu, 12 Nov 2026 10:48:47 +0000

Cuando pusimos IA a evaluar llamadas, el promedio dio 7,0 y todos felices.

Hasta que los supervisores empezaron a rechazar evaluaciones. No un par: seis de cada diez.

El sintoma que parece del modelo

El modelo puntuaba 7,0 y escribia un parrafo impecable para justificarlo. El problema es
justo ese: las justificaciones convincentes son el sintoma, no la causa. Cuando el
argumento suena bien, el supervisor deja de mirar y acepta el numero.

Entonces los rechazos no eran "el modelo se equivoca". Eran "el modelo se equivoca de una
forma que mi supervisor no comparte".

Donde estaba realmente el bug

Tardamos dos semanas en cambiar prompts. No mejoro nada. El bug estaba en la rubrica.

Teniamos un criterio que decia, mas o menos:

"El agente identifica correctamente el problema del cliente y ofrece una solucion
adecuada."

Ese criterio tenia dos cosas dentro:

que el agente identifique el problema
que ofrezca una solucion adecuada

El modelo cumplia la primera y no la segunda (en los casos donde identificaba el problema pero
ofrecia una solucion parcial). El supervisor evaluaba las dos juntas.

Resultado: el modelo resolvia "bien" una pregunta mal formulada. Y el 60% de los rechazos
venia de ahi.

El fix: partir el criterio y explicitar la excepcion

Criterio 1: El agente identifica el problema del cliente antes de responder.
  - Evidencia: cita la frase donde el cliente describe el problema.
  - Si el agente responde algo no solicitado, el criterio no se cumple.

Criterio 2: El agente ofrece una solucion concreta y completa para el problema identificado.
  - Evidencia: cita la propuesta del agente.
  - Excepcion explicita: si el cliente pide escalar o el agente transferiste, el criterio
    no se cumple (no es una falla del agente).

La parte que mas costo fue la excepcion explicita. Sin ella, los casos de escalamiento
y transferencia contaban como fallas, y el modelo (correctamente) no ofrecia solucion porque
no correspondia.

Partirlo y explicitarlo: los rechazos bajaron a la mitad en una semana, sin tocar el
modelo ni el prompt.

Tres reglas que lo hacen auditable

Esto es lo que uso en el pipeline de produccion:

Cada puntaje cita la frase exacta de la transcripcion. Sin cita, no hay punto. Sin eso, el error es invisible y el supervisor deja de verificar.
Si hay evidencia en contra, el puntaje es bajo, aunque en otro momento de la conversacion haya estado bien. Si no, el modelo promedia, y promediar es lo que vuelve inutil un sistema de QA.
La confianza es cuanto sostiene la evidencia el puntaje, no cuanto seguro se siente el modelo. Son cosas distintas, y confundirlas hace que el muestreo automatico descarte justamente los casos que importan.

El numero que casi nadie tiene

El promedio no sirve para nada. Un contact center puede tener 8 de calificacion y seguir
rompiendose en dos criterios concretos.

El numero que si sirve es cuanto se aleja tu IA de lo que evalua tu supervisor, en los
casos que si se revisaron. Ese numero te dice si tu sistema sirve, y te dice que criterio
definir mal.

Lo que me llevo de esto

La mayor parte del trabajo no es de IA. Es de escribir bien lo que queres que pase. La IA
solo te muestra, en 400 conversaciones, donde tu definicion de "bien" no cierra.

Arme un kit con el prompt del juez (con el porque de cada regla), una guia de rubrica con
12 criterios copiables de operaciones de soporte y cobranzas reales, la API en FastAPI y la
UI de revision. Es codigo abierto (MIT) y corre en Docker:

Kit QA con IA (US$79): https://kit-qa-con-ia.surge.sh/

Si estas evaluando calidad con IA y tu modelo "se equivoca", empezaria por la rubrica, no
por el prompt. De hecho, es al reves: el prompt es lo facil.

Este articulo es parte de una serie sobre evaluacion de calidad con IA en contact centers.
Si te sirve, el kit incluye la rubrica completa con los 12 criterios y sus excepciones ya
escritas.