AI & ricerca

Knowledge base per chatbot: come strutturare i contenuti per l'IA

Un chatbot non legge i documenti come un umano. Legge chunk, ricerca per similarità, mappa i concetti. Se la tua knowledge base è un mucchio di PDF disorganizzato, il chatbot soffrirà. Qui impari come chunking, metadata, tagging e plain language trasformano i tuoi contenuti in risorse che un'IA riesce a digerire e che Google riesce a citare.

A cura di ContatPubblicato il 20 settembre 20269 min di lettura

Una knowledge base tradizionale è una collezione di documenti e FAQ, organizzati per topic. Serve i clienti umani: cercano 'resetting password', trovano un link, leggono l'articolo da capo a fondo, risolvono.

Una knowledge base per un chatbot AI è una cosa diversa. L'IA non legge dal principio alla fine. Cerca frammenti di testo semanticamente vicini alla domanda, li assembla in un contesto e genera una risposta. La qualità di quella risposta dipende dalla granularità, dalla chiarezza e dall'organizzazione dei frammenti.

Questa guida spiega come disegnare una knowledge base che funziona per il chatbot, mantenendo al contempo la leggibilità umana e il valore SEO. Perché una buona knowledge base per l'IA è anche una buona knowledge base per Google, e vice versa.

Struttura dati vs testo libero: il dilemma

Due approcci:

Strutturato (JSON, tabelle, schema): Ogni informazione ha un campo: titolo, autore, data, categoria, versione. Il chatbot sa cosa è cosa. Google legge il markup e lo capisce meglio.
Testo libero (articoli, PDF, markdown): Tutto è scritto in paragrafi. Più leggibile per l'umano, meno strutturato per la macchina.

La verità: usi entrambi. La struttura organizza e orienta (metadata, categorizzazione). Il testo libero contiene il significato. Un documento ideale ha frontmatter strutturato (JSON) + corpo testuali ben scritto.

