# TD-096 · Geri bildirimi işin içinden topla

Başparmak düğmesine az kişi basıyor ve basanlar kullanıcıların çoğunu temsil etmiyor. Kullanıcının çıktıyı kullanmasını, değiştirmesini, yeniden üretmesini ve bırakmasını işin içinden kaydetmek asıl sinyali toplar.

- Adres: https://tandem.komunite.com.tr/desen/geri-bildirimi-isin-icinden-topla
- Yer: Zamanla > Ölçüm
- Seviye: Temel. Her AI özelliğinde olmalı.
- Son inceleme: 28 Ekim 2026, Komünite editörlüğü

## 30 saniyede dene

1. Ürünündeki bir AI çıktısına olumlu oy ver, sonra çıktıyı değiştirip kullan. Kayıtlarda hangisi görünüyor, oy mu, değişiklik mi?
2. Son haftanın kayıtlarında oy alan çıktıların bütün çıktılara oranını bul.
3. Bir çıktıyı yeniden ürettir, sonra hiçbirini kullanmadan pencereyi kapat. Bu iki hareket bir olay olarak kaydedildi mi?
4. Ekibinin geri bildirim panosunda yalnız beğeni oranı duruyorsa bu desen ürününde eksik.

## Sorun

Bir müşteri hizmetleri ekibi e-posta yanıtlarını bir asistanla taslaklıyor. Her taslağın altında iki küçük düğme var, yukarı ve aşağı başparmak. Ürün ekibinin panosu memnuniyeti gösteriyor, oy verenlerin büyük çoğunluğu taslağı beğenmiş. Panoda görünmeyen şey, taslakların ne kadarının hiç oy almadığı.

Temsilciler taslağı okuyor, kapanış cümlesini siliyor, fiyatı düzeltiyor ve gönderiyor. Fiyat soran müşterilere giden taslağı çoğu zaman bir kez daha ürettiriyor, sonra vazgeçip yanıtı kendisi yazıyor. Bu hareketlerin hiçbiri oy sayılmıyor, hiçbiri panoya ulaşmıyor. Oy verenler de çoğu zaman taslak ekrana gelir gelmez, göndermeden önce oy veriyor.

Ekip panodaki sayıya bakıp düzeltilecek bir şey görmüyor. Silinen kapanış cümlesi her taslakta yeniden geliyor, fiyat sorularındaki boşluk sürüyor. Ekip bu oylarla model ya da prompt seçmeye başlarsa beğenilen ama gönderilmeyen taslağı da ödüllendiriyor. Başparmak bir anın hissini ölçer, işin nasıl bittiğini ölçmez.

## Neden atlanıyor

Düğme kolay, akıbet zor. Başparmak tek bir bileşen ve tek bir olay. Taslağın gönderilip gönderilmediğini, gönderilmeden önce ne kadar değiştiğini, ne zaman bırakıldığını kaydetmek ise editöre, gönderme akışına ve çıktının kimliğine dokunmayı gerektirir. İlk sürümde düğme konur, gerisi sonraya kalır.

Açık geri bildirim seyrek ve seçici. Anthropic ajan değerlendirmeleri üzerine yazısında başparmak ve hata bildirimi gibi açık sinyalleri [seyrek ve kendi kendini seçen](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) sinyaller diye tanımlıyor. Yazıya göre bu sinyaller ağır sorunlara kayıyor ve kullanıcılar bir şeyin neden başarısız olduğunu nadiren açıklıyor. Düğmeye basan kullanıcı, ürünü kullananların hepsini temsil etmiyor.

