# Pendientes priorizados del RAG

**Ultima actualizacion:** 2026-09-08  
**Responsable de la priorizacion:** Usuario  
**Estado:** Activo

Este documento es la fuente canonica del orden de trabajo pendiente del modulo RAG. La numeracion ya refleja la prioridad final indicada por el usuario.

## 1. Documentacion y descubrimiento de la API

**Estado:** Completado y validado definitivamente en produccion el 2026-09-08.

- Implementar `/help` o una especificacion OpenAPI consultable.
- Actualizar documentos desfasados que todavia muestran como pendientes funciones ya desplegadas, como playground, logs y cleanup.
- Documentar los contratos, parametros, respuestas y errores reales de todos los endpoints.
- Mantener la documentacion alineada con produccion para que agentes e integradores no tengan que reconstruir el comportamiento desde el codigo.

## 2. Ciclo de vida del conocimiento

- Crear un catalogo de fuentes y versiones ingeridas.
- Saber que documento esta vigente, obsoleto, reemplazado o pendiente de reingesta.
- Evitar duplicados y permitir actualizaciones incrementales controladas.
- Registrar fecha de indexacion, modelo de embeddings, proveedor y version del contenido.
- Facilitar el reemplazo o rollback de una fuente sin depender de operaciones manuales dificiles de auditar.

## 3. OCR integrado en la ingesta

- Detectar PDFs con capturas, imagenes o una capa textual insuficiente.
- Ejecutar OCR automaticamente o bloquear la ingesta para revision cuando no pueda garantizarse la cobertura.
- Generar un documento intermedio auditable cuando sea necesario.
- Verificar el resultado antes de sustituir una fuente vigente.
- Evitar que se repita el problema detectado con el PDF de FacturaTech.

## 4. Mejora del retrieval

- Anadir busqueda hibrida semantica y textual para codigos exactos como `FAT07`, `504` o `SQLSTATE[23505]`.
- Mejorar el ranking usando coincidencias de codigo, regla, modulo y mensaje, no solo proximidad semantica.
- Crear un conjunto estable de consultas de evaluacion basado en casos reales.
- Medir precision, resultados irrelevantes y consultas ambiguas.
- Refinar retrieval y chunking con evidencia de uso, no mediante cambios generales sin medicion.

## 5. Seguridad de la API

- Anadir autenticacion para consumidores autorizados.
- Proteger especialmente uploads, cleanup y operaciones sobre logs.
- Aplicar rate limiting y limites de tamano o tipo de archivo.
- Revisar CORS, exposicion publica, registros sensibles y permisos por operacion.
- Sustituir la configuracion sin credenciales de n8n cuando exista el mecanismo de autenticacion definitivo.

## 6. Pruebas automatizadas

- Incorporar un framework y scripts de pruebas; actualmente el proyecto no tiene suite automatizada.
- Cubrir ingesta, parsing, chunking, scopes, cleanup y retrieval.
- Probar contratos y respuestas de error de la API.
- Anadir pruebas de regresion con consultas reales como las validadas para FacturaTech.
- Separar pruebas unitarias, de integracion y verificaciones opcionales contra servicios remotos.

## 7. Operacion y mantenimiento

- Resolver la colision de `sourceRef` al ingerir carpetas homonimas.
- Separar claramente configuracion versionable y secretos locales.
- Verificar y cerrar documentalmente la migracion del repositorio raiz de RAG y su despliegue en EasyPanel.
- Revisar copias temporales o backups asociados a la migracion antes de eliminarlos.
- Mantener un procedimiento fiable de despliegue, verificacion y rollback.

## 8. Sistema de evaluacion

- Revisar periodicamente los logs de evaluacion almacenados en Qdrant.
- Convertir incidencias reales en casos de prueba permanentes.
- Anadir metricas de recuperacion, calidad y contexto insuficiente.
- Mantener trazabilidad entre una incidencia, el cambio aplicado y la validacion posterior.
- Diferenciar claramente observacion manual, alerta automatica y regresion confirmada.

## 9. Capa MCP

- Exponer capacidades del RAG como tools MCP reutilizables.
- Definir inicialmente retrieval y consulta de fuentes; limitar operaciones destructivas.
- Mantener HTTP como API base y MCP como adaptador, evitando duplicar la logica del servicio.
- Definir autenticacion, contratos y permisos antes de exponer operaciones adicionales.

## 10. Modelo de `answer`

- Evaluar y sustituir `openai/gpt-4.1-mini` por el modelo definitivo de respuesta.
- Comparar calidad, coste, latencia y dependencia del proveedor.
- Mantener `answer` construido sobre `retrieve` y evitar un segundo camino de recuperacion.
- Considerar esta tarea despues de las anteriores; integraciones como WhatsApp ya pueden usar `/retrieve` y dejar la respuesta final a su propio agente.

## Regla de mantenimiento

- No cambiar este orden sin confirmacion del usuario.
- Al completar un punto, registrar evidencia y marcar su estado sin renumerar silenciosamente los demas.
- Las tareas detalladas pueden vivir en documentos independientes, pero este archivo conserva la prioridad global del modulo.