Toen veel bedrijven nog niet eens nadachten over het gedrag of de infrastructuur van agenten, Boeking.com was ze al ‘ tegengekomen’ met zijn eigen conversatie-aanbevelingssysteem. Deze vroege experimenten hebben het bedrijf in staat gesteld een stapje terug te doen en te voorkomen dat het wordt meegesleurd in de hectische hype van AI-agenten. In plaats daarvan hanteert het een gedisciplineerde, gelaagde, modulaire benadering van modelontwikkeling: kleine, reisspecifieke modellen voor goedkope, snelle gevolgtrekking; grotere grote taalmodellen (LLM’s) voor redeneren en begrijpen; en op het domein afgestemde evaluaties die intern zijn gebouwd 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 belangrijke gegevens, het rangschikken en de klantinteractietaken. Zoals Pranav Pathak, AI-productontwikkelingsleider van Booking.com, in een nieuwe podcast aan VentureBeat stelde: “Bouw je het heel, heel gespecialiseerd en op maat en heb je dan een leger van honderd agenten? Of houd je het algemeen genoeg en heb je vijf agenten die goed zijn in algemene taken, maar dan moet je er veel omheen orkestreren? Dat is een evenwicht dat we volgens mij nog steeds aan het ontdekken zijn, net als de rest van de sector.” Bekijk de nieuwe Voorbij de piloot podcast hieren lees verder voor hoogtepunten.
Van gissen naar diepgaande personalisatie zonder ‘griezelig’ te zijn
Aanbevelingssystemen vormen de kern van de klantgerichte platforms van Booking.com; Bij traditionele aanbevelingsinstrumenten ging het echter minder om aanbevelingen en meer om gissen, gaf Pathak toe. Daarom beloofden hij en zijn team vanaf het begin om generieke tools te vermijden: zoals hij het stelde, zouden de prijs en de aanbeveling gebaseerd moeten zijn op de context van de klant. De initiële pre-gen AI-tooling van Booking.com voor het detecteren van intenties en onderwerpen was een klein taalmodel, wat Pathak omschreef als “de schaal en omvang van BERT.” Het model verwerkte de input van de klant rond zijn probleem om te bepalen of het probleem kon worden opgelost door middel van zelfbediening of doorgestuurd kon worden naar een menselijke agent. “We zijn begonnen met een architectuur van ‘je moet een tool aanroepen als dit de bedoeling is die je detecteert en dit is hoe je de structuur hebt ontleed’, legt Pathak uit. “Dat leek heel erg op de eerste paar agentische architecturen die uitkwamen in termen van rede en het definiëren van een tool-call.” Zijn team heeft die architectuur sindsdien uitgebouwd met een LLM-orkestrator die queries classificeert, retrieval-augmentedgeneration (RAG) activeert en API’s of kleinere, gespecialiseerde taalmodellen aanroept. “We hebben dat systeem behoorlijk goed kunnen schalen omdat het qua architectuur zo dicht bij elkaar lag dat we, met een paar aanpassingen, nu een volledige agentenstack hebben”, aldus Pathak. Als gevolg hiervan ziet Booking.com een verdubbeling van de onderwerpdetectie, waardoor de bandbreedte van menselijke agenten 1,5 tot 1,7 maal wordt vrijgemaakt. Steeds meer onderwerpen, zelfs ingewikkelde onderwerpen die voorheen als ‘overig’ werden aangemerkt en escalatie vereisten, worden geautomatiseerd. Uiteindelijk ondersteunt dit meer zelfbediening, waardoor menselijke agenten zich kunnen concentreren op klanten met unieke specifieke problemen waarvoor het platform geen speciale toolflow heeft, bijvoorbeeld een gezin dat om twee uur ’s nachts geen toegang heeft tot zijn hotelkamer als de receptie gesloten is. Dat “begint echt te verergeren”, maar heeft ook een directe, langdurige impact op het klantenbehoud, merkte Pathak op. “Een van de dingen die we hebben gezien is dat hoe beter we zijn in klantenservice, hoe loyaler onze klanten zijn.” Een andere recente uitrol is gepersonaliseerde filtering. Booking.com heeft tussen de 200 en 250 zoekfilters op haar website – een onrealistisch aantal voor ieder mens om door te spitten, merkte Pathak op. Daarom introduceerde zijn team een vrij tekstvak waarin gebruikers kunnen typen om onmiddellijk op maat gemaakte filters te ontvangen. “Dat wordt zo’n belangrijk signaal voor personalisatie in termen van waar je naar op zoek bent, in je eigen woorden in plaats van in een klikstream”, zegt Pathak. Op zijn beurt leert het Booking.com wat klanten daadwerkelijk willen. Bijvoorbeeld bubbelbaden: toen filterpersonalisatie voor het eerst werd geïntroduceerd, waren jacuzzi’s een van de meest populaire verzoeken. Dat was voorheen niet eens een overweging; er was niet eens een filter. Nu is dat filter live. ‘Ik had geen idee,’ merkte Pathak op. “Eerlijk gezegd had ik nog nooit naar een bubbelbad in mijn kamer gezocht.” Als het om personalisatie gaat, is er echter een dunne lijn; het geheugen blijft ingewikkeld, benadrukt Pathak. Hoewel het belangrijk is om langetermijnherinneringen en evoluerende gesprekken met klanten te hebben – het bijhouden van informatie zoals hun gebruikelijke budgetten, favoriete hotelsterrenbeoordelingen of of ze toegang voor gehandicapten nodig hebben – moet dit op hun voorwaarden gebeuren en hun privacy beschermen. Booking.com gaat uiterst zorgvuldig om met het geheugen en vraagt toestemming om niet “griezelig” te zijn bij het verzamelen van klantinformatie. “Het beheren van geheugen is veel moeilijker dan het daadwerkelijk opbouwen van geheugen”, zegt Pathak. “De technologie is er, we hebben de technische kennis om het te bouwen. We willen ervoor zorgen dat we geen geheugenobject lanceren dat de toestemming van de klant niet respecteert, dat niet erg natuurlijk aanvoelt.”
Het vinden van een balans tussen bouwen en kopen
Naarmate agenten volwassener worden, houdt Booking.com zich bezig met een centrale vraag waarmee de hele sector wordt geconfronteerd: hoe beperkt moeten agenten worden? In plaats van zich te binden aan een zwerm zeer gespecialiseerde agenten of een paar algemene agenten, streeft het bedrijf naar omkeerbare beslissingen en vermijdt het ‘eenrichtingsdeuren’ die zijn architectuur opsluiten in langdurige, kostbare paden. De strategie van Pathak is: generaliseren waar mogelijk, specialiseren waar nodig en het ontwerp van agenten flexibel houden om de veerkracht te helpen garanderen. Pathak en zijn team houden zich “zeer bewust” van gebruiksscenario’s en evalueren waar meer algemene, herbruikbare agenten of meer taakspecifieke agenten moeten worden gebouwd. Ze streven ernaar om voor elke gebruikssituatie het kleinst mogelijke model te gebruiken, met het hoogste niveau van nauwkeurigheid en uitvoerkwaliteit. Wat gegeneraliseerd kan worden, is dat ook. Latentie is een andere belangrijke overweging. Wanneer feitelijke nauwkeurigheid en het vermijden van hallucinaties van het grootste belang zijn, zal zijn team een groter, veel langzamer model gebruiken; maar met zoeken en aanbevelingen bepalen de verwachtingen van de gebruiker de snelheid. (Pathak merkte op: “Niemands patiënt.”) “We zouden bijvoorbeeld nooit zoiets zwaars als GPT-5 gebruiken voor alleen onderwerpdetectie of voor entiteitsextractie,” zei hij. Booking.com hanteert een soortgelijke elastische aanpak als het gaat om monitoring en evaluaties: als het om algemene monitoring gaat waarvan iemand anders beter is in het bouwen en over horizontale capaciteiten beschikt, zullen zij die kopen. Maar als het gaat om gevallen waarin merkrichtlijnen moeten worden afgedwongen, bouwen ze hun eigen evaluaties. Uiteindelijk is Booking.com ‘super anticiperend’, wendbaar en flexibel geworden. “Op dit moment, met alles wat er met AI gebeurt, zijn we er een beetje huiverig voor om door eenrichtingsdeuren te lopen”, zegt Pathak. “We willen dat zoveel mogelijk van onze beslissingen omkeerbaar zijn. We willen niet vast komen te zitten in een beslissing die we over twee jaar niet meer kunnen terugdraaien.”
Wat andere bouwers kunnen leren van het AI-traject van Booking.com
Het AI-traject van Booking.com kan dienen als een belangrijke blauwdruk voor andere ondernemingen. Terugkijkend erkende Pathak dat ze begonnen met een “behoorlijk ingewikkelde” tech-stack. Daarmee zitten ze nu op een goede plek, “maar we hadden waarschijnlijk met iets veel eenvoudigers kunnen beginnen en zien hoe klanten ermee omgingen.” Daarom gaf hij dit waardevolle advies: als je net begint met LLM’s of agenten, zullen kant-en-klare API’s het prima doen. “Er is voldoende maatwerk met API’s zodat je al veel invloed kunt uitoefenen voordat je besluit dat je meer wilt gaan doen.” Aan de andere kant, als een use case maatwerk vereist dat niet beschikbaar is via een standaard API-aanroep, pleit dat voor interne tools. Toch benadrukte hij: begin niet met ingewikkelde dingen. Pak het “eenvoudigste, meest pijnlijke probleem aan dat je kunt vinden en de eenvoudigste, meest voor de hand liggende oplossing daarvoor.” Identificeer de geschiktheid van de productmarkt en onderzoek vervolgens de ecosystemen, adviseerde hij – maar ruk niet zomaar oude infrastructuren eruit omdat een nieuwe use case iets specifieks vereist (zoals het verplaatsen van een volledige cloudstrategie van AWS naar Azure alleen maar om het OpenAI-eindpunt te gebruiken). Uiteindelijk: “Sluit jezelf niet te vroeg op”, merkte Pathak op. “Neem geen beslissingen die eenrichtingsverkeer zijn totdat u er zeker van bent dat dit de oplossing is die u wilt gebruiken.”
