diff --git a/docs/CONTEXTO_PROYECTO.md b/docs/CONTEXTO_PROYECTO.md index 9184ec1..373d370 100644 --- a/docs/CONTEXTO_PROYECTO.md +++ b/docs/CONTEXTO_PROYECTO.md @@ -37,5 +37,5 @@ Servicio RAG para ingesta, versionado y recuperacion de conocimiento. Incluye un - `rag-service` es el unico proyecto Engram canonico; la sesion debe iniciarse desde la raiz de este worktree. - RAG y OCR `0.2.1` estan desplegados y verificados conjuntamente. El OCR queda aceptado para esta fase como servicio best-effort autonomo; la mejora de precision y la consola humana son evoluciones futuras no bloqueantes. -- El scheduler durable y la validacion productiva hibrida estan completados. Los defectos de rechazo blank y purga OCR quedaron corregidos y validados localmente; la unidad esta autorizada para commit/push y el usuario realizara el despliegue posterior. -- FacturaTech v8 fue rechazada sin aprobarse, indexarse ni activarse. Tras el despliegue corregido se purgaran las candidatas descartadas y se verificara que v1 sigue activa. +- El scheduler durable, la validacion productiva hibrida y la correccion de rechazo blank/purga OCR estan desplegados y verificados en `0.2.1` revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`. +- Las dos candidatas sinteticas y FacturaTech v2-v8 estan `purged`; no quedan candidatas bloqueantes. FacturaTech v1 `3fc78163-9cfb-4979-985c-1520a63327b0` sigue activa con `36/36` puntos. diff --git a/docs/HISTORIAL_SESIONES.md b/docs/HISTORIAL_SESIONES.md index 6c98264..75f94c3 100644 --- a/docs/HISTORIAL_SESIONES.md +++ b/docs/HISTORIAL_SESIONES.md @@ -10,6 +10,16 @@ ## Registro de sesion +### 2026-09-25 - Agente RAG 3 - Cierre productivo de limpieza OCR +**Agent:** Agente RAG 3 · **Model:** openai/gpt-5.6-sol · **Session:** `ses_f358ccfe9ffeEzEVNuKo93aHyH` +**Role:** Desarrollo, mantenimiento y continuidad del servicio RAG y su integracion con el servicio OCR reutilizable. +**Work:** En VPS2 PRODUCCION se verifico el despliegue conjunto `0.2.1` revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`. Se rechazo la candidata sintetica blank usando su hash vigente y se purgaron secuencialmente las dos candidatas sinteticas y FacturaTech v3-v8; FacturaTech v2 ya estaba purgada. No se aprobo, indexo ni activo ninguna candidata. +**Validation:** RAG confirma PostgreSQL, Qdrant y reconciliador sanos; OCR esta ready, con worker/sweeper operativos y cola vacia. Las etiquetas OCI de ambos contenedores coinciden con la revision. Las ocho purgas devolvieron `200`, todas las versiones descartadas quedaron `purged`, sus ocho directorios duraderos no existen y PostgreSQL no conserva estados `review_required`, `purging`, `ocr_queued`, `ocr_running` ni `indexing`. FacturaTech v1 `3fc78163-9cfb-4979-985c-1520a63327b0` sigue activa con `36/36` puntos. +**Next:** Mantener como paquete posterior no bloqueante la recuperacion automatica de la ventana post-borrado/pre-CAS y la alineacion del contrato historico de retencion. Decidir por separado si una nueva ingesta del PDF original aporta valor. +**Files:** `docs/OPERATIVA.md`, `docs/PENDIENTES_RAG.md`, `docs/SISTEMA_RAG_BASE.md`, `docs/CONTEXTO_PROYECTO.md`, `docs/HISTORIAL_SESIONES.md`. + +--- + ### 2026-09-25 - Agente RAG 3 - Publicacion de correccion de limpieza OCR **Agent:** Agente RAG 3 · **Model:** openai/gpt-5.6-sol · **Session:** `ses_f358ccfe9ffeEzEVNuKo93aHyH` **Role:** Desarrollo, mantenimiento y continuidad del servicio RAG y su integracion con el servicio OCR reutilizable. diff --git a/docs/OPERATIVA.md b/docs/OPERATIVA.md index dce8656..edd16ab 100644 --- a/docs/OPERATIVA.md +++ b/docs/OPERATIVA.md @@ -1,8 +1,8 @@ # Operativa del servicio RAG **Modulo:** RAG -**Ultima actualizacion:** 2026-09-24 -**Version:** 1.7 +**Ultima actualizacion:** 2026-09-25 +**Version:** 1.8 --- @@ -12,9 +12,9 @@ Este documento registra los hechos operativos del servicio RAG: la configuracion - Preflight R5 de solo lectura (2026-09-23): el contenedor RAG usa la base `db_rag` con el rol `usr_rag`. `rag_schema_migrations` contiene `001_knowledge_lifecycle.sql`, `002_ocr_review.sql` y `003_ocr_recovery_audit.sql`, todos con checksums coincidentes con el commit publicado; la unica migracion pendiente es `004_ocr_quality_diagnostics.sql`. - Despliegue R5 verificado (2026-09-23): RAG y OCR exponen `version=0.2.1` y `revision=0654ce5`; sus etiquetas OCI coinciden. Digests: RAG `sha256:9a22730406c09c6b773891d8953f451e6263bf9fb0033188f4479f0b93ec8bbf`, OCR `sha256:6725991d3893a4f16ae6c75f28e9dd59b051bdbc344b28d79f1292224ddceda1`. `004_ocr_quality_diagnostics.sql` esta aplicada; OCR esta `live/ready`, con cola vacia, worker/sweeper operativos y almacenamiento disponible; RAG confirma PostgreSQL, Qdrant y reconciliador sanos. -- Despliegue vigente verificado (2026-09-24): RAG y OCR exponen `version=0.2.1` y `revision=bfb2d48`; sus etiquetas OCI coinciden, las migraciones `001-004` conservan sus checksums y PostgreSQL, Qdrant, reconciliador, OCR, cola y almacenamiento estan sanos. +- Despliegue vigente verificado (2026-09-25): RAG y OCR exponen `version=0.2.1` y `revision=960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`; sus etiquetas OCI coinciden y PostgreSQL, Qdrant, reconciliador, OCR, cola y almacenamiento estan sanos. - Candidata R5 historica: FacturaTech v8 `f4fd1502-1d4d-454f-bbfb-4c3b6820ee97` completo 25/25 paginas OCR y su revision visual, pero el 2026-09-24 fue rechazada por decision del usuario sin aprobarse, indexarse ni activarse. La version activa `3fc78163-9cfb-4979-985c-1520a63327b0` sigue intacta. -- Limpieza pendiente: la candidata sintetica blank `6011a4eb-3e42-4ea4-a7da-a3e930cc60ed` permanece `review_required` y la sintetica valida `c4646668-30e4-409e-800d-23a8ee465a42` permanece `purging`. Los dos defectos que bloqueaban rechazo y purga estan corregidos y validados localmente; no reintentar la limpieza productiva hasta que el usuario despliegue la correccion. +- Limpieza completada (2026-09-25): la candidata sintetica blank fue rechazada y las dos candidatas sinteticas quedaron `purged`; FacturaTech v2-v8 tambien estan `purged`. No quedan versiones en `review_required`, `purging`, `ocr_queued`, `ocr_running` ni `indexing`. Los ocho directorios duraderos descartados fueron eliminados. - Diagnostico de precision (2026-09-24): los PNG productivos verificados de las paginas 8, 15 y 16 muestran los ceros correctos, mientras `ocr-result.json` ya contiene las tres confusiones `o/0` con confianza alta y la candidata las conserva sin cambios. Se descartan renderizado, reconstruccion y RAG como origen. El OCR queda aceptado para esta fase como servicio best-effort autonomo; la mejora de precision, la consola humana y un posible revisor visual por IA quedan diferidos. Esta aceptacion no aprueba ni activa v8. - `KNOWLEDGE_LIFECYCLE_ENFORCED=true`: el ciclo de vida del conocimiento esta activo; no queda pendiente ninguna activacion. - `OCR_INGEST_ENABLED=true`: la ingesta OCR esta habilitada en el RAG desplegado. @@ -24,11 +24,11 @@ Este documento registra los hechos operativos del servicio RAG: la configuracion - Volumen transitorio del OCR en `/data/jobs`: cola SQLite y trabajos en curso. - La respuesta publica sin token de una ruta OCR protegida es `401`, lo que confirma que el proceso desplegado tiene OCR habilitado. Con OCR deshabilitado, la misma ruta responderia `404` antes de autenticar. - El estado mostrado en EasyPanel debe contrastarse con su entorno persistido y con el entorno del contenedor en ejecucion; anteriormente la UI mostro valores distintos por variables duplicadas y desfasadas. -- `GET /health` del RAG confirma PostgreSQL, Qdrant y reconciliador sanos. OCR responde internamente `live=ok` y `ready=true`, con cola vacia, worker/sweeper operativos y version/revision `0.2.1`/`bfb2d48`. +- `GET /health` del RAG confirma PostgreSQL, Qdrant y reconciliador sanos. OCR responde internamente `live=ok` y `ready=true`, con cola vacia, worker/sweeper operativos y version/revision `0.2.1`/`960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`. - La migracion `003_ocr_recovery_audit.sql` esta aplicada y su tabla de auditoria existe. - Las rutas autenticadas de revision y recuperacion devuelven errores estructurados y seguros para una candidata inexistente: `404`, `OCR_CANDIDATE_NOT_FOUND` y accion `verify_version_id`. - La candidata OCR heredada de FacturaTech v4 fue cerrada como `failed` el 2026-09-20 mediante recuperacion administrativa auditada tras confirmar `OCR_ARTIFACT_UNAVAILABLE`. No fue indexada ni activada; la fuente conserva su version activa y no tiene candidatas OCR bloqueantes. -- Las imagenes en ejecucion tienen ambas etiquetas OCI `org.opencontainers.image.revision=bfb2d48`: EasyPanel recibe `BUILD_REVISION` durante el build. La identidad se verifica mediante las etiquetas y el health; los digests registrados de entregas anteriores son evidencia historica, no la identidad de la revision vigente. +- Las imagenes en ejecucion tienen ambas etiquetas OCI `org.opencontainers.image.revision=960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`: EasyPanel recibe `BUILD_REVISION` durante el build. La identidad se verifica mediante las etiquetas y el health; los digests registrados de entregas anteriores son evidencia historica, no la identidad de la revision vigente. ## Version de despliegue diff --git a/docs/PENDIENTES_RAG.md b/docs/PENDIENTES_RAG.md index c99b413..705d383 100644 --- a/docs/PENDIENTES_RAG.md +++ b/docs/PENDIENTES_RAG.md @@ -35,7 +35,7 @@ La prioridad actual es publicar y desplegar la correccion de rechazo/purga OCR, ### Fase 3. Hardening OCR y aceptacion de FacturaTech -**Estado:** `0.2.1` revision `bfb2d48` desplegada y verificada conjuntamente en produccion. v8 completo la aceptacion no activa, pero fue rechazada por decision del usuario sin aprobarse, indexarse ni activarse; FacturaTech v1 sigue activa. +**Estado:** `0.2.1` revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae` desplegada y verificada conjuntamente en produccion. Las candidatas descartadas quedaron purgadas y FacturaTech v1 sigue activa. La candidata v5 `5f2317c6-7a8a-4e08-a614-f8189602ebb8` completo 25/25 paginas OCR, pero fallo despues cuando RAG solicito 25 imagenes de revision en paralelo. El rerender concurrente provoco un `SIGSEGV` de PDFium/FreeType, salida `139` y reinicio del contenedor; no hubo OOM. La candidata quedo fallida y la version activa no cambio. @@ -153,7 +153,7 @@ Validacion completada: suite Node `121/121`, suite OCR `26/26`, regresiones del - [x] Preparar una unidad versionada para el scheduler durable y la operacion autonoma, revisar el diff y registrar codigo, pruebas, contrato, operativa y rollback. - [x] Solicitar y recibir autorizacion para commit/push. El despliegue conserva una autorizacion explicita posterior y separada. -- [x] Publicar y desplegar RAG/OCR juntos segun la regla operativa vigente, con OCR habilitado y version, revision y etiquetas coincidentes. La revision `bfb2d48` quedo desplegada el 2026-09-24. +- [x] Publicar y desplegar RAG/OCR juntos segun la regla operativa vigente, con OCR habilitado y version, revision y etiquetas coincidentes. El scheduler se desplego en `bfb2d48` y la correccion final de limpieza en `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae` el 2026-09-25. - [x] Verificar migraciones esperadas, health, scheduler rapido, reconciliador de cinco minutos, cola OCR, almacenamiento, PostgreSQL y Qdrant. La validacion productiva conjunta paso y la version activa permanecio intacta. ##### G. Validacion productiva sin activar contenido @@ -170,19 +170,19 @@ Validacion completada: suite Node `121/121`, suite OCR `26/26`, regresiones del - [x] Corregir la purga de versiones OCR para eliminar de forma transaccional las filas hijas de `rag_review_corrections`, `rag_document_pages` y `rag_ocr_jobs` antes de `rag_version_documents`, respetando las claves foraneas y la reanudacion desde `purging`. - [x] Eliminar idempotentemente los artefactos duraderos de la version antes de completar `purging -> purged`, evitando directorios huerfanos marcados como `retention_deleted`. - [x] Anadir pruebas de regresion para ambos defectos y ejecutar la bateria local completa. Las regresiones finales `47/47`, Node `124/124`, OCR `26/26`, typecheck, build y builds Docker RAG/OCR pasan. -- [ ] Publicar la correccion autorizada mediante commit/push y desplegar conjuntamente RAG/OCR con la nueva `BUILD_REVISION`. -- [ ] Tras el despliegue por el usuario, rechazar y purgar la candidata sintetica blank `6011a4eb-3e42-4ea4-a7da-a3e930cc60ed`, completar la purga de la sintetica valida `c4646668-30e4-409e-800d-23a8ee465a42` y purgar FacturaTech v3-v8. -- [ ] Verificar al terminar que no quedan candidatas OCR de prueba utiles o bloqueadas y que FacturaTech v1 conserva el puntero activo. +- [x] Publicar la correccion autorizada mediante commit/push y desplegar conjuntamente RAG/OCR con `BUILD_REVISION=960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`. +- [x] Rechazar y purgar la candidata sintetica blank `6011a4eb-3e42-4ea4-a7da-a3e930cc60ed`, completar la purga de la sintetica valida `c4646668-30e4-409e-800d-23a8ee465a42` y purgar FacturaTech v3-v8. +- [x] Verificar que no quedan candidatas OCR de prueba utiles o bloqueadas y que FacturaTech v1 conserva el puntero activo con `36/36` puntos. Los estados finales son 7 versiones activas y 9 purgadas; no hay estados intermedios. - [ ] Decidir por separado, solo si aporta valor, si se realiza una nueva ingesta del PDF original de FacturaTech con el sistema ya validado. **Paquete posterior no bloqueante:** implementar recuperacion automatica si la purga se interrumpe despues de eliminar artefactos y antes del CAS `purging -> purged`, y alinear el contrato historico de retencion con el comportamiento real. La operacion actual es recuperable repitiendo `DELETE`; este paquete no requiere ampliar ahora la bateria de pruebas ni bloquea la publicacion. ##### I. Criterio de servicio completamente operativo -- [ ] Confirmar en produccion que el PDF controlado hibrido no envia las paginas nativas, envia solo las visuales y compone un documento unico sin duplicar texto dentro de una pagina. -- [ ] Confirmar que las limitaciones de precision conocidas quedan trazables, el scheduler corto funciona tras reinicio, los leases evitan dobles procesamientos y el reconciliador recupera fallos residuales. -- [ ] Confirmar health, observabilidad, almacenamiento, cola, PostgreSQL, Qdrant, revision no activa y rollback documentado sin incidencias abiertas de severidad bloqueante. -- [ ] Declarar cerrado el trabajo tecnico solo cuando toda la evidencia anterior este registrada. Este cierre significa que el servicio RAG-OCR esta funcionando completamente y que las candidatas descartadas quedaron limpias; no implica una nueva ingesta de FacturaTech. +- [x] Confirmar en produccion que el PDF controlado hibrido no envia las paginas nativas, envia solo las visuales y compone un documento unico sin duplicar texto dentro de una pagina. +- [x] Confirmar que las limitaciones de precision conocidas quedan trazables, el scheduler corto funciona tras reinicio, los leases evitan dobles procesamientos y el reconciliador recupera fallos residuales. +- [x] Confirmar health, observabilidad, almacenamiento, cola, PostgreSQL, Qdrant, revision no activa y rollback documentado sin incidencias abiertas de severidad bloqueante. +- [x] Declarar cerrado el trabajo tecnico con la evidencia registrada. RAG-OCR funciona completamente y las candidatas descartadas quedaron limpias; esto no implica una nueva ingesta de FacturaTech. Las advertencias `LOW_P10_CONFIDENCE` de las paginas 2, 20 y 21 no son un defecto de comunicacion ni un bloqueo pendiente de codigo. Son senales de revision. Las confusiones puntuales `o/0` de las paginas 8, 15 y 16 son una limitacion aceptada del reconocimiento best-effort y, si aparece una futura candidata, deben corregirse explicitamente durante su revision, nunca mediante una autocorreccion silenciosa. Una futura consola podra incorporar revision humana y un revisor visual por IA podra proponer correcciones con imagen y contexto; ambos quedan fuera de esta fase. @@ -196,7 +196,7 @@ Si aparece un fallo real cuyos sintomas justifiquen aislar servicios, valorar en El SDD `ocr-ingest-integration` se archiva con 29/30 tareas completas y 7.4 incompleta. La continuidad del hardening y de la aceptacion se controla mediante el contrato ODD canónico, sin declarar retrospectivamente superada la aceptacion fallida. -**Salida anterior:** `0.2.1` supero los criterios del anexo y FacturaTech alcanzo `review_required` con evidencia completa. v8 fue rechazada posteriormente por decision del usuario; el bloque A-I solo se cierra al desplegar la correccion de limpieza, purgar las candidatas descartadas y verificar que v1 sigue activa. +**Salida actual:** `0.2.1` revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae` supero el cierre A-I. Las candidatas descartadas estan purgadas, no quedan estados bloqueantes y FacturaTech v1 sigue activa con `36/36` puntos. Una nueva ingesta del PDF original sigue siendo una decision opcional separada. ## 1. Documentacion y descubrimiento de la API diff --git a/docs/SISTEMA_RAG_BASE.md b/docs/SISTEMA_RAG_BASE.md index 81feac6..8523839 100644 --- a/docs/SISTEMA_RAG_BASE.md +++ b/docs/SISTEMA_RAG_BASE.md @@ -2,9 +2,9 @@ **Proyecto:** Workspace de tools IA para empresas **Modulo:** RAG -**Ultima actualizacion:** 2026-09-24 +**Ultima actualizacion:** 2026-09-25 **Ultima modificacion por:** Agente RAG 3 -**Estado:** RAG y OCR `0.2.1` revision `bfb2d48` desplegados; v8 rechazada y correccion de limpieza OCR validada localmente pendiente de despliegue +**Estado:** RAG y OCR `0.2.1` revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae` desplegados y verificados; candidatas descartadas purgadas y FacturaTech v1 activa --- @@ -281,7 +281,7 @@ La revision puede proponer correcciones exactas por linea. Aprobarla genera un a ### Comportamiento desplegado -Este comportamiento esta publicado y desplegado en la revision `bfb2d48`. +Este comportamiento se publico en `bfb2d48` y permanece desplegado en la revision vigente `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`. Al aceptar una ingesta OCR, RAG intenta despacharla inmediatamente. Si OCR sigue en `queued` o `running`, el dispatcher guarda `next_attempt_at` con un backoff entre 2 y 15 segundos. @@ -340,12 +340,12 @@ En documentos hibridos, `imageUrl` es `null` para paginas nativas y solo referen ## Estado productivo verificado -- RAG y OCR `0.2.1` estan desplegados desde la revision `bfb2d48`. +- RAG y OCR `0.2.1` estan desplegados desde la revision `960e04a5a9fc3a3ef108fa4ef19d5ff42dbdb1ae`. - PostgreSQL, Qdrant, OCR y reconciliador estan sanos. - FacturaTech v8 completo OCR y revision, pero fue rechazada sin aprobar, indexar ni activar; v1 sigue activa. - Una prueba productiva sintetica demostro el flujo hibrido: pagina 1 nativa, pagina 2 OCR y `review_required` en menos de 18 segundos, sin activacion y con cola final vacia. -- La limpieza de versiones OCR descubrio dos defectos en la decision de paginas blank y el orden de purga. Ambos estan corregidos y validados localmente. -- Produccion conserva una candidata sintetica en `review_required` y otra en `purging`; no se reintenta su limpieza hasta desplegar la correccion. +- La limpieza de versiones OCR descubrio dos defectos en la decision de paginas blank y el orden de purga. Ambos estan corregidos y verificados en produccion. +- Las dos candidatas sinteticas y FacturaTech v2-v8 estan `purged`; sus directorios duraderos descartados fueron eliminados. No quedan estados bloqueantes y v1 conserva `36/36` puntos. ## Fuentes de detalle