Docling suele aparecer junto a los web scrapers, pero no lo es. Se trata de un kit de conversión de documentos de 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 convierte en Markdown o JSON. Su propio lema lo dice tal cual: "Prepara tus documentos para la IA generativa."
Así que esta es una reseña práctica de un conversor, no de un crawler. Todo lo que verás a continuación se midió en una sola máquina sin GPU (macOS arm64, Python 3.14.2, Docling 2.111.0), con resultados obtenidos mediante 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 incidencias o versión aquí como una foto del momento, no como algo fijo.
Qué es realmente Docling (y qué no es)
La unidad básica de todo en Docling es DoclingDocument: analizas un archivo y lo conviertes en esa estructura, y luego exportas a Markdown, HTML, DocTags o JSON sin pérdida. El código está bajo licencia MIT (las licencias de los modelos individuales varían), nació en IBM Research Zurich y, al momento de escribir esto, la versión más reciente es la v2.112.0, publicada dos días antes de que yo ejecutara estas pruebas.
La capacidad principal está en el camino de PDF e imagen. Y ese camino no se basa en parsear texto a ciegas: utiliza una pila de modelos de aprendizaje automático, entre ellos un modelo de layout RT-DETR, el modelo de estructura de tablas TableFormer, un modelo opcional de visión-lenguaje y RapidOCR para documentos escaneados. Esos modelos recuperan el diseño de la página, el orden de lectura y la estructura de las tablas. Esa es la parte que merece la pena evaluar, y la que un test solo de HTML nunca vería.
Hay una diferencia que te ahorra una semana de confusión. Docling no obtiene nada de la web. No renderiza JavaScript, no se salta protecciones anti-bot y no rastrea sitios. Tú le das el archivo; él se encarga de entenderlo. 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 más abajo verás por qué).
La primera ejecución que nadie te avisa
pip install docling se instala sin problemas en Python 3.14.2. Luego miras el entorno virtual y ves que pesa 1.3 GB. Docling arrastra toda la pila de ML como dependencia obligatoria incluso si lo único que vas a convertir es 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) | 72.1 |
| docling_parse | 30 |
Y eso antes de convertir un solo PDF. La primera conversión de un PDF es donde aparece la fricción real, porque ahí es cuando se descargan los modelos. En una caché de HuggingFace recién creada y aislada, la primera conversión de un PDF tardó ~224 segundos, y casi todo ese tiempo fue descarga, no cómputo. Los modelos de layout y TableFormer ocupan ~506 MiB en disco (342 MiB TableFormer + 164 MiB layout, verificado con du), y RapidOCR descarga ~40 MB de pesos PP-OCRv4 en 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 dato que deberías 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 enlaces simbólicos, y la caché de HuggingFace guarda cada archivo de modelo una sola vez en blobs/ y luego lo expone de nuevo como un enlace simbólico en snapshots/, así que el recorrido cuenta dos veces los 14 archivos del modelo. La cifra que coincide con du y evita el doble conteo por enlaces simbólicos es ~506 MiB (solo blobs: 505.4 MiB). La lección para quien quiera medir Docling: reporta por separado los bytes descargados y los bytes ocupados en disco, porque no son lo mismo.
Hay otra trampa que afecta a cualquiera que quiera meter Docling en un contenedor. Los pesos se dividen entre dos ubicaciones y dos calendarios. Los modelos de layout y TableFormer respetan HF_HOME y se descargan en la primera conversión de un PDF. Los modelos de RapidOCR no: aterrizan en …/site-packages/rapidocr/models/ y se saltan por completo tu configuración de caché. Si estás preconstruyendo una imagen o trabajando en un entorno aislado, tienes que manejar ambas cachés; por mucho que configures HF_HOME, eso no cubrirá la segunda.
Dicho eso, la parte justa. Desde versiones anteriores de Docling, el proyecto publicó 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 ya es opcional. Yo probé el paquete estándar porque sigue siendo lo que instala pip install docling, pero la pesadez no es un defecto sin salida: la alternativa modular ya existe y está registrada en la incidencia #2393.
Durante la instalación me topé con un detalle menor que vale la pena mencionar: import docling; docling.__version__ lanza AttributeError: module 'docling' has no attribute '__version__'. El módulo simplemente no la expone. La forma que sí funciona es importlib.metadata.version("docling"), que devuelve '2.111.0'. Es una molestia pequeña de DX, abierta upstream desde julio de 2026 como incidencia #3733.
Fidelidad de tablas: donde TableFormer demuestra su valor
Las tablas son la razón por la que alguien elegiría Docling antes que un simple volcado de PDF a texto, así que generé siete PDFs con tablas y verdad de referencia legible por máquina, y puntúe la salida celda por celda. Importan dos métricas, y no son lo mismo: recall de celdas es la fracción de valores reales que aparecen en algún lugar de la tabla detectada; tasa en la fila correcta es la fracción que termina en la fila adecuada. Confundir ambas favorece demasiado la herramienta, así que aquí van las dos:
| Tabla (estrés) | Detectada | Recall de celdas | Tasa en la fila correcta | Nota |
|---|---|---|---|---|
| T1 rejilla simple con bordes (8 filas × 5 columnas), sola en la página | No | 0.0 | — | clasificada como <!-- image -->, se pierden todas las celdas |
| T2 sin bordes (solo una línea de encabezado) | Sí | 1.00 | 1.00 | perfecta, rejilla exacta |
| T3 encabezado con colspan de 2 niveles y celdas combinadas | Sí | 1.00 | 0.97 | aparecen todos los valores; un valor del encabezado baja una fila |
| T4 etiqueta de fila con rowspan combinado, sola en la página | No | 0.0 | — | clasificada como <!-- image --> |
| T5 encabezado con colspan + sin bordes | Sí | 1.00 | 0.97 | aparecen todos los valores; mismo desplazamiento de fila que en T3 |
| T6 financieros, columna vacía, alineada a la derecha | Sí | 1.00 | 1.00 | la columna vacía se conserva, no se desplaza |
| T7 rejilla ancha de 12 columnas | Sí | 1.00 | 1.00 | no hay desplazamiento de columnas en una tabla ancha |
En las cinco tablas que Docling detectó, todos los valores de referencia llegaron bien: recall de celdas 1.00 en todas. En tres de esas cinco, además, cada valor terminó en su fila correcta. En los dos casos con encabezados multinivel (T3 y T5), un valor del encabezado se desplaza una fila respecto a su posición original, y la tasa en la fila correcta baja a 0.97: todos los datos están presentes, pero la asignación de fila vacila un poco en un encabezado apilado.
Los casos estructurales difíciles se comportaron 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 colapsar un colspan en GFM). La cuadrícula sin bordes pero con solo una línea de encabezado (T2) salió exactamente bien. La tabla ancha de 12 columnas (T7) no se desplazó. Y una columna financiera completamente vacía (T6) se conservó como celdas vacías en lugar de desaparecer o colapsarse. Eso coincide con los puntajes oficiales TEDS de TableFormer —95.4 simple, 90.1 compleja, 93.6 todas las tablas—, que la model card sitúa muy por encima de Camelot (73.0) y EDD (88.3).
Conviene ser cauteloso con las celdas combinadas, porque hay una incidencia abierta que dice lo contrario. La incidencia #3698 informa que V1 y V2 manejan mal filas y columnas combinadas. En mis pruebas, los simples colspan (T3/T5) y los valores con rowspan se aplanaron correctamente, con la única salvedad del desplazamiento de fila en encabezados multinivel mencionado arriba. Pero los casos que fallan en #3698 son combinaciones irregulares de varias filas y varias columnas y tablas multipágina, es decir, el extremo patológico. Los míos son el extremo simple. Así que la formulación precisa es esta: aquí se recuperaron colspan y rowspan simples (los encabezados multinivel pueden desplazarse una fila); las combinaciones complejas e irregulares siguen siendo un problema abierto documentado. No es correcto decir "las celdas combinadas funcionan" ni tampoco "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 fueron detectadas en absoluto. Docling emitió <!-- image --> y perdió todas las celdas sin dar error. T1 es una rejilla perfectamente normal con bordes, de 8 filas y 5 columnas. Eso me pareció tan preocupante que no quise llamarlo debilidad de análisis de tablas hasta aislar qué lo estaba provocando, así que monté una prueba A/B por script.
Primero descarté las explicaciones obvias. La capa de texto está intacta: pypdfium2 lee 327 caracteres de T1 y 221 de 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 directamente DoclingDocument, 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 de varios párrafos normales, y convertí de nuevo. Ambas salieron perfectas: len(doc.tables) == 1, tablas GFM correctas emitidas y la etiqueta con rowspan de T4b, "North", repetida correctamente a lo largo de sus tres filas. Misma tabla. La única variable que cambió fue si estaba sola en una página escasa o incrustada en texto.
Así que la advertencia real no es que TableFormer sea frágil; es que el modelo de layout RT-DETR de Docling usa el contexto de la página, y una tabla pequeña sola en una página casi vacía puede acabar leída como Picture y descartada 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 sencilla y efectiva: dale contexto de página al modelo de layout o revisa después doc.tables y marca las páginas donde el conteo sea cero. Esto está cerca de la incidencia #3495 (una tabla detectada a la vez como Table y Picture), pero el disparador específico de página escasa —la misma tabla desaparece cuando está aislada y convierte bien cuando está incrustada— no lo encontré documentado en ningún sitio. Medido, no documentado antes; no es un bug que nadie conociera.
OCR en escaneos reales: RapidOCR, no EasyOCR
Los PDFs escaneados son el punto donde muchos conversores fallan en silencio, así que alimenté Docling con dos escaneos reales con una capa de texto medida en 0 caracteres: pypdfium2 reporta cero caracteres recuperables, lo que confirma que cualquier salida proviene de OCR y no de una capa de texto oculta.
El PDF 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 multipágina de cuatro páginas nemotron_multipage.pdf activó OCR en las cuatro páginas y tardó 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, sin configuración.
Aquí está el detalle en el que la mayoría de las reseñas se equivoca: el motor OCR predeterminado es RapidOCR, no EasyOCR. Lo confirmé viendo cómo se descargaban los pesos .pth de PP-OCRv4 en la primera ejecución. Muchos blogs existentes y textos antiguos de preguntas frecuentes de Docling todavía dicen que el valor por defecto es EasyOCR; eso ya quedó desactualizado. EasyOCR ahora es un extra opcional. La advertencia que sí sigue siendo cierta: el OCR es el camino lento a gran escala, y todo esto es un techo medido solo con CPU; con GPU los tiempos bajarían de forma material.
PDFs reales, orden de lectura y tiempo por página
Los casos sintéticos prueban comportamientos concretos; los PDFs reales prueban que la herramienta realmente funciona. Ejecuté dos artículos académicos nativos en digital: 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 artículo de 15 páginas de Attention, los cinco marcadores de sección —Abstract, Introduction, Background, Conclusion, References— aparecen en orden documental en el Markdown linealizado, pese al diseño a dos columnas. Todas las referencias de contenido que busqué (Transformer, encoder, BLEU, multi-head) están presentes, 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 el valor central para trocear documentos en RAG: no puedes dividir bien un documento si el linearizador convierte una página a dos columnas en un caos intercalado.
El tiempo deja una lección contraintuitiva. El tiempo por página depende de cuánta estructura hay en cada página, no del número de páginas. El informe más denso, de 9 páginas, corrió a 14.95 segundos por página —más lento por página que el artículo de 15 páginas, que marcó 5.99 segundos por página—, porque concentra más tablas y figuras por página —3 tablas en 9 páginas contra 4 en 15— y cada una dispara más inferencia de layout y TableFormer. Esa diferencia es pequeña y, en términos absolutos, el documento más denso tiene menos tablas, no más. Así que "segundos por página" en CPU es función de la densidad estructural, no de la longitud. Esta es una sola ejecución en CPU; es un techo, no una cifra de producción.
Multiformato y la promesa de JSON sin pérdida
Docling anuncia un análisis unificado para múltiples 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 aparecían en el Markdown y si sobrevivían al paso ida y vuelta por JSON mediante export_to_dict().
| Archivo | Conversión s | Puntos en MD | Tablas en MD | Los puntos sobreviven en JSON |
|---|---|---|---|---|
report.docx (encabezados + tabla con "Total" combinada + 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 "Total" combinada del DOCX y ambas hojas del XLSX) y cada punto también sobrevivió en el JSON de export_to_dict(), que es la evidencia que importa para la afirmación de DoclingDocument sin pérdida, al menos sobre entradas limpias. Estos formatos pasan por backends nativos del formato, no por los modelos de ML, por eso se ejecutan en decenas de milisegundos y funcionan completamente 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 matiz que decide si Docling encaja en tu pipeline de RAG, así que léelo con atención. Docling convierte el documento HTML completo. No hace extracción de contenido principal estilo readability. Cuantifiqué cuánto del chrome del sitio sobrevive contando líneas de navegación, índice, cookies y pie de página en la salida de Docling.
| Página | Líneas MD no vacías | Líneas de boilerplate | % boilerplate | La entrada 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 elementos visuales como Wikipedia, ~13% de las líneas de Markdown son navegación, índice o 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 termina con "CS1 maint… / Search Wikipedia." En páginas limpias de contenido (books, quotes) es ~0%, así que esto es un problema de decoración de plantilla, no un peaje por página. Docling te da Markdown fiel del documento completo, no una extracción limpia del artículo principal. Upstream sigue el problema del mobiliario HTML en la incidencia #1865 (cerrada) y la #1930 (abierta).
Hay dos cosas que hacen esto justo. Primero, en HTML Docling no ejecuta ningún modelo de ML: usa un backend de BeautifulSoup en una tubería simple. La historia de los "modelos de visión leyendo tu página" aplica solo a PDF e imágenes; si le das HTML a Docling, no se activa la maquinaria de layout ni de TableFormer. Segundo, la ruta PDF sí intenta clasificar encabezados y pies de página, así que decir "no hay eliminación de boilerplate en absoluto" sería demasiado fuerte; es el backend de HTML, específicamente, el que devuelve ese chrome.
Cómo se compara (y dónde encaja Thunderbit)
Prueba Thunderbit para extracción de datos web
La herramienta de referencia con la que la gente compara Docling es Firecrawl, así que aquí va una tabla de posicionamiento. Una salvedad importante antes de empezar: esta es una comparación a nivel de documentación, no una prueba en la misma máquina. No ejecuté Firecrawl sobre estos casos. 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 + extraer la web en vivo → Markdown | Convertir un documento que ya tienes → Markdown/JSON |
| Fetch / renderizado JS / anti-bot | Sí (navegador alojado) | No: tú proporcionas el archivo |
| Extracción de contenido principal | Sí | No: documento completo fiel (~13% de chrome en Wikipedia) |
| Estructura de tablas en PDF (ML) | limitada | Sí: TableFormer (TEDS oficial 93.6; recall de celdas 1.00, en fila 0.97–1.00 en los casos detectados) |
| PDF escaneado / OCR | limitada | Sí: RapidOCR por defecto (recuperó un escaneo sin capa de texto) |
| Cobertura de formatos | páginas web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/imágenes |
| Implementación | API alojada (+ autoalojado) | librería local con pip, sin conexión, sin API key |
| Peso de configuración | API key / cliente ligero | instalación por defecto de 1.3 GB + ~506 MiB en 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 PDFs, escaneos y archivos Office con muchas tablas— y quieres una conversión fiel, sin conexión y que preserve la 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 claro sobre Thunderbit, ya que trabajo aquí y sería razonable que sospecharas si fingiera lo contrario. 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 más CLI, y 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, el anti-bot y los CAPTCHA que Docling explícitamente no toca), y POST /extract devuelve JSON estructurado que coincide con un esquema mediante un JSON Schema que tú defines. Ese es el extremo de captura y limpieza de un pipeline RAG. Docling es el extremo de documento local: 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 PDFs y escaneos, usa Docling. Si son ambos —como en la mayoría de los pipelines reales—, los combinas, y ninguno intenta ser el otro.
Veredicto: provisional, y con tareas pendientes
No voy a darte una sola nota de 0 a 100, porque una suma ponderada mezclaría penalizaciones por cosas que Docling nunca prometió hacer (como rastrear la web) y fingiría que son comparables. Por dimensión, en los casos que probé:
- Instalación / primera ejecución: pesado —entorno virtual de 1.3 GB, ~506 MiB en modelos, ~224 s en el primer PDF, ~0.55 s en caliente—, pero
docling-slimte permite evitar ese peso. - Fidelidad de tablas: fuerte cuando detecta la tabla (recall de celdas 1.00 en 5/5, en fila 0.97–1.00), alineado con la historia oficial de TEDS en estos casos.
- Robustez en la detección de tablas: la trampa de página escasa: una tabla aislada puede caer como Picture. Revisa
doc.tablesdespués. - Escaneados / OCR: funciona, RapidOCR por defecto; lento a escala.
- Multiformato: sólido, con el round-trip JSON intacto.
- HTML: fiel, no limpio; sin extracción de contenido principal.
- Experiencia de desarrollador: API limpia en 3 líneas y un
DoclingDocumentordenado, salvo por la falta de__version__.
Para quién sí es: equipos que construyen pipelines de RAG o de datos sobre PDFs, 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 es: quien necesite rastreo de web en vivo o extracción limpia del artículo principal en HTML; para eso hace falta otra herramienta.
Y como esto es una reseña y no una nota de prensa, los límites se quedan visibles. Esta es una prueba focalizada —7 tablas sintéticas más 2 PDFs reales en una sola máquina sin GPU—, no un benchmark de precisión a escala TEDS. Hay varias cosas que no probé y que deberías revisar antes de apostar un pipeline entero a Docling: la ruta opcional VLM (GraniteDocling), el tamaño real de docling-slim, cualquier ejecución en GPU, las celdas combinadas complejas e irregulares y las tablas multipágina, la fidelidad de fórmulas a LaTeX y —lo que más probablemente te sorprenda en producción— la tríada de durabilidad de crecimiento de memoria por lote, escalado con threads/GIL y ciclo de vida de objetos a lo largo de miles de conversiones. Docling es fuerte en lo que dice ser, medido más que promocionado, y tiene límites reales que conviene mapear antes de confiarle un corpus. Conoce la salvedad de la página escasa, presupuesta la descarga de la primera ejecución y verifica tú mismo el comportamiento a gran escala.
Prueba Thunderbit para extracción de 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 gestiona protecciones anti-bot. Rastrear la web en vivo es otra tarea, que resuelven herramientas como Firecrawl o la API web de Thunderbit; Docling parte del archivo que tú le das.
¿Cuánto pesa la instalación de Docling y la descarga inicial?
El metapaquete docling por defecto genera un entorno virtual de ~1.3 GB porque arrastra toda la pila de ML (solo torch ocupa 536 MiB) como dependencia obligatoria. La primera conversión de un PDF descarga ~506 MiB de modelos de layout y TableFormer en disco, más ~40 MB de pesos RapidOCR, y tarda unos 224 segundos —casi todo es descarga. La segunda conversión tarda ~0.55 segundos. Si solo necesitas formatos ligeros, docling-slim (~50 MB de núcleo) evita el camino pesado.
¿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 en mi prueba recuperó el texto con claridad. El motor por defecto es RapidOCR, no EasyOCR, un error frecuente en textos antiguos. EasyOCR ahora es un extra opcional. El OCR es el camino lento a escala, especialmente en CPU.
¿Por qué Docling convirtió mi tabla en una imagen o la descartó?
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 sola en una página casi vacía puede clasificarse como Picture y desaparecer sin error. La misma tabla, rodeada de texto, se convierte correctamente. La solución es darle contexto al modelo de layout o comprobar después doc.tables y señalar cualquier página donde el 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 en vivo, renderiza JavaScript y extrae el contenido principal. Docling convierte documentos que ya posees, con estructura real de tablas en PDF y OCR, totalmente sin conexión. Si tu fuente son páginas web, usa una herramienta web (Firecrawl o la API/MCP/CLI de Thunderbit). Si son PDFs, escaneos o archivos Office, usa Docling. En la mayoría de los pipelines reales se usan ambos.
