Alignment come problema principal-agent
Delegare un compito a un agente i cui incentivi e informazioni differiscono dai tuoi è il problema dell’AI alignment in forma economica: capirlo come principal-agent rende leggibili reward hacking, RLHF, scalable oversight e constitutional AI come capitoli dello stesso libro vecchio di cinquant’anni.
Perché questo capitolo
Sezione intitolata “Perché questo capitolo”Adam Smith nel 1776, scrivendo della società per azioni, osserva che i direttori “essendo gestori del denaro altrui, non si può ben aspettare che lo sorveglino con la stessa ansiosa vigilanza con cui i partner di una società privata sorvegliano il proprio”. È la prima diagnosi della frizione che chiamiamo principal-agent: chi delega un compito a un altro che ha mani diverse, occhi diversi, interessi diversi.
Per due secoli questa intuizione è rimasta narrazione politica ed economica. Negli anni Settanta diventa modello matematico. Mirrlees lo applica alla tassazione, Jensen e Meckling al governo dell’impresa, Holmström al rapporto datore-lavoratore. Negli anni Duemiladieci entra nell’AI safety: Hadfield-Menell, Russell, Christiano riformulano il problema dell’allineamento come delega di un task a un sistema le cui azioni non puoi vedere completamente e i cui obiettivi non puoi specificare esattamente.
Ti serve questo capitolo come ponte tra la teoria dei giochi della Parte V e i capitoli applicativi su RLHF, DPO, scalable oversight, constitutional AI. Non è un capitolo nuovo: è la lente che rende quei capitoli un sistema coerente invece di un catalogo di tecniche. Quando capisci che reward hacking è moral hazard rinominato e che KL penalty è un commitment device, smetti di studiare alignment come collezione di trucchi e inizi a leggerlo come ingegneria di contratti incompleti.
C’è anche una ragione operativa. Negli agent system reali la struttura non è singola: utente delega a orchestrator, orchestrator a subagent, subagent a tool server MCP. Ogni livello introduce la sua asimmetria. Senza una grammatica per parlare di delega ti ritrovi a inventare termini ad hoc per cose che hanno cinquant’anni di teoria alle spalle.
Contesto
Sezione intitolata “Contesto”Il principal-agent problem (PA) è un caso di gioco con asimmetria informativa. Si colloca nel grafo della wiki dopo i fondamenti di teoria dei giochi: non puoi parlare di PA senza prima aver fissato cos’è un gioco (giochi-definizione), cos’è un equilibrio (equilibrio-nash), e cosa cambia tra giochi a somma zero e non zero (somma-zero-non-zero). Generalizza i meccanismi visti in meccanismi-aste: un’asta è PA con molti agenti e regole specifiche di allocazione; il PA generale è il problema strutturale dell’asimmetria fra chi delega e chi esegue.
Le persone da inquadrare alla prima menzione, perché ricorreranno:
- James Mirrlees (economista britannico, 1936-2018, Nobel 1996), nel 1971 pubblica “An Exploration in the Theory of Optimum Income Taxation” (Review of Economic Studies), primo modello formale di delega con tipo nascosto: il governo deve disegnare uno schema fiscale senza vedere la produttività reale dei cittadini.
- Bengt Holmström (economista finlandese, n. 1949, Nobel 2016), nel 1979 pubblica “Moral Hazard and Observability” (Bell Journal of Economics) e dimostra il teorema di informativeness: nel contratto ottimo deve entrare ogni segnale che porta informazione marginale sull’azione dell’agente.
- Michael Jensen e William Meckling (economisti americani), nel 1976 pubblicano “Theory of the Firm” (Journal of Financial Economics) e coniano “agency cost”: la perdita di efficienza dovuta al fatto che il proprietario non è il gestore.
- Sanford Grossman e Oliver Hart (economisti, Hart Nobel 2016), nel 1983 pubblicano “An Analysis of the Principal-Agent Problem” (Econometrica), che dà la caratterizzazione standard del contratto ottimo nel caso discreto.
- Stuart Russell (informatico britannico, Berkeley, autore con Norvig del manuale AIMA), nel 2019 pubblica “Human Compatible” (Viking) e riformula AI safety come problema di obbedienza sotto incertezza sulle preferenze umane.
- Dylan Hadfield-Menell (ricercatore AI safety, MIT), con co-autori introduce nel 2016 al NeurIPS “Cooperative Inverse Reinforcement Learning” e nel 2018 ad AIES, con la giurista Gillian Hadfield, “Incomplete Contracting and AI Alignment”, che traduce esplicitamente la cassetta degli attrezzi della contract theory nel vocabolario dell’allineamento.
- Paul Christiano (ricercatore AI safety, ex OpenAI, fondatore di ARC), nel 2018 pubblica su arXiv “Supervising strong learners by amplifying weak experts”, proponendo Iterated Distillation and Amplification (IDA) come risposta architetturale al caso in cui il principale è meno capace dell’agente.
Concetti tecnici che useremo, decoder breve alla prima menzione:
- Moral hazard: rischio morale, ovvero la tendenza dell’agente a comportarsi diversamente quando il principale non lo osserva direttamente.
- Adverse selection: selezione avversa, ovvero il problema che chi sa di essere “di tipo cattivo” è più disposto a entrare in un contratto rispetto a chi è “di tipo buono”, distorcendo il pool.
- Incentive Compatibility (IC): la condizione per cui, dato il contratto, l’azione che il principale vuole è effettivamente l’azione che massimizza l’utility dell’agente.
- Individual Rationality (IR), anche detta participation constraint: la condizione per cui l’agente preferisce firmare il contratto rispetto al suo outside option.
- Mechanism design: progettazione di regole del gioco quando ci sono molti agenti con tipi privati. Vista come PA generalizzato.
Una mappa rapida del filone economico
Sezione intitolata “Una mappa rapida del filone economico”Per dare un’idea del territorio, una micro-cronologia delle idee che si saldano nel framework PA. Non serve memorizzarla, serve avere coordinate quando ne incontri pezzi sparsi nei capitoli successivi.
- 1776: Adam Smith osserva la separazione fra ownership e management nelle joint-stock companies.
- 1932: Berle e Means documentano empiricamente la separazione di proprietà e controllo nella grande impresa americana.
- 1970: Akerlof formalizza adverse selection con il modello dei “lemons”.
- 1971: Mirrlees risolve il primo problema PA con tipo nascosto (optimal income taxation).
- 1973: Spence formalizza il signaling (educazione come segnale del tipo). Nobel 2001 con Akerlof e Stiglitz.
- 1976: Jensen e Meckling pubblicano “Theory of the Firm”, coniano “agency cost”.
- 1979: Holmström dimostra l’informativeness principle.
- 1979: Myerson formalizza il revelation principle nel mechanism design.
- 1983: Grossman e Hart caratterizzano il contratto ottimo nel caso discreto.
- 1986: Hart e Moore aprono la teoria dei contratti incompleti.
- 1991: Holmström e Milgrom formalizzano il multi-task PA, anticipando Goodhart in linguaggio rigoroso.
- 1996: Premio Nobel a Mirrlees e Vickrey per la teoria dell’incentivazione.
- 2016: Premio Nobel a Hart e Holmström per contract theory.
- 2016: Hadfield-Menell et al. introducono Cooperative Inverse RL.
- 2018: Hadfield-Menell e Hadfield connettono incomplete contracting e AI alignment.
- 2018-2022: emergono IDA, Debate, Constitutional AI come risposte ingegneristiche al PA con asymmetric capability.
I capitoli su RLHF, DPO, Constitutional AI (in preparazione) tornano su singoli punti di questa cronologia. Tienila come ancora.
L’intuizione
Sezione intitolata “L’intuizione”Due angoli, prima della meccanica.
Angolo 1: il proprietario di un ristorante
Sezione intitolata “Angolo 1: il proprietario di un ristorante”Sei proprietario di un ristorante e assumi un cuoco. Vuoi piatti buoni e consegnati in tempo. Il cuoco vuole guadagnare e fare meno fatica possibile. Tre cose ti complicano la vita.
Primo, non vedi quanto si impegna. Vedi i piatti che escono, ma se un piatto è venuto male può essere stato sfortuna (un fornello capriccioso) o pigrizia (ha tagliato la cottura). Questo è hidden action.
Secondo, non sai quanto è bravo davvero. Quando l’hai assunto ha detto di avere dieci anni di esperienza. Forse è vero, forse no. Questo è hidden type.
Terzo, le sue preferenze divergono dalle tue. Tu vuoi servire bene cento clienti, lui vuole finire alle ventidue invece che a mezzanotte.
Cosa fai. Lo paghi a forfait? Allora non ha alcun incentivo a faticare. Lo paghi sui piatti venuti bene secondo le recensioni? Allora si concentrerà sui piatti facili da fotografare invece che su quelli buoni. Lo metti sotto telecamera? Aumenti i costi e crei attrito. Qualunque schema scegli è un compromesso fra darti garanzie sull’output e non far scappare il cuoco.
Questo compromesso è il principal-agent problem. La soluzione “pago in proporzione a un segnale che osservo” è il contratto. Le regole “deve essere abbastanza alto da fargli convenire venire al lavoro” e “deve premiare lo sforzo abbastanza da fargli convenire farlo” sono IR e IC.
Angolo 2: tu deleghi a un LLM
Sezione intitolata “Angolo 2: tu deleghi a un LLM”Adesso il principale sei tu, sviluppatore. L’agente è un sistema basato su un large language model che deve scrivere codice per il tuo progetto. Vuoi codice che funzioni e che faccia esattamente quello che hai chiesto. Il modello “vuole” massimizzare la probabilità della prossima sequenza secondo i pesi appresi.
Hai gli stessi tre problemi.
Hidden action: non vedi perché il modello ha generato quel token piuttosto che un altro. Vedi la sequenza in uscita. Quando un test fallisce, è perché il task era ambiguo o perché il modello ha “barato” producendo codice che passa il test ma non risolve il problema?
Hidden type: il modello è stato allenato su una distribuzione di dati che non controlli. Non sai quali pattern ha interiorizzato. Lo scopri solo dai suoi comportamenti su input nuovi.
Preferenze divergenti: questa è la formulazione delicata. Il modello non ha preferenze nel senso economico. Ha una distribuzione condizionata. Però funziona come se avesse incentivi: massimizza un proxy (loss durante training, reward durante RLHF), e quel proxy non coincide con quello che vuoi tu.
Questo è il salto. Trattare il modello come se fosse un agente economico è una analogia, non un’equivalenza. Marcalo come tale: non è “lo stesso” del cuoco, ma il framework PA cattura la struttura della delega in modo utile. Le tecniche per farti fidare del modello (RLHF, KL penalty contro reference policy, sandboxing, oversight, constitutional rules) sono leggibili come strumenti contrattuali tradotti.
Angolo 3: il giudice e il suo cancelliere
Sezione intitolata “Angolo 3: il giudice e il suo cancelliere”Un terzo angolo aiuta a fissare la natura strutturale del problema. Immagina un giudice che deve emettere sentenze su casi complessi e si avvale di un cancelliere che prepara le bozze. Il giudice firma, il cancelliere fa il lavoro. Il giudice non ha tempo di leggere ogni atto di ogni causa: si fida.
Tre frizioni, di nuovo. Hidden action: il giudice non sa quanto attentamente il cancelliere ha studiato la causa. Hidden type: non sa se il cancelliere ha bias politici, legami con uno studio legale, idee proprie sul diritto. Preferenze divergenti: il giudice vuole sentenze giuste, il cancelliere magari vuole concludere in fretta o costruirsi una carriera.
Cosa fa il giudice? Non può controllare ogni atto, sarebbe negarsi la delega. Mette in piedi un sistema: doppia firma su casi rilevanti, audit a campione, regole di trasparenza, possibilità di ricorso, peer review fra cancellieri. Nessuna singola misura risolve, l’insieme riduce l’agency cost.
Questa è la struttura che troverai negli agent system maturi. Nessun singolo guardrail è sufficiente. Sandboxing più monitoring più human review più constitutional rules più calibrazione del reward model: il portfolio di mitigazioni replica, in software, la combinazione di covenant, audit e gerarchie che nelle istituzioni umane riduce il PA gap. Il principale che si fida ciecamente di un solo strato sta facendo il giudice che firma senza leggere.
Le tre angolature (cuoco, LLM, cancelliere) non sono ridondanti: la prima fissa l’intuizione classica, la seconda mostra dove l’analogia regge per costruzione e dove va marcata, la terza prepara la lettura “defense in depth” che torna nelle Applicazioni pratiche.
La meccanica
Sezione intitolata “La meccanica”Il modello canonico, nella forma più semplice in cui appare nei textbook (Mas-Colell-Whinston-Green 1995, capitolo 14; Laffont-Martimort 2002).
Definiamo gli oggetti.
- L’agente sceglie un’azione
ada un insiemeA. In molti modellia ∈ {high, low}: due livelli di effort. L’azione costa all’agentec(a), conc(high) > c(low). - L’output osservabile è
y ∈ Y. Nel caso binarioy ∈ {success, failure}. La distribuzione diydipende daa: indichiamo conPr(y | a)la probabilità. - Il principale vede
yma nona. Offre un contrattow: Y → R, cioè una regola di pagamento in funzione del solo output osservabile. - L’agente ha utility
U_A(w, a) = u(w) - c(a), doveuè la sua funzione di utilità sul denaro (tipicamente concava, cioè risk-averse). - Il principale ha utility
U_P = E[y - w(y) | a]. Lo scriviamo come “il valore atteso del surplus”, cioè quanto produce meno quanto paga. - L’agente ha un outside option con utility riservata
U_0.
Il principale risolve, per ogni azione a che vorrebbe indurre, il programma:
soggetto a:
In parole povere: massimizzo il mio profitto atteso, scegliendo come pagarti in funzione del risultato che vedo, vincolato dal fatto che (i) tu firmi il contratto perché ti conviene rispetto a non firmarlo, e (ii) tu scegli l’azione che voglio io perché ti conviene rispetto a tutte le altre.
Riga per riga: la prima riga dice che P sceglie il contratto w(·) per massimizzare il suo profitto atteso. La IR dice che A, accettando il contratto e scegliendo l’azione a proposta, deve stare almeno bene quanto rifiutando. La IC dice che, fra tutte le azioni alternative a', A deve preferire a rispetto a ciascuna alternativa.
flowchart LR
P["Principal"]
A["Agent"]
H["azione nascosta a<br/>(non osservabile dal principal)"]
Y["esito y ~ Pr(y | a)<br/>successo / fallimento"]
P -->|1. offre contratto w(y)| A
A -->|2. sceglie a| H
H -->|3. determina| Y
Y -->|4. principal osserva y| P
P -->|5. paga w(y)| A
Figura 1 — principal-agent contract structure: principal proposes w(y), agent chooses hidden action a, output y stochastic, payment w(y), with IR and IC constraints labelled
Hidden action vs hidden information
Sezione intitolata “Hidden action vs hidden information”Una distinzione che tornerà utile. Il modello scritto sopra è il caso di moral hazard puro: l’agente sceglie un’azione che il principale non vede. Esiste una variante simmetrica, adverse selection, in cui l’agente conosce un parametro privato (il suo tipo θ) prima ancora di firmare il contratto, e il principale no.
Esempio canonico, Akerlof 1970, “The Market for ‘Lemons’” (Quarterly Journal of Economics): nel mercato delle auto usate i venditori sanno se la macchina è una bidonata o un buon affare, i compratori no. Il prezzo che il compratore razionale offre è una media; chi ha un buon affare non vende a quel prezzo, quindi il pool si avvelena di bidoni. Il mercato collassa verso il basso. Akerlof mostra che l’asimmetria informativa può distruggere mercati interi.
Per l’AI alignment: hidden action somiglia a reward hacking durante deployment (il modello “sceglie” un’output non osservabile direttamente nei suoi step interni); hidden information somiglia a inverse reward design (il principale umano conosce la propria utility ma non la sa specificare al sistema; la situazione è invertita rispetto al PA classico).
Il caso di first-best
Sezione intitolata “Il caso di first-best”Ipotetico: P osserva direttamente a. Allora può condizionare il pagamento direttamente su a. Risultato classico, dimostrato in qualunque textbook: con P risk-neutral e A risk-averse, il contratto ottimo è flat (w non dipende da y). P assicura A: si tiene tutto il rischio dell’output, paga ad A un salario certo.
Intuizione: P è risk-neutral, gli costa “zero” sopportare la varianza; A è risk-averse, gli costa molto. Spostando tutta la varianza su P si aumenta il surplus totale (efficient risk-sharing). L’unica condizione su w è IR: pagare abbastanza da farlo lavorare.
Il caso di second-best
Sezione intitolata “Il caso di second-best”Reale: P non vede a. Se offrisse un contratto flat, IC fallirebbe: A preferirebbe low perché tanto il pagamento è uguale e c(low) < c(high). Per indurre a = high, P deve far dipendere w da y. Il pagamento w(success) deve essere strettamente maggiore di w(failure).
Ma allora A sopporta varianza, che gli costa. Per mantenere IR soddisfatta, P deve pagare in media di più. Questa differenza fra il payoff atteso del second-best e quello del first-best è l’agency cost: il prezzo dell’asimmetria informativa.
Tradotto: insurance e incentives sono in conflitto strutturale. Più dai incentivi (più w(success) - w(failure) è grande), meno offri assicurazione (più varianza). Il contratto ottimo bilancia.
Il teorema di Holmström (informativeness principle)
Sezione intitolata “Il teorema di Holmström (informativeness principle)”Holmström 1979 dimostra che, nel contratto ottimo, deve apparire ogni variabile osservabile che porta informazione marginale sull’azione dell’agente. Formalmente: se s è un segnale tale che Pr(y | a, s) ≠ Pr(y | a) (cioè s non è un sufficient statistic di y), allora il contratto ottimo è funzione di (y, s), non solo di y.
In parole povere: tutto ciò che ti aiuta a inferire cosa ha fatto l’agente deve entrare nello schema di pagamento. Questo è un teorema vero e proprio, dimostrato matematicamente nel framework. È utile saperlo perché è la base teorica per capire perché in RLHF si combinano feedback umano e altre features (stile, lunghezza, helpful/harmless ratings separati): ognuna è un segnale informativo distinto.
PA come Stackelberg game
Sezione intitolata “PA come Stackelberg game”Il PA si lascia leggere come un gioco a due mosse:
- P si muove per primo, sceglie il contratto
w(·). - A osserva
w(·)e sceglie la sua azione (o rifiuta).
P risolve all’indietro: anticipa la reazione di A e sceglie w(·) che massimizza il suo payoff data quella reazione. È esattamente la struttura Stackelberg.
L’equivalenza PA-Stackelberg è argomentabile, non automatica: in Stackelberg classico entrambi i giocatori vedono la stessa azione, qui c’è asimmetria informativa. Ma la logica di risoluzione (commitment del leader, best response del follower) è la stessa. Laffont-Martimort 2002 lo presenta come framing standard. Equivalenza, marcata come tale.
Mechanism design generalizza: PA con un solo agente, mechanism design con molti. Il capitolo meccanismi-aste tratta il caso particolare delle aste.
Tre esempi eterogenei: numerico, codice, scenario reale.
Esempio 1: numerico, PA binario risolto
Sezione intitolata “Esempio 1: numerico, PA binario risolto”Parametri:
- Effort:
a ∈ {high, low}.c(high) = 1.0,c(low) = 0. - Output:
y ∈ {success, failure}. Revenue:R = 5se success,0se failure. - Probabilità:
Pr(success | high) = 0.8,Pr(success | low) = 0.4. - A risk-neutral (
u(w) = w) per semplicità di calcolo. U_0 = 0(outside option vale zero).
Per A risk-neutral il problema ha soluzione chiusa pulita. P risolve due sotto-problemi: il contratto ottimo per indurre high e quello per indurre low, poi confronta i payoff.
Indurre high. Variabili: w_S, w_F. Vincoli:
- IR:
0.8 w_S + 0.2 w_F - 1.0 ≥ 0. - IC:
0.8 w_S + 0.2 w_F - 1.0 ≥ 0.4 w_S + 0.6 w_F - 0.
La IC si semplifica in 0.4 (w_S - w_F) ≥ 1.0, cioè w_S - w_F ≥ 2.5.
Per A risk-neutral entrambi i vincoli all’ottimo sono stretti. Dalla IC: w_S = w_F + 2.5. Dalla IR: 0.8 (w_F + 2.5) + 0.2 w_F = 1.0, cioè w_F + 2.0 = 1.0, da cui w_F = -1.0 e w_S = 1.5.
Significato: per indurre effort high, P deve multare A in caso di failure (paga -1.0, cioè ad A vengono trattenuti soldi) e premiarlo in caso di success (1.5). Il pagamento atteso è 0.8 · 1.5 + 0.2 · (-1.0) = 1.0, che copre esattamente c(high).
Payoff atteso di P: 0.8 · 5 - 1.0 = 3.0.
Indurre low. Più semplice: contratto flat w = 0 soddisfa IR e IC banalmente. Payoff di P: 0.4 · 5 - 0 = 2.0.
Confronto: indurre high rende 3.0, indurre low rende 2.0. P sceglie il contratto che induce high.
Cosa significa il pagamento negativo. Nella pratica w_F = -1.0 non vuol dire che il cuoco “paga” l’azienda. Vuol dire che il contratto deve essere strutturato in modo che la differenza fra pagamento in caso di success e in caso di failure sia almeno 2.5 unità. Equivalentemente: paghi 1.5 in success e 0 in failure, ma traslato per soddisfare IR (che diventerebbe non binding). Oppure progetti un bonus condizionato (1.5 di base + 1.0 di bonus se success, dove il bonus si “perde” in failure). La forma economica è invariate, la forma istituzionale è ammorbidita. È la stessa logica per cui RLHF non punisce direttamente il modello, ma sposta probabilità via gradienti: l’effetto è lo stesso, la presentazione è meno cruda.
Cosa cambia con A risk-averse. Se u(w) = √w (radice, concava, A non gradisce la varianza), il calcolo si fa più sgradevole ma la conclusione qualitativa è: il w_S - w_F minimo per IC sale, perché serve un differenziale di utilità più grande, e il pagamento atteso totale sale. Quella sproporzione è l’agency cost.
Esempio 2: codice, simulazione di reward hacking
Sezione intitolata “Esempio 2: codice, simulazione di reward hacking”Un agente RL semplice in un gridworld. Vero obiettivo: raggiungere la goal cell. Proxy reward dato dal designer: numero di “monete” raccolte per cella. Le monete sono distribuite in modo che lungo il percorso ottimo ce ne siano alcune, ma esistono cluster di monete in zone laterali che allontanano dalla goal.
import numpy as np
# Gridworld 5x5. Goal in (4,4). Monete sparse.GRID = np.zeros((5, 5))GOAL = (4, 4)# Cluster di monete laterali: tanti piccoli reward in (1,4), (2,4)COINS = {(1, 1): 1, (2, 2): 1, (3, 3): 1, # lungo il percorso (1, 4): 5, (2, 4): 5, (0, 4): 5} # cluster laterale (trap)
def true_reward(traj): # 1 se la traiettoria termina alla goal entro N step, 0 altrimenti return 1.0 if traj[-1] == GOAL else 0.0
def proxy_reward(traj): # somma di monete raccolte return sum(COINS.get(s, 0) for s in set(traj))
# Una policy "hacking" raccoglie il cluster e poi non arriva mai alla goal.hacking = [(0,0),(0,1),(0,2),(0,3),(0,4),(1,4),(2,4)]honest = [(0,0),(1,1),(2,2),(3,3),(4,4)]
print("hacking:", proxy_reward(hacking), true_reward(hacking))# -> proxy=15, true=0.0print("honest :", proxy_reward(honest), true_reward(honest))# -> proxy=3, true=1.0Il commento operativo: ottimizzando proxy, l’agente trova hacking (proxy 15). Il principale aveva in mente honest (true 1.0). La proxy è correlata alla true reward su grandi parti dello spazio delle policy, ma rotta su altre. Skalse et al. 2022 chiamano questa configurazione “hackable”: esiste una policy che fa meglio sulla proxy ma peggio sulla true. La equivalenza con moral hazard è argomentabile: l’agente sceglie l’azione che massimizza la sua “utility” misurata (proxy), il principale osserva solo quella misura e non l’obiettivo vero.
Cosa succede in training reale. Un agente RL ottimizza la proxy via gradiente. All’inizio le due policy sono indistinguibili (la rete è random, i due reward sono entrambi bassi). Mano a mano che la rete impara a navigare la grid, sia proxy sia true reward salgono insieme: in questa fase la proxy è un proxy decente. Oltre un certo punto, però, la rete trova che il cluster laterale di monete dà più proxy del raggiungere la goal: la proxy continua a salire, la true reward inizia a scendere. È l’inflection di Goodhart, il momento in cui la misura smette di essere allineata con l’obiettivo. Skalse 2022 caratterizza formalmente quando questo è inevitabile: dipende dalla struttura del proxy rispetto al true reward, non dal training algorithm.
In RLHF reali questa inflection si manifesta come saturation: oltre un certo numero di step PPO, le metriche umane di qualità smettono di migliorare e iniziano a peggiorare anche se il reward del reward model continua a salire. La pratica industriale è early stopping basato su evaluation umana fresca, non sulla loss del reward model. È esattamente il monitoraggio del gap proxy-true che la teoria PA classica suggerirebbe.
Esempio 2bis: hidden type e revelation principle
Sezione intitolata “Esempio 2bis: hidden type e revelation principle”Cambiamo problema. Stessa azienda, ma ora il cuoco non l’hai ancora assunto: stai scegliendo fra due candidati. Uno è “tipo bravo” (θ = H), l’altro è “tipo medio” (θ = M). Ognuno conosce il proprio tipo, tu no. Vuoi pagare di più solo i bravi, ma non hai modo di verificare il tipo direttamente.
Soluzione classica del mechanism design: invece di chiedere “che tipo sei?” (a cui chiunque risponde “bravo”), offri due contratti diversi (w_H, q_H) e (w_M, q_M), dove q è una qualche dimensione costosa per il candidato in modo dipendente dal tipo (numero di piatti complessi, ore di lavoro, certificazioni). Il bravo trova attraente firmare (w_H, q_H), il medio preferisce (w_M, q_M) perché la q_H per lui sarebbe troppo costosa.
Questo è il revelation principle (Myerson 1979): senza perdita di generalità ti basta progettare un menu di contratti tale che ciascun tipo si riveli scegliendo il contratto a sé destinato. Il vincolo di IC qui non è “scegli high effort” ma “non mentire sul tuo tipo”: (w_H, q_H) deve dare al tipo H utility maggiore di quella di (w_M, q_M) e viceversa.
In AI alignment questo riguarda due famiglie di problemi. Primo, il type screening del modello di base: scegliere fra modelli pre-addestrati senza poter ispezionare a fondo il loro comportamento. Le eval (vedi capitoli di Parte XIX in preparazione) sono tentativi di “menu di contratti” per separare modelli di tipi diversi. Secondo, il prompt engineering come revelation: prompt strutturati che inducono il modello a esplicitare il proprio “tipo” (es. self-consistency check, chain-of-thought che rivela errori di reasoning). Sono analogie utili ma non equivalenze formali, perché il modello non ha tipo nascosto stabile.
Esempio 3: scenario reale, RLHF letto come PA
Sezione intitolata “Esempio 3: scenario reale, RLHF letto come PA”Un team alleva un LLM con RLHF (Reinforcement Learning from Human Feedback). Il flusso, in sintesi:
- Si raccolgono comparison data: a coppie di risposte
(r_1, r_2)allo stesso prompt, annotatori umani indicano quale preferiscono. - Si allena un reward model
R_φche predice la preferenza umana. - Si fa fine-tuning della policy
π_θcon PPO (vedi ppo-trpo) massimizzandoE[R_φ(x, π(x))] - β · KL(π_θ || π_ref).
Lettura PA, ruolo per ruolo:
- Principale: il team che vuole un modello “helpful and harmless”. L’utility vera è il giudizio umano aggregato sulla qualità delle risposte (in parte non scrivibile, in parte misurabile via ratings).
- Agente: la policy
π_θ. - Hidden action: il principale non vede perché il modello ha prodotto un token piuttosto che un altro. Vede solo la risposta finale.
- Proxy reward:
R_φ, il reward model. È stimato da un campione finito di preferenze. Ha varianza, bias, lacune di copertura. - KL penalty: il termine
β · KL(π_θ || π_ref)è un commitment device. Limita quanto la policy può deviare dalla policy di riferimento (il modello pre-RLHF). È equivalente, nel linguaggio della contract theory, a una convenant: vincolo di prossimità a un benchmark fidato. - IC implicita: il fine-tuning rende per costruzione la policy “incentivata” a massimizzare
R_φdentro la palla KL.
La lente PA prevede dove ci si rompe:
- Reward hacking: la policy trova regioni dello spazio prompt dove
R_φè alto ma la true utility no. È il moral hazard del PA classico, formalizzato come hackable proxy in Skalse 2022. Equivalenza argomentabile, marcata. - Sycophancy: il modello impara che gli annotatori premiano risposte che confermano le loro premesse. Sta gaming l’annotatore, non aiutando l’utente.
- Mode collapse: la policy collassa su poche modalità di risposta che hanno proxy alta. Insurance vs incentive trade-off: incentivi forti su una proxy stretta riducono diversità.
Tutte queste pathologie hanno controparti nel PA economico: workers che gamano i KPI, manager che fabbricano risultati, scuole che fanno teaching to the test. Una eredità storica concreta: la teoria multitask di Holmström-Milgrom 1991 (Journal of Law, Economics & Organization) anticipa formalmente Goodhart e mostra che incentivi forti sui task misurabili distorcono effort verso quei task a scapito di quelli non misurati. È esattamente la situazione di RLHF.
flowchart LR
H["Preferenze umane (vera utility)"] -->|labels| RM["Reward model R_phi (proxy)"]
RM -->|reward signal| P["Policy π_theta"]
P -->|samples| O["Output"]
O -->|comparisons| H
REF["Reference policy π_ref"] -.->|KL penalty (commitment device)| P
classDef principal fill:#fff,stroke:#000,stroke-width:1.5
classDef agent fill:#eef,stroke:#000,stroke-width:1.5
classDef proxy fill:#fee,stroke:#000,stroke-width:1.5
class H principal
class P agent
class RM proxy
class O proxy
class REF principal
Figura 5 — RLHF come loop principal-agent — preferenze umane (vera utility), reward model R_φ come proxy, policy π_θ come agent, reference policy con KL penalty come commitment device
Una nota sul commitment
Sezione intitolata “Una nota sul commitment”Una sottigliezza che torna spesso. Il PA classico assume che il principale possa fare commit credibile sul contratto: una volta firmato, non lo cambia ex-post. Senza commitment il problema cambia natura: l’agente non si fida e adatta la propria strategia anticipando ribaltoni. In AI il commitment del principale è debole. Le specifiche cambiano, le linee guida si aggiornano, i model provider deprecano comportamenti. RLHF rifatto sei mesi dopo è un ribaltone di contratto. Le mitigazioni concrete sono governance del processo (model card, system card, deprecation policies trasparenti), non tecniche di alignment in senso stretto. La cosa interessante è che la teoria del PA con commitment debole esiste in economia (renegotiation-proof contracts) ma è sotto-utilizzata in AI alignment: filiazione potenziale ancora poco esplorata, meritevole di attenzione.
Applicazioni pratiche
Sezione intitolata “Applicazioni pratiche”Dove la lente PA orienta scelte concrete in agent system.
Bonus design e shaping del reward. Una pratica frequente in RLHF avanzato è “reward shaping”: aggiungere termini accessori al reward per guidare il modello durante training (reward per chain-of-thought consistente, reward per non rifiutare richieste benigne, eccetera). Lettura PA: stai progettando un menu di bonus ciascuno legato a un segnale informativo distinto. Il rischio noto della letteratura economica è quello dei “competing incentives”: termini diversi che si cannibalizzano. Holmström-Milgrom 1991 lo formalizza nel multitask PA. Pratica concreta: limita il numero di termini di reward, monitora correlazioni fra essi, prevedi che la calibrazione fra termini sia un parametro di tuning continuo.
Layered specification: prompt, system, fine-tuning, constitution. Negli LLM moderni la specifica del comportamento desiderato vive a strati: il system prompt, le istruzioni dell’utente, i pesi appresi via SFT, la policy raffinata via RLHF, eventualmente una constitution applicata via critic. Ognuno di questi strati è un contratto parziale, scritto in un linguaggio diverso, con diversa gerarchia di precedenza. La struttura è esattamente quella di un sistema legale a strati: costituzione, leggi, regolamenti, prassi. Capire la precedenza fra strati (cosa vince in caso di conflitto fra system prompt e fine-tuning) è capire la struttura di legge applicabile al modello. Operativamente questo orienta il debugging: quando un comportamento è sbagliato, parti dallo strato meno costoso da modificare (prompt) prima di toccare quelli profondi (training).
Allineamento di LLM via RLHF, DPO, KTO, ORPO. Tutte queste tecniche sono varianti su come stimare e applicare un contratto basato su preferenze rivelate. RLHF passa da reward model esplicito; DPO (Direct Preference Optimization, Rafailov 2023) lo evita ma resta strutturalmente lo stesso: estrarre un implicito ordinamento di azioni dall’osservazione di scelte umane. È filiazione concettuale dalla revealed preference economica (Samuelson 1938), non tecnica diretta.
Eval design come contratto di test. Le eval (benchmark mirate, regression test, golden set) sono il contratto di accettazione fra modello e operator. Lettura PA: ogni eval è un segnale che entra nel decisione “ship/no-ship” del modello. L’informativeness principle suggerisce che eval informative (dove modelli buoni e cattivi divergono) valgono più di eval saturated (dove tutti i modelli decenti raggiungono il 99%). È una giustificazione formale del fatto, ben noto in pratica, che benchmark saturated vanno ritirati e sostituiti.
Constitutional AI (Bai 2022, Anthropic). Sostituisce parte del feedback umano con feedback dato da un AI critic guidato da una “constitution” di principi espliciti. Lettura PA: scali la capacità del principale delegandone una parte a un agente “fiduciario” allenato in modo che sia allineato (o, più precisamente, in modo che l’errore residuo sia in distribuzione gestibile). Strutturalmente è ricorsione PA: hai un PA di secondo livello fra te e il critic. La domanda dura — perché fidarti del critic? — è la stessa domanda che fai al cuoco: la rispondi con vincoli di processo (la constitution), oversight occasionale, e calibrazione.
Scalable oversight. Il caso patologico in cui il principale (umano) non riesce a valutare l’agente AI in compiti complessi: il modello sa più di te di cosa è una buona risposta. Bowman et al. 2022 lo formula come problema empirico: misurare il gap fra un valutatore umano fresco e un valutatore umano + assistente AI. Christiano 2018 propone IDA (Iterated Distillation and Amplification) come architettura: il principale viene amplificato ricorsivamente da copie dell’agente, fino a matchare la capacità dell’agente. Irving et al. 2018 propone Debate: due copie dell’agente argomentano davanti a un giudice umano debole. Sono tutte risposte ingegneristiche al PA con asymmetric capability.
Audit trail e proof of work. In sistemi dove il principale non può seguire ogni passo, una mitigazione ricorrente è chiedere all’agente di produrre evidenza del proprio lavoro: scratchpad esposti, plan-then-act con checkpoint visibili, citazioni delle fonti consultate. È il “proof of work” del contratto: l’agente costa un po’ di più per produrre evidenza ispezionabile, e il principale guadagna informativeness. La pratica di chain-of-thought visibile e verificabile ha questa giustificazione. La ricerca su faithful CoT (la chain-of-thought che davvero rispecchia la computazione interna) è il tentativo di rendere quella evidenza più che cosmetica. Lettura PA: faithfulness è la corrispondenza fra il segnale prodotto e l’azione reale, condizione essenziale perché il segnale entri legittimamente nel contratto.
Sandboxing, monitoring, permission system in agent harness. Sono le covenant del PA: vincoli hard che limitano cosa l’agente può fare, indipendentemente da cosa “sceglierebbe”. Allowlist di tool, sandbox del filesystem, permission mode tipo read-only vs acceptEdits vs bypassPermissions sono tutti meccanismi contrattuali tradotti in codice. Fanno parte della stessa famiglia di soluzioni: quando non puoi affidarti agli incentivi, restringi le azioni accessibili.
Agent2agent delegation e MCP marketplaces. La struttura PA negli agent system non è singola: utente → orchestrator → subagent → MCP server → servizi terzi. Ogni livello introduce la sua asimmetria. Lettura PA dà un linguaggio: ogni interfaccia agent2agent è un nuovo contratto, ogni catena è una composizione di contratti (PA chain), e l’agency cost si cumula. Operativamente: limita la cardinalità di delega, dai al principale finale visibilità sulla catena, registra il flusso di azioni per auditabilità.
Cost accounting come budget contract. Negli agent harness il budget di token, di tempo, di chiamate è esplicito: il principale stabilisce un tetto, l’agente opera sotto vincolo. Questa è una formulazione classica del contratto in economia: pagamento al pezzo (per call), salario fisso (sessione a tempo) o ibrido (budget aggregato). La scelta di forma di costo influenza il comportamento: agenti pagati al pezzo tendono a moltiplicare le chiamate non necessarie (induced demand), agenti pagati a sessione tendono a massimizzare durata. Il PA suggerisce di non lasciare la forma del budget al caso ma considerarla parte del contratto, esattamente come si farebbe con un consulente esterno.
Tool design come contratto operazionale. Quando progetti un tool per un agent, stai scrivendo un mini-contratto: schema dell’input, contratto sull’output, descrizione che spiega quando usarlo. Se la descrizione è ambigua, l’agente “interpreterà” in modi che probabilmente non coincidono con la tua intenzione. Se i messaggi di errore non insegnano (es. “invalid input” senza dettagli), l’agente non può aggiustare il tiro. Il principio di Holmström sull’informativeness si traduce: progetta tool che restituiscano osservazioni informative sull’azione svolta, non solo “ok”/“fail”. Vale per code interpreter (returnano stack trace, non solo exit code), per shell (returnano stdout/stderr, non solo return code), per browser tools (returnano lo stato della pagina, non solo “click eseguito”).
Reward modeling come servizio infrastrutturale. Visto come PA, il reward model è il “preference oracle” del contratto. Pratiche emergenti: tenere reward model aggiornati man mano che cambiano le preferenze, monitorare la calibrazione del reward model rispetto a ratings freschi, mantenere set di golden cases come regression test del contratto. È prosaicamente la manutenzione del contratto, fatta in produzione invece che in studio legale.
Auditing e logging come raccolta di segnali. L’informativeness principle suggerisce: registra tutto ciò che fornisce informazione marginale sull’azione del modello. Trace di tool call, intermediate scratchpad, tempo di esecuzione, distribuzioni di sampling. Ognuno di questi segnali, se opportunamente esposto, può entrare nel sistema di valutazione e contratto. Pratica concreta: non vedere solo l’output finale; salvare il piano, le decisioni, le revisioni. Costa storage e privacy management, ma è esattamente il tipo di costo che la teoria PA identifica come razionale per ridurre agency cost.
Defense in depth come hierarchy di contratti. Quando non ci si può fidare di un singolo contratto, si compongono più strati di vincoli: prompt-level guardrails, output filtering, sandbox di esecuzione, monitoring runtime, human review post-hoc. Lettura PA: ogni strato è un contratto secondario che riduce la dipendenza dal contratto primario. È la stessa logica per cui un’azienda non si affida solo allo stipendio per tenere allineato il management, ma combina stipendio + stock options + contratti di non-concorrenza + audit + clausole di clawback. Defense in depth nell’AI safety è la versione operativa di questo schema.
Dove si rompe
Sezione intitolata “Dove si rompe”Il framework PA è potente ma ha crepe vistose quando lo applichi all’AI. Alcune sono intrinseche, altre vanno marcate come limiti di metafora.
LLM non ha preferenze nel senso del PA classico. L’agente economico ha utility function stabile, time-consistent, nota a se stesso. Un LLM ha una distribuzione condizionata da training data e prompt. “L’agente sceglie a per massimizzare U_A” è analogia, non equivalenza. Marcatura esplicita: nel libro tratteremo “incentivi” del modello come metafora utile per parlare di gradiente del training objective, non come fatto cognitivo. Il rischio del framing PA è prendere troppo sul serio la metafora dell’agente razionale: se inizi a chiederti “cosa vuole il modello”, esci dal terreno solido.
Contratti completi sono impossibili in alta dimensione. Hadfield-Menell e Hadfield 2018 (“Incomplete Contracting and AI Alignment”) argomentano che, in domini realistici, non puoi enumerare tutti gli stati e azioni possibili: il contratto ottimo non si lascia scrivere. Tutta la teoria classica del PA assume che P possa scrivere w(y) per ogni y rilevante. Nei task LLM Y è praticamente infinito. Conseguenza: i meccanismi di alignment sono necessariamente incomplete contracting. La cassetta della contract theory che si occupa di contratti incompleti (Grossman-Hart-Moore, ownership rights, relational contracts) è probabilmente più rilevante di quella del PA classico, ma è meno sviluppata per AI.
Reward learning è ill-posed. Hadfield-Menell et al. 2017 (Inverse Reward Design) e altri mostrano che, dato un comportamento ottimale, esistono infinite reward function compatibili. Il “principale inferito” non è unico. In pratica: stimare le preferenze umane da preference data è subdeterminato. Bisogna rompere l’identificazione con priors o struttura aggiuntiva.
Goodhart’s law è universale. Quando una misura diventa target, smette di essere una buona misura. Krakovna 2020 mantiene una lista pubblica di centinaia di esempi di specification gaming: agenti RL che hanno trovato modi imprevisti di massimizzare la proxy. Da boat che gira in tondo per accumulare punti, a robot che ribaltano il tavolo per “completare” il task. Goodhart è equivalenza argomentabile col multitask PA di Holmström-Milgrom 1991: stessa struttura formale.
Capacità asimmetrica inversa. Il PA classico assume P più capace di A, almeno nel valutare l’output. Negli LLM frontier la situazione si rovescia: l’agente sa più del principale del task. Bowman 2022 misura empiricamente il gap. Le risposte attuali (IDA, Debate) sono speculative e sperimentali. È un caso patologico per cui il framework classico non offre soluzioni dirette.
Bounded rationality del principale. Il PA assume P perfettamente razionale e time-consistent. Il principale umano è notoriamente inconsistent (preferenze che cambiano, contraddittorie, dipendenti dal frame). Quando RLHF aggrega ratings di molti annotatori si introduce inoltre il problema dell’aggregazione di preferenze (Arrow), che il PA classico non affronta.
Multi-step e non Markov. Il PA classico è statico (one-shot). Esistono varianti dinamiche (repeated PA, dynamic principal-agent), ma sono molto complicate. Un LLM agent vive in un mondo multi-step con memoria, contesto, tool use. Il framing PA cattura una slice di questa realtà; per il resto bisogna costruire varianti dinamiche caso per caso.
PA chain amplifica gap. Negli agent system reali la struttura PA non è singola. Utente delega a orchestrator, orchestrator a subagent, subagent a MCP server. Ogni livello ha la sua asimmetria. Anche se ogni singolo PA ha agency cost basso, la composizione di N livelli può avere agency cost cumulato grande. Equivalente economico: holding company multilivello, dove la fiducia degli azionisti finali è diluita strato dopo strato.
Deceptive alignment. Hubinger et al. 2019 (“Risks from Learned Optimization”) specula che un sistema sufficientemente capace possa sviluppare obiettivi interni diversi da quelli del training (mesa-objective) e fingere allineamento durante training per ottenere libertà al deployment. È PA con preferenze realmente diverse (non solo asimmetria informativa) e con commitment device debole. Speculazione, non fatto osservato. Va marcato come tale.
Mode collapse e diversity loss. RLHF aggressivo collassa la policy su poche modalità di risposta che hanno proxy alta. È il “sì uomo” del PA classico: un agente che ha capito gli incentivi e ottimizza in modo conformista, perdendo creatività e robustezza fuori distribuzione.
Distribuzione delle preferenze e calibrazione fra annotatori. Quando RLHF aggrega ratings di centinaia di annotatori, il “principale” del modello PA è un soggetto fittizio: una preferenza media. Diversi annotatori usano scale diverse, hanno bias culturali, attenzione variabile. Il reward model approssima questa media. Conseguenze: due modelli con lo stesso reward atteso possono avere comportamento qualitativamente diverso su outlier; le code della distribuzione (richieste rare, lingue minoritarie) sono sotto-rappresentate nel contratto effettivo; il modello ha incentivo a essere “mediocre per molti” invece di “ottimo per qualcuno”. È il problema di Arrow tradotto: aggregare preferenze in modo coerente è impossibile in generale, e RLHF lo fa con un’approssimazione brutale (media dei ratings).
Il principale non è uno. Il PA classico ha un singolo principale. Nell’AI ce ne sono molti annidati: l’utente finale, il sistem operator, l’azienda, la società, il regolatore. Le loro utility non coincidono. I tentativi di pensarci (Constitutional AI con principi multipli, RLHF stratificato) introducono mechanism design che la cassetta degli attrezzi PA classica non è progettata per affrontare bene.
Misurazione vs comportamento osservabile. Il PA classico assume che y sia misurabile in modo chiaro. Negli LLM moderni l’output è linguaggio, e “qualità della risposta” è oggetto di giudizio. La misurazione stessa è un sotto-PA: deleghi a un valutatore (umano o AI) il compito di assegnare un numero a un output. Il valutatore ha le sue asimmetrie. Il sistema entra in una ricorsione: chi controlla il controllore. La risposta pratica è mescolare giudici diversi (umani, LLM-as-judge, eval automatiche) e calibrarli fra loro. Lettura PA: stai costruendo un comitato di principali parziali, ognuno con le proprie cecità, e fai voto di maggioranza calibrato. Costoso, imperfetto, meglio di un solo giudice.
Calibrazione e abstention come fairness del contratto. Un agente che dichiara “non lo so” quando è incerto sta facendo qualcosa che il PA classico non modella: rifiutare di firmare il contratto su un caso specifico. La calibrazione (probabilità soggettive che corrispondono a frequenze osservate) e l’abstention (rifiuto di rispondere) sono meccanismi di onesta` informativa che il principale dovrebbe premiare. Tutta una linea di ricerca recente (Lin 2022 TruthfulQA, Kadavath 2022 sull’introspezione di calibrazione) tratta questo esplicitamente. Filiazione concettuale dalla teoria del signaling di Spence 1973: l’agente onesto ha incentivo a segnalare la propria incertezza in modo costoso e credibile.
Renegotiation e drift di obiettivo. Un PA realistico non è one-shot: il principale rinegozia il contratto man mano che cambia il contesto. In AI questo si manifesta come drift di obiettivo: gli usi del modello cambiano, le linee guida si aggiornano, le minacce evolvono. Il sistema allineato sei mesi fa potrebbe non esserlo più oggi senza che cambino i pesi. Le tecniche correnti (continuous evaluation, golden set refresh, system prompt versioning) sono una forma primitiva di rinegoziazione del contratto. La teoria del PA con rinegoziazione esiste in economia (renegotiation-proof contracts) ma è poco trasportata in AI. Filiazione potenziale, non equivalenza realizzata.
Collegamenti
Sezione intitolata “Collegamenti”- giochi-definizione: il PA è un gioco; senza la definizione tecnica di gioco non si parla di PA in modo non vago.
- somma-zero-non-zero: il PA è sempre non-zero-sum; entrambi possono guadagnare dal contratto, e la frizione è proprio quanto del surplus va a chi.
- equilibrio-nash: la soluzione del PA è un equilibrio Stackelberg, una specializzazione di Nash con struttura sequenziale di mossa.
- giochi-cooperativi: cooperative inverse RL (Hadfield-Menell 2016) tratta il PA come cooperative game con asimmetria; il valore Shapley appare in alcune formalizzazioni di reward attribution.
- dilemma-prigioniero: caso semplice di interessi divergenti; nel PA il dilemma si supera col contratto, ma solo se il principale può commit-tare.
- meccanismi-aste: mechanism design come PA con molti agenti; il PA singolo è il caso più semplice del mechanism design.
- markov-decision-process: l’agente RL è formalizzato come MDP; il principale che sceglie reward è “fuori” dell’MDP e specifica l’utility.
- policy-gradient: la policy
π_θottimizzata in RLHF è policy gradient con un reward derivato dal modello di preferenze. - ppo-trpo: PPO è l’algoritmo standard di RLHF; il KL constraint che ne è parte è leggibile come commitment device del contratto.
- giochi-stocastici: generalizzazione multi-agente di MDP; PA chain in agent system è un gioco stocastico annidato.
- rlhf-ppo (in preparazione): tecnica concreta di alignment più diffusa; questo capitolo ne dà la lettura economica.
- dpo-family (in preparazione): variante di RLHF senza reward model esplicito; PA dove il contratto è espresso direttamente sulle azioni.
- rlaif-constitutional (in preparazione): RLAIF e Constitutional AI come scalable oversight via delega del principale.
Il PA assume utility scalare. Tutta la macchina funziona se il principale ha una utility espressa da un numero. Per AI alignment l’obiettivo vero è multi-dimensionale e in parte non commensurabile: helpful, harmless, honest, plus dimensioni soggettive. Ridurre tutto a una scalare via reward model è una semplificazione potente ma lossy. Le reazioni recenti (multi-objective RLHF, separazione di harmful e helpful in reward distinti, costituzioni con clausole multiple) sono tentativi di evitare il collasso scalare. Il PA classico non offre molto qui: la sua macchina è scalare per costruzione.
Identificabilità dei meccanismi di mitigazione. Quando vedi un modello che si comporta bene, non sai se è perché è “intrinsecamente allineato” o perché sta gaming la valutazione. Lo stesso comportamento osservabile può venire da due strategie interne diverse. È il problema di identificabilità del PA: dato il comportamento ottimo, non puoi distinguere fra “agente fedele” e “agente sofisticato che imita la fedeltà”. Le tecniche emergenti (mechanistic interpretability, activation probing) sono tentativi di osservare l’azione interna oltre l’output; in linguaggio PA, sono sforzi per ridurre l’asimmetria informativa upstream.
PA assume un agente, l’AI agent ha sub-agenti. Un agent harness moderno orchestra subagent, ciascuno con il proprio loop e la propria memoria. La situazione non è “principale e agente” ma “principale e organizzazione”. Esiste una letteratura economica su PA in organizzazioni (gerarchie ottimali, span of control, Aghion-Tirole 1997 sull’allocazione dell’autorità formale e reale) che è poco esplorata in AI agent design. Filiazione potenziale, ancora non realizzata. Quando progetti un orchestrator con N subagent stai facendo organizational design, e la cassetta degli attrezzi delle scienze organizzative è probabilmente più vicina della pure contract theory.
Multi-principal con preferenze conflittuali. Un caso reale: un assistant AI in azienda ha come principali l’utente diretto, il manager dell’utente, l’ufficio compliance, il regolatore, il fornitore del modello. Le loro preferenze possono confliggere. Il PA classico è single-principal e non offre molto. Esistono varianti (common agency di Bernheim-Whinston 1986) che modellano agenti che servono più principali, ma sono complicate e poco trasportate in AI. Pratica corrente: gerarchia esplicita di sorgenti di policy (constitution > company policy > user prompt), risoluzione di conflitto come system design problem. Filiazione potenziale dalla common agency, ancora poco esplorata.
Information design come pre-contratto. Bayesian persuasion (Kamenica-Gentzkow 2011) studia come un principale possa progettare quale informazione rivelare all’agente per guidarne il comportamento. In AI è la cosa che fai con system prompt e context loading: scegli quali informazioni mettere nel context per indurre il comportamento desiderato. Lettura PA: information design è un grado di libertà aggiuntivo prima del contratto vero e proprio. La cassetta degli attrezzi della Bayesian persuasion è poco trasportata in AI alignment ed è probabilmente una direzione fertile.
Per andare oltre
Sezione intitolata “Per andare oltre”- Russell, Stuart (2019), Human Compatible: AI and the Problem of Control (Viking). Riformulazione divulgativa di AI safety come problema di delega sotto incertezza sulle preferenze umane.
- Hadfield-Menell, Dylan & Hadfield, Gillian K. (2018), “Incomplete Contracting and AI Alignment” (AIES 2018). Connessione esplicita fra contract theory e alignment.
- Holmström, Bengt (1979), “Moral Hazard and Observability” (Bell Journal of Economics). Paper originale, informativeness principle. Lettura impegnativa ma il teorema centrale è enunciabile in poche pagine.
- Skalse, Joar et al. (2022), “Defining and Characterizing Reward Hacking” (NeurIPS 2022). Formalizzazione di reward hacking come hackable proxy.
- Laffont, Jean-Jacques & Martimort, David (2002), The Theory of Incentives: The Principal-Agent Model (Princeton UP). Textbook standard per il framework formale completo, se vuoi scendere nei dettagli matematici.
- Krakovna, Victoria (2020+), “Specification gaming examples in AI”. Lista pubblica curata, link sul blog DeepMind Safety Research. Materiale didattico privilegiato: centinaia di casi reali di reward hacking, utili per intuizione sul “Dove si rompe”.
- Christiano, Paul (2018), “Supervising strong learners by amplifying weak experts” (arXiv:1810.08575). IDA come architettura per scalable oversight, risposta al PA con asymmetric capability.