De moderne klant heeft slechts één behoefte die ertoe doet: verkrijgen het ding zij willen wanneer ze het willen. Het oude standaard RAG-model insluiten+ophalen+LLM begrijpt de bedoeling verkeerd, overbelast de context en mist de frisheid, waardoor klanten herhaaldelijk op het verkeerde pad worden gestuurd.
In plaats daarvan maakt intent-first-architectuur gebruik van een lichtgewicht taalmodel om de vraag te ontleden op intentie en context, voordat deze aan de meest relevante inhoudsbronnen (documenten, API’s, mensen) wordt geleverd.
Enterprise AI is een snel rijdende trein die op weg is naar een klif. Organisaties implementeren op LLM gebaseerde zoekapplicaties in een recordtempo, terwijl een fundamenteel architectonisch probleem het meeste kans maakt op mislukking.
Dat blijkt uit een recent onderzoek van Coveo 72% van de zakelijke zoekopdrachten mislukt om bij de eerste poging betekenisvolle resultaten op te leveren, terwijl Gartner ook voorspelt dat de meerderheid van de conversationele AI-implementaties niet voldoet aan de verwachtingen van het bedrijfsleven.
Het probleem zijn niet de onderliggende modellen. Het is de architectuur om hen heen.
Nadat ik op grote schaal live AI-gestuurde klantinteractieplatforms heb ontworpen en uitgevoerd, waarmee miljoenen klant- en burgergebruikers bij enkele van ’s werelds grootste telecommunicatie- en gezondheidszorgorganisaties zijn bediend, ben ik een patroon gaan zien. Het is het verschil tussen succesvol zijn Implementaties van AI-aangedreven interactie en mislukkingen van meerdere miljoenen dollars.
Het is cloud-native architectuur patroon dat ik noem Intentie-eerst. En het verandert de manier waarop bedrijven AI-aangedreven ervaringen bouwen.
Het $36-passagiersprobleem
Gartner voorspelt dat de mondiale conversatie-AI-markt zal stijgen 36 miljard dollar in 2032. Bedrijven proberen een stukje te bemachtigen. De demo’s zijn onweerstaanbaar. Sluit uw LLM in uw kennisbanken opeens kan het vragen van klanten in natuurlijke taal beantwoorden. Magie.
Dan vindt de productie plaats.
Een grote telecommunicatieprovider waarmee ik samenwerk, heeft een RAG-systeem uitgerold met de verwachting dat dit het aantal oproepen voor ondersteuning zal verlagen. In plaats daarvan werd het tarief verhoogd. Bellers probeerden AI-gestuurd zoeken, kregen met een hoge mate van vertrouwen onjuiste antwoorden en belden de klantenondersteuning bozer dan voorheen.
Dit patroon herhaalt zich keer op keer. In de gezondheidszorg voorzien klantgerichte AI-assistenten patiënten van formulierinformatie die al weken of maanden verouderd is. Chatbots in de financiële dienstverlening spuwen antwoorden uit productinhoud van zowel retail als institutionelen. Retailers zien beëindigde producten verschijnen in productzoekopdrachten.
Het probleem is niet het falen van de AI-technologie. Het is een mislukking van de architectuur
Waarom standaard RAG-architecturen falen
Het standaard RAG-patroon – het inbedden van de zoekopdracht, het ophalen van semantisch vergelijkbare inhoud, overgaan naar een LLM —werkt prachtig in demo’s en proof-of-concepts. Maar het valt om drie systematische redenen uiteen in productiegebruiksscenario’s:
1. De intentiekloof
Intentie is geen context. Maar standaard RAG-architecturen houden hier geen rekening mee.
Zeg dat een klant typt: ‘Ik wil annuleren’. Wat betekent dat? Een dienst annuleren? Een bestelling annuleren? Afspraak annuleren? Tijdens onze telecommunicatie-implementatie ontdekten we dat 65% van de vragen over ‘annuleren’ feitelijk over bestellingen of afspraken ging, en niet over het annuleren van diensten. Het RAG-systeem kon deze bedoeling niet begrijpen en stuurde daarom consequent documenten voor annulering van de dienst terug.
Intentie is belangrijk. Als een patiënt in de gezondheidszorg ‘Ik moet annuleren’ typt omdat hij/zij een afspraak, een aanvullend recept of een procedure probeert te annuleren, is het niet alleen frustrerend om hem vanuit de planning naar medicatie-inhoud te leiden, maar ook gevaarlijk.
2. Contextoverstroming
De kennis en ervaring van ondernemingen is enorm en omvat tientallen bronnen, zoals productcatalogi, facturering, ondersteuningsartikelen, beleid, promoties en accountgegevens. Standaard RAG-modellen behandelen alles op dezelfde manier en doorzoeken alles voor elke zoekopdracht.
Wanneer een klant vraagt: “Hoe activeer ik mijn nieuwe telefoon”, interesseert hij zich niets van veelgestelde vragen over facturering, winkellocaties of updates van de netwerkstatus. Maar een standaard RAG-model haalt semantisch vergelijkbare inhoud uit elke bron en retourneert zoekresultaten die een halve stap er naast liggen.
3. Blinde vlek voor versheid
De vectorruimte is tijdblind. Semantisch gezien is de promotie van het afgelopen kwartaal identiek aan die van dit kwartaal. Maar klanten verouderde aanbiedingen aanbieden, schaadt het vertrouwen. We hebben een aanzienlijk percentage van de klachten van klanten gekoppeld aan zoekresultaten waarin verlopen producten, aanbiedingen of functies naar voren kwamen.
Het Intent-First-architectuurpatroon
Het Intent-First-architectuurpatroon is het spiegelbeeld van de standaard RAG-implementatie. In het RAG-model haal je op en routeer je. In het Intent-First-model classificeert u voordat u routeert of ophaalt.
Intent-First-architecturen gebruiken een lichtgewicht taalmodel om een query te ontleden op intentie en context, voordat deze naar de meest relevante inhoudsbronnen (documenten, API’s, agenten) wordt verzonden.
Vergelijking: Intent-first versus standaard RAG
Cloud-native implementatie
Het Intent-First-patroon is ontworpen voor cloud-native implementatie, waarbij gebruik wordt gemaakt van microservices, containerisatie en elastische schaling om bedrijfsverkeerspatronen af te handelen.
Intentieclassificatieservice
De classificator bepaalt de intentie van de gebruiker voordat er iets wordt opgehaald:
ALGORITME: Intentieclassificatie
INPUT: user_query (tekenreeks)
OUTPUT: intent_result (object)
1. PREPROCESS-query (normaliseren, samentrekkingen uitbreiden)
2. CLASSIFICEER met behulp van het transformatormodel:
– primaire_intentie ← model.predict(query)
– vertrouwen ← model.confidence_score()
3. ALS-vertrouwen
– OPBRENGST {
vereist_verduidelijking: waar,
voorgestelde_vraag: genereer_verhelderende_vraag(query)
}
4. EXTRACT sub_intent op basis van primaire_intent:
– ALS primair = “ACCOUNT” → controleer op ORDER_STATUS, PROFILE, enz.
– IF primair = “ONDERSTEUNING” → controleer op DEVICE_ISSUE, NETWORK, enz.
– ALS primair = “FACTUREER” → controleer op BETALING, GESCHIL, enz.
5. BEPALEN doelbronnen op basis van intentietoewijzing:
– ORDER_STATUS → (orders_db, order_faq)
– DEVICE_ISSUE → (probleemoplossing_kb, apparaatgidsen)
– MEDICATIE → (formularium, klinische_documenten) (gezondheidszorg)
6. RETOUR {
primaire_intentie,
sub_intentie,
vertrouwen,
doel_bronnen,
vereist_personalisatie: waar/onwaar
}
Contextbewuste ophaalservice
Zodra de intentie is geclassificeerd, wordt het ophalen gericht:
ALGORITME: Contextbewust ophalen
INPUT: vraag, intent_result, user_context
OUTPUT: gerangschikte_documenten
1. GET source_config voor intent_result.sub_intent:
– primaire_bronnen ← bronnen om te zoeken
– uitgesloten_bronnen ← bronnen om over te slaan
– versheidsdagen ← maximale leeftijd van de inhoud
2. ALS de intentie personalisatie vereist EN de gebruiker is geverifieerd:
– FETCH account_context van Accountservice
– ALS intentie = ORDER_STATUS:
– FETCH recente_bestellingen (laatste 60 dagen)
– TOEVOEGEN aan resultaten
3. BOUW zoekfilters:
– content_types ← alleen primaire_bronnen
– max_age ← versheidsdagen
– user_context ← account_context (indien beschikbaar)
4. VOOR ELKE bron IN primaire_bronnen:
– documenten ← vector_search(query, bron, filters)
– VOEG documenten toe aan resultaten
5. SCORE elk document:
– relevantie_score ← vector_similariteit × 0,40
– recentheid_score ← versheid_gewicht × 0,20
– personalisatie_score ← user_match × 0,25
– intent_match_score ← type_match × 0,15
– totale_score ← SOM van hierboven
6. RANG op basis van aflopende totale_score
7. RETOUR top 10 documenten
Zorgspecifieke overwegingen
Bij implementaties in de gezondheidszorg omvat het Intent-First-patroon aanvullende waarborgen:
Categorieën gezondheidszorgintenties:
-
Klinisch: Medicatievragen, symptomen, verzorgingsinstructies
-
Dekking: Voordelen, voorafgaande toestemming, Formularium
-
Planning: Afspraken, beschikbaarheid van providers
-
Facturering: Claims, betalingen, afschriften
-
Rekening: Profiel, personen ten laste, ID-kaarten
Kritieke beveiliging: Klinische vragen omvatten altijd disclaimers en vervangen nooit professioneel medisch advies. Het systeem stuurt complexe klinische vragen door naar menselijke ondersteuning.
Randgevallen behandelen
De randgevallen zijn waar systemen falen. Het Intent-First-patroon bevat specifieke handlers:
Trefwoorden voor frustratiedetectie:
-
Woede: “verschrikkelijk”, “ergste”, “haat”, “belachelijk”
-
Tijd: “uren”, “dagen”, “nog steeds wachten”
-
Mislukking: “nutteloos”, “geen hulp”, “werkt niet”
-
Escalatie: ‘praat met een mens’, ‘echte persoon’, ‘manager’
Wanneer er frustratie wordt gedetecteerd, kunt u de zoekopdracht volledig overslaan en contact opnemen met menselijke ondersteuning.
Sectoroverschrijdende toepassingen
Het Intent-First-patroon is van toepassing overal waar ondernemingen conversatie-AI over heterogene inhoud inzetten:
|
Industrie |
Intentiecategorieën |
Belangrijk voordeel |
|
Telecommunicatie |
Verkoop, ondersteuning, facturering, account, retentie |
Voorkomt misclassificatie bij het ‘annuleren’ |
|
Gezondheidszorg |
Klinisch, dekking, planning, facturering |
Scheidt klinisch van administratief |
|
Financiële diensten |
Detailhandel, institutioneel, kredietverlening, verzekeringen |
Voorkomt contextvermenging |
|
Detailhandel |
Product, bestellingen, retouren, loyaliteit |
Zorgt voor promotionele versheid |
Resultaten
Na de implementatie van de Intent-First-architectuur op telecommunicatie- en gezondheidszorgplatforms:
|
Metrisch |
Invloed |
|
Succespercentage van zoekopdrachten |
Bijna verdubbeld |
|
Ondersteuning van escalaties |
Met ruim de helft verminderd |
|
Tijd voor een oplossing |
Ongeveer 70% verlaagd |
|
Gebruikerstevredenheid |
Verbeterd ongeveer 50% |
|
Gebruikerstarief retourneren |
Meer dan verdubbeld |
Het percentage terugkerende gebruikers bleek het meest significant. Wanneer zoeken werkt, komen gebruikers terug. Als het mislukt, verlaten ze het kanaal volledig, waardoor de kosten voor alle andere ondersteuningskanalen stijgen.
De strategische imperatief
De conversationele AI-markt zal een hypergroei blijven ervaren.
Maar ondernemingen die typische RAG-architecturen bouwen en implementeren zullen herhaaldelijk blijven falen.
AI zal zelfverzekerd verkeerde antwoorden geven, gebruikers zullen uit frustratie de digitale kanalen verlaten en de ondersteuningskosten zullen stijgen in plaats van dalen.
Intent-First is een fundamentele verschuiving in de manier waarop bedrijven AI-aangedreven klantgesprekken moeten ontwerpen en bouwen. Het gaat niet om betere modellen of meer data. Het gaat erom dat je begrijpt wat een gebruiker wil, voordat je hem probeert te helpen.
Hoe eerder een organisatie zich realiseert dat dit een architecturale noodzaak is, hoe eerder zij in staat zal zijn de efficiëntiewinsten te benutten die deze technologie mogelijk zou moeten maken. Degenen die dat niet doen, zullen zich afvragen waarom hun AI-investeringen de komende jaren niet de verwachte bedrijfsresultaten hebben opgeleverd.
De demo is eenvoudig. De productie is moeilijk. Maar het patroon voor productiesucces is duidelijk: Intentie eerst.
Sreenivasa Reddy Hulebeedu Reddy is een leidende software-ingenieur en enterprise-architect
Welkom bij de VentureBeat-community!
In ons gastpostprogramma delen technische experts inzichten en bieden ze neutrale, niet-gevestigde diepgaande inzichten over AI, data-infrastructuur, cyberbeveiliging en andere geavanceerde technologieën die de toekomst van het bedrijfsleven vormgeven.
Lees meer uit ons gastpostprogramma — en bekijk ons richtlijnen als u geïnteresseerd bent om een eigen artikel bij te dragen!
