Notebooks de Ingeniería IA gratuitos: RAG y agentes en Colab

En pocas palabras: AI Engineer Notebooks es un repositorio gratuito de calmrocks con 12 notebooks de Colab framework-free: escribís vos el RAG, los agentes y las evals. Corre entero sobre la API de Groq sin tarjeta de crédito, del prompting al serving con vLLM.

AI Engineer Notebooks es un repositorio gratuito de notebooks de Colab creado por el usuario calmrocks que enseña a construir RAG, agentes y evaluaciones sin frameworks, corriendo sobre la API de Groq sin tarjeta de crédito. Son 12 secciones que van del prompting al serving con vLLM, pensadas para pasar de backend a rol de AI Engineer. Estos Notebooks de Ingeniería IA gratuitos se ejecutan de arriba a abajo, cada uno con sus propios ejercicios.

Los Notebooks de Ingeniería IA gratuitos son una colección de cuadernos de Google Colab que enseñan a construir sistemas sobre modelos de fundación (APIs de modelos, RAG, evaluaciones, agentes, adaptación y serving) usando APIs crudas en vez de librerías. El repo es de calmrocks y acompaña a un plan de transición a AI Engineer. Todo se ejecuta sobre la API gratuita de Groq, sin costo ni credenciales de pago.

¿Por qué estos notebooks van sin frameworks a propósito?

La idea central es escribir el agente, el RAG y las evals con llamadas crudas a la API antes de agarrar LangChain o LlamaIndex. La frase del repo lo resume: “los patrones son durables, los wrappers cambian”. Aprendés qué hacen esas librerías por debajo, y después decidís con criterio cuándo te conviene usarlas.

Hay una decisión práctica atrás de esto. Si arrancás con un framework, cuando algo se rompe en producción no sabés si el problema es tu prompt, tu retrieval o una capa de abstracción que ni ves. Con las llamadas crudas, el error tiene una sola cara.

Cada notebook es autocontenido. La primera celda instala las dependencias, la segunda llama a from aien import setup; client, MODEL = setup() para cargar tu API key desde los secrets de Colab. Sin estado escondido entre cuadernos. aien es el paquetito compartido del repo: un solo lugar donde se toca la carga de credenciales. En mejores prácticas de seguridad empresarial profundizamos sobre esto.

Todo es OpenAI-compatible, así que cada patrón se transfiere directo a OpenAI y, con cambios chicos, a Anthropic. La costura es intercambiable, la habilidad no.

¿Cómo funciona RAG en 15 líneas de código dentro de Colab?

RAG (Retrieval Augmented Generation) es el bucle recuperar → aumentar → generar: buscás fragmentos relevantes en tu corpus, los metés en el prompt y el modelo responde con esos datos a la vista. La sección 03 del repo lo muestra con un demo funcional de 15 líneas, antes de complicar nada.

Acá viene un error clásico que el notebook aclara temprano: RAG no es lo mismo que embeddings. Los embeddings son una pieza del retrieval, no el sistema entero. Ponele que armás la parte de embeddings, ves que “anda” y asumís que tenés RAG. Te falta la mitad.

El repo desarrolla el tema en capas, y el orden importa:

• Embeddings y retrieval primero: elección del embedding, búsqueda vectorial y las trampas de la similitud. Hacé que el retrieval funcione antes que nada.
• Búsqueda híbrida: keyword más vector, y rerankers, con la pregunta de cuándo cada uno se gana su costo.
• Chunking al final: estrategias de troceo sobre un corpus real y desprolijo, revisadas último, una vez que ya sabés juzgarlas contra el retrieval.
• Diagnóstico de respuestas malas: el cuello de botella casi siempre es la calidad del retrieval, no la generación.

Ese último punto es el que más plata ahorra. Cuando el modelo alucina, la reacción típica es tocar el prompt de generación. El notebook te empuja a mirar primero qué fragmentos recuperaste, porque ahí suele estar el problema.

¿Cómo se arma un bucle de agente sin LangChain ni LlamaIndex?

Un bucle de agente es un ciclo donde el modelo decide qué herramienta llamar, ejecuta, lee el resultado y vuelve a decidir, hasta una condición de corte. En la sección 05 lo escribís desde cero con API cruda: nada de framework. Diseñás las herramientas de forma que el modelo las pueda usar bien, y ponés presupuestos de costo y latencia. Te puede servir nuestra cobertura de cómo usar ChatGPT en tus notebooks.

