rag-service/docs/PENDIENTES_RAG.md

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

Diseño: Contrato de implementacion cerrado en CONTRATO_CICLO_VIDA_Y_OCR.md. Pendiente de implementar y validar en produccion antes de iniciar el punto 3.

• 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

Diseño: Contrato de implementacion cerrado en CONTRATO_CICLO_VIDA_Y_OCR.md. Su ejecucion queda bloqueada hasta completar el punto 2.

• 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.
• Actualizar Express/qs para cerrar los avisos moderados pendientes de npm audit.

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.