Módulo 7: Production Considerations para RAG
Módulo 7: Production Considerations para RAG
Descripción del módulo
Tu sistema RAG funciona. En local, con datos de prueba, en tu laptop, el pipeline completo —ingestion, indexing, retrieval, generation— devuelve resultados relevantes. Elegiste ChromaDB en el Módulo 4, comparaste opciones en el Módulo 5, y en el Módulo 6 formalizaste esa decisión con una matriz cuantitativa. Sabes PARA QUÉ necesitas una vector database, CÓMO funciona internamente y CUÁL elegir. Pero hay una pregunta que ningún tutorial, README ni getting started resuelve por ti: ¿qué pasa cuando tu RAG deja de ser un experimento y se convierte en un servicio del que dependen usuarios reales?
La distancia entre "funciona en mi máquina" y "funciona en producción con 99.9% de uptime" no es un salto incremental — es un cambio de mentalidad. En desarrollo, si algo falla, reinicias el proceso. En producción, si algo falla a las 3am un sábado, alguien recibe una alerta, abre un runbook y necesita saber exactamente qué hacer para restaurar el servicio antes de que los usuarios noten la degradación. En desarrollo, el costo es irrelevante porque usas tu propia máquina. En producción, un query mal optimizado que cuesta $0.002 se convierte en $6,000/mes cuando sirves 100K consultas diarias. En desarrollo, no hay SLAs. En producción, "el sistema está lento" se traduce en un número concreto: latencia p95 > 200ms durante más de 5 minutos dispara una alerta que requiere acción.
Este módulo cierra exactamente ese gap. No es un apéndice de "tips para producción" — es un módulo completo de 75-90 minutos diseñado para transformar tu perspectiva de developer que construye features a engineer que opera sistemas. Cubrirás las seis disciplinas que separan un RAG de tutorial de un RAG operable: escalado, observabilidad, disaster recovery, seguridad, optimización de costos y migración sin downtime. Al final, tendrás un Production Readiness Checklist que audita si tu sistema está listo para servir tráfico real.
🧠 El problema: la brecha entre tutorial y empleabilidad
Por qué la mayoría de desarrolladores RAG no están listos para producción
Haz una búsqueda de "build RAG system" en YouTube o Medium. Encontrarás cientos de tutoriales que te llevan de cero a "funciona" en 20 minutos. Pero el 95% de esos recursos termina exactamente donde empieza la parte difícil:
Tutorial típico:
1. pip install chromadb langchain openai ✅
2. Cargar documentos ✅
3. Generar embeddings ✅
4. Crear colección en ChromaDB ✅
5. Hacer query y obtener respuesta ✅
6. "¡Ya tienes un sistema RAG!" ✅
Lo que NO te dicen:
7. ¿Qué haces cuando el índice crece y la latencia sube?
8. ¿Cómo sabes que el sistema está degradándose antes del usuario?
9. ¿Qué pasa si pierdes el índice completo por un fallo de disco?
10. ¿Cómo evitas que alguien abuse tu API con 10K queries/segundo?
11. ¿Cuánto cuesta realmente operar esto por mes?
12. ¿Cómo migras de ChromaDB a Pinecone sin perder un solo query?
Los puntos 7-12 no son "nice to have". Son la diferencia entre un proyecto de portafolio y un servicio que un equipo pone en producción con confianza.
El escenario que revela la brecha
Imagina esta conversación en una entrevista técnica o design review:
Entrevistador: "Construiste un sistema RAG con ChromaDB.
¿Cómo lo pondrías en producción?"
Candidato A: "Pues... lo deployeo con Docker
y ya está."
Candidato B: "Primero definiría SLOs: p95 < 150ms,
error rate < 0.5%, uptime 99.9%. Luego
instrumentaría métricas con Prometheus,
configuraría backup diario del índice
con retención de 30 días, haría un restore
test semanal, aplicaría rate limiting por
API key, y tendría un runbook para los 3
escenarios de fallo más probables. Para
escalar, empezaría vertical y pasaría a
horizontal cuando el p95 supere el umbral
de forma sostenida."
Candidato B no necesita más experiencia. Necesita más mentalidad de producción. Y eso es exactamente lo que este módulo desarrolla.
El costo de ignorar producción
En la industria, los fallos de producción en sistemas RAG tienen consecuencias reales:
- Pérdida de datos: Un índice de 500K vectores sin backup que se corrompe = 3 semanas de re-ingestion + embedding costs
- Costos descontrolados: Sin monitoring de costo por query, un cambio inocente en
top_kde 5 a 20 puede triplicar el gasto mensual en embeddings - Degradación silenciosa: Sin alertas de latencia, el p95 sube de 120ms a 800ms durante dos semanas y nadie lo detecta hasta que un cliente se queja
- Vulnerabilidades: Sin rate limiting, un bot puede generar $2,000 en costos de API en una hora
- Migraciones traumáticas: Sin plan de migración, cambiar de ChromaDB a Pinecone requiere downtime de horas y riesgo de pérdida de consistencia
Cada uno de estos escenarios es evitable con las prácticas que aprenderás en este módulo.
🎯 Objetivo del módulo
Objetivo profesional:
Definir y aplicar prácticas mínimas para operar un sistema RAG en producción con estabilidad predecible, métricas accionables, costos controlados y respuesta clara ante incidentes.
¿Por qué es importante para un AI Engineer?
Imagina que tu equipo deployó el sistema RAG que construiste. Funciona bien las primeras semanas. Pero un lunes a las 7am, antes de que llegues a la oficina, el Slack del equipo tiene 15 mensajes: "el chat no responde", "las respuestas están tardando 10 segundos", "los resultados no tienen sentido". Tu Tech Lead te mira y pregunta: "¿Qué pasó? ¿Tenemos métricas? ¿Hay backup? ¿Cuál es el plan?"
Si no tienes respuesta para esas preguntas, la conversación es incómoda. Después de este módulo, tendrás un framework para responder cada una — no con teoría, sino con prácticas concretas que puedes implementar en una tarde.
Al finalizar este módulo, serás capaz de:
- Diseñar una estrategia de escalado para tu sistema RAG (vertical → horizontal → sharding)
- Instrumentar métricas mínimas de observabilidad (latencia p50/p95/p99, error rate, throughput, costo/query)
- Definir plan de backup y disaster recovery con RPO/RTO explícitos
- Aplicar controles mínimos de seguridad (auth, rate limiting, validación de inputs, aislamiento de datos)
- Optimizar costos de operación sin sacrificar calidad de retrieval (caching, batch ops, tuning de top_k)
- Planificar migración de vector database sin downtime usando el patrón dual-write/dual-read + canary
- Construir un Production Readiness Checklist que audite el estado operativo de tu RAG
- Responder con confianza a "¿está listo para producción?" con evidencia, no con intuición
📚 Contenido del módulo — Roadmap detallado
Cápsula 01: Introducción al módulo (estás aquí)
| Aspecto | Detalle |
|---|---|
| Tema | Contexto, objetivos, roadmap y conexión con proyecto |
| Pregunta clave | ¿Qué separa un RAG de tutorial de un RAG production-ready? |
| Entregable | Claridad sobre el proceso completo del módulo y mentalidad de producción |
| Tiempo | 8-10 min |
Cápsula 02: Estrategias de escalado
| Aspecto | Detalle |
|---|---|
| Tema | Vertical vs horizontal vs sharding — cuándo usar cada estrategia |
| Pregunta clave | ¿Cómo sé cuándo necesito escalar y qué componente es el cuello de botella? |
| Entregable | Proceso de decisión de escalado aplicable a tu sistema RAG |
| Tiempo | 10-12 min |
Qué aprenderás:
- Identificar el componente que limita el rendimiento: ingestion, retrieval o generación
- Escalado vertical primero (más CPU/RAM) — cuándo es suficiente y cuándo no
- Escalado horizontal (más nodos + balanceo) — señales de que lo necesitas
- Sharding por dominio o tenant — para índices que crecen más allá de un solo nodo
- Proceso de cuatro pasos: medir baseline → identificar cuello → intervenir → remedir
Cápsula 03: Monitoring y observabilidad
| Aspecto | Detalle |
|---|---|
| Tema | Qué métricas medir y cómo convertirlas en acciones |
| Pregunta clave | ¿Cómo sé que mi RAG se está degradando ANTES de que el usuario lo note? |
| Entregable | Dashboard mínimo de métricas con umbrales de alerta definidos |
| Tiempo | 10-12 min |
Qué aprenderás:
- Las 5 métricas mínimas: latencia p50/p95/p99, error rate, throughput, cache hit rate, costo/query
- Instrumentación básica con código Python (sin depender de vendor específico)
- Umbrales de alerta: warning vs crítico, duración mínima para evitar falsos positivos
- La diferencia entre monitoring (qué pasa) y observabilidad (por qué pasa)
- Dashboards que un on-call puede interpretar en 30 segundos a las 3am
Cápsula 04: Backup y disaster recovery
| Aspecto | Detalle |
|---|---|
| Tema | Proteger tu índice de vectores contra pérdida de datos y fallos catastróficos |
| Pregunta clave | Si pierdo el índice completo ahora, ¿cuánto tardo en recuperar y cuánto pierdo? |
| Entregable | Plan de DR con RPO/RTO definidos y runbook de restore |
| Tiempo | 10-12 min |
Qué aprenderás:
- RPO (cuánto dato puedes perder) y RTO (cuánto tardas en recuperar) — cómo elegir valores realistas
- Plan mínimo: backup diario, retención 7-30 días, restore test mensual
- Niveles de criticidad: qué respaldar primero (índice > metadata > config)
- Por qué un backup que no has probado restaurar NO es un backup
- Runbook de restore: pasos exactos que cualquier miembro del equipo puede ejecutar
Cápsula 05: Seguridad para APIs RAG
| Aspecto | Detalle |
|---|---|
| Tema | Proteger endpoints, datos y costos contra acceso no autorizado y abuso |
| Pregunta clave | ¿Qué vectores de ataque tiene mi sistema RAG y cuáles son los controles mínimos? |
| Entregable | Checklist de seguridad mínima aplicable a cualquier API RAG |
| Tiempo | 10-12 min |
Qué aprenderás:
- Los 4 controles mínimos: autenticación (API key/JWT), rate limiting, validación de inputs, aislamiento de datos
- Prompt injection en sistemas RAG — por qué es diferente de inyección SQL y cómo mitigarlo
- Guardrails básicos de validación de queries (longitud, tokens bloqueados)
- Señales de riesgo: picos anómalos de consultas, queries con patrones sospechosos
- Aislamiento por tenant: cuándo y cómo separar datos de distintos clientes
Cápsula 06: Optimización de costos y rendimiento
| Aspecto | Detalle |
|---|---|
| Tema | Reducir costos operativos sin sacrificar calidad de retrieval |
| Pregunta clave | ¿Cuánto cuesta cada query de mi RAG y cómo lo reduzco sin degradar la experiencia? |
| Entregable | Framework de optimización: identificar → intervenir → medir → conservar o revertir |
| Tiempo | 10-12 min |
Qué aprenderás:
- Las 5 palancas de optimización: cache de embeddings, cache de respuestas, ajuste de top_k, batch processing, modelos diferenciados por entorno
- Cómo identificar el mayor costo (embeddings vs generación vs infraestructura)
- La regla de una intervención a la vez — por qué cambiar dos cosas simultáneamente invalida la medición
- Métricas para decidir si una optimización se queda: mejora de p95, accuracy mantenida, reducción de costo comprobable
- El equilibrio calidad-costo: cuándo es aceptable reducir accuracy un 2% para ahorrar 40% en costos
Cápsula 07: Migración sin downtime
| Aspecto | Detalle |
|---|---|
| Tema | Mover de una vector database a otra (o actualizar) sin interrumpir el servicio |
| Pregunta clave | ¿Cómo migro de ChromaDB a Pinecone sin que mis usuarios pierdan un solo query? |
| Entregable | Plan de migración de 5 fases con criterios de rollback en cada punto |
| Tiempo | 10-12 min |
Qué aprenderás:
- El patrón de migración gradual: load data → dual-write → dual-read → canary → cutover
- Validaciones críticas en cada fase: equivalencia de resultados, latencia p95, consistencia de metadata
- Criterios de rollback: cuándo abortar y volver al sistema original
- Por qué migración ≠ reindexación — diferencias entre cambiar de DB y reconstruir el índice
- Documentación del plan: checklist que cualquier miembro del equipo puede ejecutar
Cápsula 08: Proyecto — Production Readiness Checklist
| Aspecto | Detalle |
|---|---|
| Tema | Auditar si tu sistema RAG está listo para producción |
| Pregunta clave | ¿Puedo demostrar con evidencia que mi RAG cumple estándares mínimos de producción? |
| Entregable | Checklist completado + top 5 brechas priorizadas + plan de 2 semanas |
| Tiempo | 15-20 min |
Qué construirás:
- Checklist que evalúa 5 áreas: infraestructura, observabilidad, resiliencia, seguridad, calidad RAG
- Estado actual de cada área con clasificación semáforo (verde/amarillo/rojo)
- Top 5 brechas priorizadas por impacto a usuario y probabilidad de fallo
- Plan de 2 semanas para cerrar brechas críticas con owners asignados
- Preguntas de defensa técnica: "¿Cuál es tu mayor riesgo operativo hoy?"
⏱️ Tiempo estimado
Lectura + análisis: 75-95 minutos
| Cápsula | Tema | Tiempo |
|---|---|---|
| 01 | Introducción al módulo | 8-10 min |
| 02 | Estrategias de escalado | 10-12 min |
| 03 | Monitoring y observabilidad | 10-12 min |
| 04 | Backup y disaster recovery | 10-12 min |
| 05 | Seguridad para APIs RAG | 10-12 min |
| 06 | Optimización de costos y rendimiento | 10-12 min |
| 07 | Migración sin downtime | 10-12 min |
| 08 | Proyecto — Production Readiness Checklist | 15-20 min |
| Total | 75-95 min |
Nota: Este módulo es 70% análisis operativo, 30% proyecto. No estás escribiendo queries a una vector database — estás definiendo cómo operar el sistema que las ejecuta. El "código" que produces son runbooks, dashboards, checklists y planes de migración. Estos artefactos son tan importantes como el código de tu aplicación — y en muchas organizaciones, más valorados.
🔗 Conexión con otros módulos
Vienes de:
Módulo 6: Decision Matrix para AI Engineers
- Elegiste tu vector database con scoring cuantitativo y evidencia
- Documentaste la decisión con criterios, pesos y trade-offs
- La pregunta "¿cuál DB uso?" está resuelta
- La pregunta que queda: "¿cómo la opero en producción?"
Módulos 1-5: Fundamentos, implementación y landscape
- Sabes POR QUÉ necesitas vector database (M1)
- Entiendes CÓMO funciona internamente (M2)
- Conoces las features esenciales para RAG (M3)
- Implementaste ChromaDB hands-on (M4)
- Comparaste proveedores y construiste decision tree (M5)
Este módulo te prepara para:
Módulo 8: Proyecto Integrador — RAG System con ChromaDB
- El sistema RAG completo (1,000+ docs, FastAPI, Docker) que construirás en M8 NECESITA estas prácticas
- Tu Production Readiness Checklist de este módulo se aplica directamente al proyecto integrador
- La diferencia entre un proyecto "que funciona" y uno "que está listo para producción" es exactamente lo que cubres aquí
Advanced RAG Techniques Guide (Guía #8)
- Cuando migres de ChromaDB a Pinecone en la siguiente guía, el plan de migración de la Cápsula 07 será tu referencia
- Las prácticas de monitoring, backup y seguridad se transfieren a cualquier vector database
Flujo completo:
Módulos 1-3: Fundamentos (POR QUÉ y CÓMO vector DBs)
↓
Módulo 4: ChromaDB hands-on (IMPLEMENTAR con una DB)
↓
Módulo 5: Landscape (COMPARAR cualitativamente)
↓
Módulo 6: Decision Matrix (CUANTIFICAR y DECIDIR)
↓
Módulo 7: Production ← Estás aquí (OPERAR y PROTEGER)
↓
Módulo 8: Proyecto Integrador (CONSTRUIR sistema completo)
La transición M6 → M7
El Módulo 6 te dejó con una decisión formal: sabes QUÉ vector database usar y POR QUÉ. Este módulo responde la pregunta que sigue naturalmente: "ya elegí, ahora ¿CÓMO la opero para que funcione de forma confiable, segura y económica?" Elegir bien es necesario, pero no suficiente.
🎓 ¿Qué aprenderás en este módulo?
Al finalizar este módulo, serás capaz de:
- ✅ Operar con mentalidad de producción: definir SLOs, pensar en fallos antes de que ocurran, usar runbooks en lugar de heroísmo
- ✅ Escalar tu sistema RAG: identificar cuellos de botella, decidir entre vertical/horizontal/sharding con criterios claros
- ✅ Observar proactivamente: instrumentar las 5 métricas mínimas, configurar alertas que minimizan falsos positivos
- ✅ Proteger contra pérdida de datos: definir RPO/RTO realistas, implementar backup con verificación periódica
- ✅ Asegurar tu API: aplicar los 4 controles mínimos, mitigar prompt injection, detectar patrones de abuso
- ✅ Optimizar costos sin degradar: identificar el mayor costo, aplicar intervenciones una a la vez con medición
- ✅ Migrar con confianza: ejecutar el patrón dual-write/dual-read + canary con rollback en cada fase
💡 Filosofía del módulo
Lo que separa a un developer de un engineer
Un developer construye features que funcionan. Un engineer construye sistemas que siguen funcionando.
La diferencia no es de talento ni de años de experiencia. Es de mentalidad:
| Developer mindset | Engineer mindset |
|---|---|
| "Funciona en mi máquina" | "Funciona en producción con SLOs definidos" |
| "Si falla, lo arreglo" | "Tengo un runbook para los 3 fallos más probables" |
| "No ha fallado todavía" | "¿Cuándo fue el último restore test?" |
| "Costará lo que cueste" | "Costo por query: $0.003, objetivo: < $0.005" |
| "Migrar es copiar datos" | "Migrar es mantener el servicio mientras cambias todo debajo" |
Este módulo no te pide que te conviertas en un SRE. Te pide que adoptes las prácticas mínimas que hacen que tu trabajo como AI Engineer sea confiable, defendible y escalable. Eso te diferencia en entrevistas, en design reviews y en la confianza de tu equipo.
Production mindset = pensar en fallos antes de que ocurran
El ejercicio mental más valioso de este módulo es simple: para cada componente de tu sistema RAG, preguntarte "¿qué pasa si esto falla?" y tener una respuesta documentada.
¿Qué pasa si...?
...el índice de ChromaDB se corrompe?
→ Restore del backup diario (RTO: 2h, RPO: 24h)
...la latencia p95 sube de 150ms a 800ms?
→ Dashboard detecta, alerta dispara, runbook indica:
verificar carga → check tamaño de índice → escalar si necesario
...un usuario envía 10K queries en 1 minuto?
→ Rate limiting rechaza después de 100/min con 429
...los costos de embeddings se duplican sin cambio de tráfico?
→ Alerta de costo/query, revisión de top_k y cache hit rate
...necesitas migrar de ChromaDB a Pinecone?
→ Plan de 5 fases con rollback en cada punto
Si puedes responder estas preguntas con acciones concretas, tu sistema está listo para producción. Si no, este módulo te equipa para poder hacerlo. Y nota: una cultura de ingeniería sana no depende de que la persona más senior "sepa qué hacer" cuando algo falla — depende de que exista un runbook que cualquier miembro del equipo pueda seguir. El heroísmo de las 3am es señal de que falta proceso, no de que el equipo sea bueno.
🚫 Qué NO cubre este módulo
Este módulo NO cubre:
❌ Implementación técnica de scaling específico de un proveedor
- No vas a configurar un cluster de Pinecone ni replicas de Qdrant
- El foco es el PROCESO de decisión y planificación, no la ejecución técnica
- Los principios son transferibles a cualquier vector database
❌ Herramientas de monitoring específicas
- No es un tutorial de Prometheus, Grafana, Datadog ni New Relic
- Aprenderás QUÉ medir y POR QUÉ, con instrumentación básica en Python
- La elección de herramienta es decisión de tu equipo/organización
❌ Seguridad avanzada (pen testing, compliance frameworks)
- Cubrirás los controles MÍNIMOS para proteger una API RAG
- SOC2, HIPAA, GDPR son temas que exceden el scope de esta guía
- El objetivo es que tu sistema no sea trivialmente vulnerable, no que pase una auditoría enterprise
❌ Código ejecutable de migración real
- Aprenderás el PATRÓN de migración gradual y los criterios de validación
- El código específico depende de tus DBs de origen y destino
- El plan que produces es documentación operativa, no un script ejecutable
❌ Decisión de qué vector database usar (eso fue Módulo 6)
- Aquí asumimos que ya elegiste y tu foco es operar correctamente
Scope claro: Este módulo es sobre mentalidad y prácticas operativas. Convierte la elección técnica del Módulo 6 en un sistema operable con estabilidad, métricas, seguridad y planes de contingencia.
✅ Criterios de éxito
Completaste exitosamente este módulo cuando:
Puedes responder estas preguntas:
-
✅ ¿Cómo escalas tu sistema RAG cuando la latencia empieza a subir?
- Proceso de diagnóstico: identificar cuello de botella → intervenir → medir impacto
- Decisión vertical vs horizontal con criterios cuantificables
- Señales claras de cuándo aplicar sharding
-
✅ ¿Qué métricas monitoreas y qué haces cuando una alerta se dispara?
- Las 5 métricas mínimas con umbrales de warning y crítico
- Al menos un dashboard interpretable en menos de 30 segundos
- Acciones concretas para cada tipo de alerta
-
✅ Si pierdes tu índice de vectores ahora, ¿cuánto tardas en recuperar?
- RPO y RTO definidos con números concretos
- Backup automatizado con retención y verificación
- Restore test ejecutado al menos una vez (no solo documentado)
-
✅ ¿Qué controles de seguridad tiene tu API RAG?
- Los 4 controles mínimos implementados o planificados
- Validación de inputs con guardrails contra prompt injection
- Rate limiting configurado con umbrales razonables
-
✅ ¿Puedes entregar un Production Readiness Checklist con estado real?
- 5 áreas evaluadas con clasificación semáforo
- Top 5 brechas priorizadas con justificación
- Plan de 2 semanas para cerrar las brechas más críticas
Si respondiste 4-5/5 correctamente Y entregaste checklist con brechas priorizadas → ✅ Módulo completado
🧩 Mini checklist de preparación
Antes de iniciar este módulo, asegúrate de tener claros estos puntos de módulos anteriores:
- ¿Tengo un sistema RAG funcional (aunque sea local) que puedo usar como referencia mental?
- ¿Elegí una vector database con criterios documentados (Módulo 6)?
- ¿Entiendo la diferencia entre managed y self-hosted?
- ¿Conozco las operaciones básicas de mi vector database (CRUD, search, filtering)?
- ¿Tengo noción de cuántos vectores maneja (o manejará) mi sistema?
Si respondiste "no" a 2 o más, revisa las cápsulas correspondientes de Módulos 4-6 antes de continuar.
Además, piensa en tu sistema RAG mientras avanzas:
- ¿Cuál es la latencia actual de retrieval? (aunque sea aproximada)
- ¿Quién tiene acceso a tu API? ¿Hay autenticación?
- ¿Tienes backup del índice? ¿Lo has probado restaurar?
- ¿Cuánto cuesta operar tu sistema por mes? ¿Lo sabes?
- ¿Qué harías si el sistema dejara de responder ahora mismo?
Tener tu propio sistema en mente convierte cada cápsula de "teoría interesante" a "esto lo necesito resolver esta semana".
📖 Cómo usar este módulo
Estrategia recomendada:
-
Lee secuencialmente (Cápsulas 01 → 02 → ... → 08)
- Cada cápsula cubre una disciplina independiente pero conectada
- Escalado (C02) genera las métricas que monitoreas en C03
- Backup (C04) define el plan que la seguridad (C05) protege
- Optimización (C06) requiere las métricas de C03 para medir impacto
- Migración (C07) integra prácticas de todas las cápsulas anteriores
-
Aplica cada cápsula a TU sistema
- "¿Cuál es MI cuello de botella?" — no el genérico, el tuyo
- "¿Qué métricas necesito YO?" — según tu SLA, tu tráfico, tu presupuesto
- "¿Cuál es MI RPO/RTO?" — según la criticidad de tu caso de uso
-
Construye tu checklist progresivamente
- Después de cada cápsula, agrega los ítems relevantes a tu Production Readiness Checklist
- Al llegar a la Cápsula 08, tu checklist ya tiene contenido real — solo falta consolidar
-
Prioriza realismo sobre completitud
- Es mejor tener 3 prácticas implementadas y probadas que 15 documentadas pero sin ejecutar
- Un backup probado vale más que diez dashboards configurados pero que nadie mira
Tiempo sugerido:
Opción A: Dos sesiones (recomendado)
- Sesión 1: Cápsulas 01-04 (intro, escalado, monitoring, DR) = 40-50 min
- Sesión 2: Cápsulas 05-08 (seguridad, costos, migración, proyecto) = 45-55 min
Opción B: Una sesión intensa
- Todo de corrido = 75-95 min
- Ventaja: visión integral; desventaja: mucho contenido operativo de una vez
Recomendación: Opción A. La primera sesión cubre la infraestructura operativa básica (cómo escalar, cómo medir, cómo recuperar). La segunda cubre protección y evolución (cómo asegurar, cómo optimizar, cómo migrar). El break entre sesiones te permite reflexionar sobre qué aplica a tu sistema.
🎯 Conexión con el proyecto: Production Readiness Checklist
El proyecto de este módulo es una herramienta de auditoría práctica: un Production Readiness Checklist que evalúa si tu sistema RAG cumple estándares mínimos para servir tráfico real.
¿Qué es un Production Readiness Checklist?
Es un documento estructurado que examina 5 áreas operativas de tu sistema RAG y produce un diagnóstico accionable:
INPUT: Estado actual de tu sistema en 5 áreas
OUTPUT: Clasificación semáforo por área
├─ 🟢 Verde: cumple estándar mínimo
├─ 🟡 Amarillo: parcialmente cubierto, necesita mejora
└─ 🔴 Rojo: brecha crítica, riesgo alto
Top 5 brechas priorizadas por impacto
Plan de 2 semanas para cerrar brechas críticas
No es un ejercicio académico. Es una herramienta que usarías en un design review real para responder "¿estamos listos para producción?" con evidencia.
Cómo se construye a lo largo del módulo
Cada cápsula aporta criterios de evaluación al checklist:
| Cápsula | Área del Checklist |
|---|---|
| 02 - Escalado | Infraestructura: ¿estrategia definida? ¿límites documentados? |
| 03 - Monitoring | Observabilidad: ¿dashboards activos? ¿alertas probadas? |
| 04 - Backup/DR | Resiliencia: ¿backups automáticos? ¿restore test reciente? |
| 05 - Seguridad | Seguridad: ¿auth activo? ¿rate limiting? ¿validación de inputs? |
| 06 - Costos | Calidad: ¿costo/query conocido? ¿optimizaciones medidas? |
| 07 - Migración | Infraestructura: ¿plan de migración reversible? |
| 08 - Proyecto | Consolidación: ensamblar, priorizar brechas, crear plan |
No llegas a la Cápsula 08 empezando de cero. Llegas con criterios claros para cada área, listos para evaluar tu sistema real.
El checklist en el contexto del Módulo 8
Tu Production Readiness Checklist se usa directamente en el proyecto integrador del Módulo 8. Cuando construyas el sistema RAG completo (1,000+ docs, FastAPI, Docker), aplicarás este checklist para validar que no es solo un "sistema que funciona" sino un "sistema listo para producción". La conexión es directa e inmediata.
Resumen
- Este módulo cierra el gap entre "funciona en local" y "funciona en producción" — la distancia que más importa para empleabilidad
- Aprenderás las 6 disciplinas operativas: escalado, observabilidad, disaster recovery, seguridad, optimización de costos y migración
- El enfoque es mentalidad antes que herramientas: los principios se transfieren a cualquier vector database y stack tecnológico
- Cada cápsula produce un artefacto operativo concreto (proceso de escalado, umbrales de alerta, plan de DR, controles de seguridad, framework de optimización, plan de migración)
- El proyecto final — Production Readiness Checklist — audita tu sistema real y prioriza las brechas más críticas
- La habilidad central — operar sistemas con estabilidad predecible y respuesta clara ante incidentes — es lo que separa un developer de un engineer
- Se aplica directamente al proyecto integrador del Módulo 8 y se transfiere a cualquier sistema RAG que construyas en tu carrera
- Es el puente entre decisión técnica (M6) y construcción del sistema completo (M8)
🔗 Recursos adicionales
Production engineering fundamentals:
- Google SRE Book - Table of Contents — Referencia definitiva de Site Reliability Engineering
- The Twelve-Factor App — Metodología para construir aplicaciones operables en producción
- Google SRE Workbook - Incident Response — Guía práctica de respuesta a incidentes
Monitoring y observabilidad:
- Prometheus - Monitoring Best Practices — Estándar de instrumentación de métricas
- OpenTelemetry Documentation — Framework vendor-neutral para observabilidad
Seguridad para APIs:
- OWASP API Security Top 10 — Los 10 riesgos de seguridad más comunes en APIs
- OWASP LLM Top 10 — Riesgos de seguridad específicos de aplicaciones LLM (incluye prompt injection)
Vector database production:
- Pinecone Production Best Practices — Prácticas operativas para vector databases managed
- Qdrant Production Deployment — Guía de deployment para vector databases self-hosted
Nota: Estos recursos son referencia complementaria, no lectura obligatoria. El módulo es autocontenido — cada cápsula te da las prácticas mínimas necesarias sin depender de documentación externa.
🚀 ¿Listo para empezar?
Próximo paso:
Ve a Cápsula 02: Estrategias de escalado
Ahí aprenderás:
- Cómo identificar qué componente limita el rendimiento de tu RAG
- Cuándo escalar vertical (más recursos) vs horizontal (más nodos)
- Cómo aplicar sharding para índices que crecen más allá de un nodo
- El proceso de 4 pasos: medir baseline → identificar cuello → intervenir → remedir
Es la primera disciplina operativa: antes de monitorear, respaldar o asegurar, necesitas que tu sistema pueda manejar la carga.
Tiempo de lectura: 8-10 minutos
Siguiente: 02-estrategias-escalado.md