馃毃 HITO AI ENGINEER. Desarrollo de IWS-RAG e IWS-Chat: arquitectura Serverless RAG con Google Files API y streaming en tiempo real con generateContentStream. An谩lisis t茅cnico de outages de Cloudflare/AWS. Consolidaci贸n como ingeniero capaz de construir productos de IA en producci贸n.
Noviembre del 2025 fue el mes en que la IA dej贸 de ser un experimento y se convirti贸 en producto. Constru铆 dos proyectos que consolidaron todo lo que hab铆a aprendido: iws-rag e iws-chat. No eran demos: eran sistemas de producci贸n que resolv铆an problemas reales.
IWS-RAG naci贸 de una frustraci贸n: los sistemas RAG tradicionales son demasiado complejos. Necesitas configurar bases de datos vectoriales (ChromaDB, Pinecone), escribir pipelines de chunking, gestionar embeddings, y rezar para que la b煤squeda sem谩ntica funcione. Yo quer铆a algo m谩s simple. Y lo encontr茅 en la Google Files API con File Search.
La arquitectura fue reveladora. En lugar de gestionar un pipeline completo de ingesti贸n (parseo de PDFs, splitting recursivo, generaci贸n de embeddings con text-embedding-3, almacenamiento en vectores), delegu茅 todo a la infraestructura de Google. Subir un documento era una llamada a genai.files.upload. Consultarlo era pasar una referencia al modelo. El chunking, los embeddings, la b煤squeda de similitud de coseno: todo ocurr铆a dentro de la "caja negra" de Gemini. Era Serverless RAG en su forma m谩s pura.
Pero lo que realmente me impact贸 fue la estructura de costos. Las bases de datos vectoriales cobran por pod/hora o tienen m铆nimos mensuales altos. Con Files API, el costo se concentra en la indexaci贸n ($0.15 por mill贸n de tokens) y el almacenamiento es pr谩cticamente gratis. Para aplicaciones de tr谩fico bajo a medio, la diferencia es brutal.
IWS-Chat fue el frontend de ese sistema. Pero no un frontend cualquiera: implement茅 streaming en tiempo real usando generateContentStream. La diferencia entre esperar 15 segundos a que aparezca una respuesta completa y ver los tokens escribirse en milisegundos es la diferencia entre una demo y un producto usable.
El stack t茅cnico fue quir煤rgico. React en el frontend manejando Server-Sent Events (SSE) para recibir los chunks. Un middleware en Node.js que actuaba como proxy, canalizando la respuesta de Gemini al cliente. Y la gesti贸n de interrupciones con AbortController: si el usuario cancelaba la generaci贸n, la se帽al se propagaba hasta la API para no pagar tokens innecesarios.
Tambi茅n aprend铆 sobre las limitaciones del modelo gestionado. La fragmentaci贸n es opaca: no puedo personalizar el chunk overlap ni el tama帽o. Si Google divide mal una tabla cr铆tica, la calidad de recuperaci贸n sufre. Pero para el 80% de los casos de uso, la simplificaci贸n vale la pena.
En paralelo, segu铆a analizando los outages de Cloudflare y AWS. Us茅 los logs de mi propio servidor para comparar latencias antes y despu茅s del incidente. Los servicios con m煤ltiples proveedores de DNS sobrevivieron. Los que depend铆an de uno solo, colapsaron. Era una lecci贸n de arquitectura distribuida escrita en post-mortems.
Tambi茅n prob茅 Gemini 2.0 Flash y el protocolo MCP. La velocidad era impresionante: menos tokens de entrada, m谩s contexto aprovechado, mejor razonamiento. Mi obsesi贸n por optimizar recursos (desde Hyper-V hasta Docker Swarm) hab铆a encontrado su eco en la optimizaci贸n de modelos de lenguaje.
Noviembre me ense帽贸 tres cosas: