Vai al contenuto
BionicAdri

Come ADRI impara dal proprio lavoro e apre ticket in autonomia

ADRI migliora in due modi. Impara dal proprio lavoro, con una revisione ogni notte che verifica prima di dare qualcosa per buono, e un agente vigilante legge i registri ogni giorno e apre un ticket quando trova un guasto reale. Entrambi hanno freni, e la riparazione resta nelle mani di una persona.

Esquema del ciclo de mejora de ADRI: el trabajo diario alimenta una revisión nocturna que produce lecciones, y un agente vigilante lee los registros y abre tickets con evidencia citada

Un'IA che lavora tutti i giorni sbaglia tutti i giorni. La cosa utile è cosa succede dopo: se l'errore si ripete o se qualcuno lo rileva e lo corregge. In ADRI ci sono due meccanismi per questo, e funzionano senza che nessuno debba ricordarsene.

Ti raccontiamo come funzionano, cosa vedi tu come cliente e quali freni hanno.

I quattro modi in cui ADRI impara

ADRI non riaddestra nessun modello con i tuoi dati. Conserva, ordina e riutilizza ciò che accade nel suo lavoro quotidiano, in quattro modi diversi.

  • Quello che impara da te. Al termine di una conversazione, un modello piccolo e veloce ripassa lo scambio e aggiorna il tuo profilo: come preferisci che ti scriva, quale firma usi, quali correzioni gli hai fatto. Quel profilo serve per il tono e le preferenze. Non serve come fonte di dati: se ha bisogno di un'email o dello stato di un account, ADRI lo consulta nella piattaforma invece di tirarlo fuori dalla memoria.
  • La sua memoria delle conversazioni. Le tue chat precedenti e i file che ha generato per te vengono indicizzati ogni pochi minuti. Così capisce «quello che abbiamo visto della concorrenza» anche se quella chat diceva «studio dei rivali». Ogni utente cerca solo nel suo. Se la ricerca per significato fallisce, passa alla ricerca per parole invece di dare errore.
  • Lezioni tecniche. Quando uno strumento fallisce e ADRI trova come risolverlo, o quando si blocca in un ciclo, o quando tu lo correggi, può salvare una lezione breve del tipo «per questo caso, fai quest'altro». Più sotto spieghiamo perché una lezione nuova non vale nulla finché non viene dimostrata.
  • Esperienza per strumento. Il browser, per esempio, ricorda cosa funziona su ogni sito web e dimentica gli appunti vecchi.

La regola che tiene insieme tutto è semplice: immagazzinare molto, iniettare poco. La memoria salvata può crescere, ma in ogni conversazione arriva solo un piccolo frammento rilevante. Così non si aumenta il costo di ogni risposta. Lo spieghiamo più nel dettaglio in come funziona la ricerca semantica nella base di conoscenza.

La revisione di ogni notte

Imparare a caldo accumula duplicati e appunti che non sono più validi. Ogni notte viene eseguita una revisione che mette ordine:

  1. Pulisce i profili utente. Rimuove i duplicati, risolve le contraddizioni (vince il più recente) e pota.
  2. Rivede il ciclo di vita delle lezioni. Promuove quelle che hanno dimostrato di funzionare, ritira quelle che falliscono più di quanto riescano e fonde quelle che dicono la stessa cosa con altre parole.
  3. Ritira le lezioni che non hanno più senso. Se parla di uno strumento che il suo agente non ha più, il codice la ritira. È un controllo meccanico, non l'opinione di un modello, ed è reversibile.
  4. Fa una copia delle tabelle di apprendimento. Una copia locale giornaliera, oltre ai backup generali.
  5. Salva le metriche della notte. Così si vede la tendenza invece di fidarsi dell'intuizione.

C'è un ulteriore passo che oggi è in modalità test: un modello confronta ogni lezione con le istruzioni vigenti dell'agente e propone di ritirare quelle già coperte o quelle che le contraddicono. Per ora si limita a proporre e lo annota; non tocca nulla finché non lo revisioniamo. E anche se viene attivato, può ritirare una lezione solo se cita letteralmente la parte delle istruzioni che la copre, e mai più di un terzo delle lezioni di un agente in una notte.

Come evitiamo che l'apprendimento rovini qualcosa

Un sistema che impara può imparare solo bugie: se registra come successo qualcosa che è andato male, lo ripeterà con più fiducia. Per questo quasi tutto il lavoro sta nei freni:

  • Una lezione inizia come candidata. Passa a verificata solo dopo vari usi con successo e senza errori. Se fallisce più di quanto riesca, viene ritirata. Se smette di essere usata per settimane, anche. Se l'errore che correggeva ricompare, la lezione rivive.
  • Vale solo se viene usata davvero. Una lezione su uno strumento conta un successo solo se in quella attività è stato usato quello strumento. Un'attività annullata o interrotta a metà non conta né come successo né come fallimento.
  • Dati personali fuori. Le lezioni tecniche sono comuni a tutta l'installazione, quindi vengono ripulite dai dati personali due volte prima di essere salvate.
  • Le lezioni non toccano le istruzioni fisse. Vengono aggiunte come nota all'inizio della richiesta, al massimo le tre più simili al caso. Se qualcosa va storto, si spengono con un interruttore.
  • Il tuo profilo non può ridursi per errore. Se, aggiornandolo, il risultato risulta molto più corto dell'originale, la modifica viene scartata. Prima di riscriverlo si salva una copia.
  • I test non pagano l'apprendimento. Le nostre batterie di test hanno un lucchetto che impedisce che attivino chiamate di apprendimento reali e fatturabili.
  • Puoi cancellarlo. I ruoli con permesso possono cancellare di colpo la memoria di ADRI. Per impostazione predefinita ce l'hanno super-admin, admin e manager.

È la stessa filosofia che raccontiamo in gli harness che decidono quale modello lavora e chi revisiona: il modello propone; il codice verifica.

Il guardiano: un agente che legge i log

Il secondo meccanismo non impara: vigila. È un agente separato, il guardiano, che gira su ogni server una volta al giorno, a un'ora casuale della notte. Legge ciò che è stato scritto nei log di ADRI e della piattaforma dall'ultima volta, raggruppa gli errori per tipo e, se trova un incidente reale, apre un ticket nella nostra installazione centrale di supporto.

PassoCosa succede
1. LetturaLegge solo le novità di ogni registro, senza saltare sezioni.
2. EvidenzaPer aprire un ticket deve citare righe letterali del registro, e lo strumento verifica che esistano. Se la citazione non è nel file, il ticket viene rifiutato.
3. Senza duplicatiOgni incidente ha un'impronta. Se c'è già un ticket aperto con la stessa impronta, non se ne crea un altro.
4. Un guasto comune, un ticketSe la causa è in una risorsa condivisa da più server, si apre un solo ticket con varie conferme. Se è locale, come un disco pieno, se ne apre uno per server, perché sono problemi diversi.
5. ChiusuraOgni mattina si chiudono da soli i ticket del vigilante il cui errore non si presenta da diversi giorni. Se non può misurarlo bene, non chiude.

I passi 2 e 4 sono nati da errori reali. A luglio 2026 abbiamo esaminato i sei ticket che il vigilante aveva aperto in due giorni: tre citavano contatori e nomi che non esistevano in nessun registro. Il modello aveva inventato incidenti verosimili. Non gli chiediamo onestà: gli imponiamo di citare righe che lo strumento può cercare. Quello stesso mese, un singolo guasto in una risorsa condivisa ha aperto sette ticket identici, uno per server. Da allora conta come uno.

E se il vigilante smette di passare? C'è un secondo avviso: ogni mattina si controlla quando è stata la sua ultima revisione corretta. Se sono passate più di 30 ore, si apre un ticket che lo segnala. E se si blocca o ripete la stessa azione in loop, viene interrotto.

Cosa vedi tu come cliente

Nella vita quotidiana, nulla. I ticket del vigilante arrivano al nostro team di supporto, non alla tua casella. L'idea è che veniamo a conoscenza di un guasto tramite il registro, spesso prima che ti colpisca. Non sempre arriveremo prima: il vigilante controlla una volta al giorno e alcuni guasti si notano solo quando qualcuno usa la funzione.

Quello che invece noti è l'effetto dell'apprendimento: ADRI ti scrive con il tuo tono, ricorda ciò di cui avete già parlato e smette di ripetere alcuni intoppi tecnici. Se vuoi che i tuoi server aprano ticket con la stessa logica di impronte, la piattaforma ha un'API: la trovi in ticket e supporto con IA.

Quello che non fa ancora

  • Non si ripara da solo. Il vigilante funziona in modalità di sola lettura. Esiste una seconda fase pensata per chiudere i ticket dopo aver risolto il guasto, ma è disattivata e la riparazione automatica oggi non ha alcun percorso reale. Chi ripara è una persona.
  • Non è infallibile. Un ticket del vigilante è un'ipotesi con evidenza, non un fatto. Lo verifichiamo prima di agire.
  • Imparare non è capire. Una lezione verificata ha funzionato diverse volte; non garantisce il caso successivo.
  • Misura, e a volte anche la misurazione fallisce. A settembre abbiamo verificato il ciclo notturno stesso e abbiamo scoperto che considerava la notte riuscita anche se qualche passaggio falliva. Lo abbiamo corretto.

Se vuoi vedere l'elenco degli agenti e cosa fa ciascuno, è in cosa fa ADRI. Per provarlo, inizia da la chat con ADRI. E se ti interessa come trattiamo i dati che apprende, lo trovi in sicurezza e conformità.

  • ADRI
  • Autoapprendimento
  • Ticket automatici
  • Monitoraggio

Demo senza impegno

Guardalo con i dati della tua azienda

Ti mostriamo ADRI al lavoro su un tuo compito reale, in circa 15 minuti.

[email protected]+34 604 87 17 35