Spaces:
Running
Running
Commit History
-
Pruebas unitarias de los scripts de evals y target `make evals-unit`
Jose Salazar +1: Claude Opus 5Antes de la puerta, la puerta misma: métricas, rúbrica, umbrales y esquema del dataset son código sin cobertura de nadie más. Si el medidor está roto, el resultado de la puerta no significa nada —visto: el simulador dejaba `fuera_de_alcance` sin declarar y suspendía por su cuenta una métrica de tolerancia cero—. `evals/tests/` no necesita modelo, juez ni índice: son puras. Corren con el venv del backend porque los scripts importan `app.*`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>af530a3
-
Publicar el índice curado y evitar que el Hub acumule ficheros huérfanos
Jose Salazar +1: Claude Opus 5Al publicar el índice curado (6772 → 6201 fragmentos) aparecieron dos fallos en la ruta de publicación: - `upload_folder` no borraba lo que ya no existe en local. LanceDB versiona por ficheros, así que al compactar desaparecen los datos viejos y el remoto se los quedaba: el repo tenía 2 ficheros de datos y 2 índices FTS huérfanos, 73 MB para servir 33 MB — que además se hornean en la imagen. Ahora el remoto es un espejo del local (`delete_patterns="*"`). - `manifest.json` lo escribe la ingesta, pero `curar_indice.py` cambia el número de filas después. Publicaba un recuento desfasado sin romper nada visible, que es lo peligroso: el mensaje de commit del Hub y `fetch-index` anunciaban 6772 fragmentos sobre un índice de 6201. `curar_indice.py` lo reconcilia y `publish-index` aborta si no cuadra. Verificado descargando el índice publicado en limpio: 13 ficheros, 33 MB, los 51 tests de alcance en verde y la eval de recuperación en 0.814/0.941/0.912. Co-Authored-By: Claud…02b6489 -
Ajustes varios al engine y al prompt basado en resultados de los evals
Jose Salazarbf9f7d1
-
Distribución del corpus RAG vía Hub privado y horneado de modelos
Jose Salazar +1: Claude Opus 5Los libros con licencia (226 MB) y el índice LanceDB (70 MB) no pueden ir en git. Viven en dos datasets PRIVADOS del Hub; scripts/hub.py los publica y los descarga. Se usa la API de Python de huggingface_hub y no el CLI `hf`: en la versión instalada (1.16.1) el CLI devuelve código 1 aunque la operación vaya bien, por una incompatibilidad typer/click, lo que abortaría cualquier Makefile o build. Dockerfile: - WITH_RAG pasa a 1 por defecto. Con 0, el retriever degradaba en silencio y las interpretaciones salían sin fundamentar sin que nada lo indicara. - Los modelos (bge-m3 + bge-reranker-v2-m3, ~6.4 GB) se hornean en /opt/hf y se fija HF_HUB_OFFLINE=1 en runtime, para que un fallo de red sea ruidoso en vez de degradar la recuperación a orden RRF sin avisar. - Si instance/rag_index no está en el contexto de build, se descarga con HF_TOKEN pasado como secreto de build (nunca --build-arg, que quedaría grabado en el historial de capas). NOTA: el Dockerfile no se ha podido const…aa0d853