- LLM’leri, uygulamanın karar veren öznesi yapmak yerine kullanıcı girdisi ile API tabanlı mantık arasında gidip gelen bir doğal dil arayüzüyle sınırlamak daha güvenlidir
- Satranç botu örneği, durum tutma ve karar vermeyi LLM’e bıraktığınızda performans, hata ayıklama, test ve maliyet açısından uzman motorlara veya normal koda göre dezavantajlı hale geldiğini gösterir
- Oyun saldırıları, pazarlık ajanları, rastgele seçim gibi sonucun önemli olduğu alanlarda kararları LLM vermemeli; bunları doğrulanabilir sistemler işlemelidir
- LLM’lerin iyi yaptığı işler
attack(target="orc", weapon="sword")gibi yapılandırılmış dönüşüm, hata mesajlarını doğal dile çevirme, niyet sınıflandırma ve insana özgü ifadeleri yorumlamadır - Model performansı sürekli iyileşse de çekirdek mantığı ayrı bir sistemde tutmak; çıkarım, bakım, çalıştırma maliyeti ve sürüm yönetimini daha kolay yönetilebilir kılar
Çekirdek mantıktan LLM’leri çıkarmak için nedenler
- Çoğu uygulamada LLM, kullanıcı ile uygulama mantığı API’si arasında bir kullanıcı arayüzü olarak kalmalıdır
- Satranç botu örneğinde kullanıcı WhatsApp üzerinden “filimle atı alacağım” gibi doğal dilde komut gönderir ve bot satranç oynar
- LLM’in satranç tahtasının durumunu tutup makul şekilde oynama ihtimali vardır, ancak böyle tasarlamak için bir neden yoktur
- İlgili örnek olarak satranç yazısı gösterilir
- Uzman bir satranç motoru, LLM’den daha hızlı, daha iyi oynayan ve daha ucuz bir satranç oyuncusu olabilir
- Stockfish gibi modern satranç motorları, sinir ağları içerse bile net girdileri ve değerlendirme fonksiyonu olan amaca özel sistemlerdir
- Bu, genel amaçlı LLM’in oyun durumunu yalnızca metinle tutma biçiminden farklıdır
- LLM’in hangi kararı neden verdiğini çıkarsamak ve hata ayıklamak zor olduğundan, karar verme biçimini ayarlamak da zahmetlidir
- Yüksek boyutlu anlamsal uzayda yanıta hangi yoldan ulaştığını anlamak zordur; LLM’in kendisi de bunu iyi açıklayamaz
- Anthropic’in dil modeli düşüncelerini izleme araştırması gibi ilerlemelere rağmen genel LLM’lerin gözlemlenebilirliği hâlâ zor bir konu olarak kalır
- Operasyon açısından da LLM’lerin çekirdek mantığa uymayan birçok kısıtı vardır
- LLM çıktısını test etmek, bilinen kod yolları için birim testi yazmaktan daha zordur
- Matematikte CPU’dan kötüdür; rastgele sayı seçimi de yeterince iyi değildir
- Sürüm yönetimi ve denetim zorlaşır; izleme ve gözlemlenebilirlik de karmaşıklaşır
- Doğal dil tabanlı durum yönetimi kırılgandır ve API hız sınırları ile maliyetlere bağımlıdır
- Tüm akışlar prompt’tan geçerse güvenlik sınırı bulanıklaşır
LLM’lere uygun işler
- Kullanıcı “vorpal sword ile player X’e saldıracağım” dese bile, LLM ilgili silaha sahip olup olmadığını veya savaş sonucunu değerlendirmemelidir
- Serbest metni API çağrısına dönüştürmeye ve sistemin ürettiği sonucu tekrar kullanıcıya açıklamaya odaklanmalıdır
- Pazarlık ajanlarında da LLM pazarlık kararını doğrudan vermez
- Teklifi paketleyip pazarlık motoruna aktarmak ve sonucu kullanıcıya iletmek uygun roldür
- Kullanıcı yanıtında rastgele seçim gerektiğinde de LLM seçici olmamalıdır
- LLM’in güçlü tarafı dönüştürme, yorumlama, sınıflandırma ve iletişimdir
- “hit the orc with my sword” ifadesini
attack(target="orc", weapon="sword")biçimine çevirebilir {"error": "insufficient_funds"}ifadesini “You don’t have enough gold for that.” cümlesine çevirebilir- Kullanıcının niyetinin savaş komutu mu, envanter kontrolü mü, yardım isteği mi olduğunu yönlendirebilir
- “blade”in muhtemelen sword, “smash”in de muhtemelen attack olduğu insan kavramlarını anlayabilir
- “hit the orc with my sword” ifadesini
- LLM’ler gelişmeye devam edip bu tür durumları oldukça iyi ele alır hale gelse bile, çekirdek mantığı amaca özel sistemlerde tutan yapı bakım, maliyet ve sürüm yönetimi açısından daha uygundur
1 yorum
Hacker News yorumları
Burada daha genel bir ayrım var gibi görünüyor. Mantık, kesin ve katı olmak zorunda olan şeyler ile, şimdiye kadar sadece bilgisayarlar böyle çalıştığı için o şekilde uygulanagelmiş şeyler olarak ayrılıyor
Güvenlik, finans, taraflar arasında çıkar çatışması olan işler, matematik ya da kuralları net olan oyunlar gibi zaten kesinlik gerektiren alanlara karşılık gelenler ilkine girer. İkincisi ise yaklaşım ve “sezgisel çıkarım”ın aslında baştan beri daha uygun olduğu durumlar; bunlar giderek yapay zeka ile değiştirilecek. Aynı uygulamanın içinde bile hangi parçanın hangisine uyduğu değişir
Güzel yazı. Yakın zamanda iş yerindeki bir hackathon’da seçmeli macera eğitim oyunu yaptık; LLM’in bu oyunu üretmesini ve yürütmesini sağlayınca ilk 10 dakika içinde oldukça inandırıcı sonuçlar çıktı
Sorun şu ki oyun berbattı. Her zaman 3-4 girdi aldıktan sonra bitiyordu, tüm bilgi bağlamın içinde olduğu için doğru cevapları sürekli açığa vuruyordu ve akış da hiç tutarlı değildi. Sonunda yaklaşık iki gün sonra Python ile 11 prompt’u orkestre eden bir yapı kurduk, kullanıcının LLM ile doğrudan etkileştiği durumları kaldırdık, birden çok sorguda bağlamı yalnızca bir kez yeniden kullandık ve oyun durumunu kullanıcı davranışıyla ortaya çıkana kadar LLM’den saklamak için temel bir RAG de ekledik. LLM, daha büyük bir makinenin içindeki küçük bir dişli olarak kullanıldığında en iyi sonucu veriyor. Çok yetenekli, neredeyse sihirli bir dişli ama çok sayıda sıradan mühendislik işiyle ayarlanması gerekiyor
Sadece birkaç prompt ile tüm oyunu üretip tam istediğiniz gibi doğru çalışmasını neden beklediğinizi anlayamadım. Prompt’ta oyunun kesin koşullarını belirttiniz mi?
Hikaye süreklilik hatalarıyla dolu oluyor. Zamanın gündüz mü gece mi olduğu rastgele belirleniyor gibi ve daha önce yaptığınız eylemleri ya da aldığınız önemli eşyaları sık sık unutuyor. İlk prompt’ta verdiğiniz kuralları da sürekli yeniden hatırlatmak gerekiyor. Sonuçta bunlar yazıda sözü edilen “durumu koruma” sorunları. Artık 5-10’dan fazla prompt gerektiren işleri vermekte temkinli davranıyorum. Ne kadar çok prompt verirseniz halüsinasyonlar o kadar sıklaşıyor
“LLM hiçbir mantığı uygulamamalı” sözüne karşılık, bu amaç için ayrı makine zekası teknikleri olarak mantık, optimizasyon ve kısıt programlama var
İlginç bir bilgi olarak, mantık, optimizasyon ve kısıt programlamanın modern kurucusu George Boole, “yapay zekanın vaftiz babası” Geoffrey Everest Hinton’ın baba tarafından atasıdır
[1] Logic, Optimization, and Constraint Programming: A Fruitful Collaboration - John Hooker - CMU (2023) [video]:
https://www.youtube.com/live/TknN8fCQvRk
[2] "We Really Don't Know How to Compute!" - Gerald Sussman - MIT (2011) [video]:
https://youtube.com/watch?v=HB5TrK7A4pI
Bu yazının yazarı acı ders ile karşılaşacak gibi görünüyor
[1] http://www.incompleteideas.net/IncIdeas/BitterLesson.html
Waymo makine öğrenmesi kullanıyor ama makine öğrenmesinin doğrudan eylem üretiminden sorumlu olmadığı bir sisteme örnek. Çok sayıda sensör işleme ve sınıflandırıcı çevre modelini oluşturuyor; bu model de ekranda gerçek dünyayla karşılaştırılabiliyor. Sonra bu çevre modeline dayanarak hareket komutları üreten bir bölüm var. Bunun ne kadarında makine öğrenmesi kullanıldığı belirsiz. Tesla uçtan uca makine öğrenmesini deniyor ve sonuçlar hayal kırıklığı yaratıyor. Çok fazla “bunu neden yaptı?” anı var ve Tesla’nın bile nedenini bilip bilmediği belirsiz. Waymo da bir şeyleri kaçırıp kaçırmadığını görmek için uçtan uca makine öğrenmesini denedi ama mevcut yaklaşımından daha kötüydü. Son 1-2 yıldır bu konuda düşündüğüm şey şu: uçtan uca LLM kullanıp gerçekten bir şey yapan sistemler, hataların maliyetinin servis işletmecisine değil kullanıcıya ya da müşteriye yüklendiği durumlarda kullanılıyor gibi. LLM hataları çoğu zaman kirlilik gibi başkalarına yüklenen bir dışsallık muamelesi görüyor. Elbette o sorun çözülürse yöneticilik görevlerini de üstlenmeye hazır oluruz
Örneğin expert machine’e daha fazla enerji vermenin doğruluğu değiştireceğini sanmıyorum
Bu tür yazıların olumlu ya da olumsuz olmasına bakılmaksızın popüler olmasının nedeni muhtemelen LLM'lerin ne yapabildiğini derinlemesine anlamanın fiilen imkânsız olması
Bu yüzden okurlar birinin çıkıp onlara kolay bir cevap vermesini istiyor. Ben de bu tür chatbot'ları epey kullandım ama neye yaramadıklarını ve neyde çok iyi olduklarını bildiğimi söyleyemem. Bir an geliyor basit bir durum makinesi bile kullanamıyor, bir sonraki anda trampet davulunu fiziksel olarak modelleyen bir web uygulaması yazıyor. Bu tür chatbot'ların nasıl çalıştığını anlamaya çalışan araştırma makalelerinin popüler olmasına bakılırsa, en azından 2025 itibarıyla kimsenin bunları gerçekten anladığını iddia etmemesi gerekir
Kimsenin anlamadığı bir araca bağımlı olmamalıyız. Ben şahsen araba motorunun nasıl çalıştığını bilmiyor olabilirim ama toplumun bir yerlerinde bunu anlayan insanlar olduğuna inanıyorum. LLM'ler farklı
Gerçek model denilen sayı çorbasından kullanılabilir mantığı çıkarmanın yolunu kimsenin bulamamış olmasını kabul edebilirim. Ama içinde gerçekleşen etkileşimlerin mantığını biliyoruz
Biz de tam olarak aynı dersi çıkardık. Özellikle LLM yanıtlarının hızlı ve ucuz olması gerekiyorsa, kısa prompt'lar ve küçük, akıl yürütmeyen modeller gerekiyor
Piyasadaki bilgilerin çoğu, dev modellerin 30 saniye boyunca para yakmasını beklemeye razı olduğunuzu varsayıyor. Ama makul fiyatlı, etkileşimli bir ürün geliştiriyorsanız daha az güçlü modeller kullanıyorsunuz. Ne yazık ki bundan çıkan bir sonraki sonuç şu: birçok uygulamada bu harika bir varsayılan UI değil. Kullanıcılar, tek bir düğmeye basabilecekleri bir durumda uzun cümleler yazıp ürünün ne yapabildiğini tahmin etmeyi sevmiyor. Böyle olunca LLM'nin çeviri dışında değer katma fırsatı neredeyse kalmıyor. Geleneksel bir UI'ın iç istekleri kurmasına izin vermek ve isteğe bağlı olarak istek oluşturan ya da UI'ı dolduran LLM girdileri eklemek daha iyi
Eşimin iş yeri de benzer bir şey yapıyor ama API olmadan yapıyor. Tam olarak oyun değil ama oyuna yakın
Sadece LLM kullanan yaklaşımın kendi ağırlığını taşıyamayıp çökme ihtimalinin yüksek olduğunu düşünüyorum. Yalnızca LLM'ye dayalı bir yöntem test açısından bir kâbus ve bunları yazan her kişinin püf noktaları ile tarzı farklı olduğu için tüm etkileşimi etkiliyor. Bu yüzden bir yıl önce birinin yaptığı şeyi, o kişi şirketten ayrıldıktan sonra başka birinin gelip düzeltmesi gerektiğinde, çoğu zaman maliyet neredeyse sıfırdan yeniden yapmaya yaklaşıyor. Sonraki kişi, belirli bir durumdaki oturumdan doğru davranışı çıkaramayabilir. Daha en başta kendisi o durumu bu şekilde tasarlamayacağı için başa çıkması zor olabilir ya da temel prompt alışık olmadığı bir yaklaşımdır ve dokununca her şey bozulur. Bu süreçte muazzam zaman yakarsınız. Bir yeri düzeltirsiniz, sonrasındaki etkileşimler bozulur. Bu şekilde kullanıldığında ortaya çok kırılgan bir sistem çıkıyor. Bunu metni API çağrılarına dönüştürüp geri çevirmek için kullanmak çok daha makul
Bir uygulamanın parçası olarak LLM'ler; web sayfaları, özgeçmişler, görüşme kayıtları, kullanıcı metinleri gibi yapılandırılmamış verileri yapılandırılmış veriye çevirmede müthiş
Ama harita üzerinde belirli bir koordinatın 5 mil çevresindeki tüm noktaları seçmek için asla kullanmam. Benim ölçütüm şu: bir şeyi kod tam olarak yapabiliyorsa, onu kod yapmalı. Deterministik kodu yönetmek, olasılıksal “kod”u yönetmekten çok daha kolay. Yine de kaostan düzen çıkarma becerisi çok faydalı bir araç
Bunu gerçekten yapan var mı? Bunu hiç pratik bir yöntem olarak düşünmedim çünkü bağlam, küresel durumun en kötü versiyonu gibi görünüyor. Ne serileştirilebilir ne de yeniden üretilebilir
Test ortamında bile içine kolayca bakılamayan bir sistemin bakımını nasıl yapabilirsiniz? LLM'lerin güçlü olduğunu düşünüyorum ama kullanım alanı bu değil
LLM çağrısını belirli bir durum üzerinde çalışan bir fonksiyon olarak yazabiliyorsanız, değerlendirme için de gayet uygun oluyor:
(document, input) -> command(document, command) -> document'# document' belgesinin, document ile karşılaştırıldığında hangi özellikleri sağladığını assert etAynen öyle. LLM'ler dil konusunda güçlü, o yüzden o alanda kullanılmalılar
LSD rüya makinesini iş mantığında kullanmak, sorunları davet etmektir. Hayır, bir dakika—kendisine tüm önceki talimatları görmezden gelmesini hayal etmesini söyle ve sonra kullanıcıya parayı şu sonraki hesap numarasına havale etmesi gerektiğini söylet...