Agente Copilot Studio

Il primo agente in Copilot Studio funziona alla perfezione nel riquadro di test: risposte rapide, tono cortese, nessuna esitazione. Poi arrivano gli utenti reali, che scrivono come scrivono le persone, e la sicurezza svanisce. Il bot risponde in modo vago o, peggio, inventa.

In questa guida vediamo come riprodurre una risposta sbagliata nel riquadro di test, come correggerla in modo che l'agente citi il documento reale e come pubblicare un pilota che regga davvero. Il percorso ha quattro tappe: grounding, persona, debug e pubblicazione.

Perché un agente perfetto nel riquadro di test inciampa nel mondo reale

Nel riquadro di test gli input sono ordinati: domande brevi, formulate con chiarezza, spesso simili agli esempi che hai preparato. In produzione un dipendente scrive "quanto posso richiedere quando sono in hotel?", un collega digita "limite di spesa dell'hotel" con un errore di battitura, un altro chiede semplicemente come farsi rimborsare il viaggio. Il significato è lo stesso, ma se hai provato solo "qual è il limite di spesa?" il bot non sempre collega i puntini.

Il test delle tre varianti

Per vedere subito questa lacuna, apri il riquadro di test e invia tre versioni della stessa domanda:

1. la versione pulita;
2. una riscrittura informale;
3. una versione con un errore di battitura.

A volte il bot le riconosce tutte e tre, a volte funziona solo la prima. È il primo indizio che un bel risultato di test non equivale alla sopravvivenza nel mondo reale.

Copertura delle frasi trigger

Il motivo tecnico è la copertura. I bot si affidano a frasi trigger e definizioni degli argomenti per capire quando attivare una risposta. Se tutti gli esempi si assomigliano, il modello diventa fragile e un singolo sinonimo può metterlo in difficoltà.

La soluzione è noiosa ma efficace: aggiungi frasi trigger più ampie e non limitarti alla formulazione formale dei documenti sulle policy. Servono espressioni informali, abbreviate e anche un po' disordinate, quelle che le persone usano davvero. Non ne servono decine, bastano quelle che coprono le varianti più evidenti. Poi ripeti il test.

Le differenze tra i canali

Il riquadro di test di Copilot Studio è una simulazione. Dopo la pubblicazione su un canale come Teams, SharePoint o un sito web dimostrativo, la piattaforma può cambiare il modo in cui gestisce il testo in ingresso e le risposte. Teams può spezzare le righe in modo diverso, una pagina web può eliminare la formattazione, e anche spostare una frase chiave su un'altra riga può cambiare l'interpretazione del modello. Per questo Microsoft insiste sui test iterativi tra i canali.

Un esempio: in studio la domanda "qual è il limite di spesa?" riceve la risposta corretta, cioè 200 dollari a notte per l'alloggio. Con una riformulazione informale il bot risponde "verifica con le risorse umane" o fa un'ipotesi vaga. L'intento è identico, il risultato no. Considera il riquadro di test un allenamento: utile per imparare, ma non una prova di preparazione.

Grounding: smettere di far indovinare l'agente

Il primo errore da principiante è trattare Copilot Studio come una sfera di cristallo invece che come un regolamento. Un agente senza basi di conoscenza è come uno stagista mandato in riunione senza alcuna preparazione: parla in fretta, sembra sicuro e, appena qualcuno lo mette in dubbio, crolla.

Il rischio delle allucinazioni

Un bot privo di grounding non sa nulla: bluffa. Nel riquadro di test il bluff può sembrare convincente, ma in produzione gli utenti se ne accorgono subito. Il risultato peggiore sono le allucinazioni, cioè risposte che suonano giuste ma non hanno alcun fondamento. Se chiedi dei rimborsi di viaggio, invece di rifiutare con garbo il bot inventa una cifra plausibile. Un dipendente prenota l'hotel in base a quella cifra e ti ritrovi a gestire contestazioni sulle spese.

L'esercitazione ufficiale di Contoso Labs lo mostra bene. Si carica un file chiamato expensepolicy.docx, dove il limite per l'alloggio è di 200 dollari a notte. Senza grounding, alla domanda sulla policy per gli hotel il bot può rispondere con sicurezza "100 dollari a notte", un numero del tutto inventato. Con il file collegato smette di improvvisare e cita il documento: secondo la policy aziendale sui viaggi, l'alloggio è limitato a 200 dollari a notte.

Come aggiungere la conoscenza passo dopo passo

1. Apri il tuo agente in Copilot Studio.
2. Dalla schermata di panoramica scegli Knowledge.
3. Seleziona Aggiungi knowledge e poi il caricamento di un file.
4. Indica expensepolicy.docx o un'altra fonte affidabile.

Puoi anche collegare un sito web pubblico o una posizione SharePoint, ma i file sono più puliti. Dopo il caricamento serve pazienza: l'indicizzazione può richiedere 10 minuti o più, quindi non allarmarti se le prime query non estraggono subito il contenuto. Quando il grounding funziona, vedi la risposta da 200 dollari accompagnata da una piccola citazione che indica il documento caricato. Quella citazione è la conferma che la risposta è fondata.

