Mappa dei macro-temi e loro connessioni

La wiki come grafo: quattro macro-temi, ponti espliciti tra filosofia e agenti, e sei filoni trasversali che vale la pena seguire in diagonale.

Perché esiste questa mappa

La wiki è un grafo denso: circa trecento nodi e migliaia di collegamenti. La maggior parte dei collegamenti sono intra-Parte — il capitolo rag-base rimanda a rag-avanzato, perché stanno nella stessa sezione. Ma i collegamenti che davvero cambiano la comprensione sono tra Parti diverse: memoria-working (Parte III, scienze cognitive) che illumina memoria-agentica (Parte XVI, agenti); equilibrio-nash (Parte V, teoria dei giochi) che contestualizza rlhf-ppo (Parte XI, training).

Senza una mappa, questi collegamenti restano latenti. Il lettore che entra dritto in rlhf-ppo trova RL come strumento e lo usa; il lettore che ha attraversato prima Parte V capisce perché quella precisa formulazione e non un’altra.

Questa mappa serve a tre cose: scegliere il punto di ingresso giusto, costruire percorsi personalizzati quando i reading path ufficiali non bastano, e tenere a mente le connessioni mentre leggi in profondità un singolo capitolo.

Quattro macro-temi

Le ventidue Parti della wiki si raggruppano in quattro macro-temi.

Fondamenti teorici — Parti I-VIII. Storia dell’AI, filosofia della mente, scienze cognitive, matematica operativa, teoria dei giochi e decisioni, algoritmi e strutture dati, AI classica simbolica, machine learning. È la base teorica. Chi arriva dall’ingegneria del software troverà qui molto materiale nuovo; chi arriva dall’università ne troverà una parte familiare.

Internals dei modelli — Parti IX-XIII. Anatomia di un LLM (tokenizer, attention, transformer, sampling), architetture moderne (dense vs MoE, SSM, multimodali), training (pretraining, SFT, RLHF, quantization), reasoning e test-time compute, inferenza (KV cache, prompt caching, batching). È il “sotto il cofano” dei modelli: come sono fatti e come funzionano.

Pratica dei sistemi — Parti XIV-XVIII. Context engineering (RAG, memoria, compaction), prompt engineering, agenti (ReAct, tool use, MCP, memoria agentica), harness engineering (permessi, hooks, sandbox, sub-agenti), agent coding in pratica (Claude Code, Cursor, pattern reali). È il “come si costruiscono sistemi” attorno ai modelli.

Produzione e rischi — Parti XIX-XXII. Valutazione (benchmark, eval homegrown, LLM-as-judge), sicurezza (injection, data exfiltration, jailbreak), economia (pricing, cost optimization, latency budget, observability), casi studio end-to-end. È il “cosa serve per andare in produzione”.

La separazione è didattica, non rigida. Alcuni topic vivono al confine: mcp-in-profondità è insieme pratica (Parte XVI) e sicurezza (Parte XX, per la supply chain). prompt-injection-intro è prompt engineering (XV) ed è sicurezza (XX). La wiki evita di duplicare: ogni topic sta in un unico slug, con cross-reference.

I ponti espliciti

Gli slug con prefisso ponte- sono mini-saggi dedicati a connettere temi di Parti diverse. Sono il collante che impedisce alle Parti umanistiche di diventare digressioni gratuite e alle Parti tecniche di diventare ricettari senza anima.

