Introduzione
Le recenti evoluzioni dell’intelligenza artificiale generativa (GenAI) hanno trasformato la progettazione dei sistemi software, introducendo i modelli di base come sottosistemi pre‑addestrati capaci di rimodellare architetture e operazioni. Il nuovo ostacolo non è più la messa a punto (fine‑tuning) del modello, ma la ingegneria del contesto: come i sistemi acquisiscono, strutturano e governano conoscenza esterna, memoria, strumenti e input umano per garantire un ragionamento affidabile.
Pratiche consolidate come il prompt engineering, il retrieval‑augmented generation (RAG) e l’integrazione di tool rimangono isolate e producono artefatti transitori, difficili da tracciare, controllare o mantenere. Il presente lavoro propone una astrazione a livello di file system, ispirata al principio Unix “tutto è un file”, per trasformare queste pratiche in una disciplina architetturale verificabile e sostenibile.
L’ingegneria del contesto come sfida architetturale
Il rapido tasso di adozione della GenAI ha generato un cambiamento fondamentale nel modo in cui i sistemi software integrano conoscenza ed esperienze esterne. Approcci come il Retrieval‑Augmented Generation e l’integrazione di strumenti hanno dimostrato potenziale, ma operano spesso in isolamento, creando artefatti frammentati difficili da governare, tracciare o mantenere nel tempo.
Questa situazione è aggravata da tre limitazioni intrinseche dei grandi modelli linguistici (LLM):
- C1: finestre di token limitate, che richiedono una selezione accurata del contesto.
- C2: statelessness, ovvero l’assenza di memoria persistente interna al modello.
- C3: output non deterministici, che rendono necessaria una verifica post‑hoc.
Per superare questi vincoli è indispensabile un meccanismo di gestione del contesto capace di selezionare, persistere e verificare le informazioni in maniera sistematica.
L’astrazione del file system per la gestione del contesto
Il nucleo innovativo del lavoro consiste nell’applicare la filosofia Unix “everything is a file” all’ingegneria del contesto. Ogni sorgente di contesto – memoria dell’agente, basi di conoscenza esterne, strumenti computazionali e input umano – è rappresentata come un file all’interno di uno spazio dei nomi gerarchico e unificato.
Il Virtual File System (VFS) fornisce quattro capacità chiave:
- Interfaccia uniforme: tutti i contesti sono accessibili mediante operazioni standard di file (read, write, search, execute), indipendentemente dal meccanismo di memorizzazione sottostante.
- Organizzazione gerarchica: la struttura a directory riflette relazioni logiche e schemi di proprietà.
- Metadati e governance: ogni file contiene timestamp, permessi di accesso, informazioni di provenienza e versioning.
- Componibilità: gli elementi di contesto possono essere combinati ed estesi tramite uno schema interoperabile.
Questa astrazione consente di montare backend eterogenei – da database vettoriali a API esterne – come moduli di file system senza modificarne i formati originari. Ad esempio, l’API di GitHub può essere montata come /context/tool/github/, permettendo all’agente di interagire con i repository mediante semplici operazioni di file.
Progettazione del repository persistente di contesto
Per contrastare la statelessness dei LLM, l’architettura introduce un repository persistente a tre livelli, costruito sopra l’astrazione del file system:
Livello History
Rappresenta una fonte immutabile di verità, registrando tutti gli scambi grezzi, i passaggi di ragionamento e le transizioni di stato con metadati completi di provenienza. Questo consente la ricostruzione di qualsiasi processo decisionale passato, garantendo auditabilità totale.
Livello Memory
Offre viste strutturate e indicizzate dei dati storici, ottimizzate per il recupero e il ragionamento. La memoria può assumere forme diverse:
- episodica (eventi specifici)
- fattuale (conoscenza dichiarativa)
- procedurale (come‑fare)
- profilo utente (preferenze individuali)
Le voci di memoria sono specifiche dell’agente, ma soggette a schemi di metadati condivisi e controlli di accesso.
Livello Scratchpad
Funziona come spazio di lavoro temporaneo per calcoli intermedi e bozze durante le sessioni attive di ragionamento. Sebbene effimero, ogni operazione è registrata per garantire trasparenza e facilitare il debugging.
Le transizioni tra questi livelli sono governate da politiche esplicite di sintesi, embedding, indicizzazione, archiviazione e ritenzione. Ogni cambiamento è registrato come evento verificabile a livello di file, mantenendo una tracciabilità completa.
Pipeline di ingegneria del contesto
Il framework operativo si articola in tre componenti interconnesse che gestiscono il contesto lungo tutto il suo ciclo di vita:
Context Constructor
Seleziona, prioritizza e comprime il contesto rilevante dal repository persistente, rispettando il vincolo della finestra di token (C1) e le politiche di governance (privacy, access control). Genera un “manifesto di contesto” che documenta esattamente quali informazioni sono state incluse e per quale motivo, assicurando trasparenza nel processo di ragionamento.
Context Updater
Gestisce il trasferimento dinamico e lo streaming del contesto costruito nella finestra di token attiva del LLM. Supporta sia snapshot statici sia aggiornamenti incrementali, mantenendo coerenza e consistenza man mano che nuove informazioni diventano disponibili. Tutte le operazioni di aggiornamento sono loggate con timestamp e dati di provenienza.
Context Evaluator
Chiude il ciclo verificando le uscite del modello rispetto al contesto di origine, individuando incongruenze e reintegrando le informazioni validate nel repository persistente. In caso di output a bassa confidenza, incorpora una revisione umana, archiviando annotazioni e correzioni come elementi di contesto di prima classe. Questo garantisce miglioramento continuo e supervisione umana costante.
La pipeline affronta