O que é tarefa de leitura e como ela funciona na prática
A tarefa de leitura é um problema clássico de processamento de linguagem natural em que o modelo recebe um texto (o contexto) e uma pergunta, e precisa produzir a resposta correta extraída ou inferida a partir desse texto. Parece simples até você tentar implementar e descobrir que os benchmarks mais usados escondem uma série de armadilhas que a maioria dos artigos não menciona. O formato mais comum é o qa (pergunta e resposta), mas existem variações como leitura de múltipla escolha, classificação de sentimento baseada no contexto, extração de entidades e até inferência textual (NLI). Cada uma exige ajustes diferentes no pipeline e tem custos de avaliação distintos.
O problema real por trás da tarefa de leitura
O que separa um sistema que funciona em produção de um que quebra no primeiro sinal de entrada fora doDistribution original é a maneira como você prepara os dados e mede o desempenho. A maioria dos tutoriais mostra resultados bonitos no SQuAD 2.0 ou no MNLI, mas raramente explicam que a queda de performance em dados reais pode ser de 30 a 50 pontos percentuais se você não lidar com documentos longos, ambiguidade e respostas que simplesmente não existem no texto. Eu já passei por isso. Tinha um sistema de análise de contratos baseado em tarefa de leitura rodando sobre documentos PDF extraídos com OCR ruim. O modelo ia bem no teste com dados limpos, mas na prática ele alucinava respostas em cerca de 40% dos casos porque o texto original tinha tabulações quebradas, cabeçalhos repetidos e notas de rodapé que confundiam o tokenizer. A solução que funcionou foi adicionar uma etapa de pré-processamento que normalizava o layout antes do tokenization, usando regras específicas para cada tipo de documento, e colocar um filtro de confiança que rejeitava automaticamente predições com score abaixo de 0.65. Isso reduziu as alucinações para algo em torno de 8%, mas aumentou o tempo de processamento de cada documento de cerca de 2 segundos para 11 segundos.
Não existe solução mágica. Você escolhe entre velocidade e precisão, e em alguns casos a resposta certa é simplesmente dizer ao usuário que o sistema não conseguiu encontrar a informação no documento fornecido.
Como construir um pipeline básico
Comece selecionando o modelo adequado para o seu cenário. Para tarefas simples com documentos curtos (até 512 tokens), modelos como o DistilBERT ou o RoBERTa-base fine-tuned em SQuAD são suficientes e rodam em CPU sem problemas. Para documentos mais longos ou perguntas que exigem raciocínio multi-hop, você vai precisar de modelos como o Longformer, o BigBird ou versões fine-tuned do BERT com extensões de contexto longo, e aí o custo computacional sobe consideravelmente. A arquitetura padrão funciona assim: o contexto e a pergunta são concatenados com um separador especial ([SEP] no caso do BERT), o modelo processa o tensor completo e as saídas nos tokens de início e fim são combinadas para gerar o span de resposta. No SQuAD, por exemplo, o modelo prevê dois scores, um para o início e outro para o final do span, e o par com a maior probabilidade conjunta vira a resposta. Quando não há resposta adequada no contexto (como no SQuAD 2.0), o modelo também prevê uma probabilidade de "no answer", e você define um threshold para decidir entre responder ou declarar que não sabe.
O preprocessing é onde a maioria dos erros acontece. Tokenize contexto e pergunta juntos mantendo o alinhamento de tokens, porque o modelo precisa saber exatamente quais tokens do contexto correspondem à resposta. Se você truncar o contexto arbitrariamente, pode cortar a parte que contém a informação relevante. Use o max_length adequado e considere estratégias como sliding window ou chunking quando o documento exceder o limite de tokens do modelo. Para treinamento, comece com datasets como SQuAD 1.1, SQuAD 2.0, CoQA, QuAC ou o MNLI para classificação. O SQuAD 2.0 é essencial porque treina o modelo a reconhecer quando uma resposta não existe, algo que o SQuAD 1.1 não faz. Use learning rate entre 2e-5 e 5e-5, batch size de 16 a 32, e 3 a 5 epochs. Overfitting é comum depois da terceira epoch em datasets pequenos, então monitore o validation EM (exact match) e F1 junto com o training loss.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Métricas que realmente importam
Exact match (EM) e F1 são as métricas padrão, mas elas escondem problemas sérios. O EM exige correspondência por (ou após normalização básica como lowercase e remoção de artigo), o que significa que "Rio de Janeiro" e "rio de janeiro" contam como corretos, mas "Rio" e "cidade do Rio de Janeiro" não contam, mesmo sendo semanticamente equivalentes. O F1 mede a sobreposição de tokens entre a predição e a respostagold, o que é mais tolerante mas ainda assim falho em capturar validade semântica. Para uma avaliação mais honesta, considere adicionar métricas como R@K (recall top-K), BLEU para respostas geradas (não apenas extraídas), e validação humana em uma amostra estratificada dos casos de fronteira. Eu costumo revisar manualmente uns 50 exemplos aleatórios por release para identificar padrões de erro que as métricas automáticas não mostram, como respostas parcialmente corretas mas com informações contraditórias inseridas pelo modelo.
Tarefa de leitura em cenários com documentos longos
Quando o contexto ultrapassa 512 tokens, você tem três opções principais. A primeira é o truncamento simples: corta o texto no limite do modelo. Funciona se a resposta estiver nas primeiras partes do documento, mas falha catastrificamente se estiver no final. A segunda é o sliding window: divide o documento em janelas sobrepostas, processa cada uma separadamente e agrega os resultados. O custo é linear em relação ao número de janelas, então um documento de 10 mil tokens com janela de 512 e stride de 256 gera cerca de 38 passes pelo modelo. A terceira opção é usar modelos nativamente long-contexto, que suportam de 4 mil a 32 mil tokens, mas exigem hardware mais robusto e tempo de inferência maior. Uma técnica que funciona bem na prática é o reranking: primeiro você usa um modelo leve e rápido para identificar os parágrafos mais relevantes (com embedding similarity ou um classificador barato), depois passa apenas esses trechos para o modelo principal. Isso reduz drasticamente o custo computacional mantendo a qualidade quando a resposta está concentrada em poucas seções do documento.
Erros comuns e como evitá-los
Vazar dados de teste no preprocessing é o erro mais frequente. Se você normalizar contexto e resposta usando estatísticas do dataset completo (como vocabulary frequency ou normalization rules calibradas nos dados de teste), suas métricas vão inflar artificialmente. Sempre separe train/dev/test antes de qualquer transformação. Outro erro comum é confiar cegamente no threshold de "no answer". O threshold ótimo varia muito entre domínios. Um threshold de 0.5 que funciona bem em SQuAD pode ser muito agressivo ou muito permissivo em textos médicos ou jurídicos. Calibre o threshold no seu conjunto de validação específico, olhando a curva ROC e escolhendo o ponto que equilibra precisão e recall para o seu caso de uso.
O terceiro erro é não tratar ambiguidade. Perguntas como "quem é o responsável?" podem ter múltiplas respostas válidas no mesmo texto. O modelo vai predizer apenas uma, e se você avaliar só com EM, vai penalizar a predição mesmo quando ambas as respostas estão corretas. Nesse caso, use recall-based metrics ou evaluação manual para casos ambíguos.
Quando a tarefa de leitura não é a solução certa
Se você precisa responder perguntas sobre documentos atualizados frequentemente, manter um sistema de lectura baseado em extração pura vai exigir retrainer constantly. Nessa situação, considere combinar com vetores de embedding e retrieval (RAG), onde o modelo usa um banco vetorial para buscar contextos relevantes antes de fazer a previsão. Isso não elimina os problemas de alucinação, mas reduz significativamente a necessidade de retreinamento periódico. Se o domínio for altamente técnico com terminologia especializada, um modelo geral fine-tuned em SQuAD vai ter desempenho abaixo do esperado. Nesses casos, o custo de coletar dados anotados do domínio específico e fazer fine-tuning targeting o caminho, mas saiba que isso pode levar semanas de trabalho e requer pelo menos alguns milhares de pares pergunta-resposta de qualidade.
O ponto principal é que tarefa de leitura é uma ferramenta útil dentro de um ecossistema maior de processamento de linguagem. Nenhum modelo isolado resolve o problema de entender texto de forma confiável em produção. O que faz a diferença é o pipeline completo: preprocessing rigoroso, avaliação honesta, fallbacks claros e monitoramento contínuo dos casos onde o sistema falha.
