Toen veel bedrijven nog niet eens nadachten over het gedrag van agenten of de infrastructuur, Boeking.com hij was ze al ‘ tegengekomen’ met zijn eigen conversatie-aanbevelingssysteem. Dankzij dit eerste experiment kon het bedrijf een stap terug doen en voorkomen dat het overweldigd werd door de hectische reclamecampagne over AI-agenten. In plaats daarvan wordt een gedisciplineerde, gelaagde en modulaire benadering van modelontwikkeling gevolgd: kleine reisspecifieke modellen voor goedkope en snelle gevolgtrekking; bredere taalmodellen (LLM’s) voor redeneren en begrijpen; en domein-geoptimaliseerde beoordelingen die intern zijn gebouwd wanneer nauwkeurigheid 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, classificatie en klantinteractietaken. Pranav Pathak, hoofd AI-productontwikkeling bij Booking.com, vertelde VentureBeat in een nieuwe podcast: “Bouw je het heel, heel gespecialiseerd en op maat en heb je dan een leger van honderd agenten? Of houd je het vrij algemeen 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 proberen te vinden, net als de rest van de industrie.” Ontdek het nieuwe Verder dan de piloot podcast hieren lees verder voor de hoogtepunten.
Ga van giswerk naar diepgaande personalisatie zonder ‘griezelig’ te zijn
Aanbevelingssystemen vormen de kern van de klantgerichte platforms van Booking.com; Traditionele aanbevelingsinstrumenten zijn echter minder gericht op aanbevelingen en meer op hypothesen, geeft Pathak toe. Daarom hebben hij en zijn team vanaf het begin gezworen generieke tools te vermijden: zoals hij zei, moeten prijzen en aanbevelingen gebaseerd zijn op de context van de klant. De aanvankelijke vooraf gebouwde AI-tools van Booking.com voor het detecteren van intenties en onderwerpen waren een klein taalmodel, wat Pathak omschreef als ‘de schaal en omvang van BERT’. Het model absorbeerde de input van klanten over het probleem om te bepalen of het via zelfbediening kon worden opgelost of kon worden geëscaleerd 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 zo analyseer je de structuur'”, legt Pathak uit. “Het leek heel erg op de eerste agent-architecturen die opkwamen in termen van redeneren en definiëren van een aanroep naar een tool.” Zijn team heeft die architectuur sindsdien gebouwd met een LLM-orkestrator die query’s classificeert, augmented generatie (RAG) voor het ophalen van gegevens mogelijk maakt en kleinere, meer gespecialiseerde API’s of taalmodellen aanroept. “We konden dat systeem vrij goed aanpassen omdat het qua architectuur zo dicht bij elkaar lag dat we, met enkele aanpassingen, nu een complete agentenstack hebben”, aldus Pathak. Als gevolg hiervan ziet Booking.com een verdubbeling van de detectie van onderwerpen, wat op zijn beurt de bandbreedte voor menselijke agenten 1,5 tot 1,7 keer vrijmaakt. Steeds meer onderwerpen, zelfs ingewikkelde onderwerpen die voorheen als ‘overig’ werden aangemerkt en die escalatie vereisten, worden geautomatiseerd. Uiteindelijk ondersteunt dit meer zelfbediening, waardoor menselijke agenten zich kunnen concentreren op klanten met specifieke problemen waarvoor het platform geen speciale toolflow heeft – bijvoorbeeld een gezin dat om twee uur ’s nachts geen toegang heeft tot hun hotelkamer als de receptie gesloten is. Dit “begint echt erger te worden”, maar heeft ook een directe langetermijnimpact op de klantenloyaliteit, merkte Pathak op. “Een van de dingen die we hebben gezien is dat hoe beter onze klantenservice, hoe loyaler onze klanten zullen zijn.” Een andere recente implementatie is aangepast filteren. Booking.com heeft tussen de 200 en 250 zoekfilters op haar website – een onrealistisch aantal voor ieder mens om door te bladeren, benadrukt Pathak. Daarom introduceerde zijn team een vrij tekstvak waarin gebruikers kunnen typen om direct aangepaste filters te ontvangen. “Dit wordt een heel belangrijk signaal voor personalisatie in termen van waar je naar op zoek bent, in je eigen woorden in plaats van in een klikstream”, aldus Pathak. Op zijn beurt vertelt het Booking.com wat klanten eigenlijk willen. Bijvoorbeeld bubbelbaden: Toen het aanpassen van filters voor het eerst werd gelanceerd, waren bubbelbaden een van de meest populaire verzoeken. Dit was niet eens een eerdere overweging; er was niet eens een filter. Nu is dat filter actief. ‘Ik had geen idee,’ merkte Pathak op. “Ik had eerlijk gezegd nog nooit naar een bubbelbad in mijn kamer gezocht.” Als het om maatwerk gaat, is de grens echter prima; het geheugen blijft ingewikkeld, benadrukt Pathak. Hoewel het belangrijk is om langetermijnherinneringen te hebben en om gesprekken met klanten te voeren (waarbij informatie wordt bewaard zoals hun gebruikelijke budgetten, sterbeoordelingen van favoriete hotels, of ze toegang voor gehandicapten nodig hebben), moet dit gebeuren op hun voorwaarden en met bescherming van hun privacy. Booking.com houdt bijzonder veel rekening met het geheugen en vraagt toestemming om niet “griezelig” te zijn bij het verzamelen van klantinformatie. “Het beheren van het geheugen is veel moeilijker dan het daadwerkelijk bouwen ervan”, zegt Pathak. “De technologie is er, we hebben de technische mogelijkheden om het mogelijk te maken. We willen ervoor zorgen dat we geen geheugenobject lanceren dat de toestemming van de klant niet respecteert, omdat het niet erg natuurlijk aanvoelt.”
Zoek een balans tussen bouwen en kopen
Naarmate agenten volwassener worden, wordt Booking.com geconfronteerd met een centrale vraag waarmee de hele sector wordt geconfronteerd: hoe smal moeten agenten worden? In plaats van in zee te gaan met 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 kostbare langetermijnpaden. De strategie van Pathak is: generaliseren waar mogelijk, specialiseren waar nodig en het ontwerp van agenten flexibel houden om veerkracht te garanderen. Pathak en zijn team zijn “zeer attent” over gebruiksscenario’s en evalueren waar ze meer algemene en herbruikbare agenten of meer taakspecifieke agenten kunnen 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 een groter, veel langzamer model gebruiken; maar bij onderzoek en aanbevelingen bepalen de verwachtingen van de gebruiker de snelheid. (Pathak merkte op: “Niemand is geduldig.”) “We zouden bijvoorbeeld nooit zoiets zwaars als GPT-5 gebruiken alleen voor onderwerpdetectie of entiteitsextractie”, zei hij. Booking.com hanteert een vergelijkbare elastische aanpak als het gaat om tracking en beoordelingen: als het algemene tracking is waarvan iemand anders beter is in het opbouwen en over horizontale capaciteiten beschikt, zullen zij het kopen. Maar als dit gevallen zijn waarin merkrichtlijnen moeten worden toegepast, zullen ze hun eigen beoordelingen opbouwen. Uiteindelijk werd Booking.com ‘super anticiperend’, wendbaar en flexibel. “Op dit moment zijn we, gezien alles wat er met AI gebeurt, een beetje huiverig om door eenrichtingsdeuren te lopen”, zegt Pathak. “We willen dat zoveel mogelijk beslissingen omkeerbaar zijn. We willen niet blijven steken in een beslissing die we niet binnen twee jaar terug kunnen draaien.”
Wat andere bouwers kunnen leren van het AI-traject van Booking.com
Het AI-traject van Booking.com kan als een belangrijk model dienen voor andere bedrijven. Terugkijkend erkende Pathak dat hij begon met een “behoorlijk ingewikkelde” technologiestapel. Ze bevinden zich nu op een goede plek, “maar we hadden waarschijnlijk met iets veel eenvoudigers kunnen beginnen en zien hoe klanten ermee omgingen.” Dat gezegd hebbende, gaf hij dit waardevolle advies: als je net begint met LLM’s of agenten, zullen kant-en-klare API’s het prima doen. “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 een use case maatwerk vereist dat niet beschikbaar is via een standaard API-aanroep, is het zinvol om gebruik te maken van interne tools. Hij benadrukte echter: 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.” Identificeer de aansluiting op de productmarkt en kijk dan naar ecosystemen, adviseerde hij, maar schrap niet zomaar de oude infrastructuur 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 snel af”, merkte Pathak op. “Neem geen eenzijdige beslissingen voordat u zeker weet dat dit de oplossing is die u wilt volgen.”
