Genie - Uber'ın üretken yapay zeka destekli On-Call Copilot'u

• Hızla değişen teknoloji ortamında güçlü bir on-call operasyonunu sürdürmek, hizmetlerin sorunsuz çalışmasını sağlamak açısından kritik önem taşıyor
• Platform mühendisliği ekipleri, on-call planlamasını, olay müdahalesini, kritik anlarda iletişimi ve Slack® kanallarındaki güçlü müşteri desteğini verimli şekilde yönetmekte zorlanıyor
• On-call mühendisleriyle iletişimi ve soru yanıtlama sürecini optimize etmek için üretken yapay zeka kullanan on-call copilot'u Genie anlatılıyor

Daha yakından bakış: sorun ve motivasyon

• Uber'de Michelangelo ekibi gibi çeşitli ekiplerin, iç kullanıcıların yardım isteyebildiği Slack destek kanalları bulunuyor
• Bu kanallarda aylık ortalama 45.000 soru soruluyor
• Soru hacminin yüksek olması ve uzun yanıt bekleme süreleri, kullanıcıların ve on-call mühendislerinin üretkenliğini düşürüyor

Zahmetli süreç

• Genelde bir kullanıcı Slack kanalında soru sorduğunda, on-call mühendisinin yanıtını beklemesi gerekiyor
• On-call mühendisi ya kullanıcının ilk sorusunu yanıtlıyor ya da daha fazla ayrıntı istiyor
• Kullanıcı da takip soruları sorabiliyor, daha fazla açıklık isteyebiliyor veya ek bilgi sağlayabiliyor
• Bu da yeniden on-call mühendisinin yanıtını beklemeyi gerektiren bir durum yaratıyor
• Kullanıcının sorusu, birden fazla gidip gelmeli iletişimin ardından çözülebiliyor

Bilgi bulmanın zorluğu

• Birçok soru mevcut dokümanlara bakılarak yanıtlanabilse de, bilgilerin Uber'in Engwiki adlı iç wiki'sine, dahili Stack Overflow'a ve başka yerlere dağılmış olması nedeniyle belirli bir yanıtı bulmak zorlaşıyor
• Bunun sonucunda kullanıcılar çoğu zaman aynı soruları tekrar tekrar soruyor ve bu da yüzlerce Slack kanalında on-call desteğine yüksek talep yaratıyor

Mimari zorluklar

• On-call copilot'unu oluşturmak için, LLM modelinin fine-tune edilmesi ile Retrieval-Augmented Generation (RAG) yaklaşımının kullanılması arasında seçim yapıldı
• Fine-tuning, LLM'in öğrenebileceği yüksek kaliteli ve çeşitli örnekler içeren özenle derlenmiş veriler gerektiriyor
• Ayrıca modeli yeni örneklerle güncel tutmak için hesaplama kaynaklarına da ihtiyaç duyuluyor
• Buna karşılık RAG, başlangıçta çok sayıda farklı örnek gerektirmiyor
• Bu da copilot'un piyasaya çıkış süresini kısalttığı için bu yaklaşım tercih edildi

On-call copilot'u oluştururken halüsinasyonları çözme, veri kaynaklarını koruma ve kullanıcı deneyimini iyileştirme gibi birkaç zorluk yaşandı. Her bir zorluğun nasıl ele alındığı özetleniyor.

Halüsinasyon konusunda şu noktalara odaklanıldı:

• Yanıt doğruluğu: Soruya ilişkin ilgili bilgi geri getirilerek LLM motorunun yanlış veya yanıltıcı bilgi üretmesi önleniyor
• Doğrulama mekanizmaları: Halüsinasyon ihtimalini azaltmak için copilot'un yanıtlarını yetkili kaynaklara karşı doğrulayan yöntemler uygulanıyor
• Sürekli öğrenme: Copilot'un en güncel verilere erişmesi sağlanarak doğruluğu artırılıyor

Veri güvenliği için, Slack kanallarına açılamayacak çok sayıda veri kaynağı bulunduğundan, toplanacak veri kaynakları dikkatle seçildi

Kullanıcı deneyimini iyileştirmek için şu şekilde tasarlandı:

