Capítulo 11 — Actualizaciones continuas y optimización de la pipeline

Undécima y última entrega del recorrido capítulo por capítulo de LLM Primer III: Enhancing Enterprise AI with RAG. En el que la pipeline nunca está terminada — los documentos cambian, las consultas se desplazan, los modelos se intercambian — y el equipo que la mantiene aprende a pensar en tres escalas de tiempo a la vez.

Por qué existe este capítulo

Un sistema RAG no está terminado cuando se lanza. Los documentos cambian, las consultas derivan, el propio modelo se reemplaza cada pocos meses. La pipeline de la que un equipo está orgulloso en marzo está, en septiembre, recuperando contra embeddings rancios producidos por un modelo de hace dos generaciones, sirviendo un modelo base que se intercambió en silencio y respondiendo a una distribución de preguntas que ha derivado de maneras que nadie cartografió. Este capítulo trata sobre la ingeniería de mantenerse al día — detectar qué cambió en el corpus, mantener el índice fresco sin reconstruirlo, evitar que la latencia se vaya arrastrando hacia arriba y cerrar el bucle entre la telemetría de producción y los cambios que el equipo realmente hace.

11.1 Change Data Capture e indexación incremental

El primer instinto de cada equipo que lanza un sistema RAG es programar una reconstrucción nocturna del índice. Funciona. Es también la respuesta equivocada a largo plazo. Una reconstrucción nocturna quema llamadas a la API de embeddings sobre documentos que no cambiaron, deja el índice hasta veinticuatro horas rancio y deja de caber en la ventana nocturna a medida que el corpus crece. El patrón maduro es la indexación incremental impulsada por Change Data Capture — la pipeline reacciona a eventos de aguas arriba en lugar de hacer polling.

Importan tres tipos de evento. Insertar: un documento nuevo, parseado, troceado, embebido, indexado. Actualizar: un documento existente cambió; reembebe los chunks afectados. Borrar: un documento eliminado; expulsa los vectores correspondientes antes de que puedan volver a aparecer en resultados — un requisito duro bajo GDPR, CCPA y el resto. El mecanismo que hace esto tratable es el hash de contenido. En la primera ingesta, guarda SHA-256 sobre el texto normalizado del chunk junto al embedding. En la actualización, vuelve a trocear, calcula hash y compara: los chunks que no cambiaron se quedan, los nuevos se embeben, los viejos se van. Una edición de párrafo se convierte en una sola llamada de embedding, no en mil. La factura de embeddings escala con la actividad editorial, no con el corpus.

El problema más duro es el orden y la consistencia. Los eventos llegan fuera de orden; un borrado puede adelantarse a la actualización a la que debería haber seguido. El remedio estándar son versiones monótonas por documento, con escrituras condicionales: aplica un evento sólo si su versión supera la versión en fichero. Esto hace la pipeline idempotente — un evento duplicado no puede corromper el índice — lo cual no es una optimización sino un requisito de corrección a escala. Los contextos de cumplimiento añaden lápidas: un borrado lógico que tiene efecto en tiempo de consulta antes de que el borrado físico se complete de forma asíncrona, para que la eliminación se honre de inmediato.

11.2 Gestionar la latencia: caché semántica y estratificación de modelos

Una llamada aumentada por recuperación acumula latencia en cada salto. La defensa es hacer menos trabajo cuando se demuestra innecesario, y dos técnicas cargan con la mayor parte de ese peso. Una caché convencional almacena respuestas indexadas por texto exacto de consulta y acierta en una fracción evanescente del tráfico real. La caché semántica indexa por significado: embebe cada consulta entrante, busca en una pequeña caché de consultas recientes, devuelve la respuesta cacheada si la similitud coseno con la entrada más cercana supera un umbral. "¿Cuál es nuestra política de devoluciones?" y "¿cómo funcionan las devoluciones?" no comparten ninguna coincidencia de cadenas y comparten toda la respuesta.

Las tres elecciones que importan son el umbral de similitud (0,93-0,97 coseno para embeddings generales, ajustado contra tráfico apartado), el time-to-live (idealmente atado a los chunks contribuyentes — invalidar cuando alguno se reembeba) y el alcance (particionado por inquilino, por rol de acceso, por cualquier cosa que pudiera filtrar la respuesta de un usuario a otro). Los despliegues en producción reportan tasas de acierto del 30-60% con decenas de milisegundos en los aciertos frente a respuestas no cacheadas de varios segundos, con ahorros de coste proporcionales, ya que los aciertos de caché saltan tanto el embedding como la generación.

La estratificación de modelos maneja las consultas que sí tienen que usar el modelo y no deberían usar el mayor disponible. Dos o tres niveles: un modelo pequeño rápido y barato para el grueso, otro mayor para consultas en las que el pequeño no es lo bastante confiable, opcionalmente un tercero para la cola larga. El router es donde los despliegues en producción se equivocan en la primera pasada. La versión más simple usa señales del lado de la consulta (factual corta frente a analítica). Una versión mejor usa señales del lado de la recuperación (similitud alta y consistente significa que el modelo pequeño basta). La más sofisticada corre el modelo pequeño primero y escala según una confianza calibrada — preciso en el margen, pagando una inferencia extra en los escalados. Los números a vigilar son la tasa de escalado y la tasa de arrepentimiento juntas; cualquiera por sí solo engaña.

11.3 El bucle continuo de feedback

Una pipeline RAG emite telemetría constante. La mayoría de los equipos la recoge; muy pocos cierran el bucle sobre ella. El bucle tiene cuatro etapas. Recoger: cada consulta, recuperación, generación, cita e interacción del usuario registrada con un esquema estable y un identificador de consulta estable que hile a través de cada etapa — sin ese identificador, diagnosticar una regresión degenera en adivinación. Evaluar: la tríada de los Capítulos 9 y 10 corrida en dos modos, muestreada offline contra un conjunto de referencia para precisión, y proxies de comportamiento online (regenerar, copiar, follow-up, abandono) para cobertura. Ninguno es suficiente solo. Juntos triangulan.

Decidir es la etapa más difícil, porque la misma señal implica varios remedios distintos. Una caída en la Relevancia del Contexto puede significar que el corpus se está dejando temas fuera, o que el reranker se ha degradado, o que el modelo de embedding ya no encaja con el nuevo vocabulario. Distinguir requiere rebanar las métricas — por tema, por edad del documento, por versión de embedding, por inquilino — y el equipo que sólo vigila el agregado descubrirá, un trimestre tarde, que una rebanada lleva tirando del promedio hacia abajo todo el tiempo.

Aplicar viene en tres pesos. Cambios de configuración — top-k, pesos del reranker, alfa híbrido, umbral de caché, regla de escalado — A/B-testeados en horas, revertidos en minutos, varios corriendo a la vez. Acciones de reindexación — reembedder un tema rancio, ingerir una fuente nueva, expulsar documentos obsoletos — semanales a bajo demanda, sobre una réplica no de producción antes de promocionar. Cambios de modelo — intercambiar el modelo de embedding, intercambiar el modelo base, reentrenar un reranker personalizado — trimestrales, con despliegue en sombra, evaluación paralela, cambio gradual de tráfico y opción de rollback. La disciplina está en la cadencia, no en ningún cambio individual. Un canal pequeño de etiquetado humano — quizá cien ejemplos por semana de la cola de proxies ambiguos — mantiene calibrados a los jueces LLM y evita que el bucle optimice contra sus propios proxies.

Lo que prepara el Volumen III

Empezamos tratando la generación aumentada por recuperación como la respuesta de ingeniería a dos problemas que los modelos de lenguaje puros no pueden resolver: conocimiento fresco y procedencia verificable. Trazamos la arquitectura desde el patrón temprano embed-retrieve-stuff hasta los sistemas modulares y agénticos hoy en producción, e hicimos el trabajo cuidadoso en cada componente del camino — los parsers que recuperan estructura de los PDFs, los chunkers que deciden qué es una unidad de significado, las bases de datos vectoriales que almacenan el resultado, los retrievers híbridos y los rerankers que encuentran lo que importa, los controles de acceso y las capas de anonimización que mantienen honesto al sistema, los frameworks de evaluación que nos dicen si algo de esto funciona y, ahora, los mecanismos de actualización continua que lo mantienen vivo.

RAG no es una categoría de producto. Es una disciplina de ingeniería compuesta de tal vez una docena de sub-disciplinas, cada una de las cuales puede ser la diferencia entre un sistema que funciona y otro que alucina en silencio. Un equipo que se tome en serio cada sub-disciplina producirá algo que aguante tráfico real. Un equipo que trate cualquiera de ellas como caja negra producirá algo que no.

La serie continúa en LLM Primer IV — Diseñando la cognición de la IA con MCP. Donde el Volumen III iba de traer el conocimiento correcto al modelo, el Volumen IV va de traer las manos correctas — el Model Context Protocol, los agentes que lo blanden, las herramientas que llaman y la memoria que acumulan. La misma sensibilidad arquitectónica, una cara distinta del mismo problema. El trabajo continúa.