Come funziona davvero un assistente privato sui tuoi documenti, wiki e dati: il RAG spiegato in termini semplici, l'ancoraggio con citazioni, le risposte rispettose dei permessi, il posizionamento dei modelli, la freschezza dell'indice, la misurazione dell'accuratezza, i canali e l'integrazione. Scritta per farti capire il motore prima di collegare qualsiasi fonte.
Ogni azienda oltre una certa dimensione ha lo stesso problema invisibile: la risposta a quasi qualsiasi domanda operativa esiste da qualche parte dentro l'organizzazione, ma trovarla in modo affidabile e lento, incoerente e dipende troppo dal sapere a chi chiedere. Un knowledge assistant e il modo per rendere quella conoscenza accessibile in modo affidabile senza ricostruire la tua architettura informativa.
Un knowledge assistant e un sistema AI che risponde a domande sulle informazioni specifiche della tua organizzazione. Non viene addestrato su quelle informazioni come un modello linguistico viene addestrato su internet. Invece, legge dalle tue fonti al momento della query, recupera i passaggi piu rilevanti per una domanda e usa un modello linguistico per comporre una risposta esattamente da quei passaggi, con una citazione alla fonte cosi la risposta puo essere verificata.
Vale la pena essere precisi su cio che non e. Non e un motore di ricerca, perche ti fornisce una risposta composta invece di un elenco di link. Non e un chatbot AI generico, perche risponde solo dai tuoi documenti e ti dira quando non riesce a trovare una fonte pertinente invece di inventarsi qualcosa. E non e un esercizio di addestramento: non metti a punto un modello sulla tua knowledge base. La interroghi.
La distinzione e importante perche recupero e addestramento hanno tradeoff opposti. L'addestramento e costoso, lento da aggiornare e puo incorporare informazioni obsolete. Il recupero e economico, aggiornabile istantaneamente e trasparente: ogni risposta ha una fonte tracciabile.
RAG sta per Retrieval-Augmented Generation. Il nome e piu intimidatorio del concetto. Ecco l'idea in termini semplici:
Quando un utente fa una domanda, il sistema non la passa immediatamente a un modello linguistico. Prima cerca nell'indice i passaggi che con maggiore probabilita contengono la risposta. Immagina di trovare le pagine giuste in un libro molto grande prima di chiedere a qualcuno di riassumerle. Questi passaggi, chiamati contesto o chunk recuperati, vengono poi passati al modello linguistico insieme alla domanda originale. Il modello compone la sua risposta da cio che si trova nel contesto, non dai suoi dati di addestramento.
Il risultato e una risposta specifica per i tuoi documenti, citabile perche i passaggi sorgente sono noti, e delimitata da cio che la tua knowledge base contiene realmente. Se la risposta non e nei tuoi documenti, un assistente ben costruito lo dice invece di indovinare.
Apriamo ogni ingaggio con un pilot gratuito. Colleghi una o due delle tue fonti esistenti: uno spazio Confluence, una cartella Google Drive, un database Notion. Le indicizziamo, costruiamo la pipeline di recupero e poi testi l'assistente sulle domande che il tuo team fa davvero ogni giorno.
Al termine del pilot hai un dato di accuratezza misurato sulla tua conoscenza reale, non la claim di un fornitore su cio che la tecnologia puo fare in teoria. Hai anche un tasso di citazione, la quota di risposte che si collegano a una fonte specifica, e un'analisi dei gap che mostra quali categorie di domande sono poco coperte. Ti tieni tutto questo indipendentemente dal fatto che tu proceda con il build completo.
Il pilot e gratuito perche e l'unico modo onesto per definire lo scope del lavoro. Il numero giusto di fonti da indicizzare, la giusta strategia di chunking, la profondita di recupero giusta e l'accuratezza raggiungibile dipendono tutti dalla forma specifica della tua conoscenza. Un pilot misurato ti dice esattamente cosa stai comprando.
Il passo di recupero e dove vive la maggior parte dell'ingegneria interessante. Quando arriva una domanda, il sistema deve trovare i passaggi pertinenti da un indice che puo contenere milioni di pagine. Lo fa in tre sotto-passi: chunking, embedding e ricerca vettoriale.
Il chunking consiste nel dividere i tuoi documenti in passaggi di dimensioni gestibili, tipicamente qualche centinaio di parole, cercando di preservare la coerenza semantica. Un chunk che taglia attraverso il confine di un paragrafo a meta frase e piu difficile da recuperare accuratamente rispetto a uno che rispetta la struttura naturale del documento. Un buon chunking e un mestiere, non un'impostazione da configurare.
L'embedding consiste nel convertire ogni chunk e ogni query in arrivo in un vettore: un elenco di numeri che cattura il significato del testo in un modo che consente il confronto matematico. Due parti di testo semanticamente simili avranno vettori vicini in questo spazio ad alta dimensionalita, anche se non condividono alcuna parola in comune. Questo e cio che permette all'assistente di trovare un documento di policy in risposta a una domanda formulata in modo molto diverso dal linguaggio del documento stesso.
La ricerca vettoriale trova i chunk i cui vettori di embedding sono piu vicini al vettore della query. Questo viene fatto con un database vettoriale, un sistema ottimizzato per il tipo di ricerca approssimativa del vicino piu prossimo che il recupero richiede su scala. I risultati migliori, tipicamente i dieci o venti chunk piu pertinenti, diventano il contesto per il modello linguistico.
L'ancoraggio e cio che separa un knowledge assistant da un chatbot generico, ed e il concetto piu importante di questa guida. Ogni risposta che l'assistente produce e composta da passaggi recuperati specifici. Ognuno di questi passaggi e tracciabile a un documento, una pagina e una sezione specifici. L'assistente include quella citazione nella risposta, e un utente puo cliccare sulla fonte esatta.
Perche questo e cosi importante? Perche un modello linguistico non vincolato a fonti specifiche colmera i gap dai suoi dati di addestramento, e in un contesto aziendale quei gap sono esattamente dove vivono le informazioni piu sensibili e variabili: la tua policy attuale, il tuo pricing piu recente, il tuo processo specifico per un dato mercato. L'ancoraggio previene questo. L'assistente risponde da cio che i tuoi documenti dicono realmente, non da cio che il modello e stato addestrato a dire su come operano le aziende in generale.
Le citazioni cambiano anche come la risposta arriva alla persona che chiede. Una risposta senza citazione chiede fiducia. Una risposta con una citazione alla specifica pagina e paragrafo della policy invita alla verifica. Quella differenza conta enormemente per i casi d'uso in cui un knowledge assistant ha il valore piu alto: onboarding, compliance, supporto e vendite.
C'e anche un beneficio operativo. Quando una risposta e sbagliata, una risposta citata ti dice esattamente dove si trova il problema: o la citazione e sbagliata, che e un problema di recupero, oppure la citazione e giusta ma il documento stesso e sbagliato, che e un problema di contenuto. Una risposta non citata ti lascia solo con una risposta sbagliata e nessun percorso per correggerla.
Una delle prime domande che ogni team fa e: cosa succede quando qualcuno chiede qualcosa che non dovrebbe vedere? Un knowledge assistant ben costruito applica il controllo degli accessi al layer di recupero, non come passo di post-elaborazione.
Quando l'assistente recupera passaggi per una domanda, filtra l'indice in base a cio che la persona che chiede e autorizzata a leggere. Un nuovo assunto non ha i file riservati del team finanziario che emergono nelle sue risposte, perche quei file sono esclusi dal suo pool di recupero prima che avvenga qualsiasi ricerca. Lo stesso documento puo apparire nelle risposte di una persona e non in un'altra, in base allo stesso modello di permessi che governa la fonte originale.
In pratica, cio significa che il modello di permessi del tuo knowledge assistant rispecchia il modello di permessi delle tue fonti esistenti. I permessi degli spazi Confluence, le impostazioni di condivisione di Google Drive, l'accesso alle pagine Notion: si traducono direttamente in filtri di recupero. Non devi costruire un nuovo sistema di controllo degli accessi. Erediti quello che gia mantieni.
Questo e anche il motivo per cui un knowledge assistant e piu sicuro della maggior parte degli approcci alternativi per rendere accessibile la conoscenza interna. Una pagina wiki condivisa che qualcuno cerca direttamente potrebbe rivelare la sua esistenza attraverso i risultati di ricerca anche se la pagina stessa e riservata. In un sistema di recupero rispettoso dei permessi, la pagina semplicemente non si trova nel pool di recupero per quell'utente, quindi non c'e nulla da portare in superficie.
Ci sono due classi di modelli in un knowledge assistant: il modello di embedding che converte il testo in vettori, e il modello linguistico che compone le risposte dai chunk recuperati. Entrambi possono girare nel cloud o all'interno della tua infrastruttura.
Per la maggior parte dei team, partire con un provider cloud ospitato e il punto di partenza giusto. E piu veloce da configurare, piu facile da scalare e i modelli disponibili tramite le API cloud sono eccellenti. Il tradeoff e che il contenuto dei tuoi documenti viaggia verso l'infrastruttura del provider quando viene incorporato e quando viene incluso in un prompt.
Per i team con requisiti stringenti di residenza dei dati, dati regolamentati sensibili o policy di sicurezza che vietano il trasferimento di dati esterni, eseguiamo entrambi i modelli all'interno del tuo ambiente. Questo tipicamente significa eseguire un modello di embedding open-weights e un modello linguistico open-weights piu piccolo sui tuoi server o nella tua tenancy cloud privata. Il tradeoff e piu infrastruttura da gestire e di solito un modello un po' piu lento o meno capace, anche se il gap si e notevolmente ridotto.
Il percorso dei dati e una decisione progettuale, non un'impostazione predefinita. Concordiamo il percorso dei dati prima di indicizzare qualsiasi documento: quali modelli, dove girano, cosa viene inviato fuori dal tuo ambiente, cosa viene conservato e per quanto tempo. Se la risposta a "i miei documenti lasciano la mia rete" deve essere no, lo costruiamo cosi. Se velocita e capacita contano di piu, usiamo il miglior modello cloud disponibile.
Un knowledge assistant e utile solo quanto il suo indice e aggiornato. Se una policy HR e stata aggiornata sei mesi fa ma l'indice riflette ancora la vecchia versione, l'assistente fornira con sicurezza risposte obsolete con citazioni che sembrano corrette ma non lo sono.
La freschezza dell'indice viene mantenuta tramite sincronizzazione. La maggior parte dei sistemi sorgente espone webhook o API di notifica delle modifiche che consentono di aggiornare l'indice non appena un documento cambia. Confluence notifica sulle modifiche alle pagine. Google Drive notifica sui cambiamenti ai file. Notion espone un changelog. Dove i webhook non sono disponibili, una scansione programmata reindicizza il contenuto modificato a un intervallo configurabile, tipicamente giornaliero.
Il processo di reindicizzazione per un documento modificato e efficiente: il sistema identifica quali chunk sono interessati, rimuove i vettori obsoleti dall'indice e aggiunge quelli nuovi. Una knowledge base estesa puo tipicamente essere mantenuta aggiornata con latenza minima, in modo che una pagina di policy aggiornata sia interrogabile dal suo nuovo contenuto entro pochi minuti dalla modifica.
Questo e il meccanismo che rende un knowledge assistant piu utile di un portale di documentazione statico: il portale richiede che qualcuno ricordi di aggiornarlo e poi di controllarlo; l'assistente risponde da cio che i tuoi sistemi sorgente dicono attualmente.
L'accuratezza in un knowledge assistant ha due significati diversi, ed e utile tracciarli separatamente.
L'accuratezza del recupero indica se il sistema ha trovato i passaggi giusti. Se i chunk recuperati non contengono la risposta alla domanda, il modello non puo dare una risposta corretta anche se e eccellente nella composizione. La misuri facendo domande con risposte note e controllando se i passaggi sorgente pertinenti appaiono nei risultati recuperati in cima.
L'accuratezza della risposta indica se il modello ha composto la risposta corretta dai passaggi recuperati. Un modello puo recuperare il passaggio giusto e fraintenderlo, o recuperare un passaggio parzialmente pertinente e produrre una risposta tecnicamente vera ma fuorviante. La misuri confrontando la risposta del modello con una risposta ground truth da un test set di domande reali del tuo team.
Il tasso di citazione e un terzo segnale da monitorare: quale frazione di risposte include una citazione a una fonte specifica. Un alto tasso di citazione non e sufficiente per l'accuratezza, ma un basso tasso di citazione e un segnale affidabile che qualcosa non va nel recupero o nell'ancoraggio.
| Metrica | Cosa indica | Target |
|---|---|---|
| Recall del recupero a 10 | La fonte giusta e apparsa tra i 10 chunk recuperati in cima? | Sopra l'85% |
| Accuratezza della risposta | La risposta composta e corretta rispetto a un test set? | Sopra il 90% |
| Tasso di citazione | Quota di risposte che includono un link alla fonte | 100% |
| Tasso di allucinazione | Quota di risposte contenenti un'affermazione non nella fonte | Sotto il 2% |
| Tasso di non-risposta | Quota di domande a cui l'assistente ha correttamente rifiutato di rispondere | Da monitorare, non da minimizzare |
Il tasso di non-risposta merita una nota. Un assistente ben calibrato dovrebbe rifiutarsi di rispondere quando non riesce a trovare fonti pertinenti. Se il tasso di non-risposta e zero, l'assistente sta probabilmente facendo supposizioni su domande al di fuori della sua conoscenza invece di dire che non lo sa. Questo e un segnale di eccessiva fiducia che minera la credibilita.
Dove si trova l'assistente conta quanto cio che sa fare. Il canale migliore e quello in cui il tuo team gia vive.
Slack e il primo deployment piu comune. Gli utenti fanno domande in un canale dedicato o menzionando l'assistente in qualsiasi thread. L'assistente risponde nel thread con la risposta e le citazioni. Il modello di threading di Slack rende facile fare follow-up, condividere la risposta con un collega e farvi riferimento in seguito.
Microsoft Teams funziona allo stesso modo: un bot Teams che risponde alle domande nei canali o in messaggi diretti, con citazioni che si collegano al documento sorgente in SharePoint o dove si trova. Per le organizzazioni che operano su Microsoft 365, l'integrazione con Teams significa anche che l'assistente puo essere reso disponibile all'interno di canali team specifici, limitando il suo scope alla conoscenza piu rilevante per quel team.
Un widget web e la scelta giusta quando vuoi che l'assistente sia disponibile su una pagina web o portale interno, come un sito di supporto o onboarding, senza richiedere a tutti di usare Slack o Teams. Il widget viene incorporato con poche righe di JavaScript e appare come un elemento di chat flottante.
L'assistente sottostante e lo stesso indipendentemente dal canale. L'integrazione del canale e uno strato sottile sopra la pipeline di recupero e composizione.
Un knowledge assistant e buono solo quanto le fonti che riesce a raggiungere. Il layer di integrazione e il modo in cui quelle fonti si connettono all'indice.
Per la maggior parte degli strumenti comuni esistono gia connettori: Confluence usa la REST API per estrarre pagine e allegati, Google Drive usa la Drive API per leggere documenti e Sheets, Notion usa la sua API pubblica, SharePoint usa la Microsoft Graph API. Per Jira e Zendesk, le API espongono ticket e articoli della knowledge base. GitHub espone repository e wiki. Per database interni o sistemi su misura, scriviamo un connettore personalizzato contro qualsiasi interfaccia disponibile.
I connettori gestiscono tre compiti: indicizzazione iniziale in blocco, aggiornamenti incrementali man mano che il contenuto cambia e metadati di permesso in modo che il layer di recupero sappia chi e autorizzato a vedere cosa. Quest'ultimo e il piu importante da fare bene ed e il piu comunemente trascurato nelle soluzioni preconfezionate.
I PDF sono un caso speciale. I PDF basati su testo si indicizzano senza problemi. I PDF che sono immagini scansionate hanno bisogno prima dell'OCR. Per i team con un mix di entrambi, eseguiamo un passaggio OCR come parte della pipeline di indicizzazione in modo che i documenti scansionati siano interrogabili insieme a tutto il resto.
| Fonte | Contenuto coperto | Modello di permessi |
|---|---|---|
| Confluence | Pagine, blog post, allegati | Restrizioni di spazio e pagina |
| Google Drive | Documenti, Sheets, PDF, presentazioni | Impostazioni di condivisione file e cartella |
| Notion | Pagine, database, sottopagine | Permessi workspace e pagina |
| SharePoint | Pagine, documenti, librerie | Gruppi e permessi Microsoft 365 |
| Jira | Ticket, commenti, sprint | Permessi di progetto e issue |
| Zendesk | Articoli della knowledge base, macro | Impostazioni di visibilita degli articoli |
| GitHub | Wiki, README, issue | Accesso al repository |
| DB interno / API | Personalizzato, definito per ingaggio | Auth a livello di riga o record |
Un knowledge assistant contiene un indice della conoscenza interna della tua organizzazione. Questo rende la sicurezza una preoccupazione di primo livello, non una funzionalita da aggiungere in seguito.
La proprieta di sicurezza piu importante e che l'indice non e un unico blob ricercabile. E partizionato per fonte e ogni partizione porta i metadati di accesso dal sistema originale. Quando un utente interroga l'assistente, il layer di recupero filtra in base alla sua identita prima di cercare, in modo che l'indice non faccia mai trapelare contenuto attraverso i confini dei permessi.
La sicurezza di rete e dei dati funziona come qualsiasi servizio interno: l'indice e il modello sono all'interno della tua rete o dietro il perimetro di sicurezza della tua tenancy cloud. Il traffico tra l'assistente e i tuoi sistemi sorgente usa credenziali OAuth standard o account di servizio con scope limitati all'accesso in sola lettura. L'assistente non scrive nulla nei tuoi sistemi sorgente.
Per gli ambienti regolamentati, allineamo il percorso dei dati ai tuoi requisiti di compliance. Tipicamente significa documentare esattamente quali dati fluiscono dove, concordare una policy di conservazione per i log delle query e far girare l'indice su infrastruttura che soddisfa i tuoi obblighi di residenza dei dati e audit. I requisiti GDPR, SOC 2 e ISO 27001 vengono definiti per ogni ingaggio invece di essere gestiti con un checkbox generico.
La forma del lavoro: un pilot gratuito su una o due delle tue fonti esistenti per misurare l'accuratezza su domande reali, un build a scope fisso che connette tutte le tue fonti, integra il tuo modello di permessi e porta l'assistente in Slack, Teams o un widget web, poi operativita continuativa per mantenere l'indice accurato e le risposte aggiornate man mano che la tua conoscenza cambia.
Il build e software che possiedi e gestisci tu. Non c'e una licenza di piattaforma nel mezzo. Il modello puo essere un modello cloud ospitato sulla tua chiave API o un modello open-weights che gira sulla tua infrastruttura. L'indice e un database vettoriale all'interno del tuo ambiente. Possiedi il percorso dei dati dall'inizio alla fine.
Questo e un ingaggio di servizi AI. Il knowledge assistant e il secondo servizio AI che Scalarly ha portato sul mercato, insieme a Document AI. Lo stesso approccio vale per entrambi: misura prima l'accuratezza sui tuoi dati, consegna un workflow che funziona, possiedi il risultato. Il modello di ingaggio e lo stesso: un pilot gratuito, un build fisso e operativita continuativa se vuoi che lo teniamo in esecuzione e accurato.
Questo e il motore completo. Il passo successivo e un pilot gratuito sulla tua knowledge base reale: numeri di accuratezza reali, le ore quantificate, senza impegno.
Un pilot gratuito sulla tua knowledge base reale. Citazioni ancorate. Permessi rispettati. Poi lo integriamo in Slack o Teams.
Richiedi un pilot gratuito