Vai al contenuto principale
Copertina articolo: RAG e growth engineering: Come dare fonti affidabili agli agenti AI
Articoli/AI Agents

RAG e growth engineering: Come dare fonti affidabili agli agenti AI

/

Hai messo in piedi un agente che risponde ai clienti pescando dalla knowledge base aziendale. All’inizio sembra perfetto. Poi un cliente chiede dei resi e l’agente cita una policy vecchia. Non si è inventato nulla: ha recuperato la fonte sbagliata.

È il paradosso del Retrieval-Augmented Generation (RAG). Riduce le allucinazioni, ma non risolve il problema della qualità delle fonti.

Il retrieval è una decisione

Quando un agente recupera una fonte sta già decidendo. Decide quali documenti contano e quali no, se una policy aggiornata vince su un vecchio manuale, se una FAQ breve serve più di una procedura di dieci pagine.

Se non misuri questo passaggio, finisci per misurare solo l’output. E a quel punto è tardi.

Tieni traccia almeno di questi elementi:

  • query dell’agente;
  • documenti candidati;
  • documento scelto;
  • versione della fonte;
  • confidenza del recupero;
  • risposta finale;
  • feedback umano o utente.

Con questa telemetria capisci se il problema sta nel modello, nei documenti o nel modo in cui è costruito l’indice.

La knowledge base non è neutra

Un agente RAG riflette l’ordine del tuo archivio. Se la documentazione è duplicata, datata o scritta male, l’agente amplifica quel disordine invece di nasconderlo.

Prima di chiedere all’AI di “rispondere meglio”, conviene fare pulizia:

  1. elimina i documenti superati;
  2. assegna un proprietario a ogni fonte;
  3. aggiungi date e versioni;
  4. separa le policy ufficiali dalle note interne;
  5. raccogli esempi di domande reali.

Il RAG non è solo tecnologia semantica. È governance della conoscenza.

Misura l’utilità, non solo la correttezza

Una risposta può essere corretta e comunque servire a poco. L’agente cita la policy giusta ma non dice qual è il passo successivo. Oppure usa una fonte valida che però è troppo tecnica per un cliente.

Per questo servono metriche diverse:

  • accuratezza della fonte;
  • completezza della risposta;
  • tempo risparmiato;
  • tasso di escalation;
  • riapertura del ticket;
  • soddisfazione del cliente o del team.

Il growth engineering porta qui una disciplina preziosa: ogni miglioramento deve agganciarsi a un comportamento osservabile.

Come applicarlo senza complicare il lavoro

Non partire dallo strumento più nuovo. Parti dal punto in cui il team perde tempo, discute senza dati o decide con informazioni incomplete. Lì si vede subito se il tema ha valore operativo oppure è solo una bella idea da slide.

La regola, in fondo, è semplice. Un agente non va trattato come una chat brillante. Ha bisogno di input chiari, strumenti limitati, una memoria controllata e una regola esplicita che gli dica quando passare la decisione a una persona perché il rischio sale.

In pratica conviene procedere così:

  1. definisci quali dati l’agente può leggere e quali non deve toccare;
  2. scrivi il risultato atteso in forma verificabile, non come intenzione generica;
  3. decidi quando serve una revisione umana prima di inviare o salvare l’output;
  4. misura tempo risparmiato, errori evitati e casi in cui l’agente si ferma.

Cosa misurare per capire se funziona

La domanda giusta non è “abbiamo usato AI?” né “abbiamo aggiunto una dashboard?”. È un’altra: quale decisione è diventata più veloce, più chiara o più sicura? Se nessuna decisione cambia, il progetto rischia di restare decorazione tecnica.

Misura su almeno tre piani: tempo operativo risparmiato, qualità del risultato e fiducia del team nel processo. Il solo tempo inganna, perché un flusso più rapido ma meno controllabile non è un progresso. Anche la sola qualità inganna: un sistema perfetto ma troppo lento non entra davvero nel lavoro di tutti i giorni.

Il punto umano

Un agente che cita fonti affidabili non è solo più preciso. È più rispettoso. Non chiede all’utente di fidarsi di una voce sintetica, gli mostra che dietro la risposta c’è una base verificabile.

Quindi la vera domanda non è “il nostro agente usa RAG?”. È: quando recupera una fonte, possiamo fidarci del perché l’ha scelta?

Collegamento con il percorso ginnytech

Se vuoi trasformare questo ragionamento in competenza pratica, collega questo articolo al percorso Agentic AI Data Workflows. L’obiettivo non è imparare termini nuovi, ma costruire un modo di lavorare in cui dati, modelli e persone collaborano senza perdere controllo.

Articoli correlati

Agenti AI come workflow, non come chat: La lezione per il growth
14 giugno 20261 min di lettura
Leggi
AI e sperimentazione: Cosa cambia quando la variante non e deterministica
14 giugno 20261 min di lettura
Leggi
Human-in-the-loop: Quando il growth AI deve chiedere permesso
14 giugno 20261 min di lettura
Leggi