LRE è il motore universale con cui Metnos gestisce attività troppo lunghe o troppo ampie per restare legate a un singolo turno di chat. Il lavoro viene registrato come una o più unità verificabili e affidato a un servizio di esecuzione supervisionato. La chat restituisce subito una ricevuta; l'esecuzione continua in modo indipendente e può riprendere dopo un riavvio. L'utente descrive il risultato voluto: è Metnos a decidere automaticamente se usare LRE.
LRE è indipendente dal dominio: governa nello stesso modo l'elaborazione di immagini, la posta, le banche dati e altre attività. Per ogni lavoro riceve una descrizione strutturata di ciò che deve essere eseguito: le sorgenti da usare, le dipendenze fra i passaggi, i risultati attesi, le risorse disponibili, i limiti, i tempi e il comportamento previsto in caso di errore. Nei casi ordinari Metnos ricava questa descrizione dall'executor già scelto e dagli argomenti approvati per la richiesta. Per procedure composte e già collaudate può invece riutilizzare una struttura preparata in precedenza. È una scelta interna di esecuzione: l'utente non deve configurare profili né conoscere la forma del piano.
Un esempio è l'elaborazione di una raccolta di immagini, dalla quale Metnos ricava domande, soluzioni, appunti e un formulario. LRE coordina le diverse fasi del lavoro e ne conserva lo stato. L'esempio illustra il funzionamento del motore, ma non ne circoscrive l'ambito: qualunque executor ordinario compatibile può essere ammesso attraverso lo stesso meccanismo generale, senza codice costruito per uno specifico dominio.
Che cosa significa “universale”. Il motore è indipendente dal dominio e non usa un elenco di profili come filtro. “Universale” non significa però “privo di verifiche”: LRE prende in carico automaticamente ogni azione lunga che può rappresentare senza perdere argomenti, autorità, collocazione o garanzie di ripresa. Se non può farlo, l'azione non viene eseguita silenziosamente nel percorso interattivo: Metnos spiega il limite.
Metnos prepara anzitutto il piano ordinario del turno. Subito prima dell'esecuzione, un unico controllo centrale esamina il piano definitivo e il contratto firmato dell'executor. Nell'attuale percorso automatico un'azione è considerata intrinsecamente lunga quando il tempo massimo dichiarato è di almeno dieci minuti. La decisione dipende da questo metadato strutturato, non da parole come “lungo”, “in background” o “molti file”.
Un contratto firmato che dichiara un effetto interactive resta
nel turno, anche con un tempo massimo elevato: può richiedere l'intervento
dell'utente e non promette una ripresa autonoma. Per esempio, aumentare il
tempo concesso a una ricerca nel browser non la trasforma in un job LRE.
Un eventuale piano LRE esplicito mantiene tutti i controlli di ammissione.
| Condizione | Decisione di Metnos |
|---|---|
| Il piano non contiene azioni sopra la soglia. | Metnos usa il percorso interattivo ordinario. LRE non viene coinvolto. |
| Il piano contiene una sola azione lunga indipendente; l'executor è attivo, firmato e deterministico; argomenti, effetto e destinazione possono essere congelati. | Metnos crea il piano LRE durante il turno, accoda il lavoro e restituisce una ricevuta. Non serve alcun profilo. |
| Il lavoro ha un piano LRE già integrato, come l'indicizzazione delle foto. | Metnos usa quel piano riprendibile, con passaggi e modelli definiti prima dell'avvio. Anche in questo caso devono essere rispettati i controlli di accesso e i limiti delle risorse. |
| Prima dell'azione lunga è richiesta una conferma. | Metnos sospende l'esecuzione e richiede la conferma. Dopo l'approvazione ricontrolla il piano e, se ammissibile, lo affida una sola volta a LRE. |
| L'interruttore dell'istanza è disattivato. | Nessun nuovo lavoro entra in LRE. La chat ordinaria e la consultazione dei lavori esistenti continuano a funzionare. |
| Il lavoro non ha un piano LRE integrato e contiene più azioni dipendenti, riferimenti ancora da risolvere, un modello non completamente congelato o una destinazione remota ambigua. | Metnos dichiara che il lavoro lungo non è partito. Non esegue la parte lunga nel percorso interattivo e non promette una ripresa che non potrebbe garantire. |
| La configurazione non è valida o il servizio di esecuzione non è disponibile. | L'ammissione fallisce con una spiegazione precisa. Nessuna unità aggira il controllo. |
Un lavoro che ha concluso il controllo senza richiedere azioni mostra Esente direttamente nella sua riga, mantenendo le date e il dettaglio. L'indicazione richiede una conferma esplicita di tutte le fasi finali: zero errori o una lista vuota non bastano. Nell'indicizzazione delle foto, un archivio invariato soddisfa questa condizione; aggiunte, rimozioni e analisi forzate costituiscono modifiche.
La manutenzione notturna distingue la consegna di un lavoro a LRE dalla sua conclusione. Se ritrova un lavoro che richiede attenzione, ne conserva il riferimento e registra un esito parziale; non lo duplica e non lo presenta come riuscito.
Nel dettaglio del lavoro rimangono gli elementi con errore:
il totale (nitems) e il conteggio per codice, anche dopo un riavvio.
Si contano gli elementi segnalati dai risultati confermati, non i tentativi
ripetuti. Se le categorie sono molte, la console mostra le venti più frequenti,
ma il totale le comprende tutte. Gli errori tecnici dei tentativi restano
separati. Il riepilogo vale per ogni tipo di lavoro che dichiara questi esiti;
LRE non interpreta i file o i codici dei singoli domini. La traccia resta
disponibile finché viene conservato lo storico del lavoro.
La sezione richiudibile Tentativi con errore (storico)
conserva numero e codici degli errori registrati durante i tentativi, anche se
un tentativo successivo riesce. Conta tentativi, non foto o elementi: non si
somma a nitems e non indica necessariamente un problema ancora
presente. Un lavoro completamente riuscito può quindi avere una storia di
errori recuperati senza essere dichiarato fallito.
La ricerca nel contenuto delle fotografie usa un indice persistente: descrizioni delle immagini, caratteristiche visive e, quando disponibili, volti e posizione. Cercare un nome di file o elencare una cartella non richiede questa preparazione. La semplice presenza di foto in una cartella non significa che il loro contenuto sia già stato indicizzato.
Per cercare, indica l'archivio e descrivi il contenuto desiderato. Per esempio: «Nell'archivio delle vacanze cerca foto di montagne». Questa è una richiesta di ricerca: non occorre anteporre un comando per creare l'indice.
Sì: alla prima ricerca per contenuto, Metnos richiede automaticamente l'indicizzazione se l'archivio locale non ha un indice. Non occorre avviarla manualmente: la preparazione è affidata a LRE, il motore generale per i lavori lunghi. LRE deve essere attivo, l'archivio accessibile e i modelli configurati. La ricevuta arriva solo dopo l'ammissione: se un controllo fallisce, la preparazione non è iniziata. Una richiesta ripetuta riusa il lavoro attivo; un risultato vuoto non causa una ricostruzione. Il lavoro prosegue in background e, per archivi grandi, può richiedere ore. L'esito resta nella console LRE ed è notificato sui canali associati disponibili. La ricevuta non significa indice pronto: attendi il completamento, poi ripeti la ricerca. Le ricerche successive riusano l'indice e sono in genere più veloci.
Sono due operazioni separate. L'enrollment, cioè la registrazione di una persona, associa un nome a uno o più esempi del suo volto nel registro delle persone. L'indicizzazione analizza invece le foto dell'archivio e conserva le caratteristiche dei volti rilevati, senza richiedere che le persone siano già registrate. Quando cerchi una persona per nome, Metnos confronta il registro attuale con i volti presenti nell'indice.
Puoi quindi registrare una persona prima o dopo l'indicizzazione: aggiungere o migliorare il suo enrollment non richiede di ricostruire l'indice delle foto. Per esempio, dopo aver registrato Anna puoi chiedere «Cerca le foto di Anna nell'archivio delle vacanze» anche se l'archivio era già indicizzato. Vale per un indice valido che contiene le caratteristiche dei volti: l'enrollment non analizza nuove foto e non recupera volti che non erano stati rilevati. Le foto nuove o modificate richiedono l'aggiornamento dell'indice, gestito da LRE. Le immagini usate per registrare la persona non devono appartenere all'archivio da cercare.
LRE scopre i file in background, prepara le cartelle e analizza le foto in piccoli gruppi, in parallelo entro le risorse configurate. Solo unità completate e accettate e risultati verificati sopravvivono al riavvio senza ripetizioni. La scansione iniziale è un batch: definisce il totale dei gruppi e, se interrotta prima della conferma, ricomincia; le parti intermedie non sono un cursore di ripresa. Effetti o consumi incerti possono richiedere verifica prima di riprovare: il riavvio non risolve il problema. Il modello visivo locale parte quando serve e può spegnersi per inattività. Il nuovo indice appare solo alla pubblicazione della generazione completa; il precedente indice completo resta utilizzabile. Un errore di modello o file rimane visibile come problema, non come successo.
Una foto non decodificabile non è necessariamente danneggiata: il lettore
potrebbe non supportarne il formato o la variante. L'indicizzazione registra un
esito negativo per quella foto e continua sulle altre. La descrizione comincia
con IMAGE_NOT_INDEXED:image_decode_failed, oppure con
IMAGE_NOT_INDEXED:image_format_unreadable se il formato non viene
riconosciuto. Il prefisso è fisso, in inglese e fuori dal sistema di traduzione;
solo la spiegazione successiva è tradotta. Non vengono inventati contenuti o
vettori: la foto resta distinta da quelle indicizzate con successo.
A fine lavoro il totale delle sorgenti deve coincidere con foto indicizzate più foto non indicizzate. Se tutti i batch previsti sono conclusi, lo storico mostra lo stato principale Terminato. Il badge è arancione quando esistono esiti negativi, e il loro numero e le cause restano nelle informazioni di dettaglio. Gli errori diventano visibili alla conferma di ciascun batch, senza essere ricontati nelle fasi di unione e pubblicazione. Errori di modelli, autorità, contabilità o integrità delle sorgenti non diventano foto da saltare.
Coordinate GPS EXIF non leggibili, comprese frazioni con denominatore zero, vengono omesse: una fotografia decodificabile continua a essere analizzata e indicizzata. Se un executor gestito termina con un'eccezione applicativa, conserva i consumi delle chiamate al modello già registrate e segnala il fallimento. Le chiamate iniziate senza un resoconto restano consumi incerti; la correzione non ricostruisce automaticamente contatori persi in passato.
Un recupero amministrativo può ammettere una continuazione con riferimenti espliciti a risultati già confermati: proprietario, schema e impronta vengono verificati prima di leggerne le voci. Il vecchio lavoro e i suoi consumi non vengono riscritti. Quando manca un resoconto, la continuazione può riservare l'intero massimo del contratto locale a costo zero e sottrarlo, insieme ai consumi noti, dal budget precedente. Questa riserva non è un consumo misurato. Senza un limite verificabile o budget sufficiente il recupero si ferma. Per le foto, classificazioni già confermate e salvataggi intermedi compatibili permettono di continuare la stessa generazione senza ripetere le analisi riuscite. Non è una riprova automatica della revisione bloccata.
Per identificare le foto interessate usa nella ricerca dell'indice la parola
esatta IMAGE_NOT_INDEXED, oppure uno dei due prefissi completi.
Ottieni un elenco diagnostico con percorso e motivo, senza analisi semantica o
anteprime delle immagini; non viene avviata una nuova indicizzazione. Le ricerche
ordinarie escludono questi record. Un nuovo aggiornamento incrementale riprova
le foto non indicizzate e riusa i risultati validi compatibili: non viene creato
un ciclo automatico di ritentativi. Nella stessa generazione i salvataggi
intermedi verificati possono essere riutilizzati; un nuovo lavoro non garantisce
il riuso di checkpoint privati di una generazione fallita. Gli originali e lo
storico non vengono cancellati.
Un lavoro LRE pianificato che richiede attenzione resta disponibile per la diagnosi e il recupero manuale. Non blocca però tutte le scadenze successive: una nuova scadenza può creare un nuovo lavoro, mentre una consegna ripetuta della stessa scadenza non ne crea un duplicato. Se un altro lavoro equivalente è già in esecuzione o in coda, la nuova richiesta usa quello. Il nuovo lavoro non eredita automaticamente i salvataggi privati del precedente. Dopo errori ripetuti, il pianificatore allunga l'intervallo prima del tentativo seguente senza disabilitare definitivamente l'attività.
La pubblicazione verifica dimensioni e impronte dei cinque file dell'indice, anche quando riprende dopo un'interruzione: la sola presenza dei file non prova che la generazione sia integra. Gli indici precedenti restano leggibili; una generazione storica priva di queste prove non può certificare una nuova pubblicazione mediante il percorso di ripresa rapida.
Creare l'indice richiede di leggere e analizzare le fotografie. La durata dipende dal numero e dalla dimensione dei file, dalle analisi richieste, dalla velocità del disco, dai modelli e dalle risorse disponibili. Per archivi grandi può richiedere molto tempo, anche ore. Un'eventuale stima è indicativa, non una scadenza garantita; l'attesa non va presentata come assenza di risultati.
Quando un'elaborazione viene realmente accettata da LRE, la chat restituisce una ricevuta e il motore asincrono continua il lavoro separatamente: puoi usare Metnos per altro o chiudere la pagina. Stato ed esito restano nella console LRE; le notifiche di completamento, completamento con errori o fallimento vengono consegnate su Telegram se il proprietario ha un'associazione valida. Un lavoro non ammesso non è iniziato e non produrrà una notifica di fine indicizzazione. La ricevuta iniziale non equivale a indice pronto.
Dopo il completamento dell'indice, le ricerche successive sullo stesso archivio riutilizzano il lavoro già svolto: normalmente sono molto più veloci perché non devono rianalizzare tutte le foto. Non basta essere alla seconda richiesta se la preparazione è ancora in corso o è fallita. Foto nuove o modificate richiedono un aggiornamento dell'indice; un aggiornamento incrementale riusa le foto invariate, mentre una ricostruzione completa rifà l'analisi. Nessuna di queste operazioni rende istantanea ogni ricerca.
La ricerca in un indice esistente non avvia un aggiornamento a ogni richiesta. Puoi chiedere a Metnos di aggiornare l'indice dell'archivio; anche la manutenzione notturna programmata affida l'aggiornamento incrementale a LRE. Sia l'aggiornamento sia la ricostruzione completa possono essere lavori consistenti: usano quindi gli stessi passi riprendibili e limiti di risorse.
Un normale aggiornamento non richiede una ricostruzione completa né una simulazione. Per esempio, «Aggiorna l'indice delle foto in questa cartella» mantiene il comportamento incrementale. Se vuoi rianalizzare tutte le foto, chiedilo esplicitamente. La prima risposta in chat conferma la registrazione del lavoro in background, non che l'indice sia già stato aggiornato.
LRE non impone soglie arbitrarie al numero di elementi. Ogni revisione ha però limiti finiti e visibili, coerenti con le risorse approvate. I piani che espongono unità e riduzioni avanzano per lotti, senza accumulare un corpus in memoria. Un executor monolitico resta invece una sola unità: LRE può governarne il tentativo, ma non può creare punti di ripresa interni. Se un limite si esaurisce, il lavoro espone uno stato strutturato invece di fingere una copertura completa.
Ogni fase dichiara dove e come può essere eseguita. Un executor locale opera sul server; un executor remoto opera su un dispositivo associato. Entrambi possono essere deterministici oppure usare un modello linguistico o di visione. La collocazione non determina l'intelligenza: sono due proprietà indipendenti.
Il motore LRE esegue tutte queste classi attraverso interfacce comuni. Al momento, il percorso automatico diretto ammette però soltanto executor deterministici. Un executor che usa modelli può essere ammesso quando piano, prompt, modello, lingua, costo e numero di chiamate sono già congelati da un contratto completo, come avviene nei piani composti verificati. Questa distinzione evita di promettere una ripresa che cambierebbe modello a metà lavoro.
Le unità indipendenti possono procedere in parallelo, ma non dispongono di gruppi privati di processi. Tutta la concorrenza passa dal pianificatore centrale delle risorse, che applica limiti globali, per proprietario, per lavoro, per modello e per dispositivo. Il valore mostrato come “concorrenza massima” è un tetto, non la promessa di occupare sempre tutta la capacità disponibile.
| Situazione | Comportamento di LRE |
|---|---|
| Worker o computer riavviato | Lo stato resta nel deposito persistente; lease scadute e unità incompiute vengono riconciliate per lotti. |
| Tentativo recuperabile interrotto | Può essere eseguito nuovamente secondo una semantica at least once, con ritardo e numero di tentativi registrati. |
| Due tentativi terminano per la stessa unità | Il fencing e il commit condizionale ammettono un solo risultato per unità e revisione. |
| Stessa richiesta HTTP ripetuta con la medesima chiave di idempotenza | Restituisce lo stesso lavoro; non crea una seconda revisione o un secondo corpus. |
| Esito ambiguo di un effetto esterno | L'operazione non viene ripetuta automaticamente se non è idempotente o riconciliabile; richiede attenzione. |
Nel piano automatico diretto, una lettura pura può avere al massimo tre tentativi. Un'azione che modifica dati ha un solo tentativo automatico: se il servizio si interrompe dopo averla invocata ma prima di registrarne il risultato, LRE richiede attenzione invece di rischiare un secondo effetto.
LRE riprova automaticamente soltanto gli errori dichiarati recuperabili, entro i tentativi e gli effetti consentiti dal piano. Esaurire quei tentativi non rende permanente la causa: il lavoro passa a Richiede attenzione, con i batch in attesa e i risultati già salvati conservati. Un errore di causa ignota richiede subito una verifica, senza tentativi alla cieca. Dopo la verifica, Riprova autorizza un solo nuovo tentativo; non azzera il limite. Consumi sconosciuti, autorizzazioni mancanti o effetti ambigui possono ancora impedire la ripresa. Errori esplicitamente permanenti o contratti non validi non vengono trasformati in recuperabili. Lo storico distingue il codice generale e, quando disponibile, la causa approvata; i conteggi sono tentativi, non elementi.
Prima di eseguire un'operazione, un errore di lettura del catalogo viene confermato con una sola nuova lettura verificata. Se riesce, il lavoro prosegue; se fallisce ancora, chiede attenzione. I rifiuti espliciti di sicurezza restano immediati. Questa verifica non ripete l'operazione e non aumenta i limiti.
Garanzia corretta. LRE usa tentativi con semantica at least once e ammette un solo commit valido per unità. Può rendere un effetto osservabile una sola volta quando l'operazione è pura, idempotente o riconciliabile. Non promette un exactly once universale fra database, filesystem, fornitori e dispositivi remoti.
Piano, inventario e associazioni agli executor o ai modelli sono congelati nella revisione ammessa. Una modifica incompatibile crea una nuova revisione; non cambia in silenzio metà del lavoro già avviato. I risultati possono essere riusati soltanto quando i digest delle dipendenze coincidono. Se cambia una sorgente, si invalidano l'unità interessata e i suoi discendenti, non i fratelli indipendenti.
La pausa impedisce l'acquisizione di nuove unità, ma consente a un commit già in corso di concludersi in sicurezza. L'annullamento è cooperativo e impedisce l'avvio di altre unità. I comandi di pausa, ripresa, annullamento e decisione su un errore usano una versione attesa e una chiave di idempotenza, così anche il comando può essere ripetuto senza moltiplicarne gli effetti.
Una sola attivazione per istanza. L'interruttore in Servizi non abilita il singolo lavoro. Stabilisce se l'intera istanza di Metnos può accettare nuovi lavori LRE. Non è un'impostazione per utente e non deve essere azionato prima di ogni richiesta.
workload_id. Nella chat web, /admin/lre è un collegamento cliccabile alla console della stessa installazione, anche nelle ricevute salvate. Non devi conoscere né scegliere un profilo.Settings → Sistema → LRE per controllare stato, denominatore, budget, fasi ed eventi.Disattivare la funzione impedisce l'invio di nuovi lavori, ma non cancella cronologia e artefatti. La cancellazione dei dati segue invece il ciclo di vita del proprietario e le regole di conservazione. Scaricamento e consultazione restano circoscritti all'identità autorizzata.
I limiti seguenti distinguono ciò che LRE può garantire oggi da ciò che può essere aggiunto senza perdere tracciabilità o sicurezza.
| Limite attuale | Effetto pratico | Estensione corretta |
|---|---|---|
| Piani automatici composti | L'attuale percorso automatico accoda una sola azione lunga indipendente. Se il piano contiene più passaggi eseguibili o dipendenze ancora da risolvere, il lavoro non parte. | Compilare l'intero piano definitivo nel grafo tipizzato di LRE, con riferimenti e controlli espliciti; non conservarlo come batch opaco. |
| Executor intelligenti | Il percorso diretto esclude per ora gli executor che usano modelli linguistici o di visione senza un legame completo e immutabile. | Congelare prompt, lingua, modello, limiti di chiamata, token e costo nello stesso contratto; poi usare la medesima interfaccia generale. |
| Destinazione remota implicita | Un executor utilizzabile soltanto su un dispositivo non viene accodato finché il dispositivo esatto non è stato risolto. | Indicare il dispositivo nella richiesta oppure aggiungere una risoluzione deterministica e verificabile prima dell'ammissione. |
| Executor monolitico | LRE vede una sola unità e non può riprendere a metà di un ciclo interno non dichiarato. | Esporre l'attività come unità generali, identificabili e idempotenti, oppure come riduzione a lotti; non aggiungere casi speciali per dominio. |
| Effetti esterni non sempre ripetibili | Una scrittura su un servizio o dispositivo può avere un esito ignoto dopo un'interruzione. | Usare chiavi native di idempotenza o una lettura autorevole di riconciliazione; in assenza di entrambe, fermarsi e richiedere una decisione. |
| Risorse e costi finiti | Ogni revisione ha tetti di unità, tentativi, tempo, byte, token e concorrenza. Un budget esaurito arresta il lavoro in modo esplicito. | Regolare i limiti su misure reali e aggiungere capacità locale o remota attraverso lo scheduler centrale; non eliminare i limiti. |
| Piano congelato durante l'esecuzione | Un executor, un modello o una sorgente non vengono sostituiti silenziosamente a metà lavoro. | Creare una nuova revisione e riusare soltanto i risultati le cui dipendenze non sono cambiate. |
La console è il registro operativo dei lavori, non il comando che li avvia.
Si apre nella chat web da Settings → Sistema → LRE. Ogni lavoro
visibile al proprietario occupa una riga con titolo, data e ora di inizio,
data e ora di fine e stato. Il pulsante □ espande i dettagli subito sotto
la stessa riga; il pulsante − li richiude. Testata e dettagli hanno sfondi
distinti. Nei dettagli trovi revisione, avanzamento, limiti, fasi, eventi,
unità e artefatti. Solo una lettura riuscita con elenco vuoto indica
che non esistono lavori LRE per quell'identità. Un errore di lettura indica stato
non disponibile, non assenza di lavori; gli ultimi dati disponibili restano
visibili ma sono segnalati come non aggiornati. Se la pagina è indisponibile, controlla il servizio in
Settings → Sistema → Servizi. Non occorre lasciare aperta la
console perché il lavoro continui.
La tabella compatta separa Valore e Significato. Per esempio, 10 batch completati nella fase, 967 previsti nella stessa fase e 1.935 batch noti nell'intero lavoro sono tre misure diverse: 10/967 è circa l'1% della fase, non il 50% del tempo. Il totale noto può aumentare quando vengono preparate altre fasi. Un dato assente è n.a., non zero.
Settings → Sistema → LRE; la voce resta visibile nella colonna di navigazione dell'interfaccia web.Il corpus mostrato è sintetico e non sensibile; l'identificativo è operativo e non contiene dati personali.
Coordinamento delle risorse. La prenotazione congiunta delle risorse evita di trattenere CPU mentre si attende un modello o un’altra risorsa. Nei nuovi processi locali gestiti, i thread delle librerie numeriche sono limitati dalla capacità CPU effettiva, dalle quote assegnate e dal parallelismo interno. Sono limiti di concorrenza, non core riservati in esclusiva. Il ciclo di vita dei modelli è separato dalla pianificazione LRE: confine con Virt.