Kalite, Test ve Operasyon
Production'da GenAI Agent'larını Değerlendirmek: Booking.com'dan Dersler
Evaluating GenAI Agents in Production: Lessons from Booking.com
Production'daki agent tek bir doğruluk skoruyla ölçülmez; insan etiketiyle kalibre edilmiş judge'larla sonucu, araç kullanımını ve tekrar tekrar başarabilmesini ayrı ayrı ölçersin.
Production'daki agent tek skorla ölçülmez; insanla kalibre edilmiş judge'larla sonucu, araç kullanımını ve tutarlılığı ayrı ayrı ölçmek gerekir.
Büyük platformlar ve eval rehberleri bu katmanlı yapıda birleşiyor; LLM judge'ın güvenilirliği ve trajectory ölçümü ise hâlâ tartışmalı.
Zihinsel model
Agent'ı değerlendirmek sürücü sınavı gibidir: varış noktasına ulaşmak (sonuç), kurallara uymak (araç kullanımı) ve bunu her gün yapabilmek (tutarlılık) ayrı ayrı puanlanır.
Neden
- Agent'ta hata zincirin herhangi bir halkasında doğar; yalnızca sonuca bakan metrik hatanın yerini göstermez.
- Üretken çıktının tek doğru cevabı olmadığı için ölçüm judge'a kalır; judge da insan etiketine göre doğrulanmadıkça önyargı üretir.
- Agent non-deterministiktir; bir kez başarması her seferinde başaracağı anlamına gelmez, tutarlılık ayrı ölçülmelidir.
Kanıt
Booking.com'un paylaştığı örnekte pass^k, sekiz denemeden sonra yüzde 20'nin altına düşüyor.
Booking.com ML & DS Blog, 2026Booking.com'un iç deneylerinde belirsiz araç adları hem görev tamamlamayı hem araç kullanım becerisini düşürdü.
Booking.com ML & DS Blog, 2026Ekiplerin büyük çoğunluğu agent observability kullanırken çevrimdışı eval yapanlar yaklaşık yarıda kalıyor.
LangChain State of Agent Engineering, 2026Karşı görüş
LLM judge'lar konum, uzunluk ve kendini kayırma önyargıları taşır; insan etiketiyle kalibrasyon pahalıdır ve veri dağılımı değiştikçe tekrarlanmalıdır. Trajectory için altın yol çoğu zaman tanımlanamaz, bu yüzden süreç metrikleri yaklaşık kalır.
Kavramlar
Pratikte
- Judge'ı 50 örneklik pilot ve insan etiketli test setiyle doğrulamadan production'a alma.
- Task completion yanında tool call validity ve tool correctness'ı ayrı dashboard'da izle.
- Agent'ı zero-shot, few-shot ve deterministik akış baseline'larıyla kalite, maliyet ve gecikmede yarıştır.
Bir seyahat asistanı aynı soruya bir seferinde iki, bir seferinde altı araç çağırarak cevap verebilir; 'doğru cevap' ise çoğu zaman tek değildir. Bu yüzden klasik test ve tek bir doğruluk metriği agent'lar için yetmiyor. Booking.com'un ML ekipleri 2025 ve 2026'da bu problemi açık yazılarla belgeledi: önce insan etiketli bir golden dataset ile LLM-as-a-judge'ı doğrulamak, sonra agent'ı hem dışarıdan (görev tamamlandı mı) hem içeriden (doğru araç, doğru parametre) ölçmek, en sonda da tutarlılığı pass^k gibi metriklerle sınamak. Ekim 2026 itibarıyla soru daha da büyüdü: Google AI Mode ve ChatGPT gibi üçüncü taraf yüzeyler otel rezervasyonunu kendi agent'larına taşırken, seyahat şirketleri hem kendi agent'larını hem de bu kanallarda görünen davranışlarını ölçmek zorunda. Değerlendirme artık yayın öncesi bir kapı değil, production'da sürekli çalışan bir sistem.
Çıkarımlar
- Judge'ı insan etiketli bir golden dataset ile doğrulamadan agent ölçmeye başlama; ölçtüğün şey judge'ın önyargısı olur.
- İkili ya da az sınıflı metrikler, 1-10 arası skorlardan daha güvenilir judge sonucu verir.
- Sonucu (task completion) ve süreci (tool call validity, tool correctness) ayrı ölç; biri neyin, diğeri nerede bozulduğunu söyler.
- Agent, zero-shot, few-shot ve deterministik akış baseline'larını kalite, maliyet ve gecikmede birlikte geçmiyorsa karmaşıklığı hak etmez.
- Bir kez başarmak demo, her seferinde başarmak üründür; pass^k'yi raporla.
- Seyahatte değerlendirme planını eylemin riskine göre kur: iade ve iptal gibi eylemlerde guardrail ve insan onayı şart.
Alt başlıklar
Agent'ı değerlendirmek neden tek bir LLM çağrısından zor
Tek bir LLM çağrısını değerlendirmek görece basittir: girdi, çıktı, bir ölçüt. Agent ise birden çok adımda düşünür, araç çağırır, araçtan gelen sonucu yorumlar ve kullanıcıyla birkaç tur konuşur. Hata bu zincirin herhangi bir halkasında olabilir: yanlış araç, eksik parametre, doğru verinin yanlış yorumu ya da kullanıcının ikinci mesajında unutulan kısıt.
İkinci zorluk ground truth eksikliği. 'Barselona'da çocuklu aileye uygun, denize yürüme mesafesinde otel' isteğine tek doğru cevap yoktur. Üçüncüsü non-determinizm: aynı istek iki kez gönderildiğinde farklı bir yol izlenebilir. Ve her şey ölçekte olur; bir seyahat platformunda günde on binlerce konuşmanın her birini insanın okuması mümkün değil.
Anti-pattern: demo sırasında elle seçilmiş on soruya bakıp 'iyi çalışıyor' kararı vermek. Production'da kullanıcıların sorduğu dağılım bu on soruya benzemez ve agent'ın zayıf noktası tam da o kuyrukta çıkar.
Ekim 2026 itibarıyla durum
Son on iki ayda agent değerlendirmesi deneysel bir uğraştan platform özelliğine dönüştü. Booking.com Ocak 2026'da GenAI değerlendirme serisinin ikinci yazısını agent'lara ayırdı: black box ve glass box ayrımı, araç kullanım metrikleri ve tutarlılık. Ekim 2026'da ise şirket içi agent platformu AgentHub'ı anlattı; platformda OpenTelemetry ile trace, gömülü LLM judge'lar, dashboard ve guardrail standart bileşen.
Genel tabloda LangChain'in 2026 State of Agent Engineering anketine göre ekiplerin yüzde 89'u agent'ları için observability kullanıyor, ama çevrimdışı eval yapanlar yüzde 52,4, çevrimiçi eval yapanlar yüzde 37,3. Yani çoğu ekip agent'ın ne yaptığını görüyor, iyi yapıp yapmadığını sistematik ölçmüyor. Anthropic'in Ocak 2026 tarihli rehberi gerçek hatalardan türetilmiş 20-50 görevle başlamayı öneriyor.
Seyahat tarafında dağıtım kanalları da değişti. ChatGPT, Ekim 2025'te MCP tabanlı Apps SDK ile Booking.com ve Expedia uygulamalarını açtı; Google ise Ağustos 2026'da AI Mode içinde ABD'de doğrudan otel rezervasyonunu yayına aldı. Değerlendirilmesi gereken yüzey sayısı arttı.
Önce judge'ı değerlendir: golden dataset protokolü
LLM-as-a-judge, bir agent'ın çıktısını başka bir modelin puanlaması demek. Ama judge'ın kendisi doğrulanmadıysa ölçtüğünüz şey agent kalitesi değil, judge'ın önyargısıdır. Booking.com'un Ağustos 2025 yazısındaki protokol bu yüzden insanla başlıyor.
Adımlar şöyle: metriği iş sahibiyle birlikte tanımla; mümkünse ikili ya da az sınıflı yap, çünkü modeller sürekli skor vermekte zorlanır. Yaklaşık 50 örnekle pilot etiketleme yap ve uzmanlar uzlaşana kadar tanımı düzelt. Ardından ideal olarak 500-1.000 örneği etiketle, doğrulama ve test diye ikiye böl. Uzman örneklerin yaklaşık yüzde 10'unu kontrol etsin; hatalı etiket oranı yüzde 10'u geçerse yeniden etiketle. Etiketleyiciler arası düşük uyum çoğu zaman metriğin belirsiz tanımlandığını gösterir.
Judge prompt'u doğrulama setinde macro F1 ile iyileştirilir, test setine yalnızca son ölçümde dokunulur. Önce güçlü bir modelle hedef kalite bulunur, sonra aynı kaliteye yaklaşan ucuz bir model production izlemeye alınır.
Black box: görev tamamlandı mı, baseline'ı geçti mi
Black box değerlendirme agent'ın içine bakmaz; yalnızca konuşmanın tamamına ve sonucuna bakar. Booking.com'un ana metriği task completion: kullanıcının istediği görevlerden kaçı doğru tamamlandı. Tek bir judge konuşmayı, önceden tanımlı görev listesini ve ürün kısıtlarını alır; kullanıcının hangi görevleri istediğini çıkarır ve her birini tamamlandı ya da tamamlanmadı diye işaretler. Görev listesi değiştirilince aynı düzen başka bir agent'a uyarlanabiliyor.
İkinci kural: agent'ı daha basit alternatiflerle yarıştırmak. Zero-shot LLM, few-shot LLM ve LLM destekli deterministik akış birer baseline. Agent bunları kalite, maliyet ve gecikmede birlikte geçmiyorsa karmaşıklığı hak etmiyor. Bunun için input, output ve reasoning token'ları ile saniyedeki istek sayısı ayrı izleniyor.
Kazancı iş etkisine çevirmek de gerekiyor. Yazıdaki örnek: bir milyon kullanıcılı bir senaryoda yüzde 1'lik iyileşme, 500 kullanıcılı bir senaryodaki yüzde 20'lik iyileşmeden daha değerli olabilir.
Glass box: araç kullanımını ölçmek
Glass box değerlendirme ara adımlara bakar ve hatanın nerede doğduğunu gösterir. Dört ölçü öne çıkıyor.
Tool call validity: araç adı doğru mu, zorunlu parametreler var mı, beklenmeyen parametre eklenmiş mi, tipler ve formatlar uyuyor mu. Bu kontrol JSON Schema doğrulamasıyla deterministik yapılır; Berkeley Function Calling Leaderboard'un yaklaşımına benzer. Tool correctness: görev için beklenen araç kümesiyle kullanılanı karşılaştırır; eksik ve gereksiz çağrıları ayrı raporlar, cevaplanamaz bir görevi doğru reddedip reddetmediğine de bakar. Argüman halüsinasyonu: parametre değeri olgusal olarak yanlış mı; kullanıcı Fransa'daki Paris'i sorarken Teksas'taki Paris'i aramak gibi.
Dördüncüsü en az konuşulanı: araç tanımının kalitesi. Judge'lar araç adlarını ve açıklamalarını kontrol eder; adlar açık ve kısaltmasız olmalı, opsiyonel parametre sayısı üçü geçmemeli. Booking.com'un iç deneylerinde belirsiz araç adları hem görev tamamlamayı hem araç kullanım becerisini düşürmüş. Yani bazen agent'ı değil, araç arayüzünü düzeltmek gerekiyor.
Tutarlılık, hafıza ve trajectory
Bir agent'ın bir kez başarması ürün için yeterli değil. pass@k, k denemeden en az birinin başarılı olma olasılığını ölçer ve iyimserdir. pass^k ise k denemenin hepsinin başarılı olmasını ister; kullanıcıya her seferinde güvenilir davranan agent'ın ölçüsü budur. Metrik tau-bench ile yaygınlaştı. Booking.com yazısında tau-retail veri setinde pass^k'nin 8 denemeden sonra yüzde 20'nin altına düştüğü gösteriliyor. Pratik yöntem: her soruyu k farklı şekilde yeniden ifade edip ortalama görev tamamlamayı raporlamak.
Hafıza için iki soru var: hafızadaki bilgi doğru ve ilgili mi, ve hafıza açıkken görev tamamlama gerçekten artıyor mu. İkincisi hafızalı ve hafızasız aynı testi koşarak ölçülür.
Trajectory optimalliği en zor kısım: agent hedefe gereksiz adımlarla mı ulaştı? Altın bir adım dizisi tanımlamak çoğu zaman mümkün değil; bu yüzden iyi ve kötü yolları çift olarak karşılaştıran preference tabanlı judge'lar öneriliyor.
Seyahat ve turizmde nasıl görünüyor
Seyahat, agent değerlendirmesinin zor olduğu bir alan: çok dil, çok taraf ve geri alınması pahalı eylemler. Booking.com'un partner-misafir mesajlaşma agent'ı iyi bir örnek. Platformda günde yaklaşık 250 bin partner-misafir mesajı dolaşıyor; agent bunların on binlercesinde tesis sahibine cevap taslağı öneriyor. Mimari LangGraph, merkezi bir MCP sunucusundaki araçlar ve şablon araması için vektör veritabanı. Guardrail'ler ilginç: gelen mesajda kişisel veri maskeleniyor, iade gibi 'cevap verme' kategorileri ayıklanıyor, güven düşükse agent hiç öneri yapmıyor ve son onay tesis sahibinde. Embedding karşılaştırmasında İngilizce dışı mesajlarda farklı bir model daha iyi çıktığı için dil tespitiyle yönlendirme yapılıyor.
AgentHub yazısındaki ilk örnek de ölçümün değerini gösteriyor: AI Trip Planner'daki soru-cevap akışı deterministikten agentic yapıya geçince answer relevance yüzde 53 artmış, LLM'in cevap vermeyi reddetme oranı yüzde 64 düşmüş. Havayolu ve otelde iptal, iade ve kural yorumu gibi eylemler insan onayı ya da sıkı guardrail ister; değerlendirme planı eylemin riskine göre kurulmalı.
Son gelişmeler
Ekim 2026 itibarıyla
Önce kendi cevabını düşün, sonra aç.
LLM judge'a ne kadar güvenebiliriz? Model kendi kendini puanlıyor gibi.
Doğrulanmamış bir judge'a güvenilmez. Judge bir sınıflandırıcı gibi ele alınmalı: insan etiketli bir test setinde macro F1 ölçülür ve eşik geçilmeden kullanılmaz. Judge ile hedef model aynı aileden ise önyargı riski artar; mümkünse farklı model ve periyodik insan örneklemi kullanılır.
500-1.000 etiketli örnek küçük bir ekip için çok fazla değil mi?
Başlangıç için değil. Yaklaşık 50 örneklik pilotla metriğin tanımı netleşir; ilk eval seti gerçek hatalardan 20-50 görevle kurulabilir. Büyük set, judge'ı production izlemesinde tek başına bırakmadan önce gerekir.
Task completion iyi çıkıyorsa glass box metriklere neden gerek var?
Çünkü task completion düşünce nedenini söylemez. Aynı düşüş yanlış araç seçiminden, eksik parametreden ya da kötü yazılmış bir araç açıklamasından gelebilir. Glass box metrikler hangi katmana müdahale edeceğinizi gösterir; bazen çözüm modelde değil araç arayüzündedir.
Her konuşmayı güçlü ve pahalı bir modelle puanlamak maliyetli değil mi?
Bu yüzden iki aşamalı düzen öneriliyor: geliştirmede güçlü judge ile hedef kaliteyi bul, sonra aynı test setinde ona yaklaşan ucuz bir modeli production izlemesine al. Production'da örnekleme yapmak ve yalnızca alarm veren segmentleri güçlü judge'a göndermek maliyeti daha da düşürür.
Google AI Mode ya da ChatGPT içinden gelen rezervasyonları nasıl değerlendireceğiz?
Üçüncü taraf agent'ın içini göremezsiniz, ama ona açtığınız araçları ve sonuçlarını görürsünüz. MCP ya da API üzerinden gelen çağrılarda tool call validity, argüman hataları ve tamamlanan rezervasyon oranı ölçülebilir. Araç açıklamalarının kalitesi burada daha da önemli, çünkü sizin aracınızı başkasının modeli seçiyor.
Notun kaynakları
- AI Agent Evaluation: practical tips at Booking.com (Booking.com ML & DS Blog, Ocak 2026)
- LLM Evaluation: Practical Tips at Booking.com (Ağustos 2025)
- Introducing AgentHub: Booking.com Platform for Modular Travel AI Agents (Ekim 2026)
- Building a GenAI Agent for Partner-Guest Messaging (Booking.com)
- State of Agent Engineering (LangChain, 2026)
Sunum stili
11 slayt. Tıklarsan sunum o slayttan başlar.
Slayt notları
Tek doğru cevabı olmayan, her seferinde farklı yol izleyen bir sistemi nasıl değerlendirirsiniz? Booking.com'un açık yazıları iyi bir harita sunuyor.
Çoğu ekip judge'ın verdiği sayıya güveniyor ama onu insan etiketiyle hiç karşılaştırmamış.
Etiketleyiciler arası uyum düşükse sorun etiketleyicide değil metrik tanımındadır.
Task completion düşünce sebebini söylemez. Glass box metrikler hangi katmana dokunacağınızı gösterir.
Belirsiz araç adları görev tamamlamayı düşürüyor. Opsiyonel parametreyi üçle sınırlamak iyi bir kural.
Paylaşılan örnekte pass^k sekiz denemeden sonra yüzde 20'nin altına iniyor. Her soruyu k farklı şekilde sorup ortalamayı raporlayın.
AgentHub yazısındaki ilk örnek. Bu farkı görebilmek için aynı judge metriklerinin iki mimaride de koşması gerekiyor.
Güçlü judge geliştirmede, ucuz judge production'da. Alarm veren segmenti hata analizine, bulunan vakayı golden set'e geri koyun.
Booking.com'un mesajlaşma agent'ı sağ üstte: günde on binlerce mesaj, güven düşükse öneri yok, son onay tesis sahibinde.
Bir yılda değerlendirme tekil projelerden platform özelliğine, rezervasyon da üçüncü taraf agent'lara taşındı.
İlk adım: gerçek hatalardan 20-50 görevlik bir set kurun ve judge'ı bu sette insanla karşılaştırın.