ponte-memoria-agenti — la struttura della memoria umana (sensoriale, working, a lungo termine, dichiarativa/procedurale, episodica/semantica) illumina le scelte di design della memoria agentica. Non tutto si trasferisce, ma il vocabolario aiuta a formulare il problema.
ponte-attenzione-transformer — quanto del nome attention nei modelli moderni erediti davvero dalla psicologia sperimentale? Parte del parallelo è vero (meccanismo di routing selettivo), parte è ingannevole (nel cervello non c’è un dot product tra Q e K). Il ponte chiarisce entrambi i lati.
ponte-s1-s2-llm — il dual-process di Kahneman (Sistema 1 veloce, Sistema 2 lento) come metafora operativa per l’opposizione tra LLM “fast” e LLM “thinking” del 2024-2026.
ponte-bounded-rationality-ttc — la razionalità limitata di Simon come preludio al test-time compute: non ragioniamo all’infinito perché abbiamo vincoli. Un LLM thinking fa la stessa scelta esplicita.
ponte-metacognizione-self-correction — la metacognizione come cornice per reflexion, self-refine, self-critique negli agenti.
ponte-embodied-tool-use — embodied cognition (mente-nel-corpo) come cornice per capire perché il tool use è così potente: estendere l’agente con strumenti estende la sua cognizione, in senso stretto.
ponte-tom-multi-agent — theory of mind (il modello mentale dell’altro) come fondamento per orchestrazione multi-agent.
ponte-distribuzionale-embeddings — la semantica distribuzionale di Firth (“you shall know a word by the company it keeps”) come predecessore diretto di word2vec e degli embedding LLM.
ponte-gioco-principal-agent — alignment come problema principal-agent della teoria dei giochi: il principale (umano) vuole che l’agente (modello) persegua un obiettivo, ma l’agente ottimizza un proxy.

Sei filoni trasversali

Oltre ai ponti espliciti, esistono sei filoni che attraversano la wiki in diagonale. Non sono slug: sono prospettive utili per lettori che vogliono seguire un tema specifico attraverso Parti diverse.

Rappresentazione. Come si rappresenta la conoscenza in un sistema AI? Come simboli con regole (Parte VII: logica, ontologie, description logic). Come vettori densi (Parte IV: embedding; Parte IX: spazi di attenzione). Come grafi (Parte XIV: knowledge graph). Come ibridi (Parte VII: neuro-simbolico).

Apprendimento. Come il sistema impara? Dati etichettati (supervised, Parte VIII). Feedback scalare (RL, Parte V e Parte XI). Predizione del prossimo token (auto-supervised, Parte VIII e Parte XI). Esempi in contesto (in-context learning, Parte XV).

Scala. Cosa scala in AI? Parametri (Parte XI: scaling laws). Dati (Parte XI: pretraining-dati, data-mix). Contesto (Parte XIV: long-context, compression). Compute al training (Parte XI). Compute all’inferenza (Parte XII: test-time compute; Parte XIII: batching, paged attention).

Controllo. Come si controllano i sistemi AI? Durante il training (Parte XI: RLHF, constitutional AI). Durante l’inferenza (Parte XV: constraint prompting; Parte XIII: structured output, logit processors). Durante l’uso (Parte XVII: permessi, sandbox, hooks). Per sicurezza (Parte XX: contenimento di agenti compromessi).

Valutazione. Come si misura la qualità? Metriche ML classiche (Parte VIII: precision, recall, F1, AUC). Benchmark LLM (Parte XIX: MMLU, GPQA, HumanEval). Eval agentiche (Parte XIX: SWE-bench, tau-bench). Eval homegrown e LLM-as-judge (Parte XIX). Monitoring in produzione (Parte XXI).

Economia. Quanto costano i sistemi AI? Pricing dei token (Parte XXI). Ottimizzazione tramite cache (Parte XIII). Latency budget (Parte XXI). Cost accounting in harness multi-agent (Parte XVII).

Leggere la wiki seguendo un filone invece di un reading path da’ una prospettiva diversa. Il filone “Scala” porta a capire perché le decisioni del 2020 su Chinchilla influenzano il pricing del 2026. Il filone “Controllo” porta a vedere come lo stesso problema (far fare all’agente ciò che vogliamo) si presenta a strati diversi.

La tensione centrale

Una tensione attraversa la wiki e conviene nominarla: simbolico vs statistico vs deep learning vs LLM.

Non è una progressione monotona dove l’ultimo paradigma cancella i precedenti. È una stratificazione. Nel 2026, un sistema di produzione serio può contenere:

Un’ontologia simbolica per rappresentare le entita del dominio.
Un classifier ML classico per un task specifico ad alta frequenza.
Un’embedding model deep-learning per retrieval semantico.
Un LLM per generazione e reasoning.

Capire quale paradigma usare per quale pezzo del sistema è una competenza di design. La wiki tocca tutti gli strati (Parte VII per simbolico, Parte VIII per ML classico, Parte IX-XI per deep learning e LLM) proprio perché il praticante moderno non ha il lusso di ignorarne nessuno.

Tre zoom progressivi

Un modo pratico di usare la mappa: scegli lo zoom adatto al tuo problema.

Vista a 1000 miglia. Parte I (storia) fino a Parte XVIII (agenti oggi). Risponde alla domanda: come siamo arrivati qui? Utile quando sei nuovo al campo o quando spieghi a qualcun altro.

Vista a 100 miglia. Parte IX (anatomia LLM) fino a Parte XVII (harness). Risponde alla domanda: come funziona un sistema agentico moderno? Utile per progettare un sistema nuovo.

Vista a 10 miglia. Un pattern o un componente specifico, esplorato in profondità. Esempio: RAG. Si entra da rag-base e si segue il sottoalbero: rag-avanzato, chunking, embeddings-retrieval, reranker, hybrid search. Utile per risolvere un problema concreto.

La regola: il tempo speso a zoom sbagliato non è lineare, è quadratico. Studiare internals di quantization a fondo quando il tuo problema è un RAG che perde context è una perdita netta di tempo.

Come scegliere il punto di ingresso

Tre domande pragmatiche per orientarti:

Che cosa devi poter fare dopo? — Costruire un agente in produzione, capire un paper, decidere un’architettura, fare threat modeling, spiegare a un manager, ecc.
Cosa sai già bene? — Programmazione, ML classico, filosofia della mente, RL, nessuna di queste.
Quanto tempo hai? — Ore o mesi, prima della prossima demo o senza scadenza.

Le combinazioni più frequenti mappano direttamente a un reading path o a una Parte specifica:

“Costruire un agente, senza background ML, in tre mesi” -> practitioner-quick poi Parte XVIII.
“Capire un paper su attention, ho fondamenti matematici, tempo illimitato” -> llm-internals-deep.
“Spiegare a un manager, senza tempo” -> storia-sintesi + Parte XIX + Parte XXI + Parte XX.

Quando nessun reading path fa al caso tuo, torna alla mappa, identifica i due-tre macro-temi rilevanti, e compila una sequenza personale.

Filoni per filoni: dove iniziare

Se vuoi seguire un filone invece di un path, ecco i punti di ingresso consigliati.

Rappresentazione — inizia da Parte VII (AI classica, ontologie), poi Parte IV (embedding), poi Parte IX (spazi di attenzione). Chiudi con Parte XIV knowledge-graph.
Apprendimento — Parte VIII (ML classico), poi Parte XI (training LLM), con digressione su Parte V per RL.
Scala — Parte XI (scaling laws, compute-optimal), poi Parte XIII (inferenza), poi Parte XXI (economia).
Controllo — Parte XVII (harness), poi Parte XX (sicurezza), poi Parte XI (RLHF).
Valutazione — Parte XIX intera, poi Parte XVIII per eval agentiche specifiche.
Economia — Parte XXI, poi Parte XIII per ottimizzazione, poi Parte XI per capire i costi di training.

Pattern ricorrenti tra capitoli

Alcune strutture concettuali si ripresentano in Parti diverse con volti leggermente diversi. Riconoscerli accelera la lettura.

Tutte le ricorrenze elencate qui sotto sono analogie strutturali, non filiazioni storiche né equivalenze tecniche. La meccanica concreta di un KV cache e di una memoria agentica è diversissima; ciò che si ripete è la forma del problema (cosa conservare, cosa scartare, con quale costo). Riconoscere l’analogia accelera la lettura; trattarla come equivalenza confonde.

Caching e riuso. Il tema “come evitiamo di ricalcolare quello che sappiamo già” appare nella KV cache (Parte XIII), nel prompt caching provider-side (Parte XIII), nella memoria agentica persistente (Parte XVI), nel reasoning caching (Parte XII), nel filesystem come memoria (Parte XIV). La soluzione tecnica varia caso per caso; analogamente, il vincolo di sfondo è ricorrente: la computazione è costosa, la memoria è relativamente economica, conviene trovare il confine giusto.

