Docling sigue apareciendo junto a los web scrapers, pero no lo es. Es un kit de conversión de documentos creado por IBM Research —ahora un proyecto de LF AI & Data Foundation— que toma archivos que ya tienes (PDF, DOCX, PPTX, XLSX, HTML e imágenes) y los transforma en Markdown o JSON. Su propio lema lo dice literalmente: "Prepare your documents for gen AI."
Así que esta es una reseña práctica de un conversor, no de un crawler. Todo lo que verás abajo se midió en una máquina de un solo CPU (macOS arm64, Python 3.14.2, Docling 2.111.0), con resultados obtenidos por scripts y los fallos registrados como fallos. El repositorio es enorme y cambia a diario —63,069 estrellas, 4,449 forks y un push el mismo día en que descargué los metadatos— así que toma cualquier cifra de errores o versión aquí como una foto del momento, no como una constante.
Qué es realmente Docling (y qué no es)
La unidad central de todo en Docling es DoclingDocument: parseas un archivo en esa estructura y luego lo exportas a Markdown, HTML, DocTags o JSON sin pérdida. El código tiene licencia MIT (las licencias de los modelos varían), nació en IBM Research Zurich y, al momento de escribir esto, la última versión era la v2.112.0, publicada dos días antes de esta prueba.
La capacidad principal está en el flujo de PDF e imágenes. Y ese flujo no se basa en leer cadenas de texto: usa una pila de modelos de machine learning, entre ellos un modelo de layout RT-DETR, el modelo de estructura de tablas TableFormer, un modelo opcional visión-lenguaje y RapidOCR para escaneos. Esos modelos reconstruyen el diseño de página, el orden de lectura y la estructura de tablas. Esa es la parte que vale la pena revisar, y la que una prueba solo con HTML jamás vería.
Hay una distinción que ahorra una semana de confusión: Docling no obtiene nada por sí mismo. No renderiza JavaScript, no rompe barreras anti-bot, no rastrea sitios. Tú aportas el archivo; él aporta la comprensión. El rastreo es trabajo de otra herramienta, y eso importa más adelante cuando la gente pregunta si Docling reemplaza a Firecrawl (no lo hace; se complementan, y ahora explico por qué).
La primera ejecución que nadie te advierte
pip install docling se instala sin problemas en Python 3.14.2. Luego miras el entorno virtual y pesa 1.3 GB. Docling descarga toda la pila de ML como dependencia obligatoria incluso si solo vas a convertir un archivo HTML:
| Dependencia | Tamaño en disco (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ modelos incluidos) | 75.6 |
| docling_parse | 30 |
Y eso antes de convertir un solo PDF. La primera conversión de PDF es donde aparece la fricción real, porque ahí es cuando se descargan los modelos. En una caché de HuggingFace limpia y recién creada, la primera conversión de PDF tardó ~224 segundos —y casi todo fue descarga, no cómputo. Los modelos de layout y TableFormer ocupan ~506 MiB en disco (342 MiB de TableFormer + 164 MiB de layout, verificado con du), y RapidOCR descarga ~40 MB de pesos PP-OCRv4 dentro de site-packages. ¿La segunda conversión del mismo archivo? 0.55 segundos. Los modelos quedan en caché; el peaje se paga una sola vez.
Un número que debes ignorar: el script de arranque en frío imprime model_download_mb como 1060.2. No cites eso como huella real. Proviene de un os.walk que sigue symlinks, y la caché de HuggingFace guarda cada archivo del modelo una sola vez en blobs/ y luego lo expone de nuevo mediante symlinks en snapshots/; por eso el recorrido cuenta 14 archivos dos veces. La cifra correcta, equivalente a du y sin duplicados por symlink, es ~506 MiB (solo blobs: 505.4 MiB). La conclusión para quien quiera medir Docling: informa los bytes descargados y los bytes en disco como dos cifras distintas, porque no son lo mismo.
Hay otra trampa que afecta a quien intenta construir un contenedor de Docling. Los pesos se reparten en dos ubicaciones y con dos calendarios distintos. Los modelos de layout y TableFormer respetan HF_HOME y se descargan en la primera conversión de PDF. Los modelos de RapidOCR no: terminan en …/site-packages/rapidocr/models/, ignorando por completo tu configuración de caché. Si vas a preparar una imagen de antemano o trabajar sin conexión, tienes que gestionar ambas cachés, y por mucho que definas HF_HOME no vas a atrapar la segunda.
Dicho eso, también hay que ser justo. Desde versiones anteriores, el proyecto lanzó docling-slim, un núcleo de ~50 MB que te permite hacer pip install docling-slim[format-html] para HTML sin arrastrar torch. Así que el peso de 1.3 GB es real para el metapaquete docling por defecto, pero ahora es opcional. Yo probé el paquete estándar porque sigue siendo lo que obtienes con pip install docling, pero ese peso no es un defecto sin resolver: la solución modular existe y está registrada en el issue #2393.
Durante la configuración me topé con un pequeño fastidio que vale la pena señalar: import docling; docling.__version__ lanza AttributeError: module 'docling' has no attribute '__version__'. El módulo simplemente no lo expone. La forma correcta de consultarlo es importlib.metadata.version("docling"), que devuelve '2.111.0'. Es una molestia menor de DX, abierta upstream desde julio de 2026 como issue #3733.
Fidelidad de tablas: donde TableFormer realmente se gana su lugar
Las tablas son la razón por la que alguien elige Docling antes que un volcado simple de PDF a texto, así que generé siete PDFs con tablas y verdad de referencia legible por máquina, y puntué el resultado celda por celda. Hay dos métricas importantes, y no son lo mismo: cell recall es la proporción de valores de referencia que aparecen en alguna parte de la tabla detectada; in-row rate es la proporción que cae en la fila correcta. Mezclarlas favorece demasiado a la herramienta, así que aquí van ambas:
| Tabla (estrés) | Detectada | Cell recall | In-row rate | Nota |
|---|---|---|---|---|
| T1 cuadrícula simple con bordes (5×8), sola en la página | No | 0.0 | — | clasificada como <!-- image -->, se perdieron todas las celdas |
| T2 sin bordes (solo una regla en el encabezado) | Sí | 1.00 | 1.00 | perfecta, cuadrícula exacta |
| T3 encabezado combinado de 2 niveles con colspan | Sí | 1.00 | 0.97 | todos los valores aparecen; un valor del encabezado cae en otra fila |
| T4 etiqueta de fila con rowspan combinada, sola en la página | No | 0.0 | — | clasificada como <!-- image --> |
| T5 encabezado con colspan + sin bordes | Sí | 1.00 | 0.97 | todos los valores aparecen; el mismo desplazamiento de fila que en T3 |
| T6 estados financieros, columna vacía, alineada a la derecha | Sí | 1.00 | 1.00 | la columna vacía se preserva, no se desplaza |
| T7 cuadrícula ancha de 12 columnas | Sí | 1.00 | 1.00 | no hubo desplazamiento de columnas en una tabla ancha |
En las cinco tablas que Docling sí detectó, todos los valores de referencia llegaron: cell recall 1.00 en todos los casos. En tres de esas cinco, además, cada valor quedó en su fila correcta. En los dos casos con encabezados multinivel (T3 y T5), un valor del encabezado se desliza fuera de su fila original, bajando el in-row a 0.97; es decir, los datos están, pero la asignación de fila tiembla un poco cuando hay encabezados apilados.
Los casos estructurales difíciles aguantaron mejor de lo que esperaba. El encabezado de dos niveles con colspan se aplanó correctamente en Markdown estilo GitHub (la etiqueta "Q1 2026" se repitió sobre sus dos columnas abarcadas, que es la forma correcta de convertir un colspan a GFM). La cuadrícula sin bordes con solo una regla de encabezado (T2) salió exacta. La tabla ancha de 12 columnas (T7) no se desplazó. Y una columna financiera completamente vacía (T6) se preservó como celdas vacías en lugar de desaparecer o fusionarse. Eso coincide con las puntuaciones oficiales de TableFormer TEDS —95.4 en simples, 90.1 en complejas, 93.6 en todas las tablas— que en la tarjeta del modelo superan claramente a Camelot (73.0) y EDD (88.3).
Conviene ser prudente con las celdas combinadas, porque existe un issue abierto que dice lo contrario. El issue #3698 informa que V1 y V2 manejan mal filas y columnas combinadas. En mis fixtures, los colspan simples (T3/T5) y los rowspan se aplanaron bien, salvo el desplazamiento de fila de los encabezados multinivel ya mencionado. Pero los casos que falla #3698 son combinaciones irregulares de varias filas/columnas y tablas de varias páginas, es decir, el extremo patológico. Los míos son el extremo simple. Así que la afirmación correcta debe ser precisa: aquí se recuperaron correctamente colspan y rowspan simples (aunque los encabezados multinivel pueden desplazar una fila); las combinaciones complejas e irregulares siguen siendo un problema documentado y abierto. No "las celdas combinadas funcionan", ni "las celdas combinadas están rotas".
La trampa: una tabla sola en una página puede desaparecer
Vuelve a mirar la tabla: T1 y T4 no se detectaron en absoluto. Docling emitió <!-- image --> y eliminó todas las celdas, sin error. T1 es una cuadrícula normal con bordes de 5×8. Eso es lo bastante serio como para que yo no lo llamara debilidad del análisis de tablas hasta aislar qué lo provocaba realmente, así que monté una prueba A/B automatizada.
Primero descarté las explicaciones obvias. La capa de texto está intacta: pypdfium2 lee 327 caracteres en T1 y 221 en T4, así que son PDFs digitales reales, no imágenes escaneadas. Desactivar OCR (do_ocr=False) no ayuda; las tablas siguen desapareciendo. Y al inspeccionar DoclingDocument directamente, len(doc.tables) == 0 mientras len(doc.pictures) == 1: el modelo de layout había clasificado toda la región de la tabla como una Picture.
Luego vino la prueba decisiva. Volví a renderizar las mismas tablas T1 y T4, pero esta vez rodeadas por unos cuantos párrafos normales, y las convertí de nuevo. Ambas aparecieron perfectamente: len(doc.tables) == 1, se emitieron tablas GFM correctas y la etiqueta de rowspan "North" de T4b se repitió bien a lo largo de sus tres filas. La misma tabla. Lo único que cambió fue si estaba sola en una página escasa o integrada dentro de texto.
Así que la advertencia real no es que TableFormer sea frágil, sino que el modelo de layout RT-DETR de Docling usa el contexto de la página, y una tabla pequeña aislada en una página casi vacía puede leerse como una imagen y descartarse en silencio. Esto es fácil de encontrar en la práctica, porque así se ven facturas, fichas técnicas y exportaciones recortadas: una tabla por página, sin prosa alrededor. La solución es simple y efectiva: dale contexto de página al modelo de layout o revisa doc.tables después de convertir y marca las páginas cuyo conteo sea cero. Esto se parece a el issue #3495 (una tabla detectada como Table y Picture a la vez), pero el disparador específico por escasez de página —la misma tabla se pierde aislada y se convierte cuando está embebida— no lo encontré publicado en ningún lado. Medido, no documentado antes; no es un bug que nadie conociera.
OCR en escaneos reales: RapidOCR, no EasyOCR
Los PDF escaneados son el lugar donde muchos conversores fallan en silencio, así que alimenté a Docling con dos escaneos reales con una capa de texto de 0 caracteres medida: pypdfium2 reporta cero caracteres recuperables, confirmando que cualquier salida es OCR y no una capa de texto oculta.
El archivo de una sola página ocr_test.pdf salió limpio en 14.3 segundos en CPU: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," recuperado literalmente. El PDF de cuatro páginas nemotron_multipage.pdf activó OCR en las cuatro páginas en 70.1 segundos en total (17.5 s/página), emitiendo la frase de prueba repetida en cada página. El OCR por defecto se activó automáticamente, sin bandera ni configuración.
Aquí está el detalle que muchos artículos se equivocan al mencionar: el motor OCR por defecto es RapidOCR, no EasyOCR. Lo confirmé viendo cómo se descargaban los pesos .pth de PP-OCRv4 en la primera ejecución. Muchos blogs y textos antiguos de preguntas frecuentes de Docling aún dicen que EasyOCR es el valor por defecto; eso quedó obsoleto. EasyOCR ahora es un extra opcional. Lo que sigue siendo cierto: el OCR es la ruta lenta a escala, y todo esto es un techo medido en CPU; con GPU los tiempos bajarían de forma considerable.
PDF reales, orden de lectura y tiempo por página
Los fixtures sintéticos prueban comportamientos concretos; los PDF reales prueban que la cosa funciona de verdad. Ejecuté dos papers académicos nacidos digitales —el informe técnico de Docling de 9 páginas y "Attention Is All You Need" de 15 páginas—, ambos a dos columnas, con tablas y fórmulas.
En el paper de 15 páginas de Attention, los cinco marcadores de sección —Abstract, Introduction, Background, Conclusion, References— aparecen en el orden del documento en el Markdown linealizado, pese al diseño a dos columnas. Cada punto de comprobación de contenido (Transformer, encoder, BLEU, multi-head) está presente, y las famosas tablas de resultados multicola se registran como cuatro tablas detectadas. Eso es recuperación real del orden de lectura y de la fusión de columnas, que es la propuesta de valor central para el chunking en RAG: no puedes dividir un documento de forma sensata si el linealizador convierte una página a dos columnas en un caos entrelazado.
El tiempo revela una lección contraintuitiva: el tiempo por página depende de cuánta estructura tiene cada página, no del número de páginas. El informe de 9 páginas, más denso, corrió a 14.95 segundos por página, más lento por página que el paper de 15 páginas, que fue de 5.99 segundos por página, porque incluye más tablas y figuras, y cada una dispara más inferencia de layout y de TableFormer. Así que los "segundos por página" en CPU dependen de la densidad estructural, no de la longitud. Esta es una ejecución única en CPU; es un techo, no una cifra de producción.
Multi-formato y la promesa de JSON sin pérdida
Docling anuncia un análisis unificado para varios formatos, así que generé un DOCX, un XLSX y un PPTX con contenido conocido y puntos de referencia, y luego comprobé dos cosas: si los puntos aparecen en Markdown y si sobreviven al ida y vuelta de JSON mediante export_to_dict().
| Archivo | Conversión s | Puntos encontrados en MD | Tablas en MD | Puntos sobreviven en JSON |
|---|---|---|---|---|
report.docx (encabezados + tabla fusionada "Total" + viñetas) | 0.137 | 7/7 | 1 | Sí |
workbook.xlsx (2 hojas, columna vacía) | 0.016 | 6/6 | 2 | Sí |
deck.pptx (3 diapositivas, viñetas + tabla) | 0.038 | 6/6 | 1 | Sí |
Todos los puntos de contenido llegaron al Markdown, las tablas se recuperaron (incluida la fila fusionada "Total" del DOCX y las dos hojas del XLSX), y cada punto también sobrevivió al JSON de export_to_dict(). Eso es la evidencia que importa para la afirmación de DoclingDocument sin pérdida, al menos con entradas limpias. Estos formatos pasan por backends nativos de cada formato, no por los modelos de ML, por eso se procesan en decenas de milisegundos y funcionan totalmente sin conexión. El alcance es honesto: un archivo limpio por formato demuestra amplitud, no una prueba de estrés con archivos Office patológicos.
HTML: fiel, pero no limpio
Este es el punto que decide si Docling encaja o no en tu pipeline de RAG, así que léelo con atención. Docling convierte el documento HTML completo. No hace extracción del contenido principal al estilo de Readability. Cuantifiqué cuánto ruido de interfaz de sitio sobreviene contando líneas de navegación, índice, cookies y pie de página en la propia salida de Docling.
| Página | Líneas MD no vacías | Líneas de boilerplate | % de boilerplate | La nota empieza en la línea |
|---|---|---|---|---|
| Wikipedia "Web scraping" | 255 | 34 | 13.3% | 28 |
| scrapethissite/forms | 63 | 1 | 1.6% | — |
| books.toscrape | 65 | 0 | 0.0% | — |
| quotes.toscrape | 35 | 0 | 0.0% | — |
En una página cargada de chrome como Wikipedia, ~13% de las líneas de Markdown son navegación/índice/pie de página, y el artículo real no empieza hasta la línea 28. La salida se abre con "move to sidebar / Contents / Toggle the table of contents" y cierra con "CS1 maint… / Search Wikipedia." En páginas limpias de contenido (books, quotes) el ruido es ~0%, así que esto es un problema de chrome de plantilla, no un peaje por página. Docling te entrega Markdown fiel del documento completo, no extracción limpia del artículo principal. Upstream registra el problema del mobiliario HTML en el issue #1865 (cerrado) y #1930 (abierto).
Hay dos cosas que hacen esta crítica justa. Primero, en HTML Docling no ejecuta ningún modelo de ML: usa un backend de BeautifulSoup en una tubería simple. La historia de "modelos de visión leyendo tu página" solo aplica a PDF e imágenes; si le das HTML a Docling, no se activa ni la maquinaria de layout ni TableFormer. Segundo, la ruta de PDF sí intenta clasificar encabezados y pies de página, así que decir "no elimina nada de boilerplate" sería demasiado fuerte; es el backend HTML, específicamente, el que devuelve el chrome.
Cómo se compara (y dónde encaja Thunderbit)
Prueba Thunderbit para extraer datos web
La herramienta con la que más comparan Docling es Firecrawl, así que aquí va una tabla de posicionamiento. Un matiz importante desde el principio: esta es una comparación a nivel de documentación, no un benchmark en la misma máquina. Yo no ejecuté Firecrawl en estos fixtures. Solo la columna de Docling está medida aquí; la de Firecrawl proviene de su documentación pública.
| Eje | Firecrawl (según su documentación) | Docling (medido aquí) |
|---|---|---|
| Trabajo principal | Rastrear y extraer la web en vivo → Markdown | Convertir un documento que ya tienes → Markdown/JSON |
| Fetching / renderizado JS / anti-bot | Sí (navegador alojado) | No: tú suministras el archivo |
| Extracción del contenido principal | Sí | No: documento completo fiel (~13% de chrome en Wikipedia) |
| Estructura de tablas en PDF (ML) | limitado | Sí: TableFormer (TEDS oficial 93.6; cell recall 1.00, in-row 0.97–1.00 en los fixtures detectados) |
| PDF escaneado / OCR | limitado | Sí: RapidOCR por defecto (recuperó un escaneo con capa de texto 0) |
| Amplitud de formatos | páginas web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/imágenes |
| Despliegue | API alojada (+ autoalojado) | biblioteca local pip, offline, sin API key |
| Peso de configuración | API key / cliente ligero | instalación por defecto de 1.3 GB + ~506 MiB de modelos (o docling-slim) |
| Licencia | comercial / código disponible | MIT |
La versión corta: Firecrawl es la herramienta cuando tus datos están en la web viva y necesitas rastreo, renderizado JS y limpieza del contenido principal. Docling es la herramienta cuando ya tienes el documento —sobre todo PDF, escaneos y archivos Office con muchas tablas— y quieres una conversión fiel, offline y preservando estructura, con comprensión real de tablas y OCR. Se complementan. Un pipeline realista rastrea con una y convierte documentos con la otra.
Y aquí voy a ser directo con Thunderbit, ya que trabajo aquí y sería normal que sospecharas si fingiera otra cosa. Thunderbit y Docling no hacen lo mismo, y no voy a forzar una equivalencia. Para desarrolladores, Thunderbit es una API de scraping con IA, más servidor MCP y CLI; su unidad de trabajo es la página web en vivo: POST /distill convierte una URL en Markdown limpio listo para LLM (gestionando el renderizado JS, anti-bot y CAPTCHA que Docling no toca explícitamente), y POST /extract devuelve JSON estructurado que coincide con el esquema que definas mediante JSON Schema. Ese es el extremo de captura y limpieza de un pipeline RAG. Docling es el extremo de documentos locales: el PDF, el escaneo, la hoja de cálculo que ya está en tu disco. Si tu corpus son páginas web, usa la API de Thunderbit, sus herramientas MCP (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) o la CLI (npx @thunderbit/thunderbit-cli). Si son PDF y escaneos, usa Docling. Si son ambos —que es lo habitual en los pipelines reales—, se combinan, y ninguno pretende ser el otro.
Veredicto: provisional, con tarea pendiente
No te voy a dar una puntuación única de 0 a 100, porque un total ponderado aquí metería penalizaciones por cosas que Docling nunca prometió hacer (como rastrear la web) y fingiría que son comparables. Por dimensión, en los fixtures que probé:
- Configuración / primera ejecución: pesada — entorno virtual de 1.3 GB, ~506 MiB de modelos, ~224 s en el primer PDF, ~0.55 s en caliente — pero
docling-slimte deja evitar ese peso. - Fidelidad de tablas: fuerte cuando la tabla se detecta (cell recall 1.00 en 5/5, in-row 0.97–1.00), en línea con la historia oficial de TEDS en estos fixtures.
- Robustez de detección de tablas: la trampa de página escasa: una tabla aislada puede desaparecer como Picture. Revisa
doc.tablesdespués. - Escaneos / OCR: funciona, RapidOCR por defecto; lento a gran escala.
- Multi-formato: sólido, con el ida y vuelta de JSON intacto.
- HTML: fiel, no limpio; no hace extracción del contenido principal.
- Experiencia de desarrollador: API limpia de 3 líneas y un
DoclingDocumentordenado, salvo por la falta de__version__.
Para quién sirve: equipos que construyen RAG o pipelines de datos sobre PDF, escaneos y archivos Office, y que quieren conversión offline, preservación de estructura y comprensión real de tablas y OCR. Para quién no sirve: quien necesita rastreo de la web en vivo o extracción limpia del artículo principal en HTML; eso es otra herramienta.
Y como esto es una reseña y no un comunicado de prensa, los límites quedan visibles. Esta es una prueba focalizada —7 tablas sintéticas y 2 PDF reales en una sola máquina con CPU—, no un benchmark de exactitud a escala TEDS. Hay varias cosas que no probé y que deberías revisar antes de apostar un pipeline a Docling: la ruta opcional VLM (GraniteDocling), la huella real de docling-slim, cualquier ejecución en GPU, las celdas combinadas complejas e irregulares y las tablas de varias páginas, la fidelidad de fórmulas a LaTeX, y —lo que probablemente más te sorprenda en producción— el trío de durabilidad compuesto por crecimiento de memoria por lotes, escalado con threads/GIL y ciclo de vida de objetos a lo largo de miles de conversiones. Docling es fuerte en lo que dice hacer, más medido que mercadeado, y tiene bordes reales que conviene mapear antes de confiarle un corpus. Conoce la advertencia de páginas escasas, presupuesta la descarga inicial y verifica por tu cuenta el comportamiento a escala.
Prueba Thunderbit para extraer datos web Get Started Free
Preguntas frecuentes
¿Docling es un web scraper o un crawler? No. Docling convierte documentos que ya tienes —PDF, DOCX, PPTX, XLSX, HTML e imágenes— en Markdown o JSON. No obtiene URLs, no renderiza JavaScript ni maneja anti-bot. Rastrear la web en vivo es tarea de herramientas distintas como Firecrawl o la API web de Thunderbit; Docling parte del archivo que tú le das.
¿Qué tamaño tiene la instalación de Docling y cuánto descarga en la primera ejecución?
El metapaquete docling por defecto genera un entorno virtual de ~1.3 GB porque arrastra toda la pila de ML como dependencia obligatoria (solo torch ocupa 536 MiB). La primera conversión de PDF descarga ~506 MiB de modelos de layout y TableFormer al disco, más ~40 MB de pesos RapidOCR, y tarda unos 224 segundos —casi todo en descargas. La segunda conversión tarda ~0.55 segundos. Si solo necesitas formatos ligeros, docling-slim (~50 MB de núcleo) evita la ruta pesada.
¿Docling hace OCR y con qué motor? Sí. En un PDF escaneado sin capa de texto, el OCR de Docling se activa automáticamente y recuperó el contenido con limpieza en mi prueba. El motor por defecto es RapidOCR, no EasyOCR: un error muy común en textos antiguos. EasyOCR ahora es un extra opcional. El OCR es la ruta lenta a escala, especialmente en CPU.
¿Por qué Docling convirtió mi tabla en una imagen o la eliminó?
Lo más probable es el efecto de página escasa. El modelo de layout RT-DETR de Docling usa contexto de página, y una tabla pequeña aislada en una página casi vacía puede clasificarse como Picture y desaparecer sin error. La misma tabla, rodeada de texto, se convierte bien. La solución es darle contexto de página al modelo de layout o revisar doc.tables después de convertir y marcar cualquier página cuyo conteo sea cero.
Docling vs Firecrawl: ¿cuál debería usar? Hacen trabajos distintos, así que normalmente no es una elección excluyente. Firecrawl rastrea la web viva, renderiza JavaScript y extrae el contenido principal. Docling convierte documentos que ya tienes, con estructura real de tablas en PDF y OCR, totalmente offline. Si tu fuente son páginas web, usa una herramienta web (Firecrawl o la API/MCP/CLI de Thunderbit). Si son PDF, escaneos o archivos Office, usa Docling. En la mayoría de los pipelines reales se usan ambos.
