Saúde

Extração de Dados de PDFs com Ollama e Modelos Open-source: Uma Aplicação Prática na Saúde

Neste artigo, vamos explorar uma abordagem prática para extração de dados estruturados de PDFs usando Python, Ollama e qwen3.5:4b, usando o dataset FDA 510(k) como exemplo.

Evandro Gayer Gomes
Evandro Gayer Gomes
Pipeline de inteligência artificial transformando documentos PDF em dados estruturados em JSON usando Ollama e modelos open-source.

Introdução

Muitas empresas ainda dependem de documentos em PDF para registrar informações importantes sobre produtos, contratos, laudos, relatórios, processos regulatórios, fornecedores e operações internas.

Esses documentos são fáceis de compartilhar e ler, mas nem sempre são fáceis de processar automaticamente. Um PDF pode conter texto selecionável, tabelas, imagens escaneadas, assinaturas, páginas com baixa qualidade visual, campos quebrados entre seções e informações espalhadas ao longo de várias páginas.

Quando uma pessoa lê esse tipo de documento, ela consegue interpretar o contexto, localizar informações relevantes e preencher uma planilha ou sistema. Para um software, esse processo é mais difícil. O sistema precisa transformar o conteúdo visual e textual do documento em dados estruturados, com campos claros, consistentes e prontos para uso.

Neste artigo, vamos explorar uma abordagem prática para extração de dados estruturados de PDFs usando Python, Ollama e modelos open-source, ou de código aberto. O exemplo utiliza documentos públicos do FDA 510(k), um processo regulatório dos Estados Unidos relacionado a dispositivos médicos.

A ideia é mostrar como uma empresa pode combinar extração de texto, OCR (Optical Character Recognition, ou reconhecimento óptico de caracteres), recuperação de contexto, modelos de linguagem e validação de JSON (JavaScript Object Notation, ou Notação de Objeto JavaScript) para transformar documentos regulatórios em dados organizados.

Também vamos discutir por que modelos locais podem ser uma alternativa interessante para reduzir custos em comparação com o uso exclusivo de APIs (Application Programming Interfaces, ou interfaces de programação de aplicações) comerciais de modelos como OpenAI, Anthropic ou Google Gemini.

O foco do artigo é acessível para pessoas não técnicas, mas algumas seções incluem comandos e scripts para demonstrar como a solução foi implementada em um repositório de exemplo.

Quais os desafios presentes na extração de dados de documentos em PDF?

PDFs foram criados para preservar a aparência de um documento. Eles mantêm layout, fontes, imagens, tabelas, cabeçalhos, rodapés e outros elementos visuais. Isso é útil para leitura humana, impressão e distribuição oficial de documentos.

Para automação, porém, essa característica pode trazer dificuldades.

Um PDF pode ter texto nativo. Nesse caso, o texto está armazenado internamente no arquivo e pode ser selecionado, copiado ou extraído por bibliotecas de programação. Esse é o cenário mais simples.

Mas muitos documentos chegam em outro formato: páginas escaneadas, imagens inseridas dentro do PDF, cópias antigas, arquivos comprimidos, documentos com baixa resolução ou relatórios gerados por sistemas que não preservam uma estrutura textual limpa.

Nesses casos, o sistema pode enxergar uma página inteira apenas como imagem. O conteúdo está visível para uma pessoa, mas não está disponível como texto para o software. Para recuperar essas informações, normalmente é necessário usar OCR (Optical Character Recognition, ou reconhecimento óptico de caracteres).

OCR é a técnica usada para identificar letras, números e palavras dentro de imagens. Ele pode funcionar bem em documentos claros, mas tende a falhar quando a imagem está torta, borrada, comprimida, com sombras, baixa resolução ou tabelas complexas.

Além da qualidade visual, existem outros desafios comuns:

  • informações importantes aparecem em lugares diferentes dependendo do documento;
  • campos podem estar espalhados entre várias páginas;
  • tabelas podem ser difíceis de interpretar;
  • cabeçalhos e rodapés podem gerar ruído;
  • nomes de campos podem variar entre documentos;
  • documentos longos podem exceder o limite de contexto de modelos de linguagem;
  • modelos podem devolver respostas incompletas ou em formato inválido;
  • dados críticos precisam de evidência e revisão humana.

