Ciclos de correção e validação

Mesmo com esquemas, a saída pode falhar: JSON truncado por um limite de tokens, campos extras inventados, uma cadeia de caracteres onde era exigido um número ou uma regra de negócio violada. Um ciclo de reparo detecta a falha e a envia de volta ao modelo para que ele a corrija.

Essa é a rede de segurança que transforma uma taxa de sucesso de 98% em uma de 99,9%.

O ciclo canônico é: gerar, validar e, se for inválido, solicitar novamente com o erro específico, até um número limitado de tentativas.

A qualidade do reparo depende da precisão do retorno. 'JSON inválido' ajuda pouco; 'O campo de avaliação deve ser um número inteiro entre 1 e 5, mas recebeu 7' quase sempre corrige o problema em uma única interação.

Envie ao modelo a mensagem exata de erro do seu validador (caminho e motivo).

A validação tem níveis; verifique primeiro o mais barato:

• Sintática — pode ser analisada como JSON?
• Estrutural — corresponde ao esquema?
• Semântica — os valores satisfazem as regras de negócio e os invariantes entre campos?

Um desconto não pode exceder o subtotal, mesmo que ambos sejam números válidos; essa é uma verificação semântica.

Antes de gastar com uma chamada ao modelo, tente correções determinísticas e baratas para defeitos comuns:

• Remova os delimitadores de código Markdown.
• Extraia o objeto JSON mais externo do texto ao redor.
• Remova vírgulas finais.

Só recorra ao reparo pelo modelo se a limpeza determinística falhar.

Se finish_reason == 'length', o JSON foi cortado; reparar o fragmento é inútil. Em vez disso, aumente max_tokens, reduza o conteúdo solicitado ou transmita a resposta e solicite uma continuação. Diferencie o truncamento de uma saída malformada, pois eles exigem respostas opostas.

O reparo sem limite representa um risco de custo e latência, e um modelo travado pode entrar em um ciclo infinito. Sempre limite o número de tentativas, adicione um orçamento por solicitação e defina uma alternativa (degrade graciosamente, coloque em uma fila para revisão humana ou retorne um valor padrão seguro).

Em chamadas de funções, o canal de reparo é o resultado da ferramenta. Retorne um erro estruturado e o modelo se corrigirá na interação seguinte, sem necessidade de um ciclo separado.

Quando um ciclo de reparo envolve uma ação (e não apenas geração), garanta que as novas tentativas sejam idempotentes. Use chaves de idempotência para que uma chamada repetida não faça uma cobrança duplicada nem duplique um registro. Valide antes de confirmar efeitos colaterais, nunca depois.

A taxa de reparo é um indicador antecipado de qualidade. Uma taxa crescente significa uma regressão nas instruções, um esquema rígido demais ou uma deriva do modelo. Registre o número de tentativas por sucesso e os principais caminhos de erro, e envie um alerta quando esses valores aumentarem muito.

O fluxo mais robusto combina várias camadas de proteção: decodificação restrita ou modo de esquema estrito para minimizar falhas, limpeza determinística para correções baratas e um ciclo limitado de reparo pelo modelo para os poucos problemas restantes. Nenhuma camada isolada é suficiente.

Fluxos de reparo robustos:

• Valide em níveis: sintático, estrutural e semântico.
• Envie ao modelo erros precisos no nível do caminho.
• Tente a limpeza determinística antes de pagar por uma chamada ao modelo.
• Detecte o truncamento separadamente e gere novamente.
• Limite as tentativas, garanta a idempotência e monitore as taxas de reparo.

Você concluiu a geração estruturada. Próximo curso: barreiras de proteção e validação da saída.