C'è una grande quantità di conoscenza specializzata che non è su internet. Non è in alcun libro o database. È distribuito attraverso il cervello umano, codificato in sistemi di esecuzione, e incorporato in processi che nessuno comprende pienamente.
Friedrich Hayek ha articolato questo nel 1945 meglio di chiunque altro da allora:
“C’è al di là della questione un corpo di conoscenza molto importante ma inorganizzata che non può possibilmente essere chiamato scientifico nel senso della conoscenza delle regole generali: la conoscenza delle particolari circostanze del tempo e del luogo.” [1]
Stava scrivendo sull'economia, ma l'osservazione è molto più generale. Gran parte del mondo corre sulla conoscenza locale, tacita, distribuita. Pensate al coordinatore della logistica che guadagna da vivere conoscendo temporaneamente la capacità di backhaul non legata a una corsia di camion. L'agente immobiliare che trova opportunità fugace prima di chiunque altro. L'arbitraggio che trae profitto dalle differenze di prezzo locali nessuno ha ancora notato. Ognuno possiede la conoscenza che, come ha detto Hayek, “per sua natura non può entrare in statistiche e quindi non può essere trasmesso a qualsiasi autorità centrale in forma statistica”.
Questo è il problema della conoscenza. Non manca di informazioni, ma un riconoscimento che le informazioni più importanti resiste alla centralizzazione.
Descrive anche, quasi perfettamente, quello che è successo all'interno dei più grandi sistemi software del mondo.
Le conoscenze bloccate nel codice in esecuzione
Mainframe sistemi COBOL processo trilioni di dollari in transazioni ogni giorno. Sono stati costruiti nel corso di decenni da migliaia di sviluppatori, ognuno rispondendo alle proprie particolari circostanze: un cambiamento normativo, un incidente di produzione il martedì sera, una denuncia del cliente circa un errore di arrotondamento nell'interesse trimestrale.
Nessuno ha progettato questi sistemi nel suo complesso. Sono cresciuti. Livello per livello, patch per patch, ogni sviluppatore ha contribuito la conoscenza locale a una base di codice condivisa. Le regole commerciali che disciplinano le approvazioni delle transazioni, i calcoli degli interessi, la gestione delle eccezioni e le transizioni dello stato del conto sono state raramente scritte in modo pulito. Sono stati incorporati in codice, layout di dati, convenzioni di chiamata, abitudini operative e correzioni di produzione. Come gli autori originali si ritirano, gran parte di questa conoscenza si ritira con loro.
Questo è il problema della conoscenza di Hayek, reso eseguibile.
La conoscenza è troppo distribuita in milioni di righe di codice, troppo implicite nelle interazioni del programma, e troppo dipendenti da dati e stato specifici per essere catturati in modo pulito da qualsiasi persona o documento. Nessuno lo capisce completamente. Il sistema lo fa. Eppure corre. Ogni giorno elabora le giuste transazioni, applica le regole giuste e produce i risultati giusti.
Perché l'approccio standard fallisce
L'approccio convenzionale alla modernizzazione mainframe è, in termini di Hayekian, una forma di pianificazione centrale. Noleggiare un grande team di consulenza. Leggi il codice. Documentare le regole aziendali. Riscrivere il sistema dalla documentazione.
Questo fallisce per lo stesso motivo che la pianificazione centrale fallisce. L'astrazione perde i dettagli che contano.
Un consulente leggeIF WS-FICO-SCORE < 300e scrive "I punteggi FICO inferiori a 300 sono respinti". Ma la vera conoscenza non è in quella frase. È nel comportamento del sistema in condizioni reali. Cosa succede quando quel assegno fallisce a metà della transazione? Cosa succede quando l'area di comunicazione contiene uno stato particolare? Cosa succede quando un cursore viene posizionato a un record specifico e un percorso di eccezione viene attivato due programmi dopo? Ecco dove vive la vera regola.
La conoscenza vive in parte in codice, ma più importante nel comportamento del sistema in esecuzione sotto costrizione.
Una risposta comune ma ingenua è: non si può solo puntare un LLM di frontiera al COBOL e chiedere che cosa fa? Un LLM di frontiera indicato in un file COBOL può spesso dirvi che cosa un paragrafo sembra fare in isolamento. Non può dire in modo affidabile cosa succede quando diciassette programmi interagiscono attraverso buffer di byte condivisi, aree di comunicazione interprogramma, confini delle transazioni e dati a forma di produzione. La lettura non basta. La conoscenza importante è espressa attraverso l'esecuzione.
Costruire l'ambiente, lasciare AI esplorare
Quindi l'alternativa è quella di replicare l'ambiente in cui tale conoscenza è espressa.
Piuttosto che chiedere agli esseri umani di leggere il codice e ricostruire le regole, si costruisce una replica fedele e strumentale del sistema legacy: uno che si comporta come l'originale ma corre in un ambiente in cui ogni ramo, ogni mutazione, ogni stato intermedio, e ogni interazione può essere osservata. Poi hai lasciato che l'IA operasse all'interno di quell'ambiente, formando ipotesi, facendo esperimenti, osservando i risultati e rivedendo la sua comprensione.
Questo è un orientamento fondamentalmente diverso. Smetti di trattare la comprensione come un compito di lettura. Invece, si costruisce un mondo in cui la comprensione può essere scoperto attraverso l'interazione.
In unsaggio precedente, ho sostenuto che Rich Sutton’s Bitter Lesson [6] si applica alla comprensione del codice. I metodi generali che sfruttano la computazione tendono a metodi esperformativi costruiti intorno a astratti artigianali. Summarization, RAG, progettato manualmente sulogie, grafici di conoscenza: questi sono tutti tentativi di comprimere la comprensione attraverso euristica che lavorano fino a un punto e poi rompere a sufficiente scala e complessità. Questa è la Lezione Bitter applicata alla modernizzazione.
Non costruire schemi di compressione mai-cleverer per la conoscenza tacita. Costruire l'ambiente in cui questa conoscenza è espressa e lasciare che l'esplorazione, utilizzando metodi generali come ricerca e apprendimento, faccia il lavoro.
In pratica, questo significa costruire un gemello comportamentale del sistema legacy e dare agenti AI gli strumenti per interagire con esso: navigare schermi, inviare ingressi, ispezionare i dati, osservare le tracce di esecuzione, confrontare i risultati e testare le congetture sulla logica aziendale contro il comportamento reale del sistema.
E' solo un test in abbigliamento fancier? Non proprio. Il test inizia con una specifica e verifica se il sistema lo soddisfa. Questo inizia senza una specifica e cerca di scoprirne uno. La direzione è invertita. È più vicino al metodo scientifico che al QA.
Perché costruire il gemello invece di leggere il codice?
A prima vista, costruire una replica fedele suona ancora più difficile che capire il codice direttamente. In un certo senso, lo è. Ma è un tipo diverso di duro.
Leggere un grande sistema ereditario e ricostruire il suo vero comportamento è un problema di giudizio. Dipende dall'interpretazione, dal contesto tatto e dallo sforzo umano eroico. Costruire un gemello fedele è un problema di ingegneria. L’obiettivo è di rendere fedeltà una proprietà del sistema che si costruisce, non un sottoprodotto dell’intuizione di qualcuno.
Ciò significa tradurre il sistema legacy in una rappresentazione il cui comportamento può essere controllato sistematicamente, quindi stringere l'equivalenza attraverso metodi formali e convalida differenziale continua. Eseguire gli stessi input attraverso il sistema originale e il gemello. Confronta le uscite, le tracce e gli effetti collaterali. Dove si divergono, chiudono il divario. Nel tempo, si trasforma la fedeltà in qualcosa di misurabile.
Ciò è importante perché una volta che l'infrastruttura esiste, ogni nuovo sistema diventa esplorabile per costruzione. Scambiamo un processo breve, manuale, irreducibilmente contestuale per uno basato in ingegneria ripetibile.
I laboratori AI già capiscono il modello
Una delle lezioni più chiare della moderna AI è che gli ambienti battono i dataset statici.
DeepMind non ha raggiunto superumano Vai costruendo un database gigante di commenti esperti. Hanno costruito un motore di gioco e lasciare che l'agente impara agendo dentro di esso. Quando AlphaGo Zero [2] rimosso i dati del gioco umano interamente e imparato attraverso il self-play, ha superato il sistema precedente. L'ambiente era il curriculum.
Lo stesso schema si presenta altrove. SWE-bench [4] valuta gli agenti di codifica all'interno di repository reali dove possono ispezionare il codice, fare modifiche e eseguire test. WebArena [5] valuta gli agenti web all'interno delle applicazioni web funzionanti piuttosto che i dataset statici delle tracce del browser. I grandi laboratori si sono spostati tutti verso sistemi di uso del computer dove il modello opera una vera interfaccia con screenshot, movimenti del mouse e azioni della tastiera. In ogni caso, la capacità viene non solo da più dati, ma da agire all'interno di un mondo strutturato che produce feedback.
Il modello è già visibile: se si vuole un sistema per padroneggiare un dominio, le descrizioni sono spesso un povero sostituto del dominio stesso.
Tale principio si applica tanto al software aziendale quanto a giochi, repository di codice o browser.
Se si desidera AI per capire un sistema bancario quarantenne, non solo consegnare i file sorgente e chiedere un riassunto. Dagli un ambiente in cui operare.
La fedeltà è tutto il gioco
Naturalmente, questo funziona solo se la replica è fedele. Se i due divergono dal sistema reale, la comprensione estratta sarà sbagliata.
Questo è il motivo per cui la verifica non è solo un bel-essere, ma l'intero gioco.
Il gemello deve essere convalidato continuamente contro il sistema originale attraverso l'esecuzione parallela. Gli stessi input dovrebbero produrre gli stessi output, le stesse transizioni di stato chiave, e lo stesso comportamento osservabile. Ogni discrepanza è utile. Essa rivela dove il modello del sistema è incompleto e dove l'ambiente deve diventare più preciso.
Fatto correttamente, l'ambiente diventa uno strumento progressivamente più tagliente per estrarre la comprensione.
Questo è ciò che stiamo costruendo a Hypercubic: non strumenti di documentazione, non piattaforme di analisi del codice statico, ma ambienti fedeli ed esplorabili in cui l'IA può scoprire la conoscenza che non è mai stata scritta.
Avremo molto di più da dire sulle specifiche presto.
Referenze
- Hayek, F.A. (1945).L'uso della conoscenza nella società. Rassegna economica americana, 35(4), 519-530.
- Silver, D. et al. (2017).Padroneggiare il gioco di Go senza conoscenza umana.Natura550, 354-359.
- Open Ended Learning Team, DeepMind. (2021).L'apprendimento aperto porta ad agenti generalmente responsabili.
- Jimenez, C.E. et al. (2023).SWE-bench: I modelli di lingua possono risolvere problemi reali GitHub mondo?
- Zhou, S. et al. (2023).WebArena: un ambiente web realistico per la costruzione di agenti autonomi.
- Sutton, R. (2019).La lezione di Bitter.