Yapay Zeka Ajanı Orkestrasyonu: Hatalar, Onaylar ve Yeniden Denemeler

Aynı proje üzerinde birden fazla ajanın çalışması son derece verimli görünüyor. Biri işi planlar, bir diğeri tasarımı üstlenir, üçüncüsü de kodu yazar. Ta ki işler ters gidene kadar. Üstelik hatalar sandığınızdan daha sık yaşanır.

Bu hataları önlemek dikkatli bir iş akışı mühendisliği gerektirir. O hâlde orkestre edilmiş iş akışlarını neyin güvenilmez kıldığını inceleyelim ve üretim ortamında güvenilirlik için orkestrasyonun en iyi uygulamalarını keşfedelim.

Yapay zeka ajanı orkestrasyonu, çok adımlı bir görevi tamamlamak için birden fazla yapay zeka ajanını, modeli ve aracı koordine eder. Ancak hangi ajanın önce çalışacağına, hangi bilgiyi alacağına ve işini bitirdikten sonra ne olacağına yine birinin — ya da bir şeyin — karar vermesi gerekir. Bu, orkestratörün rolüdür — yönetici gibi davranan bir yapay zeka ajanı ya da yazılımla denetlenen bir yürütme katmanı.

Basitçe söylemek gerekirse bir orkestrasyon katmanı bir hedefi daha küçük görevlere böler, bağımlılıkları takip eder, yürütmeyi doğru ajanlara devreder, paylaşılan bağlamı yönetir ve çıktıları bir araya getirir.

Orkestrasyon yürütme motorunun diyagramı: hedef ve plan, ajanlara yönlendirme, araçları yalıtılmış ortamda yürütme, yapılandırılmış sonuçlar, kalıcı iş akışı durumu ve yeniden deneyen, geri dönen, duraklatan, bekleyen veya bir sonraki göreve geçen bir doğrulama ve karar adımı.

Bir orkestratöre görev verdikten sonra neler olduğuna bakalım.

Perplexity’nin Computer atölyesinden bir örneği ele alalım: Salesforce, Snowflake, e-posta, takvim ve son haberlerden gelen bilgileri kullanarak bir hesap istihbaratı panosu oluşturmak.

Hedefi anlama ve işi planlama. Orkestratör istenen sonuçla başlar ve bunu açık bağımlılıkları olan görevlere ayırır. Pano örneğimizde bu, farklı kaynaklardan bilgi toplamayı ve bunları tamamlanmış bir çıktıya dönüştürmeyi içerir. Planlayıcı, hangi adımların diğerlerine bağlı olduğunu ve hangilerinin bağımsız olarak çalışabileceğini belirler.
Görevleri uygun ajanlara yönlendirme. Orkestratör, bağımlılıkları karşılanmış görevleri belirler ve işi uzmanlaşmış ajanlara veya modellere devreder. Bağımlı görevler ön koşullarının tamamlanmasını bekler. Perplexity Computer birden fazla öncü model kullanır ve iş akışının farklı bölümlerini bu görevlere uygun sistemlere yönlendirir. Bu aynı zamanda bağımsız işlerin paralel olarak çalışmasına olanak tanır.
Araç çağrılarını denetimli ortamlarda yürütme. Ajanlar, ortamlarıyla web araması, API’ler, bağlı uygulamalar, dosya işlemleri veya kod yürütme gibi araçlar aracılığıyla etkileşime girer. Yürütme katmanı bu eylemleri çalıştırır ve sonuçları ajanlara döndürür.
Sonuçları ve bağlamı ajanlar arasında aktarma. Bir ajan görevini bitirdiğinde, akıştaki bir sonraki ajanın devam edebilmesi için ilgili çıktıya ihtiyacı vardır. Bir devir kaydı görev kimliği, çıktı referansı, şema sürümü ve kaynak meta verilerini içerebilir. Orkestratör, sonraki adımlar için gereken bağlamı korurken bu devirleri koordine eder. Önemli olan, ajanların diğer her ajanın çalışmasının tüm geçmişini kendi bağlam pencerelerinde taşımak zorunda olmamasıdır.
Yürütme durumunu ajan bağlamından ayrı olarak kaydetme. Ajanlar görevlere başladıkça, görevleri tamamladıkça veya görevlerde başarısız oldukça yürütme motoru; görev durumları, yürütme denemeleri, çıktı referansları ve kalan işlerle kalıcı bir iş akışı kaydını günceller. Bu kayıt, orkestratörün ilerlemeyi takip etmesini ve iş akışını konuşma geçmişinden yeniden oluşturmak için bir LLM’e güvenmeden kesintilerin ardından kaldığı yerden devam etmesini sağlar.
Sonuçları doğrulama ve sonraki adıma karar verme. Bir görev sonuç döndürdüğünde orkestrasyon katmanı, çıktının beklenen sözleşmeyi karşılayıp karşılamadığını ve bir sonraki görevin bağımlılıklarının sağlanıp sağlanmadığını kontrol eder. Bir sorun bulunursa iş akışı düzeltme için önceki bir adıma dönebilir veya duraklatılabilir. Aksi takdirde tamamlanmaya doğru ilerler.

