LLM-First mı yoksa Code-First mı? Üretim AI’da Zekânın Yer Aldığı Yer

Modelin neyi ele alması gerektiğini, kodunuzun neyi ele alması gerektiğini ve ikisini nasıl bağlayacağınızı nasıl belirleyeceğinizi.

Birkaç yıl önce, bir AI uygulamasının mimarisi şöyle görünüyordu: büyük bir dil modeline bir istem gönder → bir yanıt al → kullanıcıya göster. Bu artık günümüzde tüm hikaye değil. Modellerden niyeti yorumlamaları, bilgi almaları, araçları seçmeleri, API’leri çağırmaları, plan yapmaları ve çok adımlı iş akışlarını yürütmeleri isteniyor.

Bu değişim alanı ikiye ayırdı – LLM-First veya Code-First

LLM-first mimarisinde, model merkezde bulunur ve sonraki adımı belirler. İsteği okur, bir araç seçer, işlem sırasını karar verir, ara sonuçları kontrol eder ve gerektiğinde yön değiştirir.

Code-first mimarisinde, yazılım/kod sıralamadan, iş kurallarından, doğrulamadan, izinlerden ve yürütmeden sorumlu olmaya devam eder. Buradaki LLM, dil anlayışı veya üretimi gerektiğinde kodun çağırdığı bir uzman gibidir.

İnsanlar hangisinin daha iyi olduğu konusunda tartışmayı sever. Bence bu yanlış bir tartışma. Daha iyi soru, her türlü zekânın nerede yer alması gerektiğidir. Görmüş olduğum en güçlü üretim sistemleri nadiren tamamen birine ya da diğerine dayanır. Olasılıksal akıl yürütmeyi belirleyici kontrolle karıştırırlar ve bunu bilinçli olarak yaparlar.

LLM-First Neden Bu Kadar Çekici?

Geleneksel yazılım, gereksinimleri net bir şekilde tanımlayabildiğinizde sorunsuz çalışır. Örneğin, bir kullanıcı bir ürün seçer, bir tutar girer ve ödemeyi gönderir. İzin verilen durumları, doğrulama kurallarını, hata koşullarını ve işlem sırasını kodda tanımlarsınız. İşte bu kadar.

Doğal dil böyle işbirliği yapmaz. Bir kullanıcının şu şekilde yazdığını hayal edin: “Alışılmadık görünen işlemleri bul, ne olduğunu açıkla ve önce neyi araştırmam gerektiğini söyle.”

Bu isteğin içinde sabit bir yol yoktur. Sistem burada “alışılmadık” ne demek, hangi verilerin önemli olduğunu belirlemek, belki birkaç aracı çağırmak, yanıtı değerlendirmek ve bir kişinin kullanabileceği bir açıklama yazmak zorundadır. Hiçbir mühendis ekibi/hiç kod, her ifadeyi ve her isteğin kombinasyonunu önceden öngöremez.

LLM’nin hayati bir rol oynadığı, insan dilini belirleyici hizmetlerinizle esnek bir akıl yürütme katmanı olarak bağladığı yerdir. Bu aynı zamanda ajanların bu kadar çok ilgi görmesinin nedenidir. Google Cloud’ın ajan AI mimarisi rehberi bir ajanı, AI modelinin akıl yürütme motoru olarak görev yaptığı ve araçların ona dış sistemlere ve verilere ulaşmasını sağlayan bir uygulama olarak tanımlar.

Anthropic’s Building Effective AI Agents kılavuzu bir ayrımı vurgular; sürekli geri döndüğüm bir nokta. Bir iş akışı içinde, modeller ve araçlar kodunuzun tanımladığı yolları izler. Bir ajan içinde, LLM kendi sürecini yönlendirir ve araçlarını nasıl kullanacağına karar verir. Aynı kılavuz, problemi çözen en basit mimariyle başlamayı, refleksle ajanlık karmaşıklığını eklemek yerine önerir. Bu tavsiyeyi iki kez vurgulardım.

