Para classificar contratos com IA, comece definindo quais tipos documentais a operação precisa distinguir, como os analistas resolvem ambiguidades e quando o sistema deve pedir revisão. Só depois compare regras, um modelo pronto e fine-tuning, o ajuste de um modelo com exemplos rotulados. Treinar antes de estabilizar essa taxonomia tende a automatizar divergências do cadastro.
O objetivo aqui é encaminhar documentos por tipo, como prestação de serviços, fornecimento, locação ou confidencialidade. Avaliar validade jurídica, encontrar cláusulas abusivas ou extrair obrigações exige outro desenho. Um documento corretamente classificado ainda precisa das verificações previstas pelo responsável pelo processo.
Resumo rápido
- Defina a unidade: arquivo, instrumento contratual ou conjunto com anexos.
- Separe tipo de contrato, situação da assinatura e setor econômico em campos diferentes.
- Escreva regras de inclusão, exclusão e tratamento dos documentos mistos.
- Mantenha versões do mesmo contrato no mesmo grupo de avaliação.
- Compare qualidade por classe, documentos encaminhados e trabalho de revisão antes de treinar.
1. Transforme a fila de documentos em uma taxonomia
Uma taxonomia é um conjunto organizado de categorias com critérios de uso. Para uma primeira implantação, escolha uma decisão concreta: encaminhar o contrato ao time que fará o cadastro, por exemplo. Pergunte quais diferenças mudam esse encaminhamento. Se dois rótulos seguem exatamente o mesmo fluxo e os analistas não conseguem distingui-los de maneira consistente, talvez a separação ainda não ajude.
Não copie automaticamente as pastas existentes. Uma pasta chamada “fornecedor” pode reunir contratos de software, manutenção, compras e documentos fiscais. “Assinado” descreve um estado, enquanto “jurídico” descreve uma área responsável. Misturar essas dimensões obriga a IA a escolher entre categorias que podem ser verdadeiras ao mesmo tempo.
Crie um pequeno dicionário. Cada entrada deve conter um identificador estável, nome legível, definição operacional, exemplos positivos, exemplos parecidos que ficam de fora e destino da revisão. Identificadores como prestacao_servicos evitam que diferenças de acentuação ou abreviação virem categorias novas. Guarde a versão desse dicionário junto de cada previsão.
| Campo | Valores ilustrativos | Regra de organização |
|---|---|---|
| Tipo documental | Prestação de serviços, fornecimento, locação | Identifica a finalidade principal do instrumento |
| Relação documental | Contrato principal, aditivo, anexo | Preserva a conexão com o documento de origem |
| Estado operacional | Minuta, assinado, não verificado | Não substitui a classificação por tipo |
| Encaminhamento | Cadastro, revisão, documento fora do escopo | Determina a próxima etapa sem inventar uma classe jurídica |
Essas categorias são uma proposta de organização para o projeto, não uma taxonomia jurídica oficial. O responsável pela operação precisa adaptá-las aos documentos recebidos. Deixe explícito também se um contrato de software ficará em uma categoria própria ou dentro de serviços; essa escolha deve valer para anotação e produção.
2. Resolva ambiguidades antes de rotular a base
Defina primeiro a unidade de classificação. Um PDF pode conter contrato principal, aditivo e anexos; um contrato pode estar dividido em vários PDFs. Se cada arquivo for tratado como uma unidade independente, um anexo técnico poderá receber um tipo sem ter informação suficiente. Preserve os vínculos disponíveis e encaminhe pacotes incompletos para verificação.
Depois escolha entre classificação de rótulo único e múltiplos rótulos. No primeiro caso, existe uma categoria principal por unidade. No segundo, o documento pode receber mais de uma categoria. Não use múltiplos rótulos apenas para esconder falta de regra. Um contrato misto precisa de uma política: identificar a finalidade predominante, aceitar combinação permitida ou encaminhar para análise.
Separe “outros” de “não foi possível decidir”. “Outros” significa que o documento foi lido e está fora das classes conhecidas. “Texto insuficiente” pode indicar digitalização ruim, páginas ausentes ou falha de extração. “Ambíguo” indica conflito entre regras. Essas razões pedem ações diferentes e ajudam a evitar que o sistema force uma resposta.
Faça uma rodada independente de anotação com pessoas que conheçam o fluxo. Quando discordarem, registrem o trecho que sustentou a decisão e a regra aplicada. Se a regra não resolver, corrijam o dicionário e revisitem exemplos afetados. Não é necessário transformar todo desacordo em reunião: mantenha uma fila de decisões com responsável e data.
Evite usar só o título como evidência. “Contrato de parceria” pode esconder instrumentos muito diferentes, e um modelo pode aprender o nome do escritório no cabeçalho em vez da finalidade. Peça que os anotadores localizem objeto e contexto suficiente para justificar a categoria, sem produzir uma análise jurídica completa.
3. Monte um teste que represente contratos novos
Reserve uma amostra que não será usada para escrever exemplos do prompt, ajustar regras nem escolher parâmetros. O teste precisa conter as classes relevantes, documentos difíceis e casos que devem ser rejeitados. Guarde identificadores, origem, família de minuta, qualidade de extração e decisão dos revisores em um manifesto separado do texto.
Versões quase iguais criam uma armadilha. Se o contrato de um fornecedor aparece no treino e seu aditivo quase idêntico aparece no teste, a avaliação pode medir reconhecimento da minuta. Uma opção é agrupar contratos relacionados e separar os grupos. A documentação do GroupKFold explica a divisão com grupos sem sobreposição entre as partes de treino e teste de cada rodada.
A escolha do grupo depende da pergunta. Para prever documentos de fornecedores desconhecidos, agrupe por fornecedor ou família contratual. Para receber novas versões de minutas conhecidas, avalie também uma separação por período. Não prometa generalização para uma situação que a amostra não representa. Registre essas limitações no relatório para quem vai aprovar o uso.
Inclua PDFs digitalizados, documentos sem título, instrumentos cancelados e arquivos que parecem contratos mas não são. Documente a extração usada. Caso o texto esteja ilegível, marque a falha nessa etapa; atribuí-la ao classificador prejudica o diagnóstico. O teste deve permitir distinguir problema de leitura, de taxonomia e de previsão.
4. Compare alternativas com o mesmo critério
Monte uma referência simples antes de treinar: regras verificáveis, um classificador de texto convencional ou um modelo já disponível com instrução e exemplos. Use o mesmo conjunto de teste e o mesmo processamento dos documentos. Ao comparar sistemas, conte também respostas inválidas, tempo de revisão, necessidade de infraestrutura e comportamento com entradas incompletas.
A documentação da Hugging Face apresenta um fluxo de classificação de texto com Transformers, incluindo preparação dos dados, treinamento e inferência. Esse fluxo é uma referência de implementação; não garante que um modelo treinado em outro domínio funcione com contratos brasileiros. A evidência precisa vir do seu teste.
Uma instrução inicial pode pedir categoria permitida, justificativa curta com trecho localizável e motivo de revisão. Valide a resposta contra o esquema esperado. Se o modelo produzir uma categoria desconhecida, o programa deve rejeitar a saída, sem cadastrá-la automaticamente. Uma justificativa convincente também não substitui a conferência da categoria esperada.
A decisão entre fine-tuning e RAG depende do problema. Consultar documentos para responder perguntas é diferente de aprender fronteiras entre classes. Para esta tarefa, considere ajuste quando os erros persistirem com regras estáveis, houver exemplos confiáveis e o ganho esperado justificar manutenção. Não treine para compensar PDF sem texto ou rótulo contraditório.
5. Exemplo: distribuidora em Campinas organiza contratos
Imagine uma distribuidora de Campinas que recebe contratos de fornecimento de mercadorias, manutenção de equipamentos, locação de galpão e termos de confidencialidade. Este caso é ilustrativo e não apresenta resultados medidos. O cadastro atual usa pastas por fornecedor, o que dificulta encaminhar cada documento ao responsável correto.
A equipe define quatro tipos principais e mantém o vínculo de aditivos em campo separado. Um documento de manutenção com peças incluídas não vira automaticamente “fornecimento”: a regra do projeto exige examinar a finalidade descrita no objeto. Quando compra e serviço tiverem obrigações independentes e a política não resolver o caso, o sistema solicita revisão.
Os analistas anotam uma amostra, discutem divergências e separam famílias de minutas para evitar duplicação entre treino e teste. O responsável por cadastro testa a referência simples com a mesma extração que será usada na operação. O relatório mostra quais confusões exigem correção de regra e quais continuam ocorrendo mesmo com critérios claros.
Na primeira etapa operacional, a IA apenas sugere categoria. A pessoa confirma ou corrige, e a alteração recebe um motivo. Só depois de analisar esse histórico a empresa decide se alguma categoria pode seguir sem intervenção. O limite depende do impacto do erro e da capacidade de revisão, não de uma taxa genérica encontrada em apresentação comercial.
6. Meça erros e transforme o teste em rotina
Não use somente acurácia geral. A matriz de confusão organiza classes reais e previstas para mostrar onde os erros se concentram. Ela ajuda a identificar, por exemplo, fornecimentos encaminhados como serviços. Leia os documentos por trás dessas células antes de mudar o modelo.
O relatório de classificação do scikit-learn reúne precisão, revocação, F1 e quantidade de exemplos por classe. Precisão indica a proporção de acertos entre previsões daquela categoria; revocação indica a parcela dos exemplos reais encontrada. F1 combina precisão e revocação. A média macro dá o mesmo peso às classes, enquanto a ponderada considera seu tamanho.
Meça separadamente a cobertura automática: quantos documentos foram encaminhados sem revisão. Um sistema pode parecer excelente porque rejeita quase tudo; outro pode cobrir mais documentos ao custo de erros caros. Defina limites de qualidade por categoria e volume máximo de revisão antes de escolher a solução. A confiança escrita pelo próprio modelo não deve ser tratada como probabilidade calibrada.
Após mudanças de taxonomia, extração ou modelo, repita o teste e registre a versão. Preserve um conjunto de regressão com casos difíceis, mas acrescente amostras novas para não otimizar apenas para problemas conhecidos. Para a etapa de treinamento, o guia sobre versionar e testar adaptadores LoRA ajuda a estruturar o controle dos artefatos.
Controle acesso aos documentos e evite copiar dados identificáveis para logs sem necessidade. Defina retenção e ambiente aprovado com os responsáveis pela informação. O guia de segurança e LGPD na implantação de IA complementa esse desenho; classificação documental não elimina as regras de tratamento aplicáveis ao acervo.
Erros comuns
- Treinar com nomes de pastas: revise o significado dos rótulos antes de transformá-los em exemplos.
- Separar páginas aleatoriamente: mantenha documentos e versões relacionados no grupo adequado.
- Criar “outros” para qualquer falha: registre se houve documento fora do escopo, ambiguidade ou leitura insuficiente.
- Ignorar classes pequenas: olhe quantidade de exemplos e qualidade por categoria.
- Tratar classificação como parecer: o tipo documental não comprova validade nem adequação das cláusulas.
- Aprender toda correção automaticamente: revise mudanças humanas antes de incorporá-las à próxima base.
Perguntas frequentes
Preciso começar com fine-tuning?
Não. Primeiro estabilize categorias, prepare um teste e estabeleça uma referência simples. O ajuste só faz sentido se melhorar o resultado operacional em comparação com alternativas mais fáceis de manter.
Quantos contratos são necessários?
Não existe quantidade universal. A amostra deve representar classes, variações de redação e casos difíceis. Poucos exemplos de uma categoria não sustentam conclusões firmes sobre seu desempenho, mesmo quando a média geral parece boa.
Um aditivo deve receber a classe do contrato principal?
Depende da regra operacional. Preserve a relação com o principal e diferencie tipo de instrumento de sua finalidade. Se o principal estiver ausente, encaminhe o caso em vez de deduzir conteúdo que não foi recebido.
Posso usar contratos sintéticos no teste?
Use exemplos sintéticos para explorar falhas específicas e situações raras, identificando sua origem. Eles não substituem uma amostra real representativa do recebimento, pois podem reproduzir o estilo de quem os gerou.
Quando liberar encaminhamento automático?
Quando os critérios definidos pelo responsável forem atendidos por categoria, houver controle de versões e existir uma saída de revisão para falhas. Comece por um escopo limitado e acompanhe as correções com documentos novos.
