Caso Studio: ChipsBot

Il problema della specializzazione nell'AI

Immagina di costruire un chatbot per un'azienda con più prodotti: una piattaforma di website building, un sistema di fatturazione, un CMS per contenuti, un supporto tecnico. L'approccio istintivo è creare un unico chatbot monolitico con un prompt gigante che copre tutto.

Questo approccio fallisce per motivi strutturali:

• Context window limitata — anche con 200K token, un prompt che copre 5 domini diventa enorme. Ogni dominio ha la sua documentazione, le sue FAQ, i suoi flussi. Il modello perde efficacia quando il contesto è troppo disperso (il fenomeno "lost in the middle" descritto nella sezione Modelli AI).
• Conflitto di istruzioni — regole diverse per domini diversi possono contraddirsi. Il tono per il supporto tecnico (preciso, step-by-step) è diverso da quello per il marketing (entusiasta, orientato alla vendita).
• Aggiornamento costoso — modificare la knowledge base di un dominio richiede di ri-testare l'intero sistema. Un aggiornamento ai prezzi può rompere le risposte sulla fatturazione.
• Impossibilità di ottimizzare — non puoi usare un modello piccolo e veloce per le FAQ semplici e uno grande per il supporto tecnico complesso. È 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 che usiamo nelle organizzazioni umane: specializzazione + coordinamento.

Architettura a Orchestratore e Specialisti

Il pattern che risolve questo problema è l'architettura a orchestratore e specialisti (o "hub-and-spoke", descritto nella sezione Orchestrazione). Il concetto è semplice:

1. Un orchestratore riceve ogni richiesta dell'utente
2. Analizza l'intento (di cosa si tratta? quale dominio?)
3. Instrada la richiesta allo specialista più adatto
4. Lo specialista risponde con la sua conoscenza specifica
5. L'orchestratore può arricchire o formattare la risposta prima di restituirla

Decomposizione per dominio

Il primo passo è definire i confini di ogni specialista. La regola è: ogni specialista copre un'area di competenza che un esperto umano potrebbe coprire. Se un umano specializzato in fatturazione non saprebbe rispondere a una domanda tecnica su DNS, allora quelle sono aree diverse.

Criteri per la decomposizione:

• Coerenza della knowledge base — tutti i documenti dello specialista devono parlare dello stesso dominio
• Frequenza di aggiornamento — domini che cambiano spesso (prezzi, promozioni) dovrebbero essere separati da quelli stabili (documentazione tecnica)
• Tono e stile — se il dominio richiede un tono diverso, è un buon candidato per uno specialista separato
• Volume di query — domini con molte query meritano specialisti dedicati per ottimizzazione

Knowledge base per specialista

Ogni specialista ha il suo contesto dedicato e isolato. Questo significa:

• Un system prompt specifico con le regole del dominio
• Una knowledge base con documenti, FAQ, procedure rilevanti solo a quel dominio
• Un set di esempi (few-shot) calibrato per il tipo di domande che riceverà
• Opzionalmente, un modello diverso (Haiku per FAQ semplici, Sonnet per analisi tecniche)

Prompt modulari: struttura di uno specialista

Ogni specialista è definito da un prompt modulare. La struttura tipica (vedi anche Prompt Engineering):

# Struttura del prompt di uno specialista

SPECIALIST_PROMPT = """
# Ruolo
Sei lo specialista {domain_name} di {company}.
Il tuo compito è rispondere a domande su: {scope_description}.

# Knowledge Base
{knowledge_base_content}

# Regole specifiche del dominio
{domain_rules}

# Regole comuni (condivise tra tutti gli specialisti)
- Rispondi SEMPRE in italiano
- Se non conosci la risposta, dillo chiaramente
- Non inventare informazioni
- Mantieni un tono {tone} (es. professionale, amichevole, tecnico)
- Cita le fonti quando possibile

# Formato
{output_format}

# Limiti
NON rispondere a domande che esulano dal tuo dominio.
Se la domanda riguarda {other_domains}, rispondi:
"Questa domanda riguarda un altro ambito. Fammi chiedere al collega giusto."
"""text

La potenza di questo approccio è la composizione: le regole comuni sono condivise (DRY), mentre il contesto specifico è isolato. Aggiornare la knowledge base di un singolo specialista non tocca gli altri.

Come ChipsBot implementa questo pattern

ChipsBot è un'implementazione concreta dell'architettura orchestratore + specialisti, costruita sulla piattaforma bot.chipsbuilder.com. Vediamo come traduce i concetti teorici in pratica.

L'orchestratore in pratica

L'orchestratore di ChipsBot è un bot con un prompt progettato specificamente per il routing. Non risponde direttamente alle domande — il suo unico compito è capire cosa l'utente sta chiedendo e decidere quale specialista può aiutare.

# Pseudo-struttura del prompt dell'orchestratore

ORCHESTRATOR_PROMPT = """
# Ruolo
Sei il coordinatore del team di supporto.
NON rispondi direttamente alle domande.
Il tuo compito è analizzare la richiesta e instradarla.

# Specialisti disponibili
- billing_bot: piani, prezzi, fatturazione, pagamenti, crediti
- tech_bot: problemi tecnici, DNS, SSL, deployment, errori
- template_bot: scelta template, personalizzazione, design
- general_bot: domande generali sulla piattaforma, onboarding

# Processo di routing
1. Leggi il messaggio dell'utente
2. Identifica il dominio principale
3. Se ambiguo, chiedi chiarimento
4. Instrada allo specialista corretto

# Output
Rispondi con JSON:
{"route_to": "billing_bot", "reason": "Domanda sui prezzi del piano Pro"}
"""text

In realtà, il routing può essere implementato anche in modo più sofisticato: con classificazione basata su embedding (veloce, senza LLM call per il routing), con keyword matching per i casi ovvi, o con un approccio ibrido.

Gli specialisti in azione

Ogni specialista in ChipsBot ha:

• La propria knowledge base — documenti caricati specifici per il dominio. Lo specialista Billing conosce i piani, i prezzi, le regole di fatturazione. Lo specialista Tech conosce l'architettura, i comandi, le procedure di troubleshooting.
• Il proprio prompt ottimizzato — calibrato nel tono e nelle istruzioni per il dominio. Lo specialista Billing è orientato alla vendita, quello Tech è preciso e step-by-step.
• La propria "personalità" — ogni specialista può avere un nome, uno stile di comunicazione, persino emoji o espressioni caratteristiche. Questo rende l'esperienza più naturale.

Connessioni bot-to-bot

Una delle caratteristiche più interessanti dell'architettura è la modularità dinamica. Gli specialisti possono essere:

• Connessi e disconnessi dinamicamente dall'orchestratore. Se un dominio non è ancora coperto, l'orchestratore lo sa e informa l'utente. Quando un nuovo specialista viene creato, basta "collegarlo" all'orchestratore.
• Condivisi tra orchestratori — uno specialista Billing può essere usato da più chatbot di aziende diverse, ciascuno con la propria configurazione di prezzi e piani.
• Aggiornati indipendentemente — modificare la knowledge base dello specialista Template non impatta il funzionamento dello specialista Billing. Questo è cruciale in produzione.

Creazione specialisti senza codice

Un vantaggio significativo dell'approccio piattaforma è che la creazione di nuovi specialisti non richiede codice:

1. Crea il bot sulla piattaforma (nome, descrizione, modello AI)
2. Definisci il prompt con le istruzioni specifiche del dominio
3. Carica i documenti della knowledge base (PDF, Markdown, testo)
4. Collega all'orchestratore con una connessione bot-to-bot
5. Testa con domande reali e affina il prompt

Questo ciclo può essere completato in ore, non in settimane. E la persona che lo fa non deve necessariamente essere uno sviluppatore — basta che conosca il dominio.

Analytics per specialista

Un sistema multi-agente genera dati preziosi che un monolitico non può:

• Distribuzione delle query — quale specialista riceve più richieste? Se il 60% va al Billing bot, forse serve più contenuto self-service sulla pagina prezzi.
• Tasso di soddisfazione per dominio — gli utenti sono più soddisfatti delle risposte tecniche o di quelle commerciali?
• Query non instradate — domande che l'orchestratore non sa dove mandare rivelano domini non coperti.
• Handoff rate — quante volte un utente viene passato da uno specialista all'altro? Un tasso alto indica confini mal definiti.

Lezioni apprese e best practices

Come dividere la conoscenza efficacemente

La divisione della knowledge base è più arte che scienza. Alcune regole emerse dalla pratica:

• Regola del "singolo esperto" — se un umano esperto potrebbe rispondere a tutte le domande di uno specialista senza consultare colleghi, il dominio è ben definito
• Overlap controllato — è OK avere un po' di overlap tra specialisti (es. entrambi conoscono i nomi dei piani), purché non si contraddicano
• Knowledge base snella — meglio 20 documenti precisi che 200 generici. La qualità della knowledge base è più importante della quantità
• Aggiornamento continuo — le query fallite sono la miglior fonte per migliorare la KB. Se gli utenti chiedono cose che lo specialista non sa, aggiungi quell'informazione

Quando usare un bot vs molti specialisti

Mantenere la consistenza tra specialisti

Il rischio con più specialisti è l'incoerenza: lo specialista Billing dice che il piano costa 49 euro, quello Template dice 39. Strategie:

• Regole comuni condivise — un set di istruzioni di base (tono, lingua, formato) uguali per tutti
• Single source of truth — i dati fattuali (prezzi, feature, limiti) devono essere in un unico posto, referenziato da tutti gli specialisti
• Test cross-specialista — domande che toccano più domini devono dare risposte coerenti indipendentemente da chi risponde
• Review periodiche — verificare mensilmente che le knowledge base siano allineate

Gestione degli edge case

Cosa succede quando una query attraversa più domini? "Voglio cambiare il template del mio sito e capire se col nuovo piano posso avere più pagine" tocca sia Template che Billing.

Strategie:

• Decomposizione — l'orchestratore scompone la query in sotto-domande e instrada ciascuna allo specialista giusto, poi compone la risposta
• Specialista primario — instrada allo specialista più rilevante, che ha abbastanza contesto per una risposta parziale e suggerisce di approfondire con l'altro
• Fallback al generalista — per query ambigue, un bot generalista con conoscenza superficiale di tutti i domini

Monitoring e miglioramento continuo

Un sistema multi-agente in produzione richiede monitoring attivo:

• Dashboard per specialista — volume, latenza, soddisfazione, errori per ogni bot
• Alert su anomalie — se un specialista inizia a ricevere molte più query del solito, potrebbe indicare un problema (es. bug nel prodotto che genera richieste di supporto)
• Feedback loop — le conversazioni con rating negativo vanno revisionate e usate per migliorare prompt e KB
• A/B testing dei prompt — testare varianti del prompt sullo stesso specialista per migliorare le risposte

Strumenti per creare sistemi simili

ChipsBot è un'implementazione specifica, ma i concetti si applicano a qualsiasi stack. Ecco le opzioni:

Approccio piattaforma

ChipsBot è una piattaforma che implementa nativamente il pattern orchestratore + specialisti. Permette di creare un chatbot per il proprio sito web, caricare knowledge base, definire prompt e connettere bot tra loro — tutto senza scrivere codice. Ideale per chi vuole creare un chatbot senza codice e ottenere risultati rapidi, anche senza competenze tecniche avanzate.

Approccio custom

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

• LangGraph — definisci il routing come un grafo con nodi-specialista e archi condizionali. Massima flessibilità, richiede più codice
• CrewAI — ogni specialista è un "agente" con ruolo e strumenti. L'orchestrazione è gestita dal framework
• Anthropic Agent SDK — supporta nativamente handoff tra agenti, tool use e guardrails. Integrato con MCP
• Soluzione custom — un semplice loop Python con classificazione dell'intento e routing. Per sistemi semplici, non serve un framework

Confronto: piattaforma vs DIY

Implementazione pratica: passo dopo passo

Ecco come costruire un sistema orchestratore + specialisti da zero, indipendentemente dallo strumento scelto:

Step 1: Mappa i domini

Analizza le conversazioni esistenti (email di supporto, ticket, chat) 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, scrivi il prompt, testa con 20-30 domande reali. Itera fino a quando il 90% delle risposte è soddisfacente.

Step 3: Aggiungi l'orchestratore

Con un solo specialista, l'orchestratore sembra superfluo. Ma è il momento giusto per definire il pattern di routing. Quando aggiungerai lo specialista #2, l'infrastruttura sarà già pronta.

Step 4: Scala gradualmente

Aggiungi uno specialista alla volta. Dopo ogni aggiunta, verifica che il routing funzioni correttamente e che non ci siano regressioni sugli specialisti esistenti.

Step 5: Monitora e ottimizza

In produzione, monitora le metriche per specialista. Le query non instradate ti dicono dove servono nuovi specialisti. Le query instradate male ti dicono dove il routing va migliorato.

Riflessioni finali

L'architettura a orchestratore e specialisti non è una silver bullet. Aggiunge complessità: più componenti da gestire, più prompt da mantenere, 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. Se hai più di 2 domini, considera la specializzazione
2. Knowledge base > prompt — un prompt mediocre con una KB eccellente batte un prompt perfetto con KB scarsa
3. Il routing è critico — un sistema con specialisti perfetti ma routing sbagliato fallisce. Investi nel routing
4. Testa in produzione — le domande reali degli utenti sono sempre più creative di quelle che immagini
5. Itera velocemente — il vantaggio della modularità è che puoi migliorare un pezzo alla volta senza rischiare tutto

Risorse correlate

• Orchestrazione & Agenti — i fondamenti teorici dei sistemi multi-agente
• Prompt Engineering — come scrivere i prompt per orchestratore e specialisti
• RAG — come costruire le knowledge base degli specialisti
• MCP — come connettere gli specialisti a tool e dati esterni
• ChipsBot — la piattaforma per creare chatbot intelligenti senza codice
• ChipsBuilder — il creatore di siti web AI che integra nativamente ChipsBot