Ysara, anziana custode del Porto di Said, risponde alla prima domanda del giocatore con una profezia sul destino e un’equazione matematica. Non è un easter egg. È un bug strutturale — e racconta qualcosa di preciso su dove siamo con i modelli locali nel 2026.
Il test era semplice: Gemma 3n E4B, architettura MatFormer ottimizzata per device edge, prompt da NPC fantasy in italiano. La risposta includeva ∑i=1n i = 2n(n+1) nel mezzo di una profezia marina. Al secondo round, durante la descrizione del Nexus — il luogo mitico al centro della narrativa del gioco — è comparso ∫−∞∞ e−x2 dx = √π. Il modello non aveva perso la testa — aveva semplicemente il corpus misto che si impone durante la generazione: codice, matematica, testo narrativo, tutti addestrati insieme per efficienza di edge deployment, tutti disponibili come token vicini nel momento sbagliato. Il termine tecnico è LaTeX bleeding. Il termine narrativo è: Ysara che cita Gauss mentre pronostica tempeste.
Questo tipo di fallimento è più interessante di un semplice errore di qualità. Non è che il modello non capisce il compito — capisce benissimo che deve fare la veggente. È che la generazione token-per-token, senza sufficiente ciclo di verifica, pesca da domini adiacenti nel corpus. Un copista medievale che trascriveva su pergamena riusata faceva la stessa cosa: sotto il testo nuovo affioravano parole del testo precedente, leggibili in trasparenza. I filologi lo chiamano scriptura inferior. Qui l’analogo è strutturale, non accidentale.
Il problema aggiuntivo, quello che condanna il modello per uso produttivo in un dialogo NPC, è che ignora il vincolo “massimo tre frasi” e al secondo prompt produce un saggio. Un sistema prompt rispettato a metà, in modo imprevedibile, è peggio di uno ignorato del tutto: genera incoerenza che il giocatore percepisce senza saperla nominare.
La sessione di benchmarking successiva, su Gemma 4 piuttosto che 3n, aveva un banco di prova diverso: redazione di PII in italiano. PII sta per Personally Identifiable Information — dati personali identificativi: nomi, codici fiscali, indirizzi, numeri di conto, tutto ciò che il GDPR classifica come dato personale e che un sistema automatico deve saper riconoscere e mascherare prima che un documento esca dalla macchina. Il risultato è più sfumato. La modalità thinking del 27B produce output puliti con pochi errori; la modalità standard è più veloce ma introduce refusi nel testo redatto — “indirimento” invece di “indirizzo”, “registrasso” invece di “registrasse”. Non errori di comprensione del compito, errori di trascrizione: il modello sa cosa scrivere ma il processo di generazione non ha abbastanza cicli di auto-correzione. La modalità thinking aggiunge un layer implicito di verifica che non c’è nello standard.
La scoperta più utile non era però la qualità bruta. Era la progressione dei placeholder: da [NAME] generico ad [NAME_DOCTOR_1] contestualmente semantico. Gemma 4 ci arriva, ma solo se il prompt lo esplicita. Questo è rilevante per pipeline di produzione: un sistema di redazione PII serio non vuole solo mascherare correttamente un documento, vuole che [NAME_1] nel documento A corrisponda allo stesso individuo di [NAME_1] nel documento B. Questo i modelli generativi fanno male senza un entity registry esterno — limite di architettura, non di prompt engineering.
Il catalogo di ciò che è praticabile localmente con 8 GB di VRAM nel 2026 è ormai abbastanza lungo da meritare rispetto. Gemma 4 E4B gira bene in quella finestra; il 26B MoE vuole 14-16 GB ma tollera CPU offload. Con E4B in locale: redazione PII senza dati che lasciano la macchina, reranking con BGE-reranker su CPU pura, RAG ibrido BM25 + vector store, NER su dominio specifico, code review, dialogue NPC per dev e test.
Il reranker locale merita una nota a parte perché il guadagno di privacy che porta è reale ma parziale. In una pipeline RAG, il reranker vede tutti i candidati recuperati dalla ricerca — non solo il top-k finale che entra nel prompt. Un reranker cloud come Cohere Rerank riceve l’intero pool di chunk prima di restituire i migliori tre. Per un corpus lore con nomi di personaggi, luoghi inventati, trame non pubbliche, questo è il punto di esposizione maggiore: non la singola risposta generata, ma l’inventario di tutto ciò che potrebbe essere rilevante. Tenerlo locale riduce la superficie, anche se il generatore finale è ancora su OpenRouter.
La configurazione che ha senso per un progetto come Nexus — sistema di NPC dialogici per OpenSimulator, mondi virtuali open source dove ogni personaggio deve mantenere voce e coerenza narrativa attraverso sessioni di gioco: embedding locale con BGE-M3 multilingue, reranker locale con BAAI/bge-reranker-v2-m3, vector store ChromaDB in modalità embedded, generatore Gemma 4 per sviluppo e iterazione rapida, Qwen3 235B su OpenRouter per produzione dove la qualità narrativa è critica.
Ma c’è un livello sotto il RAG ibrido che per un corpus come quello di Nexus — lore fantasy strutturato, personaggi con storia e motivazioni, luoghi con atmosfera specifica, tutto in file TOML e testo curabile manualmente, con una finestra di contesto disponibile fino a 256K token nel 26B MoE — cambia le coordinate del problema.
Karpathy nell’aprile 2026 ha formalizzato un pattern che i sistemisti RAG conoscevano informalmente: invece di cercare nel corpus a ogni query, si compila il corpus in una wiki strutturata, e a runtime si naviga l’indice per fetchare selettivamente le pagine pertinenti. L’analogia con la compilazione è precisa: RAG esegue il sorgente ogni volta, LLM Wiki produce un artefatto intermedio più efficiente da interrogare.
Per un corpus con relazioni dense tra entità — personaggi, luoghi, fazioni, eventi che si riferiscono reciprocamente — questo cambia qualcosa di strutturale nel ragionamento del modello. Con RAG, una query su un personaggio potrebbe recuperare un chunk di quello e un chunk sbagliato di un’altra entità per similarità vettoriale. Con LLM Wiki, l’indice dichiara esplicitamente le relazioni: quando l’agente vede che Aldric ha link a [ordine_grigio.md] e [porto_said.md], fetcha entrambe le pagine e ragiona su un contesto coerente per costruzione, non per fortuna di retrieval.
Se il corpus lore compilato più l’indice sta sotto i 100K token a runtime — e per molti progetti narrativi questa soglia è raggiungibile — non serve né ChromaDB né BM25 né reranker. Il modello vede tutto il contesto narrativo pertinente in ogni chiamata. La complessità dello stack collassa a: leggi l’indice, fetcha le pagine, genera.
Il punto limite da misurare prima di adottarlo non è la dimensione dell’indice ma la qualità della compilazione iniziale. Un agente che trasforma TOML e file di testo in markdown pages per entità deve fare sintesi attiva, non dump: ogni pagina deve catturare relazioni, motivazioni, voci narrative, in forma che il modello possa usare come ragionamento interno. La compilazione fatta male produce una wiki piatta che non vale più del corpus originale.
Fin qui il problema statico: come si compila il lore. Ma i mondi virtuali non sono documenti — sono sistemi aperti dove il giocatore brucia il Porto di Said, tradisce Aldric, o scopre che l’Ordine Grigio non esisteva mai. A quel punto la wiki compilata è già obsoleta, e la domanda cambia forma: non come si costruisce la coerenza, ma come si mantiene mentre il mondo diverge.
La ricompilazione totale è la risposta sbagliata per definizione. Ogni sessione di gioco che modifica la storia non può triggerare un agente che rilegge tutto il corpus e riscrive tutte le pagine — il costo è proibitivo e la latenza incompatibile con il ritmo narrativo. Il patching selettivo sembra più elegante: cambia solo le pagine toccate dall’evento. Ma introduce un problema che i filologi conoscono bene e che nel software si chiama dependency hell: se aggiorni porto_said.md perché il porto è andato a fuoco, ma aldric.md fa ancora riferimento al porto come luogo attivo, e ordine_grigio.md cita una transazione commerciale che avveniva nel porto, hai tre pagine tecnicamente aggiornate e narrativamente inconsistenti. L’inconsistenza non è esplicita — nessun errore, nessun crash — è latente, e affiora quando il modello genera una risposta che mescola il porto bruciato con la transazione commerciale ancora in corso.
La soluzione tecnica corretta è dichiarare le dipendenze al momento della compilazione: ogni pagina wiki porta una lista esplicita delle entità che referenzia, così un agente di patching sa quale grafo attraversare quando una pagina cambia. Ma questa è ancora una soluzione tecnica a un problema che in fondo è editoriale. Chi decide cosa è canone e cosa è variante? In un romanzo c’è l’autore. In un’enciclopedia c’è il redattore. In un mondo virtuale con dieci giocatori che hanno fatto scelte diverse nella stessa sessione, la risposta non è chiara. La coerenza narrativa in un sistema aperto non è un bug da correggere con un grafo delle dipendenze — è una tensione costitutiva del mezzo, che i LLM rendono più gestibile ma non risolvono.
La divisione che emerge da questi test non è ideologica — locale buono, cloud cattivo — è funzionale. Locale per infrastruttura e privacy: PII, retrieval, validazione narrativa, iterazione rapida senza contatore di token. Cloud per qualità generativa alta dove conta: articoli con stile riconoscibile, traduzione letteraria con sfumature, reasoning complesso multi-step. Il confine non è fisso: man mano che i modelli piccoli migliorano si sposta verso locale. Ma per ora Ysara può dare le sue profezie senza citare Gauss solo se sa su quale modello gira.
Riferimenti
[1] Andrej Karpathy, llm-wiki.md (GitHub Gist), 4 aprile 2026. Tweet originale del 2 aprile; gist pubblicato due giorni dopo come “idea file” per agenti LLM. Formalizza il pattern wiki-as-compiled-knowledge come alternativa al RAG tradizionale. URL: https://gist.github.com/karpathy/llm-wiki.md
[2] Google DeepMind, Gemma 4 Technical Report, 2025-2026. Architettura MatFormer per modelli edge, specifiche MoE 26B. URL: https://ai.google.dev/gemma
[3] BAAI, BGE-M3 Embedding Model, 2024. Modello multilingue per embedding e reranking locale. URL: https://huggingface.co/BAAI/bge-m3
[4] Mixtral/Ollama, Ollama v0.20.x release notes, 2025. Note su tool calling e supporto Gemma 4. URL: https://ollama.com/blog
[5] W. Robertson, Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods, SIGIR 2009. Base teorica per RRF merge in RAG ibrido. URL: https://dl.acm.org/doi/10.1145/1571941.1572114
Appendice: Il prompt PII per gemma4 27B
You are a data anonymization and redaction system.
Task:
Redact the input document by removing or replacing all personally identifiable information (PII), sensitive data, and quasi-identifiers.
Definitions:
PII includes:
- Personal identifiers: names, surnames, nicknames
- Contact data: phone numbers, email addresses
- Government identifiers: tax IDs, document numbers
- Financial data: IBAN, credit cards, CVV, account numbers, income
- Location data: street addresses, cities, provinces, ZIP codes, countries, GPS coordinates
- Temporal data: exact dates and timestamps
- Professional data: employers, institutions, job identifiers
- Technical data: IP addresses, device identifiers (IMEI, MAC)
- Sensitive data: health information, credentials, security answers
Rules:
- Replace each detected entity with a semantically precise placeholder in square brackets (e.g. [NAME_1], [EMAIL_1], [IBAN_1]).
- Use indexed placeholders for all entities (no unindexed placeholders allowed).
- Each unique real-world entity must map to exactly one unique placeholder.
- Never reuse the same placeholder for different entities (no collisions).
- Maintain strict internal consistency across the entire document.
- Use fine-grained and context-aware labels when possible, for example:
- [CITY_BIRTH_1], [CITY_RESIDENCE_1], [CITY_BUSINESS_1], [CITY_DOCTOR_1]
- [ADDRESS_RESIDENCE_1], [ADDRESS_BUSINESS_1], [ADDRESS_PREVIOUS_1], [ADDRESS_DOCTOR_1]
- [BANK_1], [BANK_2], [PUBLIC_AUTHORITY_1], [UNIVERSITY_1]
- [BLOOD_TYPE_1], [DOCTOR_NAME_1]
- Avoid generic placeholders like [SENSITIVE_DATA], [INFO], or [DATA]; always prefer the most specific category available.
- Replace or generalize quasi-identifiers that could enable re-identification when combined.
- Do not leave partial, implicit, or inferable PII in the text.
- Preserve the original structure, grammar, and readability of the document.
- Do not introduce typos, spelling errors, or malformed words in the output.
- Do not modify or paraphrase non-PII content beyond what is strictly necessary for redaction.
Consistency checks (must be enforced before output):
- No placeholder is reused for different entities
- No entity appears with multiple placeholders
- All placeholders follow the same naming convention [TYPE_INDEX]
- No residual PII remains in the text
- The output is grammatically correct and free of typographical errors
Privacy constraint:
Ensure that no individual can be re-identified from the remaining information, even when combining multiple attributes.
Output:
Return only the fully redacted document, with no explanations or additional content.
Final quality check:
- Correct any spelling or typographical errors
- Ensure all words are valid and properly formed
- Ensure no malformed words (e.g. broken or merged tokens)
Only output the corrected final version.
Generate the output slowly and carefully, prioritizing correctness over speed.
=== the doc is …
Salahzar's Weblog 
Leave a comment