Basit görünen yapay zeka ajanı orkestrasyonunun arkasında pek çok hareketli parça vardır. Ajan koordinasyonunu nasıl düzenlediğiniz, yürütme üzerinde ne kadar denetime sahip olacağınızı belirler. Elbette tüm bu koordinasyon ek yük getirir. Bu yüzden her zaman buna değmez.

Görevin farklı bölümleri ayrı uzmanlıklar gerektirdiğinde, bağımsız işler paralel olarak çalışabildiğinde veya bir sonraki adımı önceden belirleyemediğinizde çoklu ajan orkestrasyonunu değerlendirin.

Dolayısıyla orkestrasyon üç senaryoda faydalıdır:

Görevler farklı uzmanlıklar gerektirir. Örneğin bir kodlama projesi; ayrı planlama, tasarım, geliştirme ve inceleme ajanlarından fayda sağlayabilir.
Bağımsız görevler paralel olarak çalışabilir. Her şeyi tek bir ajanın sırayla tamamlaması yerine, birden fazla ajan aynı anda çalışabilir ve sonuçlarını bir orkestratöre döndürebilir.
Sorunun ucu açıktır. Ajanların önceden tanımlanmış bir sırayı izlemek yerine farklı yaklaşımları keşfetmesi, kararlar alması ve iş birliği yapması gerekebilir.

Bunların dışında orkestrasyon yalnızca maliyetli bir trendden ibarettir. Daha fazla ajan, daha fazla koordinasyon ve potansiyel olarak daha yüksek token maliyetleri anlamına da gelir.

“Genellikle en basit seçenekle başlar ve oradan ilerlerim. Adımları biliyorsak ve bu adımlar tekrarlanabilirse, bu muhtemelen bir iş akışıdır. Birden fazla ajanı devreye sokmak için ancak ajanların farklı sorumlulukları, izinleri veya kullanıcıları olduğunda bir neden görüyorum” diyor Josh Spilker (AirOps arama pazarlaması başkanı).

O durumda bile faydaları; ek model çağrıları, devirler, gecikme ve hata noktalarıyla karşılaştırarak tartın.

Ajan koordinasyonunu yapılandırmanın üç yaygın yolu vardır: merkezi, merkeziyetsiz ve hiyerarşik orkestrasyon. Doğru mimariyi seçmek tek bir soruya dayanır: İşi kim denetliyor ve ajanlar birbirleriyle nasıl koordine oluyor?

Merkezi orkestrasyonda süreci tek bir orkestratör yönetir. Orkestratör görevi parçalara ayırır, işi uzman ajanlara devreder, ilerlemelerini takip eder ve sonuçlarını bir araya getirir.

Merkezi orkestrasyon diyagramı: tek bir orkestratör kullanıcı isteğini alır ve işi, her biri kendi araçlarını kullanan araştırma, analiz ve tasarım ajanlarına devreder; bu ajanların sonuçları birleşerek nihai bir pano oluşturur.

Ödünleşim: Merkezi koordinasyon, yürütmeyi takip etmeyi ve ortak kuralları tek bir denetim noktasında uygulamayı kolaylaştırır. Ancak orkestratör bir darboğaza dönüşebilir ve sistem kurtarmayı desteklemiyorsa orkestratördeki bir arıza tüm iş akışını kesintiye uğratabilir.

Merkeziyetsiz orkestrasyonda ajanlar, her kararı vermesi için tek bir yöneticiye güvenmek yerine daha doğrudan koordine olur. Mesaj alışverişi yapabilir, paylaşılan durumu okuyabilir ve sonraki adımlarını bağımsız olarak belirleyebilirler.

Merkeziyetsiz orkestrasyon diyagramı: araştırma, analiz, tasarım ve inceleme ajanları nihai bir pano üretmek için birbirleriyle ve paylaşılan durum ve araçlarla doğrudan iletişim kurar.

Ödünleşim: Ajanlar merkezi bir planlayıcıyı beklemeden çalışabilir; bu da yaklaşımı keşif odaklı işler ve bağımsız katkılar için kullanışlı kılar. Ancak ajanlar anlaşmazlığa düştüğünde, paylaşılan bilgileri güncellediğinde veya tutarlı bir sonuca ulaşması gerektiğinde koordinasyon zorlaşır.

Hiyerarşik orkestrasyon, yönetici yaklaşımını birden fazla düzeye yayar. Üst düzey bir orkestratör sorumluluğu alt orkestratörlere devreder; bunlar da kendi uzman ajan gruplarını koordine eder.

Satış, finans ve hukuk ekiplerini içeren bir kurumsal iş akışını düşünün. Üst düzey bir orkestratör her iş kolunu alana özgü bir koordinatöre devredebilir. Bu koordinatörler de kendi uzman ajanlarını yönetir ve sonuçları birleştirerek raporlar.

Bu yapı, iş akışları tek bir orkestratörün etkili bir şekilde yönetemeyeceği kadar geniş olduğunda yardımcı olabilir.

Hiyerarşik orkestrasyon diyagramı: üst düzey bir orkestratör, her biri iki uzman ajanı yöneten satış, finans ve hukuk orkestratörlerine iş devreder; bunların çalışmaları birleşerek konsolide bir çıktı oluşturur.

Ödünleşim: Hiyerarşiler, ekiplerin koordinasyon sorumluluklarını bölüştürmesine ve arızaları potansiyel olarak tek tek dallar içinde ele almasına olanak tanır. Ancak ek devirler, daha karmaşık durum yönetimi ve daha fazla operasyonel yük getirirler. Yerel kurtarma da kontrol noktalarının ve yürütme durumunun nasıl uygulandığına bağlıdır.

Bu mimarilerin karşılaştırması:

Ölçüt	Merkezi	Merkeziyetsiz	Hiyerarşik
Yürütme sahipliği	Devretmeyi tek bir orkestratör denetler	Ajanlar eşler veya paylaşılan durum aracılığıyla koordine olur	Sorumluluk orkestrasyon düzeylerine dağıtılır
Durum tutarlılığı	Tek bir denetim noktası üzerinden koordine etmek daha kolaydır	Açık senkronizasyon ve çakışma yönetimi gerektirir	Dallar içinde ve dallar arasında koordinasyon gerektirir
Arıza yalıtımı	Merkezi denetleyici kritik bir bağımlılık hâline gelebilir	Tek tek ajanlar bağımsız olarak başarısız olabilir, ancak paylaşılan altyapı kritik olmaya devam eder	Kurtarma için tasarlanmışsa arızalar dallar içinde sınırlandırılabilir
Politika uygulaması	Ortak denetimler merkezi olarak uygulanabilir	Politikaların tüm katılımcılar arasında tutarlı biçimde uygulanması gerekir	Denetimler küresel ve etki alanı düzeylerinde uygulanabilir
Operasyonel karmaşıklık	Genellikle daha düşük	Daha yüksek koordinasyon karmaşıklığı	Birden fazla orkestrasyon katmanından kaynaklanan daha yüksek karmaşıklık

Anlaşılması gereken bir ayrım daha var. Mimari, ajanları kimin koordine ettiğini belirler. Yürütme modeli ise görevlerin nasıl ilerlediğini belirler.

Üç yürütme modeli şunlardır:

Sıralı iş akışları: Ajanlar önceden tanımlanmış bir sırayla çalışır ve bir ajanın sonucu diğerinin girdisi olur.
Paralel yürütme: Bağımsız ajanlar aynı anda çalışır.
Devir tabanlı yürütme: Görev ilerledikçe kontrol, uzman ajanlar arasında el değiştirir. Bu yöntem, sonraki adımı ele almak için başka bir ajan daha donanımlı olduğunda faydalıdır; ancak her devir, devam etmek için gereken bilgileri korumalıdır.

Bu modeller birbirini dışlamaz ve orkestrasyon mimarileriyle bire bir eşleşmez. Amaç, iş akışınızın bağımlılıklarını, koordinasyon gereksinimlerini ve kabul edilebilir operasyonel yükünü destekleyen en basit yapıyı seçmektir.

Orkestrasyonda basit gözden kaçırmalardan karmaşık engellere kadar her şey ters gidebilir. Hatta bazen bir ajan işini doğru yapıyor gibi görünürken genel iş akışı başarısız olabilir. Uygulayıcıların deneyimlerinden yola çıkarak, güvenilmez orkestre edilmiş iş akışlarının ardındaki yaygın hatalardan bazılarını derledik — bunlara dikkat edin:

Bilgi kaybına yol açan ajan devirleri. Bir orkestratör, uzman bir ajana özetlenmiş bir plan iletir, ancak özet kısıtlamaları, bağımlılıkları veya uygulama ayrıntılarını dışarıda bırakır.
Erken birleştirme (fan-in) yürütmesi. Akış aşağısındaki bir ajan, akış yukarısındaki tüm görevler tamamlanmadan sonuçları birleştirmeye başlar.
Deterministik olmayan paylaşılan durum güncellemeleri. Paralel ajanlar, iyi tanımlanmış birleştirme semantiği olmadan aynı durum anahtarlarına yazar. Çerçevenin güncellemeleri nasıl işlediğine bağlı olarak bu durum kayıp yazma işlemlerine, yinelenen verilere, sıraya bağlı çıktılara veya çakışan değişikliklere yol açabilir.
Kontrol noktası ve yan etki uyuşmazlığı. Bir görev harici bir işlem gerçekleştirir, ancak başarılı yürütmesi, çalışan (worker) başarısız olmadan önce kalıcı olarak kaydedilmez. Kurtarma sırasında orkestratör tamamlanmamış bir görev görür ve onu yeniden çalıştırır.
İnsan onayıyla devam ettirmede yarış koşulları. Yürütmeyi duraklatmak ve devam ettirmek, kendine özgü senkronizasyon sorunlarına yol açar.
Yetki devri döngüleri ve yeniden deneme çoğalması. Sorumlulukları örtüştüğü, bağımlılıkları döngüsel olduğu veya tamamlanma koşulları belirsiz olduğu için ajanlar işi tekrar tekrar birbirine devreder.
Yürütme güvenliği sanılan talimat düzeyindeki denetimler. Bir orkestratör, ajanlara belirli kaynaklara erişmemelerini veya hassas eylemler gerçekleştirmemelerini söyleyebilir; ancak model talimatları işletim sistemi izinlerini, ağ kısıtlamalarını veya yetkilendirme sınırlarını uygulamaz. Perplexity’nin güvenlik mühendisliği araştırması, kötü amaçlı talimatlar olmasa bile ajanların meşru hedeflerin peşinden giderken neden güvenlik sınırlarını aşabildiğini vurguluyor

