L’ANALISI
Heretic 2.0: plugin, modalità headless e migrazione
Heretic 2.0 introduce plugin e modalità headless, ma rompe la compatibilità con le configurazioni 1.x. Cosa controllare prima di aggiornare.
In breve: Heretic 2.0.0 è una major del programma per modificare modelli linguistici: aggiunge plugin e modalità headless, ma non accetta i file di configurazione 1.x senza migrazione. Non è un nuovo modello da scaricare e non dimostra, da sola, che il modello modificato sia migliore o sicuro.
Metodo: lettura della release ufficiale e di README e guida di migrazione fissati al tag v2.0.0. Non sono stati installati il programma o i suoi plugin, né modificati o confrontati modelli. Le indicazioni operative qui sotto sono una checklist proposta, non risultati di un test.
Che cosa cambia nella release 2.0.0?
La release è pubblicata il 1 novembre 2026 alle 13:03 UTC, cioè alle 14:03 in Italia, ed è indicata come non-prerelease dall’API GitHub. Le note segnalano il sistema generico di plugin, la modalità headless e test end-to-end nel progetto. Il punto pratico è che una pipeline può essere progettata senza passaggi interattivi; non significa che ogni configurazione sia già stata provata su ogni ambiente. Il changelog è la prova delle modifiche dichiarate, non un benchmark indipendente. Heretic 2.0.0: release e breaking changes.
Perché non basta riusare una configurazione 1.x?
L’incompatibilità è esplicita. La guida elenca opzioni rimosse, sezioni spostate e nomi modificati: per esempio chain_of_thought_skips diventa chain_of_thought_blocks, con una struttura diversa. Non basta sostituire il numero di versione e lanciare di nuovo un vecchio esperimento. Come precauzione operativa, conviene mantenere separati l’ambiente precedente, il file originale e una copia da migrare, annotando quali parametri sono cambiati. Guida ufficiale: migrazione da Heretic 1.x a 2.x.
Che cosa sono i plugin e che cosa non provano?
Il README distingue plugin che assegnano punteggi e plugin che modificano il modello. Gli scorer definiscono ciò che l’ottimizzatore cerca di migliorare; un punteggio favorevole dipende quindi dal criterio e dai dati scelti. Il documento descrive più scorer configurabili e un solo modifier per esecuzione. Questo rende esplicito l’obiettivo dell’esperimento, ma non certifica correttezza generale: migliorare una metrica può lasciare invariati o peggiorare altri comportamenti. Un plugin è inoltre codice da valutare prima di eseguirlo. README di Heretic fissato al tag v2.0.0.
Che fine fanno le funzioni di ricerca?
Le note rimuovono le precedenti funzioni di ricerca e indicano Lophius come sostituto previsto. La guida precisa che diverse opzioni di stampa e visualizzazione dei residui non sono più riconosciute. Per un workflow esistente è una differenza sostanziale, non un semplice riordino dell’interfaccia. In questa verifica non è stato provato Lophius: non va considerato un rimpiazzo equivalente già validato né una migrazione automatica. Heretic 2.0.0: release e breaking changes · Guida ufficiale: migrazione da Heretic 1.x a 2.x.
Come valutare un aggiornamento senza confondere i risultati?
Il progetto include, tra gli usi possibili, la soppressione dei rifiuti e avverte che questa è l’azione predefinita; descrive anche obiettivi diversi, come la riduzione della compiacenza. Minori rifiuti non equivalgono a maggiori capacità o minore rischio. Per una valutazione controllata propongo di confrontare base e derivato sugli stessi compiti leciti, conservare un insieme di controllo non usato per ottimizzare e annotare regressioni e condizioni dell’ambiente. Nessun risultato di questo confronto è disponibile qui. README di Heretic fissato al tag v2.0.0.
Condizioni e limitazioni
Analisi della release e dei documenti della versione 2.0.0, non prova eseguita. Plugin, test upstream e minori rifiuti non dimostrano qualità, sicurezza o compatibilità sul proprio hardware.
Checklist pratica
- Archiviare versione 1.x, configurazione originale e identificativi del modello base prima di cambiare ambiente.
- Leggere la guida v2.0.0 e annotare opzioni rimosse, rinominate e sezioni spostate.
- Esaminare dipendenze, provenienza e permessi di ogni plugin prima di eseguire codice.
- Definire un obiettivo lecito e metriche di qualità e sicurezza separate, senza equiparare meno rifiuti a più accuratezza.
- Pianificare un confronto controllato tra modello base e derivato con dati non sensibili e senza esporre servizi pubblici.
- Conservare modello e ambiente originali come rollback; non attribuire al progetto test locali non eseguiti.