92 lines
4.9 KiB
Markdown
92 lines
4.9 KiB
Markdown
# 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:** Implementado; pendiente de publicacion y validacion en produccion.
|
|
|
|
- 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.
|