• Sezgisel arayüz: Kullanıcıların copilot ile verimli şekilde etkileşime girebileceği, kullanımı kolay bir arayüz tasarlandı
• Geri bildirim döngüsü: Copilot'un performansını sürekli iyileştirmek için kullanıcıların yanıtlara geri bildirim verebileceği bir sistem oluşturuldu

Böylece güvenilir, kullanıcı dostu ve güvenli bir on-call copilot geliştirilirken bu zorluklar ele alındı

Yapıya derinlemesine bakış

• On-call copilot'u Genie'nin mimarisine bakılıyor
• Özetle, Uber'in iç wiki'si, dahili Stack Overflow'u ve mühendislik gereksinim dokümanları gibi iç veri kaynakları scrape edilerek OpenAI embedding modeliyle bu kaynaklardan vektörler oluşturuluyor
• Bu embedding'ler vektör veritabanında saklanıyor
• Ardından kullanıcı Slack kanalında bir soru paylaştığında, soru bir embedding'e dönüştürülüyor
• Servis, vektör veritabanında soruyla ilişkili ilgili embedding'leri arıyor
• Embedding'lerle indekslenen sonuçlar, yanıt almak için LLM'e gönderilen prompt'un parçası olarak kullanılıyor

Veri hazırlama, embedding ve serving için artifact push aşamaları, Apache Spark™ kullanan RAG uygulamaları için genelleştirilebiliyor. Bu ortak aşamalar, RAG uygulamalarının temelini oluşturuyor

ETL

Veri hazırlama

• Spark uygulaması, Uber'in Engwiki'si veya Uber Stack Overflow API'si üzerinden her veri kaynağından içerik çekiyor
• Bu veri hazırlama aşamasının çıktısı bir Spark dataframe'i oluyor
• Şemada bir sütunda Engwiki bağlantısı, diğer sütunda ise Engwiki içeriği yer alıyor ve her ikisi de string formatında tutuluyor

Embedding oluşturma

• Veri scrape edildikten sonra, OpenAI embedding modeli kullanılarak embedding'ler oluşturuluyor ve Uber'in Blob depolaması olan Terrablob'a push ediliyor
• Oluşturulan embedding'lere yalnızca Engwiki alanıyla ilişkili belirli Slack kanalları üzerinden erişilebiliyor
• Çıktı formatı, chunk içeriğini o chunk'ın ilgili vektörüne eşleyen bir şemaya sahip dataframe'dir
• Uber'in iç wiki içeriği langchain kullanılarak chunk'lara bölünüyor ve embedding'ler PySpark UDF üzerinden OpenAI tarafından üretiliyor

Pusher

• Vektörlerin Terrablob'a nasıl push edildiği gösteriliyor
• Vektörlerin nasıl push edildiği açıklanıyor
• Veri kaynaklarından Sia'ya veri almak için bir bootstrap işi tetikleniyor
• Sia, Uber'in dahili vektör veritabanı çözümü
• Ardından indeks oluşturma ve birleştirme için iki Spark işi tetikleniyor ve Terrablob'dan veri alınıyor
• Tüm leaf düğümler, Terrablob'da saklanan temel indeks ve snapshot'ları senkronize edip indiriyor
• Arama sırasında sorgu doğrudan her bir leaf'e gönderiliyor

Knowledge Service

• Genie'de Knowledge Service adlı bir backend servis bulunuyor
• Gelen sorgular önce embedding'e dönüştürülüyor, ardından vektör veritabanından en alakalı chunk'lar getirilerek tüm gelen sorgular için yanıt üretiliyor

Maliyet takibi

• Maliyet takibi için Slack istemcisi veya diğer platformlar Knowledge Service'i çağırdığında, bir UUID Knowledge Service'e iletiliyor
• Knowledge Service daha sonra bu UUID'yi context header üzerinden Michelangelo Gateway'e aktarıyor
• Michelangelo Gateway, LLM'e geçiş yapan bir passthrough servis olduğundan, bu UUID maliyet takibi için kullanılan denetim kayıtlarına eklenebiliyor

Genie performans değerlendirmesi

Ölçüm yöntemi

• Kullanıcılar, Genie'nin yanıtındaki ilgili butonlara tıklayarak Slack içinde anında geri bildirim verebiliyor

