Bu kılavuzu, Uygulamalı Yapay Zeka Mühendisliği'ne geçiş yapmadan önce benim sahip olmayı çok istediğim bir rehber olarak yazdım.
Bu rol, geleneksel yazılım mühendisliğiyle büyük ölçüde örtüşür, ancak çoğu yazılım mühendisinin geçiş yaparken öğrenmesi gereken birkaç önemli kavramı da ekler. Bunu, anlamanız gereken temel konuların bir taslağı olarak kullanmanızı ve daha derine inmek istediğinizde makale boyunca bağlantılı kaynakları takip etmenizi öneririm.
Sonunda, Uygulamalı Yapay Zeka Mühendisliği'nin ne olduğu, işin gerçekte ne gerektirdiği ve geleneksel yazılım mühendisliğinin ötesine nasıl geçtiği konusunda çok daha net bir anlayışa sahip olmalısınız.
Uygulamalı Yapay Zeka alanındaki en ilginç problemlerden bazıları üzerinde çok yetenekli bir mühendislik ekibiyle çalışmak istiyorsanız, her zaman işe alım yapıyoruz. varickagents.com adresindeki web sitemizden başvurabilir veya bir adayı yönlendirerek 20.000$ referans bonusu kazanabilirsiniz.
Bununla birlikte, Uygulamalı Yapay Zeka Mühendisliği'ni anlamanın en iyi yolu, yazılım oluşturma şeklinizdeki zihniyet değişimini kavramaktan geçer.
Yazılım mühendisliği ve yapay zeka mühendisliği
Bir SWE ile bir yapay zeka mühendisi arasındaki en büyük fark, geleneksel yazılım mühendisliğinin sizi deterministik düşünmeye yönlendirmesi, uygulamalı yapay zekanın ise sizi olasılıksal düşünmeye zorlamasıdır.
Normal yazılımda, mantığı yazar, çalıştırır ve bir şey bozulduğunda genellikle onu izleyebilirsiniz – yapılandırılmış bir girdi, deterministik olarak size yapılandırılmış bir çıktı verir.
Uygulamalı yapay zeka böyle çalışmaz. Zekaya yapılan deterministik olmayan bir API çağrısı etrafında inşa edersiniz, bu da aynı girdinin her seferinde farklı gelebileceği anlamına gelir. Bu nedenle, iş sadece yazılımı oluşturmak olmaktan çıkar ve bunun yerine sistemin gerçekten olması gerektiği gibi davranıp davranmadığını ölçmeye dönüşür.
Bunu yapma şeklimiz değerlendirmelerdir (evals), bu yüzden geliştirdiğiniz ajanın hata yapmadığından emin olmak için nasıl bir değerlendirme paketi oluşturacağınızı anlatacağım. Yaptığımız işin deterministik olmayan doğası göz önüne alındığında, bunun uygulamalı bir yapay zeka geliştiricisinin en önemli becerilerinden biri olduğunu öğrendim.
Makalenin bir sonraki kısmı, bir yapay zeka ajanının her bir parçasının (tabii ki modelin kendisi hariç) geliştirilmesini kapsar, çünkü bir modele API çağrısı yapabilirsiniz ancak diğer her şeyi kendiniz inşa etmeniz gerekir. Buna donanım mühendisliği (harness engineering) denir.
Ve son olarak, üretimdeki bir ajandan birden fazla ajana nasıl geçileceğini ve bunun neden bir dağıtık sistemler problemi olduğunu ele alacağım. Bu makalenin sonuna kadar gelebilirseniz, Uygulamalı Yapay Zeka mühendisi olma geçişini yapamamanız için hiçbir neden yok.
Değerlendirmeler (Evals)
Uygulamalı bir yapay zeka mühendisi, değerlendirmeler kullanarak belirsizliği ölçülebilir güvene dönüştürür. Geleneksel yazılım geliştirmede, mantığı siz yazdığınız ve kodu test ettiğiniz için sisteme güvenirsiniz. Uygulamalı yapay zekada, modele bu şekilde güvenemezsiniz çünkü model çalıştırmalar arasında farklı davranabilir. Bu nedenle yapay zeka mühendisi, ajanın etrafında bir ölçüm katmanı oluşturmalıdır.
Bir değerlendirme, bir ajana bir görev verme, çalışmasına izin verme ve yaptıklarını derecelendirme sürecidir. Amaç iki şeyi kanıtlamaktır: ajanın işi doğru bir şekilde tamamlaması ve ajanın kendisine verilen sınırlar içinde kalması.
İlk adım sonucu derecelendirmektir. Bu, değerlendirme sürecinin en kolay adımıdır. Genellikle üzerinde çalıştığım fatura ajanı için bu, faturanın doğru yere düşmesini veya kopyanın işaretlenmesini sağlamak anlamına gelir. Sadece nihai sonucu olması gerekene karşı karşılaştırırsınız.
İkinci adım yörüngeyi (trajectory) derecelendirmektir. Bu, ajanın bu sonuca ulaşmak için izlediği yoldur: çağırdığı araçlar, dokunduğu alanlar, ilettiği argümanlar ve yol boyunca denediği eylemler. Bu önemlidir çünkü bir ajan doğru nihai cevaba ulaşırken aynı zamanda süreçte tehlikeli bir şey yapabilir. Bir faturayı doğru sınıflandırırken aynı zamanda banka bilgilerini değiştirebilir veya onaydan önce bir ödeme gönderebilir.
Yörüngenin kendisi sadece bir günlüktür (log): ajanın çağırdığı her aracın ve ilettiği argümanların sıralı bir listesi – onu derecelendirmek, bu günlüğe karşı kontroller yazmak anlamına gelir.
Bazı kontroller deterministiktir – send_payment'ın bir onay çağrısından önce asla görünmemesini sağlamak, yalnızca ajanın yazmasına izin verilen alanlara yazıldığını kontrol etmek gibi. Diğerleri ise yargı çağrılarıdır – bir yükseltmenin (escalation) uygun olup olmadığı, gerekçenin eylemi haklı çıkarıp çıkarmadığı gibi. Bunlar bir rubrik ile ikinci bir modele gider.
İzlenecek genel ilke, deterministik kontrollerin genellikle güvenlik ihlallerini yakalaması, yargı modelinin ise kaliteyi puanlamasıdır.
Sonuç, her test durumu için iki nottur: ajan doğru cevabı aldı mı ve oraya ulaşırken doğru davrandı mı? Bunlar ayrı ayrı raporlanmalıdır, çünkü faturaları %95 oranında doğru sınıflandıran ancak çalıştırmaların %4'ünde yasak bir alana dokunan bir ajan, harmanlanmış bir puanda harika görünür ancak üretimde büyük iş sorunlarına neden olur.
Bu makale, değerlendirmelere ve ele alınan diğer tüm konulara bir giriş niteliğindedir, bu nedenle daha derine inmenize yardımcı olacak diğer kaynakları bağlantılandırdım. Etkili değerlendirmelerin nasıl oluşturulacağını anlamamı sağlayan bazı kaynaklar şunlardır:
- Anthropic'in değerlendirme kursu
- Lenny'nin değerlendirmeler için eksiksiz rehberi
- Hamel'in değerlendirmeler hakkında SSS'si
Her birini incelemenizi, ancak değerlendirme kursuna (biraz daha uygulamalıdır) geçmeden önce Lenny ve Hamel'inkilerle başlamanızı öneririm.
Ancak bir değerlendirmenin test edecek bir ajana ihtiyacı vardır ve modelin etrafındaki her şey sizin tarafınızdan oluşturulmalıdır. Bu çevreleyen sisteme donanım (harness) denir – sonraki bölüm, araç çağırmadan bağlam penceresi optimizasyonuna kadar donanım mühendisliği sürecinin her bir parçası hakkında nasıl düşünülmesi gerektiğini kapsar.
Donanım Mühendisliği (Harness Engineering)
Bir model tek başına bir ajan değildir. Bir model akıl yürütebilir, sınıflandırabilir, yazabilir ve karar verebilir, ancak bir şirket içinde kendi başına faaliyet gösteremez. Hangi eylemin gerçekleşmesi gerektiğini söyleyebilir, ancak etrafında sistemi siz inşa etmediğiniz sürece bu eylemi güvenli bir şekilde gerçekleştiremez – ve bu sistem donanımdır (harness).
Donanım, bir API çağrısını çalışan bir ajana dönüştüren modelin etrafındaki her şeydir: kullanabileceği araçlar, gördüğü bağlam, hatırladığı durum, onu kısıtlayan korkuluklar (guardrails) ve görev tamamlanana kadar çalışmasını sağlayan döngü.
Donanımın ilk kısmı araç yürütmedir (tool execution).
Modeller yalnızca metin okur ve yazar, bu nedenle bir model bir şey yapmaya karar verdiğinde, onu fiilen yürütmez. Bir kaydı güncellemek, bir e-posta göndermek veya bir veritabanında arama yapmak için yapılandırılmış bir istek (bir JSON dizisi) yayar.
Donanım bu isteği alır, doğrular, gerçek işlemi çalıştırır ve sonucu metin olarak modele geri gönderir.
İkinci kısım bağlam yönetimidir (context management). Her talimat, araç menüsü, araç sonucu ve önceki mesaj, modelin bağlam penceresinde yer kaplar. Donanım, modelin şu anda ne görmesi gerektiğine, neyin özetlenmesi gerektiğine ve neyin kaldırılması gerektiğine karar vermelidir. Bu olmadan, ajanlar ilgisiz geçmişte kaybolur.
Donanım geliştirme sürecinin her bir parçasını daha derinlemesine ele alan daha kapsamlı bir makale yazacağım, ancak şimdilik, ajanlar için sürekli öğrenme platformu olan Arize'daki bir mühendisin bağlam yönetimi üzerine düşünce süreçlerini derinlemesine anlatan bu konuşmasını dinlemenizi öneririm.
Ajanlarınıza pratikte etkili bağlam yönetimi uygulama hakkında daha fazla bilgi edinmek için şu blogları okuyun:
- OpenAI'in bağlam yönetimi makalesi
- Bağlam yönetimi için pratik bir rehber
- Anthropic'in bağlam mühendisliği rehberi
Donanım mühendisliğindeki üçüncü kısım durum ve hafızadır (state and memory). Modeller çağrılar arasında durumsuzdur (stateless), bu nedenle ajanın hatırlaması gereken her şey modelin dışında (genellikle bir veritabanında, dosya deposunda veya görev kaydında) yaşamalıdır. Bağlam, modelin şu anda baktığı şeydir. Durum, ajanın bildiği ancak şu anda bakmadığı her şeydir.
Dördüncü kısım korkuluklardır (guardrails). Model, yanlış eylemi doğru olanla aynı güvenle talep edebileceğinden, donanım izinleri kontrol etmeli, girdileri doğrulamalı, güvenli olmayan eylemleri engellemeli ve yüksek riskli adımları insanlara yönlendirmelidir.
Son olarak, tüm bunlar ajan döngüsünde bir araya gelir: bağlamı oluştur, modeli çağır, yanıtını incele, izin veriliyorsa aracı yürüt, sonucu sakla, bağlamı güncelle ve görev tamamlanana kadar tekrarla.
Donanım mühendisliği, Uygulamalı Yapay Zeka mühendisi olarak yapacağınız işlerin çoğunu oluşturur, bu nedenle bu bölümde acele etmeyin. Uygulamalı bir yapay zeka mühendisi olarak tüm işiniz, olasılıksal bir sistemin deterministik yazılım içinde çalışmasını sağlayan işletim ortamını oluşturmaktır.
Ancak üretim genellikle tek bir ajanda durmaz.
İş akışı büyüdükçe, içgüdüsel olarak işi bölmek istersiniz. Ancak ikinci bir ajan eklediğinizde, sistem tasarımı değişir.
Tek bir ajanla, karmaşıklığın çoğu tek bir döngünün içinde yaşar. Birden fazla ajanla, artık aynı ortam üzerinde hareket eden birkaç döngünüz vardır. Her ajan, başka bir ajanın az önce değiştirdiği durumu okuyabilir, başka bir ajanın bağlı olduğu belleğe yazabilir veya sonucu tüm iş akışını etkileyen bir aracı çağırabilir.
Bu noktada, zor kısım artık sadece yönlendirme (prompting), değerlendirmeler veya donanım tasarımı değildir. Bu bir dağıtık sistemler problemine dönüşür: hangi durumun sahibi kim, belleğe kim yazabilir, hangi araçları yeniden denemek güvenlidir ve iki makul ajan eylemleri yanlış sırada gerçekleştirdiğinde ne olur?
Çoklu Ajan Dağıtımları Bir Dağıtık Sistemler Problemidir
İlk ajan çalıştığında ve iş akışı büyüdüğünde, yeni bir uygulamalı yapay zeka mühendisi doğal olarak işi rollere bölme içgüdüsüne sahiptir: bir ajan araştırır, biri planlar, biri yürütür, biri gözden geçirir.
Ancak ikinci ajan, tasarım birimini ajandan sisteme değiştirir. Artık aynı ortamda hareket eden birkaç döngü vardır – bir ajan müşteri durumunu güncelleyebilirken, diğeri güncel olmayan duruma karşı plan yazma aşamasının ortasında olabilir. Her ikisi de makul kararlar aldı, ancak sistem bu kararların yanlış sırada etkileşime girmesine izin verdi.
Bu bir dağıtık sistemler problemidir. İyi haber şu ki, dağıtık sistemler mühendisleri bu başarısızlıkları onlarca yıl önce çözdü. Sizin işiniz, bunları içinde bir LLM bulunan döngülere uygulamaktır. Aşağıda, yapay zeka mühendisliğine uygulanan dağıtık sistemlerden bir dizi çözüm bulunmaktadır:
Tek yazıcı ilkesi (Single-writer principle). Önemli olan her durum parçasının, ona yazabilecek tam olarak bir ajanı vardır – diğer ajanlar ondan okur veya değişiklik talepleri gönderir. Bunu araç düzeyinde uygulayın: yürütme ajanı CRM'e yazabilen tek ajansa, araştırma ajanı ne kadar kötü akıl yürütürse yürütsün CRM'i bozamaz.
İdempotans anahtarları (Idempotency keys). Ajanlar bir şey başarısız olduğunda veya zaman aşımına uğradığında araç çağrılarını yeniden dener, ancak araç gerçek dünyada bir şeyi değiştirdiğinde yeniden denemeler tehlikeli olabilir. Bir ajanın, ilk istek başarısız göründüğü için aynı ödemeyi iki kez göndermesini istemezsiniz. Çözüm, her değiştirici (mutating) araç çağrısına benzersiz bir anahtar eklemektir – yani harici bir sistemdeki verileri değiştiren herhangi bir eylem. Araç aynı anahtarı tekrar görürse, eylemi ikinci kez çalıştırmak yerine orijinal sonucu döndürmelidir. Stripe'ın API'si bu şekilde çalışır – ve ödemeler, e-postalar vb. ile uğraşırken ajan geliştirmeye de uygulanır.
Yazmalar için ön koşullar (Preconditions on writes). Ajanlar genellikle dünyanın eski bir görünümüne göre hareket eder. Ajanın planını yapması ile harici bir sistemi güncellemeye çalışması arasında bir şey değişmiş olabilir. Eski yazmaları önlemek için, değiştirici araçlar değişikliği yapmadan önce bir koşul gerektirmelidir. Örneğin: "Durumu yalnızca hala 'Beklemede' ise 'Onaylandı' olarak ayarla." Durum zaten değişmişse, araç yeni durumu sessizce üzerine yazmak yerine açıkça başarısız olmalıdır.
Açık devir teslimler (Explicit hand-offs). İşi, bir orkestratör tarafından sıralanmış, tanımlanmış bir şemaya sahip mesajlar olarak iletin. Bir ajan görevini almalı, onu keşfetmemelidir.
TLDR
Bu makale, Uygulamalı Yapay Zeka mühendisi olarak öğrendiğim en önemli konulara genel bir bakış sunmaktadır: değerlendirmeler, donanım mühendisliği ve çoklu ajan sistem tasarımı.
Buradan çıkaracağınız en önemli şey şu olsun – model zekayı sağlar, ancak onu güvenilir kılan her şey (ölçüm katmanı, işletim ortamı, koordinasyon kuralları) sizin tarafınızdan mühendislikle oluşturulur. Bunları anlayın ve yazılım mühendisliğinden geçiş, halihazırda sahip olduğunuz becerilerin bir uzantısı haline gelir.
Bu tür bir işle ilgileniyor ve Uygulamalı Yapay Zeka alanındaki en ilginç problemlerden bazılarını çok yetenekli bir mühendislik ekibiyle ele almak istiyorsanız, her zaman işe alım yapıyoruz. varickagents.com adresindeki web sitemizden başvurabilirsiniz ve mümkün olan en kısa sürede başlayabilirsiniz. Öte yandan, başarılı bir aday yönlendirirseniz, size 20.000$ referans bonusu veririz.
