¿Qué es evaluación? Medir si el sistema funciona, en vez de suponerlo

Un modelo que acierta la respuesta tres veces seguidas no te dijo casi nada. Lo corriste tres veces, sobre inputs que vos elegiste, y se veía bien — así que sale, y la primera vez que un usuario real formula la pregunta de una forma que nunca probaste, devuelve algo equivocado con total seguridad y nadie se entera hasta que se queja. Esta es la trampa del vibe-check, y casi todo sistema de IA que se rompe en producción se rompió acá primero: nunca se midió, solo se muestreó, y una muestra de tres que elegiste vos misma es una impresión, no un test. La evaluación es la disciplina que reemplaza la impresión por una medición — un número que podés puntuar, mirar a lo largo del tiempo, y defender cuando alguien pregunta "¿cómo sabés que funciona?".

Este es el principio 3 — si no lo podés evaluar, no lo podés shipear — y es la columna de toda esta subcategoría. El reframe es el mismo que hace grounding para los hechos y context engineering para la ventana: dejá de confiar en cómo se siente el output y empezá a medir lo que hace. Sin una eval, cada cambio de prompt es una moneda al aire que no podés puntuar y cada regresión sale en silencio. Esta página expone el loop que arregla eso, traza la línea entre testear antes de salir y vigilar después, nombra el vocabulario sobre el que se apoya el resto de la subcategoría, y encuadra las tres formas de calificar una respuesta.

El loop de eval

La evaluación no es una compuerta de una sola vez que pasás antes del lanzamiento; es un loop que corrés en cada cambio. Tiene cuatro pasos, y la disciplina es correr los cuatro en vez de frenar en el primero que se siente terminado:

Definir criterios de éxito — decidir qué significa "funcionar" antes de medir, en términos lo bastante específicos y medibles como para puntuarlos. "Buenas respuestas" no es un criterio; "clasifica el ticket en la categoría correcta" o "cita una fuente real para cada afirmación" sí lo es. La guía de Anthropic es la vara acá: los criterios deberían ser específicos, medibles, alcanzables y relevantes — metas vagas producen evals vagas que no te dicen nada.
Construir un eval set — armar los inputs contra los que vas a testear, cada uno emparejado con cómo se ve una respuesta correcta. Este es el activo sobre el que gira todo el loop, y su versión más valiosa se construye a partir de fallas reales a medida que pasan, no inventadas en un escritorio (principio 3 — los primeros diez casos que te mordieron en testing valen más que cien sintéticos).
Calificar — correr el sistema sobre el eval set y puntuar cada output contra su criterio. Cómo calificás es la decisión que encuadra la segunda mitad de esta página: un chequeo determinístico, otro modelo como juez, o un humano.
Iterar — cambiar una cosa — el prompt, el retrieval, el modelo — volver a correr la eval, y comparar el puntaje con dónde estaba. El número se movió o no; esa es la señal que un vibe-check nunca te pudo dar.

El loop es el punto. Una sola corrida de calificación te dice dónde estás hoy; el loop te dice si un cambio mejoró o empeoró las cosas, que es la única pregunta que importa una vez que un sistema está en vivo y lo estás mejorando bajo presión.

Offline y online: antes de salir, y después

La evaluación pasa en dos lugares, y responden preguntas distintas. Los dos pertenecen a un sistema serio — no son una elección entre uno y otro, se componen.

La evaluación offline corre antes de salir, contra un eval set fijo con respuestas correctas conocidas. Es el test de pre-deployment: cambiás el prompt, corrés el eval set, y ves si el puntaje subió o bajó antes de que ningún usuario quede expuesto. Como el eval set está curado y sus respuestas se conocen, la eval offline es donde vive el regression testing — probar que una versión nueva es al menos tan buena como la anterior. Este es el loop de arriba, corrido en un laboratorio.

La evaluación online corre después de salir, sobre tráfico real de producción, donde no hay una respuesta correcta pre-escrita contra la cual comparar. Acá medís lo que podés sin ground truth: señales como si el usuario aceptó la respuesta, escaló a un humano, o reformuló y volvió a intentar, más chequeos de calidad que un juez puede aplicar a una respuesta en vivo al vuelo. La eval online es cómo atrapás la degradación silenciosa — la deriva lenta donde un sistema que pasó cada test offline empieza a empeorar en la cancha porque el tráfico se corrió o el modelo de abajo se movió. Depende del trace de lo que realmente pasó en producción, que es el principio 11 — no podés debuggear, ni evaluar, lo que no podés reproducir — y su profundidad es una página hermana sobre tracing y monitoreo.

