Ejecutar un piloto RAG con fuentes

El proyecto final no consiste en demostrar que un modelo puede conversar con PDFs. Consiste en comprobar, sobre un dominio delimitado, que el sistema recupera información autorizada, conserva condiciones, cita evidencia, se abstiene cuando corresponde y puede operarse sin depender de explicaciones informales del equipo que lo construyó.

Congela el alcance del piloto

Selecciona:

• usuarios;
• fuentes;
• tipos de pregunta;
• permisos;
• volumen;
• riesgos;
• métricas;
• periodo de prueba.

No amplíes el corpus cada vez que una pregunta falla. Registra el fallo y decide si entra en una siguiente versión. Si cambias simultáneamente corpus, chunking, modelo y prompt, perderás capacidad de saber qué mejoró.

Entrega una arquitectura reproducible

Documenta el flujo:

fuente → ingestión → fragmentación → metadatos/permisos → índice → consulta → recuperación → reranking → contexto → generación → citas → usuario

Para cada componente indica:

• responsabilidad;
• entradas;
• salidas;
• estado;
• errores;
• métricas;
• mecanismo de actualización;
• propietario.

El piloto debe poder ser entendido por otra persona sin depender del autor original.

Ejecuta primero en modo de sombra

En una fase de sombra el sistema responde y se evalúa, pero no sustituye la fuente o el proceso habitual. Puedes comparar la salida con cómo resuelven los usuarios reales.

Esto permite recopilar fallos sin convertirlos inmediatamente en decisiones operativas.

Después puedes pasar a un modo asistido donde la persona consulta la respuesta y verifica las fuentes antes de usarla. Solo si el caso, el riesgo y la evidencia lo justifican aumentas dependencia del sistema.

Evalúa antes, durante y después

Usa el conjunto versionado para comprobar:

• cobertura del corpus;
• retrieval;
• groundedness;
• completitud;
• citas;
• abstención;
• permisos;
• latencia;
• coste;
• utilidad.

Añade preguntas reales observadas durante el piloto, pero sepáralas de la prueba que utilizaste para ajustar la configuración.

Mantén una regresión estable para detectar deterioro.

Define criterios de avance y parada

Ejemplos de condiciones de avance:

• ninguna filtración de permisos en el conjunto crítico;
• recuperación mínima acordada para preguntas de alto riesgo;
• citas verificables;
• abstención correcta en preguntas sin evidencia;
• carga humana compatible con el proceso;
• latencia y coste dentro de límites.

No copies estas condiciones como umbrales universales. Debes fijar cifras y tolerancias según el caso.

También define criterios de parada: incidente de acceso, fuente crítica obsoleta, degradación relevante o incapacidad de diagnosticar errores.

Incluye operación y retirada

El entregable final debe contener:

1. catálogo de fuentes;
2. política de permisos;
3. pipeline de ingestión;
4. estrategia de chunking;
5. esquema de metadatos;
6. recuperación y reranking;
7. contrato de respuesta;
8. citas y abstención;
9. controles de seguridad;
10. conjunto de evaluación;
11. dashboard o métricas;
12. runbook;
13. propietarios;
14. procedimiento de actualización;
15. rollback o modo degradado.

Un sistema sin mecanismo de retirada no está terminado. Debe ser posible desactivar una fuente, un índice o la generación sin perder control del servicio.

Ejemplo de piloto: procedimientos internos

El alcance son procedimientos aprobados de operaciones para dos productos. Los usuarios son un grupo de soporte. Se excluyen borradores y documentos de otras áreas.

El piloto empieza con cien preguntas históricas revisadas. En sombra se comparan respuestas y fuentes. Los fallos se clasifican por corpus, recuperación, generación y permisos. Tras corregir y repetir regresión, se habilita uso asistido.

Si un usuario pregunta por una política no incluida, el sistema se abstiene y enlaza el canal de consulta. Si cambia un permiso, una prueba automática confirma que el documento deja de recuperarse para el grupo afectado.

Mantén una matriz de decisiones del piloto

Al terminar cada iteración registra:

• hallazgo;
• evidencia;
• riesgo;
• cambio propuesto;
• versión afectada;
• resultado de la nueva prueba;
• decisión.

Así evitas que el piloto se convierta en una sucesión de ajustes no documentados.

Una decisión puede ser técnica —cambiar chunking—, de gobierno —retirar una fuente— o de alcance —excluir una familia de preguntas—. Todas afectan al resultado y deben quedar trazadas.

Prueba la retirada antes de considerar terminado el piloto

Realiza una prueba completa:

1. selecciona una fuente activa;
2. retírala o revoca un permiso en el entorno de prueba;
3. ejecuta sincronización;
4. verifica índice y cachés;
5. repite preguntas relacionadas;
6. comprueba que no aparece en contexto ni citas;
7. registra el tiempo total de propagación.

Esta prueba demuestra una capacidad que las demos suelen ignorar: dejar de saber algo cuando la organización decide que ya no debe estar disponible.

Ejercicio final: dossier de decisión

Entrega un dossier con:

• problema;
• alcance;
• usuarios;
• corpus;
• arquitectura;
• amenazas;
• benchmark;
• resultados;
• fallos;
• costes;
• latencia;
• carga de revisión;
• limitaciones;
• criterios de avance;
• plan de operación;
• decisión recomendada.

La decisión no debe ser necesariamente «desplegar». Puede ser ampliar el benchmark, restringir el alcance, mejorar gobierno documental, cambiar recuperación o detener el proyecto.

Cierre del curso

RAG no es una base vectorial con un modelo conectado. Es un sistema de conocimiento donde la calidad depende de fuentes, autoridad, permisos, representación, recuperación, generación, evaluación y operación.

El resultado profesional del curso es poder diseñar ese sistema de extremo a extremo y demostrar con evidencia qué sabe hacer, qué no sabe hacer, qué puede mostrar a cada usuario y cómo detectar cuando deja de funcionar como se esperaba.