Análise do Docling: o que o conversor de documentos para Markdown da IBM realmente faz com seus PDFs

O Docling costuma aparecer na mesma conversa que web scrapers, mas ele não é isso. Trata-se de um kit de conversão de documentos criado pela IBM Research — hoje um projeto da LF AI & Data Foundation — que pega arquivos que você já tem em mãos (PDF, DOCX, PPTX, XLSX, HTML, imagens) e os transforma em Markdown ou JSON. O próprio slogan dele é literalmente "Prepare seus documentos para a gen AI."

Então 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 extraí os metadados — então trate qualquer número de versão ou contagem de problemas aqui como um retrato do momento, não como algo fixo.

O que o Docling realmente é — e o que não é

A unidade central de tudo no Docling é o DoclingDocument: você faz o parse do 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, a versão mais recente é a v2.112.0, publicada dois dias antes de eu executar estes testes.

O grande destaque é o caminho de PDF e imagens. E esse caminho não se baseia em simples leitura de string — 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. É essa parte que vale a análise — e é exatamente a parte que um teste focado só em HTML jamais enxergaria.

Uma distinção evita uma semana de confusão. O Docling não busca nada. Ele não renderiza JavaScript, não dribla bloqueios anti-bot e não faz crawling. Você entra com o arquivo; ele faz a compreensão. Crawling é função de outra ferramenta — e isso importa mais adiante, quando a pergunta vira se o Docling substitui o Firecrawl (não substitui — são complementares, e já chego nisso).

A primeira execução que ninguém avisa

pip install docling conclui normalmente no Python 3.14.2. Depois você olha para o ambiente virtual e percebe: ele tem 1,3 GB. O Docling puxa toda a pilha de ML como dependência obrigatória, mesmo se tudo o que você quiser converter for 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)	72.1
docling_parse	30

E isso antes de converter um único PDF. A primeira conversão de PDF é onde a fricção de verdade 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 todo esse tempo foi download, não processamento. Os modelos de layout e 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 segundos. Os modelos ficam em cache; a cobrança é feita uma vez só.

Um número que você deve ignorar: o script de cold start imprime model_download_mb como 1060,2. Não cite isso como pegada real. Esse valor vem de um os.walk que segue symlinks, e o cache do HuggingFace armazena cada arquivo uma única vez em blobs/ e depois o expõe de novo via symlink em snapshots/ — então a varredura 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 for benchmarkar o Docling: separe bytes baixados de bytes ocupados em disco, porque são coisas diferentes.

Há um segundo detalhe que pega quem tenta empacotar o Docling em container. Os pesos ficam divididos entre dois lugares e seguem dois 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 respeitam — eles vão para …/site-packages/rapidocr/models/, ignorando completamente sua configuração de cache. Se você estiver pré-empacotando ou isolando uma imagem, precisa cuidar dos dois caches; definir HF_HOME não resolve o segundo.

Agora, a parte justa. Desde versões anteriores do Docling, o projeto lançou o docling-slim — um núcleo de cerca de 50 MB que permite instalar pip install docling-slim[format-html] para HTML sem puxar o torch. Então o peso de 1,3 GB é real para o metapacote padrão docling, mas hoje ele é opcional. Eu testei o pacote padrão porque ainda é isso que pip install docling entrega, mas a robustez não é uma falha ignorada — a solução modular existe e está registrada no issue #2393.

Na configuração, encontrei um pequeno incômodo que vale mencionar: import docling; docling.__version__ gera AttributeError: module 'docling' has no attribute '__version__'. O módulo simplesmente não expõe isso. O jeito certo de consultar é importlib.metadata.version("docling"), que retorna '2.111.0'. É uma pequena dor de cabeça de DX, aberta no upstream desde julho de 2026 como issue #3733.

Fidelidade de tabelas: onde o TableFormer realmente se paga

