Introduzione
Le tecnologie di intelligenza artificiale generativa (GenAI) hanno trasformato il modo in cui le architetture software integrano conoscenza esterna e capacità di ragionamento. I modelli di base, pre‑addestrati su enormi quantità di dati, fungono da sottosistemi pronti all’uso, ma la sfida principale non è più il fine‑tuning dei modelli, bensì la ingegneria del contesto. Questa disciplina riguarda la capacità dei sistemi di catturare, strutturare e governare memoria, strumenti, conoscenza esterna e input umano in modo da garantire ragionamenti affidabili e responsabili.
Le pratiche attuali, come il prompt engineering, la Retrieval‑Augmented Generation (RAG) e l’integrazione di tool, rimangono frammentarie: producono artefatti transitori difficili da tracciare, verificare o rendere responsabili. Per superare questi limiti, questo lavoro propone un’astrazione di file system ispirata al principio Unix “everything is a file”, offrendo un’infrastruttura persistente e governata per la gestione del contesto.
Ingegneria del contesto come sfida architetturale
L’adozione rapida di GenAI ha introdotto una nuova modalità di interazione tra software e conoscenza. Approcci come RAG o l’integrazione di tool forniscono meccanismi per arricchire il modello con informazioni esterne, ma operano spesso in isolamento, creando artefatti sparsi e difficili da governare. Questo porta a problemi di tracciabilità, auditabilità e manutenibilità, soprattutto alla luce delle limitazioni dei modelli di linguaggio di grandi dimensioni (LLM): finestre di token limitate, statelessness intrinseca e output non deterministici.
Affinché le applicazioni basate su GenAI possano essere affidabili in contesti critici, è necessario un meccanismo strutturato per selezionare, persistere e verificare il contesto fornito al modello, garantendo al contempo rispetto di policy di privacy, controllo di accesso e responsabilità umana.
Astrazione del file system per la gestione del contesto
Il cuore dell’innovazione è l’applicazione della filosofia Unix “everything is a file” all’ingegneria del contesto. Ogni fonte di contesto – memoria dell’agente, basi di conoscenza esterne, tool computazionali e input umano – viene rappresentata come un file all’interno di uno spazio di nomi gerarchico unificato. Ogni file contiene metadati standardizzati, quali timestamp, permessi di accesso e informazioni di provenienza.
Le capacità chiave del Virtual File System (VFS) includono:
- Interfaccia uniforme: tutte le risorse di contesto sono accessibili mediante operazioni di file standard (read, write, search, execute), indipendentemente dal loro backend.
- Organizzazione gerarchica: il contesto è disposto in una struttura a directory che riflette relazioni logiche e proprietà di proprietà.
- Metadati e governance: ogni file incorpora dati di versione, controlli di accesso e audit trail, facilitando la gestione della responsabilità.
- Componibilità: i componenti di contesto possono essere combinati ed estesi tramite uno schema interoperabile, consentendo la creazione di nuovi artefatti senza rompere la coerenza.
Grazie a questa astrazione, è possibile “montare” back‑end eterogenei – ad esempio un database vettoriale o un’API esterna – come moduli di file system, senza modificare i formati originali. Un esempio pratico è il montaggio dell’API GitHub in /context/tool/github/, che consente all’agente di interagire con repository tramite semplici operazioni di file.
Progettazione del repository persistente
Per compensare la statelessness dei LLM, l’architettura introduce un repository di contesto persistente a tre livelli, costruito sopra l’astrazione del VFS:
- Livello History: log immutabile che registra tutte le interazioni grezze, i passi di ragionamento e le transizioni di stato, completo di metadati di provenienza. Questo livello consente la ricostruzione esatta di qualsiasi processo di ragionamento passato, supportando audit completi.
- Livello Memory: vista strutturata e indicizzata dei dati storici, ottimizzata per il recupero e il ragionamento. La memoria può essere di tipo episodico, fattuale, procedurale o profilo utente, ed è soggetta a schemi di metadati condivisi e controlli di accesso.
- Livello Scratchpad: spazio di lavoro temporaneo per calcoli intermedi e bozze durante sessioni attive di ragionamento. Sebbene effimero, ogni operazione è registrata per garantire trasparenza e facilitare il debug.
Le transizioni tra questi livelli sono governate da politiche esplicite di sintesi, embedding, indicizzazione, archiviazione e ritenzione. Ogni cambiamento di stato è registrato come evento a livello di file, mantenendo una tracciabilità completa.
Pipeline di ingegneria del contesto
Il flusso operativo è gestito da tre componenti strettamente integrati, progettati per operare entro i vincoli tipici di GenAI:
- Context Constructor: seleziona, prioritizza e comprime il contesto rilevante dal repository persistente. Tenendo conto della limitazione della finestra di token (C1), il costruttore crea un “manifesto di contesto” che documenta esattamente quali informazioni sono state incluse e il motivo della loro scelta, garantendo trasparenza.
- Context Updater: trasferisce e streamma il contesto costruito nella finestra di token attiva del modello. Gestisce snapshot statici e aggiornamenti incrementali, mantenendo coerenza e consistenza. Tutte le operazioni di aggiornamento sono loggate con timestamp e dati di provenienza.
- Context Evaluator: verifica l’output del modello rispetto al contesto di origine, rileva incoerenze e reintegra le informazioni validate nel repository persistente. Per output a bassa fiducia, il valutatore coinvolge un revisore umano, archiviando annotazioni e correzioni come primi elementi di contesto, assicurando un miglioramento continuo e la supervisione umana.