El curso de RAG enseñó la calidad del retrieval — parsing, chunking, embeddings, búsqueda híbrida — sobre una suposición silenciosa: que el índice ya está poblado y al día. Esa suposición es este módulo. Porque entre el tutorial (cien PDFs indexados una vez) y la producción (trescientos mil documentos que cambian a diario, con permisos, borrados y una factura de embeddings) hay exactamente un pipeline de datos — y es de los que más se improvisan y peor envejecen.

La tesis del módulo

Un índice RAG en producción es una vista derivada de tus fuentes documentales, y mantenerla es un problema de sincronización incremental: detectar qué cambió (hash por chunk), re-embeber solo eso, propagar los borrados (el derecho al olvido no negocia con tu índice) y sincronizar los permisos — todo como un asset del orquestador con SLA de frescura. Re-embeber el corpus entero cada noche es el full-extract del módulo 3 con precio de GPU: funciona en el tutorial y quiebra en producción.

El pipeline completo, con sus etapas de este curso

   EL PIPELINE DEL RAG — LO QUE EL TUTORIAL OMITE

  fuentes (SharePoint · wiki · CRM · contratos)
     │  ingesta incremental (módulo 3: marcas/CDC)
     ▼
  ┌───────────────────────────────────────────┐
  │ bronce: documento crudo + metadatos       │
  │ (versión, permisos, fecha — módulo 2)     │
  └──────────────────┬────────────────────────┘
                     ▼ parsing + chunking (rag-02/03)
  ┌───────────────────────────────────────────┐
  │ plata: chunks con hash + doc_id + permisos│
  └──────────────────┬────────────────────────┘
                     ▼ diff por hash: ¿qué cambió?
        ┌────────────┼────────────┐
        ▼            ▼            ▼
    nuevos       modificados   borrados
    embeber      re-embeber    ELIMINAR
    e insertar   y reemplazar  del índice
                     │
                     ▼
  ┌───────────────────────────────────────────┐
  │ índice (vector DB) = asset con SLA        │
  │ + aduana de calidad (módulo 7)            │
  └───────────────────────────────────────────┘

La pieza central: el diff por hash de chunk

La re-indexación incremental se apoya en una tabla humilde que el tutorial nunca menciona — el estado del índice: por cada chunk, su doc_id, su posición, y el hash de su contenido. Cada corrida del pipeline: parsea y chunkea lo ingerido → calcula hashes → compara contra el estado → y solo lo distinto viaja al modelo de embeddings. Las consecuencias económicas son brutales y a favor: en un corpus típico, el cambio diario es 1-5% — la factura de embeddings baja 20-100× respecto del re-embebido total, y la ventana de indexación pasa de horas a minutos.

Los detalles que separan la versión que funciona de la que casi:

El chunking estable importa: si el chunker corta distinto ante un cambio menor (un párrafo agregado desplaza todos los chunks siguientes), el diff cree que todo cambió. Chunking por estructura del documento (secciones, headers — rag-03) produce diffs chicos; chunking por ventana deslizante de caracteres, avalanchas.
Versionar el embedder como parte del estado: cambiar de modelo de embeddings invalida el índice entero (los vectores viejos y nuevos no viven en el mismo espacio — rag-04). El estado registra modelo_embedding_version; el upgrade es una migración planificada con re-embebido total presupuestado — no un cambio de parámetro un viernes.
Idempotencia por upsert: insertar por chunk_id determinístico (doc + posición + versión) hace que re-correr no duplique — el módulo 2, aplicado al índice.

Los dos sincronizados que nadie pone en la demo

Borrados. El documento eliminado de SharePoint que sigue en tu índice es una respuesta del RAG citando información que ya no debía existir — en el mejor caso desactualización, en el peor un problema legal (el contrato purgado por retención, el dato personal borrado por derecho al olvido — prod-10 manda aquí). La ingesta debe ver los borrados (CDC los emite; el batch los detecta por comparación de inventario — módulo 3) y el pipeline propagarlos al índice con prioridad de cumplimiento, no de conveniencia.

Permisos. El corpus real tiene ACLs: el contrato que ve legal, la política que ve RRHH. El RAG que indexa todo y responde a todos es una escalada de privilegios con interfaz conversacional — el retrieval le entrega al empleado curioso el documento que el sistema de archivos le negaba. El patrón estándar: los permisos viajan como metadatos del chunk (grupos/roles autorizados, desde la fuente) y el retrieval filtra por el usuario que pregunta (todo vector DB serio filtra por metadatos en la consulta). Y como los permisos cambian, su sincronización es parte del diff — un documento re-clasificado como confidencial debe actualizar sus chunks con la misma urgencia que un borrado.

Ojo — el índice es un asset con SLA, no un proceso con fe: la pregunta operativa del RAG es la del módulo 6: ¿está fresco el índice respecto de sus fuentes? Eso se declara — “el índice refleja las fuentes con máximo 4 horas de rezago” — y se monitorea como asset: documentos pendientes de indexar, edad del más viejo, chunks huérfanos, borrados propagados. El “¿por qué el bot no sabe del comunicado de ayer?” del gerente es un SLA de frescura sin declarar — decláralo y el reproche se vuelve dashboard.

La aduana del módulo 7 cierra el pipeline con los chequeos propios de este consumidor: chunks vacíos o basura de parsing (la tabla que se volvió sopa de caracteres — el fallo típico de rag-02), documentos con cero chunks (el PDF que el parser no pudo leer no debe desaparecer en silencio), metadatos de permisos presentes, y el conteo índice-vs-fuentes cuadrando.

Errores comunes

Re-embeber todo cada noche. El full-extract con precio de GPU: factura 20-100× mayor y ventana que no escala. Diff por hash de chunk; incremental como default.
Chunking inestable bajo el diff. La ventana deslizante que convierte un párrafo nuevo en avalancha de “cambios”. Chunking estructural para que el diff mida cambios reales.
Cambiar el embedder como quien cambia un parámetro. Espacios vectoriales incompatibles conviviendo = retrieval roto en silencio. El modelo de embeddings es parte del estado del índice; su upgrade, una migración con presupuesto.
Ignorar los borrados. El índice como cementerio de documentos purgados es deuda legal indexada. Los deletes se detectan (CDC o inventario) y se propagan con prioridad de cumplimiento.
RAG sin permisos. Indexar todo y responder a todos es escalada de privilegios conversacional. ACLs como metadatos, filtro por usuario en el retrieval, y re-clasificaciones sincronizadas.
El índice sin observabilidad de frescura. “El bot no sabe lo de ayer” descubierto por el gerente es el asset sin SLA. Rezago declarado, medido y alertado — como todo asset de este curso.

La frase para llevarse

“El índice RAG es una vista derivada que se sincroniza, no un artefacto que se regenera: diff por hash, re-embebido solo de lo que cambió, borrados con prioridad legal, permisos que viajan con el chunk — y un SLA de frescura declarado, porque ‘el bot no sabe del comunicado de ayer’ es un incidente de pipeline, no de modelo.”

Qué viene

Módulo 11: features y tiempo real. El último consumidor: los modelos tabulares en producción que necesitan sus variables calculadas ya — el feature store como la pieza que resuelve el problema doble (calcular igual en entrenamiento y en producción: el temido skew), la frontera online/offline, y cuándo toda esa maquinaria es sobre-ingeniería con nombre elegante.

Data Engineering — Módulo 10: el pipeline de un RAG a escala