Caso Studio: ChipsBot

Il problema della specializzazione nell’AI

Immagina di costruire un chatbot per una piattaforma con più prodotti: website building, fatturazione, domini, SEO, privacy, supporto tecnico. L’approccio istintivo è un unico chatbot monolitico con un prompt che copre tutto.

Questo approccio ha limiti strutturali:

• Context window dispersa — anche con 200K token, un prompt che copre 10 domini è rumoroso. Il modello perde efficacia quando il contesto è troppo vasto (fenomeno “lost in the middle”, descritto nella sezione Modelli AI).
• Conflitto di istruzioni — regole diverse per domini diversi si contraddicono. Il tono del supporto tecnico (preciso, step-by-step) è diverso da quello commerciale (rassicurante, orientato alla conversione).
• Aggiornamento costoso — modificare la knowledge base di un dominio richiede di ri-testare l’intero sistema.
• Impossibilità di ottimizzare — non puoi usare un modello piccolo e veloce per le FAQ semplici e uno grande per il supporto tecnico. È tutto o niente.

La domanda fondamentale: come dare a un sistema AI la profondità di un esperto di dominio mantenendo la copertura di un generalista? La risposta è la stessa delle organizzazioni umane: specializzazione + coordinamento.

Architettura: orchestratore e specialisti

Il pattern che risolve questo problema è l’architettura hub-and-spoke (descritta nella sezione Orchestrazione):

1. Un orchestratore riceve ogni richiesta dell’utente
2. Determina l’intento e sceglie lo specialista più adatto
3. Lo specialista risponde con la sua conoscenza specifica e la sua knowledge base dedicata

In ChipsBot, l’orchestratore è connesso a 11 specialisti, ciascuno su un dominio preciso:

Gli specialisti si agganciano e sganciano a runtime dall’orchestratore, senza toccare il codice. Ogni specialista ha la propria knowledge base, il proprio prompt e può usare un modello AI diverso.

Decomposizione per dominio

La regola pratica: ogni specialista copre ciò che un esperto umano specializzato saprebbe rispondere senza consultare colleghi. Se un esperto di fatturazione non sa rispondere a una domanda tecnica su DNS, sono domini separati.

Criteri per la decomposizione:

• Coerenza della knowledge base — tutti i documenti dello specialista parlano dello stesso dominio
• Frequenza di aggiornamento — domini volatili (prezzi, promozioni) separati da quelli stabili (documentazione tecnica)
• Tono e stile — domini con tono diverso sono buoni candidati per specialisti separati
• Volume di query — domini con molte query meritano specialisti dedicati e ottimizzati

Il routing semantico a 3 stadi

Il problema centrale di un sistema multi-agente è il routing: come decidere quale specialista deve rispondere, in modo veloce e accurato? L’approccio più semplice è passare la domanda a un LLM e chiedergli di scegliere. Ma ha un costo: una chiamata LLM extra per ogni messaggio.

ChipsBot usa un sistema di routing a 3 stadi progressivi, ciascuno attivato solo se il precedente non trova un match sufficiente:

Stage 1: RAG diretto

Il primo stadio è puro RAG. La query dell’utente viene convertita in un vettore di embedding (768 dimensioni, modello Jina jina-embeddings-v3, task retrieval.query) e confrontata via cosine similarity con i vettori delle knowledge base di tutti gli specialisti, memorizzati in un database PostgreSQL con estensione pgvector.

Se lo specialista con il punteggio più alto supera una soglia configurabile (default: 0.40), il routing avviene senza nessuna chiamata LLM. È il percorso più veloce ed economico.

La scelta di Jina jina-embeddings-v3 non è casuale: supporta task separati per indicizzazione (retrieval.passage) e query (retrieval.query), ottimizzando la similarità asimmetrica tipica del retrieval domanda-documento. I vettori sono normalizzati a norma 1.0, il che rende la cosine similarity equivalente a un semplice dot product — operazione che pgvector esegue in modo efficiente.

Stage 2: HyDE (Hypothetical Document Embedding)

Se Stage 1 non trova un match sopra soglia, entra in gioco HyDE — una tecnica che affronta un problema fondamentale del RAG classico.

Il problema: query brevi e sparse come “prezzi?” o “non funziona” hanno embedding molto diversi dai documenti della knowledge base, anche quando la risposta è lì. L’utente scrive una domanda; il documento è una risposta. Spazi semantici diversi.

La soluzione di HyDE (presentata nel paper Precise Zero-Shot Dense Retrieval without Relevance Labels, Gao et al. 2022): invece di cercare con l’embedding della domanda, genera prima una risposta ipotetica con un modello leggero (Claude Haiku), poi usa l’embedding di quella risposta per il retrieval. La risposta ipotetica è nello stesso spazio semantico dei documenti indicizzati.

# Esempio HyDE in azione

Query utente:  "prezzi?"

Risposta ipotetica generata da Haiku:
"I piani di Chips Builder partono da €9/mese per il piano Base
 con un sito incluso, fino al piano Pro a €39/mese con siti
 illimitati, analytics avanzate e addon premium..."

# L'embedding di questa risposta è molto più vicino
# ai documenti della KB dell'Esperto Piani
text

ChipsBot attiva HyDE solo se il punteggio di Stage 1 supera un floor minimo (indica che la query è nel dominio giusto, anche se sotto soglia) e la query è breve (le query lunghe di solito hanno già abbastanza contesto per il retrieval diretto). Entrambi i parametri sono configurabili.

Stage 3: LLM fallback

Se anche HyDE non trova un match, il routing è affidato a un LLM che legge la domanda in linguaggio naturale e sceglie lo specialista. È il metodo più costoso (una chiamata LLM extra) ma copre i casi edge: domande ambigue, cross-dominio, off-topic.

In pratica, Stage 3 è utile anche come segnale diagnostico: un’alta percentuale di routing via LLM indica che le knowledge base degli specialisti non sono indicizzate correttamente, o che mancano specialisti per domini frequenti.

RAG L2: chunk injection per specialista

Una volta scelto lo specialista, si pone un secondo problema: cosa iniettare nel contesto della risposta?

L’approccio più semplice è iniettare l’intero prompt della knowledge base. Funziona bene per KB piccole (<2KB). Ma per KB grandi — uno specialista Template con 50 paragrafi che descrivono 15 template diversi — iniettare tutto è rumoroso e costoso: il modello riceve molto contesto irrilevante, e il fenomeno “lost in the middle” si manifesta anche a livello di singolo specialista.

ChipsBot risolve questo con il RAG L2 (RAG di secondo livello): invece di iniettare la KB completa, seleziona a runtime i top-K chunk più rilevanti alla specifica domanda, tramite la stessa cosine similarity già usata per il routing.

Il risultato: il modello riceve solo il contesto strettamente rilevante. Per KB grandi (5KB+) questo riduce i token di input, migliora la qualità della risposta e abbassa i costi.

Strategia di chunking e parametri

Prima del retrieval, la knowledge base di ogni specialista viene suddivisa in chunk e indicizzata nel vector database. La qualità del chunking influenza direttamente la qualità del retrieval: chunk troppo grandi diluiscono il segnale semantico; chunk troppo piccoli perdono il contesto.

I parametri configurabili per-bot:

• Chunk size — dimensione massima in caratteri per chunk (default: 512). Con overlap, i chunk consecutivi si sovrappongono per non spezzare concetti a metà.
• Chunk overlap — caratteri condivisi tra chunk consecutivi (default: 64). Riduce il rischio di perdere informazioni al confine tra chunk.
• Top-K — numero di chunk iniettati per risposta (default: 3, range: 1–10). Per specialisti con KB grandi e domande complesse, aumentare a 5.

Modificare chunk size o overlap forza automaticamente la re-indicizzazione di tutti i chunk dello specialista, perché i confini cambiano e gli embedding precedenti non sono più validi.

System instructions: contesto fisso + chunk dinamici

Con RAG L2 attivo, il contesto iniettato allo specialista è solo quello dei chunk selezionati. Ma alcuni comportamenti devono essere sempre presenti, indipendentemente dalla domanda: il tono, la lingua, le regole di sicurezza (“non inventare”, “non rivelare dettagli interni”).

Le System Instructions sono un blocco di testo breve iniettato sempre nel contesto, prima dei chunk dinamici. Separano le istruzioni comportamentali (fisse) dalla conoscenza di dominio (dinamica via RAG L2). Esempio:

# System Instructions (sempre iniettate)
Sei l'Esperto Template di Chips Builder.
Rispondi SOLO a domande sui template e la personalizzazione dei siti.
Tono: informale, diretto, con esempi concreti.
MAI rivelare dettagli tecnici interni (framework, stack, deploy).

# Contesto rilevante (chunk selezionati da RAG L2)
## Contesto rilevante
[chunk 1: descrizione template Ristorante Light]
[chunk 2: guida scelta template per ristorazione]
[chunk 3: menu QR code setup]
text

ChipsBot in pratica

ChipsBot è l’implementazione concreta di questa architettura, costruita su bot.chipsbuilder.com. Vediamo i dettagli pratici.

Gli 11 specialisti collegati

L’orchestratore ChipsBuilder ha attualmente 11 specialisti connessi, ciascuno con knowledge base, prompt e configurazione RAG dedicata:

Tutti gli specialisti hanno RAG L2 abilitato con top-K=3. L’orchestratore usa un modello diverso (Claude Sonnet) per il routing LLM fallback, più capace nella classificazione dell’intento.

Connessioni bot-to-bot dinamiche

Una delle caratteristiche più interessanti dell’architettura è la modularità dinamica. Gli specialisti possono essere collegati e scollegati dall’orchestratore a runtime. Quando un nuovo specialista viene creato, basta “collegarlo” con un ruolo (es. analytics-expert) e una descrizione — l’orchestratore lo vede immediatamente nella sua lista e inizia a instradare domande rilevanti.

Questo è gestito da un’API dedicata (disponibile anche tramite MCP per integrazione con strumenti esterni).

Debug in tempo reale

Durante lo sviluppo, il widget espone un pannello di debug che mostra esattamente cosa è successo per ogni risposta:

● Esperto Template

L1  rag  0.68   hyde: —
       # routing via RAG diretto, score 0.68, HyDE non necessario

L2  cosine
    #1  0.68   342c  ▼
    #2  0.61   289c  ▼
    #3  0.55   412c  ▼
       # 3 chunk iniettati, con score e dimensione in caratteri
text

Il prefisso L1 indica il metodo di routing usato (rag, hyde, llm) e il punteggio. L2 mostra i chunk selezionati con score e dimensione. Questo rende visibile ogni decisione del sistema, utile per diagnosticare errori di routing o KB mal calibrate.

Configurabilità per-bot

Tutti i parametri del sistema RAG sono configurabili per singolo bot dalla dashboard, senza deploy:

• Soglia di routing — il punteggio minimo per Stage 1 e Stage 2 (0.05–0.95)
• Chunk size e overlap — dimensione e sovrapposizione dei chunk; modifica forza re-indicizzazione
• HyDE on/off — abilita o disabilita Stage 2
• HyDE word limit — lunghezza massima della query per attivare HyDE (query lunghe già hanno contesto sufficiente)
• RAG L2 on/off — abilita o disabilita la chunk injection per risposta
• Top-K chunks — numero di chunk da iniettare (1–10)
• System instructions — testo fisso sempre presente nel contesto, indipendentemente dai chunk
• Debug level — 0 (produzione), 1 (routing score), 2 (routing + chunk detail)

La separazione tra parametri di routing (soglia, HyDE) e parametri di risposta (L2, top-K, system instructions) riflette le due fasi distinte del sistema. Si possono ottimizzare indipendentemente.

Lezioni apprese

Il routing è critico — e più sottile di quanto sembra

Un sistema con specialisti perfetti ma routing sbagliato fallisce. Le lezioni specifiche sul routing:

• La qualità degli embedding dipende dalla configurazione — vettori calcolati con modelli o task diversi non sono confrontabili. Tenere traccia del modello usato per ogni indicizzazione.
• HyDE è potente ma ha un costo — ogni attivazione di HyDE è una chiamata LLM. Calibrare il floor score per non sprecare chiamate su domande off-topic.
• LLM fallback alto è un segnale — se l’80% del routing passa per Stage 3, le KB degli specialisti non sono indicizzate correttamente o mancano domini coperti.
• Il threshold va calibrato empiricamente — 0.40 è un punto di partenza. Il valore giusto dipende dalla distribuzione degli score nel tuo caso specifico.

Come dividere la conoscenza

• Regola del singolo esperto — se un umano esperto potrebbe rispondere a tutte le domande di uno specialista senza consultare colleghi, il dominio è ben definito
• KB snella e strutturata — meglio 20 paragrafi semanticamente densi che 200 generici. Con RAG L2, solo i chunk rilevanti vengono usati — ma chunk di scarsa qualità abbassano la similarità e non vengono selezionati
• Aggiornamento continuo — le query fallite sono la miglior fonte per migliorare la KB. Se gli utenti chiedono cose che lo specialista non sa rispondere, aggiungi quell’informazione con il vocabolario che gli utenti usano realmente

Quando usare un bot vs molti specialisti

Strumenti per creare sistemi simili

Approccio piattaforma

ChipsBot implementa nativamente il pattern orchestratore + specialisti con routing semantico, HyDE e RAG L2. Permette di creare un chatbot, caricare knowledge base, configurare tutti i parametri RAG e connettere bot tra loro — tutto senza scrivere codice.

Approccio custom

Per chi vuole il controllo totale, gli stessi concetti si implementano con:

• LangGraph — routing come grafo con nodi-specialista e archi condizionali
• CrewAI — ogni specialista è un agente con ruolo e strumenti
• Anthropic Agent SDK — handoff nativo tra agenti, tool use e guardrails, integrato con MCP
• pgvector + qualsiasi embedding model — per implementare il routing RAG custom

Implementazione pratica: passo dopo passo

Step 1: Mappa i domini

Analizza le conversazioni esistenti (email di supporto, ticket) e categorizza per dominio. Identifica i 3–5 domini principali che coprono l’80% delle richieste.

Step 2: Crea il primo specialista

Inizia con il dominio più frequente. Costruisci la knowledge base con paragrafi semanticamente densi — usa il vocabolario che gli utenti usano realmente nelle domande, non solo il gergo interno. Testa con 20–30 domande reali.

Step 3: Calibra il routing

Con i primi specialisti online, analizza gli score L1 nelle risposte reali (debug level 1 o 2). Trova il threshold che separa match buoni da match casuali. Tipicamente 0.35–0.45 per testi in italiano con Jina v3.

Step 4: Aggiungi specialisti gradualmente

Un specialista alla volta. Dopo ogni aggiunta, verifica che il routing non regredisca sugli specialisti esistenti: domande che prima andavano correttamente non devono essere deviate al nuovo arrivato.

Step 5: Ottimizza le KB per RAG L2

Con RAG L2 attivo, la struttura della KB conta. Paragrafi separati da una riga vuota diventano unità semantiche distinte. Ogni paragrafo deve avere un concetto principale. Verifica con il debug level 2 che i chunk selezionati siano effettivamente rilevanti alle domande reali.

Riflessioni finali

L’architettura a orchestratore e specialisti aggiunge complessità: più componenti, più parametri, più punti di fallimento. Ma per sistemi che devono coprire più domini con profondità, è l’approccio che scala meglio.

Le lezioni chiave da ChipsBot:

1. Specializza presto — non aspettare che il monolite diventi ingestibile
2. Il routing semantico è più scalabile del routing LLM — ma richiede embedding ben calibrati e soglie testate empiricamente
3. RAG L2 è utile per KB grandi — per KB piccole (<2KB) l’overhead non vale il guadagno
4. KB > prompt — un prompt mediocre con KB eccellente batte un prompt perfetto con KB scarsa
5. Il debug visivo è indispensabile — senza vedere score e chunk a runtime, ottimizzare un sistema RAG multi-agente è lavoro cieco

Risorse correlate

• RAG — fondamenti del retrieval augmented generation, embedding e vector search
• Orchestrazione & Agenti — pattern multi-agente, hub-and-spoke, handoff
• Prompt Engineering — come scrivere i prompt per orchestratore e specialisti
• MCP — come connettere gli specialisti a tool e dati esterni
• Modelli AI — context window, lost in the middle, scelta del modello per ruolo
• ChipsBot — la piattaforma per creare chatbot intelligenti senza codice
• ChipsBuilder — il creatore di siti web AI che integra nativamente ChipsBot