O problema real: a resposta está no documento, não no modelo
Nenhum modelo de linguagem sabe o que está no contrato da sua empresa, no laudo do seu paciente ou na norma interna que você publicou mês passado. Ele sabe português e sabe raciocinar sobre um texto que você entregue. Quando alguém pergunta e o modelo responde sem ter recebido o documento, ele preenche a lacuna com o que é plausível — e plausível não é verdadeiro.
RAG, sigla de geração aumentada por recuperação, é o desenho que resolve isso: antes de responder, o sistema busca os trechos relevantes nos seus documentos e entrega esses trechos ao modelo junto com a pergunta. A resposta passa a ser sobre o seu material, com a origem citável. O termo vem de um artigo de 2020 de Lewis e outros, e virou o padrão de fato para qualquer aplicação que precise responder sobre base própria.
Onde os projetos de RAG falham de verdade
A conversa pública sobre RAG gira em torno de banco vetorial e escolha de modelo. Na prática, a falha mais comum está uma etapa antes: a leitura do documento. Um PDF não é texto — é um conjunto de instruções de desenho. Extrair mal significa perder a estrutura: a tabela vira uma linha contínua de números sem cabeçalho, a nota de rodapé entra no meio do parágrafo, o cabeçalho se repete a cada página e colunas lado a lado se intercalam.
Depois disso, nenhuma escolha de modelo salva. Se o trecho recuperado diz "12 24 36 48" sem dizer que são meses e valores, a resposta vai estar errada com confiança. Em documentos corporativos brasileiros — laudos, contratos, planilhas exportadas, normas com numeração — a informação que importa quase sempre está em tabela ou em estrutura.
A segunda falha mais comum é o recorte. Cortar o documento em pedaços de tamanho fixo separa a pergunta da resposta: a condição fica em um pedaço e a exceção em outro. Recorte que respeita seção, título e tabela resolve boa parte dos erros sem trocar nada do resto da arquitetura.
O que o Docling muda
O Docling é um projeto aberto nascido na pesquisa da IBM e hoje hospedado pela LF AI & Data. Ele faz a etapa que costuma ser subestimada: converter PDF, DOCX, PPTX, planilhas e imagens em uma representação que preserva a estrutura do documento — títulos, seções, listas, ordem de leitura e, principalmente, tabelas como tabelas.
Três coisas o tornam adequado a empresa. Primeiro, roda localmente: o documento não precisa sair da infraestrutura do cliente para ser lido, o que resolve metade das objeções jurídicas em saúde, jurídico e setor público. Segundo, entrega um formato intermediário com a estrutura preservada, de onde dá para gerar Markdown ou JSON para o recorte. Terceiro, trata reconhecimento de tabela e leitura de documento digitalizado como problema de primeira classe, não como extra.
O efeito prático em projeto: a mesma pergunta, o mesmo modelo e o mesmo banco vetorial passam a responder certo porque o trecho recuperado finalmente contém a informação completa. É o melhor retorno por hora investida em um projeto de RAG.
Anonimizar antes de enviar: Presidio e LGPD
Documento corporativo brasileiro vem cheio de dado pessoal: nome, CPF, endereço, telefone, prontuário. Enviar isso para um serviço de IA sem tratamento é problema contratual e de LGPD. A resposta não é desistir do projeto, é separar o que precisa trafegar identificado do que não precisa.
O Microsoft Presidio, também aberto, reconhece e substitui dados pessoais em texto antes do envio, com reconhecedores que dá para ajustar para formatos brasileiros. O desenho que a JBKR usa é: Docling lê e preserva a estrutura, Presidio anonimiza o que for identificável, só então o trecho vai para o modelo — e o que volta é reassociado localmente quando necessário.
Vale dizer o óbvio: anonimizar não dispensa base legal nem contrato. Dispensa, sim, o risco desnecessário de mandar para fora o que não precisava sair.
Como medir se está funcionando
RAG sem avaliação é demonstração, não produto. A avaliação mínima tem duas partes. Recuperação: dado um conjunto de perguntas reais, o trecho certo apareceu entre os recuperados? Se não apareceu, o problema é de leitura ou de recorte, e trocar de modelo não adianta. Resposta: a resposta final está correta e sustentada pelo trecho citado?
Monte de 30 a 50 perguntas reais com a resposta conhecida, tiradas das dúvidas que as pessoas já fazem hoje. Esse conjunto é o ativo mais valioso do projeto: ele permite comparar versões, justificar troca de componente e detectar regressão quando os documentos mudam. Registre também as perguntas sem resposta boa — elas dizem o que falta na base.
E exija citação de origem na interface. Resposta com link para o documento e a página transforma o usuário em revisor; sem isso, erro passa despercebido até virar decisão errada.
O caso clínico da JBKR
A JBKR entregou um assistente de apoio ao diagnóstico que responde perguntas clínicas com base nos documentos da própria instituição — laudos, protocolos e literatura. O desenho é o descrito aqui: Docling para leitura preservando estrutura, Presidio para anonimização, recuperação com citação de origem e revisão humana obrigatória antes de qualquer uso clínico.
A lição que ficou vale para qualquer setor: o ganho não veio de um modelo melhor, veio de ler os documentos direito e de medir a recuperação com perguntas reais antes de ampliar a base.
Por onde começar
Comece por um conjunto pequeno e de alta consulta — a norma que todo mundo pergunta, o manual que gera chamado, o contrato padrão. Converta com Docling, monte 30 perguntas reais, meça a recuperação e só depois escolha o resto da arquitetura. Base grande é o último passo, não o primeiro.
Na JBKR o diagnóstico inicial de 30 minutos é gratuito e, nesse tema, costuma terminar com uma conclusão desconfortável e útil: o problema não é de IA, é de como os documentos estão guardados.
