| Score en producción | Experimento sobre dataset | |
|---|---|---|
| Cuándo | Después, sobre tráfico real | Antes de desplegar |
| Sobre qué | Lo que preguntaron los usuarios | Ejemplos que elegiste tú |
| Referencia | No hay respuesta esperada | Sí: cada ejemplo trae la suya |
| Qué comparas | Hoy contra ayer | Variante A contra variante B |
| Qué detecta | Degradación en el mundo real | Regresión antes de que exista |
La primera te avisa de que algo va mal; la segunda te deja cambiar cosas sin cruzar los dedos.
Lo que hace que esto valga la pena no es el evaluador, es el dataset: se crea una vez y se reutiliza en cada cambio. La segunda evaluación ya es gratis en esfuerzo, y la vigésima también.
Si ajustas el prompt contra los mismos diez ejemplos hasta que los diez pasen, no has mejorado el sistema: lo has ajustado a diez ejemplos. Dos defensas baratas: un conjunto aparte que no toques mientras iteras, y crecer el dataset con los fallos reales, de modo que cada respuesta mala de producción entre como ejemplo nuevo.
El 100 % anunciado. La validación de la lección de datasets dice literalmente: "Deberías ver que GPT-3.5 acertó todas (Score: 1/1 en Correctness)". El dataset son tres preguntas: capital de Francia, de Australia y de Brasil. Tres ejemplos de cultura general no cubren casos borde ni tu dominio, y anunciar el 100 % como resultado esperado enseña el reflejo contrario al del módulo: un evaluador que aprueba todo no ha demostrado que tu sistema sea bueno, ha demostrado que no discrimina. Ese resultado se audita, no se celebra.
La API de evaluación. La guía usa
from langchain.smith import RunEvalConfig, run_on_dataset. ¿Sigue
existiendo ese import en las versiones que instales hoy, o la vía vigente es
evaluate() del paquete langsmith? Compruébalo antes de
escribir el ejercicio encima: si está retirado, el fallo llega en el import y no
en la lógica.
El A/B test de la última lección. Enruta tres preguntas al
azar 50/50 entre dos variantes y declara un "ganador por eficiencia" comparando la
media de len(texto)/4 como estimación de tokens. Con tres tiradas
una variante puede llevarse las tres — la propia guía lo admite en su
troubleshooting — y los tokens reales ya están registrados en las trazas,
así que se estima a ojo un dato que la herramienta tiene medido. Eso no es un A/B
test: es una anécdota con formato de tabla.
Monta un dataset mínimo con tus propios ejemplos y córrelo. Anota la nota agregada. Ahora añade tres ejemplos que estés bastante seguro de que tu sistema falla — los casos raros que te preocupan — y vuelve a correr sin cambiar nada del sistema.
Si la nota agregada no baja, el problema no está en tu cadena: está en tu evaluador, que no mira lo que crees que mira. Arregla eso antes de usar el dataset para decidir nada.