Vai al contenuto principale
L’accuratezza e la coerenza del tuo chatbot dipendono da diversi fattori:
  • Qualità dei tuoi dati di addestramento
  • Scelta del Large Language Model (LLM)
  • Chiarezza ed esplicitezza del prompt di base
Gli LLM sono modelli statistici che richiedono grandi quantità di dati di addestramento.
Come si dice spesso nella ricerca sull’IA: «Un modello è buono quanto i suoi dati di addestramento.»
Il modo migliore per ottimizzare le prestazioni del tuo chatbot consiste nel ripulire i suoi dati di addestramento.
Di seguito trovi le best practices più importanti per strutturare i tuoi dati di addestramento.
Gli LLM non «pensano» come gli esseri umani. Interpretano le informazioni in modo diverso.
Per capire come vengono elaborate le informazioni, ci concentriamo qui sul concetto di chunk.

Suddivisione in chunk (Chunk Splitting)

Nel Retrieval-Augmented Generation (RAG), vengono selezionati dei chunk dal tuo materiale di addestramento e inseriti insieme al prompt di base nella richiesta dell’utente.
Questi chunk provengono direttamente dai tuoi dati caricati: PDF, pagine web, documenti Word, file TXT, ecc.
Dato che gli LLM hanno limiti di token, dobbiamo limitare la dimensione di un chunk. Ciò significa:
  • Anche se un capitolo del tuo documento tratta un unico argomento,
    deve essere suddiviso in più chunk e memorizzato separatamente nel nostro database vettoriale.
Come suddividere un documento mantenendo il più possibile il significato? Purtroppo non esiste un metodo universalmente perfetto.
INNOCHAT utilizza una combinazione di algoritmi basati su regole e statistici per creare i chunk, ma non possiamo garantire che ogni chunk sia:
  • completo,
  • pulito,
  • grammaticalmente corretto,
  • o semanticamente coerente.
Fortunatamente, gli LLM sono molto tolleranti nei confronti di testo non strutturato o imperfetto.

Qualità dei chunk

Un’altra fonte di errore è il contenuto del chunk stesso. Idealmente, ogni chunk dovrebbe essere:
  • interpretabile in modo autonomo
  • semanticamente coerente
  • grammaticalmente corretto
  • con eventuale indicazione di metadati (posizione nel documento)
Quando si estrae da documenti reali, questo è raramente perfetto. Il problema è particolarmente grave con le pagine web:
  • I browser visualizzano le pagine in modo diverso rispetto a un web-scraper
  • Layout, immagini, illustrazioni o contenuti incorporati spesso vanno persi
  • Le tabelle possono risultare distorte
Tabella dei prezzi INNOCHAT nel browser (Chrome).
Contenuto identico dopo scraping e suddivisione in chunk.

No gaps, no overlaps

Il RAG funziona selezionando un sottoinsieme di chunk rilevanti dai tuoi dati di addestramento.
Per farlo:
  1. La richiesta dell’utente viene incorporata (embedded)
  2. Ogni chunk viene incorporato
  3. Viene calcolata la similarità (distanza coseno)
  4. Vengono selezionati i Top-n chunk (in base al limite di token del modello scelto)
Poiché il sistema cerca di includere tutti i chunk semanticamente rilevanti, può succedere che:
  • più chunk riguardino lo stesso argomento
  • ma contengano informazioni fattualmente diverse o contraddittorie
Esempio: Qual è il prezzo dell’iPhone SE? Possibili chunk:
[Chunk 1] Il prezzo attuale dell’iPhone SE è di $250. [Chunk 2] L’iPhone SE originale costa $199. [Chunk 3] Il prezzo dell’iPhone 5 è di $600.
Tutti i chunk sono semanticamente rilevanti – contengono il termine «iPhone SE».
Ma i fatti sono incoerenti.
Ciò porta a risposte incoerenti del chatbot, anche per domande identiche.

Raccomandazione: Principio MECE

Mutually Exclusive, Collectively Exhaustive
= nessuna sovrapposizione, nessuna lacuna.
Struttura i tuoi dati di addestramento in modo che:
  • le informazioni siano chiaramente delimitate
  • non esistano affermazioni contraddittorie
Questo riduce drasticamente la probabilità che il contesto fornito all’LLM contenga dati contraddittori.

Rimuovi i dati di addestramento non necessari

Il RAG è un processo di corrispondenza semantica.
Dato il limite di token degli LLM, solo una piccola parte della base di conoscenza può essere utilizzata per richiesta.
Esempio:
  • 20 chunk totali
  • 10 chunk disponibili per richiesta
    → Ogni richiesta copre il 50 % della base di conoscenza
Ma:
  • 2000 chunk totali
  • 10 chunk disponibili per richiesta
    → Ogni richiesta utilizza solo lo 0,5 % della base di conoscenza
Più grande è la base di conoscenza, minore è la probabilità che vengano selezionate le informazioni rilevanti. Quindi vale la regola:

Meno, ma mirato = prestazioni del chatbot nettamente migliori

Dati mirati e puliti superano sempre grandi insiemi di dati disordinati.