Il cliente non legge il catalogo, fa una domanda
Su un e-commerce la conversazione tipica non è «mostrami la sitemap». È «avete un cavo SATA?», «fate assistenza a domicilio?», «quanto costa l’hosting?», «c’è uno switch a 24 porte?». Il visitatore parla come parlerebbe al telefono. Il catalogo, invece, è una foresta di schede, categorie e URL.
Il chatbot TUA nasce per chiudere quel gap: un assistente floating sul sito, alimentato da TuaGate®, che conosce prodotti e servizi senza mandare l’intero magazzino al modello a ogni messaggio. Le tecniche descritte qui sono quelle in produzione sul nostro e-commerce: centinaia di schede indicizzate, FAQ istituzionali e un widget che si installa in pochi minuti su qualsiasi CMS basato su PHP e HTML.
Perché un LLM «nudo» non conosce il vostro shop
Un modello linguistico risponde bene su cultura generale. Sul vostro catalogo è cieco: non sa quali prodotti aveteline oggi, come si chiamano le categorie, quali servizi sono attivi, quali pagine sono la fonte di verità.
La soluzione non è un modello più grande. È un sistema di retrieval: prima si pescano le schede pertinenti, poi si chiede all’LLM di rispondere solo su quei fatti. È lo stesso principio del RAG sui PDF in sede, adattato al catalogo e-commerce e a un hosting PHP ordinario.
Tre tentazioni che vi suggeriamo di evitare:
- Incollare tutto il catalogo nel prompt — costa token, rallenta, e oltre qualche decina di schede il modello perde il filo.
- Lasciare che «inventi» il listino — prezzi, disponibilità e SLA allucinati distruggono fiducia più di un «non lo so, ecco il link».
- Dipendere da un chatbot SaaS sul catalogo — i dati del negozio escono verso un provider; su listini e clienti è spesso inaccettabile.
Come TUA «vede» l’intero catalogo
TUA non memorizza il negozio nei parametri del modello. Conosce il catalogo perché, a ogni domanda, recupera le schede giuste da una knowledge base locale e le inietta nel prompt di sistema.
Il catalogo può avere centinaia o migliaia di URL: al modello arrivano solo i pezzi che superano la soglia. Nel caso in produzione (dev74.com) sono oltre 650 schede prodotto più le FAQ di servizi, identità e contatti, ciò nonstante, il prompt resta piccolo, veloce e governabile.
Dalla sitemap alle schede corte
La fonte di verità del negozio è già pubblica per Google: le sitemap prodotto (titolo, URL, percorso di categoria). Uno script le scarica, estrae titolo e slug, ricava categoria/sottocategoria dal path e genera JSON di schede corte:
- Titolo — come compare in catalogo («Switch Fast Ethernet 24 porte…»).
- Keywords — token da slug, cartelle e titolo (sata, dlink, hosting, assistenza…).
- Body breve — nome, categoria, invito a consultare la scheda per prezzo e disponibilità.
- URL canonico — il link che TUA deve citare, non un indirizzo inventato.
Nel nostro caso le schede prodotto non includono il prezzo. È una scelta deliberata: il listino cambia, le promozioni anche, e un bot che cita un importo vecchio è peggio di un bot che manda alla pagina aggiornata. I prezzi documentati restano nelle FAQ di servizio, dove sono sotto controllo editoriale.
La tecnica: mini-RAG con BM25, non embedding
Sul sito vetrina o sull’e-commerce il vincolo è pratico: Apache + PHP, niente Python, niente Qdrant, niente modello di embedding da far girare a ogni hit. Per domande fatte di nomi di prodotto, marche, acronimi e servizi, un ranker lessicale è spesso più adatto e molto più economico di una ricerca semantica.
BM25 (Best Matching 25) pesa i termini della domanda rispetto a ogni scheda: parole rare nel catalogo valgono di più; titoli e keyword pesano più del corpo; le FAQ istituzionali hanno un boost, così «chi siete» e «come vi contatto» non vengono sommersi da 600 schede hardware.
| Aspetto | Catalogo intero nel prompt | Mini-RAG BM25 di TUA |
|---|---|---|
| Cosa vede il modello | Tutte le schede (o un riassunto vago) | Solo le top 4 pertinenti alla domanda |
| Costo token | Cresce con il catalogo | Quasi costante (contesto ~2600 caratteri) |
| Infrastruttura | Spesso un SaaS o un vector DB | JSON + PHP sul web server esistente |
| Allineamento al listino | Il modello «completa» i buchi | Prompt: usa solo il contesto; niente prezzi inventati |
| Mix prodotti / servizi | Un unico blob confuso | FAQ con boost + prodotti; ranking misto controllato |
Dettagli che fanno la differenza sulle domande reali dei clienti:
- Normalizzazione italiana: accenti, minuscole, stopword («vorrei», «avete», «informazioni») così resta il segnale utile: marca, modello, servizio.
- Pesi differenziati: titolo > keyword > corpo: «Galaxy S4» o «TeraMail» nel titolo battono una coincidenza debole in una descrizione.
- Match sul titolo intero: se la query compare nel titolo della scheda, lo score sale: è il caso «cerco esattamente questo prodotto».
- Soglia minima: sotto un punteggio di rilevanza non si inietta rumore: meglio un fallback («contattaci») che quattro schede sbagliate.
- Cap sui prodotti se c’è una FAQ calda: «assistenza a domicilio» non deve diventare un elenco di cavi SATA.
Quando serve ricerca semantica su PDF, contratti e manuali, il posto giusto resta il client TuaGPT® con embeddings locali, come spiegato nel pezzo sul RAG premise. Sul widget del sito, BM25 è la scelta giusta: veloce, spiegabile, installabile dove gira già lo shop.
Perché le risposte su prodotti e servizi funzionano
La qualità percepita dal cliente non è «il modello è intelligente». È: ha capito cosa chiedo, mi ha indicato la scheda giusta, non ha inventato un prezzo.
Prodotti del catalogo
Alla domanda su un articolo, TUA recupera titolo, categoria e URL. Il system prompt gli impone di citare la scheda del contesto e di mandare il visitatore alla pagina per listino e disponibilità. Il risultato tipico è una risposta breve, con link completo https://…, non un paragrafo da brochure generica.
Servizi e FAQ
Hosting, e-commerce, assistenza, cybersecurity, posta business: stanno in schede editoriali, con keyword del parlato reale («domicilio», «NAS», «preventivo»). Qui i fatti sono più ricchi e restano sotto controllo, non derivati in automatico dalla sitemap.
Guardrail anti-allucinazione
- Usa prioritariamente il blocco «contesto recuperato».
- Se il contesto non basta, lo dice e invita al contatto ufficiale.
- Non inventa prezzi, SLA, contratti o servizi non documentati.
- Quando c’è interesse commerciale, chiede un recapito nella chat senza fingere di averlo già.
È lo stesso contratto che TuaGate® impone in azienda: il modello genera il testo; la policy decide su quali fatti può generarlo. Ovviamente il widget non espone il bearer nel JavaScript, CSRF, rate limit per IP e CORS sul dominio dello shop, tengono il canale sotto controllo. L’inferenza passa da TuaGate®, API OpenAI-compatibile, utente dedicato, budget token, come nel gateway locale.
Versatilità di installazione: un widget, tre modi
TUA non chiede di rifare il sito. Si carica una cartella sul web server e si incolla uno snippet. Il backend resta PHP lo stesso stack di moltissimi e-commerce e vetrine.
| Ambiente | Come si integra |
|---|---|
| OpenCart, WooCommerce ecc.. | HTML puro nel Custom Code / Footer (Twig non esegue PHP: lo snippet è pensato per questo) |
| Sito HTML statico | Due tag: CSS + JS, con URL di chat e CSRF |
| Footer PHP | Un include del partial embed, se il template è davvero PHP |
Configurazione in un file PHP lato server: URL di TuaGate®, bearer dell’utente bot, modello, prompt, file di knowledge. Personalizzazione visiva (titolo «Sono Tua», logo, colori, messaggio di benvenuto, apertura automatica) nello snippet, senza toccare il core dello shop.
Opzioni operative già nel pacchetto, utili in produzione e non solo in demo:
- Streaming SSE: la risposta compare token per token, con fallback JSON se il gateway non streamma.
- Log sessioni in SQLite: conversazioni, IP, pagina di provenienza; pannello admin per rileggere i turni.
- Notifiche email: avvio chat e riepilogo dopo inattività, con eventuale recapito lasciato dal cliente.
Cosa cambia per chi vende prodotti o servizi
- Il catalogo parla la lingua del cliente: marche, modelli e servizi emergono anche se l’utente non conosce lo slug della scheda.
- Meno ticket «avete X?»: la chat chiude le domande di orientamento e lascia al commerciale i casi che contano.
- Link alla scheda giusta: TUA non sostituisce la scheda prodotto: la trova e vi accompagna l'utente.
- Servizi e prodotti nello stesso assistente: «cavo SATA» e «assistenza in Marche» convivono, con ranking che non li confonde.
- Installazione sul sito che avete già: niente migrazione, niente iframe di un vendor che tiene i vostri lead altrove.
- Governance: modello e budget su TuaGate®; knowledge e prompt sul vostro server; token mai nel browser.
Come portarlo sul vostro catalogo
- Esponete (o esportate) gli URL prodotto: sitemap, feed, CSV.
- Generate schede corte: titolo, categoria, keyword, URL senza prezzi volatili.
- Scrivete 10–20 FAQ sui servizi e sui contatti, con le parole che usano i clienti.
- Collegate il widget a un utente TuaGate® dedicato e a un modello adatto al supporto (chiaro, sintetico, in italiano).
- Incollate lo snippet in footer; provate 15 domande reali: SKU, sinonimi, «quanto costa», «dove siete».
- Tarate soglia BM25, top-k e boost FAQ finché i link in risposta coincidono con le schede che mostrereste voi al telefono.
Conclusione
TUA conosce l’intero catalogo perché non finge di averlo imparato: lo interroga. Sitemap → schede corte → BM25 → poche evidenze nel prompt → risposta via TuaGate®. È una pipeline che sta su un hosting PHP, si attacca ad un OpenCart o a una vetrina statica, e dà sul pezzo che conta in e-commerce: la domanda sul prodotto o sul servizio, con il link giusto e senza listini inventati.
La versatilità è nello snippet. Il risultato è nel retrieval. Il resto, streaming, sessioni, notifiche, policy anti-allucinazione, serve a far lavorare l’assistente come un collega del supporto, non come un generatore di testo sul negozio.
Commenti su «Chatbot TUA: conosce tutto il catalogo del tuo e-commerce»
Non ci sono ancora commenti. Scrivi il primo!
Lascia un commento
Non è necessario accedere. Il commento sarà pubblicato dopo approvazione.