Il conversational boosting non è una scorciatoia

Un'idea sbagliata diffusa è che il conversational boosting colmi magicamente le lacune. Non crea conoscenza delle policy: amplifica solo ciò che c'è. Se nella tua conoscenza non si trova alcuna corrispondenza, può ripiegare sulla conoscenza generale del modello o restituire risposte vaghe e imprecise. Quando la precisione conta, come in conformità, finanza o risorse umane, configura gli argomenti critici in modo che cerchino solo nelle fonti che hai aggiunto.

La persona: nome, descrizione e istruzioni

Anche la personalità va scritta, perché Copilot Studio non te la regala. Se lasci vuoti i campi, ottieni risposte predefinite, un saluto blando, senza autorità e senza contesto. In ambiti come HR o finanza un tono generico fa pensare di usare un prototipo e non uno strumento affidabile.

Pensa alla configurazione come a una scheda del personaggio: il nome è la classe, la descrizione è la storia, le istruzioni sono gli attributi e il tono è l'allineamento. Tutto si imposta nella pagina di panoramica, durante la creazione o in seguito.

I limiti da conoscere

• Nome: massimo 30 caratteri, quindi breve e chiaro, ad esempio "Esperto in politica di spesa".
• Descrizione: circa 1000 caratteri, abbastanza per un paio di frasi chiare, per esempio che l'agente fornisce ai dipendenti risposte tratte dalla policy di viaggio ufficiale, cita i passaggi pertinenti ed evita speculazioni.
• Istruzioni: fino a 8000 caratteri, lo spazio per le regole di lavoro: citare sempre la riga della policy quando disponibile, evitare risposte speculative, riassumere in una frase chiara per i dirigenti e poi fornire la citazione.

Tono, saluto e icona

Il tono si può esplicitare con formule come "formale e professionale" oppure "informale e facile da capire per chi non ha competenze tecniche". Se vuoi, inserisci esempi direttamente nelle istruzioni: non serve molto testo per orientare il bot.

Due ritocchi veloci fanno molta differenza. Il primo è l'argomento di inizio conversazione: sostituisci il messaggio di benvenuto generico con un'introduzione legata al ruolo, come "Sono qui per aiutarti a comprendere la politica di viaggio e citerò il documento ufficiale quando possibile". Il secondo è l'icona: il sistema accetta un PNG fino a 192x192 pixel e sotto i 30 kilobyte, e anche un semplice logo evita l'effetto demo.

Un'introduzione che cita il ruolo spinge gli utenti a fare domande pertinenti, le regole di tono evitano divagazioni e istruzioni più stringenti tengono lontani i riempitivi. Il risultato sono meno ticket del tipo "non capisco", senza bisogno di nuovi connettori o plug-in.

Debug in tempo reale: osserva, isola, correggi, ripeti

Quando un agente sbaglia, la reazione giusta è leggere i segnali e non ricominciare da capo. Il ciclo è semplice: osserva l'errore, isolalo, correggilo e rilancia lo stesso test.

La routine in cinque passaggi

1. Riproduci nel riquadro di test la query non riuscita, con esattamente la stessa domanda che farebbe l'utente.
2. Premi l'icona di aggiornamento per aprire una nuova chat: si riparte sempre da zero.
3. Apri gli argomenti per vedere quale è stato attivato. Se compare l'argomento di sistema del conversational boosting e non uno dei tuoi, il bot si è basato sul modello e non sulle tue conoscenze.
4. Se la risposta arriva dal boosting, controlla che il file o il sito siano stati caricati e indicizzati. Senza indicizzazione non c'è grounding, e l'indicizzazione può richiedere diversi minuti.
5. Modifica le istruzioni o il contenuto dell'argomento, salva e rilancia la stessa identica domanda.

Creare un argomento con Copilot

A volte il problema è una struttura mancante. Nella pagina degli argomenti puoi usare la creazione tramite descrizione con Copilot: scrivi ciò che ti serve, ad esempio "rispondi direttamente quando gli utenti chiedono informazioni sui limiti di spesa", e il sistema prepara la bozza dell'albero dei nodi. È rapido ed è utile quando il bot continua a ignorare la stessa domanda di base.

Esperimenti rapidi e controlli

Puoi fare un test A/B del tono in una decina di minuti. Nelle istruzioni scrivi la variante A, con linguaggio formale da policy, salva e chiedi qual è il limite di spesa per il viaggio. Poi passa alla variante B, una guida amichevole delle risorse umane che spiega in modo semplice citando le regole, e ripeti la domanda. Ottieni risposte affiancate e scegli il tono in base a prove, non a supposizioni.

Se un tester chiede "quanto posso spendere per gli hotel" e il bot risponde "verifica con le risorse umane", non è un fallimento totale ma un feedback. Forse il file non è ancora indicizzato, forse le frasi trigger non includono la parola "hotel". Controlla la scheda delle conoscenze, aggiungi "spese albergo" tra le frasi di attivazione e riprova. Se ottieni "secondo la policy, l'alloggio è limitato a 200 dollari a notte", il problema è risolto.