Scheduling e priorità. Quale richiesta servire prima? Nella Parte XIII come batching e in-flight scheduling. Nella Parte XVI come orchestrazione multi-agent. Nella Parte XVII come task scheduling del harness. Nella Parte V come multi-armed bandit. Non è la stessa soluzione, ma la stessa famiglia di problemi, rivestita ogni volta in modo diverso.

Validazione di output. Come sappiamo che la risposta è buona? Nella Parte XV come constraint prompt. Nella Parte XIII come structured output. Nella Parte XIX come eval. Nella Parte XX come detection di jailbreak. Il “guardrail” è un’analogia comoda: la natura tecnica delle quattro soluzioni è eterogenea, ma rispondono tutte alla stessa domanda di fondo.

Compressione per efficienza. Nella Parte XI come quantization e distillation. Nella Parte XIV come context compression e LLMLingua. Nella Parte XVII come compaction automatica. Ognuna è una tecnica autonoma; il filo che le accomuna è il trade-off tra fedeltà e risorse, non una discendenza storica.

Separation of concerns. Nella Parte XVI come planner vs executor. Nella Parte XVII come main vs subagent. Nella Parte XVIII come agent vs IDE. Nella Parte XI come base model vs reward model. Qui l’analogia è con il design software classico applicato in nuovi contesti: non è una filiazione (l’AI non eredita queste pratiche da un singolo predecessore), è una convergenza progettuale.

Chi riconosce questi pattern impara più velocemente. Un nuovo capitolo non è interamente nuovo: è una variazione su un tema già visto altrove.

Esempio concreto di navigazione

Per rendere concreto come si usa la mappa, ecco un percorso realistico.

Scenario: “il mio agente ogni tanto cancella file in produzione per errore. Devo capire cosa succede e come prevenirlo.”

Passo 1 — macro-tema: è un problema di pratica dei sistemi (macro-tema 3) con forte accento su produzione e rischi (macro-tema 4). Inizio da li.

Passo 2 — Parte rilevanti: XVII (Harness Engineering) per il contenimento, XX (Sicurezza) per il threat modeling, XVI (Agenti) per la struttura del loop agentico.

Passo 3 — slug specifici da Parte XVII: permessi-sandbox (allowlist, sandbox), hooks-lifecycle (intercettare tool call rischiose), subagenti (isolation del contesto), worktree-isolation (separare il filesystem operativo), sicurezza-harness (confused deputy, path traversal).

Passo 4 — slug da Parte XX: agent-compromesso (contenere il danno), data-exfiltration (canali di fuoriuscita).

Passo 5 — ponte utile: ponte-gioco-principal-agent per capire che l’agente persegue un proxy, non l’obiettivo vero; questo chiarisce perché è sbagliato dargli fiducia illimitata per default.

Passo 6 — filone: “Controllo”. Seguendo il filone scopro che la soluzione non è solo in XVII: durante il training (Parte XI), RLHF prova a insegnare al modello di non fare certe cose; durante l’inferenza (Parte XV), guard clauses nel prompt; durante l’uso, harness permissions. Ogni strato contribuisce.

La lettura risultante è circa dieci slug in tre Parti, più un ponte, più un filone. Costo: due-tre sessioni di lavoro. Rispetto a leggere in ordine, risparmio settimane mantenendo la risposta al problema concreto.

Errori tipici nell’usare la mappa

Leggere troppo largo. Cercando di coprire tutti i macro-temi prima di scendere nei dettagli, finisci per restare alla superficie. Meglio profondità verticale su un tema urgente, poi espansione laterale.

Ignorare i ponti. Capita di saltare la Parte III (scienze cognitive) perché sembra “filosofica”. I ponti sono il motivo per cui quella Parte esiste: se li salti, la wiki perde meta del suo valore formativo.

Confondere path e mappa. I reading path sono letture lineari con uno scopo. La mappa è una vista d’insieme senza scopo preciso. Usa i path per imparare, la mappa per orientarti.

Ignorare i filoni trasversali. Leggere solo verticalmente Parte per Parte perde le analogie. Un capitolo in Parte XI diventa molto più chiaro se lo incontri sapendo di aver già visto lo stesso pattern in Parte XIII.

Trattare la mappa come definitiva. È un modello, non una verità. Se per te una certa Parte andrebbe in un altro macro-tema, probabilmente hai ragione per il tuo uso specifico. La mappa ufficiale è uno dei molti modi di organizzare.

Limiti della mappa

Una mappa non è il territorio. La struttura a quattro macro-temi è un’astrazione utile ma forza separazioni che nella realtà sono sfumate. harness-definizione (Parte XVII) è praticamente un capitolo di fondamenti teorici dei sistemi agentici: potrebbe stare in Parte XVI. scaling-laws è insieme internals (come scala la loss) e economia (quanto costa scalare): sta in Parte XI ma potrebbe stare in Parte XXI.

I sei filoni sono esemplificativi, non esaustivi. Si potrebbero definire altri filoni utili: “generalizzazione” (come i modelli generalizzano out-of-distribution), “interpretabilità” (mechanistic interpretability attraversa Parte IX e Parte XX), “multimodalita” (Parte X e Parte XVI), “temporalita” (caching, context window, memory in tutte le Parti).

I ponti espliciti non esauriscono le connessioni. Ogni capitolo ha una sezione Collegamenti che rimanda ad altri capitoli, spesso tra Parti diverse. La densita reale del grafo supera ciò che questa mappa mostra.

Quando la mappa diventerà obsoleta

Una mappa concettuale riflette una teoria implicita di come il campo è organizzato. Quella teoria cambia.

Nel 2017 la separazione “internals LLM” non aveva senso: gli LLM non dominavano. Nel 2022 “harness engineering” non era un concetto distinto: gli agenti erano demo, non sistemi. Nel 2026 alcune cose che sembrano ovvie potrebbero sembrare ingenue nel 2030. Forse il macro-tema “Pratica dei sistemi” si dividerà in due, uno per agenti single-turn e uno per loop lunghi autonomi. Forse i filoni che oggi chiamo “controllo” diventerà “co-abitazione” quando i sistemi diventeranno agenti permanenti.

La mappa va rivista ogni anno. Non come riorganizzazione drastica, ma come aggiornamento delle etichette e delle enfasi. Gli slug restano stabili, le raggruppazioni evolvono.

Verso una mappa visiva

Attualmente la mappa vive come testo strutturato in questo capitolo. In futuro, quando il progetto avrà un sito, la mappa diventerà un grafo visivo interattivo: nodi per slug, frecce per collegamenti, colori per Parti, heat map per densita di traffico. Un lettore potrà partire da un nodo qualunque e navigare liberamente.

Per ora, testo + outline.md + sezioni Collegamenti dei capitoli sono l’equivalente funzionale.

FAQ rapida sulla mappa

“La mappa contraddice i reading path?” — No. La mappa descrive la struttura statica; i path propongono traiettorie. Sono strumenti complementari, non alternativi.

“Posso saltare le Parti umanistiche?” — Tecnicamente si, e la maggior parte dei capitoli tecnici funziona anche senza. Ma perdi i ponti. Chi legge solo le Parti tecniche impara le ricette; chi legge anche i ponti capisce perché quelle ricette.

“Perché solo quattro macro-temi?” — Perché sono suffic ientemente pochi da stare in testa e sufficienti per orientarsi. Tre sarebbero troppo pochi (il macro-tema fondamenti diventerebbe abnorme). Cinque introdurrebbero una separazione forzata tra contenuti affini.

“Dove mettete la Parte II (filosofia) nei macro-temi?” — Nel primo macro-tema (fondamenti teorici). È il tema che da i concetti per ragionare sugli altri: cosa significa “capire”, cosa è un agente morale, cosa vuol dire AGI. Senza questo vocabolario, le altre Parti diventano operazionalmente utili ma concettualmente mute.

Collegamenti

intro-wiki — il quadro generale del progetto.
percorsi-lettura — letture curate lineari, alternativa alla navigazione libera sulla mappa.
storia-sintesi — l’asse temporale che attraversa la mappa dal passato al presente.
../outline.md — enumerazione di tutte le Parti e slug, complementare a questa mappa.
Gli slug ponte-* in Parte III e Parte V — i nodi-chiave della mappa concettuale viva.