Orijinal Başlık: Orkestrasyon Vergisi

Orijinal Yazar: Addy Osmani

Çeviri: Peggy

Editörün Notu: AI Ajanları giderek daha ucuz ve daha kolay çağrılabilir hale geldikçe, yazılım geliştirme yeni bir aşamaya giriyor: Sorun artık daha fazla Ajan başlatıp başlatamayacağımız değil, insanların çıktılarını yönetmek, değerlendirmek ve birleştirmek için yeterli dikkate sahip olup olmadığıdır.

Bu makale oldukça ilham verici bir kavram ortaya koyuyor: "Orkestrasyon Vergisi". Bir Ajan başlatmanın maliyeti düşüktür, sadece bir Prompt veya tek bir tıklama yeterlidir; ancak asıl pahalı olan sonraki aşamalardır: sonuçların doğru olup olmadığını kontrol etmek, sistem mimarisi üzerindeki etkisini anlamak, farklı Ajanlar arasındaki çatışmaları ele almak ve sonuçta hangi kodun ana dala gireceğine karar vermek. Bu işler kolayca paralelleştirilemez ve hala tek bir seri kaynağa geri döner: insan muhakemesi.

Yazar, geliştiricileri AI Ajan sistemindeki "GIL"e benzetiyor, yani eşzamanlı sistemin nihai verimini sınırlayan tek iş parçacıklı kilit. Birden fazla Ajan aynı anda çalışabilir, ancak mimari değerlendirme, kod incelemesi ve çatışma birleştirme aşamasına gelindiğinde, mutlaka geliştiricinin beyninden geçmek zorundadır. Sonuç olarak, daha fazla Ajan her zaman daha yüksek çıktı anlamına gelmez; sadece incelenecek görev kuyruğunu uzatabilir ve geliştiriciyi daha sık bağlam değişikliği ve bilişsel yorgunluğa sürükleyebilir.

Bu, mevcut AI programlama araçları çılgınlığında kolayca gözden kaçan bir noktadır: Verimlilik hissi ile gerçek üretkenlik her zaman aynı şey değildir. Ajanlarla dolu bir gösterge paneli, "yüksek üretkenlik" yanılsaması yaratabilir; ancak geliştirici bu değişiklikleri gerçekten anlamaz, incelemez ve entegre etmezse, sistem sonunda biriken şey üretkenlik değil, teknik borç ve bilişsel borç olabilir.

Bu nedenle, bu makalenin gerçekte tartıştığı şey "daha fazla Ajan nasıl kullanılır" değil, "insan dikkati etrafında iş akışı nasıl yeniden tasarlanır"dır. Ajan çağında, kilit yetenek sadece soru sormak ve görev dağıtmak değil, hangi görevlerin makineye paralel olarak verilebileceğini ve hangi görevlerin insan muhakemesine bırakılması gerektiğini bilmektir; ne zaman toplu inceleme yapılacağını ve ne zaman orkestrasyonu durdurup tek bir temel soruna odaklanılacağını bilmektir.

AI, yazılım üretiminin eşzamanlılık kapasitesini genişletiyor, ancak insan dikkati hala sistemdeki en kıt ve en kopyalanamaz kaynaktır. Gerçekten olgun bir Ajan iş akışı, tüm görevleri makineye atmak değil, bir üretim sistemi tasarlar gibi kendi dikkat mimarisini dikkatlice tasarlamaktır.

Artık daha fazla AI Ajanı başlatmak çok kolay hale geldi. Ancak daha fazla Ajan'ın aynı anda çalışması, "senin" de çoğaldığın anlamına gelmez. Bilişsel bant genişliğin paralelleştirilemez. Onları yönlendirmek, sonuçları değerlendirmek ve değişiklikleri birleştirmek için kullanılan tüm muhakeme yeteneğin, nihayetinde aynı seri işlemciden geçmek zorundadır: yani kendinden.

Sözde "orkestrasyon vergisi", özünde bunu unuttuğunda ödediğin bedeldir. Ve tek gerçek çözüm, herhangi bir eşzamanlı sistemi tasarlar gibi, kendi dikkatini tasarlamaya başlamaktır.

Geçenlerde Google I/O'da Richard Seroter, Aja Hammerly ve Ciera Jaspan ile yazılım mühendisliğinin şu anki hali ve bundan sonra nasıl evrilebileceği üzerine bir panel tartışmasına katıldım. Sona yaklaşırken Richard bize sordu: Geliştiriciler bunu dinledikten sonra yanlarında götürüp değiştirmeleri gereken en önemli şey ne?

