Quem é mais rigoroso com JSON: OpenAI, Gemini e xAI passam por testes de conformidade com schemas

Desenvolvedores do Habr conduziram um estudo que testou como Structured Outputs funcionam de verdade em três provedores principais de LLM: OpenAI, Gemini e xAI. Em vez de ler documentação, utilizaram um método de teste adversarial—quebrando propositalmente schemas para ver onde cada provedor mantém a rigidez e onde cede.

Como Testaram a Conformidade com Schemas

Os autores não simplesmente pediram aos modelos para retornar JSON válido. Construíram propositalmente prompts tentando forçar o modelo a violar seu próprio JSON Schema. Pediram para colocar valores do tipo errado em campos, adicionar chaves extras, usar valores enum inválidos, violar comprimento mínimo ou máximo de string, exceder intervalos numéricos. Observaram onde o modelo obedecia strict: true e onde se rompia retornando JSON inválido. Testaram separadamente construções complexas: anyOf, oneOf, allOf—regras combinatórias que são mais difíceis de implementar em LLMs. Na prática, muitos sistemas simplificam, ignoram ou implementam parcialmente essas construções. Os autores verificaram como cada provedor interpreta essas regras.

O Que Descobriram Sobre Diferentes Provedores

Os resultados são surpreendentes: cada provedor tem seu próprio conjunto de restrições duras e suaves. OpenAI mantém a rigidez melhor, especialmente quando strict: true está ativado. Gemini permite mais liberdade com enum e objetos aninhados. xAI mostra estabilidade em complexidade média, mas tem pontos cegos em construções allOf e campos condicionais.

A matriz de restrições do artigo mostra:

• OpenAI: confiável em tipos primitivos (string, number, boolean), às vezes desliza em estruturas aninhadas complexas
• Gemini: interpreta anyOf e oneOf mais livremente, pode adicionar chaves extras a objetos, menos rigoroso com valores enum
• xAI: bom em complexidade média e regras básicas, mais fraco em validação multi-nível e patternProperties

Até mesmo strict: true não garante 100% de conformidade. Isso transfere responsabilidade de volta ao desenvolvedor.

Conclusões Práticas para Production

Se você está construindo um sistema que chama múltiplos provedores de LLM em paralelo, essas diferenças são críticas. Você não pode simplesmente trocar de OpenAI para Gemini e esperar exatamente a mesma resposta formatada. JSON Schema permanece o mesmo, mas o comportamento do modelo é radicalmente diferente.

Para cenários de produção, os autores recomendam: sempre adicione validação de resposta após o modelo, mesmo se o provedor promete strict: true. Use uma biblioteca jsonschema que reverificará o resultado independentemente. E adicione lógica de fallback caso o formato se quebre inesperadamente: pergunte ao modelo novamente, use um valor padrão ou retorne um erro ao usuário. Um desvio aleatório de enum do modelo pode destruir seu pipeline inteiro.

O Que Significa

Structured Outputs é um recurso útil, mas não uma panaceia. Os testes do Habr mostraram que confiar completamente no provedor é um erro. Se você se importa com o formato de resposta, invista em validação no lado do cliente.