O Docling vive sendo colocado na mesma prateleira dos web scrapers, mas ele não é isso. Trata-se de um kit de conversão de documentos da IBM Research — hoje um projeto da LF AI & Data Foundation — que pega arquivos que você já possui (PDF, DOCX, PPTX, XLSX, HTML, imagens) e os transforma em Markdown ou JSON. O próprio slogan diz tudo: "Prepare seus documentos para a IA generativa".
Portanto, esta é uma análise prática de um conversor, não de um crawler. Tudo abaixo foi medido em uma máquina apenas com CPU (macOS arm64, Python 3.14.2, Docling 2.111.0), com pontuação baseada em scripts e falhas registradas como falhas. O repositório é gigantesco e muda todos os dias — 63.069 estrelas, 4.449 forks e um push no mesmo dia em que puxei os metadados — então trate qualquer número de versão ou contagem de problemas aqui como um recorte do momento, não como algo fixo.
O que o Docling é de verdade — e o que não é
A unidade central do Docling é o DoclingDocument: você faz o parse de um arquivo para essa estrutura e depois exporta para Markdown, HTML, DocTags ou JSON sem perdas. O código é licenciado em MIT (as licenças dos modelos individuais variam), nasceu na IBM Research Zurich e, no momento em que escrevo, o release mais recente é o v2.112.0, publicado dois dias antes deste teste.
O principal destaque é o fluxo de PDF e imagens. Esse caminho não depende de simples parsing de strings — ele usa uma pilha de modelos de machine learning: um modelo de layout RT-DETR, o modelo de estrutura de tabelas TableFormer, um modelo visão-linguagem opcional e o RapidOCR para documentos digitalizados. Esses modelos recuperam o layout da página, a ordem de leitura e a estrutura das tabelas. É justamente essa parte que merece análise, e é algo que um teste só com HTML nunca mostraria.
Há uma distinção importante que evita uma semana de confusão: o Docling não busca nada na web. Ele não renderiza JavaScript, não dribla proteções anti-bot e não faz crawling. Você fornece o arquivo; ele faz a interpretação. O crawling é tarefa de outra ferramenta — e isso vai importar mais adiante, quando a pergunta inevitável surgir: Docling substitui Firecrawl? Não. Eles se complementam, e já vou explicar por quê.
A primeira execução sobre a qual ninguém te avisa
pip install docling conclui normalmente no Python 3.14.2. Depois você olha o ambiente virtual e vê que ele ocupa 1,3 GB. O Docling puxa toda a stack de ML como dependências obrigatórias, mesmo que tudo o que você vá converter seja um arquivo HTML:
| Dependência | Tamanho em disco (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ modelos incluídos) | 75,6 |
| docling_parse | 30 |
Isso tudo antes de converter um único PDF. A primeira conversão de PDF é onde a fricção real aparece, porque é nesse momento que os modelos são baixados. Em um cache HuggingFace novo e isolado, a primeira conversão de PDF levou cerca de 224 segundos — e quase tudo isso foi download, não processamento. Os modelos de layout + TableFormer ocupam cerca de 506 MiB em disco (342 MiB do TableFormer + 164 MiB do layout, verificado com du), e o RapidOCR baixa cerca de 40 MB de pesos PP-OCRv4 para dentro de site-packages. A segunda conversão do mesmo arquivo? 0,55 segundo. Os modelos ficam em cache; esse pedágio você paga uma vez.
Tem um número que você deve ignorar: o script de cold start imprime model_download_mb de 1060,2. Não cite isso como footprint real. Esse número vem de um os.walk que segue symlinks, e o cache do HuggingFace guarda cada arquivo de modelo uma única vez em blobs/ e depois o expõe novamente como symlink em snapshots/ — então o walk conta os 14 arquivos de modelo duas vezes. O valor compatível com du, sem duplicação por symlink, é cerca de 506 MiB (somente blobs: 505,4 MiB). A lição para quem estiver benchmarkando o Docling: informe bytes baixados e bytes em disco separadamente, porque são coisas diferentes.
Há um segundo detalhe que pega qualquer pessoa tentando empacotar o Docling em container. Os pesos são divididos em dois locais e baixados em cronogramas diferentes. Os modelos de layout e TableFormer respeitam HF_HOME e são baixados na primeira conversão de PDF. Já os modelos do RapidOCR não — eles vão parar em …/site-packages/rapidocr/models/, ignorando sua configuração de cache. Se você estiver montando uma imagem pré-baked ou isolada da rede, precisa lidar com os dois caches; só definir HF_HOME não resolve o segundo.
Agora, a parte justa. Desde as versões anteriores do Docling, o projeto passou a oferecer o docling-slim — um núcleo de cerca de 50 MB que permite fazer pip install docling-slim[format-html] para HTML sem carregar torch. Então o peso de 1,3 GB é real no metapacote padrão docling, mas agora ele é opcional. Testei o pacote padrão porque é isso que pip install docling ainda entrega, mas esse peso não é uma falha sem solução — a correção modular já existe e está acompanhada na issue #2393.
Durante a configuração, encontrei um pequeno problema prático que vale mencionar: import docling; docling.__version__ gera AttributeError: module 'docling' has no attribute '__version__'. O módulo simplesmente não expõe essa informação. A forma correta de consultar a versão é importlib.metadata.version("docling"), que retorna '2.111.0'. É uma irritação pequena para desenvolvedores, aberta upstream desde julho de 2026 como issue #3733.
Fidelidade de tabelas: onde o TableFormer realmente entrega valor
Tabelas são o motivo de alguém escolher o Docling em vez de um dump simples de PDF para texto, então gerei sete PDFs com tabelas e ground truth legível por máquina, e pontuei a saída célula por célula. Dois indicadores importam, e eles não são a mesma coisa: recall de célula é a fração dos valores do ground truth presentes em algum lugar da tabela detectada; taxa na linha correta é a fração que cai na linha certa. Misturar os dois deixa a ferramenta mais bonita do que ela é, então aqui vão os dois:
| Tabela (estresse) | Detectada | Recall de célula | Taxa na linha correta | Observação |
|---|---|---|---|---|
| T1 grade simples com bordas (5×8), isolada na página | Não | 0,0 | — | classificada como <!-- image -->, todas as células descartadas |
| T2 sem bordas (apenas uma linha de cabeçalho) | Sim | 1,00 | 1,00 | perfeito, grade exata |
| T3 cabeçalho mesclado com colspan em 2 níveis | Sim | 1,00 | 0,97 | todos os valores encontrados; um valor do cabeçalho cai uma linha |
| T4 rótulo de linha com rowspan mesclado, isolado na página | Não | 0,0 | — | classificado como <!-- image --> |
| T5 cabeçalho com colspan + sem bordas | Sim | 1,00 | 0,97 | todos os valores encontrados; o mesmo deslocamento de linha do T3 |
| T6 financeiro, coluna em branco, alinhado à direita | Sim | 1,00 | 1,00 | coluna em branco preservada, sem deslocamento |
| T7 grade ampla de 12 colunas | Sim | 1,00 | 1,00 | sem deslocamento de colunas em tabela larga |
Nas cinco tabelas que o Docling detectou, todos os valores do ground truth apareceram — recall de célula 1,00 em todas. Em três dessas cinco, todos os valores também caíram na linha correta. Nos dois casos com cabeçalho multinível (T3 e T5), um valor de cabeçalho escorrega para fora da linha original, baixando a taxa na linha correta para 0,97 — os dados estão lá, mas a atribuição de linha vacila em um cabeçalho empilhado.
Os casos estruturais mais difíceis se saíram melhor do que eu esperava. O cabeçalho com colspan em dois níveis foi achatado corretamente para o Markdown no estilo GitHub (o rótulo "Q1 2026" foi repetido sobre as duas colunas abrangidas, que é a forma certa de colapsar um colspan em GFM). A grade sem bordas com apenas uma linha de cabeçalho (T2) saiu exatamente. A tabela larga com 12 colunas (T7) não deslocou. E uma coluna financeira totalmente em branco (T6) foi preservada como células vazias, em vez de ser descartada ou colapsada. Isso bate com as pontuações oficiais do TableFormer em TEDS — 95,4 para tabelas simples, 90,1 para complexas e 93,6 no geral — que o model card coloca bem acima de Camelot (73,0) e EDD (88,3).
Uma observação importante sobre células mescladas, porque existe uma issue aberta dizendo o contrário. A issue #3698 relata que as versões V1 e V2 lidam mal com linhas e colunas mescladas. Nos meus fixtures, colspan simples (T3/T5) e valores com rowspan foram achatados corretamente, com exceção do deslocamento de linha nos cabeçalhos multinível já citado acima. Mas os casos que falham na #3698 envolvem mesclas irregulares de várias linhas/colunas e tabelas em várias páginas — o lado patológico do problema. Os meus são o lado simples. Então a formulação correta é esta, de forma restrita: colspan e rowspan simples foram recuperados aqui (cabeçalhos multinível podem deslocar uma linha); mesclas complexas e irregulares continuam sendo um problema aberto documentado. Não é "células mescladas funcionam", nem "células mescladas estão quebradas".
A armadilha: uma tabela sozinha na página pode sumir
Volte à tabela — T1 e T4 não foram detectadas. O Docling emitiu <!-- image --> e descartou todas as células, sem erro. T1 é uma grade comum, 5×8, com bordas. Isso é preocupante o bastante para eu não chamar isso de fraqueza de parsing de tabela antes de isolar o que realmente disparava o comportamento, então montei um teste A/B automatizado.
Primeiro, descartei as explicações mais óbvias. A camada de texto está intacta — o pypdfium2 lê 327 caracteres de T1 e 221 de T4, então são PDFs digitais de verdade, não imagens escaneadas. Desligar o OCR (do_ocr=False) não ajuda; as tabelas continuam sumindo. E, inspecionando o DoclingDocument diretamente, len(doc.tables) == 0 enquanto len(doc.pictures) == 1 — o modelo de layout tinha classificado toda a região da tabela como uma Picture.
Depois veio o teste decisivo. Recriei os mesmos T1 e T4, mas desta vez cercados por alguns parágrafos normais de texto, e converti novamente. Ambos saíram perfeitamente: len(doc.tables) == 1, tabelas GFM adequadas emitidas, e o rótulo "North" do rowspan em T4b foi repetido corretamente nas três linhas. Mesma tabela. A única variável que mudou foi estar sozinha numa página esparsa ou inserida em texto.
Então a verdadeira ressalva não é que o TableFormer seja frágil — é que o modelo de layout RT-DETR do Docling usa contexto da página, e uma tabela pequena sozinha em uma página quase vazia pode ser lida como Picture e descartada silenciosamente. Isso é fácil de encontrar na prática, porque é exatamente assim que parecem invoices, fichas técnicas e exports recortados: uma tabela por página, sem texto ao redor. A solução é simples e eficaz — dê contexto de página ao modelo de layout, ou verifique doc.tables depois da conversão e sinalize páginas em que a contagem seja zero. Isso fica próximo da issue #3495 (uma tabela detectada como Table e Picture ao mesmo tempo), mas o gatilho específico de página esparsa — mesma tabela, some quando isolada, converte quando embutida — eu não encontrei documentado em lugar nenhum. Medido, não documentado antes; não é um bug que ninguém conhecia.
OCR em scans reais: RapidOCR, não EasyOCR
PDFs escaneados são onde muitos conversores falham silenciosamente, então alimentamos o Docling com dois scans reais com camada de texto medida em 0 caracteres — o pypdfium2 retorna zero caracteres recuperáveis, confirmando que qualquer saída vem de OCR, não de uma camada de texto escondida por trás.
O ocr_test.pdf, de uma página, voltou limpo em 14,3 segundos na CPU: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," recuperado literalmente. O nemotron_multipage.pdf, com quatro páginas, acionou OCR nas quatro em 70,1 segundos no total (17,5 s/página), emitindo a frase de teste repetida em cada página. O OCR padrão foi acionado automaticamente — sem flag, sem configuração.
Aqui está um detalhe que muita matéria erra: o motor de OCR padrão é RapidOCR, não EasyOCR. Eu confirmei isso vendo os pesos .pth do PP-OCRv4 serem baixados na primeira execução. Muitos blogs e até textos antigos de FAQ do Docling ainda dizem que o EasyOCR é o padrão; isso está desatualizado. Hoje, EasyOCR é um extra opcional. O ponto que continua verdadeiro: OCR é o caminho lento em escala, e tudo aqui é um teto medido em CPU — com GPU, esses tempos cairiam bastante.
PDFs reais, ordem de leitura e tempo por página
Os fixtures sintéticos provam comportamentos específicos; PDFs reais provam que a coisa realmente funciona. Rodei dois artigos acadêmicos digitais — o relatório técnico do Docling, com 9 páginas, e "Attention Is All You Need", com 15 páginas — ambos em duas colunas, com tabelas e fórmulas.
No paper de 15 páginas Attention, todos os cinco marcadores de seção — Abstract, Introduction, Background, Conclusion e References — aparecem na ordem do documento no Markdown linearizado, apesar do layout em duas colunas. Todos os pontos de verificação de conteúdo (Transformer, encoder, BLEU, multi-head) estão presentes, e as famosas tabelas de resultados em múltiplas colunas aparecem como quatro tabelas detectadas. Isso é recuperação real de ordem de leitura e mesclagem de colunas, que é o valor central para chunking em RAG — você não consegue quebrar um documento de forma útil se o linearizador transforma uma página em duas colunas num caos intercalado.
O tempo traz uma lição contraintuitiva: o tempo por página é definido por quanta estrutura existe em cada página, não pela quantidade de páginas. O relatório de 9 páginas, mais denso, rodou a 14,95 segundos por página — mais lento por página do que o artigo de 15 páginas, que ficou em 5,99 segundos por página — porque ele tem mais tabelas e figuras, e cada uma dispara mais inferência de layout e do TableFormer. Então "segundos por página" em CPU dependem da densidade estrutural, não do tamanho do arquivo. Esta é uma única execução em CPU; é um teto, não um número de produção.
Multi-formato e a promessa de JSON sem perdas
O Docling anuncia parsing unificado para múltiplos formatos, então gerei um DOCX, um XLSX e um PPTX com conteúdo conhecido e pontos de verificação de ground truth, e testei duas coisas: os pontos aparecem no Markdown? E sobrevivem ao round-trip de JSON via export_to_dict()?
| Arquivo | Conversão s | Pontos no MD | Tabelas no MD | Pontos sobrevivem no JSON |
|---|---|---|---|---|
report.docx (títulos + tabela mesclada "Total" + bullets) | 0,137 | 7/7 | 1 | Sim |
workbook.xlsx (2 planilhas, coluna em branco) | 0,016 | 6/6 | 2 | Sim |
deck.pptx (3 slides, bullets + tabela) | 0,038 | 6/6 | 1 | Sim |
Todos os pontos apareceram no Markdown, as tabelas foram recuperadas (incluindo a linha "Total" mesclada do DOCX e as duas planilhas do XLSX), e todos os pontos também sobreviveram ao JSON de export_to_dict() — o que é a evidência que importa para a promessa de DoclingDocument sem perdas, pelo menos em entradas limpas. Esses formatos passam por backends nativos de cada formato em vez de pelos modelos de ML, por isso rodam em dezenas de milissegundos e funcionam totalmente offline. O escopo é honesto: um arquivo limpo por formato comprova amplitude, não um teste de estresse com arquivos Office patológicos.
HTML: fiel, mas não limpo
Esta é a ressalva que decide se o Docling cabe ou não no seu pipeline de RAG, então leia com atenção. O Docling converte o documento HTML inteiro. Ele não faz extração de conteúdo principal no estilo readability. Eu medi quanto do “enfeite” de um site sobreviveu contando linhas de navegação, sumário, cookie e rodapé na saída do próprio Docling.
| Página | Linhas MD não vazias | Linhas de boilerplate | % de boilerplate | Onde o artigo começa |
|---|---|---|---|---|
| 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% | — |
Em uma página pesada em elementos de interface, como a Wikipedia, cerca de 13% das linhas de Markdown são boilerplate de navegação/sumário/rodapé, e o artigo de verdade só começa na linha 28 — a saída abre com "move to sidebar / Contents / Toggle the table of contents" e termina com "CS1 maint… / Search Wikipedia." Em páginas limpas de conteúdo (books, quotes), esse valor fica em torno de 0%, então o problema é o chrome do template, não um custo por página. O Docling te entrega Markdown fiel do documento inteiro, não extração limpa do artigo principal. O upstream acompanha esse problema de “mobiliário” HTML na issue #1865 (fechada) e na #1930 (aberta).
Dois pontos deixam isso justo. Primeiro, especificamente em HTML o Docling não roda nenhum modelo de ML — ele usa um backend BeautifulSoup dentro de um pipeline simples. A história de “modelos visuais lendo sua página” vale para PDF e imagens apenas; se você alimentar HTML ao Docling, nenhuma das engrenagens de layout ou TableFormer entra em ação. Segundo, o caminho de PDF realmente tenta classificar cabeçalho e rodapé como mobiliário, então seria exagero dizer que não há remoção alguma de boilerplate — é o backend de HTML, especificamente, que devolve o chrome.
Como ele se posiciona — e onde o Thunderbit entra
Experimente o Thunderbit para extração de dados da web
A ferramenta de referência com que as pessoas costumam comparar o Docling é o Firecrawl, então aqui vai uma tabela de posicionamento. Um aviso importante desde já: esta é uma comparação em nível de documentação, não um benchmark no mesmo hardware. Eu não rodei o Firecrawl nesses fixtures. Apenas a coluna do Docling foi medida aqui; a coluna do Firecrawl vem da documentação pública.
| Eixo | Firecrawl (segundo a documentação) | Docling (medido aqui) |
|---|---|---|
| Tarefa principal | Rastrear + extrair a web ao vivo → Markdown | Converter um documento que você já possui → Markdown/JSON |
| Busca / renderização JS / anti-bot | Sim (navegador hospedado) | Não — você fornece o arquivo |
| Extração do conteúdo principal | Sim | Não — documento fiel completo (~13% de chrome na Wikipedia) |
| Estrutura de tabelas em PDF (ML) | limitada | Sim — TableFormer (TEDS oficial 93,6; recall de célula 1,00, taxa na linha 0,97–1,00 nos fixtures detectados) |
| PDF escaneado / OCR | limitada | Sim — RapidOCR por padrão (recuperou um scan sem camada de texto) |
| Amplitude de formatos | páginas web | PDF/DOCX/PPTX/XLSX/HTML/EPUB/imagens |
| Implantação | API hospedada (+ self-host) | biblioteca local em pip, offline, sem chave de API |
| Peso de configuração | chave de API / cliente leve | instalação padrão de 1,3 GB + ~506 MiB de modelos (ou docling-slim) |
| Licença | comercial / código disponível | MIT |
A versão curta: Firecrawl é a ferramenta certa quando seus dados estão na web ao vivo e precisam de crawling, renderização de JS e limpeza do conteúdo principal. O Docling é a ferramenta certa quando você já tem o documento — especialmente PDFs, scans e arquivos Office pesados em tabelas — e quer conversão fiel, offline e preservando estrutura, com compreensão real de tabelas e OCR. Eles se complementam. Um pipeline realista faz o crawl com um e converte os documentos com o outro.
E aqui vou ser direto sobre o Thunderbit, já que trabalho aqui e seria justo desconfiar se eu fingisse neutralidade. Thunderbit e Docling não fazem a mesma coisa, e eu não vou forçar uma equivalência. Para desenvolvedores, Thunderbit é uma API de scraping com IA + servidor MCP + CLI, e sua unidade de trabalho é a página da web ao vivo: POST /distill transforma uma URL em Markdown limpo pronto para LLM (lidando com renderização JS, anti-bot e CAPTCHA, algo que o Docling explicitamente não faz), e POST /extract devolve JSON estruturado compatível com o schema que você definir. Esse é o lado de busca e limpeza de um pipeline de RAG. O Docling é o lado de documentos locais — o PDF, o scan, a planilha que já está no seu disco. Se o seu corpus é de páginas web, use a API do Thunderbit, suas ferramentas MCP (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) ou o CLI (npx @thunderbit/thunderbit-cli). Se forem PDFs e scans, use o Docling. Se forem os dois — que é o caso da maioria dos pipelines reais — combine os dois, porque nenhum está tentando ser o outro.
Veredito: provisório, com dever de casa restante
Não vou te entregar uma nota única de 0 a 100, porque um total ponderado aqui misturaria penalidades por coisas que o Docling nunca prometeu fazer (como crawling) e fingiria que são comparáveis. Por dimensão, nos fixtures que testei:
- Configuração / primeira execução: pesado — venv de 1,3 GB, ~506 MiB de modelos, ~224 s no primeiro PDF, ~0,55 s nas execuções quentes — mas o
docling-slimpermite evitar esse peso. - Fidelidade de tabelas: forte quando a tabela é detectada (recall de célula 1,00 em 5/5, taxa na linha correta 0,97–1,00), em linha com a história oficial de TEDS nesses fixtures.
- Robustez na detecção de tabelas: a armadilha da página esparsa — uma tabela isolada pode ser reclassificada como Picture. Faça pós-verificação de
doc.tables. - Scans / OCR: funciona, RapidOCR por padrão; lento em escala.
- Multi-formato: sólido, com o round-trip em JSON intacto.
- HTML: fiel, não limpo — sem extração do conteúdo principal.
- Experiência de desenvolvedor: API limpa em 3 linhas e um
DoclingDocumentorganizado, com exceção do__version__ausente.
Para quem ele é: equipes construindo pipelines de RAG ou dados sobre PDFs, scans e arquivos Office que querem conversão offline, preservando estrutura e com compreensão real de tabelas e OCR. Para quem ele não é: quem precisa de crawling da web ao vivo ou de extração limpa do artigo principal em HTML — isso é trabalho de outra ferramenta.
E, como isto é uma análise e não um press release, os limites continuam claros. Este foi um teste direcionado — 7 tabelas sintéticas + 2 PDFs reais em uma máquina apenas com CPU — e não um benchmark de precisão em escala TEDS. Há várias coisas que não testei e que você deveria testar antes de apostar um pipeline no Docling: o caminho opcional de VLM (GraniteDocling), o footprint real do docling-slim, qualquer execução em GPU, células mescladas complexas e irregulares + tabelas multi-página, fidelidade de fórmulas para LaTeX e — a que mais provavelmente vai te surpreender em produção — a tríade de durabilidade: crescimento de memória em lotes, escala de threads/GIL e ciclo de vida dos objetos em milhares de conversões. O Docling é forte no que promete, medido e não vendido por marketing, mas também tem arestas reais que vale mapear antes de confiar nele com um corpus inteiro. Conheça a ressalva das páginas esparsas, reserve espaço para o download da primeira execução e valide o comportamento em escala por conta própria.
Experimente o Thunderbit para extração de dados da web Get Started Free
Perguntas frequentes
O Docling é um web scraper ou crawler? Não. O Docling converte documentos que você já possui — PDF, DOCX, PPTX, XLSX, HTML, imagens — em Markdown ou JSON. Ele não busca URLs, não renderiza JavaScript e não lida com anti-bot. O crawling da web ao vivo é um trabalho separado, feito por ferramentas como Firecrawl ou pela API web do Thunderbit; o Docling começa no arquivo que você fornece.
Qual é o tamanho da instalação do Docling e do download na primeira execução?
O metapacote padrão docling cria um venv de cerca de 1,3 GB porque puxa toda a stack de ML como dependência obrigatória (só o torch já ocupa 536 MiB). A primeira conversão de PDF baixa cerca de 506 MiB de modelos de layout e TableFormer em disco, além de cerca de 40 MB de pesos do RapidOCR, e leva aproximadamente 224 segundos — quase tudo em download. A segunda conversão leva cerca de 0,55 segundo. Se você só precisa de formatos leves, o docling-slim (núcleo de ~50 MB) evita esse caminho pesado.
O Docling faz OCR? E com qual motor? Sim. Em um PDF escaneado sem camada de texto, o OCR do Docling é acionado automaticamente e recuperou o texto com clareza no meu teste. O motor padrão é RapidOCR, não EasyOCR — um erro comum em textos antigos. Hoje o EasyOCR é um extra opcional. OCR é o caminho mais lento em escala, especialmente em CPU.
Por que o Docling transformou minha tabela em imagem ou a descartou?
Muito provavelmente por causa do efeito de página esparsa. O modelo de layout RT-DETR do Docling usa contexto da página, e uma tabela pequena sozinha em uma página quase vazia pode ser classificada como Picture e descartada sem erro. A mesma tabela, cercada por texto, converte normalmente. A correção é dar contexto de página ao modelo de layout ou verificar doc.tables depois da conversão e sinalizar qualquer página com contagem zero.
Docling vs Firecrawl — qual devo usar? São tarefas diferentes, então normalmente não é uma escolha de um ou outro. Firecrawl rastreia a web ao vivo, renderiza JavaScript e extrai o conteúdo principal. O Docling converte documentos que você já possui, com estrutura real de tabelas em PDF e OCR, totalmente offline. Se a sua fonte é página web, use uma ferramenta para web (Firecrawl ou a API/MCP/CLI do Thunderbit). Se são PDFs, scans ou arquivos Office, use o Docling. Na prática, a maioria dos pipelines usa os dois.
