Cómo evaluar un modelo de lenguaje en tu empresa (si responde bien o no)

El día que cambias el modelo y nadie sabe si respondió mejor o peor

La escena se repite en cualquier empresa que ya usa un modelo de lenguaje para algo que le importa: atender clientes, redactar respuestas, resumir casos, clasificar tickets. Alguien prueba el cambio a mano, con las preguntas que se le ocurren en el momento, y si las respuestas “se ven razonables” lo aprueba. No hay nada escrito de por qué se aprobó, ni con qué se comparó. La aprobación vive en la cabeza de una persona durante cinco minutos y después desaparece.

El costo de ese vacío no se nota el mismo día. Se nota tres semanas después, cuando el agente le da a un cliente una respuesta que contradice la política vigente, o cuando deja de escalar un reclamo que antes sí escalaba, o cuando cambia el tono y empieza a sonar cortante en un canal donde antes sonaba cordial. En ese momento el equipo se pregunta si el modelo nuevo es peor que el anterior, y la respuesta honesta es que nadie lo sabe, porque nunca se guardó un conjunto de casos con la respuesta esperada para poder comparar una versión contra la otra.

Sin ese conjunto, hasta una decisión tan básica como qué LLM elegir para una empresa se reduce a una preferencia personal disfrazada de análisis técnico: alguien prefiere cómo “suena” un proveedor sobre otro, sin haber corrido ni un solo caso real de la operación por los dos. La pregunta que de verdad importa no es qué modelo parece más inteligente en una conversación de prueba. Es si responde bien, muchas veces seguidas, sobre los casos que tu empresa enfrenta todos los días.

Evaluar no es que “suene bien”, es correr el mismo examen dos veces

Hay una confusión de fondo que conviene resolver antes de seguir. Un resultado que un laboratorio publica sobre su propio modelo mide capacidad general en tareas genéricas: razonamiento abstracto, matemática, código de ejemplo. Ese número no dice nada sobre si el modelo respeta tu política de devoluciones, si mantiene el tono de tu marca frente a un cliente molesto, o si sabe cuándo callarse en vez de inventar. Comparar proveedores por su reputación pública es un punto de partida razonable para armar una primera lista corta, y nada más que eso.

Evaluar de verdad significa otra cosa: dejar de mirar respuestas sueltas y empezar a correr, cada vez que algo cambia, el mismo conjunto de casos con su respuesta esperada al lado.

Dos palabras de esa definición cargan todo el peso. “Conjunto fijo” quiere decir que el examen no se reinventa cada vez: es el mismo banco de casos que se corre antes y después de un cambio, porque si cambias las preguntas junto con el modelo, dejaste de medir lo mismo y ninguna comparación sirve. “Casos reales” quiere decir que esas preguntas salen de tu operación, no de lo que un equipo cree que preguntan los clientes. Con esas dos condiciones, evaluar deja de ser una impresión y se convierte en un procedimiento que cualquiera puede repetir y auditar.

Cómo se arma el set de casos de prueba con la operación real

El set de casos no se inventa en una sala de reuniones. Sale de conversaciones que ya atendió una persona: tickets de soporte cerrados, chats de ventas, consultas resueltas por el área que hoy hace ese trabajo a mano. De cada una ya se sabe cuál era la respuesta correcta según la política vigente en ese momento, así que armar el caso de prueba es casi trabajo de copiar y ordenar, no de imaginar un escenario nuevo.

Cubrir solo lo fácil no sirve de nada, porque lo fácil rara vez es lo que rompe algo en producción. Un set de casos serio reparte su atención entre varios tipos de situación:

• Casos frecuentes: las preguntas y solicitudes que se repiten todos los días, el volumen real sobre el que el sistema va a operar la mayor parte del tiempo.
• Casos límite: los que rozan una excepción, un descuento que no está en la tabla, una condición que depende de un dato que el modelo no siempre tiene a mano.
• Casos donde lo correcto es “no lo sé”: preguntas sobre información que el sistema no tiene, donde la respuesta esperada es abstenerse o derivar, no inventar algo plausible.
• Intentos de manipular la respuesta: un usuario que insiste, presiona o pide directamente que se ignore una regla o una política.
• Casos con información contradictoria o incompleta: dos políticas que chocan entre sí, un dato que falta en el sistema, una condición vencida que nadie actualizó.

No hace falta un archivo gigantesco para que esto funcione. En la práctica, un conjunto de unas pocas decenas de casos bien elegidos, que cubra los cinco tipos de arriba, detecta más problemas reales que un archivo de miles de preguntas fáciles armado sin ese criterio: ese archivo grande solo da una sensación de rigor que no existe. Este nivel de cuidado en cómo se arma el examen, y no solo en qué modelo se compra, es justamente lo que distingue a una empresa AI Native de una que instaló un chatbot y espera que funcione solo.

Qué se mide en cada caso: no solo si acertó

Correr el set de casos no sirve de mucho si la única pregunta que se hace es “¿acertó o no?”. Evaluar de verdad implica mirar varias dimensiones a la vez sobre cada respuesta:

• Exactitud: la respuesta coincide con la información real vigente de la empresa (el precio actual, la política de hoy, el dato que hay en el sistema), no con algo que sonaba plausible.
• Formato: respeta la estructura esperada para ese tipo de consulta, ya sea la extensión, si debe enumerar pasos, si debe citar de dónde saca el dato, o si debe usar el nombre del cliente.
• Tono: suena a la marca y al canal, ni tan robótico que incomoda, ni con un entusiasmo que no corresponde frente a un reclamo o una queja.
• Qué hace cuando no sabe: si se abstiene y deriva la conversación a una persona, o si inventa una respuesta con la misma seguridad que si de verdad supiera.

La mayoría de las empresas mide solo la primera dimensión y da por hecho las otras tres, hasta que una de ellas falla frente a un cliente real. Esa última dimensión, qué hace el modelo cuando no sabe, es la que menos se revisa y la que más cuesta cuando se ignora: entender qué pasa cuando la IA da información incorrecta a un cliente no es una curiosidad técnica, es exactamente el costo de no haber medido esto antes de subir el cambio a producción.

Quién evalúa: por qué el área técnica sola no alcanza

El equipo técnico puede armar el set, correrlo automáticamente cada vez que algo cambia, y revisar lo que se mide sin criterio de negocio: formato, tiempos de respuesta, señales de seguridad, si el sistema reveló algo que no debía. Eso es necesario, pero no alcanza.

Solo el área usuaria (quien atiende al cliente hoy, quien conoce la política vigente al detalle, quien maneja la excepción todos los días) puede certificar si una respuesta es correcta en el contexto real del negocio. Alguien de tecnología, sin ese contexto, puede leer una respuesta bien redactada y aprobarla sin darse cuenta de que cita una política que cambió el mes pasado.

Dejarlo solo en manos del área usuaria tampoco alcanza, porque revisar caso por caso sin apoyo técnico no escala ni detecta patrones entre cientos de respuestas. La evaluación seria reparte el trabajo: el área técnica arma el set y corre la comparación, el área usuaria certifica los casos límite y de negocio, y ninguna de las dos partes firma la aprobación sola.

Cada cuánto se repite la evaluación (no es examen de una sola vez)

La evaluación no es un examen que se rinde una vez y queda aprobado para siempre. Se repite en dos momentos distintos, y confundirlos es donde la mayoría de las empresas se relaja de más.

El primero es reactivo: cada vez que cambia el modelo, el proveedor o el prompt, sin excepción, antes de que ese cambio llegue a los clientes reales. No hay cambio “chico” que se salte este paso: un ajuste de una frase en el prompt puede mover el comportamiento tanto como cambiar de proveedor entero.

El segundo es preventivo, y es el que casi nadie hace: una revisión periódica aunque nada haya cambiado a propósito. El comportamiento de un sistema se degrada solo con el tiempo, a medida que el negocio cambia su política, sus clientes cambian su forma de preguntar, y el contexto alrededor deja de parecerse al que existía cuando se armó el set original. Ese deterioro silencioso tiene nombre: se conoce como deriva de modelo, y solo se detecta si alguien vuelve a correr el examen aunque nadie haya tocado nada.

Cómo se detecta una regresión al cambiar de modelo o de prompt

Detectar una regresión no es complicado en el método, aunque sí exige disciplina. Se corre el mismo set fijo con la versión anterior y con la nueva, caso por caso, y se compara respuesta contra respuesta. La condición que no se puede saltar: el examen tiene que ser exactamente el mismo en ambas corridas. Si armas un set de prueba distinto para el modelo nuevo, dejaste de medir lo mismo, y cualquier conclusión que saques de esa comparación es ruido, no evidencia.

Lo segundo que importa es no quedarse solo con el promedio. Un cambio puede mejorar el resultado general y, al mismo tiempo, empeorar justo el caso que más le importa al negocio, el que toca dinero o el reclamo de un cliente grande. Si solo miras un puntaje total, ese deterioro puntual se esconde detrás de un número que en conjunto se ve mejor. Hay que revisar caso por caso qué empeoró, no solo cuánto mejoró el promedio.

La forma más segura de hacer esta comparación es correr la versión nueva en paralelo, sin que reemplace del todo a la anterior en producción, durante unos días antes de decidir. Es la misma lógica que conviene aplicar al pensar en cómo cambiar de modelo de IA sin perder lo construido: el cambio se prueba antes de que el cliente lo note, nunca después.

El umbral aceptable no es el mismo para toda tarea

No toda tarea exige el mismo nivel de exigencia, y tratar todas por igual es un error en los dos sentidos: exigir de más en una tarea de bajo riesgo frena al equipo sin necesidad, y exigir de menos en una tarea de alto riesgo deja pasar un error caro.

• Tareas de alto impacto: las que tocan dinero, datos legales o de salud, o que hablan directo con el cliente sin que nadie revise antes. El margen de error tiene que acercarse a cero, y los casos límite necesitan revisión humana antes de responder.
• Tareas de impacto medio: borradores, recomendaciones o resúmenes que una persona revisa antes de que salgan. El margen puede ser mayor porque hay alguien en el medio que corrige antes de que el error llegue a alguien más.
• Tareas de bajo impacto: clasificar, ordenar o resumir información interna que nadie más ve. El margen es más amplio porque el costo de equivocarse es bajo y fácil de corregir.

Lo que no puede pasar es fijar el umbral después de ver el resultado. Si el número “aceptable” se decide una vez que ya se sabe cómo salió la prueba, deja de ser un criterio y se convierte en una excusa para aprobar lo que ya se decidió subir. El umbral se declara antes de correr el set, para cada tipo de tarea, y ese mismo umbral es la base para, más adelante, saber si tu sistema de IA está funcionando bien en producción, no solo el día en que se aprobó.

Mi criterio sobre cuándo un modelo está listo para producción