Esempio: {"title": "Come resettare la password", "category": "account", "difficulty": "beginner", "lastUpdated": "2026-09-20"} + [corpo dell'articolo in markdown chiaro]

Il chatbot usa il frontmatter per capire il contesto e il corpo per generare la risposta. Google usa il tutto.

Chunking: come dividere il contenuto

Chunking è la pratica di dividere un documento lungo in frammenti più piccoli, ognuno con senso compiuto. È il cuore di come il chatbot recupera l'informazione.

Il parametro chiave è la dimensione del chunk:

Troppo piccolo (50-100 token): Molti piccoli frammenti che il chatbot deve assemblare. Contesto parziale, rischi di perdere coerenza.
Ottimale (300-500 token): Grosso abbastanza per contenere un concetto intero (es. una sezione), piccolo abbastanza per essere rilevante senza rumore.
Troppo grande (1000+ token): Pochi grossi frammenti che racchiudono troppi concetti non correlati. Il chatbot recupera un'intera sezione quando t'interessa solo un paragrafo.

Una sezione di 400 token è un chunk di taglia giusta. Se l'articolo è lungo 2500 token, genera 5-6 chunk semanticamente legati: introduzione, sezione 1, sezione 2, conclusione, FAQ, link.

Overlap tra chunk: Aggiungi un piccolo overlap tra frammenti consecutivi (50-100 token di contesto da quello precedente). Questo aiuta il chatbot a capire che i chunk sono correlati e a mantenere coerenza nella risposta.

Esempio:

Chunk 1: Introduzione + 50 token della sezione 1
Chunk 2: Ultimi 50 token della sezione 1 + sezione 2 + 50 token della sezione 3
Chunk 3: Ultimi 50 token della sezione 3 + sezione 4 + conclusione

Metadata tagging: aiuta il retrieval

Metadata è il contesto che aiuta il chatbot a sapere se un chunk è rilevante per la domanda dell'utente.

Metadata utili:

title: Titolo del documento (non del chunk)
topic: Categoria principale (es. "account", "billing", "technical")
subtopic: Sottocategoria (es. "password reset", "payment methods")
difficulty: Livello di complessità ("beginner", "intermediate", "advanced")
language: Lingua del documento (per sistemi multilingue)
source: Da dove viene il contenuto (KB interna, FAQ pubblica, documento tecnico)
lastUpdated: Data ultima modifica (importante per validità)
versions: Versione del prodotto a cui si applica (se rilevante)
keywords: Parole chiave manuali (per boost in retrieval)

Il chatbot usa questo metadata per filtrare i chunk rilevanti prima di generare. Se l'utente chiede qualcosa di "billing" e il metadata dice "topic: account", quel chunk può essere scartato. Questo riduce l'allucinazione (inventare risposte).

Plain language: scrivi per macchine e umani

Un'IA generativa capisce meglio il testo chiaro e diretto che il testo tecnico o oscuro.

Regole di scrittura per knowledge base AI-ready:

Frasi brevi. Massimo 20 parole per frase. L'IA percepisce meglio il significato.
Verbi attivi. "Clicca il pulsante reset" invece di "Il reset del password può essere effettuato cliccando il pulsante". Meno ambiguità.
Evita l'ambiguità. Se una parola ha due significati, usa il più specifico o aggiungi contesto. "Ticket" è generico; "support ticket" è chiaro.
Acronimi spiegati. La prima volta che usi un acronimo, scrivi il significato intero. "Single Sign-On (SSO)" dopo scrivi "SSO".
Esempi concreti. Non: "Inserisci il valore appropriato". Sì: "Inserisci un email valido, es. user@example.com".
Numero di lista invece di paragrafi lunghi. Le IA e gli umani ambedue. "1. Clicca. 2. Inserisci. 3. Conferma" è più digeribile di tre paragrafi di narrativa.

Scritti così, il testo è idoneo sia al chatbot che a Google sia all'umano che legge dal browser.

Aggiornamento e versioning

Una knowledge base è un organismo vivo. Prodotti cambiano, procedure si aggiornano, bug si fixano. Il chatbot deve sapere quando il contenuto è obsoleto.

Strategie di versioning:

Timestamp di aggiornamento: Ogni chunk ha lastUpdated: "2026-09-20". Il chatbot può filtrar out chunk più vecchi di N giorni se la domanda è sullo state dell'arte.
Versione del prodotto: Se il tuo prodotto ha versioni (1.0, 2.0, 2.1), tagger ogni chunk con appliesTo: "v2.0+". Se il cliente usa v1.5, il chatbot non gli da risposte v2.0.
Deprecation flag: Se un processo è stato rimpiazzato, marca il vecchio contenuto come status: "deprecated". Il chatbot lo dà come fallback, ma con disclaimer.
Archivio: Documento i vecchi contenuti in archivio, non in live KB. Google indexa l'archivio? No, perché lo escludi via robots.txt.

Un sistema di versioning ben fatto fa risparmiare tempo: puoi aggiornare una versione senza mandare in giro il chatbot a correggere mille frammenti.

Integrazione con il tuo sito e la SEO

La knowledge base per il chatbot e il sito web devono condividere la stessa fonte di verità.

Scenario ideale:

Hai una KB centrale (es. database JSON, markdown folder, CMS interno)
Il chatbot la consuma tramite API (pull gli ultimi 100 chunk ogni ora)
Il tuo sito web la pubblica come FAQ e articoli (lo stesso JSON genera pagine HTML tramite SSG come Nuxt)
Google indexa il sito web e vede la KB come pagine pubbliche

Conseguenza: una update alla KB pubblica arriva al sito e al chatbot contemporaneamente. Niente duplicazione manuale, niente sincronizzazione rotta.

SEO benefit: Google vede il contenuto come articoli ben strutturati (non vede il "dietro le quinte" del chunking). Se ogni chunk è 300-400 token, ogni article/section è un size ragionevole per Google (1500-2000 token totali di articolo).

Plain language per citazioni AI

Uno dei benefici della buona knowledge base è che il tuo contenuto diventa candidato per citazioni negli LLM e nei motori di ricerca generativi (come Perplexity, Google SGE).

Se il tuo contenuto è ben scritto, ben strutturato e di qualità, quando un'IA cercherà risposta a una domanda che tu conosci, potrebbe citarti come fonte ("Secondo Contat...").

Questo vale per la SEO: citazioni dagli LLM hanno valore di ricerca generativa. Il tuo brand esce fuori in generative search. Ma solo se il contenuto è sufficientemente chiaro e affidabile per un'IA citarlo.

Leggi di più: Chatbot sul sito e SEO: cosa vede davvero Google.

Checklist di creazione della KB

Contenuti:

Ogni documento ha metadata strutturato (title, topic, difficulty, lastUpdated)
Ogni documento è diviso in chunk di 300-500 token con 50-100 token di overlap
Il testo è in plain language: frasi brevi, verbi attivi, esempi concreti
Acronimi spiegati; ambiguità risolte
Niente copy-paste tra documenti; ogni chunk ha senso compiuto

Organizzazione:

Gerarchia di topic/subtopic chiara e coerente
Versioning per ogni chunk se applicabile
Timestamp aggiornamento per ogni modifica
Archivio separato per contenuto deprecato

Integrazione:

Una sola fonte di verità (KB centrale)
Chatbot consuma KB tramite API
Sito web genera pagine public dalla stessa KB
Google indexa il sito, non il feed API del chatbot

SEO:

Ogni articolo/sezione ha URL unica e canonical
Meta title e description editabili
Schema.org FAQPage per articoli FAQ
Internal linking tra articoli correlati

Una buona knowledge base per l'IA è anche una buona knowledge base per l'uomo e per Google. Plain language, metadata, chunking: gli stessi principi che aiutano il chatbot aiutano il ranking.

FAQ

Domande su knowledge base per chatbot

No, ma simile. Un motore di ricerca interno indexa parole chiave; un chatbot ricerca per significato (embedding). Una KB per chatbot ha bisogno di metadata strutturato per il retrieval semantico, mentre un motore di ricerca usa keyword indexing. Ma la sorgente può essere la stessa: una KB ben strutturata serve entrambi.

No, perché il ranking del chatbot non esiste (non è Google). Quello che cambia è la qualità delle risposte: chunk diversi = contesto diverso = risposte diverse. Se cambio da 200 a 500 token per chunk, il chatbot avrà più contesto e potenzialmente risposte migliori, ma non c'è danno SEO.

No. Puoi tenere alcuni documenti privati (solo per il chatbot interno) e altri pubblici (sul sito web). Esempio: guide pubbliche sul sito, FAQ tecniche interne solo nel chatbot. La sorgente è una, il publishing è selettivo.

Dipende. Chunk grandi hanno più contesto (bene), ma anche più rumore (male). Chunk piccoli sono precisi, ma frammentati. La zona ottimale è 300-500 token, dove il chatbot ha contesto sufficiente e poco rumore. Prova entrambi e misura la qualità delle risposte.

No direttamente. Google indexa il testo pubblico (corpo dell'articolo), non i metadati nascosti del chatbot. Ma il metadata aiuta a pubblicare versioni diverse del contenuto (una per il web, una per il chatbot), e se la versione web è migliore per SEO, indirettamente il metadata contribu.

Esempio pratico di chunking

Immagina un articolo su "Come resettare la password":

Documento completo (1800 token)

Introduzione (100 token)
Sezione 1: Reset da accesso (400 token)
Sezione 2: Reset senza accesso (500 token)
Sezione 3: Problemi comuni (400 token)
Conclusione (100 token)

Chunking ideale (4 chunk da ~400 token):

Chunk 1: Introduzione + metà Sezione 1 (400 token)
Chunk 2: Metà Sezione 1 (overlap) + Sezione 2 completa + inizio Sezione 3 (450 token)
Chunk 3: Fine Sezione 2 (overlap) + resto Sezione 3 + Conclusione (400 token)

Ogni chunk ha senso compiuto. Il chatbot che ricerca "password reset" trova uno o più chunk rilevanti e li assembla in una risposta. L'umano che legge l'articolo web vede la pagina completa. Google indexa il tutto come un articolo coeso.

Link a contenuti correlati

Stai costruendo un chatbot e non sai come strutturare il contenuto?

Aiutiamo a progettare una knowledge base che funziona per il chatbot, il tuo team e Google. Dalla strategia di chunking al metadata alla pubblicazione.

Descrivi il tuo progetto con Smartquote Scopri i nostri servizi SEO