La pregunta interesante que plantea el notebook no es “cómo hago un agente”, sino cuándo NO hacerlo. ¿Cuándo un pipeline lineal le gana a un agente autónomo? Cuando los pasos ya los conocés. Ahí meter un agente es agregar no-determinismo y tokens de más sin necesidad.

Después llega la parte conceptual: MCP (Model Context Protocol), que estandariza cómo el agente habla con las herramientas, y las Skills, el patrón de “revelación progresiva” para cargar know-how a demanda sin inflar el contexto. El repo trata Tools, MCP y Skills como una sola historia, lo cual se agradece porque en la mayoría de los tutoriales aparecen sueltos.

¿Por qué las evaluaciones propias importan más que los benchmarks públicos?

Porque un benchmark público no te dice si tu sistema anda con TUS datos y TUS usuarios. El repo instala temprano el hábito de “medir antes de tunear” y lo repite en cada sección. Las evals son la columna vertebral: sin un golden set propio, no sabés si un cambio de prompt mejoró o empeoró las cosas.

La sección 02 arranca con golden sets y métricas sobre la tarea de la sección 01. La sección 04 lo lleva al RAG: construís un golden set para tu sistema de retrieval, usás LLM-as-judge (con sus propias fallas, que el notebook no esconde) y medís el acuerdo con humanos.

El salto conceptual clave: evals como CI. Las corrés en cada cambio de prompt o modelo para cachar regresiones de calidad antes de que lleguen a producción. Y para no quedarte en “corrí una eval”, la sección 08 mete MLflow de punta a punta: logueás runs, params y métricas del harness de la sección 04, registrás y versionás un modelo, y lo promovés por etapas. Eso convierte una prueba suelta en un flujo reproducible. Para más detalles técnicos, mirá elegir el modelo de lenguaje ideal.

¿Cuándo conviene Groq gratis y cuándo saltar a un modelo comercial o LoRA?

Groq alcanza para aprender el stack entero gratis y sin tarjeta. El límite aparece en dos temas que Groq no puede hostear: el fine-tuning con LoRA (sección 06) y el serving self-hosted (sección 09). Para esos, el notebook enseña el concepto primero y deja un apéndice opcional con GPU de Colab.

La discusión de la sección 06 es la que se da en cualquier reunión de equipo: ¿cambiás los pesos del modelo o cambiás sus inputs? La comparación entre fine-tuning y RAG es un buen complemento para entender cuándo cada enfoque paga. Acá va la síntesis:

Enfoque	Qué toca	Cuándo conviene	Costo relativo
Prompting	Solo el input	Casi siempre el primer intento; la palanca más barata	Mínimo
RAG	El contexto que ve el modelo	Necesitás datos frescos, propios o que cambian seguido	Medio
LoRA / QLoRA	Un subconjunto de pesos	Formato o estilo muy específico que el prompt no logra fijar	Alto (requiere GPU)

La sección 09 es la que más se aleja del “hola mundo”: el stack de serving real entre el que un AI Engineer elige, vLLM, TGI, Triton y TensorRT-LLM, con qué optimiza cada uno y las cuentas de servilleta para dimensionar un deploy (QPS, VRAM, latencia, réplicas). Si tu proyecto crece y necesitás alojar ese servicio de inferencia o el frontend en Argentina, podés mirar donweb.com para la parte de hosting e infraestructura.

Caso real: el asistente de soporte que salvaron las evals

El caso de estudio A del repo toma un pedido vago de cliente y lo lleva a un asistente de soporte RAG más agente, desplegado y evaluado. Después viene la parte jugosa: una regresión de calidad en vivo. ¿La causa? Un índice vectorial quedó viejo tras una migración de corpus. Las evals lo detectaron, y el ejercicio es diagnosticarlo y arreglarlo.

Es el arco completo, de armar a debuggear, que atraviesa las secciones 02 a 11. Y toca una verdad incómoda: subís el modelo, lo probás en local, funciona bárbaro, lo mandás a producción, migrás el corpus, nadie reindexó, y de repente el asistente responde con datos viejos sin tirar un solo error. Sin evals corriendo como CI, te enterás por un cliente enojado.

El flujo que enseña es el mismo que pide un rol de FDE, según describen guías del puesto como la de Shakers: preguntas de discovery, un doc de scoping de una página, la disciplina del demo y el loop de debug.

Caso real: extracción de contratos, pipeline contra agente

El caso de estudio B es el que a los entrevistadores les encanta. La misma tarea de extracción de contratos resuelta de dos formas: como agente autónomo y como pipeline lineal. Después medís y probás con accuracy más costo de tokens cuál gana.