• Kullanıcılara şu seçenekler sunuluyor:

  • Çözüldü: Yanıt sorunu tamamen çözdü
  • Yardımcı oldu: Yanıt kısmen yardımcı oldu ama kullanıcı daha fazla desteğe ihtiyaç duyuyor
  • Yardımcı olmadı: Yanıt yanlış veya alakasızdı
  • Alakasız: Kullanıcının on-call desteğine ihtiyacı var ve Genie yardımcı olamıyor (örneğin code review gibi durumlarda)

• Kullanıcı geri bildirim bıraktığında, Slack eklentisi bunu alıyor ve belirli bir Kafka topic'i kullanarak geri bildirimi ve ilgili metadata'yı Hive tablosuna stream ediyor

• Daha sonra bu metrikler dashboard'da görselleştiriliyor

Performans değerlendirmesi

• Genie kullanıcılarına özel değerlendirme çalıştırma seçeneği sunuluyor
• Kullanıcılar halüsinasyon, yanıt alakalılığı veya kullanım senaryoları için önemli gördükleri diğer metrikleri değerlendirebiliyor
• Bu değerlendirme, retrieval ve generation gibi ilgili tüm RAG bileşenlerini daha iyi ayarlamak için kullanılabiliyor

Değerlendirme süreci, zaten oluşturulmuş Michelangelo bileşenlerini kullanan ayrı bir ETL hattı. Genie'nin bağlamı ve yanıtı Hive'dan alınarak Slack metadata'sı ve kullanıcı geri bildirimi gibi diğer ilgili verilerle join ediliyor. İşlenip Evaluator'a iletiliyor. Evaluator belirtilen prompt'u alıyor ve Judge olarak LLM'i çalıştırıyor. Belirlenen metrikler çıkarılarak değerlendirme raporuna dahil ediliyor ve kullanıcılar bu rapora UI üzerinden erişebiliyor

Doküman değerlendirmesi

• Doğru bilgi retrieval'ı, kaynak dokümanların açıklığına ve doğruluğuna bağlı
• Dokümanların kalitesi düşükse, LLM ne kadar iyi çalışırsa çalışsın iyi performans göstermesinin bir yolu yok
• Bu nedenle dokümanları değerlendirebilme ve doküman kalitesini iyileştirmek için uygulanabilir öneriler sunabilme yeteneği, verimli ve etkili bir RAG sistemi için kritik önemde

Doküman değerlendirme uygulamasının iş akışı gösteriliyor. Veri scrape edildikten sonra, bilgi tabanındaki dokümanlar bir Spark dataframe'ine dönüştürülüyor. Dataframe'deki her satır, bilgi tabanındaki tek bir dokümanı temsil ediyor. Ardından LLM, Judge olarak çağrılarak değerlendirme işleniyor. Burada kullanıcı tanımlı değerlendirme prompt'u ile LLM'e veri sağlanıyor. LLM, değerlendirme puanını; puana ilişkin açıklamayı ve her dokümanın kalitesini artırmak için uygulanabilir önerileri birlikte döndürüyor. Tüm bu metrikler, kullanıcıların Michelangelo UI üzerinden erişebildiği bir değerlendirme raporu olarak yayımlanıyor

Zorluklara çözümler

• Halüsinasyonları azaltmak için, vektör veritabanından alınan prompt'ların LLM'e gönderilme biçimi değiştirildi
  • Vektör veritabanından alınan tüm sonuçlara, kısmi bağlamla birlikte ilgili kaynak URL'si açıkça eklendi
  • LLM'den yalnızca verilen çeşitli alt bağlamlara dayanarak yanıt vermesi ve yanıtta alıntılanacak kaynak URL'lerini döndürmesi istendi
  • Tüm yanıtlar için kaynak URL sağlanmaya çalışıldı
• OpenAI ile embedding oluştururken veya önemli veri kaynaklarına erişimi olmayan kişilere Slack üzerinden veri sızdırmamak için, Uber mühendislerinin büyük çoğunluğu tarafından yaygın şekilde erişilebilen veri kaynakları önceden özenle seçildi ve embedding üretiminde yalnızca bu kaynakların kullanılmasına izin verildi
• Genie'nin soruları yanıtlama potansiyelini en üst düzeye çıkarmak için yeni bir etkileşim modu geliştirildi
  • Bu modda kullanıcılar takip sorularını daha rahat sorabiliyor ve Genie'nin yanıtlarını daha dikkatli okumaya teşvik ediliyor
  • Genie soruyu yanıtlayamazsa, kullanıcılar sorunu kolayca on-call desteğine escalate edebiliyor