Em processos empresariais, esses problemas têm impacto operacional direto. Quanto maior o volume de documentos, maior o tempo gasto com leitura manual, conferência, digitação, retrabalho e validação.

Na área da saúde, esse desafio aparece com frequência em documentos regulatórios, materiais técnicos, laudos, registros de produtos, manuais, documentos de fornecedores e relatórios de conformidade. Mesmo quando esses documentos seguem algum padrão, a extração automática ainda precisa lidar com variações de formato e qualidade.

De documentos não estruturados para dados estruturados

Grande parte dos documentos usados em empresas contém dados não estruturados ou semi-estruturados.

Dados não estruturados aparecem em formato livre, como parágrafos, descrições técnicas, observações, justificativas ou textos narrativos. Dados semi-estruturados têm alguma organização visual, como seções, tabelas, campos e tópicos, mas ainda não estão prontos para serem usados diretamente por um sistema.

Um sistema interno normalmente precisa de dados estruturados. Em vez de receber um PDF inteiro, ele precisa de campos específicos.

Em um documento regulatório de dispositivo médico, por exemplo, pode ser útil extrair:

  • número da submissão;
  • nome do dispositivo;
  • empresa responsável;
  • data de decisão;
  • código do produto;
  • número da regulação;
  • classe regulatória;
  • indicação de uso;
  • descrição técnica;
  • dispositivos de referência;
  • evidências encontradas no documento.

Esses campos podem ser armazenados em um banco de dados, exibidos em um painel, enviados para um fluxo de aprovação, usados em uma busca interna ou integrados com outros sistemas.

Um exemplo simplificado de saída estruturada em JSON (JavaScript Object Notation, ou Notação de Objeto JavaScript) seria:

{
  "document_type": "FDA 510(k) summary",
  "submission_number": "K220646",
  "device_name": "Play & Joy InvisiLube Lubricant Capsule",
  "applicant": "InnoveMed Bio-tech Co., Ltd.",
  "decision_date": "2023-07-10",
  "product_code": "NUC",
  "regulation_number": "21 CFR 884.5300",
  "regulatory_class": "Class II"
}

JSON é um formato muito usado por APIs, aplicações web e sistemas corporativos. Ele organiza dados em pares de chave e valor, facilitando o envio de informações entre sistemas.

A extração estruturada de PDFs segue uma sequência lógica:

  1. obter o documento;
  2. identificar se há texto nativo;
  3. aplicar OCR quando necessário;
  4. dividir o conteúdo em partes menores;
  5. localizar trechos relevantes;
  6. enviar esses trechos para um modelo de linguagem;
  7. solicitar uma saída em formato estruturado;
  8. validar o resultado;
  9. registrar evidências e diagnósticos.

Essa abordagem evita tratar o modelo de inteligência artificial como uma solução isolada. O modelo faz parte de um fluxo maior, com preparação do documento, busca de contexto, controle de formato e tratamento de falhas.

Para quem está começando na área, alguns conceitos de inteligência artificial, modelos de linguagem, tokens e prompts foram explicados em mais detalhes no artigo Inteligência Artificial: Entendendo os Conceitos Principais.

Exemplo: extração de dados estruturados do dataset FDA 510(k)

Para tornar o exemplo mais próximo de um cenário real, este artigo utiliza documentos públicos do FDA 510(k).

A FDA, sigla de Food and Drug Administration, é a agência regulatória dos Estados Unidos responsável por regular, entre outras áreas, dispositivos médicos. Dispositivo médico é qualquer instrumento, aparelho, software, implante ou artigo similar (e seus acessórios) que não atue por meios químicos (como um medicamento) no corpo humano.

O 510(k) é uma submissão pré-mercado usada por fabricantes para demonstrar que um dispositivo médico é substancialmente equivalente a outro dispositivo já legalmente comercializado. Esse dispositivo usado como referência é chamado de predicate device, ou dispositivo de referência.

Em termos práticos, a empresa apresenta informações sobre o dispositivo, seu uso pretendido, características tecnológicas, fabricante, classificação regulatória e comparação com dispositivos semelhantes. A FDA avalia essas informações para determinar se o dispositivo pode ser comercializado nos Estados Unidos dentro daquele caminho regulatório.

Esse dataset (conjunto de dados) é interessante para uma prova de conceito por três motivos.

Primeiro, ele usa documentos reais e públicos da área da saúde, sem depender de prontuários, dados clínicos privados ou informações sensíveis de pacientes.

Segundo, os documentos possuem campos recorrentes, o que permite definir um schema (estrutura esperada) de extração. Um schema é a estrutura esperada para o resultado final, como uma lista de campos obrigatórios e opcionais.

Terceiro, os PDFs ainda representam desafios comuns de automação documental. Mesmo em um domínio regulatório, os documentos podem ter seções narrativas, tabelas, campos técnicos e variações de layout.

O repositório usado como base para este artigo está disponível em: https://github.com/evgomes/pdf-data-extraction-ollama

Ele implementa um pipeline (fluxo de processamento) em Python para baixar documentos do FDA 510(k), preparar os arquivos, extrair texto, aplicar OCR quando necessário, recuperar trechos relevantes e gerar JSON estruturado usando Ollama e um modelo open-source (de código aberto).

O exemplo inicial usa o registro K220646, referente ao dispositivo Play & Joy InvisiLube Lubricant Capsule. O pipeline tenta extrair campos como número da submissão, nome do dispositivo, empresa solicitante, data de decisão, código do produto, número da regulação, classe regulatória, indicação de uso, descrição técnica e dispositivos de referência.

Por que usar Ollama e modelos open-source?

Ollama é uma ferramenta que facilita a execução local de modelos de linguagem. Em vez de depender apenas de uma API externa, a empresa pode baixar modelos compatíveis e executá-los em uma máquina local, servidor interno ou ambiente controlado.

Um modelo de linguagem é um sistema de inteligência artificial treinado para interpretar e gerar texto. No contexto deste artigo, ele recebe trechos relevantes do PDF e retorna dados organizados em JSON.

O ponto central é que a inferência pode acontecer localmente.

Inferência é o momento em que o modelo recebe uma entrada e gera uma resposta. Quando uma empresa usa uma API comercial, normalmente paga por uso, com base em tokens, chamadas ou volume processado. Em projetos com muitos documentos, esse custo variável pode crescer rapidamente.

Com um modelo local, a empresa passa a ter outro perfil de custo. Ainda existem custos de hardware (equipamento), energia, configuração, manutenção e equipe técnica, mas o custo incremental por documento pode ser menor quando o volume é alto ou recorrente.

Além do custo, existem outros benefícios potenciais:

  • maior controle sobre onde os dados são processados;
  • menor dependência de provedores externos;
  • possibilidade de manter versões fixas de modelo e pipeline;
  • adaptação do fluxo para tipos específicos de documentos;
  • uso de infraestrutura própria em cenários com restrições de segurança.

Isso não significa que modelos open-source sejam sempre melhores. Modelos comerciais avançados, como os da OpenAI, Anthropic e Google, podem entregar resultados superiores em tarefas complexas, documentos difíceis, raciocínio mais longo e interpretação multimodal avançada.

A decisão mais realista costuma ser técnica e econômica. Para tarefas repetitivas, bem delimitadas e com alto volume, um modelo local pode oferecer boa relação entre qualidade e custo. Para documentos mais difíceis ou casos de exceção, modelos comerciais podem ser usados como fallback (plano de contingência) ou camada premium de processamento.

Esse desenho híbrido costuma fazer sentido em empresas: modelos locais processam a maior parte do volume, enquanto modelos mais caros são reservados para casos em que a qualidade adicional justifica o custo.

Para o código de exemplo, eu optei por usar o modelo qwen3.5:4b.

Por que escolher o qwen3.5:4b neste exemplo?

O repositório usa o modelo qwen3.5:4b como baseline (referência inicial).

Baseline significa ponto de partida. Não quer dizer que o modelo seja necessariamente o melhor para todos os cenários. Ele serve como uma referência inicial para testar o pipeline, medir qualidade, identificar limitações e comparar alternativas.

A escolha faz sentido para uma prova de conceito porque o qwen3.5:4b é um modelo relativamente leve dentro da família Qwen 3.5. Na página do Ollama, ele aparece com cerca de 4,66 bilhões de parâmetros, quantização Q4_K_M e aproximadamente 3,4 GB.

Alguns termos merecem explicação.

Parâmetros são valores internos aprendidos pelo modelo durante o treinamento. Em geral, modelos maiores tendem a ter mais capacidade, mas também exigem mais memória, processamento e infraestrutura.

