Cómo convertirse en un ingeniero de IA aplicada

Escribí esta guía como la que me hubiera gustado tener antes de hacer la transición a la Ingeniería de IA Aplicada.

El rol se superpone en gran medida con la ingeniería de software tradicional, pero agrega algunos conceptos importantes que la mayoría de los ingenieros de software tienen que aprender al hacer la transición. Sugiero que uses esto como un esquema de los temas centrales que necesitas entender, y luego sigas los recursos enlazados a lo largo del artículo cuando quieras profundizar.

Al final, deberías tener una comprensión mucho más clara de qué es la Ingeniería de IA Aplicada, qué requiere realmente el trabajo y cómo se extiende más allá de la ingeniería de software tradicional.

Si te interesa trabajar en algunos de los problemas más interesantes de la IA Aplicada con un equipo de ingeniería muy talentoso, siempre estamos contratando. Aplica en nuestro sitio web en varickagents.com o recomienda a un candidato para obtener un bono de recomendación de $20,000 USD.

Dicho esto, la mejor manera de entender la Ingeniería de IA Aplicada es comenzar con el cambio en cómo piensas sobre la construcción de software.

Ingeniería de software vs. Ingeniería de IA

La mayor diferencia entre ser un ingeniero de software y un ingeniero de IA es que la ingeniería de software tradicional te entrena para pensar de manera determinista, mientras que la IA aplicada te obliga a pensar de manera probabilística.

En el software normal, escribes la lógica, la haces funcionar y, cuando algo se rompe, generalmente puedes rastrearlo: una entrada estructurada te da deterministamente una salida estructurada.

La IA aplicada no funciona así. Estás construyendo alrededor de una llamada API no determinista a la inteligencia, lo que significa que la misma entrada puede devolverse diferente cada vez. Debido a esto, el trabajo deja de ser solo construir el software y se convierte en medir si el sistema realmente se comporta como debería.

La forma en que hacemos eso es a través de evaluaciones, así que explicaré cómo construir un conjunto de evaluaciones que asegure que el agente que desarrollas no esté cometiendo errores. He llegado a aprender que esta es una de las habilidades más importantes de un desarrollador de IA aplicada, dada la naturaleza no determinista del trabajo que hacemos.

La siguiente parte del artículo cubre el desarrollo de cada parte de un agente de IA (excepto el modelo en sí, por supuesto), porque puedes llamar a una API para un modelo, pero necesitas construir todo lo demás tú mismo. Esto se llama ingeniería de arnés.

Y por último, cubriré cómo pasar de un agente en producción a múltiples agentes, y por qué es un problema de sistemas distribuidos. Si puedes llegar al final de este artículo, no hay razón para que no puedas hacer la transición para convertirte en un ingeniero de IA Aplicada.

Evaluaciones

Un ingeniero de IA aplicada convierte la incertidumbre en confianza medida utilizando evaluaciones. En el desarrollo de software tradicional, confías en el sistema porque escribiste la lógica y probaste el código. En la IA aplicada, no puedes confiar en el sistema de esa manera porque el modelo puede comportarse de manera diferente en diferentes ejecuciones. Por lo tanto, el ingeniero de IA tiene que construir una capa de medición alrededor del agente.

Una evaluación es el proceso de darle una tarea a un agente, dejarlo ejecutar y calificar lo que hizo. El objetivo es demostrar dos cosas: que el agente completó el trabajo correctamente y que el agente se mantuvo dentro de los límites que se le dieron.

El primer paso es calificar el resultado. Este es el paso más fácil del proceso de evaluación. Para un agente de facturas, en los que suelo trabajar, eso significa asegurarse de que la factura llegue al lugar correcto, o que el duplicado sea marcado. Simplemente estás comparando el resultado final con lo que debería haber sucedido.

El segundo paso es calificar la trayectoria. Este es el camino que tomó el agente para llegar a ese resultado: las herramientas que llamó, los campos que tocó, los argumentos que pasó y las acciones que intentó en el camino. Esto es importante porque un agente puede llegar a la respuesta final correcta mientras aún hace algo peligroso en el proceso. Puede clasificar una factura correctamente mientras también cambia los datos bancarios o envía un pago antes de la aprobación.

La trayectoria en sí misma es solo un registro: una lista ordenada de cada herramienta que el agente llamó y los argumentos que pasó. Calificarla solo significa escribir verificaciones contra ese registro.

Algunas verificaciones son deterministas: asegurarse de que send_payment nunca aparezca antes de una llamada de aprobación, verificar que los únicos campos escritos fueron aquellos que el agente tenía permitido escribir. Otras son decisiones de juicio: si una escalación fue apropiada, si el razonamiento justificó la acción. Esas van a un segundo modelo con una rúbrica.

El principio general a seguir es que las verificaciones deterministas generalmente detectan las violaciones de seguridad, mientras que el modelo juez califica la calidad.

El resultado son dos calificaciones por caso de prueba: si el agente obtuvo la respuesta correcta y si se comportó correctamente al llegar allí. Estas deben informarse por separado, porque un agente que clasifica facturas correctamente el 95% del tiempo pero toca un campo prohibido en el 4% de las ejecuciones se ve muy bien en una puntuación combinada, pero causa grandes complicaciones comerciales en producción.

Este artículo sirve como una introducción a las evaluaciones y todos los demás temas cubiertos, por lo que he enlazado otros recursos para ayudarte a profundizar. Algunos que me ayudaron a entender cómo construir evaluaciones efectivas son:

• El curso de evaluaciones de Anthropic
• La guía completa de evaluaciones de Lenny
• Las preguntas frecuentes sobre evaluaciones de Hamel

Recomendaría revisar cada uno, pero comenzando con los de Lenny y Hamel antes de pasar al curso de evaluaciones (que es un poco más práctico).

Pero una evaluación aún necesita un agente para probar, y todo lo que rodea al modelo tiene que ser construido por ti. Ese sistema circundante se llama arnés. La siguiente sección cubre cómo pensar en cada parte del proceso de ingeniería de arnés, desde la llamada a herramientas hasta la optimización de la ventana de contexto.

Ingeniería de Arnés

Un modelo por sí solo no es un agente. Un modelo puede razonar, clasificar, escribir y decidir, pero no puede operar dentro de una empresa por sí mismo. Puede decir qué acción debería ocurrir, pero no puede tomar esa acción de manera segura a menos que construyas el sistema a su alrededor, y ese sistema es el arnés.

El arnés es todo lo que rodea al modelo que convierte una llamada API en un agente funcional: las herramientas que puede usar, el contexto que ve, el estado que recuerda, las barreras de seguridad que lo limitan y el bucle que le permite seguir trabajando hasta que la tarea esté completa.

La primera parte del arnés es la ejecución de herramientas.

Los modelos solo leen y escriben texto, por lo que cuando un modelo decide hacer algo, en realidad no lo ejecuta. Emite una solicitud estructurada (una cadena JSON) para actualizar un registro, enviar un correo electrónico o buscar en una base de datos.

El arnés recibe esa solicitud, la valida, ejecuta la operación real y envía el resultado de vuelta al modelo como texto.

La segunda parte es la gestión del contexto. Cada instrucción, menú de herramientas, resultado de herramienta y mensaje anterior ocupa espacio en la ventana de contexto del modelo. El arnés tiene que decidir qué necesita ver el modelo en este momento, qué debe resumirse y qué debe eliminarse. Sin esto, los agentes se pierden en un historial irrelevante.

Escribiré un artículo más completo que profundice en cada parte del proceso de desarrollo del arnés, pero por ahora, recomendaría escuchar esta charla de un ingeniero de Arize, la plataforma de aprendizaje continuo para agentes, que profundiza en su proceso de pensamiento sobre la gestión del contexto.

Para aprender más sobre cómo aplicar una gestión de contexto efectiva a tus agentes en la práctica, lee estos blogs:

• El artículo de OpenAI sobre gestión de contexto
• Una guía práctica para la gestión de contexto
• La guía de ingeniería de contexto de Anthropic

La tercera parte de la ingeniería de arnés es el estado y la memoria. Los modelos no tienen estado entre llamadas, por lo que cualquier cosa que el agente necesite recordar tiene que vivir fuera del modelo (generalmente en una base de datos, almacén de archivos o registro de tareas). El contexto es lo que el modelo está viendo en este momento. El estado es todo lo que el agente sabe pero que no está viendo actualmente.

La cuarta parte son las barreras de seguridad. Dado que el modelo puede solicitar la acción incorrecta con la misma confianza que la correcta, el arnés tiene que verificar permisos, validar entradas, bloquear acciones inseguras y dirigir los pasos de alto riesgo a los humanos.

Finalmente, todo esto se une en el bucle del agente: construir el contexto, llamar al modelo, inspeccionar su respuesta, ejecutar la herramienta si está permitido, almacenar el resultado, actualizar el contexto y repetir hasta que la tarea esté completa.

La ingeniería de arnés es la mayor parte de lo que harás como ingeniero de IA Aplicada, así que tómate tu tiempo con esta sección. Como ingeniero de IA aplicada, todo tu trabajo es construir el entorno operativo que permita que un sistema probabilístico funcione dentro de un software determinista.

Pero la producción generalmente no se detiene en un solo agente.

A medida que el flujo de trabajo se vuelve más grande, el instinto natural es dividir el trabajo. Pero una vez que agregas ese segundo agente, el diseño del sistema cambia.

Con un agente, la mayor parte de la complejidad vive dentro de un solo bucle. Con múltiples agentes, ahora tienes varios bucles actuando sobre el mismo entorno. Cada agente puede leer el estado que otro agente acaba de cambiar, escribir en la memoria de la que depende otro agente, o llamar a una herramienta cuyo resultado afecta a todo el flujo de trabajo.

En ese punto, la parte difícil ya no es solo la ingeniería de prompts, las evaluaciones o el diseño del arnés. Se convierte en un problema de sistemas distribuidos: quién es dueño de qué estado, quién puede escribir en la memoria, qué herramientas son seguras de reintentar y qué sucede cuando dos agentes razonables toman acciones en el orden incorrecto.

Los Despliegues Multi-Agente son un Problema de Sistemas Distribuidos

Cuando el primer agente funciona y el flujo de trabajo se vuelve más grande, un nuevo ingeniero de IA aplicada tiene naturalmente el instinto de dividir el trabajo en roles: un agente investiga, uno planifica, uno ejecuta, uno revisa.

Pero el segundo agente cambia la unidad de diseño del agente al sistema. Varios bucles ahora actúan en el mismo entorno: un agente puede actualizar el estado del cliente mientras otro está en medio de la planificación escribiendo contra el estado desactualizado. Ambos tomaron decisiones razonables, pero el sistema permitió que esas decisiones interactuaran en el orden incorrecto.

Este es un problema de sistemas distribuidos. La buena noticia es que los ingenieros de sistemas distribuidos resolvieron estas fallas hace décadas. Tu trabajo es aplicarlas a bucles que, por casualidad, contienen un LLM. A continuación, se muestra una lista de soluciones de sistemas distribuidos que se aplican a la ingeniería de IA:

Principio de escritor único. Cada pieza importante de estado tiene exactamente un agente que puede escribir en ella; otros agentes la leen o envían solicitudes de cambio. Aplica esto a nivel de herramienta: si el agente de ejecución es el único que puede escribir en el CRM, el agente de investigación no puede corromper el CRM, sin importar qué tan mal razone.

Claves de idempotencia. Los agentes reintentan las llamadas a herramientas cuando algo falla o se agota el tiempo, pero los reintentos pueden ser peligrosos cuando la herramienta cambia algo en el mundo real. No quieres que un agente envíe el mismo pago dos veces solo porque la primera solicitud pareció fallar. La solución es adjuntar una clave única a cada llamada de herramienta mutante, es decir, cualquier acción que cambie datos en un sistema externo. Si la herramienta ve la misma clave nuevamente, debe devolver el resultado original en lugar de ejecutar la acción por segunda vez. La API de Stripe funciona de esta manera, y se traslada al desarrollo de agentes cuando se trata de pagos, correos electrónicos, etc.

Precondiciones en las escrituras. Los agentes a menudo actúan basándose en una visión antigua del mundo. Puede que algo haya cambiado entre el momento en que el agente hizo su plan y el momento en que intenta actualizar un sistema externo. Para evitar escrituras obsoletas, las herramientas mutantes deben requerir una condición antes de realizar el cambio. Por ejemplo: "establecer el estado en Aprobado solo si aún está Pendiente". Si el estado ya ha cambiado, la herramienta debe fallar claramente en lugar de sobrescribir silenciosamente el estado más nuevo.

Transferencias explícitas. Pasa el trabajo como mensajes con un esquema definido, secuenciados por un orquestador. Un agente debe recibir su tarea, no descubrirla.

Resumen

Este artículo sirve como una visión general de los temas más importantes que he aprendido como ingeniero de IA Aplicada: evaluaciones, ingeniería de arnés y diseño de sistemas multi-agente.

Si te llevas algo, que sea esto: el modelo proporciona la inteligencia, pero todo lo que lo hace confiable (la capa de medición, el entorno operativo, las reglas de coordinación) es diseñado por ti. Comprende estos conceptos y la transición desde la ingeniería de software se convierte en una extensión de las habilidades que ya tienes.

Si te interesa este tipo de trabajo y quieres venir a abordar algunos de los problemas más interesantes de la IA Aplicada con un equipo de ingeniería muy talentoso, siempre estamos contratando. Aplica en nuestro sitio web en varickagents.com , y podrías comenzar lo antes posible. Por otro lado, si recomiendas a un candidato exitoso, te daremos un bono de recomendación de $20,000 USD.