Vai al contenuto

Analisi della correzione b11377 per response_format, precedenza sulle tool call, reasoning e test degli output strutturati.

L’ANALISI

Ling 3.0 in llama.cpp: cosa corregge davvero il supporto JSON Schema

Analisi della correzione b11377 per response_format, precedenza sulle tool call, reasoning e test prima/dopo degli output strutturati.

2 min di letturaFatti, limiti e fonti primarie
Release llama.cpp b11371 con supporto text-only al decision model Clef
La pagina ufficiale della pre-release llama.cpp b11371 che introduce il supporto text-only a Clef.

In breve: prima della b11377 il parser Ling 3.0 costruiva una grammatica per le tool call, ma ignorava inputs.json_schema nelle richieste response_format. La patch aggiunge una grammatica dedicata con precedenza sugli strumenti, richiede la chiusura del reasoning e impedisce testo dopo il JSON.

Il difetto corretto

Il percorso Ling 3.0 non trasformava inputs.json_schema in un vincolo grammaticale. Una richiesta di output strutturato poteva quindi produrre testo non conforme pur dichiarando response_format.

Che cosa cambia nella b11377

La release introduce un percorso eager per la grammatica di response_format e gli assegna precedenza rispetto alle tool call. Lo scopo è vincolare la risposta allo schema richiesto invece di lasciare libero il testo finale.

Reasoning e separazione del JSON

Quando il reasoning è attivo, la patch richiede la chiusura del blocco di pensiero prima dell’oggetto JSON. Inoltre non ammette prosa dopo il JSON, una condizione importante per parser e automazioni che consumano direttamente la risposta.

Impatto sui workflow locali

Il cambiamento interessa API locali, pipeline RAG e agenti che passano l’output a un validatore o a un servizio successivo. Riduce un difetto noto del parser, ma non sostituisce la validazione applicativa del risultato.

Condizioni e limiti

La b11377 è una prerelease e descrive una correzione di codice, non un benchmark di affidabilità. Schemi annidati, enum, campi obbligatori, quantizzazioni e template diversi possono ancora esporre errori: per flussi critici serve un test ripetuto e un validatore JSON Schema esterno.

Checklist per verificare il fix

  • Fissare una build precedente e la b11377.
  • Usare lo stesso modello Ling 3.0 e la stessa quantizzazione.
  • Preparare uno schema con oggetto annidato, required ed enum.
  • Eseguire almeno tre run per build con identici parametri.
  • Validare ogni risposta con un validatore JSON Schema esterno.
  • Rifiutare trailing prose e campi non previsti.
  • Ripetere il test con reasoning attivo e disattivato.
  • Registrare build, prompt, seed, errori e output grezzi.

Fonti primarie

Radar AI · a cura di Francesco Gruner

Chiedi al sito.

Assistente OpenAI

Le domande vengono inviate a OpenAI. Non inserire dati personali o riservati. Privacy.

Verifica le risposte nelle fonti. 16 messaggi al giorno per rete.

Cosa cerchi? Ti indico le pagine utili.