Yeni etkileşim modunda kullanıcı bir soru sorduğunda, Genie sağlanan sonraki adım işlem butonlarıyla birlikte yanıt veriyor. Bu butonlar sayesinde kullanıcılar kolayca takip sorusu sorabiliyor, soruyu çözüldü olarak işaretleyebiliyor veya insan desteğine başvurabiliyor

Sonuçlar

• Eylül 2023'teki lansmandan bu yana Genie, varlığını 154 Slack kanalına genişletti ve 70 binden fazla soruyu yanıtladı
• Genie, etkisinin arttığını gösteren %48,9'luk bir faydalılık oranına sahip
• Lansmandan bugüne kadar 13.000 saatlik mühendislik zaman tasarrufu sağladığı tahmin ediliyor

Gelecek

• Genie, on-call yönetimini sadeleştirmek, olay müdahalesini optimize etmek ve ekip iş birliğini iyileştirmek için tasarlanmış son teknoloji bir Slack botu
• Basitlik ve etkililiğe odaklanılarak geliştirilen Genie, kapsamlı bir asistan görevi görüyor ve mühendislik ekiplerinin on-call sorumluluklarını sorunsuz şekilde yerine getirmesine yardımcı oluyor
• Bu on-call asistan copilot'u, kullanıcıların ve on-call mühendislerinin her platformun Slack kanalları içinde etkileşim kurma ve katılım sağlama deneyimini bütünüyle dönüştürebilir
• Ayrıca Michelangelo veya IDE gibi her ürün içinde, kullanıcıların on-call desteğini beklemeden ürüne özel Slack kanallarında ya da ürün içinde ürüne özel yardımı bulma deneyimini de dönüştürebilir

Sonuç

• On-call asistan copilot'u Genie, mühendislik ekiplerinin on-call işlerini yönetme biçimini dönüştürüyor
• Otomatik çözümü teşvik edip içgörülü analizler sunarak Genie, ekiplerin on-call sorumluluklarını verimli ve etkili biçimde yerine getirmesine destek oluyor

GN⁺ yorumu

• Genie, Uber'in çok sayıdaki Slack kanalında kullanıcı sorularını yanıtlayarak mühendislerin zamanını kazandıran ve kullanıcı deneyimini iyileştiren yenilikçi bir on-call copilot'u
• Genie'nin başarısı, makine öğrenimi teknikleri ile insan uzmanlığının güçlü birleşimini gösteriyor. Sorulara doğru ve faydalı yanıtlar sağlamak için büyük veri ve LLM'lerden yararlanıyor
• Ancak Genie'nin hâlâ sınırlamaları ve geliştirme alanları var. Halüsinasyon sorununu tamamen çözebilmiş değil ve zaman zaman yanlış veya yanıltıcı bilgi verebiliyor. Sistemin sürekli izlenmesi ve kullanıcı geri bildirimleriyle iyileştirilmesi gerekiyor
• Bir diğer değerlendirme konusu veri güvenliği ve gizlilik. Genie'nin işlediği veriler hassas ve gizli olabilir; bu nedenle güvenli işleme ve erişim kontrolü kritik önem taşıyor
• Gelecekte Genie, yanıt kalitesini artırma, daha fazla veri kaynağını entegre etme ve güvenliği güçlendirme yönünde gelişebilir. Ayrıca Genie benzeri copilot'ların başka iş alanlarına genişletilmesi de mümkün
• Otomatik müşteri desteğinden satış desteğine, hatta kodlama desteğine kadar yapay zeka destekli asistanlar çok çeşitli görevlere uygulanabilir. Bu tür araçlar çalışan verimliliğini artırabilir ve kullanıcı deneyimini iyileştirebilir
• Genel olarak Genie, yapay zeka ile insan uzmanlığının nasıl daha iyi çalışma biçimlerine ve müşteri hizmetlerine yol açabileceğini gösteren ilgi çekici bir örnek. Bu teknolojiler gelişmeye devam edecek ve nasıl çalıştığımız ile nasıl etkileşim kurduğumuz üzerinde önemli etkiler yaratması bekleniyor