¿Cómo se actualiza la base vectorial del RAG cuando la fuente cambia?
Un vector store no aprende solo — recupera chunks desactualizados con la misma confianza que frescos. Estrategias concretas de re-indexación: scraping programado, crons, CRAG y Self-RAG.
El RAG no aprende solo
Una base vectorial es estática por defecto. El proceso de indexación (chunking → embedding → almacenamiento en el vector store) ocurre una vez y los vectores quedan fijos. Cuando la fuente de conocimiento cambia — se actualiza un documento, cambia una URL, se acumulan conversaciones nuevas — el índice no lo sabe. El retriever devuelve el chunk desactualizado con la misma confianza semántica que el actual.
No hay un hook automático que conecte la fuente con el índice. La decisión de cuándo re-indexar y cómo hacerlo es parte del diseño del sistema, no algo que el RAG resuelva por sí mismo.
La consecuencia silenciosa: un agente con RAG puede responder con absoluta confianza usando información que cambió hace seis meses. No hay señal de error — la respuesta parece correcta hasta que alguien la contrasta con la fuente real.
Estrategias según el tipo de fuente
La estrategia de re-indexación depende del formato y la frecuencia de cambio de la fuente de conocimiento:
URLs / documentación web
Se programa un scraper que vuelve a extraer el contenido de las URLs indexadas y regenera los embeddings. Puede ser un cron diario, semanal, o disparado por un webhook cuando la fuente actualiza.
# cron.py scrape_and_reindex(urls=INDEXED_URLS) # Ejecutar con: cron 0 3 * * * python cron.py
PDFs / documentos estáticos
Re-ejecutar la celda de indexación cuando el documento cambia. En producción, esto se puede automatizar con un hash del archivo: si el hash cambia respecto al indexado, se re-indexa.
# Comprobar si el PDF ha cambiado antes de re-indexar
if hash_of(new_pdf) != stored_hash:
reindex(new_pdf)Conversaciones acumuladas
Cuando el volumen de interacciones supera un umbral (ej. 500 conversaciones validadas), se re-indexan junto al conocimiento base. Este patrón cierra el loop de aprendizaje del agente.
if len(validated_conversations) > THRESHOLD:
reindex(base_docs + validated_conversations)Patrones avanzados: CRAG y Self-RAG
Para sistemas donde la re-indexación manual no es viable (información que cambia continuamente, fuentes desconocidas a priori), existen patrones que automatizan parcialmente la gestión de la frescura:
CRAG — Corrective RAG
El agente evalúa la confianza del retrieval. Si la confianza es baja (los chunks recuperados no son relevantes o están potencialmente desactualizados), hace una búsqueda web en tiempo real para complementar. Añade latencia pero mantiene la relevancia sin re-indexar todo el corpus.
Self-RAG
El modelo evalúa su propia respuesta después de generarla. Si detecta que el output es inconsistente con el contexto recuperado, inicia otro ciclo de retrieval antes de devolver la respuesta final. Añade complejidad significativa pero reduce alucinaciones en dominios cambiantes.
Ambos patrones añaden complejidad de implementación. Para la mayoría de casos de uso el punto de partida correcto es un cron de re-indexación bien diseñado, no CRAG ni Self-RAG. Escalar a esos patrones cuando la re-indexación programada no es suficiente.
El takeaway
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.