Hacemos consultable la memoria normativa de México.
Documentamos cómo convertir el Diario Oficial de la Federación en un corpus estructurado, verificable y útil para sistemas de recuperación con inteligencia artificial.
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.
Probamos Gemini 2.5 Flash Lite con el prompt v3 en 100 imágenes aleatorias del Diario Oficial de la Federación. Cero errores, 2.3s promedio por imagen, y un estimado de $41 USD para procesar las ~97,000 imágenes del corpus completo.
Segunda iteración del experimento: cambiamos el prompt, ajustamos las imágenes de prueba y reemplazamos Qwen por Grok y Gemma. Comparamos 6 modelos en 14 imágenes del Diario Oficial de la Federación.
Comparamos 6 modelos de visión (Gemini, GPT, Qwen, Claude) en la tarea de generar descripciones de imágenes para indexación RAG del Diario Oficial de la Federación.
Del archivo WORD descargado al Markdown estructurado listo para embeddings: un recorrido por nuestro pipeline de procesamiento completo que incluye conversión con LibreOffice, filtros LUA personalizados, análisis de imágenes con Gemini y arquitectura de directorios robusta.
Cómo la realidad del procesamiento masivo de documentos nos llevó a replantear nuestra estrategia: de descargar PDFs completos a obtener archivos WORD segmentados, reduciendo dramáticamente el costo computacional sin sacrificar calidad.
Análisis detallado de las proyecciones de almacenamiento para el proyecto DOF-RAG, evaluando diferentes dimensiones de embeddings y sus implicaciones de escalabilidad para un horizonte de 25 años.
Un análisis comparativo entre tres modelos de embeddings (Nomic Embed, Gemini, Jina) evaluando velocidad, calidad y estabilidad en búsqueda vectorial para documentos oficiales mexicanos.
Un análisis de los desafíos encontrados durante la integración de los modelos de IA de Google en el proyecto DOF RAG, el manejo de librerías en evolución y la resolución de problemas con las APIs.