El resultado que el notebook busca demostrar: cuando los pasos ya se conocen, el pipeline gana. Es determinístico, más barato en tokens y más fácil de auditar. El agente brilla cuando el camino es incierto, no cuando vos ya sabés la secuencia. (Sí, en serio: no todo problema necesita un agente.) Complementá con potencial de Google Colab gratis.

Hay un tercer caso, el C, que le da otra vuelta de tuerca: un benchmark de robustez red-team. En vez de servir un modelo, lo evalúa. Es un loop atacante → target → juez (patrón PAIR) que mide la tasa de éxito de los ataques, combinando el loop de agente, el LLM-judge, la seguridad y las evals en un solo harness.

Errores comunes al arrancar con estos notebooks

• Confundir embeddings con RAG. Armar la búsqueda vectorial y creer que ya tenés el sistema. RAG es el loop completo recuperar→aumentar→generar; los embeddings son una pieza. Sin el paso de aumentar el prompt, no hay RAG.
• Saltear las evals para “ir más rápido”. Es la trampa más cara. Sin golden set propio no podés saber si un cambio mejoró algo. El repo pone evals antes de cualquier tuning por una razón: es lo que separa a quien shippeó un sistema de quien armó un demo.
• Meter un agente donde iba un pipeline. Si los pasos ya los conocés, el agente solo agrega no-determinismo, latencia y tokens. Preguntate si de verdad necesitás que el modelo decida el camino.
• Ir directo al framework. Empezar con LangChain sin haber escrito el loop crudo. Cuando algo falla, no distinguís si el problema es tu lógica o la capa de abstracción. Escribí el patrón crudo primero.

Preguntas Frecuentes

¿Qué son los AI Engineer Notebooks gratuitos?

Son 12 secciones de notebooks de Colab del repo calmrocks/ai-engineer-notebooks que enseñan a construir RAG, agentes, evaluaciones y serving sobre modelos de fundación usando APIs crudas, sin frameworks. Corren gratis sobre la API de Groq y cada uno cierra con ejercicios prácticos.

¿Cómo hago RAG en Google Colab sin frameworks?

Con llamadas crudas a una API OpenAI-compatible: recuperás fragmentos relevantes con búsqueda vectorial, los insertás en el prompt y generás la respuesta. La sección 03 del repo trae un demo funcional de 15 líneas y después suma búsqueda híbrida, rerankers y chunking sobre un corpus real.

¿Cuánto cuesta correr estos notebooks?

Nada. Todo el material se ejecuta sobre la API gratuita de Groq, que no pide tarjeta de crédito. Los dos temas que Groq no puede hostear, LoRA (06) y serving self-hosted (09), traen apéndices opcionales con GPU de Colab, también gratis dentro de los límites de la plataforma.

¿Cuándo conviene un pipeline en vez de un agente?

Cuando los pasos del proceso ya se conocen de antemano. Un pipeline lineal es determinístico, más barato en tokens y más fácil de auditar. El agente conviene cuando el camino es incierto y necesitás que el modelo decida qué herramienta usar en cada paso.

¿Sirven para prepararse como Forward Deployed Engineer?

Sí. El repo es el compañero práctico de un plan de transición a Forward Deployed Engineer / AI Engineer. La sección 11 trabaja la parte de cliente: convertir un pedido vago en un sistema evaluable, con discovery, doc de scoping y disciplina de demo, que es la ronda de entrevista que menos gente puede evidenciar.

Conclusión

Lo que cambia con estos notebooks es el orden en que aprendés. Primero escribís el loop crudo, después entendés qué hace el framework, y recién ahí decidís si lo usás. Las evals dejan de ser un extra y se vuelven la columna vertebral, que es exactamente lo que un rol de AI Engineer o FDE te va a pedir demostrar.

Si venís de backend o full-stack y querés la capa de modelo aplicado arriba, el plan es simple: clonás el repo, sacás una API key gratis de Groq, la cargás en los secrets de Colab y trabajás de la sección 01 a la 12 haciendo los ejercicios. El capstone (una sección de serving más un reporte de eval) es lo que después ponés en el CV. Los casos de estudio son para aprender; el capstone es para que te contraten.

Fuentes

• GitHub – calmrocks/ai-engineer-notebooks – repositorio oficial con los notebooks framework-free de Colab.
• Magnesium – Forward Deployed Engineer en la empresa – contexto sobre el rol de FDE.
• Shakers – Skills stack del Forward Deployed Engineer – habilidades esperadas del puesto.
• dev.to – Fine-tuning vs RAG en producción – cuándo usar cada enfoque de adaptación.