15 publicacionescon esta etiqueta
Probamos Qwopus, Qwen3.6 y Qwen3.8 con las mismas 42 preguntas del DOF. Qwen3.8 obtuvo más respuestas sustentadas en la revisión, pero también fue el más lento. Los errores muestran por qué una cita válida no basta y dónde conviene trabajar antes de abrir el piloto.
Once días de cómputo después, la corrida de embeddings terminó y corrimos la evaluación híbrida completa en los cortes v2 y v3 del set. La mejor configuración híbrida supera a cada componente por separado en ambos cortes — pero el peso ganador cambia de un corte al otro (W0.5 en v2, W0.75 en v3), y el mismo tipo de consulta (paráfrasis) favorece pesos opuestos según cómo fue construido el corte. El argumento del peso adaptativo ya no es una hipótesis: es una medición. El set curado v4 (42 preguntas multi-hop con evidencia anotada a mano) confirma el margen de la fusión y delimita dónde el ranking deja de ser el problema.
Cómo construimos una aplicación local para probar el agente con preguntas reales, transmitir su proceso verificable y guardar respuestas y feedback sin depender del índice vectorial.
Cómo construimos un bucle acotado de herramientas, convertimos las partes de una pregunta en requisitos verificables y evaluamos sus respuestas sobre el DOF.
Cómo separamos la búsqueda documental de la recuperación de pasajes y construimos cinco herramientas deterministas, trazables y evaluables sobre el DOF.
Construimos una evaluación manual de 42 preguntas para medir listas completas, vigencias, referencias jurídicas, consultas multidocumento, monitoreo y premisas falsas. La corrimos contra BM25 completo y un índice vectorial al 38.2% para fijar una línea base antes de terminar los embeddings.
Mientras la corrida de embeddings avanza sobre 6.7 millones de chunks, construimos el índice FTS5 del corpus completo (2.7 GiB) y corrimos la primera evaluación BM25 a escala real. La v2 del set produjo un MRR de 0.170; al corregir títulos falsos y consultas ambiguas, la v3 llegó a 0.366 y el smoke test híbrido parcial a 0.402. En el camino: un COUNT(*) que miente, 32 documentos casi invisibles para el índice, y una poda de tokens que convirtió 21 horas de consultas en 34 minutos sin alterar las métricas.
Construimos las bases de producción sobre los 657,867 documentos del DOF: el corpus comprimido completo ocupa 3.52 GiB, el índice de chunks guarda 6.73 millones de recetas de 91 bytes, y el piloto de vectores binarios confirma que el índice vectorial cabrá en menos de 1 GiB. En el camino: un GROUP BY que consumió 35 GB de disco, un documento que se convertía en 21 GB de chunks, y una lección sobre paridad de resultados.
Cuarta entrega del benchmark: construimos el corpus comprimido sobre 10,000 documentos reales. sqlite-zstd comprime 10.9x con acceso aleatorio, los chunks se guardan como recetas de 110 bytes en lugar de texto, el índice de búsqueda por palabras resultó 15x más chico de lo temido, y la cuantización TurboQuant empata en calidad con los vectores completos. Todo cabe en ~11 GB.
Tercera entrega del benchmark: fusionamos los rankings de BM25 y embeddings y el resultado supera a ambos por separado. También medimos cómo indexar el corpus completo desde la Mac M3: qué sirve (GGUF/Metal), qué no (batches grandes, fp16), y por qué la cuantización binaria de jina decide la arquitectura de almacenamiento.
Segunda ronda del benchmark: 499 documentos del corpus completo (1999-2026), 3,023 queries generadas con LLM en 6 tipos, baseline de BM25 con FTS5, y evaluación de late chunking para pplx-embed-context. BM25 y embeddings resultan complementarios por tipo de query.
Comparamos 10 modelos de embedding en velocidad, memoria y calidad de recuperación sobre documentos reales del DOF. Probamos cuantización int8, binaria y truncado Matryoshka. Los leaderboards públicos no predijeron al ganador.
Evaluamos 8 estrategias de chunking (5 de Chonkie, 2 pipelines, 1 custom) sobre 1,000 documentos del DOF. Ninguna opción de librería estándar respetaba tanto la estructura del documento como el límite de tokens.
Presentamos el chunker del RAG: un clasificador que detecta 5 patrones estructurales en los markdown del DOF antes de aplicar la estrategia de split correcta.
