Esse: LLM çağında izahsız arızalar normalleşiyor

ihatethefuture.com blogunda yayımlanan bir makale (yazarın takma adı: patrickxia) Hacker News'te zirveye çıktı. Yazar, LLM hızlandırmalı yazılım geliştirme kültürünün, kimsenin açıklamaya çalışmadığı arızaları sessizce normalleştirdiğini savunuyor.

"Stupid thing sucks"

Yazı, bir karakterin açılmayan kapıdan geçmeye çalıştığı iki çizgi film karesiyle başlıyor. Kapının önündeki engel fazlasıyla somut: önce bir insan bedeni, sonra yaklaşık bir milyar dolar değerinde altın. İki sahnede de sinirlenen karakter "stupid thing sucks" (kabaca "aptal şey işte, berbat") diye mırıldanıp yoluna devam ediyor. Yazar bunu "kapıların makul bir modeli" saymıyor: arızanın somut bir nedeni vardı, suçlama ise yanlış nesneye yöneldi.

Jev ve "AI-powered" işareti

Makale ardından Jev'e geçiyor: TypeSafe AI tarafından geliştirilen, tiplenmiş değerleri olasılık tahminleriyle birlikte döndüren bir AI modeli. Yazarın anlatımına göre satış noktaları hız ve maliyet: hızlı, ucuz ve üzerine hızla bir şey inşa edilebiliyor. Asıl soru inşadan sonra başlıyor. Alıcılar neredeyse hiç değerlendirme (eval) çalıştırmıyor: belirsiz soruları Jev'e verip belirsiz yanıtlar alıyor, böylece "AI-powered" kutusunu işaretleyebiliyorlar. Alt katmandaki mantık bozulduğunda "iyi işte, AI hata yapar" açıklaması hazır oluyor; hata bütçeleri, arıza modları ve test setleri sonraya kalıyor. Arıza oranını bu arada kullanıcılar kendileri keşfediyor.

Makale bariz savunmayı önceden yanıtlıyor: Jev güven skorları döndürüyor. Peki onlarla ne yapacaksınız? Bir güven skoruna göre makul bir karar vermek için hem skorun kalibrasyonunu bilmek hem de belirsizliğin maliyeti üzerine bir modeliniz olması gerekiyor. Yazarın ifadesiyle insanlar güven skorlarını en iyi ihtimalle "kargo kültü" tarzında kullanıyor; en kötü ihtimalle onları başarısız bir çağrı için mazeret olarak kullanıyor: sanki "73% eminim" yanıtı size 27%'lik bir hata bütçesi ayırmış gibi.

Sorumluluk ve soruşturmanın bittiği nokta

Bir sitede düğme bozulduğunda mühendisin kafasında genelde ne olması gerektiğine dair bir model vardır: bir sözleşme kırıldı, DNS bozuldu, biri yalnızca belirli bir yolda sözdizimi hataları olan bir betik yayınladı, bir işleyici beklenmedik bir istisna fırlattı. Çıplak bir HTTP 500'ü ayıklama erişimi olmayabilir, ama uç noktanın neden çalışmadığını anlamak birilerinin işi. Ne var ki pek çok kullanıcı için deneyim buna uzak: "bazen işler sadece kötü gider".

Makalenin asıl korkusu, LLM odaklı geliştirmenin daha çok arıza üretmesi değil. Üretecek, üretti bile: yeni bir yöntemle inşa etmenin bedelinin bir parçası bu. Korku, "bazen işler sadece kötü gider" ifadesinin soruşturmanın kabul gören bitiş noktası haline gelmesi. Yazar bunu bir kayıp olarak görüyor, çünkü hızlandırılmış çalışma bu sorunları çözmeye de yarayabilir: otomatik QA iş akışları mühendislik zamanı olmadığı için yazılmıyor ve Jev'i değiştirecek ya da kullanımını meşrulaştıracak değerlendirme "birkaç prompt uzakta". Yazı metaforuyla kapanıyor: kapının arkasında bir beden olup olmadığını ne kullanıcının ne de inşa edenin merak ettiği sistemler kuruyoruz.