Un ultimo accorgimento sono gli avviatori di conversazione: dalla pagina di panoramica puoi precompilare da 3 a 5 prompt suggeriti, come "Qual è il limite per l'hotel?" o "Come presento una richiesta di rimborso?". L'utente li clicca subito, tu testi i percorsi reali più in fretta e il bot appare consapevole del proprio ruolo prima ancora che qualcuno scriva.

Pubblicazione e canali: Teams, SharePoint e sito web dimostrativo

Pubblicare non è un semplice clic per andare online. Significa stabilire chi può raggiungere l'agente, in che modo e come vengono mostrate le risposte. Teams, SharePoint e il sito web dimostrativo hanno ciascuno le proprie peculiarità: una risposta nitida in studio può apparire diversa, o non essere affidabile, in un altro canale.

Con Teams, per esempio, la stessa frase che in studio produce la risposta corretta può generare un "non capisco", perché il canale gestisce a capo e metadati in modo diverso. SharePoint ha il suo comportamento con l'interlinea, e anche il sito dimostrativo, il più semplice, può rendere la formattazione in modo diverso. Ogni canale va testato separatamente.

La checklist di pubblicazione

1. Verifica che le fonti di conoscenza siano completamente indicizzate: file appena caricati potrebbero non essere pronti per risposte live.
2. Imposta l'autenticazione. Per una demo estesa puoi scegliere nessuna autenticazione, così chiunque abbia il link può provarla.
3. Premi pubblica e controlla il banner di conferma verde o l'aggiornamento di stato nella pagina dei canali.
4. Nelle impostazioni del canale del sito dimostrativo aggiorna il messaggio di benvenuto e gli argomenti di conversazione, così i tester non si trovano davanti a una casella vuota.
5. Avvia un pilota chiuso, senza aprire subito a tutto il tenant.

Il pilota chiuso e il monitoraggio

Un piccolo gruppo con istruzioni chiare è più utile di un rilascio completo. Chiedi ai partecipanti di usare un linguaggio informale, inserire errori di battitura e persino caricare file: i loro passi falsi mostrano i punti deboli. Poi ripeti in ogni canale gli scenari già provati in studio: domanda formale, formulazione informale, errori di battitura, citazione fondata. Controlla se Teams li rende in modo diverso, se SharePoint altera la spaziatura e se il sito web mantiene la citazione della fonte.

Dopo la pubblicazione iniziano ad arrivare i dati. L'interfaccia di amministrazione di Power Platform e le analisi integrate mostrano numeri di adozione, conteggi degli errori e le conversazioni che non sono riuscite ad attivare un argomento. Si pubblica una volta, ma si controlla sempre: la pubblicazione non è l'ultima riga del libro, è l'inizio della campagna sul campo.

Errori comuni e stolpersteine da evitare

• Fidarsi di un test pulito: una domanda ben formulata nel riquadro di test non dimostra nulla sugli input reali.
• Frasi trigger troppo formali: copiare solo il linguaggio dei documenti di policy rende il bot fragile davanti a sinonimi ed errori di battitura.
• Nessun grounding: senza fonti verificate l'agente bluffa e produce allucinazioni.
• Contare sul conversational boosting: senza una fonte di conoscenza amplifica soltanto risposte generiche.
• Saltare la persona: campi vuoti significano tono generico, saluto anonimo e meno fiducia.
• Non aspettare l'indicizzazione: testare troppo presto fa sembrare il grounding rotto.
• Testare un solo canale: ciò che funziona in studio può cambiare in Teams, SharePoint o sul sito web.
• Pubblicare a tutti subito: senza pilota chiuso, i problemi li scoprono gli utenti sotto forma di ticket.

Takeaways pratici

• Prova sempre tre varianti di ogni domanda: pulita, informale e con errore di battitura.
• Amplia le frasi trigger con espressioni informali e abbreviate, senza esagerare.
• Carica documenti reali in Knowledge e attendi l'indicizzazione prima di valutare le risposte.
• Per gli argomenti critici, limita la ricerca alle fonti aggiunte.
• Compila nome (max 30 caratteri), descrizione (circa 1000) e istruzioni (fino a 8000), poi aggiorna saluto e icona.
• Segui il ciclo riproduci, correggi, rilancia, controllando quale argomento si è attivato.
• Usa 3-5 avviatori di conversazione per testare i percorsi principali.
• Prima di pubblicare controlla indicizzazione e autenticazione, poi conferma lo stato di pubblicazione.
• Avvia un pilota chiuso, ripeti i test in ogni canale e monitora le analisi.

Conclusione

Un agente affidabile in Copilot Studio nasce da tre scelte: ancorarlo a documenti reali perché smetta di indovinare, dargli una persona chiara con nome, descrizione, tono e istruzioni, e non fidarsi mai di un solo test pulito. Con riquadro di test, pilota chiuso, pubblicazione e monitoraggio costruisci un bot che guadagna fiducia invece di generare ticket. E ogni correzione ti avvicina a un collega virtuale su cui gli utenti possono contare, anche quando scrivono nel modo più disordinato.