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.

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.