Hace poco, le pedí a la IA que me ayudara a pulir una entrada de blog.
Escribió rápido. La estructura estaba completa y las ideas eran claras. Cuando le dije que quería que sonara más profesional, añadió discusión técnica. Cuando le pedí respaldo académico, encontró artículos recientes.
El artículo se volvió más serio, pero empecé a dudar: ¿realmente necesitaba estar escrito así?
No había nada obviamente malo en el contenido. Pero lo que yo había querido escribir era un texto con mi propia voz, uno que dejara a los lectores ver cómo razonaba yo sobre un problema. Tras varias rondas de revisión, se estaba convirtiendo gradualmente en una revisión de investigación que yo mismo necesitaría tiempo para digerir.
Mis expectativas también fueron cambiando por el camino. Al principio, no tenía del todo claro qué debería significar «profesional» o «en profundidad» para este artículo en particular.
Esa experiencia me hizo repensar qué hace bueno a un agente.
Si revisaba los requisitos uno por uno, nuestra colaboración había logrado bastante: el artículo estaba escrito, la investigación estaba hecha y las referencias estaban en su lugar. Cada solicitud individual tenía un entregable correspondiente.
Pero al juntarlos, todavía tenía que preguntarme: ¿es este el artículo que quiero publicar?
Es fácil comprobar lo que un agente ha hecho. Explicar si esas acciones han acercado al usuario a su objetivo requiere más trabajo.
En este caso, «añadir respaldo académico» era una solicitud explícita. Su propósito era hacer el argumento más creíble. Si añadir investigación hacía que el artículo perdiera su voz original, necesitábamos reconsiderar cómo usar ese material.
Una nueva solicitud del usuario no siempre es algo que simplemente se añade encima. Puede ser una corrección de rumbo, o incluso un motivo para eliminar trabajo que ya se había completado.
Para un agente que permanece involucrado en una tarea, entender estos cambios afecta la calidad de toda la colaboración. Necesita revisar su comprensión de la tarea a medida que llega la retroalimentación, en lugar de añadir continuamente más al resultado.
Esto también hace más complicado el «hecho». El artículo puede tener un final, y la tarea puede estar marcada como completada, mientras el usuario todavía no tiene algo que pueda usar.
Así que antes de diseñar una evaluación, quiero aclarar algo más: ¿qué juicio estamos intentando hacer a partir de los resultados?
Comprobar la exactitud factual significa verificar citas y evidencia de respaldo. Evaluar la capacidad de revisión significa observar si el agente entiende la retroalimentación y preserva el contenido que todavía funciona. Juzgar si puede asumir una tarea de principio a fin también significa mirar cuánto trabajo le deja al usuario.
Estas preguntas están relacionadas, pero «la calidad general es buena» hace poco para responderlas todas.
Solo cuando tenemos claro qué estamos evaluando podemos saber qué evidencia recoger y cuánto puede decirnos una puntuación.
Una evaluación también debe ser justa con las condiciones del momento.
En este proceso de escritura, algunos objetivos solo se aclararon mediante la discusión. Las primeras respuestas deberían juzgarse según las necesidades que ya se habían expresado, en lugar de preferencias que surgieron después.
Si los requisitos ya estaban claros y el resultado seguía siendo inadecuado, necesitamos identificar el problema con más precisión. ¿Malinterpretó el agente? ¿Olvidó una restricción anterior? ¿O satisfacer una nueva solicitud deshizo algo que ya funcionaba?
Todo esto podría describirse como «mala escritura», pero exige mejoras muy diferentes. Proporcionar más información sobre la tarea, ajustar el contexto o cambiar el enfoque de ejecución pueden ayudar cada uno. Pero primero necesitamos saber dónde salió mal.
Otros requisitos no deberían cambiar con la preferencia personal. Si las citas son reales, si los hechos son exactos y si las conclusiones están respaldadas debe comprobarse de forma independiente. Que a un usuario le guste un resultado no basta para establecer que estos requisitos se han cumplido.
Creo que esta distinción importa. Permite que la evaluación tenga en cuenta necesidades específicas mientras conserva estándares de juicio necesarios.
Incluso cuando el objetivo está claro y el agente lo acierta esta vez, todavía hay más que observar.
¿Puede hacer bien la misma tarea una segunda vez? Si el usuario formula la solicitud de otra manera, ¿malinterpretará la intención? Cuando falta información, ¿puede reconocer la incertidumbre en lugar de llenar los huecos con prosa fluida?
Un estudio sobre la fiabilidad de los agentes examinó por separado la consistencia, la robustez, la previsibilidad y la seguridad. En los modelos y benchmarks que probó, las mejoras en capacidad solo aportaron mejoras limitadas en fiabilidad. Es un recordatorio de que, después de aprender qué puede lograr un agente, todavía necesitamos entender las condiciones bajo las cuales podemos confiar en él. Investigación relacionada
Entonces, ¿quién define qué es un buen agente?
Creo que el propósito real del usuario debería ser el punto de partida. Los equipos de producto necesitan tener claro qué necesidades pretenden atender y cuánta responsabilidad asumirán. La ingeniería necesita entender la implementación y los límites de las capacidades del sistema. La evaluación pone esas expectativas en situaciones concretas y comprueba si los resultados las confirman.
Alguien debe rendir cuentas por las compensaciones finales, y debe haber evidencia sobre la cual discutirlas.
Tomemos la solicitud de hacer algo «más profesional». Una persona piensa en terminología y referencias. Otra piensa en un razonamiento más riguroso. Alguien más espera que el autor señale el corazón del problema. Cuando aplicamos la solicitud a un artículo real, se vuelve más fácil ver que no todos estamos hablando de lo mismo.
Prefiero construir acuerdo mediante casos como estos. ¿Qué hechos deben ser correctos? ¿Qué partes afectan si el resultado es utilizable? ¿Dónde hay espacio para diferentes elecciones? Todo esto puede discutirse. Cuanto más específicos sean nuestros estándares, mejores serán nuestras posibilidades de explicar desacuerdos más adelante.
Esos estándares también deberían estar abiertos a revisión. Nuevas situaciones pueden exponer problemas que no habíamos considerado, y los usuarios pueden empezar a pedir cosas diferentes. Lo que importa es registrar por qué hicimos un ajuste, para que el equipo pueda distinguir una mejora en el producto de un cambio en cómo se juzga.
El valor de la evaluación también necesita mostrarse en las decisiones que tomamos después.
Si una evaluación nos deja más claros sobre qué priorizar, capaces de explicar por qué vale la pena invertir en una mejora y conscientes de qué pruebas adicionales necesitamos cuando la evidencia es insuficiente, entonces las puntuaciones tienen valor práctico.
En retrospectiva, la IA sí me ayudó a hacer el artículo más completo. Fueron las últimas rondas de discusión las que nos ayudaron a determinar qué conservar y qué podíamos eliminar.
Eso es también lo que espero que la evaluación pueda ayudar a hacer a un equipo: cuando un resultado ya parece bueno, todavía tener una forma de juzgar si está listo para ponerlo en manos de un usuario, y por qué podemos confiar en ese juicio.