Yerel LLM İş Akışları İçin Dayanıklı Yürütme (Durable Execution): Öğrendiklerim

Çoğu büyük dil modeli (LLM) demosu, çalışan sürecin kesintisiz olarak hayatta kalacağını varsayar. Ancak süreci yarıda keserseniz oluşturulan plan, araç (tool) sonuçları ve bağlam tamamen kaybolur. Üretim seviyesinde yazılım geliştirirken bu kırılganlığı aşmak kritik bir öğrenme adımıdır. Süreç kesintilerine dayanıklı araçlarla çalışırken edindiğim temel çıkarımlar, LLM tabanlı sistemlerin mimarisini nasıl kurmamız gerektiğini yeniden şekillendiriyor.

Dayanıklı Yürütme (Durable Execution) Hata Algınızı Değiştirir#

Temporal, bir iş akışının her adımını bir olay geçmişine (event history) kaydeder. Çalışan bir süreç (worker) çökerse, başka bir süreç bu geçmişi yeniden oynatır (replay) ve tamamlanan son adımdan devam eder. Böylece bitmiş işler iki kez çalıştırılmaz. LLM iş akışları ve ajan mimarileri için bu yaklaşım mükemmel bir uyum sağlar:

• Model ve araç çağrıları aktivitelere (activities) aittir: LLM ve dış araç çağrıları yavaştır, deterministik değildir ve başarısız olabilirler. Aktiviteler tam olarak bu tür riskli işlemleri izole etmek için tasarlanmıştır. Pratik çıkarım olarak, dış dünya ile iletişim kuran her adımı bir aktivite içine sarmalamalısınız.
• İş akışı (workflow) kodu deterministik kalmalıdır: Yeniden oynatma (replay) mekanizması buna bağlıdır. Bu nedenle rastgelelik (randomness), doğrudan ağ çağrıları ve zaman damgaları iş akışı kodunun dışında tutulmalıdır. İş mantığınızı saf ve öngörülebilir bir orkestrasyon katmanı olarak kurgulamalısınız.
• Yeniden denemeler (retries) kod değil, politikadır: Bekleme süreleri (backoff) ve zaman aşımları (timeouts), iç içe geçmiş karmaşık try/catch blokları yerine yapılandırma (configuration) olarak tanımlanır. Bu yaklaşım, kodunuzu temiz tutarken hata yönetimini standartlaştırır.

Yerel Modeller Hata Testlerini Ucuzlaştırır#

Ollama aracılığıyla yerel bir model çalıştırmak, geliştirme döngüsünü tamamen kendi makinenizde tutar. Hız sınırları (rate limits) veya API faturası yoktur ve bir süreci çalışırken yarıda kesmenin maliyeti sıfırdır. Bu durum, gerçek hataların çoğunun gizlendiği "mutsuz yolları" (unhappy path) sık sık test etmeyi kolaylaştırır. Geliştiriciler için en büyük pratik avantaj, kaos mühendisliğini yerel ortamda bedavaya deneyimleyebilmektir.

Bunun karşılığında ortaya çıkan ödünleşim (trade-off), küçük yerel modellerin barındırılan (hosted) büyük modellere göre daha az tahmin edilebilir olmasıdır. Dayanıklı yürütme burada devreye girer; çünkü hatalı bir adım, tüm süreci baştan çalıştırmaya gerek kalmadan tek başına yeniden denenebilir veya incelenebilir.

Göremediğiniz Şeye Güvenemezsiniz#

Yeniden denemeler ve kaldığı yerden devam etmeler varsayılan olarak görünmezdir ve görünmez hatalar ayıklanması (debug) en zor olanlardır. Sentry'nin izleme (tracing) özelliği bu noktada çok iyi bir çözümdür; çünkü adım başına oluşturulan bir iz (trace), hangi çağrının yavaş olduğunu, hangisinin yeniden denendiğini ve çalışmanın tam olarak nereden devam ettiğini gösterir.

İş akışı geçmişinin üzerine inşa edilen küçük bir React kontrol paneli (dashboard) bu süreci daha da kolaylaştırır. Bir çalışmanın denemelerini zaman çizelgesi (timeline) olarak görselleştirmek, satırlarca metin tabanlı log okumaktan çok daha etkilidir.

Üzerinde Çalışmaya Devam Ettiğim Açık Sorular#

Bu mimariyi derinleştirirken yanıt aradığım ve her sistem tasarımcısının düşünmesi gereken üç temel soru bulunuyor:

• Yeniden oynatma (replay) işlemi yavaşlamadan önce iş akışı geçmişinde ne kadar durum (state) verisi tutulabilir?
• Hangi hatalar sürecin kaldığı yerden devam etmesini sağlamalı, hangileri çalışmayı tamamen durdurmalıdır?
• Dayanıklılık (durability), istemleri (prompts) ve araç tanımlarını (tool definitions) yazma şeklimizi değiştirir mi?

Bu sorulara yanıtlar buldukça öğrendiklerimi paylaşmaya devam edeceğim.

---

Bu konuyu derinlemesine öğrenmek isterseniz: Production'da Agent Güvenilirliği modülüne göz atın.