La división honesta del trabajo: la eval offline prueba que un cambio es seguro de shipear; la eval online prueba que siguió bien una vez que salió. Salteate la primera y shipeás a ciegas; salteate la segunda y te enterás de la degradación por un cliente.

El vocabulario

Esta subcategoría se apoya en un conjunto chico y preciso de términos. Acá están una vez, en simple; vas a conocer cada uno en profundidad a medida que la subcategoría avanza.

Término	Qué significa
Eval set	La colección de inputs de prueba contra los que corrés el sistema, cada uno emparejado con el resultado esperado. El activo sobre el que gira todo el loop.
Golden dataset	Un eval set curado y confiable cuyas respuestas se saben correctas — los casos apartados contra los que medís, mantenidos estables para que los puntajes sean comparables en el tiempo.
Ground truth	La respuesta conocida como correcta para un input dado — la "respuesta correcta" contra la que se compara un output calificado. La materia de la que está hecho un golden dataset.
Metric	Una medida cuantificada de desempeño — accuracy, una tasa de aprobación, un puntaje de 1 a 5, el tiempo de respuesta. El número que produce una calificación.
Judge	Lo que hace la calificación. Un chequeo determinístico, otro modelo (LLM-as-judge), o un humano — cada uno puntuando un output contra su criterio.
Baseline	El puntaje contra el que estás comparando — normalmente la versión actual del sistema. Un cambio es una mejora solo en relación a un baseline.
Regresión	Un cambio que empeora el puntaje — un caso que antes pasaba y ahora falla. Lo que la eval offline existe para atrapar antes de que salga.

Cada uno de estos recibe una página o una sección propia a medida que la subcategoría avanza. Acá son solo las palabras, para que el resto se lea limpio.

Cómo calificás: tres formas, y cuándo encaja cada una

La decisión más difícil en evaluación no es si calificar sino cómo — qué cumple el rol de juez. Hay tres opciones, hacen el mismo trade-off siempre, y un eval set real por lo general las mezcla según la pregunta que hace cada caso. Esta página encuadra la elección; la profundidad de construir bien cada juez vive en páginas hermanas — un chequeo determinístico es el más barato, el [Style Guide de Evaluación] fija la vara que un juez pasa antes de que confíes en sus puntajes, y la página de LLM-as-judge va en profundidad sobre el caso calificado por modelo.

Metric determinístico — el código chequea el output contra una regla: exact match contra ground truth, una frase clave presente, JSON válido, un número en rango. El más rápido, el más barato, perfectamente repetible, y la elección correcta siempre que la respuesta es clara — una categoría, un campo, un sí o un no. Su límite es el matiz: no puede juzgar si la prosa es buena, solo si coincide.
LLM-as-judge — otro modelo califica el output contra un rubric que vos escribís, devolviendo un puntaje o un veredicto. Así calificás las cosas que una regla no alcanza — coherencia, tono, si una respuesta es fiel a sus fuentes — a una velocidad y un costo que un humano no puede igualar. El detalle es que el juez es en sí mismo un modelo no determinístico que hay que evaluar antes de confiar en él; un rubric vago produce un juez poco confiable, y un juez que no chequeaste es solo una segunda opinión que estás esperando que tenga razón.
Humano — una persona lee el output y lo puntúa. La señal más flexible y de más alta calidad, y la fuente de verdad contra la que las otras dos se validan en última instancia — pero lenta y cara, así que la gastás donde se gana su lugar: construir el golden dataset, calibrar un juez LLM, y dirimir los casos que son genuinamente ambiguos. No es el método que escalás a miles de corridas.

El patrón en las tres: elegí el juez más barato que de verdad pueda responder la pregunta que hace este caso. Determinístico donde la respuesta es exacta, un modelo donde necesita un juicio que podés especificar en un rubric, un humano donde necesita un juicio que no podés — y validado por humanos por debajo, porque las otras dos son tan confiables como el ground truth que estableció una persona.

