Il problema dell’idea originale.
Il repository era nato come bot Telegram “psicologo”. Conservava conversazioni sensibili e presentava risposte generate come qualcosa di più vicino all’assistenza di quanto il software potesse sostenere.
Ho mantenuto la domanda ingegneristica utile, cioè come un piccolo classificatore testuale apprende e fallisce, ma ho rimosso account, trascrizioni, diagnosi e affermazioni terapeutiche. Il nuovo progetto rende visibili modello, suddivisione dei dati, policy di calibrazione e confine di sicurezza.
Ciò che serve a un esperimento credibile.
La riprogettazione doveva rendere più difficili da nascondere la contaminazione della valutazione e l’incertezza:
- I prompt correlati devono restare raggruppati, così le parafrasi non possono passare tra le partizioni di training e test.
- Calibrazione, selezione della policy, test in-distribution e test out-of-distribution richiedono ruoli dati separati.
- Evidenze deboli devono produrre un’astensione, non un’etichetta forzatamente sicura.
- Le implementazioni browser e Rust devono verificare lo stesso artefatto versionato e lo stesso contratto di inferenza.
Dall’accuratezza della demo a un protocollo.
Un singolo punteggio train/test non avrebbe risposto alle domande importanti. Non avrebbe mostrato se famiglie di prompt simili attraversavano la divisione, se le soglie venivano tarate sui dati finali di test o cosa accade fuori dal dominio di training.
Il protocollo v3 congela quindi partizioni consapevoli dei gruppi e separa fitting del modello, calibrazione delle probabilità, selezione della policy di astensione e valutazione finale. I tipi Rust impediscono ai set di test finali di entrare nelle API di selezione.
La pipeline open-set.
Una validazione TSV rigorosa alimenta una divisione deterministica consapevole dei gruppi. Un vocabolario TF-IDF costruito solo sul training e una regressione logistica multinomiale producono probabilità; il temperature scaling le calibra e una policy selezionata separatamente decide se il modello deve astenersi.
Perché queste tecnologie.
Lo stack privilegia un esperimento riproducibile e ispezionabile rispetto alla massima capacità apparente.
Rust per pipeline e CLI.
- Perché
- Tipi, build bloccate e un binario portabile rendono espliciti i ruoli dei dati e riproducibili i percorsi di verifica.
- Cosa ho escluso
- Un notebook o una pipeline solo Python favorirebbero l’esplorazione, ma lascerebbero più stato implicito e maggiore deriva dell’ambiente.
- Quanto è costata
- Accettiamo più lavoro di implementazione e un ecosistema ML meno ampio.
TF-IDF con regressione logistica multinomiale.
- Perché
- È proporzionata a un corpus sintetico piccolo e permette di ispezionare pesi, margini e calibrazione.
- Cosa ho escluso
- Un transformer sarebbe più opaco, costoso e sovradimensionato rispetto alle evidenze disponibili.
- Quanto è costata
- Accettiamo una comprensione semantica e una copertura linguistica limitate.
Un protocollo annidato consapevole dei gruppi.
- Perché
- Tiene unite le famiglie di prompt e separa scelta del modello, calibrazione e test finale.
- Cosa ho escluso
- Una divisione casuale lascerebbe filtrare parafrasi correlate e produrrebbe metriche ingannevolmente ottimistiche.
- Quanto è costata
- Accettiamo 506 addestramenti, più contabilità sperimentale e intervalli di incertezza visibili.
Astensione calibrata.
- Perché
- Un sistema open-set deve poter rifiutare evidenze deboli o fuori distribuzione invece di simulare certezza.
- Cosa ho escluso
- Forzare sempre una classe produrrebbe una risposta anche quando nessuna etichetta è sostenuta dai dati.
- Quanto è costata
- Accettiamo copertura inferiore, selezione delle soglie più complessa e nessuna pretesa che l’astensione elimini il rischio.
Le scelte che mantengono onesto il risultato.
Il progetto considera il protocollo di valutazione parte integrante del software.
Limitare le conclusioni ai dati sintetici
Risultati, intervalli ed errori descrivono esclusivamente le fixture sintetiche versionate dell’esperimento. Non vengono estesi a conversazioni reali, contesti clinici o copertura linguistica generale.
Il compromessoLa conclusione è più stretta e meno spettacolare, ma resta proporzionata alle evidenze effettivamente osservate.
Pubblicare l’intero percorso di selezione
Bundle, piano delle partizioni, probabilità out-of-fold, assegnazioni dei fold e graduatoria dei candidati vengono congelati e collegati tramite SHA-256, così il risultato scelto può essere ricostruito.
Il compromessoL’artefatto è più impegnativo da produrre e revisionare, ma impedisce che una sola metrica finale nasconda il percorso di selezione.
Spiegare il margine reale
Le predizioni espongono probabilità, confidenza, margine tra le prime due classi e contributi delle feature che ricostruiscono la differenza tra i logit vincenti.
Il compromessoL’attribuzione delle feature spiega il calcolo di questo modello lineare; non spiega il significato o l’intento umano.
Controlli di riproduzione e rilascio.
Modello, policy, metriche e piano delle partizioni vivono in un bundle collegato tramite SHA-256. La CLI può ricostruire il bundle, verificare ogni contratto ed eseguire inferenza batch limitata. Una precisione di reporting dichiarata mantiene il bundle v3 identico byte per byte tra i target di rilascio supportati.
Il codice Rust e quello browser eseguono fixture di parità sullo stesso modello. Un report di selezione separato e vincolato tramite SHA-256 pubblica ogni probabilità out-of-fold, assegnazione ai fold e posizione dei candidati; il browser ricalcola le metriche e si blocca se cambiano byte o aggregati.
Cosa dimostra il progetto.
ELIZA Lab dimostra un flusso completo per un piccolo modello: selezione annidata per gruppi, calibrazione, scelta della policy open-set, test congelato, verifica degli artefatti e inferenza locale.
Non è un terapeuta, un rilevatore di crisi o un modello linguistico di produzione. Il suo valore sta nella possibilità di ispezionare l’esperimento e riprodurre il risultato, invece di fidarsi di una demo opaca.
Registro delle evidenze.
Gli artefatti verificati mostrano insieme il risultato di selezione, il test congelato e i casi deboli:
- Protocollo di selezione
- 385 righe di training e sviluppo in 77 famiglie attraversano 11 fold esterni e 5 interni per gruppi, per un totale di 506 modelli addestrati.
- Risultato di selezione
- L’accuracy out-of-fold è 62,597% e il macro-F1 62,640%; l’intervallo al 95% per famiglia dell’accuracy è 57,143–68,571%.
- Test ID congelato
- Accuratezza dell’82,857% e macro-F1 dell’82,278% su 70 righe sintetiche in inglese.
- Risultato open-set
- La policy congelata copre il 62,857% delle righe ID e l’11,11% delle righe OOD; l’AUROC OOD è 0,80278 e l’FPR al 95% di TPR è 0,7778.
- Debolezza nota
- La fixture di contrasto da 28 righe raggiunge un’accuratezza per coppia del 42,86%; il progetto non nasconde questo limite.
Release verificata v1.6.0 Verifica del
Questo case study descrive la release immutabile v1.6.0 al commit cacd4448. Il tag firmato e i 20 artefatti attestati coprono Linux x64, Windows x64, macOS Intel e Apple Silicon. Il corpus sintetico non dimostra validità clinica, ampia copertura linguistica o idoneità alla produzione.