Giriş
Konteyner taşımacılığında “müşteri sesi” çoğu zaman raporların içinde kaybolur; aksiyon alana kadar da tazeliğini yitirir. Hapag-Lloyd’un hikâyesi, geri bildirimi bir metin yığını olmaktan çıkarıp operasyonel bir sinyale dönüştürmenin tasarım problemine odaklanıyor.
🧩 Ne oldu?
– AWS ML Blog’da 5 Mayıs 2026’da yayımlanan yazıya göre Hapag-Lloyd, daha önce iki haftada bir CSV dışa aktarımlarıyla manuel yürüttüğü geri bildirim okuma/tema-duygu sınıflandırma işini otomatikleştirdi.
– Çözüm; Amazon Bedrock (Claude Sonnet 4.6), Amazon OpenSearch Service/Elasticsearch ve LangChain/LangGraph ile kurulup; S3, Lambda (günlük), ECS, SES gibi bileşenlerle üretime bağlandı.
– Güvenlik/uyum için Bedrock Guardrails, yoğun trafik için EU bölgelerine dağıtılan Cross-Region Inference Service (CRIS) uç noktası kullanıldı; chatbot bilgi tabanı olarak OpenSearch indeksine yaslandı.
🎯 Neden önemli?
Müşteri geri bildirimi analizi “NLP projesi” gibi anlatılsa da asıl mesele karar döngüsünün hızıdır. İki haftada bir yapılan manuel okuma, sorunları doğru tespit etse bile geç kalmaya mahkûmdur; özellikle global operasyonu olan yapılarda.
Hapag-Lloyd ölçeğinde (313 gemi, 2,5 milyon TEU filo kapasitesi; toplam konteyner kapasitesi 3,7 milyon TEU; 140 ülkede 400+ ofis; 133 servisle 600+ liman) geri bildirim, doğal olarak çok dilli, dağınık ve bağlam bağımlıdır. Bu yüzden “sadece duygu analizi” tek başına az şey söyler; tema çıkarımı ve aksiyona bağlanan özet, gerçek değeri üretir.
Bir diğer kritik nokta: Kurumsal ortamda üretken yapay zekâ, doğruluk kadar güvenlik ve izlenebilirlikle değerlendirilir. Guardrails gibi kontrol katmanları ve dayanıklılık (CRIS) tercihi, “demo” ile “operasyonel sistem” arasındaki farkı belirler.
👥 Kim etkilenir?
– Müşteri deneyimi (CX) ve şikâyet yönetimi ekipleri
– Operasyon ve saha ekipleri (liman süreçleri, rezervasyon, dokümantasyon akışları)
– Ürün sahipleri ve servis tasarımı ekipleri (hangi tema hangi akış kırılıyor?)
– Veri/ML ve platform ekipleri (OpenSearch, Bedrock, güvenlik, maliyet)
– Uyum ve bilgi güvenliği (müşteri verisi, erişim politikaları, çıktının denetimi)
AI Sözlük görüşü
Bu mimarinin asıl fikri, “LLM her şeyi bilir” yaklaşımı değil; kurumsal hafızayı (geri bildirimleri) önce aranabilir bir zemine (OpenSearch indeksi) oturtup, modeli bu zeminin üzerinde konuşturmak. Yani model, varsayım üretmek yerine kanıtla konuşmaya zorlanıyor. Bu, özellikle yüksek hacimli ve hata maliyeti yüksek sektörlerde daha sürdürülebilir bir çizgi.
Risk/ödül dengesi net: Ödül tarafında hız (günlük çalışan akış), ölçeklenebilir içgörü üretimi ve ekipler arası ortak dil var. Risk tarafında ise halüsinasyon, hassas veri sızıntısı ve “yanlış tema = yanlış aksiyon” maliyeti bulunuyor. Guardrails bu riski azaltır ama sıfırlamaz; asıl güvence, ölçüm ve geri besleme döngüsünün tasarlanmasıdır.
Buradan çıkarılacak tasarım tercihi dersi: Daha fazla model çağrısı ve daha karmaşık prompt zincirleri yerine, önce veri altyapısını düzenle (indeksleme, erişim, sorgu), sonra modeli bu kısıtlı alanda çalıştır. Daha az “zeka gösterisi”, daha çok “doğru bağlam” çoğu zaman daha iyi sonuç verir.
👀 Ne izlenmeli?
– Tema çıkarım kalite metriği: sınıf bazlı precision/recall veya en azından örneklem denetiminde “doğru tema” oranı (haftalık trend).
– Duygu/tema model sapması: dil, ülke veya kanal bazında hata türleri (ör. olumsuzun nötr çıkması) ve “unknown/other” oranı.
– Maliyet-per-içgörü: 1.000 geri bildirim başına Bedrock çağrı maliyeti ve ortalama gecikme (latency); yoğun trafik anlarında CRIS öncesi/sonrası fark.
– Aksiyon etkisi: üretilen içgörüden açılan ticket sayısı, kapanma süresi ve tekrar eden şikâyet oranındaki değişim.
