Spunto: «Jev» in 25 righe di Python, o la softmax che smonta l’hype

La tesi

Il post di NobodyWho (595 punti su Hacker News) sostiene che «Jev», il classificatore di cui si parla ovunque, non è niente di più di un prompt con scelte etichettate e una softmax ristretta sui logit di un LLM qualunque, eseguibile in locale in 25 righe di Python.

Come la argomenta

  1. Apre sull'ironia dell'hype ("Everyone and their mom is talking about Jev") e annuncia subito il gioco: ecco Jev in 25 righe.
  2. Mostra il caricamento di un GGUF piccolo — Qwen3-0.6B-Q8_0 via Llama.from_pretrained, con logits_all=True e contesto a n_ctx=512 — dichiarando che va bene qualunque modello GGUF.
  3. Costruisce un prompt ChatML con tre opzioni etichettate A/B/C (Legitimate, Spam, Phishing) su un'email di esempio, pre-riempiendo un blocco <think> vuoto nella parte assistant.
  4. Estrae i logit dell'ultimo token, li riduce ai tre token-etichetta e applica la log-softmax, stampando logits, log-probabilità e probabilità: phishing al 0.885.
  5. Fissa l'identikit: "This is Jev" — classifica e restituisce probabilità, veloce, locale, dati che non escono dalla macchina.
  6. Scarica in anticipo le obiezioni (nessun "System One decision model", nessuna API, nessun dato sintetico, nessun RLCD) e chiude dichiarando la natura di parodia, con rimando a implementazioni open più complete: OpenJev, openjev-sglang, OpenJev su DiffusionGemma.

I punti più forti

  • Il codice è completo e riproducibile: metadati PEP 723, dipendenze dichiarate, valori di output nel commento. Non è retorica, è una demo.
  • La matematica torna: i numeri mostrati sono esattamente quelli di una log-softmax sui tre logit (differenze dal massimo più una costante log-sum-exp di 0.122). Chi conosce la tecnica non può liquidarla come sbagliata.
  • Il bersaglio dell'attacco è dichiarato con precisione: il paragrafo "But no, you don't understand Jev!" elenca punto per punto ciò che il post non fa, senza fingere il contrario.
  • Il tema privacy è concreto, non di facciata: modello locale, verbose=False, nessun dato inviato.

Dove è discutibile

  • Il post non spiega mai cosa sia Jev, chi l'abbia rilasciato né cosa prometta: chi non conosce già il bersaglio legge una striscia a cieco. RLCD e "System One decision model" sono citati di striscio, mai valutati.
  • L'esempio è una singola email di test. Nessuna accuracy, nessun confronto con l'originale, nessun benchmark: "It's fast" resta un'asserzione.
  • La frase "(even though they are not always correct)", incastonata tra parentesi, è l'ammissione che le probabilità del trucco non sono calibrate — cioè il problema che Jev, presumibilmente, risolve con l'addestramento.
  • La nota finale rimanda a implementazioni "better/more complete": implicitamente l'autore concede che la versione in 25 righe non è la storia intera.
  • Nessun dato su hardware, latenza o qualità su modelli più piccoli o task diversi dalla classificazione a tre etichette mono-token.

Domande aperte

  1. Quando ti è servita una vera calibrazione delle probabilità (soglie, costi di errore asimmetrici) e dove invece un argmax su etichette con softmax ristretta basta e avanza?
  2. Quanto regge l'approccio fuori dal caso demo: etichette multi-token, più di tre opzioni, prompt lunghi contro n_ctx=512, un 0.6B su task tuoi?
  3. Il blocco <think> vuoto nel prompt: quanto incide disattivare il ragionamento sulla stabilità delle probabilità in un modello thinking come Qwen3?
  4. Nel tuo stack, dove finisce il trade-off tra classificatore a logit in locale e API gestita: latenza, costi, conformità dei dati, aggiornamenti dei modelli?

Citazioni utili

  • "It classifies: it gets a prompt with choices and outputs probabilities."
  • "It's fast. It's local. You don't send your data anywhere else."

lillodipiazza

Scritto da

Sviluppo backend e strumenti interni. Scrivo qui le note che vorrei aver trovato io mentre risolvevo il problema.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *