O que faz com que a saída de um LLM local viole um esquema JSON válido?

A saída de um LLM local quebra um esquema JSON válido quando a geração, o tratamento de restrições, as regras de paragem e a validação não aplicam o mesmo contrato.

Um fluxo de trabalho autoalojado pode fornecer um esquema compatível com as normas para metadados de ficheiros, ações de casa inteligente, extração de documentos ou argumentos de ferramentas e, ainda assim, receber uma saída malformada ou rejeitada. “Esquema válido” descreve o documento do esquema, não todo o percurso de execução. O modelo tem de compreender a tarefa, o descodificador tem de suportar as funcionalidades relevantes do esquema, a geração tem de terminar antes de uma condição de paragem a interromper, o analisador tem de recuperar um valor JSON completo e o validador da aplicação tem de aplicar a versão esperada do esquema e as regras de conversão de tipos.

JSON válido e JSON válido segundo o esquema são resultados diferentes

Um objeto pode ser analisado com êxito e, ainda assim, violar campos obrigatórios, tipos, enumerados, limites de matrizes ou ramificações condicionais. Também pode conter nomes de campos corretos, mas adicionar propriedades proibidas pelo esquema.

O módulo JSON do Python define a camada de sintaxe para descodificar um documento JSON, mas a análise não aplica um contrato JSON Schema separado.

Esta causa é reconhecível quando a saída é carregada sem um erro de sintaxe, mas falha apenas depois da validação do esquema. Uma chaveta em falta ou uma explicação final são falhas de serialização; uma cadeia de texto onde é exigido um número inteiro é uma falha de contrato.

A composição de esquemas pode criar ramificações difíceis de satisfazer

Palavras-chave como allOf, anyOf, oneOf e not combinam restrições. Uma ramificação pode ser válida isoladamente, enquanto o objeto combinado não satisfaz nenhuma ou satisfaz várias das alternativas permitidas.

A documentação do JSON Schema explica como as palavras-chave de composição do esquema alteram a necessidade de correspondência com um ou vários subesquemas.

Um modelo local costuma lidar de forma mais fiável com uma lista simples de propriedades do que com lógica condicional aninhada. Se as falhas se concentrarem em uniões ou em formas de objetos mutuamente exclusivas, a principal dificuldade está na seleção da ramificação, não na pontuação básica do JSON.

O descodificador condicionado pode suportar apenas parte do esquema

Os motores de saída estruturada traduzem esquemas em restrições de tokens, gramáticas, expressões regulares ou regras específicas do backend. Nem todos implementam todas as versões ou palavras-chave do JSON Schema.

O vLLM disponibiliza vários backends de saída estruturada, mostrando que as restrições baseadas em esquema JSON, gramática, expressão regular e escolhas fixas são modos de execução distintos.

Esta causa surge quando o mesmo esquema é validado corretamente num validador compatível com as normas, mas falha apenas num backend de inferência específico. Recursividade, referências, padrões ou palavras-chave condicionais não suportados podem ser simplificados, ignorados ou rejeitados antes de o modelo gerar qualquer conteúdo.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

As instruções do prompt podem entrar em conflito com o esquema

O prompt do utilizador pode pedir comentários, citações, explicações, omissões opcionais ou incerteza em linguagem natural, enquanto o esquema exige um único objeto com campos fixos.

O modelo passa então a ter dois critérios de sucesso concorrentes: responder ao utilizador de forma conversacional e emitir apenas tokens permitidos pelo contrato da máquina. Um modelo local mais pequeno pode seguir a instrução mais recente ou mais saliente, em vez de reconciliar ambas.

Estas falhas adicionam frequentemente um preâmbulo, um bloco Markdown, uma explicação depois do objeto ou um valor que satisfaz o pedido em prosa, mas viola o enumerado declarado. O esquema é válido; a hierarquia de instruções é inconsistente.

O truncamento pode transformar um plano correto numa saída inválida

Matrizes e objetos aninhados requerem tokens gerados suficientes para fechar todas as estruturas. Um limite de tokens, uma cadeia de paragem, um pedido cancelado ou uma transmissão interrompida podem terminar a resposta antes de chegarem os delimitadores finais.

O Transformers disponibiliza controlos do número máximo de tokens e da paragem que determinam quando a geração termina.

Esta causa distingue-se por prefixos válidos que terminam abruptamente, sobretudo em matrizes maiores ou campos de texto longos. Violações repetidas de tipos logo no início apontam para outra causa; parênteses retos ou chavetas de fecho em falta perto do limite de saída indicam uma geração incompleta.

A semântica do validador pode rejeitar valores que o modelo considerou equivalentes

Um modelo pode emitir "3" para um número inteiro, null para um campo omitido, um enumerado em minúsculas ou uma data ISO que a aplicação espera noutro formato.

O Pydantic documenta categorias distintas de erros de validação para valores em falta, JSON inválido, incompatibilidade de enumerados, campos adicionais proibidos e tipos incompatíveis.

Se todas as falhas chegarem ao mesmo campo com um valor analisável, mas rejeitado, a causa não é uma quebra aleatória do esquema. É uma divergência quanto à conversão de tipos, ao rigor, à possibilidade de nulos, às maiúsculas e minúsculas ou aos formatos ao nível da aplicação.

As restrições gramaticais podem preservar a sintaxe, mas não o significado comercial

Uma gramática pode bloquear chavetas e chaves ilegais, mas continuar a permitir uma combinação semanticamente impossível, como uma data de fim anterior à data de início ou um caminho de ficheiro inexistente.

O llama-cpp-python disponibiliza geração condicionada por gramática como controlo de inferência, mas a gramática governa a estrutura de tokens permitida, não a verdade externa.

Uma falha do esquema causada por regras entre campos pode surgir apenas numa segunda camada de validação. A saída pode ser sintática e estruturalmente válida, mas continuar a ser inutilizável no fluxo de trabalho do servidor doméstico.

O pós-processamento pode corromper uma saída do modelo que era válida

Por vezes, as aplicações removem Markdown, extraem o primeiro bloco delimitado por chavetas, juntam fragmentos de uma transmissão, corrigem vírgulas ou convertem valores antes da validação.

Uma resposta válida do modelo pode tornar-se inválida quando um fragmento da transmissão é duplicado, o Unicode é descodificado incorretamente, uma sequência de escape é removida ou uma função de correção altera conteúdo aninhado. Por outro lado, uma etapa de correção pode ocultar que a saída original do modelo era inválida.

A explicação da ZimaSpace sobre o motivo pelo qual os modelos locais pequenos têm alucinações durante a saída JSON fornece o contexto adjacente: a validade do esquema e a correção factual devem ser avaliadas separadamente, e a resposta original deve ser conservada antes das transformações da aplicação.

FAQ

O JSON válido prova que a saída corresponde ao esquema?

Não. A análise de JSON verifica a sintaxe. A validação do esquema verifica separadamente propriedades obrigatórias, tipos, enumerados, ramificações, limites e outras restrições declaradas.

A temperatura zero impede falhas do esquema?

Não. Pode tornar um percurso de descodificação mais repetível, mas não adiciona funcionalidades de esquema não suportadas, não impede o truncamento nem resolve instruções contraditórias.

A descodificação condicionada garante um registo de automatização utilizável?

Não. Pode garantir restrições estruturais suportadas, mas as regras comerciais, a fundamentação nas fontes, a existência de ficheiros, as permissões e a consistência entre campos continuam a exigir validação pela aplicação.