Kazanimlar:
- Akışın (streaming) ne olduğunu, olay tiplerini ve neden gerektiğini açıklayabilir
- max_tokens, zaman aşımı ve 128K uzun çıktı ilişkisini kavrar
- Akışlı ve akışsız istekler arasında iş yüküne göre doğru tercihi yapabilir
Bir sohbet arayüzünde yanıtın kelime kelime "yazılarak" geldiğini fark etmişsinizdir. Bu bir görsel süs değil; akış (streaming) denen bir tekniğin sonucudur ve üretim kalitesinde LLM entegrasyonu için çoğu zaman zorunludur. Bu ünitede akışın ne olduğunu, hangi olaylardan oluştuğunu, uzun çıktı ve zaman aşımı ile ilişkisini, ne zaman akış kullanıp ne zaman kullanmayacağınızı öğreneceksiniz. Konuyu bir profesyonelin gerçek görevleri üzerinden — canlı asistan, uzun rapor üretimi, toplu işleme — ele alacağız.
Akış Nedir?
Akışsız (senkron) bir istekte model tüm yanıtı üretene kadar beklersiniz; yanıt hazır olunca tek parça olarak gelir. Akışlı istekte ise sunucu, model ürettikçe yanıtı parça parça gönderir. Teknik olarak bu, sunucu-gönderimli olaylar (SSE — Server-Sent Events, sunucunun açık bir bağlantı üzerinden art arda küçük olaylar yolladığı yöntem) ile yapılır.
Fark kullanıcı deneyiminde belirginleşir: 8 saniye süren bir yanıtta akışsız kullanıcı 8 saniye boş ekrana bakar; akışlı kullanıcı ~0,5 saniyede ilk kelimeleri görür ve metin akmaya başlar. Algılanan gecikme (perceived latency) — kullanıcının hissettiği bekleme — çok düşer, oysa toplam süre değişmez.
Akışın Olay Tipleri
Akış bir olay dizisidir. Kavramsal olarak tipik bir akış şöyle ilerler:
Olay
Anlamı
message_start
Yanıt başladı; model, kimlik gibi üst bilgiler geldi
content_block_start
Bir içerik bloğu (ör. metin) başladı
content_block_delta
Metnin küçük bir parçası (delta) geldi; bunları biriktirirsiniz
content_block_stop
Blok tamamlandı
message_delta
stop_reason ve usage gibi bitiş bilgileri güncellendi
message_stop
Yanıt bitti
Kodunuz content_block_delta olaylarındaki metin parçalarını sırayla birleştirir; sonuçta akışsız yanıtla aynı tam metni elde edersiniz. usage (token sayıları) genellikle akışın sonunda netleşir — maliyet takibini akış bittiğinde yaparsınız.
İpucu: Çoğu resmi SDK (Software Development Kit — sağlayıcının hazır kütüphanesi) akışı sizin için toplayan bir yardımcı sunar (ör. stream.get_final_message()). Tüm parçaları elle yönetmeniz gerekmez; tam metni istiyorsanız bu yardımcıyı kullanın, tek tek olayları ancak canlı yazdırma için işleyin.
Uzun Yanıtlar, max_tokens ve Zaman Aşımı
Akışın ikinci ve daha teknik nedeni zaman aşımıdır (timeout). Bir HTTP isteği belli bir süre içinde tamamlanmazsa istemci bağlantıyı düşürür. Modelden büyük bir çıktı (ör. 40.000 token'lık bir rapor) istediğinizde akışsız çağrı bu sınırı aşıp zaman aşımına düşebilir — istek başarısız olur, üstelik üretilen token'lar için ödeme yapmış olursunuz.
Modern modeller tek istekte 128.000 token'a kadar çıktı üretebilir. Ancak pratik kural nettir: `max_tokens` değeri yüksekse (kabaca 16.000'in üzeri) akış kullanın. Akış, bağlantıyı canlı tutar ve zaman aşımını önler; ayrıca ilerlemeyi anında görürsünüz.
- `max_tokens`: Modelin üretebileceği en fazla çıktı token'ı; sert bir tavan. Kesme olursa stop_reason max_tokens döner.
- Bağlam penceresi (context window): Girdi + çıktı toplamının sığması gereken pencere. max_tokens, çıktının tavanıdır; ikisini karıştırmayın.
Dikkat: Büyük max_tokens ile akışsız istek atmak üretimdeki klasik bir hatadır. Yanıt gelmeden bağlantı düşer, kullanıcı hata görür ve token maliyeti boşa gider. Uzun çıktı = akış.
Ne Zaman Akış, Ne Zaman Değil?
Durum
Tercih
Neden
Canlı sohbet / asistan
Akış
Algılanan gecikme düşer, kullanıcı ilerlemeyi görür
Uzun rapor / doküman üretimi
Akış
Zaman aşımını önler, büyük çıktıyı güvenle taşır
Kısa sınıflandırma (ör. tek kelime etiket)
Akışsız
Çıktı zaten küçük; ek karmaşıklık gereksiz
Toplu (batch) işleme
Akışsız/batch
Sonuçlar anlık gösterilmez; 7. üniteye bakın
Otomasyon adımı (arka planda)
Genellikle akışsız
Sonucu bir sonraki adıma geçirirsiniz, canlı gösterim yok
Kopyalanabilir Prompt/Şablonlar
Akışın kendisi bir prompt değildir ama akışla üretilen çıktıyı yönetmek için promptlar kritiktir. Uzun ve akışlı üretimlerde yapıyı önden dayatmak, hem kaliteyi hem izlenebilirliği artırır.
# Uzun raporu bölümlere ayır (akışta ilerleme görünür olsun)Raporu şu başlıklarla, tam bu sırayla yaz. Her başlığı '## ' ile başlat:## Özet## Bulgular## Öneriler## Sonraki adımlar
# Uzun üretimde kesilmeyi önlemek için hedef uzunluk verToplam metin yaklaşık 800 kelime olacak. Bölümleri dengeli tut; sonunda yarım cümle bırakma.
# Akışlı asistan için ilk cümleyi anında verÖnce tek cümlelik bir doğrudan cevap ver, ardından ayrıntıya gir.Böylece kullanıcı beklerken hemen bir sonuç görsün.
# Uzun çıktıyı yapılandırılmış tut (sonradan ayrıştırılabilsin)Çıktını şu bölümlerle ver ve her bölümü ayrı bir '### ' başlığıyla işaretle,böylece programatik olarak ayrıştırabileyim: ### GIRIS ### GOVDE ### KAYNAKLAR
Zayıf prompt / Güçlü prompt (uzun üretim)
# ZAYIFBu konu hakkında uzun ve detaylı bir rapor yaz.
# GÜÇLÜBu konu hakkında yaklaşık 900 kelimelik bir rapor yaz.Başlıklar: ## Özet, ## Analiz, ## Riskler, ## Öneriler.Her başlık en fazla 3 paragraf olsun. Sonda yarım cümle bırakma.
Güçlü sürüm; uzunluğu, yapıyı ve bitiş kalitesini önden belirler. Akışta bölümler geldikçe kullanıcı ilerlemeyi net görür ve model kesilme riskine karşı uzunluğu kendisi yönetir.
Üç Mini Vaka
Vaka 1 — Boş ekran şikâyeti. Bir danışmanlık ekibinin müşteri asistanı yanıtı akışsız veriyordu; ortalama yanıt 7 saniye sürüyor, kullanıcılar "donuyor mu?" diye şikâyet ediyordu. Akışa geçince ilk kelime ~0,6 saniyede geliyordu; toplam süre aynı kaldı ama "yavaş" şikâyetleri neredeyse sıfırlandı.
Vaka 2 — Zaman aşımına düşen rapor. Bir finans ekibi 30 sayfalık çeyrek raporu ürettiriyordu; max_tokens: 30000 ile akışsız istek 60 saniyelik istemci zaman aşımına takılıyor, istek başarısız oluyordu — üstelik üretilen token'lar faturaya yazılıyordu. Akışa geçtiler; bağlantı canlı kaldı, rapor eksiksiz teslim edildi ve boşa giden maliyet ortadan kalktı.
Vaka 3 — Gereksiz akış. Bir operasyon ekibi gelen e-postaları "acil/normal" diye etiketliyordu; çıktı tek kelimeydi ama alışkanlıkla akış kullanıyorlardı. Akış, tek kelimelik yanıtta hiçbir fayda sağlamıyor, kodu gereksiz karmaşıklaştırıyordu. Akışsıza dönünce kod sadeleşti, davranış aynı kaldı. Ders: akış her yerde değil, uzun/canlı çıktıda değerlidir.
Sık yapılan hatalar
- Uzun çıktıda akış kullanmamak: Zaman aşımı ve boşa giden token maliyeti.
- Kısa çıktıda akış kullanmak: Gereksiz karmaşıklık, sıfır fayda.
- `stop_reason`'ı akış sonunda kontrol etmemek: max_tokens ile kesilmiş yanıt tam sanılır.
- Delta'ları yanlış birleştirmek: SDK yardımcısı varken elle toplama, sıra/eksik parça hatası doğurur.
- `usage`'ı akış ortasında okumaya çalışmak: Token sayıları genelde sonda netleşir; maliyet takibini bitişte yapın.
- Akışı maliyet düşürücü sanmak: Akış deneyimi ve dayanıklılığı iyileştirir; token fiyatını değiştirmez.
Daha Derine: Akışta Kesintiler ve Dayanıklılık
Akış canlı bir bağlantıdır; bu, hem gücü hem kırılgan yanıdır. Bağlantı ortada koparsa (ağ dalgalanması, istemci zaman aşımı), o ana kadar biriktirdiğiniz metin elinizde kalır ama yanıt yarım olur. Üretim kalitesinde bir akış istemcisi bu duruma hazırlıklı olmalıdır: kısmi metni "tamamlanmış cevap" gibi işlememeli, message_stop olayını görmeden yanıtı bitmiş saymamalıdır.
İkinci incelik, akışın maliyeti değiştirmediğidir. Bir yanıtı akışlı ya da akışsız almanız token fiyatını etkilemez; akış yalnızca deneyimi ve dayanıklılığı iyileştirir. Bu yüzden "akışa geçersek ucuzlar mı?" sorusunun cevabı hayırdır — maliyet için 5. ve 6. üniteye (model seçimi, önbellek) bakılır.
Üçüncü nokta pratik bir denge kurmaktır: canlı asistanlarda ilk kelimenin hızla gelmesi (algılanan gecikme) çok değerlidir; bu yüzden modelin cevaba doğrudan girip önce kısa bir sonuç vermesini istemek (4. ünitedeki sistem promptu ile) akışın faydasını katlar. Kullanıcı ilk saniyede anlamlı bir şey görürse, arkadan gelen ayrıntı için sabırla bekler. Buna karşılık arka planda çalışan, çıktısı bir sonraki otomasyon adımına giden işlerde akışın hiçbir katkısı yoktur; oradaki tek ölçüt işin doğru ve eksiksiz tamamlanmasıdır.
Özetle
Akış, yanıtı parça parça alarak algılanan gecikmeyi düşürür ve büyük çıktılarda zaman aşımını önler. Canlı asistan ve uzun doküman üretiminde neredeyse zorunlu; kısa/arka plan işlerinde gereksizdir. Uzun üretimlerde yapıyı ve uzunluğu prompt ile önden dayatmak hem kaliteyi hem izlenebilirliği artırır; akış bittiğinde stop_reason ve usage mutlaka kontrol edilir.
Uygulama görevi
İki senaryo seçin: biri canlı/uzun (ör. müşteriye rapor), biri kısa/arka plan (ör. etiketleme). (1) Her biri için akış kullanıp kullanmayacağınıza karar verin ve gerekçelendirin. (2) Uzun senaryo için yapıyı dayatan bir prompt yazın (başlıklar + hedef uzunluk). (3) max_tokens değerlerini belirleyin. (4) Akış sonunda stop_reason ve usage ile hangi kontrolleri yapacağınızı listeleyin.
Kontrol listesi
- [ ] Akışın ne olduğunu ve algılanan gecikmeyi nasıl düşürdüğünü açıklayabiliyorum.
- [ ] Akışın temel olay tiplerini ve delta birleştirmeyi kavradım.
- [ ] Büyük max_tokens ile akış gerektiğini ve zaman aşımı ilişkisini biliyorum.
- [ ] Hangi iş yükünde akış kullanıp hangisinde kullanmayacağıma karar verebiliyorum.
- [ ] Akış sonunda stop_reason ve usage kontrolü yapabiliyorum.