Bu hataların ne kadar farklı olduğuna dikkat edin. Erken bir zamanlayıcı geçişi de belirsiz bir harici yazma işlemi de hatalı bir sonuca yol açabilir, ancak bunlar yürütme yaşam döngüsünün farklı bölümlerinden kaynaklanır. Bu nedenle güvenilir orkestrasyon, istemleri iyileştirmekten veya yeniden denemeler eklemekten fazlasını gerektirir.

Belirsiz hedefler ve net olmayan bir tamamlanma tanımı, çoğu zaman ajanların hayal kırıklığı yaratan sonuçlar üretmesine yol açar. Çözüm, bir istem sözleşmesi (bir ajan için iş kapsamı) oluşturmaktır: Yürütme başlamadan önce hedef, kısıtlamalar, çıktı biçimi ve başarısızlık koşulları üzerinde anlaşın.

Örneğin, aralıklı olarak başarısız olan bir entegrasyon testini düzeltmekten sorumlu bir ajan için sözleşmeyi şöyle tanımlayabilirsiniz:

Hedef: Kararsız çalışan (flaky) bir ödeme API’si entegrasyon testinin nedenini belirleyip düzeltmek.
Girdiler: Test kaynak kodu, CI hata günlükleri, son commit’ler ve ilgili uygulama kodu.
Kısıtlamalar: Testleri devre dışı bırakmayın, doğrulamaları (assertion) gevşetmeyin veya ilgisiz uygulama davranışlarını değiştirmeyin.
Beklenen çıktı: Bir kod yaması, kök nedenin açıklaması ve test yürütme sonuçları.
Kabul kriterleri: Daha önce başarısız olan test art arda 10 çalıştırmada başarılı olur ve ilgili regresyon test paketi geçer.
Başarısızlık koşulları: Kök neden belirlenemez, düzeltme regresyonlara yol açar veya gerekli test ortamı kullanılamaz.

Ancak önemli bir nokta daha var: Ajan ne zaman durmalı?

Bir ajan, tatmin edici bir sonuç üretemedi diye süresiz olarak yinelemeye devam etmemelidir. Neyin başarılı tamamlanma sayılacağını, kısmen tamamlanmış bir görevin ne zaman döndürüleceğini ve bir gereksinim karşılanamadığı için ne zaman durulacağını tanımlayın. Çözülemeyen görevlerin sonsuz döngülere dönüşmemesi için maksimum yetki devri derinliği ve yineleme sınırları ya da yürütme bütçeleri belirleyin.

CI örneğimize dönelim. Şu durma koşullarını tanımlayabilirsiniz:

Başarı: Düzeltme, art arda 10 test çalıştırmasını ve ilgili regresyon test paketini geçer.
Yineleme sınırı: Ajan en fazla iki aday düzeltme deneyebilir.
Yürütme bütçesi: Sorun çözülmemiş olsa bile ajan 60 dakika sonra durmalıdır.
Yetki devri sınırı: Ajan işi tek bir uzman ajana devredebilir; bunun ötesinde alt ajanlara devir yapılamaz.
Kısmi tamamlanma: Her iki deneme de başarısız olursa veya süre sınırı dolarsa ajan bulgularını, denediği değişiklikleri ve test sonuçlarını döndürür.
Engellenen yürütme: Test ortamı kullanılamıyorsa ajan başarı iddia etmek yerine durur ve engeli bildirir.

Geliştiriciler bazen bir orkestratöre çok fazla sorumluluk yükler; orkestratör de uzman ajanları koordine etmek yerine kendisi kod yazmaya, hata ayıklamaya veya ayrıntılı incelemeler yapmaya başlar. Bu bir darboğaz yaratır: Orkestratör bağlam bütçesini uygulama ayrıntılarına harcar, yetki devrini geciktirir ve sonuçlara ilişkin sorumluluğu bulanıklaştırır.

Bu yüzden orkestratörlerin kendi işini yapmasına izin verin ve devirleri somut yapıtlara başvurarak zorunlu kılın: orijinal görev, ilgili girdiler, çıktı yapıtları, yürütme durumu ve çözülmemiş sorunlar.

Şu örneği ele alın: status: completed, tüm iş akışını değil, ajana atanan işi ifade eder. Testler hâlâ pending durumunda olduğundan orkestratör nihai sonucu onaylamamalıdır.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

Bir ajanın konuşma geçmişi, iş akışı ilerlemesinin güvenilir bir kaydı değildir. Bağlam penceresi dolduğunda otomatik sıkıştırma önemli ayrıntıları atabilir. Bir çalışan (worker) çöktüğünde ise sonraki ajanın hangi adımların gerçekten tamamlandığını bilmesi gerekir.

Örneğin, kodlama ajanı bir yama oluşturup ardından çökerse, sonraki çalışan kaydedilmiş yapıtı almalı ve kaydedilen iş akışı durumundan devam etmelidir. Ancak ajan ayrıca harici bir CI çalıştırmasını tetiklediyse, orkestratör eylemi tekrarlamadan önce bu çalıştırmayı ayrıca uzlaştırmalıdır

Bu nedenle yürütme durumunu ajanın çalışma bağlamından ayrı tutun. Görev durumlarını, yürütme denemelerini, tamamlanan adımları ve yapıt referanslarını kalıcı depolamada saklayın. Bu arada, tüm yürütme geçmişini bağlam penceresine doldurmak yerine yalnızca ajanın mevcut göreviyle ilgili talimatları, girdileri ve sonuçları yükleyin.

CI ajanınızın bir test çalıştırmasını tetiklediğini, ancak API isteğinin zaman aşımına uğradığını varsayalım. Test çalıştırması başlatılamadı mı, yoksa CI hizmeti onu kuyruğa alıp yanıtı mı kaybetti?

Zaman aşımı, bir işlemin başarısız olduğu anlamına mutlaka gelmez. Bu nedenle sonrasında ne olacağına karar vermeden önce hataları birbirinden ayırt etmeniz gerekir:

Geçici hatalar (429, 503): Sınırlı üstel geri çekilme (exponential backoff) ve rastgele gecikme (jitter) ile yeniden deneyin; sağlandığında Retry-After değerine uyun.
Doğrulama veya izin hataları (400, 403): Aynı isteği tekrarlamak yerine durun veya temeldeki sorunu düzeltin.
Belirsiz sonuçlar (olası bir yazma işleminden sonra zaman aşımı): Tekrar denemeden önce işlemin başarılı olup olmadığını kontrol edin.

Not: Yeniden denenebilir hataların bile sınırları olmalıdır. Her araç çağrısı için bir zaman aşımı belirleyin, yeniden deneme sayısını ve toplam yeniden deneme süresini sınırlayın ve iç içe ajanların aynı işlemi sürekli yeniden başlatamaması için genel bir iş akışı son tarihi uygulayın. Bir bağımlılık tekrar tekrar başarısız olursa istekleri geçici olarak durdurmak için devre kesici (circuit breaker) kullanın.

Harici yan etkileri olan işlemler için her mantıksal eyleme sabit bir eş etkililik (idempotency) anahtarı atayın ve yeniden denemelerde bu anahtarı tekrar kullanın. API sunucu tarafında tekilleştirmeyi destekliyorsa, eylemi iki kez gerçekleştirmeden yinelenen istekleri tanıyabilir. Desteklemiyorsa, harici sistemi bir korelasyon kimliği veya başka bir yetkili referans kullanarak sorgulayın.

Ne olduğunu belirleyemediğinizde durun ve konuyu üst kademeye iletin.

CI ajanımız için yeniden deneme mantığının sözde kodla ifade edilmiş bir örneği:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

Kod notu: Örnek, CI API’sinin çalıştırmaları istek kimliğine göre aramayı desteklediğini varsayar. request_id yalnızca sağlayıcı eş etkililiği açıkça garanti ediyorsa yinelemeleri önler. bounded_retry() açıklama amaçlı bir sözde koddur. Üretimde yeniden denemeler hem işlem başına bir yeniden deneme bütçesiyle (maksimum deneme sayısı veya geçen süre) hem de genel iş akışı son tarihiyle sınırlandırılmalıdır.

Birden fazla hizmeti kapsayan daha uzun iş akışlarında, sonraki adımlar başarısız olduğunda telafi edici eylemleri koordine etmek için Saga modelini değerlendirin. Ancak telafinin her zaman tam bir geri alma anlamına gelmediğini unutmayın. Bir veritabanı güncellemesini geri alabilirsiniz, ancak gönderilmiş bir e-postayı geri alamazsınız.

Burada dengelenmesi gereken iki şey var: Her görevin ne kadar model yeteneğine ihtiyaç duyduğu ve aynı anda kaç görev çalıştırabileceğiniz. Bunlardan birini yanlış ayarlarsanız ajanların paylaşılan API kotaları için yarışması ya da yalnızca pahalı akıl yürütme modellerine bağımlı kalması riskiyle karşılaşırsınız.

Söz konusu model seçimi olduğunda, model yeteneğini ve akıl yürütme çabasını görev karmaşıklığıyla eşleştirin — basit ama oldukça göz ardı edilen bir ilke. Yönlendirme kurallarını yapılandırıp modelleri kendiniz değerlendirebileceğinizi ya da model seçimini sizin yerinize yapan bir orkestrasyon platformu kullanabileceğinizi unutmayın.

Örneğin Perplexity Computer’ın Effort Mode özelliği, elle model seçmenize gerek kalmadan bir görevin ne kadar çaba gerektirdiğini belirlemenizi sağlar. Light, Standard, High veya Ultra seçeneklerinden birini belirleyin; Perplexity orkestrasyonu yürüten modeli ve akıl yürütme düzeyini otomatik olarak seçer. Ardından bu orkestratör, alt görevleri farklı sağlayıcıların modellerini kullanabilen destekleyici ajanlara devreder.

Perplexity, model yapılandırmalarını kalite ve maliyet açısından değerlendirir ve benzer sonuçlar veren daha düşük maliyetli seçenekleri tercih eder. Modeli ve akıl yürütme düzeyini kendiniz seçmeyi tercih ederseniz Custom denetimlerini de kullanabilirsiniz.

Paralellik açısından sınır, altyapınızdan ve harici bağımlılıklarınızdan gelmelidir. Paylaşılan API’lerin istek ve token hız sınırlarını doğrulayın, ardından iş akışınızı artan eşzamanlılıkla yük testine tabi tutun. İş hacminin artıp artmadığını ya da isteklerin kuyruğa girmeye, yavaşlamaya veya 429 hataları döndürmeye başlayıp başlamadığını izleyin.

Kaynak tüketimini öngörülebilir tutmak için kaynak sınırları ve zamanlama denetimleri uygulayın:

Eşzamanlılığı ve istek hızlarını kontrol edin: Hizmet başına devam eden çağrı sayısını sınırlayın ve fazla işi kuyruğa alın. Tek başına bir eşzamanlılık sınırının dakika başına istek veya dakika başına token sınırlarını uygulamayacağını unutmayın.
Token ve maliyet bütçelerini takip edin: Alt ajanlar dahil tüm iş akışı genelindeki kullanımı hesaba katın ve kalan bütçe yetersiz olduğunda yeni iş başlatmayı durdurun.
Yürütme son tarihlerini uygulayın: Görev ve iş akışı süre sınırları belirleyin ve desteklendiği durumlarda iptal işlemini çalışan ajanlara iletin.
Bağımlılıklara uyun: Tüm ajanları aynı anda başlatmak yerine akış aşağısındaki görevleri yalnızca gerekli girdileri hazır olduğunda başlatın.

Modelden kendi eylemlerinin güvenli olup olmadığına karar vermesini asla istemeyin. Bunun yerine ajanlara en az ayrıcalık ilkesine göre izinler verin ve risk tabanlı onay kurallarını uygulama kodu içinde zorunlu kılın. Ajanlar kod çalıştırıyorsa bu yürütmeyi ana makine ortamınızdan yalıtın ve dosyalara, ağlara ve kimlik bilgilerine erişimi kısıtlayın. Bu, ajan bir hata yaptığında veya güvenli olmayan kod çalıştırdığında oluşacak hasarı sınırlar.

“Özellikle ajanların birbirinin işini incelediği ve onayladığı durumlarda, aşırı karmaşık çoklu ajan sistemlerine şüpheyle yaklaşıyorum. Sonunda birkaç ajanın aynı hatayı kendinden emin bir şekilde birbirine aktardığı ve kimsenin bunu gerçekten fark etmediği bir durumla karşılaşabilirsiniz,” diye uyarıyor Spilker.

Onay akışı diyagramı: Bir ajan, parametreleri, hedef kaynağı ve durum sürümünü içeren bir işlem önerir; bir insan bunu onaylar veya reddeder; onaylanan işlemler yeniden doğrulanır ve dosya, ağ ve kimlik bilgisi erişimi sınırlı, yalıtılmış bir ortamda çalıştırılır. Reddedilen veya süresi dolan istekler kapatılır; değişen istekler ise yeni onay gerektirir.

İnsan onayı gerektiren eylemler için yürütmeyi duraklatın ve önerilen işlemi tam haliyle, şu bilgilerle birlikte kaydedin:

parametreleri
hedef kaynağı
commit’i veya durum sürümü
inceleyenin kararı

Ayrıca onay reddedilirse, süresi dolarsa veya üst kademeye iletilmesi gerekirse ne olacağını tanımlayın. Bu, devam ettirilebilir çerçeveler için kritik önem taşır; çünkü kesintiye uğrayan bir düğümü devam ettirmek, kodu o düğümün başından itibaren yeniden yürütür. Kesintiden önceki tüm yan etkiler yeniden çalışabilir.

Dolayısıyla onay reddedilirse veya süresi dolarsa istek kapanır. Hedef commit, parametreler veya izinler yürütmeden önce değişirse onayı geçersiz kılın ve yeni bir onay isteyin.

Spilker, hedef olarak görülen tamamen otonom, uçtan uca ajanlar fikrini de desteklemiyor. “Bence daha iyi yaklaşım, net sorumlulukları ve tanımlanmış izinleri olan, doğru noktalarda insan incelemesinden geçen birkaç odaklı ajan oluşturmak. Böylece tam kontrolden vazgeçmeden verimlilik elde edersiniz,” diyerek sözlerini tamamlıyor.

Hiç aslında başarısız olduğu halde Success bildiren bir ajanla karşılaştınız mı? Çileden çıkarıcı değilse bile can sıkıcıdır ve düzeltmesi hızlı olmaz, çünkü ajanın son mesajı size işlerin nerede ters gittiğini mutlaka söylemez.

Sorunu araştırmak için yürütme sırasında ne olduğunun izini sürün ve sonuçları bağımsız olarak doğrulayın. O halde sorunu yalıtmaya ve çözmeye biraz zaman ayıralım.

Bir ajanın istemlerinde hata ayıklamadan önce tüm yürütme yolunu kaydedin. Aynı iş akışı çalıştırması altında ajan çağrılarını, araç çağrılarını, hataları ve yeniden denemeleri birbirine bağlayan bir izlemeye (trace) ihtiyacınız var.

OpenTelemetry’nin GenAI semantik kuralları, bu işlemleri tanımlamak için standart bir yol sunar. Örneğin invoke_workflow iş akışı yürütmesini, invoke_agent bir ajan çağrısını, execute_tool ise bir araç çağrısını tanımlar. Her işlem; zamanlaması, durumu ve ilgili meta verileriyle birlikte bir span olarak kaydedilebilir.

Bu adım size yürütme yolunun bir izini sunar; böylece bir ajanın nerede takıldığını belirleyebilirsiniz.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

Açıklama amaçlı bir yürütme izi.

Mümkün olan her yerde programatik kontroller kullanın. Çıktıları JSON şemalarına göre doğrulayın, birim ve entegrasyon testleri çalıştırın, gerekli yapıtların var olduğunu kontrol edin ve eylemlerin gerçekten başarılı olduğunu doğrulamak için harici sistemleri sorgulayın.

Öznel değerlendirme gerektiren ve bu nedenle programatik kontrollerle değerlendirilemeyen çıktılar için bağımsız bir inceleyici ajan kullanın. Yaklaşımlardan biri uygulayıcı–inceleyici–çözümleyici döngüsü kullanmaktır: Bu döngüde bir ajan bir yapıt üretir, temiz bir bağlamla çalışan bir inceleyici sorunları belirler ve doğrulama yeniden çalıştırılmadan önce bir çözümleyici bu sorunları giderir.

Yine de mümkün olduğunda inceleyicinin bulgularını doğrulamanız gerekir; tekrarlanan değerlendirmeler için LLM tabanlı puanlayıcılar kullanıyorsanız, bunların yargılarını insanlar tarafından incelenmiş örneklere göre kalibre edin.

Şu ana kadar ajanların neleri yürüttüğünü izlediniz ve çıktılarının doğru olup olmadığını kontrol ettiniz. Peki bir worker bir görevin ortasında çöktüğünde veya bir API bir isteği kabul ettikten sonra zaman aşımına uğradığında ne olur? Şaşırtıcı bir şekilde, iş akışınız normal koşullarda kusursuz çalışırken kurtarma sırasında başarısız olabilir.

Bunu test etmek için bir test ortamında kasıtlı olarak hatalar enjekte edin:

API zaman aşımlarını simüle edin
Harici yazma işlemleri ile kontrol noktaları arasında worker'ları çökertin
Hatalı biçimlendirilmiş araç çıktıları döndürün
Onayların süresini doldurun

Her testten sonra hangi adımların çalıştığını, iş akışının nereden devam ettiğini ve herhangi bir eylemin tekrarlanıp tekrarlanmadığını veya atlanıp atlanmadığını görmek için yürütme izini inceleyin. Ardından gerçek sonuçları gözden geçirin.

Diyelim ki CI ajanınız bir test çalıştırması başlatmak için istek gönderiyor, ancak API yanıtı zaman aşımına uğruyor. Ajan yeniden deniyor, başarılı bir yanıt alıyor ve Başarılı sonucunu bildiriyor. CI hizmetini kontrol edip bir yerine iki test çalıştırması oluşturulduğunu fark edene kadar her şey yolunda görünür.

Bu nedenle hem iş akışının kaydedilen durumunu hem de harici sistemlerdeki gerçek değişiklikleri doğrulamalısınız. Bir kurtarma testi, yalnızca iş akışı istenmeyen yan etkiler olmadan beklenen duruma ulaştığında başarılı sayılmalıdır.

Gelecekteki değişikliklerin bunları yeniden ortaya çıkarmaması için keşfettiğiniz hataları regresyon testlerinize ekleyin.

Sonuç olarak başarı, iş akışının gerekli kontrollerden geçtiği ve harici sonuçlarının doğrulandığı anlamına gelir.

Silo halinde çalışan ajanlar bireysel görevlerini doğru şekilde tamamlayabilir ancak birlikte tutarsız sonuçlar üretebilir. Saat 10.00'da müşteri koşullarını alan bir satış ajanı, saat 10.05'te güncellenmiş fiyatları kullanarak teklif hesaplayan bir fiyatlandırma ajanı ve saat 10.07'de değişen bir sözleşmeyi kontrol eden bir hukuk ajanı düşünün. Her ajan işletmenin farklı bir anlık görüntüsüyle çalışır; bu nedenle çıktıları birbiriyle çelişebilir.

Sorun kurumsal ölçekte daha da belirgin hale gelir, çünkü ajanlar birbirinden bağımsız olarak güncellenen birden çok sistemle etkileşime girer, farklı izinlerle çalışır ve bağlamı veya yürütme durumunu her zaman paylaşmaz.

Sınırları birden çok düzeyde belirleyin: maksimum araç çağrısı yeniden deneme sayısı, maksimum ajan yinelemesi, yetki devri derinliği ve genel bir iş akışı son tarihi. Yeniden denemeden önce hataları sınıflandırın. Geçici 429 yanıtlarında, sağlandığında Retry-After değerine uyun. Aksi takdirde, jitter içeren sınırlı üstel geri çekilme kullanın.

Doğrulama veya izin hatalarından sonra değiştirilmemiş istekleri yeniden denemeyi bırakın. Bir alt akış hizmeti tekrar tekrar başarısız olursa, devre kesici ajanların ek yük oluşturmasını önleyebilir.

Kurtarma mekanizması çalışma zamanınıza bağlıdır. LangGraph'ta PostgresSaver gibi kalıcı bir checkpointer, grafik durumunu bir thread_id altında depolayarak yürütmenin kalıcı durumdan devam etmesini sağlar. Temporal'da ise başka bir worker, olay geçmişini yeniden oynatarak bir iş akışını yeniden oluşturabilir. Yeniden oynatma sırasında daha önce kaydedilen aktivite sonuçlarını yeniden kullanır.

İş akışları hâlâ çalışırken uygulama yeniden dağıtılırsa, kaydedilen durum ve yürütme geçmişleri artık uyumlu olmayabilir. Temporal bu sorunu Worker Versioning ve iş akışı yamalama (workflow patching) ile ele alır. Kontrol noktası tabanlı sistemlerde, uyumsuz değişiklikleri kullanıma sunmadan önce şema geçişlerini planlayın ve kurtarmayı mevcut kayıtlı durumlar üzerinde test edin.

Aynı temsili görevleri birden çok kez çalıştırın ve pass@k (k denemeden en az birinin başarılı olup olmadığı) ile pass^k (k denemenin tamamının başarılı olup olmadığı) arasındaki farkı gözetin

Tek bir toplu başarı oranına güvenmek yerine sonuçları görev kategorisine ve iş akışı sürümüne göre ölçün. İlk denemedeki başarıyı, tekrarlanan çalıştırmalar arasındaki tutarlılığı, p95 gecikmesini, tamamlanan görev başına maliyeti ve insan müdahalesi gerektiren oranı takip edin. Başarı oranları için örneklem büyüklüklerini ve belirsizlik aralıklarını raporlayın.

Yapay zeka ajanı orkestrasyonu nedir?

Yapay zeka ajanı orkestrasyonu nasıl çalışır: Yürütme motorunun içi

Yapay zeka ajanı orkestrasyonunu ne zaman kullanmalısınız?

Yapay zeka ajanı orkestrasyon mimarileri ve ödünleşimleri

Merkezi orkestrasyon

Merkeziyetsiz orkestrasyon

Hiyerarşik orkestrasyon

Sıralı, paralel ve devir tabanlı yürütme

Yaygın yapay zeka ajanı orkestrasyonu hataları

Üretimde güvenilirlik için 7 yapay zeka ajanı orkestrasyonu en iyi uygulaması

1. Açıkça tanımlanmış görev sözleşmeleri, kabul kriterleri ve durma koşulları belirleyin

2. Orkestratörleri yalın tutun ve yapılandırılmış devirleri zorunlu kılın

3. İş akışı durumunu kalıcı hale getirin ve bağlam büyümesini kontrol altında tutun

4. Hatalara duyarlı yeniden denemeler ve kurtarılabilir araç yürütmesi tasarlayın

5. Net kaynak bütçeleriyle işi yönlendirin ve paralelleştirin

6. Onayları zorunlu kılın ve ajan yürütmesini yalıtın

7. Çıktıları bağımsız olarak doğrulayın ve kurtarma davranışını test edin

İş akışının izini sürerek neyin ters gittiğini belirleyin

Çıktıyı bağımsız olarak inceleyin

Kurtarma davranışını test etmek için hata enjekte edin

Yapay zeka ajanı orkestrasyonu hakkında SSS

Silo halinde çalışan yapay zeka ajanları kurumsal ölçekte neden başarısız olur?

Yapay zeka ajanlarında sonsuz yeniden deneme döngülerini nasıl önlersiniz?

Bir yapay zeka ajanı iş akışını çökmeden sonra nasıl sürdürürsünüz?

Yapay zeka ajanı orkestrasyonunun güvenilirliğini nasıl test edersiniz?