Wanneer veel bedrijven niet eens nadenken over het gedrag van agenten of de infrastructuur, Boeking.com was hen ‘ tegengekomen’ met een lokaal systeem voor conversatieaanbevelingen. Deze vroege experimenten hebben bedrijven in staat gesteld een stapje terug te doen en te voorkomen dat ze verstrikt raken in de waanzin van AI-agenten. In plaats daarvan hanteren ze een gedisciplineerde, gelaagde en modulaire benadering van modelontwikkeling: kleine, reisspecifieke modellen voor goedkope en snelle gevolgtrekking; grotere grote taalmodellen (LLM’s) voor redeneren en begrijpen; en evaluaties op maat voor aangepaste domeinen wanneer precisie van cruciaal belang is. Met deze hybride strategie – gecombineerd met selectieve samenwerking met OpenAI – heeft Booking.com de nauwkeurigheid zien verdubbelen bij het ophalen van sleutels, rangschikking en klantbetrokkenheidstaken. Zoals Pranav Pathak, AI-productontwikkelingsleider bij Booking.com, tegen VentureBeat zei in zijn nieuwe podcast: “Bouw je het heel, heel gespecialiseerd en op maat en heb je een leger van honderd agenten? Of bouw je het vrij generiek en heb je vijf agenten die goed zijn in algemene taken, maar dan moet je veel dingen om hen heen organiseren? Dat is een evenwicht dat we volgens mij nog steeds aan het uitzoeken zijn, net als de rest van de industrie.” Kijk wat er nieuw is Verder dan piloot podcasts hieren lees verder voor de hoogtepunten.
Ga van giswerk naar diepgaande personalisatie zonder ‘griezelig’ te zijn
Het aanbevelingssysteem vormt de kern van het klantgerichte platform van Booking.com; Traditionele aanbevelingsinstrumenten zijn echter niet langer alleen maar aanbevelingen, het zijn slechts giswerk, erkende Pathak. Daarom hebben hij en zijn team vanaf het begin gezworen generieke tools te vermijden: zoals hij zegt, moeten prijzen en aanbevelingen gebaseerd zijn op de context van de klant. De pre-gen AI-tools van Booking.com voor het detecteren van intenties en onderwerpen waren kleine taalmodellen, die Pathak beschrijft als “de schaal en omvang van BERT.” Het model absorbeert feedback van klanten over hun probleem om te bepalen of het probleem kan worden opgelost via zelfbediening of kan worden overgedragen aan een menselijke agent. “We zijn begonnen met de architectuur van ‘Je moet de tool aanroepen als dit de bedoeling is die je detecteert en dit is hoe je de structuur parseert’, legt Pathak uit. “Het leek heel erg op sommige van de eerste agent-architecturen die opkwamen in termen van redeneren en definiëren van tool-oproepen.” Zijn team heeft de architectuur zo gebouwd dat deze een LLM-orchestrator bevat die queries classificeert, Retrieval Augmented Generation (RAG) activeert en kleinere API’s of aangepaste taalmodellen aanroept. “We hebben deze systemen goed genoeg kunnen schalen omdat de architectuur zo op elkaar lijkt dat we, met een paar aanpassingen, nu een complete agentenstack hebben”, aldus Pathak. Als gevolg hiervan ondervond Booking.com een tweevoudige verbetering in onderwerpdetectie, waardoor de bandbreedte voor menselijke agenten 1,5 tot 1,7 maal werd vrijgemaakt. Steeds meer onderwerpen, zelfs complexe onderwerpen die voorheen als ‘overig’ werden aangemerkt en verbetering behoeven, worden nu geautomatiseerd. Uiteindelijk ondersteunt dit meer zelfbediening, zodat menselijke agenten zich kunnen concentreren op klanten die unieke en specifieke problemen hebben die het platform niet kan oplossen – bijvoorbeeld een gezin dat om twee uur ’s nachts geen toegang heeft tot hun hotelkamer als de receptie gesloten is. Niet alleen begint dit “echt te kloppen”, maar het heeft ook een onmiddellijke en langdurige impact op het klantenbehoud, aldus Pathak. “Een van de dingen die we zien is dat hoe beter we onze klanten bedienen, hoe loyaler onze klanten zijn.” Een andere recente lancering is gepersonaliseerde filtering. Booking.com heeft tussen de 200 en 250 zoekfilters op zijn site – een onrealistisch aantal waar mensen doorheen kunnen filteren, zei Pathak. Daarom introduceerde zijn team een vrij tekstvak waarin gebruikers konden typen om onmiddellijk aangepaste filters te ontvangen. “Dit is een belangrijk signaal voor personalisatie in termen van waar je naar zoekt in je eigen woorden, in plaats van op basis van clickstream”, aldus Pathak. Dit geeft op zijn beurt weer aan Booking.com aan wat klanten echt willen. Bubbelbaden bijvoorbeeld: toen filterpersonalisatie voor het eerst werd gelanceerd, waren jacuzzi’s een van de meest populaire verzoeken. Het was niet eens een uitgemaakte zaak; er is niet eens een filter. Nu is het filter actief. ‘Ik weet het niet,’ zei Pathak. “Eerlijk gezegd heb ik nog nooit naar een bubbelbad in mijn kamer gezocht.” Als het om personalisatie gaat, zijn er echter grenzen; Haar geheugen is nog steeds ingewikkeld, benadrukt Pathak. Hoewel het belangrijk is om een langetermijngeheugen te hebben en een evoluerende relatie met klanten – waarbij informatie wordt vastgelegd zoals hun gemiddelde budget, de sterrenwaardering van favoriete hotels, of of ze toegang voor gehandicapten nodig hebben – moet dit op hun voorwaarden gebeuren en hun privacy beschermen. Booking.com let er heel goed op dat het vragen om toestemming niet “griezelig” is bij het verzamelen van klantinformatie. “Het beheren van geheugen is veel moeilijker dan het opbouwen van geheugen”, zegt Pathak. “De technologie is er, we hebben de technische mogelijkheden om deze te bouwen. We willen ervoor zorgen dat we geen geheugenobjecten lanceren die de klantovereenkomsten niet respecteren, wat niet eerlijk voelt.”
Een balans vinden tussen bouwen versus kopen
Nu agenten steeds volwassener worden, beantwoordt Booking.com een belangrijke vraag waarmee de hele sector wordt geconfronteerd: hoe beperkt moeten agenten zijn? In plaats van zich te binden aan een groep zeer gespecialiseerde agenten of een paar generieke agenten, streeft het bedrijf ernaar om omkeerbare beslissingen te nemen en ‘eenrichtingsdeuren’ te vermijden die zijn architectuur op lange termijn en dure paden vergrendelen. De strategie van Pathak is: generaliseer waar mogelijk, specialiseer waar nodig en houd het ontwerp van agenten flexibel om robuustheid te helpen garanderen. Pathak en zijn team “letten goed op” gebruiksscenario’s en evalueerden waar ze meer algemene, herbruikbare agenten of meer taakspecifieke agenten konden bouwen. Ze streven ernaar om voor elke gebruikssituatie het kleinst mogelijke model te gebruiken, met het hoogste niveau van nauwkeurigheid en uitvoerkwaliteit. Alles wat generaliseerbaar is, is dat wel. Latentie is een andere belangrijke overweging. Wanneer feitelijke nauwkeurigheid en het vermijden van hallucinaties van het grootste belang zijn, zal zijn team grotere, langzamere modellen gebruiken; maar bij zoeken en aanbevelingen bepalen de verwachtingen van de gebruiker de snelheid. (Pathak merkt op: “Niemand is geduldig.”) “We zouden bijvoorbeeld nooit zoiets zwaar werk als GPT-5 gebruiken, alleen voor onderwerpdetectie of entiteitsextractie”, zei hij. Booking.com hanteert ook een vergelijkbare elastische benadering van monitoring en evaluatie: als monitoring voor algemene doeleinden wordt gedaan door iemand anders die beter is in bouwen en over horizontale capaciteiten beschikt, dan zullen zij het kopen. Maar als merkrichtlijnen moeten worden afgedwongen, zullen ze hun eigen evaluaties maken. Uiteindelijk is Booking.com vaak ‘super anticiperend’, wendbaar en flexibel. “Op dit moment, met alles wat er gaande is met AI, zijn we een beetje terughoudend om door een eenrichtingsdeur te lopen”, zei Pathak. “We willen dat zoveel mogelijk van onze beslissingen ongedaan worden gemaakt. We willen niet vastzitten in een beslissing die we over twee jaar niet meer ongedaan kunnen maken.”
Wat andere ontwikkelaars kunnen leren van het AI-traject van Booking.com
Het AI-traject van Booking.com zou een belangrijke blauwdruk kunnen zijn voor andere bedrijven. Terugkijkend geeft Pathak toe dat ze zijn begonnen met een ‘redelijk complexe’ technologiestapel. Ze zijn er nu mee bekend, “maar we zouden waarschijnlijk met iets eenvoudiger kunnen beginnen en kijken hoe klanten ermee omgaan.” Daarom geeft hij dit waardevolle advies: als je net begint met een LLM of een bureau, is een kant-en-klare API voldoende. “Er zijn genoeg aanpassingen mogelijk met de API, zodat je al veel invloed kunt uitoefenen voordat je besluit dat je meer wilt doen.” Aan de andere kant, als de use case maatwerk vereist dat niet beschikbaar is via standaard API-aanroepen, zijn interne tools nodig. Toch benadrukte hij: begin niet met iets ingewikkelds. Bespreek “de eenvoudigste en meest pijnlijke problemen die je kunt vinden en de eenvoudigste en meest voor de hand liggende oplossingen voor die problemen.” Identificeer de aansluiting op de productmarkt en onderzoek vervolgens het ecosysteem, adviseert hij, maar schrap niet alleen de verouderde infrastructuur omdat een nieuwe use case iets specifieks vereist (zoals het verplaatsen van een volledige cloudstrategie van AWS naar Azure alleen maar om OpenAI-eindpunten te gebruiken). Uiteindelijk: “Sluit jezelf niet te vroeg op”, zegt Pathak. “Neem geen eenrichtingsbeslissing totdat u er absoluut zeker van bent dat dit de oplossing is die u wilt nemen.”