Aylardır üzerinde düşündüğüm bir noktayı söyledim: Kendini meşgul hissetmek, kesinlikle üretken olmak anlamına gelmez. Aynı anda 20 Ajan çalıştırabilir ve kendini inanılmaz meşgul hissedebilirsin. Ancak bu, 20 Ajan'ın karşılığı olan iş miktarını teslim ettiğin anlamına gelmez.

Konuşmanın başlarında Richard bu soruna bir isim vermişti. Dedi ki: "Az önce bahsettiğin şey aslında orkestrasyon vergisi. Kendi kafanın içinde 20 Ajan'ı başarıyla yönetemezsin."

Tamamen haklıydı. Bu kavramı daha ayrıntılı olarak açmak istiyorum çünkü bu bir öz disiplin sorunu değil, bir mimari sorunudur.

O panelde neredeyse ağzımdan kaçan ve sonra aklımdan çıkmayan bir cümle vardı: Birden fazla Ajan çalıştırmak, dünyada bir tane daha sen olduğu anlamına gelmez.

İnsanların Hesaba Katmadığı Asimetri

Ajan iş akışlarında gizli bir asimetri vardır.

Bir Ajan'ı başlatmak çok ucuzdur. Sadece bir tuşa basman veya bir Prompt yazman yeterlidir. Ancak Ajan'ın döngüsünü tamamlamak hiç de ucuz değildir. Birinin, döndürdüğü sonuçların doğru olup olmadığını kontrol etmesi ve bunları diğer Ajanların değiştirdiği içeriklerle yeniden koordine etmesi gerekir.

Bu kişi sensin. Ve sadece bir tane varsın.

Geçen ay, "Paralel Ajan Sınırın" başlıklı yazımda bu sorunun bir kısmını ele almıştım, özellikle de şu çevresel kaygıyı: Hangi paralel iş parçacığının sessizce başarısız olduğunu bilemezsin. Bu yazı ise bu maliyetin arkasındaki yapıdan bahsetmek istiyor.

Ajan geliştirmeyi eşzamanlı bir sistem olarak görmeye başladığınızda, insanın kendisinin de bu sistemin yalnızca bir bileşeni olduğunu fark edersiniz. Çok yavaş, seri bir bileşen.

Siz o tek iş parçacıklı kaynaksınız

Daha önce eşzamanlı kod yazdıysanız, bu sorunu anlamak için gereken sezgiye zaten sahipsinizdir. Sadece bu sezgiyi daha önce yanlış yerde kullanıyordunuz.

Python'da Global Interpreter Lock (GIL) bulunur. İstediğiniz kadar iş parçacığı oluşturabilirsiniz, ancak aynı anda yalnızca bir iş parçacığı Python bayt kodunu çalıştırabilir çünkü hepsinin önce bu kilidi alması gerekir.

Siz, AI Ajanınızın GIL'isiniz.

Hepsi aynı anda çalışabilir. Ancak işleri, sistem mimarisini gerçekten anlamayı veya birleştirme çakışmalarını çözmeyi gerektirdiğinde, önce bu kilidi almaları gerekir. Ve bu kilitten yalnızca bir tane var ve o da sizde.

Amdahl Yasası bunu çok kesin bir şekilde ifade eder: Paralelleştirmeden elde edilecek hızlanma, işin hâlâ seri olarak yapılması gereken kısmına bağlıdır. Sürecinizin büyük bir kısmı paralelleştirilemiyorsa, ne kadar çok çekirdek eklerseniz ekleyin, sonunda sert bir üst sınıra çarparsınız.

Ajan geliştirmede, bu seri kısım muhakeme yeteneğidir.

8 Ajan başlatmak, muhakeme sürenizi hızlandırmaz. Sadece sizin ilgilenmenizi bekleyen kuyruğu uzatır.

Bu, performans mühendisliğinde çok eski bir gerçektir, ancak yine de birçok kişiyi şaşırtır: Darboğaz olmayan bir kısmı optimize etmek, genel verimi artırmaz. Sadece darboğazın önünde henüz tamamlanmamış daha fazla iş biriktirirsiniz.

Ajan eklemek, zaten kısıt olmayan kısmı optimize eder. Gerçek kısıt, inceleme aşamasıdır ve tüm sistemin verimi, tam olarak bu aşamanın verimine eşittir.

Orkestrasyon vergisi, Ajanların üretim kapasitesi ile sizin fiilen birleştirebildiğiniz şey arasındaki yapısal boşluktur. Bu, tek iş parçacıklı bir kaynağı eşzamanlı bir sistemi yönetmekle görevlendirdiğinizde ortaya çıkar.

Zorlamak yapısal sınırı aşmaz

O yuvarlak masa toplantısında bir şey söyledim: Araçlarımın hiç bu kadar verimli olduğunu hissetmemiştim, ama aynı zamanda hiç bu kadar yorgun da olmamıştım.

Bu iki duygu da tamamen gerçek ve aynı nedenden kaynaklanıyor.

Bu yorgunluğun çok spesifik bir kaynağı var: Seri bir işlemciyi sürekli olarak %100'de çalıştırmanın ve hiçbir pay bırakmamanın hissi tam olarak bu.

Dikkatinizden çıkmış bir Agent'a geri dönüp baktığınız her seferde, bir bağlam değiştirme maliyeti ödersiniz. Zihninizi boşaltmanız ve sıfırdan başka bir bağlamı yeniden yüklemeniz gerekir.

CPU bunu mikrosaniyeler içinde yapabilir, ancak yine de mimarlar sık sık geçiş yapmaktan kaçınır. Sizse bunu yapmak için dakikalar harcarsınız ve bağlamı asla mükemmel bir şekilde geri getiremezsiniz.

5 Agent, 1 birimlik iş yükünün 5 kez tekrarlanması değildir. Bu, 5 kez soğuk başlatma tarzında bağlam yeniden yüklemesi ve arka planda sürekli çalışan, şu anda hangi Agent'ı kontrol etmeniz gerektiğini sorgulayan bir beyin sürecidir.

Yapısal bir sınırlamayı "daha çok çabalayarak" çözemezsiniz. Bu vergi her zaman ödenecektir.

Zorlamaya çalışırsanız, eninde sonunda başka bir şekilde ortaya çıkar: ya kod incelemeleri giderek yüzeyselleşir ya da "bilişsel teslimiyet" durumuna girersiniz—kendi yargınızı oluşturmak çok fazla dikkat gerektirdiğinden, Agent'ın yazdığı kodu olduğu gibi kabul edersiniz.

Ya bu vergiyi aktif olarak ödersiniz ya da sisteminize dair anlayışınızı karanlıkta yavaşça yok etmesine izin verirsiniz.

Dikkatinizi Bir Sistem Tasarımı Gibi Tasarlayın

Bu nedenle, dikkatinizi kıt ve seri bir kaynak olarak ele almalısınız.

Dağıtık bir sistem tasarlarken darboğazları tamamen göz ardı etmezsiniz. O halde, beyninize de aynı saygıyı gösterin.

İşte benim için gerçekten işe yarayan bazı yöntemler:

Agent ekibinizi UI kapasitesine göre değil, inceleme kapasitenize göre genişletin.

İyi bir eşzamanlı sistem, kuyrukların sınırsızca büyümesini önlemek için geri basınç mekanizması kullanır. Üretici, tüketicinin işleme kapasitesine uyum sağlamak için yavaşlar.

Sizin Agent sayınız üreticidir, inceleme kapasiteniz ise tüketicidir. Doğru paralel Agent sayısı, ciddi bir şekilde kod incelemesi yapabileceğiniz sayıdır. Çoğu insan için bu, genellikle düşük tek haneli bir rakamdır.

AI araçları sizi 20 Agent başlatmaya teşvik eder, ancak bu sadece bir UI özelliğidir; onları gerçekten yönetebileceğiniz anlamına gelmez.

Görevleri kategorize edin.

Richard bana bununla nasıl başa çıktığımı sorduğunda bu yöntemden bahsetmiştim. Görevleri iki gruba ayırırım.

İlk yığın, nispeten bağımsız işlerdir ve bunları bulutta arka planda çalışan Agent'lara emanet etmek isterim. Bu görevler asenkron olarak yürütülebilir ve genellikle yalnızca son aşamada bir kez kontrol etmem gerekir.

İkinci yığın ise karmaşık görevlerdir; asıl işin kendisi karar vermektir. Örneğin, garip bir hata veya bir mimari tasarım gibi.

En büyük hata, ikinci tür görevleri de paralelleştirmeye çalışmaktır. Birden fazla karmaşık görevi aynı anda işlemek, üretkenliğinizi artırmaz; aksine, o kilidin sürekli olarak kapışılmasına neden olur ve sonuçta tüm çıktılar daha kötü hale gelir.

Toplu inceleme.

Her bağlam değişikliği size yüksek bir maliyet çıkarır. Bir kerede oturup 4 Agent'ın sonucunu incelemek, önce birine bakıp başka bir iş yapıp sonra soğuk başlangıçla diğerine dönmekten çok daha ucuzdur.

Agent'lara daha uzun bir ip verin. İşin biraz birikmesine izin verin ve ardından bunları bir parti olarak ele alın.

Bu kilidi yalnızca karar verme anlarında kullanın.

Beyninizi, makinelerin kendi başına doğrulayabileceği şeyler için harcamayın. Agent'ların geçebilecek testler yazmasını veya ekran görüntüleri oluşturmasını sağlayın.

Sıkıcı ama doğrulanabilir olan %80'lik kısmı kendilerinin kanıtlamasına izin verin. Böylece, kıt olan dikkatinizi yalnızca gerçekten insan yargısı gerektiren %20'lik kısma harcayabilirsiniz.

Seri zamanınızı koruyun.

Darboğaz, en iyi zamanınızı gerektirir; Agent kontrolleri arasında kalan parça zamanları değil.

Bazen en yüksek kaldıraçlı hareket, tamamen düzenlemeyi durdurmaktır: Agent'larla dolu bilgisayarı kapatın, yalnızca tek bir soruna odaklanın ve tüm süreç boyunca o kilidi sıkıca tutun.

Düzenleme, asıl iş değildir. Sadece işin etrafında oluşan bir ek yüktür.

Aja, mimari yeteneğin artık en acil beceri haline geldiğini belirtiyor: Hangi görevin bir Agent'a uygun olduğunu ve hangi görevin onun için çok büyük olduğunu bilmeniz gerekiyor.

Ben de şunu eklemek isterim: Siz de bu sistemin bir bileşenisiniz. Dikkatinizin bilinen, çok düşük bir seri işleme kapasitesi vardır. Sistem ya bu sayıya saygı duyar ya da standartlarınızı sessizce düşürerek onu aşmaya çalışır.

Meşgul olmak, üretken olmak demek değildir

Bu çok önemlidir, çünkü bu başarısızlık modu sizin için neredeyse görünmezdir.

20 tane çalışan Agent size "üretkenlik patlaması" hissi verir. Gösterge paneli tıklım tıklım, her şey hareket halinde. Ancak bu his, yüksek kaliteli kodun ana dala birleştirilmesiyle arasındaki bağlantıyı çoktan kaybetmiştir.

Maksimum düzeyde meşgul olabilirsiniz, ancak neredeyse hiç gerçek çıktı üretmezsiniz. İçsel deneyim açısından, bu ikisi neredeyse aynıdır.

Ciera, Margaret-Anne Storey'in borç üzerine yaptığı araştırmadan bahsetti. Teknik borçtan ve bilişsel borçtan söz ettik.

Ödenmemiş orkestrasyon vergisi, bu iki borcu aynı anda biriktirmenize neden olur.

Dikkatlice okumadığınız şeyleri birleştirirsiniz. Kod tabanına dair zihinsel modeliniz tamamen güncelliğini yitirir. Bu sorunlar bugün gösterge panelinde görünmez. Üretim ortamında bir arıza olduğunda ortaya çıkarlar—sisteme bakarsınız ve bir anda nasıl çalıştığını artık bilmediğinizi fark edersiniz.

Yani asıl sonuç şu: Agent başlatmak bir yetenek değildir. Herkes 20 tane çalıştırabilir.

Gerçek yetenek, klonlanamayan ve paralelleştirilemeyen seri kaynağın etrafında bir sistem tasarlamaktır.

Bu kaynak, sizin dikkatinizdir.

Onu, üretim ortamında bağımlı olunan herhangi bir kritik bileşeni tasarlar gibi tasarlayın.

[Orijinal bağlantı]

BlockBeats Resmi Topluluğuna Katılın:

Telegram Abonelik Grubu: https://t.me/theblockbeats

Telegram Sohbet Grubu: https://t.me/BlockBeats_App

Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia