El objetivo: medir una ruta real, no una demo

La pregunta no era si Talqora podía extraer texto de un PDF aislado. Queríamos saber cómo se comporta el pipeline completo cuando recibe una mezcla de Office, PDFs, currículums, imágenes, audio y formatos web provenientes de datasets públicos reales.

Por eso el corpus no fabrica bytes ni frases de prueba. Cada archivo conserva su URL de origen, licencia, tipo MIME, hash SHA-256 y una consulta tomada de su propio texto, caption o transcripción. La evaluación busca recuperar el archivo correcto usando esa evidencia, no un identificador artificial insertado para el test.

  • 1.000 archivos agregados desde fuentes públicas trazables
  • Subida presignada, jobs asíncronos, SQS/Lambda, extracción, embeddings e indexación en producción
  • Búsqueda híbrida real con top_k=10 y correlación mediante metadata source_file
  • Índice preservado para inspeccionar los resultados, en lugar de borrar la evidencia al final

Cómo compusimos el corpus

El corpus reunió datos de Apache POI para DOCX, XLSX y PPTX; currículums PDF de Hugging Face; artículos de arXiv; imágenes y captions de COCO; audio y transcripciones de LibriSpeech; datos tabulares de Vega; Markdown de tldr-pages; HTML y XML de web-platform-tests; y texto de Project Gutenberg.

Antes de enviar un Office file validamos su extracción con las mismas bibliotecas que usa el procesador: python-docx, openpyxl y python-pptx. También verificamos que los 1.000 paths existieran, que su SHA-256 coincidiera con el manifiesto y que ningún archivo tuviera una extracción desproporcionada para una sola tarea.

  • 80 DOCX, 204 XLSX y 40 PPTX
  • 89 PDFs, incluyendo 35 currículums
  • 100 imágenes y 50 audios
  • 437 archivos de texto y web: CSV, JSON, Markdown, HTML, XML y TXT

Qué medimos exactamente

Cada archivo generó un job durable. El runner esperó su estado terminal y verificó tanto el job como todas sus tareas; completed_with_warnings no cuenta como éxito. Para la recuperación, enviamos la consulta de evidencia a búsqueda híbrida y consideramos un acierto sólo cuando el resultado contenía el source_file esperado dentro de los primeros diez resultados.

Reportamos recall@10, la proporción de archivos recuperados dentro de esos diez resultados, y MRR@10, que penaliza acertar en posiciones bajas. Son métricas de recuperación, no una afirmación sobre la calidad de una respuesta generativa posterior.

  • 1.000/1.000 jobs completed y todas sus tareas completed
  • 0 jobs failed y 0 completed_with_warnings dentro del corpus principal
  • Recall@10 global: 87,8%
  • MRR@10 global: 73,94%

Resultados por formato

CSV, HTML, PPTX y XML alcanzaron 100% de recall@10. JSON llegó a 97,4%, currículums PDF a 97,1% y audio a 98%. Esto confirma que la ruta de extracción, transcripción, embeddings y recuperación funciona de forma consistente en formatos muy distintos.

Office y contenido visual también tuvieron resultados sólidos: DOCX alcanzó 92,5%, XLSX 91,7% e imágenes 92%. Los PDFs generales marcaron 85,2%. La diferencia no indica una falla de job: todos terminaron correctamente; muestra que algunas consultas compiten contra fragmentos similares de otros documentos.

  • Audio: 98,0% recall@10 · MRR@10 71,3%
  • DOCX: 92,5% · XLSX: 91,7% · imágenes: 92,0%
  • PDFs: 85,2% · currículums PDF: 97,1%
  • CSV, HTML, PPTX y XML: 100% recall@10

Dónde cae la recuperación y por qué importa

Los 122 misses se concentraron en Markdown: 73 de los 122, con 74,2% de recall@10. El segundo grupo fue TXT, con 75%. No se trata de archivos sin procesar: son colecciones con textos breves, plantillas, comandos y vocabulario muy repetido. En esos casos varias fuentes son semánticamente plausibles y la respuesta correcta puede caer fuera del top 10.

Esto es una señal útil. El benchmark no debe maquillarse removiendo ejemplos difíciles: debe orientar las decisiones de producto. Para casos con documentación breve y repetitiva, el ranking necesita más señales de estructura y una evaluación por familias de documentos, no sólo una búsqueda semántica general.

  • Markdown: 74,2% recall@10 · 52,2% MRR@10 · 73 misses
  • TXT: 75,0% recall@10 · 60,6% MRR@10 · 7 misses
  • XLSX: 17 misses; PDFs generales: 8; imágenes: 8
  • La correlación se hizo con source_file, no con nombres de dataset ni IDs inyectados

El edge case que encontramos: XLSX pequeños que explotan al extraerse

Dos hojas de cálculo públicas de Apache POI eran pequeñas en bytes comprimidos, pero se expandían a millones de caracteres al leerlas. El procesador actual trata un Office file como una sola tarea; esas fuentes quedaron reintentando por SQS en vez de emitir un estado terminal claro. Es un hallazgo de producción, no una simulación.

Las quitamos del gate principal de 1.000 para que la evaluación de recuperación mida archivos dentro del presupuesto de una tarea, pero no las descartamos como problema. Deben permanecer como una suite de estrés separada y bloquearse de forma explícita hasta que la implementación tenga límites y una transición terminal confiable.

  • Agregar límite de caracteres extraídos y de chunks por archivo Office
  • Partir hojas o páginas grandes en work units independientes
  • Convertir desbordes de presupuesto en un error terminal explicable, no en reintentos indefinidos
  • Registrar tamaño comprimido, texto extraído, chunks y motivo de rechazo en el detalle del job

Qué vamos a mejorar después de este benchmark

La primera prioridad es endurecer la ruta Office frente a expansiones de contenido. La segunda es mejorar la recuperación de documentación repetitiva: chunking consciente de encabezados y comandos, señales de path y título, deduplicación de fragmentos cercanos y una fusión híbrida calibrada por familia de formato.

También vamos a conservar este manifiesto como un benchmark reproducible. Cada cambio de extractor, modelo de embedding, estrategia de chunking o fusión debe compararse contra el mismo conjunto, con resultados por formato y no sólo una métrica global. Mejorar un promedio mientras empeoran archivos de clientes no es una mejora real.

  • Suite de estrés para Office con límites terminales
  • Mejor chunking y señales estructurales para Markdown y TXT
  • Evaluación desagregada por formato, corpus y posición
  • Regresión de procesamiento y retrieval antes de cambios de producción

La conclusión

El procesamiento de archivos pasó la prueba más importante: 1.000 fuentes públicas heterogéneas atravesaron la ruta desplegada sin fallos de job. La recuperación híbrida es fuerte en formatos estructurados y multimodales, con 87,8% de recall@10 global, pero el benchmark revela margen concreto para mejorar contenido repetitivo y documentos Office extremos.

Ese es el propósito de publicar el resultado completo: hacer visibles tanto la capacidad actual como los límites que todavía hay que resolver. Un sistema de retrieval confiable no promete perfección; conserva evidencia, mide sus errores y usa esa evidencia para mejorar.