Agent görevi devraldıktan sonra ilk sıkılaştırılması gereken şey çalışma birimidir.

Son zamanlarda Agent ile ilgili çok fazla tartışma okuyorum ve sonunda hep aynı soruya dönüyorum: Bir eseri kime vermeli, teslim etmeden önce nasıl paketlenmeli, iade edildikten sonra nasıl kabul edilecek? Bir projede bu sorun ortaya çıktığında artan ilk şey genellikle modelin maliyeti değil, iş biriminin karmaşıklığıdır. Görev çok büyük kesilirse model “sanki yapılabilirmiş gibi” görünecektir; asıl sorunlar genellikle geri alma, çoğaltma ve kabul etmede yatmaktadır.

Öncelikle iş biriminin kabul edilebilmesi gerekir

Geçtiğimiz birkaç gün içinde, Martin Fowler’ın parçalanmış notlarını ve Thinkworks Future of Software Development Retreat’teki çeşitli tartışmaları bir araya getirdikten sonra, en bariz duygu, toplantıdaki konuşmanın yüzeysel olarak dağınık olduğu, ancak aslında tek bir şeyin etrafında döndüğüydü: büyük bir işin Ajan’a teslim edilmesi.

Kief Morris’in bitiriciliği en basit olanıdır. Farklı oturumlarda kod incelemesi, üretim kazaları, ekip iş bölümü ve model yönlendirme tartışıldı. Farklı şeylerden bahsediyor gibi görünüyorlardı ama sonuç aynıydı: İnsanlar “birim işin” boyutunu ayarlıyordu. Birim ne kadar büyük olursa, teslim edilmesi de o kadar kolay olacaktır; Birim ne kadar büyükse, geri döndükten sonra onu kabul etmek o kadar zor olacaktır. Modelin bunu yapamaması değil, sonraki onay bağlantısının ilk önce dayanamamasıdır.

Bu nedenle koşumdan tekrar tekrar bahsediliyor. Bağlam yönetimi, hesaplamalı sensörler, özellik tabanlı testler, resmi yöntemler, bunlar ek araçlar gibi görünse de aslında çalışma birimlerini toplarlar. Bazı insanlar agents.md’i 200 satırdan daha azına kadar kontrol ederler; bu, biçimsel bir düzen sağlamak için değil, sistemi bilginin yalnızca gerçekten yararlı ve gerçekten kontrol edilebilecek kısmını almaya zorlamak için yapılır. Bağlam çok gevşek, elbette Temsilci çalışabilir; ancak koştuktan sonra kimse hangi kısıtlama katmanını yuttuğunu bilmiyor.

Kendi kendine barındırma, kontrol yüzeyini yükseltir

Kendi kendine barındırılan modellere ilişkin tartışmalar da aynı şeye işaret ediyor. Tokenlar pahalılaştıkça, uyumluluk gereklilikleri katılaştıkça ve veriler dışarı sızdırılamaz hale geldikçe açık kaynaklı modeller ve yerel modeller doğal olarak daha çekici hale gelecektir. Ancak modeli kendiniz taşıdığınızda sıkıntılarınız da olur: GPU, çıkarım odası, yönlendirme, geri alma, ince ayar ve model seçimi. Bunlar model yetenekleri değildir ancak sistemin nihai olarak kararlı olup olmadığını belirleyeceklerdir.

Bu tür maliyetler genellikle hafife alınır. Birçok ekip başlangıçta “modelin daha güçlü olup olmadığına” odaklandı, ancak daha sonra asıl zaman harcayan şeyin iş birimlerinin birden fazla model arasında istikrarlı bir şekilde aktarılması olduğunu keşfetti. Ne zaman büyük bir model kullanılacağı, ne zaman hafif bir model kullanılacağı ve ne zaman basitçe yerel bir model kullanılacağı, sözel tercihe değil, saptırma ve örtbas etme için kullanılabilecek bir kontrol yüzeyi katmanına bağlıdır. Bu katmanlar olmadan, kendi kendine barındırma, “inisiyatif almaktan” “işletme ve bakım karmaşıklığını kendiniz üstlenmeye” doğru kayacaktır.