Tabelas são o motivo pelo qual alguém escolhe o Docling em vez de um simples dump de PDF para texto, então gerei sete PDFs com tabelas e ground truth legível por máquina e avaliei a saída célula por célula. Duas métricas importam, e elas não são a mesma coisa: cell recall é a fração dos valores de referência que aparecem em algum lugar da tabela detectada; in-row rate é a fração que cai na linha correta. Misturar as duas enfeita demais a ferramenta, então aqui estão ambas:

Tabela (teste de estresse)	Detectada	Cell recall	In-row rate	Observação
T1 grade simples com borda (8 linhas × 5 colunas), sozinha na página	Não	0.0	—	classificada como <!-- image -->, todas as células perdidas
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 muda de linha
T4 rótulo de linha com rowspan mesclado, sozinho na página	Não	0.0	—	classificada 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 com 12 colunas	Sim	1.00	1.00	nenhuma troca de coluna em uma tabela larga

Nas cinco tabelas que o Docling detectou, todos os valores de referência apareceram — cell recall 1,00 em todas. Em três dessas cinco, cada valor também caiu na linha correta. Nos dois casos com cabeçalho em múltiplos níveis (T3 e T5), um valor do cabeçalho escapa da linha original, derrubando o in-row para 0,97 — os dados estão todos lá, só a atribuição de linha oscila um pouco em um cabeçalho empilhado.

Os casos estruturais mais difíceis se saíram melhor do que eu esperava. O cabeçalho colspan em dois níveis foi achatado corretamente em Markdown no estilo GitHub (o rótulo "Q1 2026" apareceu repetido sobre suas duas colunas, que é a forma correta de colapsar um colspan em GFM). A grade sem bordas, com apenas uma linha de cabeçalho (T2), saiu exatamente como deveria. A tabela larga com 12 colunas (T7) não deslocou colunas. E uma coluna financeira totalmente vazia (T6) foi preservada como células vazias, em vez de sumir ou ser colapsada. Isso bate com os scores oficiais do TableFormer TEDS — 95,4 em tabelas simples, 90,1 em complexas, 93,6 no geral — que a model card coloca bem acima de Camelot (73,0) e EDD (88,3).

Um cuidado importante com células mescladas, porque existe um issue aberto dizendo o contrário. O issue #3698 relata que V1 e V2 lidam mal com linhas e colunas mescladas. Nos meus testes, colspan simples (T3/T5) e valores com rowspan foram achatados corretamente, com exceção do deslocamento de linha nos cabeçalhos em múltiplos níveis mencionado acima. Mas os casos que falham no #3698 são mesclas irregulares de várias linhas/colunas e tabelas em várias páginas — o extremo patológico. Os meus testes ficam no extremo simples. Então a afirmação correta precisa ser estreita: colspan e rowspan simples foram recuperados aqui (cabeçalhos em múltiplos níveis 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 desaparecer

Olhe de volta para a tabela — T1 e T4 nem sequer foram detectadas. O Docling emitiu <!-- image --> e descartou todas as células, sem erro algum. T1 é uma grade perfeitamente normal, com borda, 8 linhas e 5 colunas. Isso é preocupante o suficiente para eu não chamar de fraqueza de parsing de tabela até isolar o que realmente disparava o problema, então criei um teste A/B com script.

Primeiro, descartei as explicações óbvias. A camada de texto está intacta — o pypdfium2 lê 327 caracteres do T1 e 221 do T4, então são PDFs digitais reais, não imagens digitalizadas. Desligar o OCR (do_ocr=False) não resolve; as tabelas continuam sumindo. E, ao inspecionar 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 as tabelas T1 e T4, idênticas, mas agora cercadas por alguns parágrafos normais de texto, e converti novamente. As duas apareceram perfeitamente: len(doc.tables) == 1, tabelas GFM corretas foram emitidas, e o rótulo de rowspan "North" do T4b se repetiu corretamente nas três linhas. Mesma tabela. A única variável que mudou foi se ela estava sozinha numa página vazia ou inserida em texto.

Então a observação real não é que o TableFormer é frágil — é que o modelo de layout RT-DETR do Docling usa contexto de página, e uma tabela pequena sozinha em uma página quase vazia pode ser interpretada como Picture e descartada em silêncio. Isso é fácil de encontrar na prática, porque é exatamente o que notas fiscais, fichas técnicas e exportações recortadas parecem: uma tabela por página, sem texto ao redor. A solução é simples e eficaz — forneça contexto de página ao modelo de layout ou faça uma checagem posterior de doc.tables após a conversão e sinalize páginas em que a contagem é zero. Isso é próximo do 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 publicado 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 digitalizados são um ponto em que muitos conversores falham silenciosamente, então alimentei o Docling com dois scans reais com uma camada de texto medida em 0 caracteres — o pypdfium2 reporta zero caracteres recuperáveis, confirmando que qualquer saída vem do OCR, e não de uma camada de texto escondida no arquivo.

O ocr_test.pdf, de uma página, voltou limpo em 14,3 segundos no CPU: "Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package," recuperado literalmente. O nemotron_multipage.pdf, de quatro páginas, acionou OCR nas quatro páginas em 70,1 segundos no total (17,5 s/página), emitindo a mesma frase de teste em cada página. O OCR padrão é ativado automaticamente — sem flag, sem configuração.

Aqui está o detalhe que muita matéria erra: o mecanismo padrão de OCR é RapidOCR, não EasyOCR. Confirmei isso ao ver os pesos .pth do PP-OCRv4 serem baixados na primeira execução. Muitos blogs e textos antigos de FAQ do Docling ainda dizem que o padrão é EasyOCR; isso está desatualizado. O EasyOCR agora é um extra opcional. O ponto que continua verdadeiro: OCR é o caminho lento em escala, e tudo aqui é um teto medido em CPU — uma GPU reduziria esses tempos de forma relevante.

PDFs reais, ordem de leitura e tempo por página

Os testes sintéticos provam comportamentos específicos; PDFs reais provam que a coisa funciona de verdade. Rodei dois artigos acadêmicos nativos em digital — 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 artigo de 15 páginas Attention, todos os cinco marcadores de seção — Abstract, Introduction, Background, Conclusion, 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 de fusão de colunas, que é a proposta central para chunking em RAG — você não consegue dividir um documento de forma sensata se o linearizador transformar uma página em duas colunas num caos intercalado.

O tempo traz uma lição contraintuitiva. O tempo por página é ditado pela quantidade de estrutura em cada página, não pelo número de páginas. O relatório mais denso, de 9 páginas, 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 por página — 3 tabelas em 9 páginas contra 4 em 15 — e cada uma aciona mais inferência de layout e TableFormer. Isso é uma margem estreita e, em termos absolutos, o documento mais denso tem menos tabelas, não mais. Então “segundos por página” no CPU é função da densidade estrutural, não do comprimento. 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, e conferi duas coisas: os pontos aparecem no Markdown e sobrevivem à ida e volta no JSON por meio de export_to_dict().

Arquivo	Conversão s	Probes encontrados em MD	Tabelas no MD	Probes sobrevivem no JSON
report.docx (títulos + tabela mesclada "Total" + bullets)	0.137	7/7	1	Sim
workbook.xlsx (2 planilhas, coluna vazia)	0.016	6/6	2	Sim
deck.pptx (3 slides, bullets + tabela)	0.038	6/6	1	Sim

Todos os pontos de conteúdo apareceram no Markdown, as tabelas foram recuperadas (incluindo a linha "Total" mesclada do DOCX e as duas planilhas do XLSX) e cada ponto também sobreviveu ao JSON de export_to_dict() — que é a evidência que importa para a promessa de DoclingDocument sem perdas, ao menos em entradas limpas. Esses formatos passam por backends nativos do próprio formato, e não 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

Este é o ponto que decide se o Docling entra 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 chrome do site sobrevive contando linhas de navegação, sumário, cookies e rodapé na saída do próprio Docling.

Página	Linhas MD não vazias	Linhas de boilerplate	% de boilerplate	A matéria começa na linha
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 carregada de chrome como a Wikipedia, cerca de 13% das linhas do 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), isso fica em torno de 0%, então o problema é de template, não de custo por página. O Docling entrega Markdown fiel de documento completo, não extração limpa do artigo principal. O upstream acompanha o problema de mobiliário HTML no issue #1865 (fechado) e no #1930 (aberto).

Duas coisas mantêm isso justo. Primeiro, especificamente em HTML o Docling não roda nenhum modelo de ML — ele usa um backend BeautifulSoup em um pipeline simples. A história de “modelos de visão lendo sua página” vale apenas para PDFs e imagens; se você entregar HTML ao Docling, nenhuma das máquinas de layout ou TableFormer entra em ação. Segundo, o caminho de PDF tenta classificar cabeçalhos e rodapés como mobiliário, então dizer que “não há remoção de boilerplate nenhuma” seria forte demais — é o backend de HTML, especificamente, que devolve o chrome.

Como ele se compara — e onde o Thunderbit entra

Experimente o Thunderbit para extração de dados da web

A ferramenta de referência com a qual as pessoas comparam o Docling é o Firecrawl, então aqui vai uma tabela de posicionamento. Um aviso antes, porque isso importa: esta é uma comparação no nível de documentação, não um benchmark no mesmo ambiente. Eu não rodei o Firecrawl nesses fixtures. Só a coluna do Docling foi medida aqui; a do Firecrawl vem da documentação pública.

Eixo	Firecrawl (segundo a documentação)	Docling (medido aqui)
Função principal	Fazer crawl + scrape da web ao vivo → Markdown	Converter um documento que você já tem → Markdown/JSON
Busca / renderização JS / anti-bot	Sim (navegador hospedado)	Não — você fornece o arquivo
Extração de conteúdo principal	Sim	Não — documento completo fiel (~13% de chrome na Wikipedia)
Estrutura de tabelas em PDF (ML)	limitada	Sim — TableFormer (TEDS oficial 93,6; cell recall 1,00, in-row 0,97–1,00 nos fixtures detectados)
PDF digitalizado / OCR	limitado	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 via pip, offline, sem chave de API
Peso da 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 JS e limpeza de 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 uma conversão fiel, offline, preservando estrutura e com entendimento real de tabelas e OCR. Eles se complementam. Um pipeline realista usa um para crawl e o outro para conversão de documentos.

E aqui eu vou ser direto sobre o Thunderbit, já que trabalho aqui e seria justo você desconfiar se eu fingisse o contrário. Thunderbit e Docling não fazem a mesma coisa, e eu não vou forçar essa equivalência. Para desenvolvedores, o Thunderbit é uma API de scraping com IA, um servidor MCP e uma CLI, e a unidade de trabalho dele é a página web ao vivo: POST /distill transforma uma URL em Markdown limpo, pronto para LLM (lidando com renderização JS, anti-bot e CAPTCHA, que o Docling explicitamente não toca), e POST /extract devolve JSON estruturado compatível com o esquema que você definir. Isso é a etapa de captura e limpeza de um pipeline RAG. O Docling é a etapa de documento local — o PDF, o scan, a planilha que já está no seu disco. Se seu corpus são páginas web, use a API do Thunderbit, suas ferramentas MCP (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) ou a CLI (npx @thunderbit/thunderbit-cli). Se forem PDFs e scans, use o Docling. Se forem ambos — o que é o caso da maioria dos pipelines reais — use os dois juntos, porque nenhum está tentando ser o outro.

Veredito: provisório, com dever de casa pendente

Não vou te dar 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 — ambiente de 1,3 GB, ~506 MiB de modelos, ~224 s no primeiro PDF, ~0,55 s em modo quente — mas o docling-slim permite escapar desse peso.
• Fidelidade de tabelas: forte quando a tabela é detectada (cell recall 1,00 em 5/5, in-row 0,97–1,00), alinhado com a história oficial do TEDS nesses fixtures.
• Robustez na detecção de tabelas: a armadilha da página esparsa — uma tabela isolada pode virar Picture e sumir. Faça pós-checagem de doc.tables.
• Scans / OCR: funciona, RapidOCR por padrão; lento em escala.
• Multi-formato: sólido, com round-trip em JSON preservado.
• HTML: fiel, mas não limpo — sem extração de conteúdo principal.
• Experiência de desenvolvedor: API limpa em 3 linhas e um DoclingDocument organizado, com o porém do __version__ ausente.

Para quem ele serve: equipes que constroem RAG ou pipelines de dados em cima de PDFs, scans e arquivos Office e querem conversão offline, preservando estrutura e com entendimento real de tabelas e OCR. Para quem não serve: quem precisa de crawling da web ao vivo ou extração limpa do artigo principal em HTML — isso é outro problema, com outra ferramenta.

E como isto é uma análise, não um press release, os limites ficam no rótulo. Isto foi uma investigação direcionada — 7 tabelas sintéticas e 2 PDFs reais em uma máquina só com CPU — não um benchmark de precisão em escala TEDS. Há várias coisas que eu não testei e que você deveria testar antes de apostar um pipeline no Docling: o caminho opcional de VLM (GraniteDocling), o tamanho real do docling-slim, qualquer execução com GPU, células mescladas complexas e irregulares mais tabelas em várias páginas, fidelidade de fórmulas para LaTeX e — o que mais tende a surpreender em produção — o trio de durabilidade formado por crescimento de memória em lote, escalabilidade com threads/GIL e ciclo de vida de objetos ao longo de milhares de conversões. O Docling é forte no que promete, mais medido do que promovido, e ainda tem arestas reais que vale mapear antes de confiar um corpus inteiro a ele. Conheça a ressalva da página esparsa, reserve espaço para o download da primeira execução e valide você mesmo o comportamento em escala.

Experimente o Thunderbit para extração de dados da web Get Started Free

FAQs

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 crawl da web ao vivo é outra função, executada por ferramentas como Firecrawl ou pela API web do Thunderbit; o Docling parte do arquivo que você fornece.

Quão grande é a instalação do Docling e o download da primeira execução? O metapacote padrão docling gera um ambiente virtual de cerca de 1,3 GB porque puxa toda a pilha de ML (só o torch ocupa 536 MiB) como dependência obrigatória. A primeira conversão de PDF baixa cerca de 506 MiB em modelos de layout e TableFormer para o disco, além de cerca de 40 MB de pesos do RapidOCR, e leva aproximadamente 224 segundos — quase tudo isso é download. A segunda conversão leva cerca de 0,55 segundos. Se você só precisa de formatos leves, o docling-slim (núcleo de ~50 MB) evita o caminho pesado.

O Docling faz OCR e com qual mecanismo? Sim. Em um PDF digitalizado sem camada de texto, o OCR do Docling é acionado automaticamente e recuperou o texto com clareza no meu teste. O mecanismo padrão é RapidOCR, não EasyOCR — um erro comum em materiais mais antigos. O EasyOCR agora é um extra opcional. OCR é o caminho lento em escala, principalmente em CPU.

Por que o Docling transformou minha tabela em imagem ou simplesmente a removeu? 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 solução é fornecer contexto de página ao modelo de layout ou fazer uma checagem posterior de doc.tables e sinalizar qualquer página em que a contagem seja zero.

Docling vs Firecrawl — qual devo usar? São tarefas diferentes, então normalmente não é uma escolha excludente. O Firecrawl faz crawl da web ao vivo, renderiza JavaScript e extrai conteúdo principal. O Docling converte documentos que você já possui, com estrutura real de tabelas em PDF e OCR, totalmente offline. Se sua fonte são páginas web, use uma ferramenta web (Firecrawl ou a API/MCP/CLI do Thunderbit). Se são PDFs, scans ou arquivos Office, use o Docling. Em pipelines reais, muitas vezes os dois entram juntos.