Kazanimlar:
- Toplu (batch) işlemenin hangi iş yükleri için uygun olduğunu belirler
- Senkron, asenkron ve toplu işleme arasındaki maliyet/gecikme dengesini kavrar
- custom_id ile sonuçları eşleştiren dayanıklı bir toplu iş akışı tasarlar
LLM entegrasyonlarının çoğu, bir kullanıcının ekran karşısında yanıt beklediği "canlı" senaryolara odaklanır. Ama profesyonel iş yüklerinin büyük bölümü aslında canlı değildir: gece boyu binlerce belgeyi etiketlemek, bir veri setinin tamamını özetlemek, arşivdeki tüm çağrı kayıtlarını sınıflandırmak. Bu işlerde kimse anlık cevap beklemez; önemli olan işi ucuza ve güvenilir bitirmektir. İşte toplu işleme (batch) tam bu iş yükleri için vardır. Bu ünitede senkron, asenkron ve toplu işleme arasındaki farkı, batch'in ne zaman doğru seçim olduğunu ve custom_id ile sonuçları güvenle eşleştiren dayanıklı bir akışı öğreneceksiniz.
Üç Çalışma Modu
Mod
Nasıl çalışır
Gecikme
Tipik maliyet
Uygun iş
Senkron
İstek atar, yanıtı beklersiniz
Saniyeler
Standart
Canlı sohbet, anlık asistan
Asenkron
İşi kuyruğa atar, bittiğinde haber alırsınız
Saniyeler–dakikalar
Standart
Arka plan görevleri, otomasyon adımları
Toplu (batch)
Binlerce isteği tek pakette gönderir, sonuçları sonra alırsınız
Dakikalar–saatler
Genellikle indirimli
Yüksek hacimli, gecikmeye toleranslı işler
Toplu işleme şudur: yüzlerce/binlerce isteği tek bir "iş" olarak sağlayıcıya gönderirsiniz; sağlayıcı bunları kendi hızında işler ve tamamlandığında sonuçların tümünü topluca verir. Karşılığında iki şey elde edersiniz: (1) genellikle daha düşük birim maliyet, (2) hız limitleriyle boğuşmadan yüksek hacmi taşıma. Bedeli, sonuçların anında değil, bir süre sonra gelmesidir.
Ne Zaman Batch, Ne Zaman Değil?
Karar tek soruyla verilir: Kullanıcı sonucu şimdi mi bekliyor?
- Hayır, bekletebilirim → batch adayı. Gece etiketleme, toplu özetleme, arşiv sınıflandırma, veri zenginleştirme, değerlendirme (eval) çalıştırma.
- Evet, ekranda bekliyor → senkron. Canlı sohbet, anlık öneri, form doldururken yardım.
İpucu: Aynı üründe iki mod bir arada yaşayabilir. Kullanıcı canlı sohbette senkron çalışır; gece o günün tüm konuşmalarını kalite analizi için batch'e verirsiniz. "Canlı ihtiyaç" ile "toplu ihtiyaç"ı ayırmak mimarinin ilk kararıdır.
Dayanıklı Batch Akışının Anatomisi
Toplu işlemenin en önemli teknik kuralı sonuç eşleştirmesidir.
- Her isteğe benzersiz bir `custom_id` verin. Bu, isteği tanımlayan sizin ürettiğiniz kimliktir (ör. fatura-2026-07-18-000431).
- İşi gönderin. Tüm istekler tek pakette gider; her biri kendi custom_id'si ile.
- Durumu yoklayın (poll). İş "tamamlandı" olana kadar aralıklarla durumu sorarsınız.
- Sonuçları `custom_id` ile eşleştirin. Sonuçlar gönderim sırasından farklı bir sırada dönebilir; bu yüzden asla konuma göre değil, her sonucun taşıdığı custom_id'ye göre eşleştirin.
- Her sonucun tipini kontrol edin. Bir istek başarılı olabilir, biri hata verebilir, biri süresi dolmuş olabilir. Başarı/başarısızlık durumuna göre işleyin.
{ "requests": [ { "custom_id": "fatura-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Faturayı sınıflandır. Yalnızca JSON döndür.", "messages": [{ "role": "user", "content": "{{fatura_metni}}" }] } }, { "custom_id": "fatura-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Faturayı sınıflandır. Yalnızca JSON döndür.", "messages": [{ "role": "user", "content": "{{fatura_metni_2}}" }] } } ]}
Dikkat: Sonuçları gönderim sırasına güvenerek eşleştirmek, batch'teki bir numaralı hatadır. Sıra korunmaz. custom_id olmadan hangi sonucun hangi belgeye ait olduğunu güvenle bilemezsiniz — yanlış eşleştirme sessizce yanlış veriye yol açar.
Kopyalanabilir Şablonlar
# custom_id üretme kuralı (benzersiz ve izlenebilir)Biçim: <istür>-<tarih>-<sıra>. Örnek: talep-20260718-000431Kural: iş içinde asla tekrar etme; kaynak kayıt kimliğini içine göm.
# Batch iş kartı (planlama şablonu)İş adı: .................Kayıt sayısı: .................Model: ................. (basit iş → hızlı model)İstek başı max_tokens: .................Beklenen teslim süresi toleransı: ......... saatSonuç eşleştirme anahtarı: custom_idHata durumunda: yeniden dene / kuyruğa al / raporla
# Batch içindeki tekil istek promptu (kısa ve şemalı)Bu belgeyi sınıflandır. Yalnızca şu JSON'u döndür, açıklama yazma:{"kategori":"...","aciliyet":"dusuk|orta|yuksek"}Belge: """{{belge}}"""
# Sonuç işleme sözde-koduher sonuç için: eğer sonuç.durum == "başarılı": kayıt = bul(custom_id) kaydet(kayıt, sonuç.çıktı) değilse: hatalıya_ekle(custom_id, sonuç.hata) # sonra yeniden dene
Zayıf prompt / Güçlü prompt (batch iş tasarımı)
# ZAYIF (kırılgan tasarım)10.000 belgeyi güçlü modelle sırayla gönder, dönen sonuçları geldiği sırayla kaydet.
# GÜÇLÜ (dayanıklı tasarım)10.000 belgeyi hızlı modelle tek batch olarak gönder.Her belgeye kaynak-kayıt kimliğini içeren benzersiz custom_id ver.Sonuçları custom_id ile eşleştir; başarısız olanları ayrı kuyruğa al ve yeniden dene.Gece penceresinde çalıştır; teslim toleransı 6 saat.
Güçlü sürüm; model seçimi, eşleştirme anahtarı, hata yönetimi ve zamanlamayı önden tanımlar. Bu, on binlerce kaydı güvenle işlemenin farkıdır.
Üç Mini Vaka
Vaka 1 — Gece etiketleme. Bir e-ticaret ekibi 200.000 ürün yorumunu duygu etiketine ayıracaktı. Canlı senkron akışta hem hız limitine takılıyor hem pahalıya mal oluyordu. İşi hızlı modelle geceye batch olarak taşıdılar; birim maliyet düştü, tüm set sabaha hazır oldu ve hiçbir hız limiti sorunu yaşanmadı.
Vaka 2 — Sıra karışması. Bir araştırma ekibi 5.000 makale özetini batch ile çıkardı ama sonuçları geldiği sırayla dosyalara yazdı. Sonuçlar farklı sırada döndüğü için 5.000 özetin yaklaşık 900'ü yanlış makaleye bağlandı. custom_id ile yeniden eşleştirdiler; sorun çözüldü ve bu deneyim kalıcı kural oldu: "Batch'te her zaman custom_id."
Vaka 3 — Yanlış modda canlı bekleme. Bir destek ekibi, kullanıcının ekranda beklediği canlı yanıtları batch'e vermeye çalıştı; sonuçlar dakikalar sonra geldiğinden kullanıcılar terk etti. Canlı işi senkrona geri aldılar, yalnızca gece yapılan kalite analizini batch'te bıraktılar. Ders: batch canlı bekleme için değildir.
Sık yapılan hatalar
- Sonuçları konuma göre eşleştirmek: Sıra korunmaz; custom_id kullanın.
- Canlı işi batch'e vermek: Kullanıcı dakikalarca bekleyemez; batch gecikmeye toleranslı işler içindir.
- Hata durumlarını işlememek: Bazı istekler başarısız/süresi dolmuş dönebilir; ayrı kuyruğa alıp yeniden deneyin.
- Batch'te güçlü model kullanma refleksi: Basit işlerde hızlı model + batch en ucuz kombinasyondur.
- custom_id'yi izlenebilir yapmamak: Kimliğe kaynak kaydı gömülmezse sonucu geri bağlamak zorlaşır.
- Durumu yoklamayı unutmak: İş bitmeden sonuç beklemek; tamamlanma durumunu kontrol edin.
Daha Derine: Batch'i İzlemek ve Kısmi Başarısızlığı Yönetmek
Toplu işlemenin en olgun yanı, tek tek çağrılardan farklı bir zihniyet gerektirmesidir: bir batch işi bir "olay" değil, bir "süreç"tir. On binlerce isteğin hepsinin başarılı olacağını varsaymak kırılganlıktır; gerçekçi tasarım kısmi başarısızlığı baştan kabul eder. Her sonucun durumu farklı olabilir: başarılı, hatalı (ör. geçersiz girdi), iptal edilmiş veya süresi dolmuş. Sağlam bir akış, sonuçları dolaşırken her birinin durumunu ayrı işler, başarısızları ayrı bir "yeniden deneme kuyruğuna" alır ve bu kuyruğu ayrıca çalıştırır.
İkinci pratik, idempotentlik (aynı işi iki kez çalıştırmanın zarar vermemesi) tasarlamaktır. Bir batch yarıda kesilir ve yeniden başlatırsanız, zaten işlenmiş kayıtları tekrar işleyip iki kez yazmamalısınız. custom_id'yi kaynak kaydınıza bağlamak burada da işe yarar: sonucu kaydetmeden önce "bu kayıt zaten işlendi mi?" kontrolü yapmak, mükerrer yazmayı önler.
Üçüncü nokta, batch ile canlı akışları kademelendirmektir. Bazı işler hem canlı hem toplu boyut taşır: kullanıcı bir belgeyi yüklediğinde ona hızlı bir ön özet (senkron) verir, aynı belgeyi gece daha derin bir analiz için (batch) yeniden işlersiniz. İki modu bilinçli ayırmak, hem kullanıcı deneyimini hem maliyeti optimize eder.
Son olarak batch, hız limitleriyle (8. ünite) başa çıkmanın da bir yoludur. Yüksek hacmi canlı senkron akışta göndermek sürekli 429 üretirken, aynı hacmi batch'e vermek limit baskısını sağlayıcının kendi zamanlamasına devreder ve işi daha öngörülebilir kılar.
Özetle
Toplu işleme, gecikmeye toleranslı ve yüksek hacimli iş yükleri için genellikle daha ucuz ve daha dayanıklı bir moddur. Kararı "kullanıcı sonucu şimdi mi bekliyor?" sorusu belirler. En kritik teknik kural, her isteğe benzersiz bir custom_id verip sonuçları konuma göre değil kimliğe göre eşleştirmek ve her sonucun başarı/başarısızlık durumunu ayrı ele almaktır.
Uygulama görevi
Yüksek hacimli bir işinizi seçin (ör. arşiv sınıflandırma). (1) Bu işin canlı mı toplu mu olduğuna karar verin ve gerekçelendirin. (2) Bir custom_id biçimi tasarlayın (kaynak kaydı içersin). (3) Batch iş kartını doldurun (model, max_tokens, tolerans, hata politikası). (4) Sonuç işleme sözde-kodunu, başarısız istekleri de kapsayacak şekilde yazın.
Kontrol listesi
- [ ] Senkron, asenkron ve batch modlarını maliyet/gecikme ekseninde ayırt edebiliyorum.
- [ ] Bir işin batch'e uygun olup olmadığına doğru soruyla karar verebiliyorum.
- [ ] Her isteğe benzersiz custom_id verip sonuçları kimliğe göre eşleştiriyorum.
- [ ] Başarısız/süresi dolmuş sonuçları ayrı ele alabiliyorum.
- [ ] Basit batch işlerinde hızlı model tercih etmenin getirisini biliyorum.