Simon Willison, işi yapmak için daha güçlü modellerin daha küçük modelleri seçmesine izin verilmesinden bahsetti. Bu fikir aynı zamanda kontrol düzleminin yaptığına da çok benzer. Modelin kendisi ekibin maliyet sınırlarını mutlaka bilmeyebilir ancak sistem bilir. Modeli bir komisyoncu olarak ele almak ve onu görevleri dağıtmak için kullanmak, her şey dahil teslimat için körü körüne tek bir modeli takip etmekten daha gerçek teslimata daha yakındır.

Kabul ve hedefler dışarıdan temin edilemez

Sam Ruby’nin “Bana Bir Taş Getir” şarkısı bir konuyu daha gün ışığına çıkardı. Çalışmayı modele vermek, bir uygulayıcı eklemekle eşdeğerdir; sorumluluk ortadan kalkmaz. Yöneticiler Yüksek Lisans’ı keşif için kullanabilir ve önce bir dizi aday çözümün ortaya çıkmasına izin verebilirler, ancak nihai kabul kriterlerinin yine de insanların eline geçmesi gerekir. Gizli hedefler en zahmetli olanlardır. İzinler, gizlilik, yıkıcı eylemler ve içerik sızıntısı çoğu zaman orijinal gereksinimlere dahil edilmez.

Dolayısıyla uygunluk testleri çoğu zaman spesifikasyonlardan daha faydalıdır. Spesifikasyonlar “neyin gerekli olduğunu” açıklama konusunda iyidir ve testler “neyin olamayacağını” ortaya çıkarmada daha iyidir. Bu özellikle Agent sistemlerinde geçerlidir. Model, açık hedefleri çok iyi bir şekilde telafi edebilir ancak örtülü sınırların daha sıkı doğrulama yoluyla doğrulanması gerekir. Kabul koşulları belirsiz açıklamalarda kaldığı sürece, Acente ne kadar çok yaparsa, sistem o kadar çok olasılığa bahis oynuyormuş gibi görünecektir.

Bu nedenle, eskiden insana çok benzeyen görevler olan kod incelemesi, olay yönetimi ve görev atama artık başka biçimler almaya başlıyor. Yöneticiler modeli doğrudan kullanırlar. Görünüşte verimliliği artırıyor gibi görünüyor, ancak alt düzeyde aslında bir yönetim yöntemini değiştiriyorlar: yönetim yöntemlerinden hedefleri yönetmeye doğru. Hedef açıkça yazılırsa modelin çalışma şansı olur; hedef belirsizse model yalnızca başkaları için belirsizliği artıracaktır.

Deneyim ve okuma becerileri hâlâ gelişiyor

Dan Davies’in bahsettiği etkileşimsel uzmanlık ve katkıda bulunan uzmanlık da bu değişimle oldukça alakalı. Model birçok materyali okuyabilir ve doğru bir karara varabilir, ancak sistemin kararlı olması için yine de teknik özellikleri okuyabilen, sonuçları görebilen ve neyin yanlış olduğunu bilen birinin olması gerekir. Burada önemli olan insanların kimin daha akıllı olduğunu görmek için modelle rekabet etmesi değil, insanların sınırları belirleyen bir konumda durmaya devam etmeleridir.

Yazılım teslimatı söz konusu olduğunda bu konu daha basittir. Agent görevi devraldıktan sonra, insan işi manuel yürütmeye daha az, görev bölümlendirme, sınır tanımlama, kabul tasarımı ve istisna işlemeye daha fazla düşecek. Görevlerin devredilip devredilemeyeceği, daha sonraki bağlam yönetimi, model yönlendirme ve araç orkestrasyonunun yapılmaya değer olup olmadığını açıkça belirler. Eğer ünite net değilse, kaç katman olursa olsun, bu sadece sorunu geriye itecektir.

Geçtiğimiz birkaç gün içinde bu parçaları okuduktan sonra aklımda kalan şey belirli bir model adı ya da yeni bir çerçeve değil, daha basit bir yargı: Agent sisteminin sıkılaştırması gereken ilk şey model yeteneği değil, iş birimidir. Birim daha küçükse, kabul daha katı ve izinler daha sıkıysa sistem karmaşıklığı kontrol edilebilir bir aralıkta tutma fırsatına sahip olacaktır.