De moderne klant heeft maar één behoefte die ertoe doet: krijgen het ding zij willen wanneer ze het willen. Het oude standaard RAG-model insluiten+krijgen+LLM begrijpt de bedoeling verkeerd, overbelast de context en mist frisheid, waardoor klanten herhaaldelijk op het verkeerde pad terechtkomen.
In plaats daarvan gebruikt intent-first-architectuur een lichtgewicht taalmodel om de vraag te ontleden op intentie en context voordat deze wordt afgeleverd bij de meest relevante inhoudsbronnen (documenten, API’s, mensen).
Enterprise AI is een sneltrein die op weg is naar een klif. Organisaties implementeren op LLM gebaseerde zoekapplicaties in een recordtempo, terwijl een fundamenteel architectonisch probleem de meeste kans op mislukking veroorzaakt.
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 er niet in zijn geslaagd aan de verwachtingen van de onderneming te voldoen.
Het probleem ligt niet bij de onderliggende modellen. Het is de architectuur om hen heen.
Nadat ik live AI-aangedreven klantinteractieplatforms op schaal heb ontworpen en uitgevoerd en miljoenen klant- en burgergebruikers bij enkele van ’s werelds grootste telecommunicatie- en gezondheidszorgorganisaties heb bediend, ben ik een patroon gaan zien. Dat is het verschil in succes AI-aangedreven interactie-implementaties en een mislukking 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-probleem
Gartner verwacht dat de mondiale AI-conversatiemarkt een grote vlucht zal nemen 36 miljard dollar in 2032. Bedrijven vechten om een stukje te krijgen. De demo’s zijn onweerstaanbaar. Sluit uw LLM in uw kennisbanken opeens kan het vragen van klanten in natuurlijke taal beantwoorden. Magie.
Vervolgens vindt de productie plaats.
Een grote telecombedrijf waarmee ik werk, heeft een RAG-systeem uitgerold met de verwachting dat de tarieven voor ondersteuningsoproepen zullen dalen. In plaats daarvan werd het tarief verhoogd. Bellers probeerden AI-gestuurd zoeken, kregen met een hoge mate van vertrouwen foute 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 weken of maanden verouderd is. Chatbots voor de financiële dienstverlening spuwen reacties uit van zowel retail- als institutionele productinhoud. Retailers zien beëindigde producten opduiken in productzoekopdrachten.
Het probleem is geen fout in de AI-technologie. Het is een fout in de architectuur
Waarom standaard RAG-architecturen falen
Het standaard RAG-patroon – het inbedden van de zoekopdracht, het ophalen van semantisch vergelijkbare inhoud, op 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.
Stel dat een klant schrijft: “Ik wil annuleren”. Wat betekent dat? Wilt u een dienst opzeggen? Een bestelling annuleren? Afspraak annuleren? Tijdens onze telecomuitrol ontdekten we dat 65% van de vragen over “annulering” feitelijk bestellingen of afspraken waren, en geen annuleringen 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 schrijft: ‘Ik moet afzeggen’ omdat hij of zij een afspraak, het bijvullen van een recept of een procedure probeert te annuleren, is het niet alleen frustrerend om hen te verwijzen naar de medicatie-inhoud van het schema, maar ook gevaarlijk.
2. Contextoverstroming
De kennis en ervaring van het bedrijf is enorm en omvat tientallen bronnen, zoals productcatalogi, facturering, ondersteuningsartikelen, beleid, campagnes en accountgegevens. Standaard RAG-modellen behandelen alles hetzelfde en zoeken naar alle zoekopdrachten.
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 op en retourneert zoekresultaten die een halve stap naast het doel 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 die verlopen producten, aanbiedingen of functies lieten zien.
Het Intent-First-architectuurpatroon
Het Intent-First-architectuurpatroon is het spiegelbeeld van de standaard RAG-implementatie. In het RAG-model haal en routeer je dienovereenkomstig. In het Intent-First-model classificeert u voordat u routeert of ophaalt.
Intent-First-architecturen gebruiken een lichtgewicht taalmodel om een query te analyseren 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.
Service voor intentieclassificatie
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 < 0,70 DAN
– OPBRENGST {
vereist_verduidelijking: waar,
voorgestelde_vraag: genereer_verhelderende_vraag(query)
}
4. EXTRA sub_intent gebaseerd op primaire_intent:
– IF primair = “ACCOUNT” → zoek naar ORDER_STATUS, PROFILE, etc.
– IF primair = “ONDERSTEUNING” → controleer op DEVICE_ISSUE, NETWORK enz.
– INDIEN primair = “FACTUREN” → controleer op BETALING, GESCHIL, enz.
5. BEPALEN doelbronnen op basis van intentietoewijzing:
– ORDER_STATUS → (orders_db, order_faq)
– DEVICE_ISSUE → (debug_kb, device_guides)
– MEDICATIE → (formulier, 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 doelgericht uitgevoerd:
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:
– inhoudstypen ← 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
– nieuwste_score ← versheidsgewicht × 0,20
– personalisatiescore ← gebruikersmatch × 0,25
– intent_match_score ← type_match × 0,15
– totaal_score ← SOM van het bovenstaande
6. RANG op basis van aflopende totale_score
7. RETOUR top 10 documenten
Gezondheidsspecifieke overwegingen
Bij implementaties in de gezondheidszorg omvat het Intent-First-patroon aanvullende waarborgen:
Categorieën voor gezondheidsintenties:
-
Klinisch: Medicijnvragen, symptomen, verzorgingsinstructies
-
Dekking: Voordelen, voorafgaande goedkeuring, formulier
-
Planning: Overeenkomsten, beschikbaarheid provider
-
Facturering: Claims, betalingen, afschriften
-
Rekening: Profiel, nabestaanden, ID-kaart
Kritieke bescherming: Klinische onderzoeken omvatten altijd disclaimers en zijn nooit een vervanging voor professioneel medisch advies. Het systeem stuurt complexe klinische vragen naar menselijke ondersteuning.
Afhandelen van randgevallen
De randgevallen zijn waar systemen falen. Het Intent-First-patroon bevat specifieke handlers:
Trefwoorden voor registratie van frustratie:
-
Woede: “verschrikkelijk”, “ergste”, “haat”, “belachelijk”
-
Tijd: “uren”, “dagen”, “nog steeds wachtend”
-
Fouten: “nutteloos”, “geen hulp”, “werkt niet”
-
Escalatie: “praat met een mens”, “echte persoon”, “manager”
Wanneer er frustratie wordt gedetecteerd, sla dan de zoektocht helemaal over en ga naar menselijke ondersteuning.
Sectoroverschrijdende toepassingen
Het Intent-First-patroon is van toepassing overal waar bedrijven conversationele AI inzetten over heterogene inhoud:
|
Industrie |
Intentiecategorieën |
Belangrijk voordeel |
|
Telecommunicatie |
Verkoop, ondersteuning, facturatie, account, opslag |
Voorkomt misclassificatie bij het ‘annuleren’ |
|
Gezondheidszorg |
Klinisch, dekking, planning, facturering |
Onderscheidt klinisch van administratief |
|
Financiële diensten |
Retail, institutioneel, kredietverlening, verzekeringen |
Voorkomt contextvermenging |
|
Detailhandel |
Product, bestellingen, retouren, loyaliteit |
Zorgt voor promotionele versheid |
Resultaten
Na de implementatie van de Intent-First-architectuur op telecom- en gezondheidszorgplatforms:
|
Metrisch |
Invloed |
|
Succespercentage van zoekopdrachten |
Bijna verdubbeld |
|
Ondersteuning van escalaties |
Met ruim de helft verminderd |
|
Tijd voor oplossing |
Ongeveer 70% verlaagd |
|
Gebruikerstevredenheid |
Verbeterd ongeveer 50% |
|
Gebruikerstarief retourneren |
Meer dan verdubbeld |
Het gebruikersrendement bleek het meest significant. Wanneer de zoekopdracht werkt, komen gebruikers terug. Als dat niet lukt, verlaten ze het kanaal helemaal, waardoor de kosten voor alle andere ondersteuningskanalen stijgen.
De strategische imperatief
De conversationele AI-markt zal een hypergroei blijven ervaren.
Maar bedrijven die typische RAG-architecturen bouwen en implementeren zullen herhaaldelijk blijven falen.
AI zal vol vertrouwen 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 opbouwen en opbouwen. 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ëntieverbeteringen te realiseren die deze technologie mogelijk zou moeten maken. Degenen die dat niet doen, zullen falen, waarom hun AI-investeringen de komende jaren geen verwachte bedrijfsresultaten hebben opgeleverd.
De demo is eenvoudig. De productie is zwaar. Maar het patroon van productiesucces is duidelijk: Intentie eerst.
Sreenivasa Reddy Hulebeedu Reddy is een toonaangevende software-ingenieur en enterprise-architect
Welkom bij de VentureBeat-community!
In ons gastpostprogramma delen technische experts inzichten en bieden ze neutrale, onbevooroordeelde diepgaande inzichten in 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 uw eigen artikel bij te dragen!
