Mira bastante igual que antes. Como ingeniero de software en el espacio de IA, mi trabajo ha sido un híbrido de ingeniería de software, ingeniería de IA, intuición de productos y dosis de empatía de los usuarios.
Con tanto en marcha, quería dar un paso atrás y reflexionar sobre el panorama general, y el tipo de habilidades y los ingenieros de modelos mentales deben mantenerse a la vanguardia. Una lectura reciente de la ingeniería de IA de O’Reilly me dio el empuje para que también quería sumergirme en cómo pensar en Evals, un componente central en cualquier sistema de IA.
Una cosa se destacó: la ingeniería de IA a menudo es más software que la IA.
Fuera de los laboratorios de investigación como OpenAi o Anthrope, la mayoría de nosotros somos modelos de entrenamiento desde cero. El verdadero trabajo se trata de resolver problemas comerciales con las herramientas que ya tenemos: dar modelos con un contexto relevante suficiente, usar API, construir tuberías de trapo, llamas de herramientas, todo además de las preocupaciones de SWE habituales como la implementación, el monitoreo y la escala.
En otras palabras, la ingeniería de IA no está reemplazando la ingeniería de software: está capas de una nueva complejidad además de ella.
Esta pieza es yo desencadenando algunos de esos temas. Si alguno de ellos resuena, me encantaría escuchar sus pensamientos, ¡no dude en comunicarse aquí!
Las tres capas de una pila de aplicaciones de IA
Piense en una aplicación de IA como construida en tres capas: 1) Desarrollo de aplicaciones 2) Desarrollo del modelo 3) Infraestructura.
La mayoría de los equipos comienzan desde la cima. Con modelos poderosos disponibles en el estante, a menudo tiene sentido comenzar enfocándose en construir el producto y solo más tarde sumergirse en el desarrollo del modelo o la infraestructura según sea necesario.
Como dice O’Reilly, “la ingeniería de IA es solo ingeniería de software con modelos de IA arrojados a la pila”.
Por qué las evals importan y por qué son difíciles
En el software, uno de los mayores dolores de cabeza para equipos de rápido movimiento son las regresiones. Envías una nueva característica, y en el proceso, sin saberlo, rompes algo más. Semanas después, un insecto aparece en un rincón polvoriento de la base de código, y trazarlo hacia atrás se convierte en una pesadilla.
Tener una suite de prueba integral ayuda a atrapar estas regresiones.
El desarrollo de IA enfrenta un problema similar. Todos los cambios, ya se trata de ajustes rápidos, actualizaciones de tuberías de trapo, ajuste o ingeniería de contexto, pueden mejorar el rendimiento en un área mientras degradan en silencio otro.
En muchos sentidos, las evaluaciones son para AI qué pruebas son para el software: atrapan regresiones temprano y brindan a los ingenieros la confianza para moverse rápidamente sin romper las cosas.
Pero evaluar la IA no es sencilla. En primer lugar, los modelos más inteligentes se vuelven, se obtiene una evaluación más dura. Es fácil saber si un resumen del libro es malo si es Gibberish, pero mucho más difícil si el resumen es realmente coherente. o Sepa si realmente está capturando los puntos clave, no solo sonando fluido o de hecho correcto, es posible que tenga que leer el libro usted mismo.
En segundo lugar, las tareas a menudo son abiertas. Raramente hay una sola respuesta “correcta” e imposible curar una lista completa de salidas correctas.
En tercer lugar, los modelos de base se tratan como cajas negras, donde los detalles de la arquitectura del modelo, los datos de capacitación y el proceso de capacitación a menudo se analizan o incluso se hacen públicos. Estos detalles revelan mucho sobre las fortalezas y debilidades de un modelo y sin él, las personas solo evalúan modelos basados en observar sus salidas.
Cómo pensar en Evals
Me gusta agrupar evals en dos reinos amplios: cuantitativa y cualitativa.
Las evals cuantitativas tienen respuestas claras e inequívocas. ¿El problema matemático se resolvió correctamente? ¿Se ejecutó el código sin errores? Estos a menudo se pueden probar automáticamente, lo que los hace escalables.
Las evals cualitativas, por otro lado, viven en las áreas grises. Se tratan de interpretación y juicio, como calificar un ensayo, evaluar el tono de un chatbot o decidir si un resumen “suena bien”.
La mayoría de las evals son una mezcla de ambos. Por ejemplo, evaluar un sitio web generado significa no solo probar si realiza sus funciones previstas (cuantitativas: puede un usuario registrarse, iniciar sesión, etc.), sino también juzgar si la experiencia del usuario se siente intuitiva (cualitativa).
Corrección funcional
En el corazón de las evals cuantitativas está la corrección funcional: ¿la salida del modelo realmente hace lo que se supone que debe hacer?
Si le pide a un modelo que genere un sitio web, la pregunta principal es si el sitio cumple con sus requisitos. ¿Puede un usuario completar las acciones clave? ¿Funciona de manera confiable? Esto se parece mucho a las pruebas de software tradicionales, donde ejecuta un producto con un conjunto de casos de prueba para verificar el comportamiento. A menudo, esto puede ser automatizado.
Similitud contra datos de referencia
No todas las tareas tienen salidas tan claras y comprobables. La traducción es un buen ejemplo: no hay una única traducción al inglés “correcta” para una oración francesa, pero puede comparar salidas con datos de referencia.
La desventaja: esto se basa en gran medida en la disponibilidad de conjuntos de datos de referencia, que son caros y requieren mucho tiempo para crear. Los datos generados por humanos se consideran el estándar de oro, pero cada vez más, los datos de referencia están siendo arrancados por otros AIS.
Hay algunas formas de medir la similitud:
Matricidad exacta del juicio humano: si la respuesta generada coincide con una de las respuestas de referencia exactamente. Estos producen resultados booleanos. Similitud léxica: medir cuán similares se ven las salidas (por ejemplo, superposición en palabras o frases). Similitud semántica: medir si las salidas significan lo mismo, incluso si la redacción es diferente. Esto generalmente implica convertir los datos en insertos (vectores numéricos) y compararlos. Los incrustaciones no son solo para texto: plataformas como Pinterest los usan para imágenes, consultas e incluso perfiles de usuario.
La similitud léxica solo verifica la semejanza a nivel de la superficie, mientras que la similitud semántica profundiza en el significado.
Ai como juez
Algunas tareas son casi imposibles de evaluar limpiamente con reglas o datos de referencia. Evaluar el tono de un chatbot, juzgar la coherencia de un resumen o criticar la persuasión de la copia AD se divide en esta categoría. Los humanos pueden hacerlo, pero las evals humanas no se escalan.
Aquí le mostramos cómo estructurar el proceso:
Definir un criterio de evaluación estructurado y medible. Sea explícito sobre lo que le importa: claridad, ayuda, precisión objetiva, tono, etc. Los criterios pueden usar una escala (1–5 calificación) o verificaciones binarias (pasar/fallar). La entrada original, la salida generada y cualquier contexto de apoyo se dan al juez de IA. El juez devuelve un puntaje, etiqueta o incluso una explicación para la evaluación. Agregado sobre muchas salidas. Al ejecutar este proceso en grandes conjuntos de datos, puede descubrir patrones, por ejemplo, notar que la ayuda cayó un 10% después de una actualización del modelo.
Debido a que esto se puede automatizar, permite una evaluación continua, tomando prestados de las prácticas de CI/CD en ingeniería de software. Las evals se pueden ejecutar antes y después de los cambios de la tubería (desde los ajustes rápidos hasta las actualizaciones del modelo), o utilizarse para el monitoreo continuo para atrapar la deriva y las regresiones.
Por supuesto, los jueces de IA no son perfectos. Así como no confiaría completamente en la opinión de una sola persona, tampoco debe confiar plenamente en la de un modelo. Pero con un diseño cuidadoso, múltiples modelos de juez o ejecutándolos en muchas salidas, pueden proporcionar aproximaciones escalables de juicio humano.
Desarrollo impulsado por evaluación
O’Reilly habló sobre el concepto de desarrollo impulsado por evaluación, inspirado en el desarrollo impulsado por las pruebas en ingeniería de software, algo que sentí que vale la pena compartir.
La idea es simple: defina sus evals antes de construir.
En la ingeniería de IA, esto significa decidir cómo se ve el “éxito” y cómo se medirá.
El impacto aún es más importante, no exagerado. Las Evals correctas aseguran que las aplicaciones de IA demuestren valor de manera relevante para los usuarios y el negocio.
Al definir Evals, aquí hay algunas consideraciones clave:
Conocimiento del dominio
Existen puntos de referencia públicos en muchos dominios (depuración de códigos, conocimiento legal, uso de herramientas, pero a menudo son genéricos. Las evals más significativas generalmente provienen de sentarse con las partes interesadas y definir lo que realmente importa para el negocio, luego traducirlo en resultados medibles.
La corrección no es suficiente si la solución no es práctica. Por ejemplo, un modelo de texto a SQL podría generar una consulta correcta, pero si tarda 10 minutos en funcionar o consume grandes recursos, no es útil a escala. El tiempo de ejecución y el uso de la memoria también son métricas importantes.
Capacidad de generación
Para tareas generativas, ya sea texto, imagen o audio, las evals pueden incluir fluidez, coherencia y métricas específicas de tareas como la relevancia.
Un resumen puede ser factualmente preciso, pero perder los puntos más importantes: una evaluación debería capturar eso. Cada vez más, estas cualidades pueden ser calificadas por otra IA.
Consistencia objetiva
Las salidas deben verificarse con una fuente de verdad. Esto puede suceder de dos maneras:
Consistencia local
Esto significa verificar las salidas en un contexto proporcionado. Esto es especialmente útil para dominios específicos que son exclusivos de sí mismos y tienen un alcance limitado. Por ejemplo, las ideas extraídas deben ser consistentes con los datos. Consistencia global
Esto significa verificar los resultados contra fuentes de conocimiento abiertos, como verificar los hechos a través de una búsqueda web o una investigación de mercado, etc. Auto verificación
Esto sucede cuando un modelo genera múltiples salidas y mide cuán consistentes son estas respuestas entre sí.
Seguridad
Más allá del concepto habitual de seguridad, como no incluir blasfemias y contenido explícito, en realidad hay muchas formas en que se puede definir la seguridad. Por ejemplo, los chatbots no deben revelar datos confidenciales del cliente y deberían poder protegerse contra ataques de inyección inmediatos.
Para resumir
A medida que crecen las capacidades de IA, las evals robustas solo se volverán más importantes. Son las barandillas que permiten a los ingenieros moverse rápidamente sin sacrificar la confiabilidad.
He visto cuán desafiante puede ser la confiabilidad y cuán costosas son las regresiones. Damilan la reputación de una empresa, frustran a los usuarios y crean experiencias de desarrollo dolorosas, con ingenieros atrapados persiguiendo los mismos errores una y otra vez.
A medida que se difuminan los límites entre los roles de ingeniería, especialmente en equipos más pequeños, nos enfrentamos a un cambio fundamental en la forma en que pensamos sobre la calidad del software. La necesidad de mantener y medir la confiabilidad ahora se extiende más allá de los sistemas basados en reglas a aquellos que son inherentemente probabilísticos y estocásticos.