Come creare una knowledge base: articoli, ricerca, permessi e risposte AI

Una knowledge base è una biblioteca consultabile di risposte: come fare qualcosa, come risolvere un problema, qual è la regola. Per costruirne una ti servono articoli raggruppati in alcune categorie chiare, un editor che i tuoi redattori useranno davvero, una ricerca che trovi l'articolo giusto dalle parole che le persone digitano davvero e una decisione su chi può leggere cosa: il pubblico, i clienti autenticati o solo lo staff. Un builder AI può produrre la struttura, l'editor e la ricerca in una sessione breve. Ciò che rende utile una knowledge base è la scrittura e la manutenzione, quindi progetta fin dal primo giorno per una modifica facile e per individuare gli articoli obsoleti.

Decidi prima per chi è

Gli stessi strumenti servono siti molto diversi:

• Centro assistenza pubblico — per clienti e potenziali clienti. Deve essere veloce, indicizzabile dai motori di ricerca e scritto con le loro parole.
• Documentazione riservata ai clienti — dietro un login, per clienti paganti o partner.
• Knowledge base interna — policy, processi, guide pratiche per lo staff. Deve essere privata; la ricerca e la freschezza contano più del design.

Mescolare articoli pubblici e interni in un unico sito è la causa principale delle fughe di informazioni. Se ti servono entrambi, assegna a ogni articolo un'impostazione di visibilità chiara, oppure gestisci due siti separati.

Cosa serve all'app

Dati

Due campi fanno molto lavoro: responsabile (chi tiene l'articolo accurato) e ultima revisione (quando qualcuno ha confermato per l'ultima volta che è ancora vero). Insieme ti permettono di elencare gli articoli che nessuno controlla da sei mesi.

Pagine

• Lettore: home con ricerca e categorie, pagine di categoria, pagine articolo con indice, articoli correlati e la domanda "È stato utile?".
• Editor: elenco articoli con filtri (bozze, obsoleti, valutati male), un editor con anteprima e cronologia delle revisioni.
• Amministrazione: categorie, utenti e ruoli, e report sulle ricerche senza risultati.

Permessi

I lettori vedono gli articoli pubblicati a cui hanno accesso. Gli editor creano e modificano gli articoli, magari limitatamente ad alcune categorie. Gli amministratori pubblicano, archiviano e gestiscono gli utenti. Per una knowledge base interna serve il login per tutti; per un centro assistenza pubblico, solo per chi scrive.

Decisioni e compromessi

Editor: Markdown o testo ricco

Markdown è rapido, portabile e funziona bene con la cronologia delle versioni, ma alcuni redattori lo trovano ostico. Un editor di testo ricco con titoli, elenchi, immagini, box di avviso e blocchi di codice risulta familiare. Qualunque scelta tu faccia, salva i contenuti in un formato che potrai esportare in seguito.

Ricerca

La ricerca testuale di base del database basta per qualche centinaio di articoli, se cerchi in titoli, riepiloghi e corpi e dai più peso alle corrispondenze nei titoli. Oltre questa soglia, o se contano errori di battitura e sinonimi ("fattura" vs "ricevuta"), usa una vera ricerca full-text o un servizio di ricerca ospitato. La nostra guida su come aggiungere la ricerca illustra le opzioni. Registra ogni query che non restituisce nulla: è un elenco gratuito degli articoli da scrivere.

Risposte AI

Una casella "fai una domanda" che risponde a partire dai tuoi articoli è ormai comune. Funziona recuperando i passaggi più pertinenti e chiedendo a un modello linguistico di rispondere solo in base a essi — vedi cos'è il RAG. Mostra sempre gli articoli di origine, consenti la risposta "non lo so" e ricorda che ripeterà con sicurezza qualsiasi cosa di obsoleto ci sia nei tuoi articoli. Costruiscila dopo che gli articoli sono in buono stato, non prima.

Versioni e revisione

Conserva le revisioni così puoi vedere chi ha cambiato cosa e tornare indietro. Per i contenuti regolamentati (policy HR, procedure di sicurezza), aggiungi un passaggio di approvazione prima della pubblicazione di una modifica.

Un primo prompt che funziona

