RAG 6: de la evaluación a una operación reproducible
Qué prepararía para mantener el sistema cuando cambien documentos, permisos o modelos, y cuándo consideraría entrenarlo de nuevo.
En este artículo
Un notebook que encuentra evidencia hoy no demuestra que el sistema seguirá funcionando cuando cambie un archivo, se retire un permiso o se actualice un modelo. Después de una comparación experimental favorable, la siguiente tarea es transformar las decisiones en contratos verificables. Esta es una propuesta de ingeniería para el próximo ciclo; no una descripción de controles ya desplegados en Taesa.
Una versión del sistema contiene más que un modelo
Versionaría corpus, parser, reglas de segmentación, metadatos, prompt de enriquecimiento, embeddings, índice, recuperadores, reranker, generador y evaluación. Guardaría configuración y dependencias con cada resultado. Un cambio de embedding obliga a revisar compatibilidad y reconstrucción del índice; una corrección de permisos exige invalidar resultados y caches afectados. La ingestión debe ser idempotente: repetir un evento no duplica documentos.
Para actualizar el acervo construiría una versión candidata, comprobaría integridad y consultas de regresión, y solo entonces cambiaría la referencia al índice activo. Mantendría una versión recuperable para rollback. Las eliminaciones y revocaciones no pueden esperar indefinidamente al siguiente lote: necesitan una política de propagación verificable, incluida la capa de cache.
Pruebas que corresponden a fallos reales
Separaría pruebas del parser con documentos difíciles, validaciones del esquema, pruebas de integración de búsqueda y evaluación de respuestas. Incluiría referencias rotas, tablas sin encabezado, documentos duplicados, nuevas versiones y acceso revocado. Un documento recuperado es contenido no confiable: sus instrucciones no deben modificar permisos, ejecutar herramientas o sustituir la petición del usuario. Los escenarios de inyección forman parte de las pruebas del sistema.
Cada ejecución registraría los identificadores de documentos, la versión del índice, candidatos, puntuaciones, filtros y configuración, con retención y acceso acordes con la sensibilidad de los datos. No hace falta registrar indiscriminadamente preguntas y documentos completos. La observabilidad debe permitir localizar el fallo en el corpus, la extracción, la búsqueda o la generación sin crear otra colección confidencial sin control.
Cuándo entrenar y cuándo reparar el pipeline
No entrenaría para compensar una tabla perdida por el parser o un documento ausente. Si el modelo recibe la evidencia correcta y falla sistemáticamente en una tarea bien definida, entrenamiento supervisado puede ser una hipótesis. Un estudio de 2026 sobre preguntas multi-hop encontró ventajas diferentes para RAG, entrenamiento no supervisado y supervisado; este último logró la mejor exactitud en su comparación. Eso impide sostener que RAG siempre supera cualquier entrenamiento.
Comparación de inyección de conocimiento en preguntas multi-hop
SPA estudia generación de datos sintéticos para entrenamiento continuado. Su resultado no es una validación de índices contextualizados. Si probara datos sintéticos, controlaría diversidad, fidelidad y separación del test, y compararía con una alternativa simple. Los hechos que cambian y necesitan cita seguirían exigiendo una fuente recuperable y actualizada.
SPA: alcance del estudio de aumento sintético
Responsabilidades y criterio de entrega
El científico de datos lidera la definición del objetivo, la muestra, las métricas y el análisis de errores. Ingeniería de datos responde por ingestión, versiones, linaje y actualización. Ingeniería de software integra permisos, pruebas, despliegue y recuperación. Especialistas del dominio revisan evidencia y significado. Son responsabilidades compartidas con entregables concretos, no una transferencia del problema al modelo.
En el próximo ciclo quiero guardar el manifiesto del corpus, las preguntas revisadas y las configuraciones, junto con los rankings, errores e intervalos. También contaría qué cambios no ayudaron. Ese protocolo aún no se ha ejecutado; lo que presento aquí es el plan de pruebas.
El preprint AGO AI Quality Gate, de octubre de 2026, refuerza otra cautela: un juez puede producir JSON impecable y discriminar mal respuestas incorrectas. Sus estudios de juez y de promoción tienen alcances distintos, incluido un experimento con resultados sintéticos. La lección que incorporaría es calibrar al evaluador frente a referencias humanas, separar evidencia ausente de resultado malo y medir decisiones de promoción inseguras. No copiaría sus umbrales sin validación local.
AGO: validar al juez antes de promover una versión
Descargar scripts, manifiesto y documentación de la revisión