Unsloth e QLoRA podem ser usados para adaptar um modelo de linguagem à classificação de documentos de seguros, desde que exista um conjunto de exemplos bem rotulados e uma avaliação separada do treinamento. O primeiro passo é definir exatamente o que será classificado: tipo de documento, assunto de uma cláusula ou família de produto. A adaptação não deve transformar um rótulo documental em decisão sobre cobertura ou pagamento.
Para uma equipe brasileira, o projeto começa na organização de contratos e apólices em português. O resultado esperado pode ser uma categoria controlada e o trecho que a sustenta. A qualidade precisa ser medida em documentos que o treinamento não viu, incluindo versões diferentes e casos em que a resposta correta é encaminhar para revisão.
Resumo rápido
- Defina uma taxonomia documental antes de escolher parâmetros de treinamento.
- Compare o modelo adaptado com regras e com o modelo sem adaptação.
- Separe documentos por família e versão para reduzir vazamento entre conjuntos.
- Use QLoRA para treinar adaptadores sobre uma base quantizada.
- Valide categorias, evidências e abstenções antes de conectar o resultado ao fluxo de trabalho.
O papel de Unsloth e QLoRA no projeto
Fine-tuning é a adaptação de um modelo já treinado a exemplos de uma tarefa. O guia oficial do Unsloth apresenta métodos de treinamento e orientações para preparar esse processo. Neste projeto, a ferramenta integra a execução do ajuste; a equipe continua responsável por escolher os documentos, revisar os rótulos e testar a saída.
QLoRA combina uma base quantizada com adaptadores LoRA, que são conjuntos adicionais de parâmetros treináveis. O trabalho original de QLoRA descreve o ajuste com pesos da base representados em quatro bits e passagem dos gradientes para os adaptadores. A técnica busca reduzir a memória necessária ao processo de adaptação.
Essa característica não determina quanto de memória o seu projeto exigirá. Modelo, comprimento dos textos, tamanho do lote e configuração do treinamento precisam ser considerados conjuntamente. Também não garante ganho de classificação. A hipótese de que o ajuste ajudará a lidar com a linguagem das apólices deve ser testada contra alternativas mais simples.
Escolha um modelo cuja licença e condições de uso sejam compatíveis com o projeto e registre sua revisão exata. Evite selecionar a base apenas por tamanho ou popularidade. Antes do treinamento, execute uma pequena avaliação em português com a tarefa definida. Ela mostra o ponto de partida e evita atribuir ao adaptador uma capacidade que já existia.
Defina categorias que possam ser revisadas
Uma taxonomia é a lista organizada de categorias usadas na classificação. Para documentos de seguros, um primeiro eixo pode distinguir apólice, proposta, endosso e comunicação administrativa. Outro eixo pode identificar o assunto de um trecho, como vigência, identificação das partes ou descrição do objeto. Não misture os dois eixos em uma lista sem explicar o critério.
Escreva uma definição operacional para cada categoria. Ela deve incluir exemplos positivos, exemplos que parecem semelhantes e a regra para casos incompletos. Se a tarefa permitir mais de um rótulo, declare isso. Obrigar um documento com vários assuntos a receber uma única classe pode produzir discordâncias que nenhum ajuste de modelo resolve.
O gabarito precisa ser criado por pessoas que conheçam os documentos e o uso pretendido. Registre divergências, revise definições e só depois consolide os exemplos. Se uma cláusula depende de outra parte do contrato, inclua o contexto necessário ou marque o item como insuficiente. Não treine o modelo a adivinhar conteúdo que não recebeu.
Use identificadores estáveis para os rótulos, como tipo_endosso, e mantenha os nomes de exibição em um catálogo separado. Assim, uma mudança de redação na interface não exige alterar todo o conjunto. Preserve também uma categoria de encaminhamento para revisão, com critérios que possam ser auditados.
| Abordagem | Quando testar | Principal cuidado |
|---|---|---|
| Regras por campos e títulos | Documentos padronizados e categorias explícitas | Não depender apenas de uma palavra recorrente |
| Modelo sem adaptação | Primeira avaliação da taxonomia | Fixar instrução e formato da resposta |
| Modelo com exemplos no contexto | Confusões que podem ser esclarecidas por demonstrações | Não usar exemplos do teste reservado |
| Adaptação com QLoRA | Erros persistentes e exemplos rotulados suficientes | Verificar ganho fora das famílias de treinamento |
Prepare os dados sem ensinar o gabarito por acidente
Trabalhe com uma cópia controlada dos textos e mantenha a ligação com o documento de origem fora da entrada do modelo. Retire identificadores pessoais que não sejam necessários à tarefa. Revise também nomes de arquivo, cabeçalhos e anotações internas: um campo criado pelo processo de rotulagem pode revelar a resposta antes da análise do conteúdo.
O conteúdo técnico deve ser preservado. Limpeza excessiva pode remover expressões que distinguem categorias. Para campos sensíveis, use um procedimento documentado e avalie se o tratamento altera o significado. A discussão sobre mascaramento em APIs ajuda a planejar essa etapa sem pressupor que uma ferramenta identifica todos os dados sensíveis.
Separe treino, validação e teste por grupos documentais. Uma apólice e sua versão revisada não devem cair em conjuntos diferentes por simples sorteio de parágrafos. O mesmo vale para contratos derivados de um único modelo. Uma divisão por família ou por período pode produzir um teste mais informativo, desde que o critério seja registrado.
Para contratos longos, defina a unidade de classificação. Se a saída descreve uma cláusula, recorte a cláusula e o contexto necessário. Se descreve o documento inteiro, mantenha uma estratégia que preserve as seções relevantes. Cortar o texto no limite de tokens sem verificar o trecho removido pode eliminar justamente a evidência do rótulo.
Crie um inventário do conjunto com origem, versão, grupo, categoria e responsável pela revisão. A contagem por classe mostra onde faltam exemplos. Balancear o treinamento pode ser útil como experimento, mas o teste deve permitir entender o desempenho diante da distribuição documental esperada, incluindo classes menos frequentes.
Monte um experimento de treinamento reproduzível
Organize cada exemplo como entrada e resposta esperada. O SFTTrainer do TRL documenta formatos de treinamento supervisionado, incluindo pares de prompt e completion e estruturas conversacionais. Escolha um formato compatível com a base e use o mesmo padrão na avaliação e na aplicação.
Uma resposta de treinamento pode conter somente {"categoria": "tipo_endosso", "evidencia": "trecho literal"}. O fragmento é ilustrativo e precisa ser substituído por uma evidência real do próprio exemplo. Não acrescente longas justificativas inventadas para tornar a resposta mais convincente. A supervisão deve ensinar exatamente o contrato de saída que será cobrado depois.
A documentação do PEFT sobre quantização explica como combinar pesos quantizados com parâmetros adicionais treináveis. Os detalhes dependem da arquitetura e da biblioteca. Por isso, registre as versões instaladas e parta de um exemplo oficial compatível com o modelo escolhido, em vez de juntar parâmetros de tutoriais diferentes.
Faça primeiro uma execução curta de diagnóstico. Confirme que os exemplos carregam, que os textos não são cortados indevidamente e que a saída esperada participa do cálculo de treinamento. Inspecione amostras já tokenizadas. Uma curva de perda decrescente não compensa um conjunto no qual a resposta foi removida durante o processamento.
Depois, compare poucas configurações de forma controlada. Altere um aspecto por vez e registre rank dos adaptadores, taxa de aprendizado, comprimento de sequência, lote efetivo e critério de parada. Escolha a configuração pela validação. O teste final permanece reservado até que a escolha esteja encerrada.
Salve o adaptador, a referência da base, o tokenizer, a instrução e o catálogo de rótulos como um conjunto versionado. Um adaptador isolado não descreve todo o sistema. Antes de qualquer integração, recarregue os artefatos em uma sessão limpa e confirme que produzem respostas compatíveis com as verificadas durante o experimento.
Exemplo: organização de apólices em uma corretora de Curitiba
Imagine uma corretora de Curitiba que deseja encaminhar documentos recebidos para filas internas de conferência. O exemplo é ilustrativo e não representa resultados de uma empresa real. O sistema classifica o tipo documental e destaca a evidência textual. Ele não informa se um evento será coberto nem recomenda aceitar ou recusar um pedido.
A equipe define categorias para apólice, endosso, proposta e material fora do escopo. Os revisores identificam que parte das mensagens contém apenas um anexo incompleto. Esses casos recebem encaminhamento para revisão, em vez de uma categoria escolhida a partir do assunto do e-mail. O gabarito permanece vinculado ao texto efetivamente disponível.
O primeiro teste usa regras e o modelo sem ajuste. A equipe inspeciona os erros antes de decidir se vale treinar um adaptador. Se os enganos vierem de documentos ausentes ou de categorias mal definidas, o trabalho necessário está na entrada ou na taxonomia. QLoRA só entra no experimento quando há uma hipótese específica sobre comportamento a melhorar.
Após o treinamento, a comparação considera documentos de famílias reservadas. Um relatório mostra classe prevista, classe revisada e trecho de evidência. O piloto pode operar em paralelo ao processo humano, registrando propostas de encaminhamento sem alterar a fila automaticamente. Assim, a equipe observa o comportamento antes de conceder efeitos operacionais à classificação.
O acesso ao acervo continua sendo uma decisão separada. A discussão sobre permissões para documentos confidenciais ajuda a planejar quem pode consultar o conteúdo. O fato de um arquivo ser útil para treinamento não significa que todas as pessoas com acesso ao modelo devam poder recuperá-lo.
Erros comuns
Medir apenas acurácia total. Uma classe frequente pode dominar o resultado. Apresente métricas por classe e matriz de confusão. A documentação do scikit-learn ajuda a escolher medidas adequadas. Explique separadamente quantas respostas tiveram formato inválido ou exigiram revisão.
Usar o próprio treinamento como demonstração de qualidade. Reproduzir um rótulo já visto não prova generalização. Preserve o teste reservado e registre as famílias documentais presentes em cada conjunto. Inclua casos em que títulos semelhantes descrevem tipos diferentes, para descobrir dependência de atalhos superficiais.
Interpretar confiança declarada como probabilidade. Um texto como “tenho certeza” não é uma medida calibrada. Se houver pontuação de confiança, avalie sua relação com os erros observados antes de escolher um limiar. A rota de revisão deve depender de critérios documentados, como falta de evidência ou categoria fora do catálogo.
Publicar artefatos e registros sem revisão. Adaptadores, exemplos e logs podem carregar informações do treinamento. Defina quem pode recebê-los e verifique o conteúdo antes de compartilhar. Preserve rastreabilidade sem copiar contratos completos para ferramentas de observabilidade que não fazem parte do ambiente autorizado.
Perguntas frequentes
É obrigatório fazer fine-tuning para classificar apólices?
Não. Regras, modelos sem adaptação e exemplos no contexto devem participar da comparação inicial. O ajuste faz sentido como hipótese de melhoria para erros identificados. Se a alternativa simples atender aos critérios definidos, o custo operacional de manter treinamento adicional precisa ser justificado.
QLoRA garante que o treinamento caberá na minha GPU?
Não. A técnica reduz necessidades de memória de partes do treinamento, mas a execução depende do modelo, do comprimento das entradas e de outras configurações. Faça uma execução de diagnóstico no ambiente previsto e registre o consumo observado, sem extrapolar resultados de outra configuração.
O modelo pode determinar a cobertura de um sinistro?
Essa não é a tarefa deste projeto. O rótulo informa a organização documental e deve ser apresentado assim na interface. Determinar direitos, obrigações ou consequências de um contrato exige outro processo de análise, com responsáveis e critérios próprios, que não é validado por este benchmark.
Preciso atualizar o adaptador a cada nova apólice?
Não necessariamente. Monitore mudanças de linguagem e novos tipos documentais. Uma nova categoria pode exigir revisão da taxonomia e do conjunto. Antes de retreinar, verifique se a mudança pode ser tratada na instrução, na preparação da entrada ou no encaminhamento para revisão.
Como saber se a adaptação realmente melhorou?
Compare a mesma bateria reservada com a base e com o adaptador, mantendo as demais condições. Examine classes raras, evidências incorretas e abstenções, além da média. Registre regressões. Só considere ganho quando o comportamento atender aos critérios definidos antes da avaliação.