Crea un centro assistenza pubblico per Parcelly, un'app per le etichette di spedizione destinata a piccoli e-commerce. Home page con una grande casella di ricerca e sei categorie (Per iniziare, Stampa delle etichette, Corrieri, Fatturazione, Resi, Risoluzione dei problemi). Gli articoli hanno titolo, riepilogo, corpo in Markdown con immagini e box di avviso, categoria, tag, stato (bozza, pubblicato, archiviato), responsabile e data dell'ultima revisione. Le pagine articolo mostrano un indice, articoli correlati e un "È stato utile?" sì/no con un commento facoltativo. La ricerca copre titoli, riepiloghi e corpi, con le corrispondenze nei titoli messe per prime, e registra ogni query e se ha restituito risultati. Un'area editor (login richiesto, ruoli editor e amministratore) elenca le bozze, gli articoli non revisionati da 180 giorni e quelli con punteggi di utilità bassi, e conserva la cronologia delle revisioni. Ogni articolo ha un proprio titolo di pagina e una meta description per i motori di ricerca. Design pulito, calmo, leggibile. Prima il mobile.

Passaggi di costruzione

1. Elenca i primi 20–30 articoli partendo da domande reali dell'assistenza, prima di costruire qualsiasi cosa. Quell'elenco determina le categorie.
2. Genera il sito e verifica la lettura da telefono: lunghezza delle righe, titoli, immagini.
3. Editor e ruoli. I redattori devono poter aggiungere e correggere articoli senza chiedere a uno sviluppatore.
4. Ricerca, poi testala con le parole che usano davvero i clienti, inclusi gli errori di battitura.
5. Feedback e registrazione delle ricerche.
6. Report sugli articoli obsoleti basato su responsabile e data dell'ultima revisione.
7. Basi SEO per un sito pubblico: titoli e descrizioni unici, URL puliti, una sitemap. Vedi SEO per siti creati con l'AI.
8. Collegala dal tuo prodotto e dalle risposte di assistenza, poi controlla ogni settimana il log delle ricerche senza risultati.
9. Risposte AI, quando i contenuti sono solidi.

Errori comuni

• Organizzare per reparto invece che per ciò che il lettore vuole fare.
• Articoli lunghi che coprono cinque attività. Un'attività per articolo, con un titolo che dice quale problema risolve.
• Nessun responsabile per articolo. Nessuno aggiorna nulla, e la fiducia cala al primo errore.
• Note interne negli articoli pubblici. Usa una visibilità separata e revisiona prima di pubblicare.
• Una ricerca che confronta solo i titoli. I lettori digitano sintomi, non nomi di articoli.
• Screenshot senza testo alternativo o contesto. Invecchiano in fretta; descrivi il passaggio anche a parole.

Quando è meglio un prodotto già pronto

Se il tuo team lavora già in uno strumento di documentazione o wiki, una knowledge base interna lì è di solito la strada più comoda — la nostra comparazione Notion vs Confluence copre due scelte frequenti. Se usi un prodotto di helpdesk, il suo centro assistenza integrato collega gli articoli ai ticket e suggerisce articoli ai clienti, cosa difficile da replicare. I generatori di siti di documentazione sono ideali per la documentazione per sviluppatori tenuta accanto al codice.

Costruiscine una tua quando ti servono una struttura o permessi personalizzati (articoli per cliente, per sede, per ruolo), vuoi la knowledge base dentro il tuo prodotto anziché su un sito separato, ti servono passaggi di revisione e approvazione che una wiki non impone, o vuoi risposte AI sui tuoi contenuti senza un altro abbonamento. Si abbina bene a un helpdesk personalizzato.

Costruirlo con Mythex

Su Mythex descrivi la knowledge base in chat e viene costruita in un'anteprima live; articoli, revisioni e feedback sono salvati in un database Postgres che l'agente aggiunge quando serve, e le immagini vanno nello storage di file del progetto. I login degli editor usano un approccio di autenticazione che scegli tu, poiché Mythex non ha un login utente integrato. Per le risposte AI usi la chiave API del tuo fornitore di AI salvata come segreto di progetto, e l'utilizzo viene addebitato al tuo account presso il fornitore, non ai crediti Mythex (ricetta AI). Le nuove app Mythex usano per default una single-page app React renderizzata lato client, meno efficace per i motori di ricerca; quindi per un centro assistenza pubblico chiedi una configurazione statica o renderizzata lato server, come Next.js (ricetta SEO).

Per un prompt di partenza prova i template hub di conoscenza del prodotto o app di documentazione del team.

Domande