Modelin Karar Vermesine İzin Vermenin Sınırları

Bir model, ne olması gerektiği konusunda akıl yürütme yapabilir. Akıl yürütme, bir kuralı uygulamaktan aynı şey değildir.

Örneğin bir finansal iş akışını ele alalım. Bir LLM, “Geçen ay gönderdiğim aynı tutarı aynı satıcıya gönder” ifadesini anlamada harika olabilir. Ancak transferin yetkili olup olmadığını, düzenleyici limitleri hesaplamasını, hesap sahipliğini doğrulamasını, bir güvenlik politikasını geçersiz kılmasını ve işlemi yürütmesini de karar vermeli mi?

Muhtemelen hayır. Bu işler deterministik, test edilebilir, denetlenebilir ve uygulanabilir niteliktedir ve bu tam da geleneksel yazılımın iyi olduğu şeydir. Modeller araçlara eriştikçe risk artar. OWASP’ın üretken AI güvenlik rehberi işaretler aşırı yetki önemli bir risk olarak işaretlenir: bir LLM tabanlı sisteme görevinden daha fazla işlevsellik, izin veya özerklik vermek. Model metin ürettiğinde garip ya da manipüle edilmiş bir çıktı bir şeydir. Model gerçek dünyada hareket edebildiğinde ise çok daha büyük bir sorundur.

Bunun hiçbiri, modellerin asla eylem yapmaması gerektiği anlamına gelmez. Model özerkliğinin deterministik yetkiyle sınırlı olması gerektiği anlamına gelir.

Code-First Hâlâ Önemli

AI o kadar hızlı ilerliyor ki, geleneksel mühendisliğin modası geçmiş gibi hissetmek kolay. Ben tam tersini savunurum. AI, iyi deterministik sistemleri daha da önemli kılar, daha az değil.

Kod, bir görevin tam tekrarlanabilirlik gerektirdiği her durumda hâlâ doğru seçimdir. Kimlik doğrulama bunun en basit örneğidir. Bir model, birinin yönetici yetkisine sahip olup olmadığını “akıl yürütmemeli”. Uygulamanız yetkili bir kimlik ve erişim yönetim sistemine sormalıdır. Aynı durum para hesaplamaları, hak kontrolü, veri doğrulama, düzenleyici kısıtlamalar, işlem limitleri, şema doğrulama ve geri döndürülemez her şey için geçerlidir. Bunlar en iyi tahminler değil, açık sözleşmeler gerektirir.

Bu, daha geniş yönetişim düşüncesiyle uyumludur. NIST AI Risk Management Framework kuruluşların AI riskini tasarım, geliştirme, dağıtım ve kullanım boyunca yönetmelerini ister. Generative AI Profile ek olarak, üretken sistemlerin, ilgili riskin seviyesine bağlı olarak ek denetim, dokümantasyon, inceleme ve kontroller gerektirebileceğini belirtir.

Bu yüzden her tasarım kararını iki soruya bölmenin faydalı olduğunu buluyorum:

Ne olması gerekir?

ve

Ne olmasına izin verilir?

Bir LLM genellikle birincisine yardımcı olabilir. Deterministik sistemler genellikle ikincisini üstlenmelidir.

Hibrit Desen: Olasılıksal Düşün, Deterministik Yürüt

Çoğu kurumsal uygulama için pratik cevap hibrittir. LLM, yorumlama ve akıl yürütme katmanı olarak çalışır. Deterministik hizmetler ise yürütme ve uygulama katmanı olarak çalışır.

İşte bir örnek. Bir AI asistanının geliştiricilerin geçici API test ortamları oluşturmasına yardımcı olduğunu ve bir geliştiricinin şu komutu verdiğini düşünün: \”Müşteri onboarding iş akışı için bir sandbox ver.\”

LLM bunu yorumlayabilir, hangi iş akışının kastedildiğini belirleyebilir, belgeleri okuyabilir ve hangi API’lerin muhtemelen ilgili olduğunu önerebilir. Ancak ortamı gerçekten oluşturmak serbest biçimli oluşturulan metne bağlı olmamalıdır. Kod, istenen API’lerin mevcut olduğunu doğrulayabilir, sözleşmelerini doğrulayabilir, yetkilendirmeyi kontrol edebilir, kaynak limitlerini uygulayabilir, onaylanmış bir yapılandırma oluşturabilir ve dağıtımı çalıştırabilir.

Kabaca bölünme şu şekildedir:

• LLM: anlamak, akıl yürütmek, sınıflandırmak, önermek, özetlemek.
• Kod: doğrulamak, yetkilendirmek, hesaplamak, kalıcı hale getirmek, uygulamak, yürütmek.

Her iki taraf da en iyi olduğu işi yapar ve hiçbiri diğerinin güçlü yönlerini taklit etmesi istenmez.

Sınırlar, Ajanlar Daha Güçlü Hale Geldikçe Daha Önem Kazanır

Bu ayrım, asistanlardan ajanlara geçtikçe daha da önemli hale gelir. Kötü bir yanıt veren bir asistan birini rahatsız eder. Üretime yazma erişimi olan bir ajan çok daha büyük bir karmaşaya yol açabilir.

Düzeltme mutlaka özerkliği tamamen kaldırmak değildir. Özerkliği kademeli olarak eklemek, açık kontrol noktalarını yerinde tutmak gerekir. Google’ın çok ajanlı sistemler üzerine kılavuzu dinamik AI davranışını deterministik güvenlik kontrolleri, gözlemlenebilirlik, net tanımlanmış özerklik ve iş kritik senaryolar için insan denetimiyle eşleştirmeyi önerir.

İnsan onayı, resmi bir güvenlik ağı olmak yerine iş akışının içine de entegre edilebilir. Microsoft’s agent framework documentation, örneğin, istenen işlemi bir kişinin açıkça onaylayana kadar duraklatan araç çağrılarını destekler.

İlke basittir: bir eylemin sonuçları ne kadar yüksekse, etrafındaki deterministik kontroller de o kadar güçlü olmalıdır.

Bir Görevi LLM’ye Vermeden Önce Sorulması Gereken Beş Soru

Bir bileşenin LLM-öncelikli mi yoksa kod-öncelikli mi olacağına karar verirken, şu soruları gözden geçiririm:

1. Görev, nesnel olarak tek bir doğru cevaba sahip mi? Eğer öyleyse, deterministik koda yönelin. Vergi hesaplamaları, izinler ve şema doğrulaması, bir modelin bugün farklı okuması nedeniyle değişmemelidir.
2. Belirsiz dil veya yapılandırılmamış bilgi içeriyor mu? Eğer öyleyse, bir LLM gerçek değer katabilir.
3. Model yanıldığında ne olur? Bir toplantı özetinin doğru mimarisi, bir ödemeyi başlatmanın doğru mimarisinden çok farklıdır.
4. Çıktı bağımsız olarak doğrulanabilir mi? LLM tarafından üretilen planlar, deterministik kurallar sonuçta oluşan eylemi çalıştırmadan önce kontrol edebildiğinde çok daha güvenli hale gelir.
5. Bu gerçekten bir ajana ihtiyaç duyuyor mu? Eğer adımları zaten biliyorsanız, birkaç hedeflenmiş LLM çağrısı içeren normal bir iş akışı genellikle daha basit, daha ucuz, test etmesi ve işletmesi daha kolaydır.

Son soru ekstra dikkat gerektirir. Ajanlar, her adımı tahmin edemediğiniz durumları yönetebildikleri için güçlüdür. Ancak eğer yapabilir adımları tahmin ediyorsanız, bunları açık uçlu bir akıl yürütme problemine dönüştürmek genellikle zekâ eklemeden değişkenlik ekler.

Güvenilirlik Bir Mimari Özelliktir, Prompt Değil

Birçok ekip, güvenilirliği neredeyse tamamen prompt mühendisliğiyle artırmaya çalışarak başlar. Prompt’lar önemlidir, ancak tüm yükü taşıyamazlar.

Bir üretim sistemi, model çıktısının zaman zaman eksik, hatalı, beklenmedik ya da sadece yanlış olacağını varsaymalıdır. LLM uygulamaları için OWASP Top 10, şu riskleri listeler: prompt enjeksiyonu ve uygunsuz çıktı işleme, bu da önemli bir alışkanlığı pekiştirir: model çıktısını aşağı akış sistemlerine güvenilmeyen girdi olarak ele almak, otomatik olarak çalıştırılacak talimat olarak değil.

Bu, sorduğunuz soruyu değiştirir. “Modelin her zaman kuralı uygulamasını sağlayacak bir istemi nasıl yazarım?” sorusu yerine, “Model bir hata yaptığında bile kuralın kırılmasını engelleyecek şekilde sistemi nasıl tasarlarım?” sorusunu sorun.

Bu bir yazılım mimarisi sorunudur, istem sorunu değildir. Bir istem, bir ajana yetkisiz bir eylemi gerçekleştirmemesini söyleyebilir. Yetkilendirme hizmeti ise bunu gerçekten durdurabilir. Bu iki kontrol eşdeğer değildir.

Tartışmanın Ötesinde: Niyet-İlk Sistemler

Bunların hepsini düşündükçe, LLM-öncelikli ile kod-öncelikli tartışmasının üçüncü bir fikre işaret ettiğine inanıyorum: intent-first mimarisi.

Bir niyet-öncelikli sistemde, uygulama kullanıcının ne başarmaya çalıştığını anlamakla başlar. İşte bu noktada bir LLM en değerli olur, çünkü insanlar ne istediklerini nadiren net bir şekilde ifade eder. Buradan itibaren sistem, bu belirsizliği istikrarlı bir şekilde yapılandırılmış, deterministik işlemlere dönüştürür.

“Müşterinin ödeme sorununu çözmeme yardımcı olun” gibi bir istek, şu aşamalardan oluşan bir işlem hattına dönüşebilir: niyeti anlamak, işlemi getirmek, hata nedenini belirlemek, bir çözüm önermek, onay istemek, onaylanan işlemi yürütmek.

Bu aşamalardan bazıları dil modeli akıl yürütmesinden fayda sağlar. Diğerleri sabit hizmetler olmalıdır. Mimari, AI mı yoksa kodun mu “kazandığı”na göre belirlenmez. Belirsizliğin kabul edilebilir olduğu yerlere göre tanımlanır.

Sonuç

Modeller geliştikçe, onlara yığının daha büyük ve daha büyük bölümlerinde kontrol vermek cazip olacaktır. Bazen bu doğru bir karar olur. Diğer sistemlerde, en sofistike tasarım, modeli kasıtlı olarak daha az yetki vermek olacaktır.

Üretim AI mühendisliği, nihayetinde, zekayı doğru sınırda konumlandırmakla ilgilidir. Yorumlama, akıl yürütme, sentez ve uyarlamanın değer yarattığı yerlerde dil modelleri kullanın. Tutarlılık, yetkilendirme, hassasiyet ve uygulamanın önemli olduğu yerlerde deterministik yazılım kullanın. Ardından ikisini dar, gözlemlenebilir, iyi test edilmiş arabirimlerle bağlayın.

Kurumsal AI geleceği muhtemelen tamamen LLM-öncelikli ya da tamamen kod-öncelikli olmayacak. Belirsizliğin zekâ gerektirdiği yerlerde LLM, kesinliğin kontrol gerektirdiği yerlerde kod kullanılacak.

Bu ayrım, hangi modeli seçtiğinizden çok daha önemli olabilir.