Artigos · Mustapha Alouani
Três verificações antes de confiar em uma extração
Um JSON correto pode conter a informação errada. Um protocolo para separar formato e significado.
A reunião na cidade errada
O documento diz: “A sede fica em Paris. A reunião acontecerá em Lyon”. Você pede a cidade da reunião. O sistema devolve um objeto contendo Paris. Nada trava, a aplicação exibe um mapa e a demonstração parece funcionar. Mesmo assim, ela manda você para o lugar errado.
O erro passa por dois controles comuns: o JSON pode ser lido e o valor é uma string. O problema é o papel da cidade selecionada, não sua representação.
Defina o contrato antes do prompt
Especifique o campo esperado, seu tipo e o procedimento quando a informação estiver ausente. Aqui, meeting_city contém texto ou null, sem campos adicionais. null significa ausência da cidade da reunião; não significa dúvida do modelo nem uma cidade fora da lista permitida.
Crie uma resposta de referência para cada documento. Se dois anotadores não chegam a um acordo, a tarefa ainda não está bem definida para uma avaliação confiável.
Meça três sucessos diferentes
- Sintaxe: o analisador consegue ler a saída?
- Esquema: os campos e tipos cumprem o contrato?
- Fidelidade: a resposta corresponde à informação e ao papel solicitados?
Informe o denominador de cada taxa. “90% de acertos entre saídas válidas” não significa “90% dos documentos processados corretamente”. Saídas inválidas não podem desaparecer silenciosamente do resultado geral.
Monte um teste pequeno e útil
Inclua quatro famílias: uma cidade, várias cidades com papéis diferentes, nenhuma cidade de reunião e uma cidade fora do catálogo habitual. Varie também a ordem das frases. Reserve documentos novos para o teste final após as correções.
A decodificação restrita pode reduzir alguns erros de formato. Ela não substitui referências nem casos difíceis. O volume 2 ilustra essa distinção em um protocolo específico; seus números não representam o desempenho universal de todos os LLMs.
Acompanhe um documento do início ao fim
Voltemos ao documento como leitores que verificam o resultado. Procuramos uma relação: qual cidade está associada à reunião? “Paris” satisfaz a condição “ser uma cidade presente no texto”, mas essa condição é fraca demais. A frase que contém Paris descreve a sede. A segunda frase liga explicitamente a reunião a Lyon. A referência deve vir dessa relação, não da primeira cidade encontrada.
Isso explica por que extrair informações nem sempre é apenas procurar palavras. Reconhecer uma entidade, atribuir seu papel e colocá-la no campo correto são operações conceitualmente distintas. Mesmo quando um modelo realiza tudo em uma única geração, essa separação ajuda a compreender os erros.
Imagine três saídas: texto livre dizendo “Lyon”, um objeto cujo meeting_city é Paris e outro cujo meeting_city é Lyon. A primeira contém a informação correta, mas não respeita a interface da aplicação. A segunda respeita a interface, mas transmite a informação errada. Somente a terceira atende às duas exigências. O sucesso operacional exige conteúdo correto e representação utilizável.
Do resultado geral ao diagnóstico
Em outro exemplo construído, avaliamos cem documentos. Dez saídas não podem ser interpretadas, vinte são legíveis mas violam o esquema e cinquenta das setenta saídas conformes contêm a cidade correta. O sucesso de ponta a ponta é 50 em 100. A fidelidade entre as saídas conformes é 50 em 70, aproximadamente 71,4%. Os dois números são úteis, mas respondem a perguntas diferentes. O primeiro descreve o que o usuário recebe; o segundo ajuda a isolar erros de significado depois dos erros de formato.
Melhorar o formato pode aumentar o número de saídas utilizáveis sem melhorar sua exatidão. No sentido inverso, uma compreensão melhor pode ficar invisível se a aplicação não consegue ler a resposta. Escolha a próxima correção pela categoria de erros dominante e repita a medição em documentos reservados.
Uma regra para casos difíceis
Se o documento menciona duas reuniões em duas cidades, nosso contrato de um único valor se torna insuficiente. É preciso especificar qual reunião interessa, permitir vários valores ou sinalizar ambiguidade. Pedir que o modelo seja “mais preciso” não conserta uma pergunta mal definida. Uma extração excelente começa com uma tarefa que possa ser explicada e verificada sem o modelo.
Exercício resolvido
“A sede fica em Lyon. A reunião será em Marseille”. null está correto porque Marseille não está na lista? Não. A informação está presente. Preveja um estado separado para valores fora do catálogo ou permita sua extração, sem confundir presença com ausência.