Calidad
En una interacción simple con un modelo es natural evaluar el resultado final.
Pedimos un resumen.
Leemos el resumen.
Decidimos si sirve.
En un agente esa estrategia empieza a quedarse corta.
El sistema puede haber realizado varias búsquedas, seleccionado herramientas, descartado fuentes, interpretado resultados intermedios, corregido un plan y pedido —o no pedido— intervención humana.
Dos agentes pueden entregar documentos finales casi idénticos siguiendo trayectorias radicalmente diferentes.
Y esas trayectorias pueden importar jurídicamente.
La calidad de un agente no puede reducirse a:
“¿La respuesta final parece correcta?”
Para este handbook evaluaremos al menos cuatro dimensiones:
resultado · trayectoria · evidencia · capacidad de corrección.
La salida importa.
Pero también importa cómo se produjo, con qué sustento y si podemos localizar y reparar una falla.
Resultado: ¿cumplió el objetivo?
La primera dimensión sigue siendo el producto final.
Si el objetivo era preparar una matriz de revisión contractual, podemos preguntar:
- ¿está completa?;
- ¿es jurídicamente útil?;
- ¿incluye las materias requeridas?;
- ¿la redacción es comprensible?;
- ¿respeta el formato?;
- ¿separa hallazgo, evidencia e inferencia?;
No debemos restar importancia a la salida.
Un sistema con una trayectoria impecablemente registrada que produce un informe incorrecto sigue siendo un sistema de mala calidad para esa tarea.
El problema del “parece correcto”
En IA generativa existe una dificultad adicional: la fluidez puede ocultar errores.
Un informe puede estar:
- bien estructurado;
- bien redactado;
- lleno de terminología pertinente;
- organizado en una tabla profesional;
y aun así contener:
- una cita inexistente;
- una omisión material;
- una fuente desactualizada;
- una clasificación errónea.
Por eso el resultado debe evaluarse contra criterios definidos, no sólo mediante impresión general.
Definir qué significa “bueno”
Antes de medir calidad debemos definir el objetivo y los criterios.
Por ejemplo, para una matriz contractual:
COMPLETITUD
cubrir las materias obligatorias
CORRECCIÓN
no atribuir al contrato obligaciones inexistentes
EVIDENCIA
cada hallazgo material debe tener fuente verificable
UTILIDAD
indicar consecuencia y acción siguiente
PRUDENCIA
identificar incertidumbre cuando correspondaGoogle insiste en que la evaluación debe partir por definir qué significa “mejor” para el caso de uso. Huyen también trata la evaluación como parte continua del desarrollo de aplicaciones, no como una prueba final aislada.
Trayectoria: ¿cómo llegó al resultado?
La trayectoria es la secuencia de decisiones y acciones que condujo a la salida.
Puede incluir:
solicitud
→ clasificación
→ búsqueda
→ documento recuperado
→ herramienta
→ resultado
→ nueva decisión
→ comparación
→ revisión
→ salidaEn las clases se formula mediante preguntas muy concretas:
¿qué fuentes leyó?
¿qué herramienta usó?
¿qué descartó?
¿dónde dudó?
Por qué importa
Supongamos que dos agentes concluyen correctamente:
“La cláusula permite terminación unilateral por parte del proveedor.”
El primero llegó a la conclusión leyendo la cláusula 12.3.
El segundo utilizó un resumen antiguo del contrato y acertó por coincidencia.
El resultado puede ser idéntico.
La confiabilidad del proceso no lo es.
Calidad de proceso
Podemos preguntar:
- ¿seleccionó la herramienta adecuada?;
- ¿usó las fuentes correctas?;
- ¿reconoció errores de herramientas?;
- ¿repitió pasos innecesarios?;
- ¿se desvió del objetivo?;
- ¿escaló cuando correspondía?;
Google denomina este enfoque evaluación de trayectoria o proceso y lo contrapone a mirar únicamente la salida.
Evidencia: ¿podemos respaldar los hallazgos?
La tercera dimensión es especialmente importante para trabajo jurídico.
Un sistema no debería producir solamente:
“Riesgo alto en privacidad.”
Deberíamos poder reconstruir algo como:
HALLAZGO
El proveedor puede reutilizar contenido para mejorar el servicio.
EVIDENCIA
Contrato, cláusula 8.4.
CRITERIO
Política interna de uso secundario, versión vigente.
INFERENCIA
La autorización contractual es más amplia que el estándar interno.
INCERTIDUMBRE
Falta revisar la definición de “Service Data”.La evidencia permite revisar tanto el contenido como el razonamiento observable de la aplicación.
Citar no basta
Una cita puede ser incorrecta.
Una cláusula puede existir pero no sustentar la conclusión.
Por eso la evaluación de evidencia tiene al menos tres preguntas:
- ¿la fuente existe?;
- ¿el fragmento citado corresponde?;
- ¿la inferencia se sigue razonablemente de ese material y del criterio aplicado?
Capacidad de corrección
Ésta es la dimensión que suele olvidarse.
Un sistema profesional no debería evaluarse únicamente por cuántas veces acierta.
También importa:
cuando falla, ¿podemos identificar dónde falló y corregir el proceso?
Corregir el resultado versus corregir el sistema
Supongamos que el agente clasifica mal un riesgo porque recuperó una política antigua.
Podemos editar manualmente la frase final.
Eso corrige el documento.
Pero si la siguiente ejecución vuelve a recuperar la misma política, no corregimos el sistema.
Una capacidad real de corrección requiere poder localizar:
fuente equivocada
→ por qué fue recuperada
→ qué criterio de vigencia faltó
→ qué etapa debe modificarse
→ qué casos deben volver a probarseCorrección localizada
Una arquitectura modular ayuda.
Si sabemos que el error ocurrió en recuperación, podemos mejorar esa capa sin reescribir necesariamente todo el agente.
Si el problema está en el evaluator, ajustamos la rúbrica.
Si la herramienta recibió parámetros incorrectos, revisamos su interfaz o validación.
La calidad incluye capacidad de diagnóstico.
Evaluar por capas, no sólo con una nota final
Un agente es un sistema compuesto. Por eso una evaluación útil puede separar distintos puntos de falla.
Por ejemplo:
| Capa evaluada | Pregunta |
|---|---|
| Interpretación inicial | ¿entendió correctamente el encargo? |
| Planificación | ¿el plan era suficiente y permitido? |
| Recuperación | ¿trajo las fuentes correctas y vigentes? |
| Herramientas | ¿seleccionó la herramienta adecuada y parámetros válidos? |
| Interpretación de tool output | ¿entendió correctamente el resultado? |
| Síntesis | ¿la conclusión refleja la evidencia? |
| Control | ¿escaló y pidió aprobación cuando correspondía? |
Google utiliza una lógica semejante al analizar la trayectoria “desde dentro”: planificación, selección y parametrización de herramientas, interpretación de respuestas, desempeño de RAG, eficiencia, robustez y dinámica multiagente.
La ventaja de evaluar por capas es diagnóstica.
Si un informe falla, no concluimos automáticamente:
“el modelo es malo”.
Podemos descubrir que:
- el modelo razonó correctamente sobre una fuente equivocada;
- la herramienta correcta recibió un parámetro incorrecto;
- el RAG recuperó una política obsoleta;
- la regla de aprobación nunca se activó.
Cada falla exige una corrección distinta.
Calidad antes, durante y después del despliegue
La evaluación tampoco debería ocurrir una sola vez.
Podemos distinguir tres momentos.
Antes de producción
Probar casos representativos y casos límite.
Durante producción
Observar métricas, errores, revisiones humanas y nuevas clases de uso.
Después de incidentes o cambios
Convertir fallas reales en nuevos casos de prueba.
Así la evaluación se transforma en un ciclo de mejora y no en una certificación estática.
Una modificación aparentemente menor —un prompt, una herramienta, una fuente o una versión de modelo— puede alterar la trayectoria. Por eso resulta útil volver a probar comportamientos previamente aceptados después de cambios materiales.
Un ejemplo completo
Un agente debe preparar un informe sobre un proveedor de IA.
La salida final dice:
“No se identifican transferencias internacionales de datos.”
La frase parece plausible.
Evaluación del resultado
Incorrecto: el DPA contiene una lista de subprocesadores fuera del país.
Evaluación de trayectoria
La trace muestra que el agente:
- abrió contrato principal;
- buscó “transferencia internacional”;
- no encontró coincidencias;
- nunca abrió el DPA;
- concluyó ausencia.
El problema ya es identificable.
Evaluación de evidencia
La conclusión no tenía evidencia positiva.
Confundió:
“no encontré una referencia”
con:
“la transferencia no existe”.
Capacidad de corrección
Podemos modificar el procedimiento:
toda evaluación de transferencias debe verificar contrato + DPA + lista de subprocesadores.
Después volvemos a ejecutar los casos de prueba afectados.
Este ejemplo muestra por qué la trayectoria y la evidencia convierten un error en algo corregible.
Calidad y probabilismo
Los agentes basados en modelos generativos pueden producir variación entre ejecuciones.
Por eso una prueba individual tiene poco valor estadístico.
No basta:
“Lo probé una vez y funcionó.”
Necesitamos un conjunto de casos representativos.
Google propone conjuntos de evaluación o golden sets con escenarios esperados, incluidos algunos casos inesperados. Huyen recomienda diseñar pipelines de evaluación y criterios antes de depender del sistema en producción.
Casos normales y casos difíciles
Una evaluación útil debería incluir:
- casos rutinarios;
- documentos incompletos;
- información contradictoria;
- herramientas que fallan;
- consultas fuera de alcance;
- situaciones que deben escalarse.
En agentes, saber abstenerse o pedir ayuda puede ser parte de la calidad.
Calidad no es una sola cifra
Un agente puede mejorar en exactitud y empeorar en costo.
Puede ser más rápido y cometer más omisiones.
Puede completar más tareas pero pedir menos aprobaciones de las debidas.
Por eso conviene observar varias dimensiones.
Google organiza su marco de calidad mediante atributos como efectividad, eficiencia, robustez y seguridad. Para nuestro curso no necesitamos adoptar esa taxonomía como estructura principal; basta conservar la intuición:
“mejor” debe definirse respecto de la función y de los riesgos del sistema.
Evaluación humana y evaluación automatizada
Parte de la evaluación puede automatizarse.
Un sistema puede comprobar:
- campos obligatorios;
- cumplimiento de formato;
- existencia de una fuente;
- número de tool calls;
- latencia;
- resultado de una función.
También pueden utilizarse modelos para evaluar outputs contra rúbricas.
Pero en tareas jurídicas complejas continúa siendo necesaria validación de dominio.
La ABA y el CCBE enfatizan que los abogados deben revisar outputs cuando el caso de uso lo requiere y continúan siendo responsables por el trabajo profesional.
La evaluación automatizada ayuda a escalar control.
No transforma al evaluador automático en autoridad jurídica final.
Una matriz de calidad mínima
| Dimensión | Pregunta | Ejemplo de evidencia |
|---|---|---|
| Resultado | ¿Cumplió el objetivo? | matriz final |
| Trayectoria | ¿Siguió una ruta adecuada? | secuencia de pasos |
| Evidencia | ¿Los hallazgos están respaldados? | cláusulas y fuentes |
| Corrección | ¿Podemos localizar y reparar fallas? | diagnóstico + reejecución |
Las cuatro dimensiones se refuerzan mutuamente.
Sin observabilidad, la trayectoria es difícil de evaluar.
Sin evidencia, la salida es difícil de verificar.
Sin capacidad de corrección, la evaluación produce diagnóstico pero no mejora.
Qué puede salir mal
Evaluar sólo demos felices
Mide capacidad, no confiabilidad.
Confundir formato con calidad
Una salida perfectamente estructurada puede ser sustantivamente falsa.
Utilizar una rúbrica vaga
“Sé correcto y útil” es difícil de medir consistentemente.
Optimizar una métrica aislada
Reducir latencia puede aumentar errores o eliminar verificaciones importantes.
Corregir manualmente sin retroalimentar el sistema
Oculta fallas repetibles.
Qué debes recordar
En agentes, la salida final es solamente una parte de la calidad.
También necesitamos saber:
- qué trayectoria siguió;
- qué evidencia utilizó;
- si el proceso puede diagnosticarse y corregirse.
Por eso la pregunta:
“¿Funciona?”
se vuelve demasiado simple.
Una mejor versión es:
“¿funciona de manera suficientemente correcta, trazable y corregible para esta tarea y este nivel de riesgo?”
El problema que todavía queda abierto
Para evaluar una trayectoria debemos poder verla.
Eso nos conduce a una infraestructura conceptual nueva:
observabilidad.
La siguiente página distingue cuatro mecanismos para reconstruir y supervisar el comportamiento del agente:
logs, traces, métricas y auditoría.