Como separei classificação de reescrita para reduzir alucinação de LLM em otimização de currículo · ThalissonDamiao

um dos problemas mais chatos de trabalhar com LLM em produção é alucinação contextual. não o modelo inventando fatos do nada, mas o modelo sendo "criativo demais" pra resolver o problema que você pediu.

no meu caso específico: pedia pro sonnet injetar keywords faltantes num currículo e ele sempre achava um jeito de encaixar qualquer keyword, mesmo sem nenhuma evidência real no histórico do candidato. o modelo estava otimizando pra parecer útil, não pra ser factualmente correto.

o problema em detalhe

o fluxo original era direto: currículo + descrição da vaga + lista de keywords faltantes entrava no sonnet, currículo otimizado saía.

o modelo recebia instrução explícita de não inventar experiências. funcionava na maioria dos casos. mas em edge cases com keywords muito específicas ele encontrava formas sutis de recontextualizar bullets existentes de um jeito que tecnicamente não mentia mas claramente forçava uma conexão que não existia.

o validador rejeitava os casos mais óbvios mas casos sutis passavam.

a solução: dois modelos com responsabilidades diferentes

separei o processo em duas etapas com modelos diferentes.

etapa 1 com haiku (temperatura 0.3):
recebe o currículo e a lista de gaps do motor ATS. para cada keyword faltante classifica se existe evidência real no curriculo que justifique a injeção. evidência pode ser direta (a tecnologia aparece em algum lugar) ou semântica (o contexto de uso implica familiaridade). keywords sem nenhuma evidência viram perguntas pro usuário antes de qualquer reescrita.

etapa 2 com sonnet:
recebe o currículo já com o mapa de evidências da etapa 1 mais as respostas do usuário pras perguntas geradas. agora ele tem contexto factual pra cada decisão de injeção. keywords confirmadas pelo usuário entram como fatos. keywords sem evidência e sem confirmação simplesmente não entram.

por que haiku pra classificação e não sonnet

classificação de evidência é uma tarefa estruturada com resposta binária. o haiku com temperatura baixa é mais determinístico nesse tipo de tarefa do que o sonnet com temperatura padrão, além de custar significativamente menos.

o sonnet fica reservado pra reescrita semântica que é onde o raciocínio mais sofisticado realmente importa.

o validador pós-reescrita

mesmo com a separação implementei um validador que confere o output do sonnet antes de persistir qualquer coisa.

para cada keyword declarada no campo keyword_injected do JSON de resposta o validador verifica se o termo realmente aparece no texto otimizado. se não aparecer vira aviso. se o score calculado depois da otimização não for maior que o score original a otimização inteira é rejeitada.

isso cria um loop de feedback: o LLM sabe que o output vai ser verificado por um sistema determinístico, o que na prática melhora a qualidade das respostas porque o prompt deixa isso explícito.

o que ficou de aprendizado

temperatura baixa em tarefas de classificação reduz criatividade indesejada sem perder precisão

separar "o que posso injetar" de "como injetar" resolve a maioria dos casos de alucinação contextual sem precisar de prompt engineering mais complexo

validação determinística pós-LLM é inegociável em produção quando o output afeta dados reais do usuário

coletar confirmação do usuário antes de otimizar parece fricção adicional mas na prática aumenta a confiança no resultado e elimina os casos onde o modelo teria que "adivinhar"

isso está em produção num produto que construí chamado Kore_ ou Korecv para os íntimos. se alguém tiver curiosidade sobre algum ponto específico
da implementação comento aqui