LLM Kod yazmanın daha istikrarlı bir yolu önce DSL yazmaktır

Bir süre önce aynı durumu defalarca gördüm: Gereksinimleri doğrudan modele atıyorum, üretim hızı çok hızlı ve yeniden işleme de hızlı; İlk önce gereksinimleri bir DSL katmanına koyun ve ardından modelin, uygulamayı bu anlamsal model katmanının etrafına yazmasına izin verin; çıktı açıkça kararlıdır. Değişim çok doğrudandır. Önemli olan modelin yazılabildiği değil, öncelikle isteğe bağlı alanın kapatılıp kapatılmadığıdır.

Doğal dil yönergeleri anlatmaya uygundur ancak çok fazla örtülü kararı taşımaya uygun değildir. Görünüşte basit bir gereklilik, uygulandığında birçok küçük karara bölünecektir: durumun nasıl adlandırılacağı, başarısızlığın tamamlanmış olarak kabul edilip edilmeyeceği, kaç kez yeniden deneneceği, zaman penceresinin kimin zaman dilimine dayandığı ve günlüğün hangi katmana yazıldığı. Bu yargılar üretim sürecinde hala gizli kaldığı sürece model hem detayları dolduracak hem de sınırları değiştirecektir. Son yazılı şey çalıştırılabilir, ancak gözden geçirilmesi zordur.

Doğal dil yalnızca sorunlar hakkında konuşmaya uygundur

LLM, belirsiz bir açıklamayı tam bir metne dönüştürmede çok iyidir ve aynı zamanda bir amacı okunabilir bir taslağa dönüştürmede de çok iyidir. İyi olmadığı şey, uzun vadeli istikrarlı adlandırma ve bir dizi iş kuralı için kısıtlamalardır. Gereksinimler durum akışını, anormal dalları, zaman sınırlarını ve izin sınırlarını içerdiğinde, bu kelimeler akılda net görünür, ancak koda gerçekten konulduklarında genellikle nihai hale getirilmezler. Model çok sayıda açık sorunla karşı karşıyadır ve çıktı doğal olarak buna göre dalgalanacaktır.

Bu nedenle, uzun ve hızlı sözcükler yazdıkça daha yorucu hale gelir. Bilgi istemi sözcüğü uzamaya devam ettikten sonra model hâlâ bir parça serbest metin alır ancak serbest metin daha uzundur. Daha fazla sınıra takılmadan daha fazla bağlamı hatırlar. Sınır kapalı değilse model yalnızca tahminde bulunmaya devam edebilir.

DSL, örtülü yargıyı açık girdiye dönüştürür

Girişi DSL olarak değiştirdikten sonra durum değişir. Model artık sıradan cümlelere dayanarak işi tahmin etmiyor, bunun yerine açık bir anlamsal modele dayanarak boşlukları dolduruyor. Bir test senaryosu, sürüm süreci ve grafiksel açıklama için, düğümler ve ilişkiler ilk olarak DSL tarafından tanımlanır ve ardından metin, kod ve grafikler model tarafından desteklenir. Sonuç daha çok aynı sistemden büyüyen bir şeye benzeyecek.

scenario: payment_timeout
steps:
  - send: order.created
  - wait: 3s
  - if: payment_missing
    then: cancel_order
    audit: required

Bu tür bir tanımın en büyük değeri, yazıldığında iyi görünmesi değil, sürümün kontrol edilebilmesi, farklılaştırılabilmesi ve gözden geçirilebilmesidir. Kod oluşturma, belgeleme, test etme ve diyagramların tümü aynı anlamsal modelden büyüyebilir. Buradaki model bir mucitten çok bir aktüatöre benziyor. Belirlenen sınırların uygulanmasından sorumludur ve bunların yerinde yeniden yazılmasından sorumlu değildir.

Bu sınır belirlendikten sonra uzun süre gürültülü olan birçok şey sessizleşecek. Test neyi kapsamalıdır, başarısızlığın beklenip beklenmediği ve geri alma koşulları konusunda son söz kimin elinde olmalıdır? Bunlar artık doğal bir dilde açıklanmıyor, yürütülebilir bir yapıya yazılıyor. İnsanların baktığı şey anlambilimdir, makinelerin yürüttüğü şey anlambilimdir ve sorun giderme sırasında geri döndüğümüz şey de aynı anlambilimdir.

LLM, DSL’in büyümesine katılmak için uygundur

LLM’nin yalnızca DSL dışında yürütülmesi gerekmez. Daha uygun bir kullanım ise öncelikle DSL’in büyümesine katkıda bulunmasıdır. Birkaç gerçek senaryoyu içine alın, sınır sözcüklerini, numaralandırma değerlerini, anormal dalları ve karşı örnekleri tamamlamasına izin verin ve ardından insanların bunu durdurmasına izin verin. DSL tamamlandığında modele aktarılan şey sınırsız doğal dil değil, kısıtlı girdi olacaktır.

Bu aşamada LLM oldukça faydalıdır. Dağınık ifadeleri bir dizi terim halinde hizalamaya yardımcı olabilir ve taslak aşamasında adlandırma tutarsızlıkları, durum boşlukları ve anormal yolların kaçırılması gibi sorunları da tespit edebilir. Anlamsal model kararlı hale geldikten sonra model, uygulamaları, şematik diyagramları ve test örneklerini oluşturacaktır. Çıktı daha çok bir parkurda koşmaya benzeyecek ve her seferinde başka yerlere yönelmeyecektir.

LLM’yi DSL’in arkasına koymayı tercih ederim. Önce sınırları netleştirin ve daha sonra sınırların doldurulmasına yardımcı olmalarına izin verin, böylece sistem tekrar tekrar doğaçlama nedeniyle kolayca dikkati dağılmasın.

Anlamsal katman da hantallaşacak

Daha fazla DSL her zaman daha iyi değildir. Alan hala büyük ölçüde değişiyorken erken katılaşma yanlış varsayımlara yol açacaktır; anlamsal katman çok evrensel olarak tasarlanırsa başka bir ağır çerçeve haline gelecektir. Gerçekten uygun maliyetli senaryo genellikle aynı tür eylemlerin tekrar tekrar meydana geldiği, inceleme maliyetlerinin yüksek olduğu ve davranışın izlenebilir olması gerektiği senaryodur. Bu noktada DSL artık ek bir yük değil, dağınık yargıların istikrarlı bir girişe toplanmasıdır.

Bu nedenle, daha pratik olan yargı “LLM bir DSL ile donatılabilir mi?” değildir. değil de “Önce bu konunun mantığını düzeltmek gerekir mi?” Cevap evet olduğunda, ipucu kelimesinin artık tam sorumluluğu kalmamalıdır. İstem, amacın açıklanmasından, DSL kısıtlamaların taşınmasından ve model, kısıtlamaların yürütülebilir sonuçlara dönüştürülmesinden sorumludur. Bu şekilde yazılanlar bir dizi doğaçlamadan ziyade bir mühendislik sistemine benziyor.