LLM'ler, doğal dil açıklamalarından kod üretmede olağanüstü yeteneklere sahiptir. Ancak, üretilen kodun tam olarak istenen amaca uygun olması için net sınırlara ihtiyaç vardır. Soyutlamalar ve Domain-Specific Languages (DSL'ler), LLM'leri baştan itibaren doğru yönlendiren güçlü bir kılavuz sağlar. Tickloom örneği – dağıtık sistem davranışını modellemek için bir domain modeli ve DSL – bir LLM'yi hem DSL'i yinelemeli olarak inşa etmek için bir ortak hem de onu kullanmak için doğal dil arayüzü olarak nasıl kullanabileceğimizi gösteriyor. Bu tür bir DSL, LLM dünyasında yazılım sistemleri için ana doğruluk kaynağı olarak hareket edebilir.
Modern LLM'ler, yalnızca yüksek seviyeli doğal dil açıklamalarından büyük miktarlarda kod ve hatta bütün sistemler üretebilir. Burada önemli bir varsayım, inşa edilecek şeyin 'niyetinin', LLM'lerin kod bloklarına haritalayabileceği kesin kelimelerle iyi ifade edilmiş olmasıdır. Ancak, iki önemli noktayı belirtmekte fayda var: baştan belirlemenin sınırları ve tasarımın uygulama yoluyla keşfedilmesi. Büyük sistemler inşa etmek, çok sayıda küçük tasarım kararı içerir ve bunların hepsi önceden bilinemez veya tamamen yüksek seviyeli bir spesifikasyondan yönlendirilemez. Bir spesifikasyon en iyi ihtimalle başlangıç hipotezidir; gerçek kısıtlamalar, ödünleşimler ve uç durumlar, uygulamaya devam ettikçe yinelemeli olarak keşfedilir. Bu, Spesifikasyonun İmkansızlığı olarak adlandırdığımız bir durumdur. Amaç, spesifikasyonların değersiz olduğu değil, ilkinin bitmiş bir plan değil, revize edilecek bir hipotez olduğudur. Doğal yanıt, yinelemektir: spesifikasyonu iyileştir, kod üret, geri döneni gözden geçir ve öğrendiklerini bir sonraki tura besle. Bu döngü, her tur küçük, gözden geçirilebilir bir değişiklik ürettiğinde iyi çalışır.
Kod gözden geçirmek, özellikle tasarımı henüz keşfederken, onu yazmakla aynı değildir. Üretilen kodu gözden geçirirken, niyetimize uyup uymadığını doğrulayan parçaları inceler ve olası tuzakları ararız. Ancak gözden geçirme, nadiren bizi tasarım kararlarıyla boğuşmaya zorlar. Kod yazmak ise bizi somut kararlar – bir sorumluluğun nereye ait olduğu veya tasarımın daha da genişletilebilmesi için hangi sınırların açığa çıkarılması gerektiği gibi – üzerinde düşünmeye zorlar. Tasarım en iyi bu kararları verirken kendini gösterir. Kod, iki farklı ancak iç içe geçmiş amaca hizmet eder: makine için bir dizi talimat ve problem alanının kavramsal bir modeli. İyi tasarlanmış bir kod tabanı, bir alanın kelime dağarcığının bir temsilidir. Bu soyutlamalar, ancak geliştiriciler yazılımı inşa ederken ortaya çıkar. Programlama dilleri, düşünme araçları olarak hareket eder ve daha sonraki evrimi destekleyen kavramsal bir modelin inşasını sağlar. LLM'lerde kod, temel bağlam görevi görür: iyi soyutlamalar, yürütülebilir davranış, testler, türler ve değişmezler, modeli kısıtlamaya ve çıktısını daha kullanışlı hale getirmeye yardımcı olur.
Domain-Specific Languages (DSL'ler), LLM'lerle neden bu kadar iyi çalışır? PlantUML, Mermaid ve Graphviz, görsel modelleme için DSL'lerdir; SQL, veritabanı sorgulama için bir DSL'dir; Kubernetes YAML, bulut altyapısını tanımlamak için bir DSL'dir. Bunlar genel amaçlı programlama dilleri değildir – kasıtlı olarak kısıtlanmış, bir alandaki dar bir kavram kümesini ifade etmek için tasarlanmıştır. LLM'lerin düz bir İngilizce açıklamadan Mermaid diyagramları, SQL sorguları veya Kubernetes manifestoları oluşturmada oldukça iyi olması şaşırtıcı değildir. Gözlemim, DSL'lerin LLM'leri daha güvenilir kıldığı yönünde çünkü birkaç bağlam içi örneğe çok iyi yanıt veriyorlar. Java gibi genel amaçlı bir dil, aynı amacı ifade etmek için birçok geçerli yol sunar. Bir DSL, bu çeşitliliği ortadan kaldırır. Modele birkaç örnek vermek, doğru sözdizimini güvenilir bir şekilde oluşturmak için yeterlidir. Ön saflardaki modellerin eğitim sırasında PlantUML veya Java akıcı arayüzlerine yoğun maruz kaldığını belirtmekte fayda var. Daha küçük, daha kısıtlı modellerin gerçekten yeni bir DSL ile karşılaştığında nasıl performans göstereceğini görmek merak konusu olacaktır.
Bir ajan – tek seferlik üretim yerine otonom bir üret-ve-kontrol et döngüsünde çalışan bir LLM – için bir fayda daha vardır. Bir DSL neredeyse her zaman belirleyici bir doğrulayıcı ile birlikte gelir: bir ayrıştırıcı, JSON şeması, tip denetleyicisi veya derleyici. Ajan, bir aday üretebilir, doğrulayıcıdan geçirebilir ve hatadan onarabilir, tüm bunları insan müdahalesi olmadan yapabilir. Kritik olarak, hatalar alan düzeyinde ifade edilir – “bir işlemciyi iki kuyruğa bağlayamazsınız” gibi – bu da düzeltmeyi daha anlamlı kılar. Bu, LLM'lerle DSL kullanımını sadece doğru değil, aynı zamanda verimli kılar.
Uzmanların Görüşleri
Sonuç olarak, DSL'ler LLM'lerin güvenilirliğini artırmak için güçlü bir araçtır. Soyutlama ve doğrulama yoluyla, LLM'lerin ürettiği kodun istenen amaca uygun olmasını sağlarlar. Tickloom örneği, bu yaklaşımın pratikte nasıl uygulanabileceğini gösteriyor. Geliştiriciler, DSL'leri kullanarak LLM'leri daha etkili bir şekilde yönlendirebilir ve yazılım geliştirme sürecini hızlandırabilir. Gelecekte, daha fazla alan için DSL'lerin geliştirilmesi ve LLM'lerle entegrasyonu, yazılım mühendisliğinde yeni bir dönemin kapılarını açabilir.
Kaynak: martinfowler.com