Quantização é uma técnica usada para reduzir o tamanho e o consumo de memória do modelo. Ela permite rodar modelos em hardware mais acessível, normalmente com algum compromisso entre eficiência e qualidade.

Q4_K_M é um formato de quantização comum em modelos locais. Para uma pessoa não técnica, o ponto principal é simples: o modelo fica menor e mais viável para execução local.

Um modelo de 4B, ou cerca de quatro bilhões de parâmetros, não deve ser tratado como equivalente a modelos comerciais de fronteira. Ele pode falhar em documentos complexos, imagens ruins, tabelas difíceis ou instruções ambíguas. Mesmo assim, pode ser útil em tarefas bem definidas quando recebe contexto selecionado, instruções objetivas e validações ao redor.

Essa é a ideia do projeto: em vez de esperar que um modelo pequeno resolva tudo sozinho, o pipeline prepara o documento, seleciona os trechos relevantes e pede uma saída objetiva em JSON.

Com hardware melhor, outras alternativas podem ser avaliadas. Modelos maiores da própria família Qwen, versões maiores de Llama, Gemma, Mistral ou outros modelos compatíveis com Ollama podem melhorar qualidade, robustez e capacidade de interpretação. A escolha ideal depende de testes com documentos reais, medindo acurácia, tempo de resposta, consumo de memória, custo operacional e taxa de falhas.

Resumindo: a ideia aqui é usar um modelo que não exija hardware poderoso para processamento, mas que seja eficiente o bastante para processar os documentos que precisamos, sem resultar em custos extras além do consumo de energia elétrica e do próprio hardware.

Estrutura do repositório

O projeto foi organizado de forma simples para facilitar o entendimento e a adaptação.

A estrutura principal é:

.
+-- data/
|   +-- sources.json
+-- schemas/
|   +-- fda_510k.schema.json
+-- scripts/
|   +-- download_dataset.py
|   +-- find_fda_510k_samples.py
|   +-- prepare_pdf.py
|   +-- extract_510k.py
+-- src/
|   +-- pdf_data_extraction_demo/
|       +-- json_tools.py
|       +-- ollama_client.py
|       +-- pdf_processing.py
|       +-- rag.py
+-- requirements.txt
+-- README.md

O arquivo data/sources.json funciona como um manifesto do dataset. Ele informa quais documentos devem ser baixados, de onde eles vêm e qual nome será usado localmente.

O script download_dataset.py baixa os PDFs definidos nesse manifesto.

O script prepare_pdf.py prepara o PDF para processamento. Ele extrai texto nativo, renderiza páginas como imagens e, quando solicitado, cria versões degradadas para simular documentos com baixa qualidade visual.

O script extract_510k.py executa a extração principal. Ele monta o fluxo de RAG (Retrieval-Augmented Generation, ou geração aumentada por recuperação), chama o modelo via Ollama, tenta gerar JSON estruturado e registra diagnósticos.

O módulo ollama_client.py concentra a comunicação com o Ollama.

O módulo pdf_processing.py reúne funções relacionadas ao processamento de PDFs, como extração de texto e renderização de páginas.

O módulo rag.py implementa a divisão do texto em chunks (pedaços de texto) e a recuperação de trechos relevantes com BM25.

O módulo json_tools.py ajuda a extrair, reparar e validar respostas em JSON vindas do modelo.

Essa separação é importante porque torna o projeto mais fácil de evoluir. Em uma aplicação real, a mesma arquitetura poderia ser adaptada para outros documentos da área da saúde, como materiais técnicos, registros de fornecedores, documentos de conformidade, relatórios internos ou manuais de dispositivos.

Como preparar o ambiente

O projeto usa Python e Ollama.

Python é uma linguagem de programação bastante usada em automação, dados e inteligência artificial.

Primeiro, clone o repositório para um diretório do seu computador:

git clone https://github.com/evgomes/pdf-data-extraction-ollama.git
cd pdf-data-extraction-ollama

Depois, crie um ambiente virtual:

python -m venv .venv

Um ambiente virtual é uma pasta isolada com as bibliotecas do projeto. Isso evita conflitos com outras aplicações instaladas no mesmo computador.

No Windows PowerShell, ative o ambiente com:

.\.venv\Scripts\Activate.ps1

No Windows Command Prompt:

.\.venv\Scripts\activate.bat

