Una risposta documentata può essere fuori tempo
Un agente risponde a una domanda sul limite degli allegati di un servizio: “100 MB”. Ha trovato un documento autentico e pertinente, con una somiglianza molto alta rispetto alla domanda. Il documento, però, annuncia una regola che entrerà in vigore il mese prossimo. Oggi il limite è 80 MB. L’errore non nasce necessariamente da un’invenzione del modello: può nascere da una memoria che conserva il contenuto ma perde il suo tempo. Come progettare il recupero delle informazioni perché “parla dello stesso argomento” non venga confuso con “vale per questa domanda”?
Abstract. Costruiamo una memoria con due assi: quando un fatto è valido e quando il sistema ne possiede una determinata versione. Usiamo un limite di upload interamente sintetico, con una modifica appresa in ritardo e un annuncio futuro. Deriviamo il filtro temporale, lo eseguiamo in SQLite e distinguiamo risposte supportate, informazioni mancanti e conflitti. Non eseguiamo un modello linguistico né misuriamo la qualità di un motore di embedding: verifichiamo il livello deterministico che prepara le evidenze per un agente.
Due date rispondono a due domande diverse
Il tempo di validità risponde a “quando si applica questa regola?”. Il tempo di conoscenza risponde a “quando questa versione era presente nel sistema?”. Supponiamo che un limite passi da 50 a 80 MB il primo settembre, ma il connettore acquisisca l’aggiornamento il 3 settembre. Il 2 settembre il mondo e l’archivio sono disallineati. Se oggi ricostruiamo la regola valida il 2 settembre, la risposta è 80. Se ricostruiamo ciò che l’agente poteva leggere quel giorno, l’archivio mostrava ancora 50. Sono entrambe ricostruzioni utili, ma non intercambiabili.
Aggiungiamo un terzo evento: il 20 settembre viene acquisito l’annuncio di 100 MB dal primo ottobre. “L’ultimo documento acquisito” ora parla del futuro. Nemmeno scegliere sempre il timestamp più recente risolve la domanda corrente. Tutti i nomi, numeri e documenti dell’esempio sono inventati per il calcolo; non descrivono limiti o funzionalità EL-AI. MB indica qui un valore di policy, non una misura delle prestazioni di upload.
Conservare le versioni senza riscrivere il passato
Ogni riga conserva identificativo, valore, fonte, inizio e fine validità, inizio e fine conoscenza. Gli intervalli sono semiaperti: includono l’inizio ed escludono la fine. Così al primo settembre la versione vecchia termina esattamente quando inizia la nuova, senza sovrapposizione sul confine. Usiamo date alla mezzanotte UTC e granularità giornaliera; un sistema reale deve scegliere precisione e fuso prima del confronto. Il valore 9999-12-31 è soltanto un segnaposto per un termine non ancora noto, non una promessa che la regola resterà valida per millenni.
Quando il 3 settembre arriva la modifica, non cancelliamo la vecchia fotografia: chiudiamo il suo intervallo di conoscenza al 3 settembre. Aggiungiamo una fotografia corretta della vecchia regola, valida solo fino al primo settembre, e la nuova regola da 80 MB. Il 20 settembre chiudiamo analogamente la fotografia che considerava 80 MB senza fine nota, aggiungendo quella con fine al primo ottobre e la regola futura. Questo schema registra come cambia ciò che sappiamo: una correzione retroattiva non deve fingere di essere stata conosciuta prima dell’acquisizione.
Il filtro traduce la domanda in quattro confronti
Chiamiamo t la data cui si riferisce la domanda e k la data della conoscenza da usare. Una riga è ammissibile se t cade nel suo intervallo di validità e k nel suo intervallo di conoscenza. Per una risposta corrente, entrambi sono oggi; per un audit possono essere diversi. Separare i due parametri impedisce di usare inconsapevolmente un aggiornamento successivo per giudicare ciò che il sistema poteva sapere in passato.
La ricerca semantica può continuare a identificare l’argomento, ma la somiglianza non sostituisce questi vincoli. Nel nostro esempio assegniamo punteggi sintetici 0,97 al testo vecchio, 0,93 al corrente e 0,99 all’annuncio futuro. Ordinare solo per punteggio seleziona 100 MB; filtrare per il 29 settembre e poi ordinare seleziona 80 MB. Questi numeri non sono probabilità di verità e non provengono da un modello di embedding: isolano un errore di selezione indipendente dal particolare motore semantico.
| Data valida t | Conoscenza k | Valore MB | Interpretazione |
|---|---|---|---|
| 2026-09-29 | 2026-09-29 | 80 | current |
| 2026-08-20 | 2026-09-29 | 50 | historical |
| 2026-09-02 | 2026-09-29 | 80 | retrospective |
| 2026-09-02 | 2026-09-02 | 50 | known_then |
| 2026-10-02 | 2026-09-29 | 100 | announced_future |
| 2025-12-01 | 2026-09-29 | — | missing |
La riga “known_then” significa “l’archivio del 2 settembre riportava 50”, non “il limite reale era 50”. La riga futura significa “è annunciato 100 dal primo ottobre”, non “oggi si possono caricare 100 MB” né “l’annuncio si realizzerà certamente”. La riga senza dati non significa valore zero. Una risposta affidabile deve conservare queste qualificazioni nel linguaggio naturale, invece di consegnare al modello soltanto il numero nudo.
Un conflitto non si risolve facendo la media
Inseriamo una seconda fonte che dichiara 90 MB nello stesso periodo in cui la prima dichiara 80. Assumiamo uguale ambito e nessuna precedenza documentata fra le due. Il filtro temporale ammette entrambe. La procedura raccoglie i valori distinti: nessun valore significa informazione mancante, uno significa supporto coerente nel materiale disponibile, più di uno significa conflitto. Non facciamo la media 85 e non scegliamo 90 soltanto perché il documento è stato acquisito dopo. Una precedenza può essere legittima, ma deve derivare da una regola esplicita sull’autorità delle fonti o sulla sostituzione, non dal desiderio di rispondere comunque.
L’etichetta “supported” del programma non significa verità certificata. Significa soltanto che le righe disponibili, pertinenti e ammissibili concordano sul valore. Due copie dello stesso documento non sono due verifiche indipendenti; una fonte autorevole può essere sbagliata; una modifica può non essere ancora arrivata. Separare il controllo deterministico dalla fiducia nelle evidenze evita di attribuire al database capacità che non possiede. L’agente dovrebbe poter dire “le fonti disponibili riportano…” e mostrare fonte, versione e data di riferimento.
Dalla regola logica alla query eseguita
La query seleziona evidenze, non scrive la risposta. ORDER BY id rende l’output riproducibile e non stabilisce l’autorità delle fonti. I parametri vanno passati come valori legati alla query, non concatenati a testo SQL. Nell’esperimento usiamo SQLite in memoria, così ogni esecuzione parte dalle stesse cinque righe sintetiche; poi aggiungiamo separatamente il conflitto. Verifichiamo anche il confine: con conoscenza al 3 settembre, il 31 agosto restituisce 50 e il primo settembre 80. Questa prova controlla concretamente l’esclusione dell’estremo finale.
La scansione diretta costa O(n) confronti su n righe, prima dell’ordinamento. Per archivi grandi si possono indicizzare chiave dell’entità e intervalli, ma selettività e piano della query determinano il costo reale; qui non abbiamo misurato prestazioni. La chiave deve identificare anche prodotto, ambiente e ambito della regola: mescolare limiti di due servizi diversi crea un conflitto artificiale. Il nostro insieme contiene un solo servizio, proprio per isolare l’asse temporale. Aggiungere più documenti senza modellare l’ambito non risolve questa ambiguità.
La memoria dell’agente comprende anche copie e sintesi
Un aggiornamento può correggere il documento principale lasciando vecchi frammenti nel database vettoriale, una sintesi nella memoria dell’agente e una risposta in cache. Se la sintesi perde gli identificativi delle fonti, non sappiamo più quali oggetti invalidare. Serve conservare la derivazione: quale versione ha prodotto quale frammento o riassunto. L’origine va distinta dalla verità; documentare una catena di trasformazioni non garantisce che l’estrazione sia corretta, ma permette di riesaminarla quando cambia l’input.
Il PROV Primer del W3C descrive entità, revisioni, derivazioni e tempi di generazione; è un riferimento per rappresentare questa provenienza. La documentazione SQL Server mostra come interrogare lo stato storico del database con FOR SYSTEM_TIME AS OF. Nessuno dei due riferimenti sostituisce la definizione applicativa di quando una regola diventa efficace. Nel nostro prototipo i due intervalli sono espliciti e gestiti dal programma: SQLite non li mantiene automaticamente.
Anche la ricerca deve essere completa rispetto al problema. Se prendiamo soltanto il documento semanticamente più vicino e lo scartiamo perché futuro, potremmo rispondere “non so” pur avendo la regola corrente in archivio. Un filtro applicato prima della selezione finale, o una ricerca che allarghi i candidati quando necessario, evita questa specifica perdita. Non garantisce comunque che tutti i documenti utili siano stati acquisiti. Per una domanda corrente particolarmente sensibile al cambiamento, può servire consultare direttamente la fonte autorevole; il successo del recupero locale non dimostra freschezza globale.
La risposta conserva data, fonte e limite della conoscenza
L’agente dovrebbe ricevere un oggetto strutturato con valore o stato, fonti ammissibili, data di validità richiesta e fotografia della conoscenza. In caso di conflitto, deve esplicitare le alternative; in caso di assenza, può cercare altre evidenze o dichiarare il limite. Il testo generato resta da verificare: un filtro corretto non impedisce al modello di omettere “dal primo ottobre” durante la riscrittura. Un controllo finale può confrontare valore e qualificazioni temporali della risposta con l’oggetto deterministico. È un’estensione proposta, non implementata nell’esperimento.
La conclusione è semplice, ma cambia l’architettura: una memoria utile non conserva soltanto ciò che è stato detto; conserva a quale mondo temporale quella frase appartiene e quando il sistema l’ha appresa. La pertinenza sceglie l’argomento, la validità sceglie il periodo, la provenienza rende controllabile la ricostruzione. Nel nostro esperimento questi controlli distinguono 80 MB oggi, 50 nel passato e 100 soltanto nell’annuncio futuro, senza chiedere al modello linguistico di indovinare quale documento prevalga.
Fonti e riproducibilità
W3C — PROV Model Primer, Working Group Note, 30 April 2013, sections 2.6–2.9.
Microsoft — Query data in a system-versioned temporal table, AS OF and historical queries.
Il frammento seguente mostra una sola fotografia della conoscenza per rendere leggibile il filtro di validità. L’archivio contiene la versione completa a due assi, le cinque righe, le sei domande, il conflitto e i controlli sui confini, tutti eseguiti con Python e SQLite. Nessun dato è stato inviato a un modello esterno. I risultati descrivono questa fixture deterministica, non l’affidabilità generale di un agente o una funzionalità disponibile di EL-AI.
records = [
dict(value=50, start='2026-01-01', end='2026-09-01'),
dict(value=80, start='2026-09-01', end='2026-10-01'),
dict(value=100, start='2026-10-01', end='9999-12-31'),
]
for date in ('2026-08-20', '2026-09-29', '2026-10-02'):
values = {r['value'] for r in records if r['start'] <= date < r['end']}
status = 'missing' if not values else ('conflict' if len(values)>1 else 'supported')
print(date, status, sorted(values))
# One knowledge snapshot only. Full archive implements both temporal axes in SQLite.
Codice, dati e istruzioni · JSON. Calcoli didattici eseguiti con Python 3.14.0; figure con Matplotlib 3.11.2. Analisi con assistenza AI, senza dichiarare peer review o revisione umana. Copertina originale ImageGen, illustrativa: non documenta persone, sedi o installazioni EL-AI. Fonti consultate il 29 settembre 2026.