Porque é que os modelos locais pequenos têm mais alucinações ao gerar JSON?

Os modelos locais pequenos têm mais tendência para alucinar durante a geração de JSON porque têm de resolver a tarefa e, ao mesmo tempo, preservar um esquema rígido e uma sintaxe válida.

Um fluxo de trabalho de IA doméstico pode pedir a um modelo compacto que extraia nomes de ficheiros, datas, etiquetas, estados de dispositivos ou argumentos de automatização e os devolva como JSON legível por máquinas. O modelo não está a executar apenas uma tarefa. Tem de identificar os factos corretos, associá-los aos campos pretendidos, respeitar os tipos e valores enumerados obrigatórios, lembrar-se da pontuação e da estrutura hierárquica e parar sem acrescentar comentários. Quando a capacidade do modelo é limitada, estas restrições competem com o raciocínio necessário para manter os valores fundamentados.

O JSON transforma a correção num problema de duas camadas

A resposta tem de estar semanticamente correta e ser estruturalmente válida ao mesmo tempo. Uma resposta de formato livre pode expressar incerteza ou explicar um valor em falta, enquanto um contrato JSON muitas vezes exige que o modelo escolha um valor para um campo, mesmo quando as evidências são fracas.

A investigação sobre o compromisso entre validade e correção mostra por que motivo estas medições devem permanecer separadas: restrições de saída mais fortes podem melhorar a validade do esquema, enquanto os valores selecionados se tornam menos precisos.

A pressão é mais visível num modelo local pequeno porque este tem menos capacidade disponível para acompanhar instruções, extrair informação e serializar dados. Um modelo maior também pode inventar um campo, mas um modelo compacto chega mais depressa ao ponto em que a conformidade com o formato prejudica a qualidade da resposta.

Um objeto válido ainda pode conter uma resposta alucinada

A descodificação condicionada pode impedir a emissão de uma chaveta ilegal, de uma chave desconhecida ou de um valor enumerado inválido. Não consegue provar que o ID do cliente, a data, o caminho ou o estado escolhido está presente no material de origem.

A vLLM descreve as restrições de esquema JSON como uma forma de limitar a estrutura da saída gerada. O descodificador restringe os tokens que podem ser legalmente escolhidos a seguir, mas o modelo continua a fornecer o significado transportado por esses tokens legais.

Isto cria um modo de falha perigoso para a automatização: o objeto é analisado com sucesso, pelo que o código subsequente confia nele, mas um dos campos é fabricado. Valide as regras de negócio e as evidências de origem depois da validação do esquema, em vez de tratar o sucesso da análise como prova de correção factual.

Os esquemas aninhados aumentam a ramificação e o acompanhamento do estado

Cada propriedade obrigatória, ramificação opcional, matriz aninhada, campo anulável e valor enumerado acrescenta estado que o modelo tem de acompanhar durante a geração. Nomes de chaves semelhantes ou estruturas de objetos repetidas facilitam a colocação de um valor correto no local errado.

O guia do llama.cpp sobre JSON condicionado por gramáticas distingue a gramática de saída permitida do prompt que explica o significado dos campos. Uma gramática pode impor a estrutura, mas o esquema continua a precisar de instruções semânticas claras.

Reduza o número de decisões simultâneas. Achate objetos profundamente aninhados, remova campos opcionais não utilizados, use nomes de chaves distintos e divida uma extração grande em objetos mais pequenos quando o modelo local trocar repetidamente campos ou preencher campos não relacionados.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Os prompts que exigem apenas JSON podem suprimir raciocínio útil

Uma instrução rigorosa como “devolva apenas JSON” leva o modelo a empacotar imediatamente uma resposta. Numa extração difícil, isso pode provocar a escolha prematura de um campo, antes de o modelo comparar passagens concorrentes ou resolver uma data ambígua.

As avaliações da Hugging Face mostram a sensibilidade ao formato do prompt: alterar a estrutura esperada e o espaço disponível para o raciocínio pode mudar o desempenho da tarefa, mesmo quando a pergunta subjacente é a mesma.

Não exponha cadeias de raciocínio privadas, mas separe a resolução interna da tarefa da serialização final. O fluxo de trabalho pode primeiro extrair um registo compacto de evidências ou fazer uma consulta determinística e, em seguida, pedir ao modelo que apresente apenas os campos verificados.

O JSON solicitado no prompt e a descodificação condicionada falham de formas diferentes

O JSON baseado apenas no prompt pode acrescentar blocos de código, comentários, chaves duplicadas, vírgulas finais ou um objeto incompleto. A descodificação condicionada elimina muitas falhas de sintaxe, mas pode obrigar o modelo a escolher entre valores válidos quando “desconhecido” não era uma opção permitida.

A Fireworks explica como as escolhas de tokens restringidas pelo esquema mantêm a geração dentro de um contrato de saída, embora continuem a exigir que o prompt descreva corretamente os dados pretendidos.

Acompanhe ambas as famílias de falhas. Meça as falhas de análise no caso de saídas baseadas apenas no prompt e, depois de ativar a descodificação condicionada, meça os campos errados mas válidos, os valores predefinidos indesejados e a falsa certeza.

A amostragem e o truncamento amplificam pequenos erros

Uma temperatura mais elevada pode variar a escolha de chaves e os valores dos campos, enquanto um orçamento insuficiente de tokens pode truncar matrizes ou chavetas de fecho. Uma temperatura mais baixa reduz a variação, mas não torna verdadeiro um valor sem suporte.

Uma análise prática de um pipeline de saídas estruturadas local demonstra por que motivo a validação e a geração condicionada são componentes separados, e não um único truque de prompting.

Reserve tokens de saída suficientes para o maior objeto permitido, limite o tamanho das matrizes e repita apenas a parte que falhou. Regenerar o objeto inteiro pode substituir campos que já estavam corretos por novas alucinações.

Utilize um pipeline JSON local em duas etapas

Primeiro, resolva a tarefa num registo tipado mínimo: o segmento exato da origem, a data normalizada, o identificador selecionado, o estado de confiança e qualquer valor em falta explícito. Esta etapa deve poder rejeitar o pedido em vez de inventar dados obrigatórios.

Em seguida, apresente esse registo através de um descodificador condicionado pelo esquema, analise-o e execute verificações semânticas, como a existência do ficheiro, o intervalo de datas, a compatibilidade do valor enumerado e a consistência entre campos. Um validador deve devolver erros específicos que identifiquem o campo a corrigir.

A explicação da ZimaSpace sobre por que motivo um modelo mais pequeno pode ser mais fiável estabelece o limite: os modelos compactos funcionam melhor quando a tarefa, o contexto, o conjunto de ferramentas e o contrato de saída são suficientemente restritos para permitir a verificação.

Perguntas frequentes

Um JSON válido significa que o modelo não alucinou?

Não. Um JSON válido prova que o objeto segue as regras de sintaxe ou do esquema. Não prova que os valores dos campos vieram da origem ou correspondem ao estado real do sistema.

Definir a temperatura como zero resolve as alucinações em JSON?

Não. Pode tornar a saída mais repetível, mas um valor sem suporte selecionado de forma consistente continua a ser uma alucinação.

A descodificação condicionada é suficiente para a automatização?

Não. Utilize-a em conjunto com extração fundamentada na origem, análise do esquema, validação semântica e um caminho seguro de rejeição para dados em falta ou ambíguos.