No macOS ou Linux:

source .venv/bin/activate

Depois, instale as dependências:

pip install -r requirements.txt

Com o Ollama instalado e em execução, baixe o modelo usado no exemplo:

ollama pull qwen3.5:4b

Essa etapa baixa o modelo para a máquina local. A partir daí, o pipeline pode chamá-lo por meio da API local do Ollama.

Baixando o dataset de exemplo

Depois que o ambiente está pronto, o primeiro passo é baixar o PDF público usado no exemplo:

python scripts/download_dataset.py

A saída esperada é parecida com:

downloading: https://www.accessdata.fda.gov/cdrh_docs/pdf22/K220646.pdf
saved: .../data/raw/fda_k220646.pdf

Se o arquivo já existir, o script informa que ele já foi baixado:

exists: .../data/raw/fda_k220646.pdf

Essa etapa parece simples, mas é relevante em um projeto real. A ingestão de documentos precisa ser reproduzível. O sistema deve saber de onde cada arquivo veio, qual documento foi baixado, onde ele foi salvo e como será identificado nas etapas seguintes.

Em uma empresa, essa lógica poderia ser adaptada para buscar documentos em um portal interno, sistema de gestão documental, bucket (repositório de arquivos em nuvem), e-mail, API de fornecedor ou fluxo de upload (envio de arquivos).

Preparando arquivos para processamento

Depois do download, o PDF precisa ser preparado:

python scripts/prepare_pdf.py data/raw/fda_k220646.pdf --degrade

A saída esperada é:

pages: 7
native text chars: 13425
output: .../data/processed/fda_k220646

Essa etapa gera artefatos como:

data/processed/fda_k220646/pages.jsonl
data/processed/fda_k220646/pages/page_001.png
data/processed/fda_k220646/degraded_pages/page_001.png

O arquivo pages.jsonl guarda o texto extraído por página. JSONL (JSON Lines, ou JSON por linhas) é uma variação do JSON em que cada linha representa um registro independente. Esse formato é útil para processar grandes volumes de documentos de forma incremental.

As imagens em pages/ representam as páginas renderizadas do PDF. Elas são úteis para testes visuais, OCR e comparação entre texto nativo e imagem.

As imagens em degraded_pages/ simulam documentos com qualidade inferior. Isso ajuda a testar situações próximas da realidade, como digitalizações antigas, PDFs comprimidos, anexos enviados por terceiros ou páginas com baixa nitidez.

Essa etapa é importante porque o pipeline precisa saber lidar com dois cenários: documentos com texto nativo e documentos que dependem de interpretação visual.

Quando há texto nativo, o caminho costuma ser mais rápido, barato e confiável. Quando o documento está escaneado ou degradado, o OCR pode ser necessário, mas tende a exigir mais processamento e validação.

Esse ponto também se conecta ao tema de visão computacional, área da inteligência artificial voltada à análise de imagens e vídeos. No caso deste artigo, porém, o foco visual está nas páginas dos documentos, e não em cenas do mundo físico.

Rodando a extração

O caminho mais simples é executar a extração em modo texto:

python scripts/extract_510k.py data/raw/fda_k220646.pdf --model qwen3.5:4b --mode text --output outputs/fda_k220646_text.json

A saída esperada é:

wrote: outputs/fda_k220646_text.json

Nesse modo, o pipeline usa o texto nativo extraído do PDF. Esse costuma ser o melhor cenário quando o documento possui texto selecionável.

O resultado é um arquivo JSON com os dados extraídos e informações de diagnóstico. Um exemplo simplificado dos campos principais seria:

{
  "document_type": "FDA 510(k) summary",
  "submission_number": "K220646",
  "device_name": "Play & Joy InvisiLube Lubricant Capsule",
  "applicant": "InnoveMed Bio-tech Co., Ltd.",
  "decision_date": "2023-07-10",
  "product_code": "NUC",
  "regulation_number": "21 CFR 884.5300",
  "regulatory_class": "Class II"
}

Além dos dados extraídos, o arquivo de saída também pode incluir informações como:

  • selected_chunks: trechos selecionados e enviados ao modelo;
  • diagnostics: mensagens de diagnóstico;
  • parse_error: erro ao interpretar a resposta, se houver;
  • raw_model_response: resposta original do modelo;
  • data: objeto final com os dados estruturados.

