Classificador de serviços com LLM subiu de 73% para 94%, mas uma cadeia de três nós ainda entrega só 75%

Qualquer equipe que já colocou um LLM em produção conhece essa decepção. No conjunto de teste o modelo entrega 98%, e nos dados reais chega a 73%. O autor da análise no Habr considera que em produção raramente se consegue uma qualidade do sistema inteiro acima de 90%. Por isso, vale se orientar justamente por esse número. Alguns projetos, por causa do alto custo do erro, simplesmente não vão fechar a conta.

A tarefa: 50 classes e um catálogo

O exemplo vem de um trabalho real. A partir do nome do serviço, é preciso escolher o código para o formulário 402. A classificação é plana, com 50 classes, e cada tipo de serviço corresponde exatamente a um código. Por exemplo, «842 — Desenvolvimento e instalação de software» ou «7123 — Transporte rodoviário de cargas». A tarefa parece simples, mas mostra bem como um único nó se comporta.

O primeiro instinto é acrescentar exceções ao prompt. Assim o prompt incha, e surgem três problemas. Primeiro, o modelo pode «perder» parte de um contexto longo: a informação está na entrada, mas não na resposta. Segundo, se um único prompt reúne dezenas de tarefas diferentes (digamos, extrair 50 atributos, com um parágrafo inteiro de regras só para o valor), parte das regras é ignorada. Terceiro, surge um análogo do overfitting: você ajusta o prompt ao mesmo benchmark, e ele decora exemplos em vez de aprender a regra geral. Pararam em 8 exemplos e obtiveram 81%.

O que realmente melhorou a qualidade do nó

O autor rejeita a divisão ingênua do catálogo ao meio. Isso resultaria em dois candidatos, e seria necessária uma terceira etapa para escolher um único código. É um novo ponto de erro.

O que ajudou foi analisar os logs e conversar com o negócio. Descobriu-se que um documento pode conter vários serviços. O nó anterior os gravava em uma única linha, e o LLM escolhia um código, enquanto os demais serviços se perdiam. A correção foi: extrair os serviços em lista, passar cada um separadamente com o contexto necessário do documento e reunir o resultado com um código para cada. A qualidade subiu para 89%. O problema estava na formulação da tarefa, não no modelo.

O passo seguinte são os exemplos dinâmicos. A partir do benchmark rotulado, constrói-se uma tabela «vetor do nome do serviço — classe». Para um novo serviço, buscam-se os similares e eles são inseridos no prompt junto com os códigos corretos. O resultado foi 94%. Chegar a 100% não é possível: a tabela é incompleta, e os vetores às vezes convergem de forma falsa, levando ao prompt exemplos inadequados.

Cadeias: a qualidade se multiplica

A ideia central da segunda metade do artigo: em uma cadeia de chamadas, a qualidade final é o produto da qualidade das etapas. Exemplo de um contact center: a reescrita da pergunta funciona em 95%, a busca RAG na base de conhecimento em 80%, e a resposta final em 99%. Total: 0,95 × 0,80 × 0,99 = 75%. O cálculo só é válido em um único conjunto de dados fixo: não se pode medir cada elo em seu próprio conjunto e depois multiplicar.

A tentação é compreensível: adicionar uma orquestração com lista de bloqueio de perguntas problemáticas. De fato, ela elimina parte dos casos, e o RAG funciona melhor nos restantes, digamos 89%. Mas o próprio orquestrador também erra, digamos em 5% dos casos. Resultado: 95% × 95% × 89% × 99% ≈ 79,5%. Há ganho, mas pequeno, e o sistema ficou mais complexo. Ele não se tornou perfeito: a cadeia ganhou mais uma etapa, com seu próprio erro.

O que fazer na prática

• Meça a qualidade em dados realistas, e não apenas no benchmark interno. A distância entre 98% e 73% é um cenário típico.
• Antes de complicar o prompt, olhe os logs e converse com o negócio. Parte dos «erros do modelo» será, na verdade, erro de formulação da tarefa ou da etapa anterior.
• Divida a tarefa por sentido (um serviço, uma chamada), e não de forma mecânica.
• Calcule a cadeia com antecedência: três etapas de 90% dão cerca de 73%.
• Se o custo do erro é alto, coloque uma pessoa no circuito. Não se deve esperar 100% de um sistema com LLM.

Limitações

Os números vêm de um único caso do autor, no qual ele alterou os dados de entrada preservando o sentido geral. Não há verificação independente, e o tamanho do ganho de cada técnica depende dos dados. Mas a lógica é universal: a qualidade do sistema é determinada pelo elo mais fraco e pelo número de etapas, e é melhor aceitar logo a referência de 90%.