Mantener actualizado tu base de conocimiento: gestión de datos RAG

Qué cubre este artículo sobre actualización de la base de conocimiento

• Por qué la base de conocimiento RAG necesita actualizaciones regulares y qué sucede si no lo haces.
• Las dos estrategias principales: reconstrucción completa y actualizaciones incrementales.
• Guía paso a paso para documentos nuevos, modificados y obsoletos.
• Versionado y automatización para mantener tu base de conocimiento siempre al día.
• Trampas comunes y cómo evitarlas.

Introducción: actualización de la base de conocimiento explicada

Un sistema RAG vive de sus datos. Has recopilado documentos, los has dividido en chunks, los has procesado con un modelo de embedding y los has almacenado en una base de datos vectorial. Hasta aquí, bien. Pero los documentos cambian. Llegan nuevos, otros quedan obsoletos, algunos se revisan.

Aquí comienza el mantenimiento de tu base de conocimiento. Este artículo te muestra cómo mantener actualizado tu base de conocimiento RAG sin tener que empezar desde cero cada vez. Aprenderás qué estrategias existen, cuándo tiene sentido cada una y cómo automatizar el proceso.

Si aún no conoces los fundamentos de RAG, lee primero ese artículo. Explica cómo trabajan juntos los componentes individuales.

¿Por qué necesito actualizaciones?

Imagina que tu empresa tiene un manual para empleados. Contiene reglas de vacaciones, horarios de trabajo y políticas. Cargaste este manual en tu sistema RAG hace seis meses. Ahora alguien pregunta: “¿Cuántos días de vacaciones tengo al año?”

El sistema RAG busca en la base de datos vectorial, encuentra la entrada antigua y responde: “30 días.” El problema es que el manual se actualizó hace dos meses. Ahora son 28 días. Tu sistema RAG no lo sabe, porque nadie eliminó la versión antigua ni añadió la nueva.

No es un escenario teórico. Sucede en cualquier lugar donde los documentos no son estáticos. Los contratos cambian, los textos legales se adaptan, los manuales de productos reciben nuevas versiones, las políticas internas se revisan. Un sistema RAG sin actualizaciones se vuelve cada vez más poco confiable.

Otros ejemplos de datos obsoletos:

• Un catálogo de productos del que se han eliminado artículos, pero el sistema aún los recomienda.
• Una política de privacidad antigua que no se ajusta a la legislación actual.
• Ofertas caducadas que el sistema aún presenta como válidas.

Base de conocimiento: actualización resumida

Imagina una biblioteca. Regularmente llegan libros nuevos. Algunos se reemplazan por ediciones más recientes. Otros se descartan porque están desactualizados. El bibliotecario mantiene un registro de qué es nuevo, qué ha sido reemplazado y qué se ha eliminado. Sin este mantenimiento, la biblioteca se volvería inutilizable porque los visitantes encontrarían información desactualizada.

Tu base de conocimiento RAG funciona igual. La base de datos vectorial es la biblioteca, los documentos son los libros, y tú eres el bibliotecario. Los documentos nuevos deben añadirse, los modificados reemplazarse y los obsoletos eliminarse. Este proceso se llama actualización o mantenimiento de la base de conocimiento.

Para quién es este artículo

Este artículo está dirigido a principiantes que ya tienen un sistema RAG funcional y ahora quieren aprender cómo mantenerlo a largo plazo. No necesitas conocimientos profundos de programación, pero deberías estar familiarizado con los fundamentos de RAG local y preparación de documentos.

Si tienes dudas generales sobre qué es la IA local, el artículo ¿Qué es la IA local? te puede ayudar.

Términos importantes en relación a la actualización

Término	Significado
Base de conocimiento	Conjunto de todos los documentos y chunks en tu base de datos vectorial
Collection	Área nombrada en la base de datos vectorial que contiene datos relacionados
Upsert	Actualizar entrada si existe, si no crear nueva (Update + Insert)
Delete	Eliminar entrada o entradas de la base de datos vectorial
Versionado	Capacidad de rastrear qué versión de un documento se almacena
Actualización incremental	Actualizar solo documentos modificados o nuevos, no recargar todo
Full Rebuild	Reconstrucción completa de la base de datos vectorial, todos los datos se incrustan de nuevo
Stale	Entrada obsoleta que no corresponde al estado actual del documento origen
Chunk ID	Identificador único para un chunk individual en la base de datos
Embedding	Vector numérico que representa el significado de una sección de texto

¿Qué sucede con datos obsoletos?

Los datos obsoletos no son solo desagradables, son activamente perjudiciales para tu sistema RAG. Estas son las consecuencias más comunes:

Respuestas incorrectas: El sistema responde basándose en información antigua. En el mejor de los casos, esto significa que se menciona una fecha de producto desactualizada. En casos más graves, el sistema proporciona información de seguridad o legal incorrecta.

Respuestas contradictorias: Si tienes versión antigua y nueva del mismo documento en la base de datos, el sistema puede dar una respuesta u otra según la consulta. Esto parece poco confiable y confuso.

Problemas de cumplimiento: En áreas reguladas como finanzas, medicina o privacidad de datos, es importante usar solo documentos actuales. Las políticas obsoletas pueden traer consecuencias legales.

Pérdida de confiabilidad: Cuando los usuarios notan que las respuestas están desactualizadas, pierden la confianza en el sistema. Esto es difícil de recuperar.

Estrategia 1: Reconstrucción completa

La reconstrucción completa, también llamada Full Rebuild, es la estrategia más simple. Eliminas todos los datos de la base de datos vectorial y recargas todos los documentos. Cada documento se divide de nuevo en chunks, cada chunk se incrusta de nuevo y se almacena.

¿Cuándo tiene sentido?

• Al construir el sistema por primera vez.
• Cuando tu método de chunking o modelo de embedding ha cambiado.
• Cuando la base de datos es defectuosa o inconsistente.
• Con bases de conocimiento pequeñas que se reconstruyen rápidamente.
• Cuando no tienes seguimiento y no sabes qué ha cambiado.

Ventajas:

• Simple de implementar, no requiere rastreo de cambios.
• Garantiza un estado consistente después.
• Sin entradas obsoletas.

Desventajas:

• Con bases de conocimiento grandes tarda mucho tiempo.
• Cada documento debe incrustarse de nuevo, lo que consume recursos.
• Durante la reconstrucción el sistema no está disponible.

Un Full Rebuild es como un soplo de aire fresco para tu base de datos. Para proyectos pequeños o intervalos de mantenimiento ocasionales es completamente suficiente.

Estrategia 2: Actualizaciones incrementales

Las actualizaciones incrementales son la estrategia más eficiente para bases de conocimiento más grandes. En lugar de recargar todo, actualizas solo lo que ha cambiado. Los documentos nuevos se añaden, los modificados se reemplazan, los eliminados se borran.

¿Cuándo tiene sentido?

• Con bases de conocimiento grandes donde un Full Rebuild llevaría demasiado tiempo.
• Cuando los documentos cambian frecuentemente, pero solo en partes pequeñas.
• Cuando tienes un sistema para detectar cambios.
• Cuando el sistema debe permanecer disponible durante la actualización.

Ventajas:

• Mucho más rápido que un Full Rebuild.
• Menor consumo de recursos, solo los documentos modificados se incrustan de nuevo.
• El sistema permanece disponible.

Desventajas:

• Más complejo de implementar.
• Requiere rastreo de qué versión de cada documento tienes almacenada.
• Los errores en detección de cambios llevan a entradas obsoletas.

Las actualizaciones incrementales son la estrategia preferida para sistemas en producción que necesitan mantenimiento continuo.

Paso 1: Añadir nuevos documentos

Añadir nuevos documentos sigue el mismo proceso que la configuración inicial. Recorres los pasos conocidos de Preparación de documentos:

1. Preparación: Carga el documento, límpialo y verifica su contenido. Elimina formatos innecesarios y asegúrate de que el texto sea legible.
2. Chunking: Divide el documento en secciones, como se describe en Chunking.
3. Embedding: Convierte cada chunk en un vector usando tu modelo de embedding.
4. Almacenamiento: Inserta los vectores junto con metadatos en la base de datos vectorial.

Es importante incluir metadatos. Deberías almacenar al menos estos campos:

• source: Ruta o URL del documento original.
• version: Versión o fecha del documento.
• chunk_id: ID único para el chunk.
• created_at: Momento en que se añadió.

Con estos metadatos puedes actualizar o eliminar datos específicos más adelante.

Un ejemplo simple con Chroma:

import chromadb

client = chromadb.PersistentClient(path="./vectordb")
collection = client.get_or_create_collection("wissen")

collection.add(
    documents=["Urlaubsregelung 2026: 28 Tage pro Jahr"],
    metadatas=[{"source": "handbuch.pdf", "version": "2026-08", "chunk_id": "handbuch_001"}],
    ids=["handbuch_001"]
)

Paso 2: Actualizar documentos modificados

Cuando un documento cambia, no es suficiente añadir la nueva versión. De lo contrario tendrás chunks antiguos y nuevos simultáneamente en la base de datos, lo que genera respuestas contradictorias.

El proceso correcto es:

1. Detectar cambios: Compara la versión actual del documento con la almacenada. Para esto funcionan bien los valores hash o números de versión.
2. Eliminar chunks antiguos: Borra todos los chunks de la versión anterior. Puedes localizarlos a través de metadatos, por ejemplo usando source y version.
3. Añadir nuevos chunks: Divide el documento actualizado, genera embeddings y guárdalo con el nuevo número de versión.

Muchas bases de datos vectoriales admiten upsert, es decir, actualizar e insertar simultáneamente. Con Chroma se ve así:

# Eliminar chunks antiguos de este documento
collection.delete(
    where={"source": "handbuch.pdf"}
)

# Añadir la nueva versión
collection.add(
    documents=["Neue Urlaubsregelung 2026: 28 Tage pro Jahr"],
    metadatas=[{"source": "handbuch.pdf", "version": "2026-09", "chunk_id": "handbuch_001"}],
    ids=["handbuch_001"]
)

Alternativamente, puedes usar upsert si tu base de datos lo soporta. Upsert sobrescribe los IDs existentes e inserta los nuevos.

Paso 3: Eliminar documentos obsoletos

A veces los documentos se vuelven completamente inválidos. Un producto se descontinúa, una política se revoca, un contrato expira. En estos casos debes eliminar los chunks correspondientes de la base de datos.

Puedes eliminar de varias formas:

Por fuente: Borra todos los chunks que pertenecen a un documento específico.

collection.delete(where={"source": "altes_handbuch.pdf"})

Por fecha: Elimina todos los chunks añadidos antes de una fecha determinada.

collection.delete(where={"created_at": {"$lt": "2026-01-01"}})

Por metadatos: Borra todos los chunks que tengan una propiedad específica, por ejemplo una versión antigua.

collection.delete(where={"version": "2025-12"})

Importante: No elimines ciegamente todo lo que sea antiguo. Algunos documentos siguen siendo válidos después de años. Verifica antes de eliminar si el documento realmente está obsoleto.

Versionado y trazabilidad

El versionado es la clave para mantener actualizaciones limpias. Sin él no sabes qué versión de un documento está en la base de datos y no puedes actualizarla de forma selectiva.

Un versionado simple almacena los siguientes metadatos para cada chunk:

• source: De dónde viene el documento.
• version: Qué versión es. Puede ser un número, una fecha o un valor hash.
• updated_at: Cuándo se actualizó por última vez.

Así puedes consultar en cualquier momento qué versiones hay en la base de datos:

results = collection.get(
    where={"source": "handbuch.pdf"},
    include=["metadatas"]
)

for item in results["metadatas"]:
    print(item["version"], item["updated_at"])

Un versionado más avanzado utiliza valores hash. Calculas un hash del contenido del documento y lo almacenas. Cuando cambia el contenido, también cambia el hash. Así detectas cambios de forma confiable sin necesidad de comparar manualmente.

Automatización

La actualización manual funciona para bases de conocimiento pequeñas. Pero cuando tienes decenas o cientos de documentos, se vuelve tedioso. La automatización ayuda aquí.

Cron Jobs: Configura un job regular que revise tu carpeta de documentos. El job compara los archivos actuales con las versiones almacenadas y actualiza la base de datos si es necesario.

Watch Folder: Un script monitorea una carpeta en busca de cambios. Cuando se añade, modifica o elimina un archivo, la base de datos se actualiza automáticamente.

Un ejemplo simple de un cron job con Python:

import os
import hashlib
import chromadb

def datei_hash(pfad):
    with open(pfad, "rb") as f:
        return hashlib.md5(f.read()).hexdigest()

def aktualisiere_wissensbestand(ordner, collection):
    for dateiname in os.listdir(ordner):
        pfad = os.path.join(ordner, dateiname)
        if not os.path.isfile(pfad):
            continue

        hash_wert = datei_hash(pfad)

        # Pruefen, ob sich etwas geaendert hat
        bestehend = collection.get(
            where={"source": dateiname},
            include=["metadatas"]
        )

        if bestehend["metadatas"]:
            aktueller_hash = bestehend["metadatas"][0].get("hash")
            if aktueller_hash == hash_wert:
                continue  # Keine Aenderung

            # Alte Version loeschen
            collection.delete(where={"source": dateiname})

        # Neue Version hinzufuegen
        with open(pfad, "r", encoding="utf-8") as f:
            text = f.read()

        collection.add(
            documents=[text],
            metadatas=[{"source": dateiname, "hash": hash_wert, "version": hash_wert[:8]}],
            ids=[dateiname]
        )

client = chromadb.PersistentClient(path="./vectordb")
collection = client.get_or_create_collection("wissen")
aktualisiere_wissensbestand("./dokumente", collection)

Este script es un punto de partida. Para uso en producción deberías ampliarlo con manejo de errores, logging y un chunking apropiado.

Tropiezos habituales en la actualización

1. No guardar metadatos: Sin metadatos no puedes actualizar ni eliminar de forma selectiva. Tendrías que hacer un full rebuild. Almacena siempre al menos source y version.

2. No eliminar versiones antiguas: Si añades una nueva versión sin eliminar la antigua, tendrás duplicados con contenidos distintos. Esto lleva a respuestas contradictorias.

3. No detectar cambios: Sin un sistema para detectar cambios, actualizas demasiado a menudo (esfuerzo innecesario) o demasiado pocas (datos obsoletos). Los valores hash o números de versión resuelven este problema.

4. Cambiar modelo de embedding sin reconstruir: Si usas un modelo de embedding diferente, los vectores antiguos ya no son compatibles. Necesitas hacer un full rebuild, de lo contrario los resultados de búsqueda son inutilizables.

5. Cambiar chunking sin ajustar IDs: Si modificas tu procedimiento de chunking, también cambian los límites de chunks. Los IDs antiguos ya no coinciden con los nuevos. Elimina los chunks antiguos y añade los nuevos.

6. No hacer backup antes de actualizar: Si algo sale mal durante la actualización, tus datos pueden perderse. Haz un backup de la base de datos vectorial antes.

7. Escrituras simultáneas: Si varios procesos escriben en la base de datos al mismo tiempo, pueden surgir conflictos. Bloquea la base de datos durante la actualización o usa una cola.

8. Documentos olvidados en subcarpetas: Si tu script solo examina la carpeta principal, los documentos en subcarpetas quedan sin procesar. Asegúrate de buscar de forma recursiva.

Hardware, costos y seguridad al actualizar

Hardware: La actualización requiere principalmente potencia de cálculo para el embedding. Si actualizas muchos documentos a la vez, puedes saturar tu CPU o GPU. Con actualizaciones incrementales el esfuerzo es mínimo, ya que solo se re-incrustan pocos documentos. Un rebuild completo en colecciones grandes puede tardar varias horas.

Costos: Al ejecutar localmente no hay costos directos más allá de la electricidad y el desgaste del hardware. Si utilizas embeddings en la nube, cada llamada tiene un costo. Las actualizaciones incrementales son notablemente más económicas que un rebuild completo.

Seguridad: Todos tus datos permanecen en tu máquina mientras ejecutes el modelo de embedding y la base de datos vectorial de forma local. Esta es una de las grandes ventajas de la IA local. Asegúrate de que los backups estén cifrados, especialmente si contienen documentos sensibles.

Enlaces y recursos adicionales sobre actualización

• RAG local - Resumen de todos los artículos sobre RAG.
• Fundamentos de RAG - Cómo trabajan conjuntamente los componentes.
• Preparar documentos - Antes de actualizar, los documentos deben estar en buen estado.
• Chunking - La división afecta cómo actualizas.
• Modelos de embedding - Si cambias de modelo, debes reconstruir.
• Bases de datos vectoriales - La base de datos es tu almacenamiento.
• Probar calidad de RAG - Después de actualizar, debes verificar la calidad.

FAQ: Actualizar tu base de conocimiento - Preguntas frecuentes

¿Con qué frecuencia debo actualizar mi base de conocimiento?

Depende de qué tan seguido cambien tus documentos. Si el contenido varía diariamente, una actualización diaria tiene sentido. Para documentos estables, una actualización semanal o mensual es suficiente.

¿Rebuild completo o actualizaciones incrementales, qué es mejor?

Para bases de conocimiento pequeñas o cuando cambias el modelo de embedding o la estrategia de chunking, un rebuild completo es más simple. Para colecciones grandes que se mantienen continuamente, las actualizaciones incrementales son más eficientes.

¿Qué ocurre si no elimino los chunks antiguos?

La base de datos contendrá versiones antiguas y nuevas simultáneamente. El sistema RAG puede generar respuestas contradictorias porque no sabe cuál es la versión actual.

¿Cómo sé si un documento ha cambiado?

El método más simple es calcular un hash del contenido del archivo. Si el contenido cambia, el hash también cambia. Alternativamente, puedes usar números de versión o fechas de modificación del archivo.

¿Debo reiniciar la base de datos vectorial después de cada actualización?

No, la mayoría de las bases de datos vectoriales soportan actualizaciones mientras están en funcionamiento. Para rebuilds completos grandes, puede ser útil bloquear la base de datos brevemente para evitar conflictos.

¿Puedo automatizar la actualización?

Sí, con tareas cron o scripts que monitoreen una carpeta. Cuando hay cambios, la base de datos se actualiza automáticamente. Esto es recomendable para sistemas en producción.

¿Qué hago si cambio el modelo de embedding?

Debes realizar un rebuild completo. Los vectores antiguos no son compatibles con el nuevo modelo, ya que cada modelo genera vectores con significado y dimensión distintos.

¿Cómo manejo documentos eliminados?

Borra todos los chunks que pertenezcan al documento eliminado. Usa los metadatos para esto, típicamente el campo source, para encontrar y eliminar las entradas correspondientes.

¿Necesito un backup antes de actualizar?

Sí, definitivamente. Si algo sale mal durante la actualización, podrás restaurar el estado anterior. Especialmente con rebuilds completos, un backup es imprescindible.

¿Cómo verifico que la actualización fue exitosa?

Haz preguntas de prueba cuyas respuestas conoces y comprueba que el sistema proporciona la información actual. Encontrarás más detalles en el artículo Probar calidad de RAG.

¿Qué son los metadatos y por qué son importantes?

Los metadatos son información adicional sobre cada chunk, como origen, versión o fecha. Te permiten actualizar y eliminar de forma selectiva sin necesidad de reconstruir toda la base de datos.

Referencias y lectura adicional

• Documentación de Chroma: Collections y Metadata
• Documentación de Qdrant: Points y Filtering
• Documentación de LangChain: Document Loaders y Vector Stores
• Documentación de LlamaIndex: Index Management