Esses dados de diagnóstico são importantes para auditoria e melhoria contínua. Em automação documental, não basta saber que um JSON foi gerado. É preciso saber em quais trechos o modelo se baseou, quais campos ficaram incertos, se houve erro de parsing (interpretação da resposta) e quais documentos precisam de revisão humana.

Como o RAG entra no processo

RAG significa Retrieval-Augmented Generation, ou geração aumentada por recuperação.

A ideia é simples: antes de pedir uma resposta ao modelo, o sistema busca os trechos mais relevantes do documento. Assim, o modelo recebe um contexto menor, mais focado e mais útil.

No projeto, o texto do PDF é dividido em chunks (pedaços de texto). Depois, o BM25 é usado para recuperar os trechos mais próximos das consultas de extração.

BM25 é um algoritmo clássico de busca textual. Ele ajuda a encontrar partes do documento que têm maior relação com termos importantes.

As consultas usadas no projeto são parecidas com:

EXTRACTION_QUERIES = [
    "510(k) Number Device Name Applicant Decision Date Product Code Regulation Number Regulatory Class",
    "Indications for Use Describe prescription over the counter use",
    "Predicate Device Information device name 510(k) number manufacturer",
    "Device Description technological characteristics specifications table performance testing",
]

Em português, essas consultas buscam informações como:

  • número do 510(k), nome do dispositivo, solicitante, data de decisão, código do produto, número da regulação e classe regulatória;
  • indicação de uso, descrição do uso, prescrição ou uso sem prescrição;
  • informações dos dispositivos de referência, incluindo nome, número do 510(k) e fabricante;
  • descrição técnica, características tecnológicas, especificações e testes de desempenho.

Esse fluxo reduz ruído. Em vez de enviar o PDF inteiro para o modelo, o sistema envia os trechos com maior chance de conter os campos desejados.

Isso também melhora o custo-benefício. Quanto menor e mais relevante for o contexto enviado ao modelo, menor tende a ser o custo computacional e maior tende a ser a previsibilidade da resposta.

Testando PDFs com qualidade de imagem baixa

O projeto também permite testar um caminho híbrido, combinando texto nativo e OCR visual:

python scripts/extract_510k.py data/raw/fda_k220646.pdf --model qwen3.5:4b --mode hybrid --degrade-images --vision-ocr --max-ocr-pages 4 --max-image-pages 0 --ollama-timeout 30 --output outputs/fda_k220646_bad_image.json

A saída esperada é parecida com:

vision OCR page 1: page_001.png
vision OCR page 2: page_002.png
vision OCR page 3: page_003.png
vision OCR page 4: page_004.png
wrote: outputs/fda_k220646_bad_image.json

Nesse modo, o sistema tenta transcrever o texto visível nas imagens das páginas. O prompt (instrução enviada ao modelo) de OCR é objetivo:

Transcribe all visible text from this PDF page. Preserve section headings, table rows, numbers, units, and field labels. If text is unreadable, mark it as [unreadable]. Return plain text only.

Em português, a instrução seria:

Transcreva todo o texto visível desta página do PDF. Preserve títulos de seção, linhas de tabelas, números, unidades e rótulos de campos. Se algum texto estiver ilegível, marque como [ilegível]. Retorne apenas texto simples.

Essa etapa tem um objetivo específico: transcrever o conteúdo visível. Ela não deve resumir, interpretar ou preencher lacunas. A interpretação acontece depois, na etapa de extração estruturada.

Separar essas responsabilidades ajuda a reduzir erros. Quando o mesmo prompt tenta transcrever, interpretar, resumir e estruturar ao mesmo tempo, aumenta a chance de o modelo omitir detalhes ou inventar informações.

O caminho visual é mais exigente que o caminho textual. Ele pode consumir mais tempo, exigir mais memória e falhar em hardware modesto. Por isso, o pipeline registra diagnósticos e pode continuar usando texto nativo quando disponível.

Em uma solução real, esse tipo de fallback (plano de contingência) é essencial. Documentos empresariais raramente chegam todos no mesmo padrão de qualidade.

O prompt de extração final

Na etapa principal, o modelo recebe trechos relevantes do documento e uma instrução para devolver JSON válido.

A instrução de sistema usada no projeto é curta:

You extract regulated-document data. Return valid JSON only. Do not invent missing values.

Em português:

Você extrai dados de documentos regulados. Retorne apenas JSON válido. Não invente valores ausentes.

Essa instrução define três regras importantes.

A primeira é o papel do modelo: extrair dados de documentos regulados.

A segunda é o formato de saída: JSON válido.

A terceira é uma regra contra alucinação: o modelo não deve inventar valores quando a informação não estiver presente no contexto.

O prompt principal também define os campos esperados, como:

  • submission_number: número da submissão;
  • device_name: nome do dispositivo;
  • applicant: solicitante ou empresa responsável;
  • decision_date: data de decisão;
  • product_code: código do produto;
  • regulation_number: número da regulação;
  • regulatory_class: classe regulatória;
  • indications_for_use: indicações de uso;
  • predicate_devices: dispositivos de referência;
  • device_description: descrição do dispositivo;
  • performance_or_specifications: desempenho ou especificações;
  • evidence: evidências usadas para justificar a extração;
  • warnings: avisos ou pontos de atenção.

O campo evidence merece destaque. Em um processo empresarial, é importante saber de onde veio cada informação. Se o modelo extraiu uma data, um código ou uma classe regulatória, o sistema deve preservar evidências para facilitar revisão humana e auditoria.

Isso é ainda mais importante na saúde, onde decisões podem envolver risco regulatório, segurança, conformidade e responsabilidade técnica.

O que acontece quando o modelo falha

Modelos de linguagem podem falhar.

Eles podem demorar demais, devolver uma resposta vazia, gerar JSON inválido, ignorar uma instrução, confundir campos ou ter dificuldade com documentos de baixa qualidade.

Por isso, o pipeline não assume que a resposta do modelo sempre virá correta. Ele considera situações como:

  • timeout (tempo limite excedido) na chamada ao modelo;
  • resposta vazia;
  • JSON malformado;
  • contexto grande demais;
  • falha no OCR visual;
  • resposta fora do formato esperado;
  • necessidade de reparo de JSON;
  • campos ausentes ou incertos.

Esse cuidado aproxima o exemplo de uma arquitetura real. Em uma solução real, precisamos garantir que o pipeline seja resiliente, evitando interrupções caso haja uma falha em um único documento, ou uma falha intermitente. Lembre-se: modelos de inteligência artificial não são determinísticos, então é preciso preparar as soluções para cenários de falha e para novas tentativas quando necessário.

Aplicações na área da saúde

Na saúde, muitos processos dependem de documentos extensos, técnicos e regulatórios. Isso inclui documentos de dispositivos médicos, materiais técnicos, registros de fornecedores, protocolos, laudos, manuais, relatórios, certificados, submissões e documentos de conformidade.

Um pipeline como o demonstrado neste artigo pode ajudar em tarefas como:

  • organizar metadados de documentos regulatórios;
  • extrair campos técnicos de documentos de produtos;
  • criar bases pesquisáveis a partir de PDFs;
  • apoiar revisão de fornecedores;
  • comparar documentos similares;
  • identificar campos ausentes;
  • alimentar sistemas internos de compliance (conformidade);
  • acelerar a triagem documental antes da revisão humana;
  • preservar evidências para auditoria.

No exemplo do FDA 510(k), o objetivo é extrair dados de documentos públicos sobre dispositivos médicos. Em uma empresa da área da saúde, a mesma lógica poderia ser adaptada para outros tipos de documentos, desde que haja cuidado com segurança, privacidade e governança.

Esse ponto é importante. Documentos de saúde podem conter dados sensíveis. No Brasil, a LGPD, Lei Geral de Proteção de Dados, exige atenção especial no tratamento de dados pessoais e dados relacionados à saúde. Em outros países, existem regras próprias, como a HIPAA, Health Insurance Portability and Accountability Act, nos Estados Unidos em determinados contextos.

Rodar modelos localmente pode ajudar no controle sobre onde os dados são processados, mas isso não elimina a necessidade de políticas de segurança. É necessário definir permissões de acesso, registrar logs (registros de eventos), proteger arquivos, classificar documentos, limitar o uso de dados sensíveis e manter revisão humana em decisões críticas.

A aplicação também pode ser adaptada para outras áreas de negócio que dependem de PDFs, como jurídico, financeiro, seguros, indústria e compras. O padrão operacional é parecido: documentos estáticos são transformados em dados estruturados para alimentar sistemas, indicadores, buscas internas e fluxos de trabalho.

Impacto operacional e financeiro

A extração estruturada de PDFs pode gerar ganhos práticos em empresas que lidam com grande volume de documentos.

O primeiro ganho é redução de trabalho manual. Quando um sistema consegue pré-preencher campos, localizar informações relevantes e apontar evidências, a equipe pode revisar em vez de digitar tudo do zero.

O segundo ganho é velocidade. Documentos que antes precisavam ser lidos individualmente podem passar por uma triagem automática inicial.

O terceiro ganho é padronização. Campos extraídos em JSON podem seguir uma estrutura comum, facilitando comparação entre documentos diferentes.

O quarto ganho é rastreabilidade. Ao preservar evidências e diagnósticos, o processo fica mais auditável.

O quinto ganho é custo. Em APIs comerciais, o custo cresce conforme o volume processado. Em modelos locais, o custo fica mais associado à infraestrutura. Para volumes recorrentes, isso pode tornar o processamento mais previsível.

Ainda assim, a decisão entre modelos locais e modelos comerciais deve ser feita com métricas. Alguns critérios importantes são:

  • qualidade da extração;
  • custo por documento;
  • tempo de resposta;
  • consumo de memória;
  • taxa de falhas;
  • esforço de manutenção;
  • complexidade do documento;
  • sensibilidade dos dados;
  • necessidade de auditoria;
  • disponibilidade de equipe técnica.

Em muitos casos, a melhor estratégia pode ser híbrida. Modelos locais processam documentos mais simples e recorrentes. Modelos comerciais mais avançados são usados para documentos difíceis, casos de exceção ou validações de maior valor.

Limitações e cuidados

Apesar dos bons resultados em um exemplo controlado, existem limitações importantes.

Documentos escaneados podem exigir OCR mais robusto. Tabelas complexas podem precisar de tratamento específico. PDFs longos podem exigir estratégias melhores de chunking (divisão em pedaços) e recuperação. Campos críticos podem precisar de validação determinística. Dados sensíveis exigem governança, segurança e controle de acesso.

Também é importante testar o pipeline com documentos reais do domínio desejado. Um modelo que funciona bem em documentos do FDA 510(k) pode não funcionar da mesma forma em laudos, editais, contratos, manuais técnicos ou relatórios internos.

Em uma solução real, seria recomendável adicionar:

  • versionamento de prompts;
  • testes automatizados com documentos conhecidos;
  • comparação entre modelos;
  • validações por campo;
  • trilha de auditoria;
  • revisão humana para campos sensíveis;
  • métricas de acurácia;
  • classificação de sensibilidade dos documentos;
  • controle de permissões;
  • monitoramento de falhas e custos;
  • fallback para modelos mais fortes quando necessário.

Se você trabalha em um cenário onde precisa automatizar extração de dados de documentos em PDF, e gostaria de avaliar opções similares a essa, pode entrar em contato conosco, podemos ajudar.

Conclusão

PDFs continuam sendo uma barreira importante para automação de processos em empresas. Eles concentram informações úteis, mas muitas vezes em formatos difíceis de integrar com sistemas.

O exemplo com documentos públicos do FDA 510(k), Python, Ollama e qwen3.5:4b mostra uma abordagem prática para transformar PDFs em dados estruturados. O pipeline combina extração de texto, renderização de páginas, OCR opcional, RAG, BM25, prompts objetivos, JSON estruturado, diagnóstico e tratamento de falhas.

Essa combinação é mais robusta do que simplesmente enviar um documento inteiro para um modelo e esperar uma resposta perfeita. O valor está no fluxo completo: preparar o documento, selecionar os trechos certos, extrair campos relevantes, validar a saída, registrar evidências e permitir revisão.

Para empresas da área da saúde, esse tipo de solução pode apoiar análise de documentos regulatórios, revisão de fornecedores, organização de bases documentais e processos de compliance. Para outras áreas, o mesmo padrão pode ser adaptado sempre que houver volume relevante de PDFs e necessidade de transformar leitura manual em dados operacionais.

Modelos open-source executados localmente não substituem todos os cenários de modelos comerciais, mas podem oferecer uma alternativa viável para tarefas bem delimitadas, especialmente quando custo, volume, privacidade e controle operacional são fatores importantes.

Fontes

Leia Mais

Link copiado