Il cliente moderno ha una sola esigenza importante: ottenere la cosa vogliono quando lo vogliono. Il vecchio modello RAG customary incorpora+recupera+LLM fraintende le intenzioni, sovraccarica il contesto e perde la freschezza, indirizzando ripetutamente i clienti lungo la strada sbagliata.
Invece, l’architettura intent-first utilizza un modello linguistico leggero per analizzare la question per intento e contesto, prima di consegnarla alle fonti di contenuto più rilevanti (documenti, API, persone).
L’intelligenza artificiale aziendale è un treno in corsa diretto verso un precipizio. Le organizzazioni stanno implementando applicazioni di ricerca basate su LLM a un ritmo file, mentre un problema architettonico fondamentale sta predisponendo la maggior parte delle soluzioni al fallimento.
Lo ha rivelato un recente studio Coveo Il 72% delle query di ricerca aziendali fallisce di fornire risultati significativi al primo tentativo, mentre Gartner prevede anche che la maggior parte delle implementazioni di intelligenza artificiale conversazionale non sono state all’altezza delle aspettative aziendali.
Il problema non sono i modelli sottostanti. È l’architettura che li circonda.
Dopo aver progettato e gestito piattaforme di interazione con i clienti basate sull’intelligenza artificiale su larga scala, servendo milioni di clienti e cittadini utenti in alcune delle più grandi organizzazioni di telecomunicazioni e assistenza sanitaria del mondo, sono arrivato a vedere uno schema. È la differenza tra implementazioni di interazione basate sull’intelligenza artificiale di successo e fallimenti multimilionari.
È nativo del cloud architettura modello che chiamo L’intento innanzitutto. E sta rimodellando il modo in cui le aziende creano esperienze basate sull’intelligenza artificiale.
Il problema del passeggero da 36 dollari
Gartner prevede che il mercato globale dell’intelligenza artificiale conversazionale crescerà a dismisura 36 miliardi di dollari entro il 2032. Le imprese fanno a gara per accaparrarsene una fetta. Le demo sono irresistibili. Collega il tuo LLM alla tua data base e all’improvviso sarà in grado di rispondere alle domande dei clienti in linguaggio naturale.Magia.
Quindi avviene la produzione.
Un importante fornitore di telecomunicazioni con cui lavoro ha implementato un sistema RAG con l’aspettativa di ridurre la tariffa delle chiamate di supporto. Invece il tasso è aumentato. I chiamanti hanno provato la ricerca basata sull’intelligenza artificiale, hanno ricevuto risposte errate con un alto grado di sicurezza e hanno chiamato l’assistenza clienti più arrabbiata di prima.
Questo schema viene ripetuto più e più volte. Nel settore sanitario, gli assistenti AI a contatto con i clienti forniscono ai pazienti informazioni sui formulari out of date di settimane o mesi. I chatbot dei servizi finanziari stanno fornendo risposte sia dai contenuti dei prodotti al dettaglio che da quelli istituzionali. I rivenditori vedono i prodotti fuori produzione emergere nelle ricerche di prodotto.
Il problema non è un fallimento della tecnologia AI. È un fallimento dell’architettura
Perché le architetture RAG customary falliscono
Il modello RAG customary (incorporamento della question, recupero di contenuti semanticamente simili e passaggio a un LLM) funziona magnificamente nelle demo e nelle show di concetti. Ma cade a pezzi nei casi d’uso di produzione per tre ragioni sistematiche:
1. Il divario di intenti
L’intento non è il contesto. Ma le architetture RAG customary non tengono conto di questo.
Supponiamo che un cliente digiti “Voglio annullare”. Cosa significa? Annullare un servizio? Annullare un ordine? Cancellare un appuntamento? Durante la nostra implementazione delle telecomunicazioni, abbiamo riscontrato che il 65% delle richieste di “annullamento” riguardavano in realtà ordini o appuntamenti, non l’annullamento del servizio. Il sistema RAG non aveva modo di comprendere questo intento, quindi restituiva costantemente i documenti di annullamento del servizio.
L’intento conta. Nel settore sanitario, se un paziente digita “Devo annullare” perché sta tentando di annullare un appuntamento, una nuova prescrizione o una procedura, indirizzarlo al contenuto del farmaco dalla programmazione non è solo frustrante, ma anche pericoloso.
2. Alluvione del contesto
La conoscenza e l’esperienza aziendale sono vaste e abbracciano decine di fonti quali cataloghi di prodotti, fatturazione, articoli di supporto, politiche, promozioni e dati sugli account. I modelli RAG customary trattano tutto allo stesso modo, cercando tutto per ogni question.
Quando un cliente chiede “Come posso attivare il mio nuovo telefono”, non si preoccupa delle domande frequenti sulla fatturazione, dell’ubicazione dei negozi o degli aggiornamenti sullo stato della rete. Ma un modello RAG customary recupera contenuti semanticamente simili da ogni fonte, restituendo risultati di ricerca che sono a metà passo dal bersaglio.
3. Punto cieco della freschezza
Lo spazio vettoriale è cieco nel tempo. Semanticamente, la promozione dell’ultimo trimestre è identica a quella di questo trimestre. Ma presentare ai clienti offerte out of date distrugge la fiducia. Abbiamo collegato una percentuale significativa di reclami dei clienti ai risultati di ricerca che mostravano prodotti, offerte o funzionalità scaduti.
Il modello di architettura Intent-First
Il modello di architettura Intent-First è l’immagine speculare della distribuzione RAG customary. Nel modello RAG, si recupera e quindi si instrada. Nel modello Intent-First, classifichi prima di instradare o recuperare.
Le architetture Intent-First utilizzano un modello linguistico leggero per analizzare una question in termini di intento e contesto, prima di inviarla alle fonti di contenuto più rilevanti (documenti, API, agenti).
Confronto: RAG intent-first vs customary
Implementazione nativa del cloud
Il modello Intent-First è progettato per l’implementazione nativa del cloud, sfruttando microservizi, containerizzazione e scalabilità elastica per gestire i modelli di traffico aziendale.
Servizio di classificazione degli intenti
Il classificatore determina l’intento dell’utente prima che avvenga qualsiasi recupero:
ALGORITMO: Classificazione degli intenti
INPUT: user_query (stringa)
OUTPUT: intent_result (oggetto)
1. Question PREPROCESSO (normalizza, espandi contrazioni)
2. CLASSIFICARE utilizzando il modello del trasformatore:
– intento_primario ← mannequin.predict(question)
– fiducia ← mannequin.confidence_score()
3. SE confidenza < 0,70 ALLORA
– RITORNO {
richiede_chiarimento: vero,
domanda_suggerita: generate_clarifying_question(question)
}
4. EXTRACT sub_intent in base a primario_intent:
– IF primario = “ACCOUNT” → controlla ORDER_STATUS, PROFILE, ecc.
– IF primario = “SUPPORT” → controlla DEVICE_ISSUE, NETWORK, ecc.
– SE primario = “FATTURAZIONE” → verificare PAGAMENTO, CONTROVERSIA, ecc.
5. DETERMINARE target_sources in base alla mappatura degli intenti:
-STATO_ORDINE → [orders_db, order_faq]
– PROBLEMA_DISPOSITIVO → [troubleshooting_kb, device_guides]
– FARMACI → [formulary, clinical_docs] (assistenza sanitaria)
6. RITORNO {
intento_primario,
sottointento,
fiducia,
origini_destinazione,
richiede_personalizzazione: vero/falso
}
Servizio di recupero sensibile al contesto
Una volta classificato l’intento, il recupero diventa mirato:
ALGORITMO: recupero sensibile al contesto
INPUT: question, intento_risultato, utente_contesto
OUTPUT: documenti_classificati
1. OTTIENI source_config per intent_result.sub_intent:
– fonti_primarie ← fonti da cercare
– sorgenti_escluse ← fonti da saltare
– giorni_freschezza ← età massima del contenuto
2. SE l’intento richiede la personalizzazione E l’utente è autenticato:
– RECUPERA account_context dal servizio account
– SE intento = ORDER_STATUS:
– RECUPERA ordini_recenti (ultimi 60 giorni)
– AGGIUNGI ai risultati
3. COSTRUISCI filtri di ricerca:
– tipi_di_contenuto ← solo fonti_primarie
– età_max ← freschezza_giorni
– contesto_utente ← contesto_account (se disponibile)
4. PER OGNI fonte IN fonti_primarie:
– documenti ← ricerca_vettoriale(question, sorgente, filtri)
– AGGIUNGI documenti ai risultati
5. VALUTARE ogni documento:
– punteggio_pertinenza ← somiglianza_vettore × 0,40
– recency_score ← freschezza_peso × 0,20
– punteggio_personalizzazione ← corrispondenza_utente × 0,25
– intent_match_score ← type_match × 0,15
– punteggio_totale ← SOMMA di cui sopra
6. CLASSIFICA per punteggio_totale discendente
7. RESTITUIRE i primi 10 documenti
Considerazioni specifiche per l’assistenza sanitaria
Nelle implementazioni sanitarie, il modello Intent-First embrace ulteriori garanzie:
Categorie di intenti sanitari:
-
Clinico: Domande sui farmaci, sintomi, istruzioni per la cura
-
Copertura: Prestazioni, autorizzazione preventiva, formulario
-
Pianificazione: Appuntamenti, disponibilità del fornitore
-
Fatturazione: Reclami, pagamenti, dichiarazioni
-
Account: Profilo, persone a carico, carte d’identità
Tutela critica: Le domande cliniche includono sempre dichiarazioni di non responsabilità e non sostituiscono mai la consulenza medica professionale. Il sistema indirizza domande cliniche complesse al supporto umano.
Gestione dei casi limite
I casi limite sono quelli in cui i sistemi falliscono. Il modello Intent-First embrace gestori specifici:
Parole chiave per il rilevamento della frustrazione:
-
Rabbia: “terribile”, “peggiore”, “odio”, “ridicolo”
-
Tempo: “ore”, “giorni”, “ancora in attesa”
-
Fallimento: “inutile”, “nessun aiuto”, “non funziona”
-
Escalation: “parla con una persona”, “persona reale”, “supervisor”
Quando viene rilevata la frustrazione, salta completamente la ricerca e indirizzati al supporto umano.
Applicazioni intersettoriali
Il modello Intent-First si applica ovunque le aziende implementino l’intelligenza artificiale conversazionale su contenuti eterogenei:
|
Industria |
Categorie di intenti |
Vantaggio chiave |
|
Telecomunicazioni |
Vendite, supporto, fatturazione, account, fidelizzazione |
Previene la classificazione errata “cancellata”. |
|
Assistenza sanitaria |
Clinica, copertura, pianificazione, fatturazione |
Separa il clinico dall’amministrativo |
|
Servizi finanziari |
Vendita al dettaglio, istituzionale, prestiti, assicurazioni |
Impedisce la miscelazione del contesto |
|
Vedere al dettaglio |
Prodotto, Ordini, Resi, Fedeltà |
Garantisce freschezza promozionale |
Risultati
Dopo aver implementato l’architettura Intent-First su piattaforme di telecomunicazioni e sanità:
|
Metrico |
Impatto |
|
Tasso di successo delle question |
Quasi raddoppiato |
|
Supportare le escalation |
Ridotto di oltre la metà |
|
È tempo di risolvere |
Ridotto circa il 70% |
|
Soddisfazione dell’utente |
Migliorato di circa il 50% |
|
Tasso di restituzione degli utenti |
Più che raddoppiato |
Il tasso di utenti che ritornano si è rivelato molto significativo. Quando la ricerca funziona, gli utenti tornano. Quando fallisce, abbandonano completamente il canale, aumentando i costi su tutti gli altri canali di supporto.
L’imperativo strategico
Il mercato dell’intelligenza artificiale conversazionale continuerà a registrare un’ipercrescita.
Ma le aziende che costruiscono e implementano le tipiche architetture RAG continueranno a fallire… ripetutamente.
L’intelligenza artificiale darà con sicurezza risposte sbagliate, gli utenti abbandoneranno i canali digitali per la frustrazione e i costi di supporto aumenteranno invece di diminuire.
Intent-First rappresenta un cambiamento fondamentale nel modo in cui le aziende devono progettare e costruire conversazioni con i clienti basate sull’intelligenza artificiale. Non si tratta di modelli migliori o di più dati. Si tratta di capire cosa vuole un utente prima di provare advert aiutarlo.
Quanto prima un’organizzazione si renderà conto di questo come un imperativo architetturale, tanto prima sarà in grado di ottenere i miglioramenti in termini di efficienza che questa tecnologia dovrebbe consentire. Quelli che non lo faranno cercheranno di capire perché i loro investimenti nell’intelligenza artificiale non hanno prodotto i risultati aziendali attesi per molti anni a venire.
La dimostrazione è semplice. La produzione è dura. Ma il modello del successo produttivo è chiaro: L’intento innanzitutto.
Sreenivasa Reddy Hulebeedu Reddy è un ingegnere informatico capo e un architetto aziendale
Benvenuto nella comunità VentureBeat!
Il nostro programma di visitor posting è il luogo in cui gli esperti tecnici condividono approfondimenti e forniscono approfondimenti neutrali e non conferiti su intelligenza artificiale, infrastruttura dati, sicurezza informatica e altre tecnologie all’avanguardia che plasmano il futuro dell’impresa.
Per saperne di più dal nostro programma di submit per gli ospiti e dai un’occhiata al nostro linee guida se sei interessato a contribuire con un tuo articolo!
