Te contamos qué son los evals, los tests para saber si un prompt anda bien o si el cambio que le hiciste lo empeoró: cómo armarlos, cómo mejorar de a un cambio por vez y cómo evitar que la IA se copie en el examen. Las noticias: el escándalo de Nvidia, la caída de las acciones de IA y las mascotas de escritorio.
Rodri leyó un post del blog de Claude sobre cómo diseñar evals y mejorar con hill climbing y con Tincho lo usamos para explicar qué es un eval y cómo aprovecharlo.
Qué es un eval. Un test para medir qué tan bien funciona un modelo, un agente o un prompt. Para los tests de código cada lenguaje tiene su librería de siempre; para esto todavía no hay una que use todo el mundo.
Las partes. Un dataset de inputs, el resultado que esperás para cada uno, un grader que corrige la respuesta y un puntaje. El ejemplo de la charla es un prompt moderador: mide el enojo de un mensaje y avisa si tiene insultos o comentarios de política.
Dos formas de corregir. Con código, cuando la respuesta se puede chequear: si el mensaje tiene insultos, el prompt tiene que decir que sí. O con LLM as a judge, cuando no hay una única respuesta correcta: otro modelo lee la respuesta y la evalúa contra criterios escritos. Ahí también hay que revisar que el juez corrija bien.
Cómo se arman. En Claude Code, /claude-api build-eval te hace preguntas y arma los casos lo más parecidos posible a los reales: conversaciones, tickets de soporte o ejemplos que le pases. Te los muestra para que los apruebes y corre una primera vez para dejar un puntaje de base.
Para qué sirven. Como cualquier test, para saber si un cambio en el prompt rompió algo, y se pueden correr en CI. Con el puntaje de base además podés comparar: otro modelo, otro nivel de esfuerzo u otra temperatura.
Hill climbing. Es mejorar de a un cambio por vez usando ese puntaje. Con /claude-api hillclimb elegís el objetivo, que puede ser mejorar el puntaje o bajar el costo sin perder calidad. Claude lee los errores, propone un cambio, corre los evals y se lo queda solo si mejora. Sirve para prompts, skills, descripciones de tools, modelo y nivel de esfuerzo. A veces se mejora sacando cosas: un prompt más corto es más fácil de seguir.
El overfitting. Si optimizás contra un solo dataset, el prompt se puede volver muy bueno en esos casos y malo en los reales. Nos pasó: para arreglar una conversación mal clasificada, Claude agregó al prompt ese caso exacto en vez de una regla general. La solución es partir los casos en dos, train y test, y que el agente que optimiza nunca vea los de test. Es como un examen: si te dan las preguntas antes, te las aprendés de memoria. Si un cambio mejora train y no mejora test, se descarta.
Datos reales. Los casos sacados de producción sirven más que los inventados, siempre que la confidencialidad lo permita.
Sin llegar a un eval. Para probar una skill propia le pedimos a Claude que corra un agente con la skill y otro sin, y que compare cuál lo hizo mejor o con menos idas y vueltas.
Music track: Monday Routine by Aventure
Source: freetouse.com/music
No Copyright Vlog Music for Video