Model de oyla eğitilince oyu kazanmayı öğreniyor. OpenAI, Nisan 2025'teki GPT-4o güncellemesine ChatGPT'nin başparmak verisinden gelen [ek bir ödül sinyali](https://web.archive.org/web/20260105142837/https://openai.com/index/expanding-on-sycophancy/) eklediğini yazdı. Şirkete göre bu sinyal çoğu zaman işe yarıyor, aşağı başparmak genellikle bir şeylerin ters gittiğini gösteriyor. Ama kullanıcı geri bildirimi bazen daha uyumlu cevapları kayırabiliyor ve şirketin ilk değerlendirmesine göre yapılan değişikliklerin toplamı dalkavukluğu o güne kadar frenleyen asıl ödül sinyalini zayıflattı.

## Desen

Kullanıcı çıktıyla ne yaptığını işin içinde zaten söylüyor. Kullanıyor, değiştiriyor, yeniden istiyor ya da bırakıyor. Ürün bu hareketleri sinyal olarak kaydeder ve başparmağı ek bilgi sayar.

1. **Her çıktının akıbetini kaydet.** Çıktıya bir kimlik ver ve sonunu ona bağla: olduğu gibi kullanıldı (gönderildi, kopyalandı, belgeye eklendi), değiştirilerek kullanıldı, yeniden üretildi, bırakıldı. Akıbeti bilinmeyen çıktı ayrı sayılır.
2. **Değişikliğin yerini sakla.** Kullanıcı çıktıyı değiştirip kullandıysa hangi bölümün silindiğini, hangisinin yeniden yazıldığını kaydet. Aynı bölüm her hafta siliniyorsa düzeltilecek şey orada duruyor.
3. **Sinyali göreli oku.** Tek bir kopyalama çıktının iyi olduğunu söylemez. Aynı istek için ilk taslağın bırakılıp ikincinin kullanılması, ikincinin daha iyi olduğunu tek bir mutlak puandan daha güvenilir söyler. Karşılaştırmayı aynı kullanıcı ve aynı istek içinde yap.
4. **Nedeni vazgeçme anında sor.** Kullanıcı taslağı bırakınca ya da yeniden ürettirince tek dokunuşluk birkaç seçenek göster: bilgi eksik, ton yanlış, çok uzun, başka. Seçenekler birbirinin içine geçmesin, cevap vermemek de serbest kalsın.
5. **Tek sinyali hedef yapma.** Modeli ya da promptu yalnız beğeniye ya da yalnız kullanılma payına göre seçme. Akıbeti, oyu ve ayrı bir doğruluk denetimini birlikte oku.
6. **Neyi topladığını söyle.** Kullanıcıya hangi hareketlerin kaydedildiğini ve ne için kullanıldığını söyle, kaydı kapatma yolu bırak. Değişikliğin metnini kişisel veriden ayıklamadan saklama.

Başparmak düğmesi yerinde kalabilir. Ürün asıl geri bildirimi kullanıcının çıktıyla yaptığı işten okur.

## Önce ve sonra

Aynı asistanın haftalık geri bildirim raporu, iki ayrı hâlde. Soldaki yalnız başparmak oylarını sayıyor ve yüksek bir memnuniyet gösteriyor. Sağdaki her taslağın akıbetini kaydediyor, en çok silinen bölümü ve en çok bırakılan konuyu gösteriyor, oyların bu akıbetle ne kadar uyuştuğunu yazıyor.

Örnek ekran (kurgusal): Müşteri hizmetleri temsilcileri e-posta yanıtlarını bir asistanla taslaklıyor. Ürün ekibi haftalık geri bildirim raporuna bakıyor.

### Önce: Asistan · geri bildirim raporu

- Bilgi: Hafta 43 · 14.300 taslak
- Adım (tamam): Olumlu oy payı · %91 · 212 oy
- İçerik (Son yorumlar): “Harika, çok hızlı.” · “Teşekkürler!” · “Fiyat yanlış.”
- AI: Temsilciler taslaklardan memnun. Bu hafta düzeltilecek belirgin bir sorun yok.
- Düğmeler: Raporu paylaş

1. 14.300 taslaktan 212'si oy almış, oyların çoğu taslak ekrana gelir gelmez verilmiş. Rapor bu küçük ve kendi kendini seçmiş grubu bütün kullanıcılar sanıyor.
2. Taslakların gönderilip gönderilmediği, değiştirilip değiştirilmediği raporda yok. Her hafta tekrar eden düzeltmeler hiçbir sayıya girmiyor.

### Sonra: Asistan · geri bildirim raporu

- Bilgi: Hafta 43 · 14.300 taslak · akıbeti kayıtlı 14.120
- Adım (tamam): Olduğu gibi gönderilen · 3.710 taslak
- Adım (tamam): Değiştirilip gönderilen · 6.110 taslak · en sık silinen bölüm: kapanış cümlesi
- Adım (hata): Yeniden üretilen ya da bırakılan · 4.300 taslak · 1.920'si fiyat sorusu
- İçerik (Bırakma nedenleri · fiyat soruları): Bilgi eksik 61 · Ton yanlış 12 · Çok uzun 9 · Neden seçilmedi 1.838
- Uyarı: Olumlu oy alan 193 taslaktan 41'i gönderilmeden bırakılmış. Bu hafta oy ile işin sonu uyuşmuyor.
- Düğmeler: Fiyat taslaklarını incele · Kapanış cümlesini kaldır

1. Rapor her taslağın akıbetini sayıyor. Kimse oy vermeden de en çok silinen bölüm ve en çok bırakılan konu görünüyor.
2. Başparmak raporda kalıyor ama akıbetle yan yana okunuyor. Beğenilip gönderilmeyen taslaklar oyun neyi kaçırdığını gösteriyor.

## Piyasada

Cursor, kod düzenleyicisindeki öneri modelinin [günde 400 milyondan fazla isteğe](https://cursor.com/blog/tab-rl) cevap verdiğini ve kullanıcıların hangi öneriyi kabul edip hangisini reddettiğine dair bu veriyle modeli eğittiğini anlatıyor. Ödül kabul edilen öneriyi ödüllendiriyor, gösterilip kabul edilmeyen öneriyi cezalandırıyor. Hiç öneri göstermemek de modelin seçeneklerinden biri. Şirkete göre yeni model önceki modelden [%21 daha az öneri gösteriyor ve gösterdiklerinde %28 daha yüksek kabul alıyor](https://cursor.com/blog/tab-rl). Sinyal, kullanıcının öneriyi kabul edip etmemesinden geliyor. Kimseye bir şey sorulmuyor.

Google iç kodlama araçlarındaki modelleri [kabuller, retler ve düzeltmeler içeren kullanım günlükleriyle](https://research.google/blog/ai-in-software-engineering-at-google-progress-and-the-path-ahead/) ayarladığını yazıyor ve bu döngüyü sentetik örnekler yerine pratikteki davranıştan öğrenmenin yolu sayıyor.

Google'ın PAIR rehberi örtük geri bildirimi ürün günlüklerindeki kullanıcı davranışı diye tanımlıyor ve örnek olarak [önerilerin kaç kez kabul edilip reddedildiğini](https://pair.withgoogle.com/chapter/feedback-controls/) veriyor. Aynı rehber bu veriyi toplarken kullanıcıya haber vermeyi ve iznini önceden almayı istiyor.

Anthropic açık sinyali tek başına bırakmıyor. Ajan yazısı geri bildirimin [sürekli ayıklanmasını ve kayıtlardan her hafta örnek okunmasını](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) öneriyor, üretim izlemesiyle birlikte.

## Kanıt

**GPT-4o, Nisan 2025.** OpenAI'ın ayrıntılı açıklamasına göre şirket yeni modelleri küçük kullanıcı gruplarıyla A/B testinde denerken başparmak oylarına, yan yana karşılaştırmalardaki tercihlere ve kullanım örüntülerine bakıyordu. 25 Nisan güncellemesi bunlara başparmak verisinden gelen ek bir ödül sinyali de ekledi. A/B testinde modeli deneyen küçük grup [modeli beğenmiş göründü](https://web.archive.org/web/20260105142837/https://openai.com/index/expanding-on-sycophancy/). Model belirgin biçimde dalkavuklaştı ve OpenAI güncellemeyi 28 Nisan'da [geri almaya başladı](https://web.archive.org/web/20260105142837/https://openai.com/index/expanding-on-sycophancy/). Şirket kullanıcı geri bildirimini doğru yorumlamanın kendi sorumluluğu olduğunu yazdı. Oyların toplamı iyi görünüyordu, sorun oyun ölçmediği yerdeydi.

Tıklamayı örtük geri bildirim olarak okumanın sınırı yirmi yıl önce ölçüldü. Joachims ve arkadaşları Google sonuç sayfasında kullanıcıların göz hareketlerini izledi ve tıklamalarını değerlendiricilerin elle verdiği ilgililik kararlarıyla karşılaştırdı. Vardıkları sonuca göre tıklamalar [bilgi taşıyor ama yanlı](https://www.sigir.org/wp-content/uploads/2017/06/p003.pdf). Kullanıcılar üst sıradaki sonuca, alttaki daha ilgili olsa bile daha çok tıklıyordu. Yazarlar buna güven yanlılığı dedi. Tıklamayı mutlak bir onay gibi okumak yanıltıyordu. Göreli okununca, yani tıklanan sonuç üstünde atlanan sonuçtan daha ilgili sayılınca, tıklamadan çıkan tercihler değerlendiricilerin kararıyla [%80,8 oranında uyuştu](https://www.sigir.org/wp-content/uploads/2017/06/p003.pdf). Farklı değerlendiricilerin kendi arasındaki uyum [%89,5](https://www.sigir.org/wp-content/uploads/2017/06/p003.pdf) idi. Ekrana ilk gelen AI taslağı da aynı güveni alabilir. Akıbeti göreli okumak bu yüzden gerekli.

OpenAI'ın açıklaması tek bir şirketin kendi değerlendirmesi. Joachims'in deneyi 2005'te üniversite öğrencileriyle ve arama sonuçlarıyla yapıldı. Senin ürünündeki oyların ne kadar yanılttığını söylemezler. İkisi aynı noktada buluşuyor. Kullanıcının bir anlık tepkisi bilgi taşıyor, ama işin sonucunun yerini tutmuyor.

## Ölçüm

- **Akıbeti bilinen çıktı payı.** Çıktıların ne kadarının sonu kayıtlı: kullanıldı, değiştirilerek kullanıldı, yeniden üretildi, bırakıldı. Hedef neredeyse hepsi.
- **Oy ile akıbetin uyumu.** Oy alan çıktılarda oy ile akıbet ne kadar örtüşüyor? Beğenilip bırakılan ya da beğenilmeyip olduğu gibi gönderilen çıktılar çoksa oy işi ölçmüyor.
- **En çok değişen bölüm.** Değiştirilerek kullanılan çıktılarda en sık silinen ya da yeniden yazılan bölüm. O bölüme dokunan bir düzeltmeden sonra bu pay düşmeli.
- **Bırakmanın nedeni.** Bırakılan ve yeniden üretilen çıktılarda tek dokunuşla verilen nedenlerin dağılımı, konuya göre.
- **Değişiklikten sonra akıbet.** Model ya da prompt değişince akıbet dağılımı nasıl kayıyor? Beğeni artarken bırakma da artıyorsa beğeniye güvenme.

## Ajanına ver

Üç metin var. Denetim promptu ürünündeki geri bildirim düğmelerini ve çıktının akıbetini kaydeden olayları tarar. Hangi sinyalin toplanıp hangisinin kaybolduğunu ve oyların model ya da prompt seçiminde nasıl kullanıldığını raporlar, hiçbir dosyayı değiştirmez. Uygulama promptu her çıktıya bir kimlik verir, akıbet olaylarını, değişikliğin yerini ve vazgeçme anındaki neden seçeneklerini kurar. Önce planı gösterir, onayınla uygular ve bırakılan bir taslağın doğru kaydedildiğini sınayan bir test ekler. Kural kodlama ajanının kendi işi için. Senin ajanın da bir değişikliğin sonucunu çıktının akıbetine bakarak raporlasın.

## Sınır

Örtük sinyal gürültülü. Kopyalamak onaylamak anlamına gelmez, kullanıcı yanlışı fark etmeden kopyalamış olabilir. Bırakmak da başarısızlık sayılmaz, kullanıcı cevabı okuyup aradığını bulduğu için gitmiş olabilir. Google kod tamamlama yazısında bağlam değiştirmede gözlediği bir azalmayı [istatistiksel olarak doğrulayamadığı için sonradan metinden çıkardı](https://research.google/blog/ml-enhanced-code-completion-improves-developer-productivity/). Örtük sinyalden sonuç çıkarmadan önce farkın gerçek olduğunu sına.

Az kullanılan üründe sinyal birikmez. Günde birkaç çıktı üreten bir iç araçta akıbet kaydı anlamlı bir oran vermez. Orada kullanıcıyla konuşmak ve kayıtları elle okumak daha çok şey söyler.

Sinyal ödüle dönünce bozulabilir. Yalnız kullanılma payını yükseltmeye ayarlanan model, kullanıcının düzeltmeye üşendiği çıktıyı üretmeyi öğrenebilir. Akıbeti ayrı bir doğruluk denetimiyle birlikte oku.

Değişikliğin metni müşterinin adını, adresini ve sorununu taşır. PAIR rehberi örtük geri bildirimi toplamadan önce kullanıcıya [haber vermeyi ve izin almayı](https://pair.withgoogle.com/chapter/feedback-controls/) öneriyor. Metni saklaman gerekmiyorsa yalnız değişikliğin yerini ve büyüklüğünü sakla.

## Promptlar

### Denetim promptu

```
Bu depoda kullanıcıya metin, kod ya da öneri üreten bir AI özelliği var. Görevin, ürünün bu çıktılar hakkında hangi geri bildirimi topladığını ve kullanıcının çıktıyla yaptığı işin kaydedilip kaydedilmediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Açık geri bildirim yollarını bul: başparmak düğmeleri, puanlar, yorum kutuları, "hata bildir". Her birinin hangi olayı ürettiğini, hangi alanları taşıdığını ve nereye gittiğini yaz.
2. Çıktıya bir kimlik veriliyor mu? Kullanıcının çıktıyla sonraki hareketleri bu kimliğe bağlanıyor mu: kopyalama, gönderme, belgeye ekleme, değiştirme, yeniden üretme, kapatma ya da hiçbir şey yapmadan bırakma?
3. Çıktı değiştirilerek kullanıldığında değişikliğin yeri ve büyüklüğü kaydediliyor mu? Değişikliğin metni saklanıyorsa kişisel veri ayıklanıyor mu?
4. Kullanıcı çıktıyı bıraktığında ya da yeniden ürettirdiğinde nedenini sormanın bir yolu var mı? Seçenekler neler, cevap vermemek mümkün mü?
5. Toplanan oylar ve olaylar nerede kullanılıyor: panolarda, A/B testlerinde, model ya da prompt seçiminde, eğitim verisinde? Yalnız beğeniye bakılarak verilen bir karar var mı?
6. Kullanıcıya hangi davranışının kaydedildiği söyleniyor mu, kaydı kapatmanın bir yolu var mı?

Rapor biçimi: önce toplanan sinyallerin listesi (açık ve örtük), her biri için dosya ve satır. Sonra kaybolan sinyaller: çıktının akıbetinden hangisi hiç kaydedilmiyor. En sonda oyların tek başına karar verdiği yerler ve gizlilik riskleri.

```

### Uygulama promptu

```
Bu depodaki AI özelliğine "geri bildirimi işin içinden topla" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Her AI çıktısına bir kimlik ver. Çıktının akıbetini bu kimliğe bağlı tek bir olayla kaydet: olduğu gibi kullanıldı (gönderildi, kopyalandı, eklendi), değiştirilerek kullanıldı, yeniden üretildi, bırakıldı. Belirli bir süre içinde hiçbir hareket yoksa akıbet "bırakıldı" olsun.
2. Değiştirilerek kullanılan çıktılarda değişikliğin yerini (bölüm, satır aralığı) ve büyüklüğünü kaydet. Değişikliğin metnini saklaman gerekiyorsa önce kişisel veriyi ayıkla.
3. Kullanıcı çıktıyı bıraktığında ya da yeniden ürettirdiğinde tek dokunuşluk, birbirini dışlayan birkaç neden seçeneği göster (bilgi eksik, ton yanlış, çok uzun, başka). Cevap vermemek serbest olsun.
4. Başparmak oylarını akıbet olayıyla aynı çıktı kimliğine bağla ki ikisi birlikte okunabilsin.
5. Haftalık bir rapor üret: akıbet dağılımı, en sık değişen bölüm, konuya göre bırakma payı ve nedenleri, oy ile akıbetin uyuşma payı.
6. Hangi hareketlerin kaydedildiğini kullanıcıya gizlilik metninde ya da ayarlarda söyle ve kaydı kapatma seçeneği ekle.

Uygularken:
- Modeli ya da promptu yalnız beğeniye ya da yalnız kullanılma payına göre seçen bir kod yazma. Akıbeti, oyu ve doğruluk denetimini birlikte raporla.
- Olaylara kullanıcının adını, e-postasını ve çıktının metnini koyma. Kimlik, konu ve akıbet yeter.
- Bir test ekle: bir çıktı üret, kullanıcı hiçbir şey yapmadan pencereyi kapatsın ve akıbetin "bırakıldı" olarak kaydedildiğini doğrula. İkinci test: çıktı değiştirilip gönderilsin, değişikliğin yerinin kaydedildiğini ve metninin kaydedilmediğini doğrula.

```

### AGENTS.md kuralı

```
## Geri bildirimi işin içinden topla
- AI çıktısı üreten kod yazarken çıktıya bir kimlik ver ve akıbetini (kullanıldı, değiştirildi, yeniden üretildi, bırakıldı) bu kimliğe bağla.
- Başparmak oyunu tek geri bildirim sayma. Oyu çıktının akıbetiyle birlikte oku.
- Bir değişikliğin işe yarayıp yaramadığını raporlarken akıbet dağılımındaki farkı ver.
- Değişikliğin metnini ve kişisel veriyi olaylara koyma. Yer ve büyüklük yeter.
- Kullanıcıya nedeni yalnız vazgeçtiği anda ve tek dokunuşla sor.

```

## Kaynaklar

1. [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents), Anthropic, 9 Ocak 2026
2. [Expanding on what we missed with sycophancy](https://web.archive.org/web/20260105142837/https://openai.com/index/expanding-on-sycophancy/), OpenAI (Wayback Machine kopyası), 2 Mayıs 2025
3. [Improving Cursor Tab with online RL](https://cursor.com/blog/tab-rl), Cursor, 12 Eylül 2025
4. [AI in software engineering at Google: Progress and the path ahead](https://research.google/blog/ai-in-software-engineering-at-google-progress-and-the-path-ahead/), Google Research · Chandra, Tabachnyk, 6 Haziran 2024
5. [Feedback + Control (People + AI Guidebook)](https://pair.withgoogle.com/chapter/feedback-controls/), Google PAIR
6. [Accurately Interpreting Clickthrough Data as Implicit Feedback](https://www.sigir.org/wp-content/uploads/2017/06/p003.pdf), Joachims, Granka, Pan, Hembrooke, Gay · SIGIR 2005 (SIGIR Forum), Ağustos 2005
7. [ML-Enhanced Code Completion Improves Developer Productivity](https://research.google/blog/ml-enhanced-code-completion-improves-developer-productivity/), Google Research · Tabachnyk, Nikolov, 26 Temmuz 2022

---

Kaynak: https://tandem.komunite.com.tr · Metin CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/deed.tr), promptlar ve kural MIT-0 (https://opensource.org/license/mit-0).