La columna: tres superficies, compuestas por dónde corre el sistema

La evaluación no es una sola herramienta. Como grounding y prompting antes que ella, las superficies se componen — son instrumentos complementarios que un ingeniero elige según dónde corre el sistema, nunca productos rivales para elegir entre ellos. El hilo conductor que cada Style Guide de este catálogo ya invoca — evaluá cada cambio — se sostiene idéntico en las tres; solo difiere el tooling.

Agentforce Testing Center y observabilidad — cuando el agente corre en Agentforce dentro del modelo de seguridad de Salesforce, lo evaluás donde vive: una superficie de testing para correr casos contra el agente antes de la release, y observabilidad para lo que hace en producción, con traces que pueden fluir hacia afuera a través de OpenTelemetry hacia Data 360. La eval hereda el modelo de seguridad de la plataforma y se queda al lado de la data sobre la que el agente actúa.
Tooling de eval de Anthropic y LLM-as-judge — en la capa del modelo, cuando estás llamando a Claude directo, evaluás contra el loop de definir-criterios-y-después-calificar que Anthropic documenta, con LLM-as-judge como el método de calificación para todo lo que un chequeo determinístico no alcanza. Esta es la capa que califica el comportamiento crudo del modelo, independiente de dónde se embeba después.
LangSmith — cuando el sistema corre fuera de plataforma, sobre un loop de control custom, LangSmith es la superficie de evaluación y tracing: datasets de ejemplos, eval offline antes de salir, y eval online sobre traces en vivo. Es donde el loop de eval de un agente fuera de plataforma y su monitoreo de producción viven en un mismo lugar.

No elegís uno y le jurás lealtad. Un agente fundamentado en Data 360 y orquestado fuera de plataforma podría testearse en Testing Center, calificarse en la capa del modelo con un juez LLM, y tracearse en LangSmith — cada superficie haciendo la parte para la que está construida. El oficio es componerlas al sistema que realmente construiste, que es la misma lógica de composición del toolkit que recorre los principios de AI Engineering.

A dónde ir después

Desde acá, la subcategoría construye hacia afuera desde el loop que esta página encuadró. El activo sobre el que gira todo — cómo construir un eval set y elegir las metrics que lo puntúan — es la página de eval datasets y metrics. El juez calificado por modelo, el que alcanza las cosas que una regla no puede, recibe su propia profundidad en la página de LLM-as-judge. Las superficies de plataforma — testing y observabilidad dentro de Salesforce — son la página de Agentforce testing y observabilidad, y el trace del que depende la eval online es tracing y monitoreo. Cuando una eval misma te engaña — un juez que puntúa mal, un set que se desvió de la realidad — eso es debuggear evals. Y la vara que una eval pasa antes de que confíes en ella es el Style Guide de Evaluación. (Esas hermanas están saliendo junto a esta página; nombradas acá, linkeadas una vez que salgan.)

La evaluación no está sola. Es la capa de medición debajo de todo lo demás que cubre este catálogo: puntúa si el grounding de verdad recuperó los hechos correctos, si un cambio de prompt o de contexto mejoró el output, y si un agente hace su trabajo lo bastante confiable como para shipear. Lo que se evalúa cambia; el loop no.

Qué es grounding — la evaluación puntúa si el retrieval puso los hechos correctos al alcance; esta es la disciplina de ponerlos ahí
Qué es context engineering — la evaluación es cómo sabés que un cambio de prompt o de contexto de verdad ayudó, en vez de suponerlo
Qué es un agente — el sistema más a menudo bajo evaluación: el loop puntúa si hace su trabajo de forma confiable
Debuggear agentes — tracear una corrida cuando sale mal, la misma reproducción de la que depende la evaluación online
Tools y actions — cada acción que un agente puede tomar es algo que una eval debería cubrir antes de que salga
Principios de AI Engineering — si no lo podés evaluar no lo podés shipear (3), traceá todo (11), una demo no es un producto (1)
Style Guide de IA de Marketing Cloud — la decisión de qué-superficie-para-qué-trabajo, una capa hacia afuera
Style Guide de evaluación — el marco de decisión que alimenta este vocabulario
Testing y observabilidad de Agentforce — la superficie in-platform del mismo loop de eval

Reference: