Diseño
Paso uno - Diseño del agente
Iniciemos por el inicio
Es algo obvio: no puedo iniciar por el final —o bueno, sí podría, pero aquí no hacemos eso—. Entonces, lo principal es diseñar los componentes necesarios y sus interacciones. Todavía tengo muchas incógnitas respecto al uso de IA en productos, no porque dude de su capacidad; más bien, dudo de su incertidumbre. Me refiero a que toda la vida en programación hemos buscado que, mediante una secuencia de pasos, siempre lleguemos a un mismo resultado, y siento que la inclusión de agentes en determinados procesos lo único que hacen es agregar una capa de incertidumbre que no aporta y, por el contrario, complejiza de manera innecesaria al agregar indeterminismo. Es por esto que, al menos en un inicio, trato de delegar al agente únicamente los procesos en los que yo tendría que intervenir para hacer evaluaciones repetitivas y que no tenga un impacto “mayor”.
Partiendo de esa premisa, la arquitectura del proyecto debería tener la mayor cantidad de procesos deterministas posibles.
Planeación
Creo que para este proyecto es bueno empezar con algo “sencillo”, pero con responsabilidades claramente definidas. Y si la premisa es tener la mayor cantidad posible de procesos deterministas, lo más natural es separar lo que puede resolver el código de lo que de verdad necesita criterio.
Así que el sistema quedó dividido en dos componentes:
- El buscador, un componente “tonto” (y lo digo con cariño). Su única tarea es buscar ofertas de trabajo y guardarlas. No evalúa, no opina y no sabe nada de mi perfil: busca (conoce las preferencias de búsqueda), descarta lo que ya ha visto y anota lo nuevo. No usa IA en absoluto.
- El evaluador, el componente que sí piensa. Toma las ofertas que encontró el buscador, las compara con mi perfil y decide cuáles vale la pena mostrarme. Aquí, y solo aquí, vive el LLM.
¿Y cómo se hablan entre ellos? De la forma más simple que se me ocurrió: comparten la información escribiendo en una base de datos. El buscador guarda cada oferta nueva y, cuando termina, le avisa al evaluador mediante un webhook, algo así como un “oye, hay cosas nuevas, échales un ojo”. El evaluador lee lo pendiente, lo evalúa y escribe el resultado en esa misma base de datos.
Lo que me gusta de este diseño es que cada parte puede fallar, cambiar o crecer sin arrastrar a la otra. Si mañana quiero buscar en otro sitio, solo toco el buscador; si quiero cambiar de modelo o ajustar cómo se evalúa, solo toco el evaluador. Y la incertidumbre que trae el LLM queda encerrada en un único lugar.
Alternativas descartadas
Este diseño no fue el primero en el que pensé, así que te comparto cuáles fueron un par de opciones que consideré y las razones por las que las descarté.
IA total
La primera versión que contemplé fue un único agente que lo hacía todo. Buscaba las ofertas, las leía, decidía cuáles me servían, ajustaba mi hoja de vida y me avisaba.
¿Por qué lo descarté? Funcionaba, sí, pero:
- La búsqueda es algo que puede hacer un proceso determinista. Sobresimplificando, un llamado a un API externo con parámetros de búsqueda.
- Puede que el consumo de tokens por búsqueda sea elevado, debido a que el agente debe razonar que debe usar la herramienta para búsqueda de ofertas. Esto, en todas las corridas, me parece un gasto innecesario.
Dos responsabilidades acopladas
La otra opción que consideré fue separar la búsqueda de la evaluación y que el buscador le pasara las ofertas directamente al evaluador, sin una base de datos de por medio.
¿Por qué lo descarté? Más simple, en teoría, pero con un problema:
- Si el evaluador está caído o falla a mitad de camino, esas ofertas se pierden.
Lo que cuesta este diseño
Ningún diseño es gratis, y este no es la excepción.
Para empezar, ahora son dos piezas que desplegar, configurar y mantener, en lugar de una. Si algo deja de funcionar, toca revisar dos lugares.
Además, debo definir un contrato que ambos componentes tienen que entender para que sepan ponerse de acuerdo en cómo se ve una oferta guardada. Si el buscador cambia el formato, debo cambiar el contrato en ambos componentes.
Por último, el webhook es solo un aviso. Si el evaluador no está disponible o falla en medio del proceso, las ofertas simplemente quedan pendientes hasta el siguiente aviso (una solución “rápida” es implementar una notificación en estos casos).
Siendo honestos, para un proyecto personal me parece un precio razonable.