2026-08-01T08:39:05.962Z
Agente Lightning: cancelli ogni aggiornamento RL prima che raggiunga un agente
Trasforma i lanci di Agent Lightning, i tempi, le ricompense, i risultati canarici, l'approvazione e il ritorno in un cancello supportato dalle prove per ogni risorsa addestrata.
Il documento Agent Lightning: Train ANY AI Agents with Reinforcement Learning risponde a un'importante domanda di ingegneria: come può un agente esistente generare dati di formazione senza essere ricostruito intorno a un loop RL? Essa non risponde alla domanda di rilascio che segue: quando dovrebbe essere consentito a una risorsa di nuova formazione di influenzare un flusso di lavoro reale? Il default sicuro è quello di mantenere ogni nuovo modello o risorsa come candidato. Promuoverlo solo dopo aver aggiunto l'aggiornamento al suo genitore esatto, istantaneo dei dati, valutatore, tentativi di lancio, copertura delle tracce, casi protetti, risultati limitati dei canari, approvazione e rollback testati. Una ricompensa superiore è una prova utile, ma non è un verdetto sanitario. Quel confine si adatta al quadro piuttosto che combatterlo. L'agente Lightning separa già l'esecuzione dell'agente dall'algoritmo di apprendimento. Conserva quella separazione come un cancello di rilascio. Cosa registra l'agente Lightning e cosa provano quei registri La carta presenta l'agente Lightning come un modo per dissociare l'esecuzione dell'agente dall'addestramento RL. Modella l'esecuzione degli agenti come processo decisionale di Markov, converte le traiettorie degli agenti in transizioni di formazione attraverso un modulo di assegnazione di credito e riferisce esperimenti su testo a SQL, generazione aumentata di recupero e utilizzo di strumenti matematici. L'attuale documentazione del progetto dà agli operatori nomi più concreti: un Resource è un asset che l'algoritmo può aggiornare, ad esempio un modello o un modello di prompt; un Rollout è un'unità di lavoro effettuata su una risorsa; un Attempt è una esecuzione di tale implementazione, comprese le riprovazioni; un Span registra un evento o una traccia dall'esecuzione; un Reward è un giudizio numerico allegato a un determinato periodo di implementazione; il LightningStore collega il Runner, che esegue l'agente, all'Algorithm, che consuma prove e aggiorna le risorse. Questa è una forte interfaccia di allenamento. Non e' una ricevuta completa di rilascio. Considerate un lancio che alla fine ebbe successo e che richiedeva quattro tentativi. La sua ricompensa finale può sembrare bella mentre i retest rivelano non determinismo, debito di costo o dipendenza che fallisce intermitentemente. Un secondo lancio potrebbe avere una ricompensa elevata mentre manca il 31% delle sue spesa attese. Un terzo può migliorare il punteggio medio di valutazione, rompendo l'unico caso protetto che impedisce una chiamata di strumento distruttivo. Sono diversi i fallimenti: Registrazione Una domanda utile che risponde La domanda non risponde da sola Rollout Quale compito fu tentato? Il risultato esterno previsto esisteva? Provare Quante esecuzioni furono eseguite, e come finirono? L'ultimo successo era stabile o solo fortuna? Spazzatura Quali eventi strumentali furono osservati? Gli effetti non strumentali importanti erano corretti? La ricompensa Come ha fatto un giudice di nome a valutare un certo comportamento? Il comportamento protetto, la privacy e il retrocesso rimasero intatti? Aggiornamento delle risorse Quale modello o suggerimento divenne disponibile? Questa risorsa dovrebbe diventare la risorsa predefinita? La distinzione è importante perché l'architettura ufficiale consente all'algoritmo di imparare da spazi e aggiornare le risorse senza che il Runner diventi un'autorità di distribuzione. Questa è una caratteristica. Non cancellarlo trattando ultima risorsa come risorsa approvata. Metti una ricevuta intorno all' aggiornamento della formazione Utilizzare un unico ricevimento di aggiornamento immutabile, assemblato in tre fasi. La ricevuta può vivere fuori dall'agente Lightning finché conserva identificatori stabili che si uniscono ai registri LightningStore. Prima della formazione: congelare l'identità e l'autorità Registrare l'ID della risorsa candidata, l'ID della risorsa madre esatta, l'istantanea dei dati di formazione, l'istantanea dei dati trattenuti, la versione dell'evaluatore, la configurazione dell'algoritmo, la revisione del codice e la portata prevista. Indicare quale attore può approvare un canario e quale attore può rendere la risorsa di default. Il genitore deve decidere di trovare un artefatto che si possa ancora caricare. Se l'ultimo aggiornamento non è un obiettivo di rollout quando l'apprendimento continuo ha prodotto tre nuove risorse da quando l'istruzione è stata scritta. Mantenere l'evaluatore, i casi protetti, la politica di promozione e la cronologia del rollback al di fuori della superficie scrivibile dell'allievo. Altrimenti un ottimista può migliorare il suo punteggio apparente cambiando la regola piuttosto che il comportamento. Durante la formazione: conto dei tentativi e copertura delle prove Per ogni implementazione nelle finestre di formazione e di convalidazione ammesse, tenere: Le esatte famiglie di spazi dipendono dal flusso di lavoro. L'invariante è più importante dei nomi: dichiarare quali prove dovrebbero esistere prima di esaminare il risultato, quindi segnalare le prove mancanti come non disponibili. Non trasformare l'assenza in un valore sano. I tentativi meritano la loro risposta. Un lancio con un tentativo finito e quattordici fallimenti silenziosi non equivale a un lancio finito una volta. Decidere un bilancio di riprova prima della formazione, distinguere i campionamenti previsti da quelli di infrastruttura e mantenere il motivo di ogni tentativo. Dopo la formazione: il successo dell'apprendimento separato dall'ammissione operativa Prima confronta il candidato e il genitore su un deposito bloccato. Relazione del risultato complessivo, ma anche fissazione di un bilancio di tolleranza zero o di limiti per le famiglie di casi protetti. Poi eseguire il candidato in un canario che non può superare un compito esplicito, tempo, strumento, costo, e il limite di effetti collaterali. La ricevuta canaria dovrebbe verificare la destinazione, non solo il comando. Se l'agente doveva creare un file, consultare il percorso previsto e convalidare il suo contenuto. Se doveva aggiornare un biglietto, leggi il biglietto. Se l'effetto non può essere verificato deterministicamente, registrare il giudice più debole o la prova umana e la sua incertezza. Infine, il test di ritorno. Caricare l'esatto genitore nello stesso ambiente di confine e dimostrare che il routing può tornare a esso. Solo un agente umano autorizzato o un agente di rilascio vincolato alle politiche dovrebbe approvare il passo successivo. Un esperimento con quattro candidati Ho codificato il gate come un deterministico Node.js. Ogni candidato migliora il punteggio. Essi differiscono solo per quanto riguarda le prove operative: Il dispositivo valuta sette controlli: 1. la risorsa, il parent, l'istantanea del set di dati e l'evaluatore sono fissati; 2. ciascun lancio finito ha una copertura completa della durata prevista; 3. il debito inaspettato di riprova è pari a zero; 4. il candidato batte il suo genitore esatto sul blocco bloccato; 5. nessun regresso di caso protetto; 6. ogni compito limitato canario ha un risultato verificato e nessun effetto nocivo registrato; 7. il rollback si risolve e viene testato, e un attore autorizzato approva la fase. La sua uscita è intenzionalmente inconveniente: Il più grande guadagno di ricompensa perde. Il candidato C migliora di 0,10 ma rompe tre casi protetti. Candidato B migliora di 0,08 ma ha solo 83 lanciamenti a intervallo completo su 120 e quattordici tentativi inaspettati. Il candidato D migliora di 0,07 ma verifica solo 18 dei 20 risultati canarici e non riesce a risolvere o testare il suo genitore. Il candidato A passa tutti e sette i controlli, ma il suo verdetto è deliberatamente PROMOTE TO BOUNDED CANARY , non safe o deploy ovunque. Passare le prove ha un ambito: questo genitore, questi snapshot, questo valutatore, questi casi protetti, questo canario e questa finestra di osservazione. L'artefatto eseguibile e la sua produzione leggibile dalla macchina rendono la tesi falsificabile. Cambia un campo, eseguilo e controlla il controllo fallito. La politica è rigorosa, ma le sue soglie possono essere modificate per un vero flusso di lavoro piuttosto che nascoste in prosa. L'apprendimento continuo ha bisogno di una regola di freschezza La documentazione dell'agente Lightning descrive anche una modalità di apprendimento online o continuo. I corridori possono segnalare i lanciamenti e gli intervalli opportunistici; l'algoritmo cerca nuove prove e può aggiornare le risorse quando arrivano dati sufficienti. Quel ciclo rende la freschezza parte della correttezza. Un pannello di controllo che dice candidato migliorato senza nominare il taglio dei dati, la versione dell'evaluatore, la finestra madre delle risorse e la finestra canaria sta presentando una conclusione che non può essere ricostruita. Utilizzare due suggerimenti: latest candidate resource può avanzare ogni volta che l'algoritmo crea un aggiornamento; approved default resource avanza solo dopo che un ricevimento completo di aggiornamento è passato. Non li chiamate mai alias. Un consumatore che richieda il default approvato non dovrebbe ricevere in silenzio il nuovo candidato. Definire anche una regola di prove obsolete. Se il valutatore, il contratto degli strumenti, la distribuzione dei compiti o il padre cambiano dopo che il gate è stato eseguito, annulla i controlli interessati. Un canario precedente non copre automaticamente una nuova autorizzazione, destinazione, modello di server o politica di riprova. Per l'addestramento di lunga durata, le condizioni di arresto appartengono oltre alle condizioni di ricompensa. Pausa quando la copertura della durata scende, riprova il debito oltrepassa il suo limite, il set protetto regredisce, il genitore diventa indisponibile o il canario non può verificare un effetto esterno. L'allenatore è ancora attivo descrive l'attività, non il progresso utile. Rispettare i confini indicati dal progetto Il progetto Documentazione responsabile AI, finanziato con impegno, descrive Agent Lightning come orientato alla ricerca, chiede ulteriori test prima di un utilizzo commerciale o reale e consiglia di evitare contesti decisionali ad alto rischio. Esso lascia anche l'accuratezza, la sicurezza, l'equità, la privacy, i diritti dei set di dati e la supervisione umana all'adolatore. Un gate di aggiornamento supporta tale responsabilità; non la discharge. Il dispositivo non può dimostrare la sicurezza a termine, rilevare ogni spostamento di distribuzione o rendere un piccolo canario in lingua inglese rappresentativo di un'altra lingua o dominio regolamentato. La sua promessa utile è più ristretta: gli aggiornamenti positivi per la ricompensa ma poco evidenziati rimangono in quarantena per una ragione verificabile. La regola di funzionamento risultante è semplice: lasciare che l'agente Lightning ottimizza i candidati, ma fare la promozione una decisione indipendente, supportata dalle prove, reversibile. Mantenere visibile il confine dell'algoritmo Runner, preservare il genitore esatto, dichiarare le prove attese prima dell'addestramento, verificare il vero risultato canario e richiedere autorità prima di modificare il default. Sidewisp è attualmente in anteprima privata. La sua direzione del prodotto è la salute degli agenti, la raggiungibilità, il progresso utile, l'accesso agli strumenti, i risultati, i costi, le prove e i confini di approvazione sicuri, ma il monitoraggio della produzione degli agenti Lightning non è presentato qui come un'integrazione spedita.