Toen veel bedrijven nog niet eens nadachten over het gedrag van agenten of infrastructuren, Boeking.com was ze al ‘ tegengekomen’ met zijn zelfgemaakte gespreksaanbevelingssysteem. 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 is een gedisciplineerde, gelaagde, modulaire benadering van de modelontwikkeling nodig: kleine, reisspecifieke modellen voor goedkope, snelle afwerking; 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 sleutels, rangschikking en klantinteractie. Zoals Pranav Pathak, AI-productontwikkelingsleider van Booking.com, aan VentureBeat vroeg 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 algemeen genoeg en heb je vijf agenten die goed zijn in algemene taken, maar dan moet je veel om hen heen orkestreren, en ik denk dat dat nog steeds wordt uitgezocht, om de rest van de industrie te doorgronden.” Bekijk wat er nieuw is Verder dan de piloot podcast hieren blijf lezen 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 generieke tools te vermijden: zoals hij het stelde, moesten de prijs en de aanbeveling gebaseerd zijn op de klantcontext. De eerste pre-gen AI-tool 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 over zijn probleem om te bepalen of het probleem kon worden opgelost via zelfbediening of via een menselijke tussenpersoon. “We zijn begonnen met een architectuur van: ‘je noemt een tool als dat de bedoeling is die je ontdekt, en zo heb je de structuur ontleed'”, legt Pathak uit. “Het leek heel erg op de eerste paar agentische architecturen die uitkwamen in termen van het zinvol maken en definiëren van een tool-oproep.” Zijn team heeft die architectuur sindsdien uitgebreid 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 opschalen, dus met een paar aanpassingen hebben we nu een verdubbeling van de onderwerpregistratie, wat op zijn beurt de bandbreedte van menselijke agenten met 1,5 keer vrijmaakt, zelfs complexe onderwerpen die eerder als ‘overig’ werden geïdentificeerd en escalatie vereisen.” uiteindelijk zorgt dit ervoor dat 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 niet in hun hotelkamer kan komen. Het begint echt op te tellen,’ merkte Pathak op, hoe beter we zijn in de klantenservice, hoe loyaler onze klanten zijn. Doorzoeken, merkte Pathak op. Daarom introduceerde zijn team een gratis tekstvak waarin gebruikers direct op maat gemaakte filters kunnen ontvangen. “Het wordt zo’n belangrijk signaal voor personalisatie in termen van wat je zoekt in je eigen woorden, in plaats van een klikstream”, aldus Pathak. Nu was er nog niet eens een filter is 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, blijft de grens ingewikkeld, benadrukt Pathak klantinformatie, zei Pathak: “De technologie is beschikbaar, we hebben de technische trucs om deze te bouwen. We willen ervoor zorgen dat we geen geheugenobject lanceren dat de toestemming van de klant niet respecteert, dat niet erg natuurlijk aanvoelt.”
Balans vinden tussen bouwen en kopen
Naarmate agenten volwassener worden, staat Booking.com voor een belangrijke 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 de architectuur opsluiten in dure langetermijnpaden. De strategie van Pathak is: generaliseer waar mogelijk, specialiseer waar nodig en houd het agentontwerp flexibel om robuustheid te garanderen. Pathak en zijn team zijn “zeer alert” op gebruiksscenario’s en evalueren waar meer algemene, herbruikbare agenten of meer taakspecifieke agenten moeten worden gebouwd. Ze streven ernaar om voor elke toepassing 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 stijgen de verwachtingen van gebruikers. (Pathak merkte op: “Niemand is geduldig.”) “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 waarbij iemand anders beter is in het opbouwen en horizontale capaciteit heeft, kopen zij die. Maar als het gevallen betreft waarin brandrichtlijnen moeten worden gehandhaafd, bouwen ze hun eigen evaluaties op. Uiteindelijk was Booking.com vaak ‘super anticiperend’, wendbaar en flexibel. “Op dit moment, met alles wat er gebeurt met kunstmatige intelligentie, zijn we een beetje niet geneigd om door eenrichtingsdeuren te gaan”, zei Pathak. “We willen dat zoveel mogelijk van onze beslissingen omkeerbaar zijn. We willen niet vastzitten in een beslissing die we over twee jaar niet meer kunnen terugdraaien.”
Wat andere ontwikkelaars kunnen leren van het AI-traject van Booking.com
Het AI-traject van Booking.com zou kunnen dienen als een belangrijke blauwdruk voor andere bedrijven. Terugkijkend erkende Pathak dat ze begonnen met een “behoorlijk ingewikkelde” technologiestapel. Ze zitten er nu goed mee, “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 genoeg maatwerk met API’s zodat je al veel invloed kunt uitoefenen voordat je besluit meer te doen.” Aan de andere kant, als een use case maatwerk vereist dat niet beschikbaar is via een standaard API-aanroep, is dat een zaak voor interne tools. Toch benadrukte hij: begin niet met ingewikkelde dingen. Bespreek het “eenvoudigste, meest pijnlijke probleem dat je kunt vinden en de eenvoudigste, meest voor de hand liggende oplossing ervoor.” Identificeer de marktgeschiktheid van het product en onderzoek vervolgens de ecosystemen, adviseerde hij, maar ruk niet zomaar de oude infrastructuur 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 heel zeker van bent dat dit de oplossing is die u wilt gebruiken.”
