Cevabı sessizce kırpma

Kullanıcı asistandan uzun bir hizmet sözleşmesinin maddelerini tek tek, her birini birer cümleyle anlatmasını istiyor. Cevap düzgün bir liste olarak geliyor. Maddeler numaralı, cümleler tamam, liste bir maddenin sonunda bitiyor. Kullanıcı listeyi ekibine gönderiyor. Bir hafta sonra biri fesih maddesini soruyor. Listede yok. Asistanın cevabı çıktı uzunluğu sınırına takılmış, son maddeler hiç yazılmamıştı.

Cevap iki yoldan eksik gelebiliyor. Birincisi uzunluk: model çıktı sınırına ya da bağlam penceresinin sonuna ulaşınca duruyor. İkincisi filtre: bir güvenlik ya da politika katmanı cevabın bir kısmını kesiyor ya da hiç göstermiyor. İki durumda da sağlayıcı bunu cevabın yanında bildiriyor. Bildirimi okuyan bir arayüz yoksa kullanıcının gördüğü şey yarım bir cevabın bitmiş görünen hâli.

Zarar burada büyüyor. Eksik olduğu belli olan bir cevabı kullanıcı tamamlatır. Tam görünen bir cevap ise bir karara, bir rapora, bir sözleşme incelemesine eksiğiyle giriyor. Eksik cevap tek başına küçük bir aksaklık. Kullanıcıyı yanıltan, eksiğin görünmemesi.

Cevabın bir kısmı yazılmadıysa ya da çıkarıldıysa kullanıcı bunu cevabın içinde görmeli.

Kesinti hata kanalından gelmiyor. Anthropic'in API belgesi durma nedenini her başarılı cevabın bir parçası olarak tanımlıyor ve onu hatalardan açıkça ayırıyor. Çıktı sınırına takılan cevap da başarılı bir cevap¹ olarak dönüyor, yalnız durma nedeni farklı. Hata yakalayan kod bu cevaplara hiç dokunmuyor, metni ekrana basan kod da yalnız metne bakıyor.

Alanların adı sağlayıcıdan sağlayıcıya değişiyor. OpenAI'ın sohbet arayüzünde bilgi finish_reason alanında: sınıra ulaşan cevap length, içerik filtresi yüzünden bir kısmı çıkarılan cevap² content_filter diyor. OpenAI'ın Responses arayüzünde cevabın durumu incomplete oluyor ve neden ayrı bir alanda³ yazıyor. Google'ın Gemini API'sinde uzunluk, güvenlik, alıntı, yasaklı terim ve kişisel veri için ayrı durma değerleri⁴ var. Birden çok sağlayıcıyı aynı arayüze bağlayan ekip bu alanları tek bir yerde toplamazsa çoğu zaman yalnız metni alıp geçiyor.

Üçüncü neden görünüşte. Yarım bir cevap çoğu zaman yarım görünmüyor. Liste bir maddenin sonunda, paragraf bir cümlenin sonunda bitebiliyor. Akarak gelen cevapta kullanıcı metnin durduğunu görüyor ve durmayı bitiş sanıyor. Google'ın People + AI rehberi bu tür hatalara arka plan hatası diyor: sistem doğru çalışmıyor ama ne kullanıcı ne sistem bir hata kaydediyor⁵.

Cevabın her parçası ya gösterilir ya da eksik olduğu söylenir. Arayüz sağlayıcının durma nedenini okur ve tam olmayan her cevabı tam olandan ayrı çizer.

1. Durma nedenini her cevapta oku. Metni ekrana basmadan önce sağlayıcının durma alanına bak. Doğal bitiş dışındaki her değer arayüzde bir duruma karşılık gelir. Tanımadığın değer tam sayılmaz, “cevap tamamlanmamış olabilir” diye gösterilir.
2. Eksiği cevabın içinde göster. Kesilen cevabın sonuna, kesildiği yere görünür bir not koy: neyin eksik kaldığını ve nedenini söyle. Not bir bildirimde ya da günlükte kalmaz, metnin içinde durur. Kullanıcı metni kopyalayıp başka yere taşıdığında not da onunla gider.
3. Nedeni ayır. Uzunluk sınırı ile filtre aynı notu almaz. Uzunlukta hangi bölümlerin yazılmadığını söyle. Filtrede ne tür içeriğin çıkarıldığını söyle, içeriğin kendisini açmadan.
4. Devam yolunu ver. Uzunlukta “Kalanı yaz” cevabı kaldığı yerden sürdürür ve eklenen kısmı öncekiyle birleştirir. Filtrede işe yarayacak yolu göster: soruyu değiştirmek, bir insana başvurmak.
5. Ekrandaki metni sessizce silme. Akarak gelen bir cevap yarıda reddedilir ya da filtreye takılırsa gösterilmiş metin bir anda kaybolmaz. Ürün metni kaldırıyorsa yerine neden kaldırıldığını söyleyen bir satır koyar.
6. Eksik cevabı tam cevap gibi işleme. Kesik cevap kendiliğinden bir dosyaya, e-postaya ya da ajanın sonraki adımına geçmez. Yarım kalmış bir araç çağrısı çalıştırılmaz, istek daha yüksek bir sınırla yeniden gönderilir.

Sınır her üründe var ve bazen cevabı kesecek. Kullanıcı bunu cevabın içinden öğrenir.

Aynı sözleşme, aynı kesinti. Soldaki liste bir maddenin sonunda bitiyor ve tam görünüyor, fesih ve ceza maddeleri yok. Sağdaki aynı listeyi gösteriyor, kesildiği yere bir not koyuyor, hangi maddelerin eksik olduğunu yazıyor ve kalanı yazmayı tek düğmeye bırakıyor.

Anthropic'in belgesi kesintiyi arayüze taşımayı açıkça öneriyor. Cevap token sınırı ya da bağlam penceresi yüzünden kesildiğinde okurun çıktının eksik olduğunu bilmesi için bir not eklemeyi¹ söylüyor ve örnek kodda metnin sonuna bu notu ekliyor. Ret için de aynı açıklık var. Ret cevabın başında da akışın ortasında da gelebiliyor ve iki durumda da yarım çıktı eksik sayılıp atılmalı⁶. Atılan metnin yerine ne görüneceği ürüne kalıyor. Belge retle gelen açıklama metnini ayrıştırmamayı, kullanıcıya göstermeyi öneriyor.

OpenAI'ın Model Spec'i kısmi gizlemeyi model davranışı olarak tanımlıyor. Yasal gereklilik yüzünden çıkarılan her içerik kullanıcıya her cevapta açıkça belirtilmeli⁷: hangi tür bilginin neden çıkarıldığı söylenmeli, içeriğin kendisi açılmadan.

Microsoft'un Azure OpenAI belgesi geliştiriciyi aynı yere yönlendiriyor. İçerik filtresine takılan cevabın durma nedeni content_filter oluyor, uzun cevaplarda kısmi bir sonuç dönebiliyor ve uygulamanın eksik kalabilecek içerik senaryolarını hesaba katması⁸ gerekiyor. Filtrenin akıştan sonra çalıştığı modda belge bir adım daha ileri gidiyor. Gecikmeli sinyal gelince gösterilen içeriği durdurmak, kaldırmak ya da yerine başka bir şey koymak⁹ uygulamanın işi.

Google'ın Gemini API'si prompt engellendiğinde hiç aday cevap döndürmüyor. Belge bu durumda yapılacak şeyi tek cümleyle yazıyor: promptu yeniden yaz⁴. Bu cümle ancak kullanıcıya ulaşırsa işe yarıyor.

Dört belgenin ortak noktası aynı: sinyal API'de var ve satıcı onu kullanıcıya taşımayı öneriyor. Sinyali okuyup ekrana koymak ürün ekibinin işi.

Bu desenin dayanağı sağlayıcıların kendi belgeleri. Kesik bir cevabın tam sanılmasından doğan, kamuya mal olmuş bir olay ya da bunun sıklığını ölçen yayımlanmış bir çalışma yok. Belgeler yine de üç şeyi açıkça gösteriyor.

Birincisi, kesinti başarı gibi kaydediliyor. Anthropic güvenlik reddini bile normal bir 200 cevabı olarak döndürüyor¹. Microsoft'un belgesi de filtrelenen akış cevabının 200 koduyla ve content_filter nedeniyle döndüğünü faturalandırma notunda⁹ yazıyor. Yalnız hata kodlarına bakan bir izleme panosu bu cevapları başarılı sayar.

İkincisi, kesik cevap boş da olabilir. OpenAI'ın belgesine göre akıl yürüten bir modelde çıktı sınırına görünür metin üretilmeden ulaşılabiliyor ve kullanıcı girdi ve akıl yürütme token'larının bedelini ödüyor³. Arayüz bu durumu ayırmazsa kullanıcı boş bir balon ya da hiç gelmeyen bir cevap görüyor.

Üçüncüsü, filtrenin kestiği yer ekranda olabilir. Azure'un eşzamansız filtre modunda içerik önce gösteriliyor, filtre sinyali sonra geliyor. Belge zararlı içeriğin bazı bölümlerinin kullanıcıya görünebileceğini⁹ açıkça yazıyor. Ürün o bölümü sonradan kaldırıyorsa kullanıcının okuduğu metin gözünün önünde değişiyor.

Bu belgeler sinyallerin nasıl çalıştığını anlatıyor, kesik cevapların ne sıklıkla tam sanıldığını ölçmüyor. Kendi ürünündeki payı günlüğündeki durma nedenlerinden çıkarabilirsin.

• Doğal olmayan bitiş payı. Cevapların ne kadarının uzunluk, filtre ya da başka bir nedenle bittiği, nedene göre ayrı. Bu sayıyı bilmeyen ekip kesintinin varlığını da bilmez.
• Notsuz kesinti. Durma nedeni doğal bitiş olmadığı hâlde ekranda not göstermeyen cevaplar. Hedef sıfır.
• Kalanı yaz kullanımı. Not gösterilen cevaplarda kullanıcının devam ettirme payı. Yüksekse sınır gerçek işi kesiyor, çıktı sınırını ya da işin bölünmesini yeniden düşün.
• Boş cevap. Görünür metin içermeyen ama başarılı dönen cevaplar. Akıl yürüten modellerde ayrıca izle.
• Sonradan fark edilen eksik. Kullanıcının “devamı nerede”, “bu kesildi mi” diye sorduğu mesajlar. Not yerindeyse bu sorular azalır.

Üç metin var. Denetim promptu ürünündeki AI cevaplarının ekrana nasıl taşındığını tarar, durma nedeninin okunup okunmadığını ve kesik ya da filtrelenmiş cevabın kullanıcıya nasıl göründüğünü raporlar, hiçbir dosyayı değiştirmez. Uygulama promptu durma nedenlerini tek bir yerde toplar, kesik cevabın içine görünür bir not ve devam yolu ekler, akışta kaldırılan metnin yerine açıklama koyar. Önce planı gösterir, onayınla uygular ve çıktı sınırını bilerek düşüren bir testle notun göründüğünü doğrular. Kural kodlama ajanının kendi çıktısı için. Uzun bir dosyayı ya da listeyi yarım bıraktığında bunu söylesin.

Bu depoda bir AI modelinin cevabını kullanıcıya gösteren bir özellik var. Görevin, cevap uzunluk sınırına takıldığında ya da bir filtre cevabın bir kısmını çıkardığında kullanıcının bunu görüp görmediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. AI cevabının alındığı bütün yerleri bul: SDK çağrıları, akış (streaming) işleyicileri, toplu işler, ajan döngüsü, cevabı başka bir araca ya da dosyaya geçiren kod.
2. Her yerde durma nedeni okunuyor mu? Sağlayıcıya göre alan: Anthropic stop_reason (max_tokens, model_context_window_exceeded, refusal, pause_turn), OpenAI Chat Completions finish_reason (length, content_filter), OpenAI Responses status ve incomplete_details.reason (max_output_tokens, content_filter), Gemini finishReason (MAX_TOKENS, SAFETY, RECITATION, BLOCKLIST, PROHIBITED_CONTENT, SPII) ve promptFeedback.blockReason. Okunmuyorsa metin ekrana nasıl basılıyor?
3. Durma nedeni doğal bitiş değilse kullanıcı ne görüyor? Cevabın içinde bir not var mı, yoksa metin tam gibi mi gösteriliyor? Not yalnız bir bildirimde ya da günlükte mi kalıyor?
4. Akışta gösterilmiş metin sonradan (ret, filtre, hata yüzünden) kaldırılıyor ya da değiştiriliyor mu? Kaldırılıyorsa yerine bir açıklama konuyor mu?
5. Kesik ya da boş cevap kendiliğinden başka bir yere geçiyor mu: dosyaya yazma, e-posta, ajanın sonraki adımı, araç çağrısı? Yarım kalmış bir araç çağrısı bloğu çalıştırılmaya çalışılıyor mu?
6. Görünür metin içermeyen başarılı cevaplar (örnek: akıl yürütme token'ları çıktı sınırını doldurdu) nasıl gösteriliyor?
7. Kopyalama, dışa aktarma ve paylaşma yolları kesinti notunu taşıyor mu?

Rapor biçimi: her bulgu için dosya ve satır, hangi durma nedeninin okunmadığı ya da gösterilmediği, kullanıcının ne gördüğü (örnek: liste dokuzuncu maddede bitiyor, eksik olduğuna dair hiçbir işaret yok) ve önerdiğin düzeltme. Eksik cevabın sessizce başka bir sisteme geçtiği yollardan başla.

Bu depodaki AI özelliğine "cevabı sessizce kırpma" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Her sağlayıcının durma alanını tek bir iç değere çeviren bir fonksiyon yaz: tamam, uzunluk (çıktı sınırı ya da bağlam penceresi), filtre (güvenlik, politika, alıntı, kişisel veri), ret, duraklatıldı, bilinmeyen. Bilinmeyen değeri tamam sayma.
2. Durum tamam değilse cevabın sonuna, kesildiği yere görünür bir not ekle. Not nedeni ve neyin eksik kaldığını söylesin: "Cevap uzunluk sınırına takıldı, son bölümler yazılmadı" ya da "Bu cevabın bir kısmı içerik filtresi nedeniyle gösterilmiyor". Filtrede çıkarılan içeriği ya da filtrenin nasıl aşılacağını yazma, yalnız türünü söyle.
3. Uzunlukta "Kalanı yaz" eylemi cevabı kaldığı yerden sürdürsün ve eklenen kısmı öncekiyle birleştirsin. Filtre ve retta işe yarayacak yolu göster: soruyu değiştirmek, bir insana başvurmak.
4. Akışta gösterilmiş metin ret ya da filtre yüzünden kaldırılacaksa yerine neden kaldırıldığını söyleyen bir satır koy. Metni sessizce silme.
5. Durumu tamam olmayan cevap kendiliğinden dosyaya, e-postaya ya da ajanın sonraki adımına geçmesin. Yarım kalmış araç çağrısı bloğunu çalıştırma, isteği daha yüksek bir çıktı sınırıyla yeniden gönder.
6. Görünür metni olmayan başarılı cevabı boş balon olarak gösterme. "Cevap üretilemedi" notu ve yeniden deneme yolu göster.
7. Kopyalama ve dışa aktarma kesinti notunu da taşısın.

Uygularken:
- Durma nedenini her cevapta günlüğe yaz, böylece doğal olmayan bitişleri sayabilirsin.
- Not metinlerini tek bir dosyada tut.
- Bir test ekle: çıktı sınırını bilerek düşük ayarla (örnek: 50 token) ve uzun bir liste iste. Notun cevabın içinde göründüğünü, "Kalanı yaz"ın listeyi tamamladığını ve kopyalanan metnin notu taşıdığını doğrula. İkinci test: sağlayıcı istemcisini taklit ederek content_filter ya da refusal döndür ve akışta gösterilen metnin yerine açıklama satırının geldiğini doğrula.

## Çıktıyı sessizce kırpma
- Uzun bir dosyayı, listeyi ya da çıktıyı yarım bıraktığında bunu açıkça söyle: nerede kaldığını ve neyin eksik olduğunu yaz.
- Bir dosyayı yazarken içeriği "geri kalanı aynı" gibi bir yer tutucuyla kısaltma. Tam içeriği yaz ya da neyi atladığını açıkça işaretle.
- Bir komut çıktısının ya da okuduğun dosyanın kesildiğini fark edersen (satır sınırı, çıktı sınırı) kesik kısma dayanarak sonuç çıkarma. Kalanını oku ya da kesildiğini söyle.
- Bir cevabın bir kısmını vermiyorsan nedenini söyle, sessizce atlama.

Kısa cevaplarda kesinti nadir. Çıktı sınırı işin ihtiyacının çok üstündeyse bu desenin görünen kısmı neredeyse hiç devreye girmez. Durma nedenini okuyan kod yine de yerinde durmalı.

Not, gerekçeyi aşırı açmamalı. Filtrenin neden devreye girdiğini anlatırken çıkarılan içeriği ya da filtrenin nasıl atlatılacağını söyleme. İçeriğin türünü söylemek yeter.

Bu desen sınırı görünür kılar, sınırın kendisi yerinde kalır. Kullanıcıların sık sık “Kalanı yaz”a bastığı bir işte işi baştan bölmek daha iyi sonuç verir: uzun listeyi parçalara ayıran ve her parçayı ayrı üreten bir akış.

Bütünüyle reddedilen istek ayrı bir tasarım işi. Bu desen cevabın bir kısmı eksik kaldığında görünürlüğü anlatıyor. İsteğin hiç yerine getirilmediği durumda nedenin ve en yakın yolun nasıl söyleneceği başka bir desenin konusu.