LLMs Vazam Raciocínio em Saídas Estruturadas Apesar de Instruções Explícitas

O Problema: Passagens de Validação de LLM Vazam Raciocínio

Um desenvolvedor construindo uma ferramenta que faz chamadas paralelas à API do Claude e analisa a saída estruturada por chamada encontrou um problema intermitente. Cada chamada retorna conteúdo dentro de marcadores específicos como [COVER], [SLIDE 1], [CAPTION], etc. Uma segunda passagem de LLM valida a saída contra regras e reescreve qualquer coisa que falhe.

O prompt de validação afirma explicitamente: "retorne APENAS o texto corrigido no exato mesmo formato. Nenhum comentário. Nenhum raciocínio. Nenhuma lista de violações."

Apesar disso, o modelo de validação ocasionalmente emite seu raciocínio antes do conteúdo corrigido. Exemplos incluem: "Preciso verificar este texto por violações... Estas frases formam um par dramático empilhado usado puramente para efeito. Aqui está a reescrita:" seguido pelo texto corrigido real.

Consequências a Jusante

Este texto de raciocínio é passado diretamente para o analisador. O analisador espera conteúdo começando em [COVER] mas, em vez disso, recebe meta-comentários. Isso causa desalinhamento de campo a jusante. Em um caso, o texto de raciocínio do validador acabou dentro de um campo de prompt de imagem porque o analisador consumiu o raciocínio como conteúdo do corpo, deslocando tudo algumas linhas para baixo.

Aperto do prompt sozinho não resolveu o problema. Tornar as instruções mais explícitas, adicionar "sua saída DEVE começar com o primeiro marcador de conteúdo," e adicionar "nunca inclua raciocínio" reduziu a frequência, mas não a eliminou. O modelo ocasionalmente ignora instruções, especialmente quando encontra violações para corrigir—ele quer mostrar seu trabalho.

A Solução: Defesa de Duas Camadas

A correção que funcionou envolveu duas camadas:

• Camada 1: Aperto do prompt. Ainda vale a pena fazer porque reduz a frequência com que o problema ocorre.
• Camada 2: Uma função defensiva de remoção que é executada em toda saída de validação antes que qualquer análise aconteça. Para formatos estruturados, ela ancora ao primeiro marcador reconhecido e descarta tudo antes dele. Para formatos de texto simples, ela remove linhas que correspondem a padrões conhecidos de comentários do validador (coisas como "Deixe-me verificar este texto" ou "Isso viola a restrição").

A ordem de remoção-antes-da-análise é fundamental. Todo analisador a jusante opera em saída já saneada. Isso evita manter lógica de remoção por campo ou jogar whack-a-mole com novos formatos de raciocínio.

Considerações de Implementação

Para padrões de remoção de texto simples, é necessário um design cuidadoso. Uma regex que captura "Esta é uma violação" também poderia capturar "Este é um erro comum" em conteúdo legítimo. Os padrões devem ser apertados para corresponder apenas à linguagem específica do validador, como "Isso viola a/uma regra/restrição" em vez de correspondências amplas em "Isto é" ou "Isto usa". Cada padrão precisa de auditoria contra conteúdo real antes da implantação.

Se você está analisando saída estruturada de um LLM, trate as instruções do prompt como uma primeira passagem de melhor esforço e sempre tenha uma defesa em nível de código antes do analisador. O modelo irá cumprir 95% das vezes, mas os 5% em que não cumpre irão quebrar a lógica a jusante de maneiras difíceis de reproduzir porque são intermitentes.