Standart retrospektifler, temel davranışın belirleyici olmadığı, maliyetin kullanımla öngörülemeyen şekillerde ölçeklendiği ve geçen ay dikkatlice ayarlanmış istemlerin, model sağlayıcının bir güncelleme göndermesi nedeniyle bozulabileceği ürünler için tasarlanmamıştır.
LLMs ile geliştirme yapıyorsanız, yapay zeka ürünlerinin başarılı ve başarısız olma yollarını açıklayan retrospektiflere ihtiyacınız vardır. Her retroyu üç saatlik bir metrik incelemesine dönüştürmeden bunu nasıl yapabileceğinizi burada bulabilirsiniz.
Normal Retro Formatınız Neden Yetersiz Kalıyor
Geleneksel retrospektifler öngörülebilir bir model etrafında inşa edilir: Kodu yazarsınız, gönderirsiniz, o da yazdıklarınızı yapar. İlginç sorunlar süreç, iletişim ve önceliklerle ilgilidir.
Yapay zeka ürünleri bu modeli çeşitli şekillerde bozar:
Çıktılar aynı girişler arasında değişiklik gösterir. Aynı kullanıcı mesajına sahip aynı istem, aramalar arasında farklı kalitede sonuçlar üretebilir. Bu, "makinemde çalışıyor" ifadesinin "beş dakika önce test ettiğimde çalıştığına" kadar uzandığı anlamına geliyor.
Arıza modları yenidir. Halüsinasyonlar, istem enjeksiyonu, önyargı güçlendirme ve bağlam penceresi taşması, geleneksel hata kategorileriyle eşleşmiyor. Ekibinizin bunları tartışabilmesi için belirli sözcüklere ve çerçevelere ihtiyacı var.
Maliyetler kullanımla orantılıdır ve tahmin edilmesi zordur. Geleneksel bir özelliğin maliyeti, oluşturma maliyeti kadardır ve daha sonra mevcut altyapınızda çalışır. LLM özelliğinin maliyeti her kullanıcı etkileşimiyle birlikte artar ve viral bir an, bütçenizi bir gecede uçurabilir.
Kalite görünmez bir şekilde düşer. Sağlayıcınızdan alacağınız bir model güncellemesi, çıktı kalitesini herhangi bir bildirimde bulunmadan hafifçe değiştirebilir. İstemleriniz belirli bir model sürümü için optimize edildi; bu optimizasyon aktarılmayabilir.
Bunların hiçbiri geriye dönük değerlendirmelerin daha az önemli olduğu anlamına gelmiyor. Bu, farklı şeylere bakmaları gerektiği anlamına geliyor.
Yapay Zeka Ürün Retroları için Dört Lens
Klasik "neyin yolunda gittiği / neyin gitmediği / eylem öğeleri" yapısı yerine, AI ürün retrospektifinizi dört farklı mercek etrafında düzenleyin. Her biri farklı bir sorun kategorisi ortaya çıkarıyor.
Lens 1: Model Performansı
Bu, yapay zekanın teknik düzeyde işini yapıp yapmadığıyla ilgili.
Tartışılacak sorular:
- Değerlendirme puanlarımız nasıl bir trend gösteriyor? Doğru şeyleri mi ölçüyoruz?
- Model güncellemeleri veya hızlı değişikliklerle ilişkili kalite değişimlerini fark ettik mi?
- Bu dönemdeki en kötü başarısızlık durumlarımız nelerdir? Ortak noktaları neler?
- Modelin sürekli olarak sorun yaşadığı ve farklı şekilde ele almamız gereken kullanım durumları var mı?
Odada ihtiyacınız olan şeyler: değerlendirme sonuçları, hata günlükleri, kullanıcıların bildirdiği veya QA tarafından işaretlenen hatalı çıktı örnekleri.
Objektif 2: Hızlı Mühendislik Etkinliği
İstemler ürününüzün kontrol yüzeyidir. Özel ilgiyi hak ediyorlar.
Tartışılacak sorular:
- Hangi hızlı değişiklikler sonuçları gerçekten iyileştirdi, hangileri ise ters hareketlerdi?
- İstem sürümlerini sistematik olarak mı izliyoruz, yoksa geçici mi?
- Kırılgan istemlerimiz var mı? Çalışıyorlar ancak küçük girdi değişiklikleriyle bozuluyorlar mı?
- Diğer mühendislik işlerine kıyasla hızlı yinelemeye ne kadar zaman harcıyoruz? Bu oran doğru mu?
Odada ihtiyacınız olan şey: anlık değişikliklerin ve bunların ölçülen etkilerinin günlüğü. Eğer buna sahip değilseniz ilk yapmanız gereken o takip sistemini kurmak olacaktır.
Lens 3: Kullanıcı Deneyimi
Kullanıcılar hâlâ hayal kırıklığı yaşarken model teknik olarak iyi performans gösteriyor olabilir.
Tartışılacak sorular:
- Kullanıcılar yapay zeka tarafından oluşturulan çıktılara nasıl tepki veriyor? Geri bildirimde ne yazıyor?
- Kullanıcılar AI önerilerini nerede geçersiz kılıyor, düzenliyor veya yok sayıyor? Bunlar sinyal açısından zengin anlardır.
- Yapay zeka deneyimli kullanıcılar için değer katıyor ancak yeni kullanıcıların kafasını karıştırıyor mu, yoksa tam tersi mi?
- Güven sorunları var mı? Kullanıcılar yapay zekanın ürettiği her şeyi tekrar kontrol ediyor mu, yoksa ona aşırı mı güveniyorlar?
Odada ihtiyacınız olan şeyler: kullanıcı geri bildirimi, kullanım analizleri (özellikle bırakma ve düzenleme oranları) ve AI özellikleriyle ilgili destek biletleri.
Lens 4: Maliyet ve Sürdürülebilirlik
Yapay zeka özellikleriniz ekonomik açıdan sürdürülebilir değilse kalitenin ve kullanıcı deneyiminin hiçbir önemi yoktur.
Tartışılacak sorular:
- Her bir yapay zeka özelliği için kullanıcı etkileşimi başına gerçek maliyetimiz nedir?
- Büyüme tahminlerimize göre maliyet nasıl ölçekleniyor? Doğrusal mı yoksa maliyet yükselticilerimiz var mı?
- Anlamlı kalite etkisi olmadan maliyetleri azaltma fırsatları var mı? (Önbelleğe alma, daha kısa istemler, daha basit görevler için daha küçük modeller.)
- Harcadığımız tokenlardan değer mi alıyoruz yoksa şişirilmiş istemler mi gönderiyoruz ve kullanmadığımız çıktıları mı işliyoruz?
Odada ihtiyacınız olan şeyler: Özelliklere göre ayrılmış faturalandırma verileri, etkileşim başına maliyet hesaplamaları ve kullanım artış eğilimleri.
Toplantıyı Yönetme
Süre: 60 dakika. Ekibiniz disiplinliyse bunu 45'te yapabilirsiniz ancak bunu 30'a sıkıştırmaya çalışmayın.
Sıklık: Yapay zeka özelliklerini aktif olarak yineliyorsanız iki haftada bir. Aylık olarak işler istikrara kavuşunca. Anlamlı hiçbir şey değişmediyse sırf takvimde var diye bir plan çalıştırmayın.
Kimler orada olmalı: Ürün yöneticisi, yapay zeka özellikleri üzerinde çalışan mühendisler ve model çıktılarını veya kullanıcı geri bildirimlerini inceleyen herkes. Şirketin tamamına ihtiyacınız yok.
İşe yarayan biçim:
Verilerin gözden geçirilmesi (10 dakika): Birisi son retrospektiften bu yana temel ölçümleri sunuyor. Henüz görüş yok; yalnızca rakamlar var. Bu, odadaki en gürültülü kişinin konuşmayı kendi anekdotuna bağlamasını engeller.
Dört mercekli tartışma (35 dk): Her merceğin üzerinden geçin. Her birine eşit zaman harcamanıza gerek yok; bazı dönemlerde maliyet en önemli konu olacaktır; diğer zamanlarda ise kalite gerilemesi hakim olacaktır. Verilerin odaklanacağınız yere rehberlik etmesine izin verin.
Eylem öğeleri (15 dk.): Spesifik olun. "Hız kalitesini artırın" bir eylem öğesi değildir. "Mevcut özetleme istemini v7 adayıyla karşılaştıran A/B testini çalıştırın, ROUGE puanlarını ve kullanıcı düzenleme oranlarını ölçün, bir sonraki retroda rapor verin" bir eylem öğesidir.
İzlenmeye Değer Metrikler (ve İzlemeye Değer Olmayan Bazıları)
Düzinelerce yapay zeka ölçümünü takip eden ayrıntılı bir kontrol paneli oluşturma isteği var. Diren. Gerçekten bilgilendirici olan küçük bir metrik kümesiyle başlayın ve yalnızca belirli bir soruyu yanıtlamanız gerektiğinde daha fazlasını ekleyin.
Yüksek değerli metrikler:
- Görev başarı oranı — Yapay zeka, kullanıcının istediğini başardı mı? Bu en önemli ölçümdür ve genellikle ölçülmesi en zor olanıdır. Kaba bir proxy bile ("kullanıcı çıktıyı düzenlemeden kabul etti") bile hiç yoktan iyidir.
- Başarılı etkileşim başına maliyet — Yalnızca arama başına maliyet değil, kullanıcıya gerçekten yardımcı olan sonuç başına maliyet. Bu, yalnızca hacme değil değere odaklanmanızı sağlar.
- Kullanıcı düzenleme oranı — Kullanıcılar yapay zeka tarafından oluşturulan içeriği ne sıklıkla değiştirir? Düzenleme oranının yüksek olması mutlaka kötü değildir (bu, kullanıcıların aktif olarak etkileşimde bulunduğu anlamına gelebilir), ancak düzenleme oranının artması kalitenin düştüğünü gösterir.
- p95'teki gecikme — Kötü deneyimleri gizleyen ortalama gecikme değil. 95'inci yüzdelik dilim size en şanssız ama aşırı olmayan kullanıcılarınızın nelerle uğraştığını gösterir.
Yararlı görünen ancak çoğu zaman olmayan metrikler:
- Ham jeton sayısı — Size değeri değil hacmi bildirir. Faturalandırma açısından ilgi çekicidir ancak ürün kararları açısından ilgi çekici değildir.
- İstem uzunluğu — Daha uzun olması otomatik olarak daha kötü değildir ve daha kısa olması otomatik olarak daha iyi değildir. Yargıç, uzunluğa değil çıktı kalitesine göre karar verir.
- Model sürümü karşılaştırmaları tek başına — Soyut karşılaştırmalarda GPT-4o ile Claude 3.5'i karşılaştırmak size özel kullanım durumunuz hakkında çok az şey anlatır. Yalnızca gerçek görevlerinizi gerçek değerlendirme kriterlerinizle karşılaştırın.
Zor Konuşmalarla Başa Çıkmak
Yapay zeka ürün retroları, ekiplerin sıklıkla kaçındığı rahatsız edici konuları gün yüzüne çıkarıyor:
"Aslında yapay zekanın iyi olup olmadığını bilmiyoruz." Ekibinizin çıktı kalitesini değerlendirecek sistematik bir yöntemi yoksa bunu kabul edin. Eylem öğesi, her değişiklikten sonra çalıştıracağınız, beklenen çıktıları içeren bir dizi test senaryosundan oluşan minimum bir değerlendirme çerçevesi bile oluşturmaktır.
"Çok fazla harcama yapıyoruz ve buna değip değmeyeceğinden emin değiliz." Bu bir ürün sorusudur, teknik bir soru değil. Yapay zeka özelliği elde tutmayı, dönüşümü veya başka bir iş sonucunu teşvik ediyor mu? Bu çizgiyi çizemiyorsanız yapay zeka özelliklerini değerli oldukları için değil, etkileyici oldukları için geliştiriyor olabilirsiniz.
"Model bazen sorunlu şeyler yapıyor ve bunu nasıl önleyeceğimizden emin değiliz." Güvenlik sorunlarını ele almayın. Model zaman zaman önyargılı, zararlı veya yanıltıcı içerik üretiyorsa bu, dosyalayıp kaldıracağınız "bilinen bir sorun" değil, en öncelikli eylem öğesidir.
"Hızlı mühendisliğimiz tahmine dayalı bir çalışma gibi görünüyor." Genellikle öyledir, özellikle de ilk günlerde. Retro, daha fazla titizlik oluşturmak için iyi bir yerdir: istemler için sürüm kontrolü, A/B test protokolleri ve açık değerlendirme kriterleri.
Retro Analizleri Ürün Kararlarına Bağlama
Bu retrospektiflerin amacı bir ince ayar listesi oluşturmak değil. Daha büyük ürün kararlarını bilgilendirmek içindir:
- Bu yapay zeka özelliğine daha fazla yatırım yapmalı mıyız, yoksa bu bir çıkmaz sokak mı?
- Bu kullanım durumu için doğru modeli mi kullanıyoruz yoksa alternatifleri mi denememiz gerekiyor?
- Mevcut yaklaşımımız ölçeklenebilir mi, yoksa maliyetler kullanıcı marjımızı 10 kat artıracak mı?
- Eklememiz gereken yapay zeka özellikleri var mı, yoksa mevcut olanları güvenilir hale getirmek için daha fazla çaba göstermeli miyiz?
Retro'nuz bu tür kararları etkilemiyorsa, bu yalnızca retrospektif kıyafetleri giyen bir durum toplantısıdır.
NextRetro'yi ücretsiz deneyin — Bir sonraki AI ürün retrospektifinizde Model, İstemler, Kullanıcı Deneyimi ve Maliyet için özel sütunlar içeren dört lensli formatı kullanın.
Son Güncelleme: Şubat 2026
Okuma Süresi: 7 dakika
