1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Incident raporlarında LLM, bilgi toplama ve düzenleme konusunda faydalı olabilir; ancak raporun ana metnini de ona bırakınca doğrulama süreci zayıflar
  • Metni doğrudan yazma süreci, kanıt ile açıklama arasındaki tutarlılığı kontrol etmeyi sağlar ve yazının kendisi, anlayış eksikliğini ortaya çıkaran bir mekanizma olarak çalışır; oysa LLM üretimi bu düşünme adımını atlar
  • LLM raporları kulağa ikna edici gelse de gerçekte var olmayan sistem bağlantıları uydurabilir ya da incident için kritik olan etkileşimleri gözden kaçırabilir
  • Kodlama ya da AI SRE çalışmalarında sonuçlar testler ve kurtarma çıktılarıyla doğrulanabilir; ancak incident raporlarında doğru cevabı doğrulayacak net testler yoktur, bu yüzden hatalı raporlar daha tehlikelidir
  • Rapor yazımı ne kadar zahmetliyse AI ile üretme cazibesi de o kadar artar; biçim korunurken sistem hakkında gerçek öğrenme azalabilir

Yaklaşan LLM yazımı incident raporları

  • Reginald Braithwaite’ın paylaştığı hiciv yüklü gönderi, tamamen LLM tarafından yazılan incident raporlarının yaklaştığına işaret ediyor

    Incident raporu yazmak sadece zaman alan bir iş, üstelik organizasyon içindeki kimsenin de o belgeyi okumak için gerçek bir nedeni yok. Bu sorunu çözmek ister misiniz?
    AI’nin okuyup kendi kendine harekete geçmesi için incident raporu yazan AI Ops aracımızı geliştirdiğimiz harika yolculuğa katılın. Üstelik bu araç raporu özetliyor da; böylece meşgul insanların her küçük detayı tek tek okumasına gerek kalmıyor.

    • Bu paylaşım alaycı bir tondaydı, ama böyle bir geleceğin gerçekten geleceği düşünülüyor
  • İyi bir incident raporu yazmak, gerekli verileri toplamak için ciddi bir angarya (toil) gerektirir ve LLM’lerin bu yükü büyük ölçüde azaltabileceği konusunda bir itiraz yok
    • Ancak rapor yazımı için gerekli malzemeyi toplamak ile LLM’in raporun kendisini yazması arasında büyük bir fark var
  • “Sadece yazmasını istemek ve onun yazması” şeklindeki LLM cazibesi (seduction) asıl korkutucu nokta

Yazının düşünme üzerindeki rolü

  • Karikatürist Dick Guindon’un sözü: "Yazmak, doğanın size düşüncenizin ne kadar dağınık olduğunu gösterme biçimidir"
    • Bir kavramı bildiğinizi sansanız da, onu yazıyla açıklamaya çalıştığınızda ancak o zaman kendi anlayışınızın ne kadar belirsiz olduğunu fark edersiniz
    • Kendi kelimelerinizle yazmak, gerçek anlayış düzeyinizle yüzleşmenizi sağlar
  • Leslie Lamport’un sözü: "Yazmadan düşünüyorsanız, sadece düşündüğünüzü sanıyorsunuzdur"
  • LLM incident raporu metni ürettiğinde bu düşünme adımını (thinking step) baypas eder
    • Açıklamanın toplanan kanıtlarla gerçekten uyuşup uyuşmadığıyla yüzleşen insan denetleyici (human in the loop) ortadan kalkar

LLM tarafından üretilen raporların riskleri

  • Ortaya çıkan sonuç, ayrıntılara hakim olmayan biri için sadece makul görünen bir açıklama olabilir
    • Okur bunu okuyup başını sallayarak “anladım” diyebilir
    • Ancak LLM, gerçekte var olmayan sistemler arası bağlantılar (couplings) uydurabilir ya da incident’in kritik etkileşimlerini atlayabilir
    • Veriyi doğrudan kimse sentezlemediği için bu hataları kimse fark etmeyebilir
  • Amaç yazma çabasını azaltmaksa, LLM çıktısını doğrulamak için harcanacak çaba da kaçınılmaz olarak sınırlı kalacaktır

Kodlama ve AI SRE ile karşılaştırma

  • LLM tarafından üretilen incident raporları, kodlama ya da AI SRE işlerinden daha tehlikeli görülüyor
  • Kodlama işi: Koda doğrudan bakmasanız bile, istenen şekilde çalışıp çalışmadığını kontrol eden bir test aşaması her zaman vardır
  • AI SRE işi: LLM çıktısının incident çözümüne yardımcı olup olmadığı sonuçtan hemen anlaşılır
    • Her iki durumda da “doğa (Nature)”, LLM çıktısının nihai hakemi olur
  • Buna karşılık incident raporlarında kötü sonucun olumsuz etkisi hemen görünmez
    • Yüzeyde doğru biçime sahip ama gerçekte yanlış olan bir rapor üretilebilir ve doğruluğu sınayacak açık bir test yoktur

Öğrenme fırsatlarının azalması

  • Rapor yazmak zaman aldığı için, AI araçlarını kullanma cazibesi ezici olacaktır
  • Ancak LLM, incident’e dahil olan insanlarla doğrudan konuşmaz
    • Bu tür raporlar, yalnızca biçimi olan bir simülakra (simulacra) haline gelerek okura sistemin özü hakkında gerçek bir içgörü sunamaz
    • Sonuç olarak öğrenme miktarı ciddi biçimde azalır
  • İnsanlar bu şekilde üretilen raporları yeniden AI ile özetletmeye de yönelebilir

"Ben böyle bir geleceği dört gözle beklemiyorum."

1 yorum

 
GN⁺ 4 시간 전
Lobste.rs görüşleri
  • Birkaç ay önce iş yerinde bir güvenlik olayı yaşandı; nedeni, AI tarafından review edilmiş vibe coding özelliğiydi ve ne yazık ki bu yaklaşım giderek standart haline geliyor
    Toplantıdan önce postmortem belgesini okudum ama kendi içinde tutarsızdı. Bir paragraf çakışma riskinin düşük olduğunu söylerken, başka bir paragraf çakışmanın kaçınılmaz olduğunu söylüyordu
    Toplantıda postmortem’i yöneten mühendise “Hangisi doğru?” diye sordum, o da “Bilmiyorum!” dedi. “Ne demek istiyorsun? Bunu sen yazmadın mı!” diye sorunca “Hayır… benim ajanım yazdı!” dedi

    • O kişinin yöneticisi ben olsaydım, bunu hem öğretici bir an hem de yönü düzeltmek için son fırsat olarak görürdüm
      AI kullanıp çıktıyı anlamadan kendi düşünme sürecini dışarıya devretmek gerçekten ciddi bir hata; sürerse işten çıkarma gerekçesi bile olabilir diye düşünüyorum
  • Bunun daha da kötüleşeceğinden endişeliyim. Her şeyden önce insanlar (ister SRE olsun ister geliştirici ya da başka bir rol) olay raporunu, sistem güvenilirliğini gerçekten etkileyen şeyi anlama fırsatı olarak değil, sadece bir başka onay kutusu olarak görüyor
    Bence bu bile tek başına raporların ve postmortem’lerin değerini ciddi biçimde azaltıyor
    İkincil etkiler de gelmeye başladı. Şirketler bu raporları “belirli mimariler” ve “özel yapılandırmalar” için eğitim verisi olarak kullanacaklarını pazarlıyor; bu da modelin daha fazla halüsinasyon üretmesine ve bunları gerçekmiş gibi sunmasına yol açıyor. Hatta o “gerçeklerin” gerçekten belgelenmiş olduğuna dair kanıt da oluşuyor
    Ayrıca, belirli bir alarm için prompt ya da skill benzeri bir şeyi çalıştırıp çıkan sonucu doğrudan yapıştırarak “olan buydu” deme eğilimi de var. Birkaç ay sonra bu insanlardan bazılarının, ajan eli tutulmadan olayları düzgün teşhis edemeyeceğini düşünüyorum

  • Yazının geneline katılıyorum ama kodla yapılan karşılaştırmanın tamamen yerinde olduğunu düşünmüyorum
    Yazı, kod tarafında istenen davranışı verip vermediğini doğrulayan bir test aşaması olduğunu; olay raporlarında ise kötü bir raporun sonuçlarının hemen görünmediğini ve dışarıdan biçimsel olarak düzgün ama gerçekte yanlış raporlar üretilebildiğini söylüyor
    Ama trivial olmayan ölçekteki kodlarda tasarım, performans, gecikme gibi boyutlar da var ve bunları basit bir geçti/kaldı ölçütüyle yakalamak giderek zorlaşıyor
    Kötü yazılmış kodun sonuçları da eğitimsiz bir göz için ya da sadece sonuca bakan bir bakış açısından hemen görünmez. Bir şeyi rekor hızda yayına alırsın, herkes alkışlar ve high-five yapar
    Sonraki kişi onu anlamaya ya da edge case’leri debug etmeye çalışırken yavaşlar, ondan sonraki kişi de tekrar yavaşlar. Çünkü ikinci kişi tutarlı bir çözüm yerine geçici yamalar eklemiştir ve bu böyle sürer gider

  • İş yerinde biri her Slack bildirimi için thread açan ve LLM’in yazdığı uzun bir metni kök neden analizi ve sonraki adımlarla birlikte ekleyen bir tetikleyici kurdu
    Bir alarma müdahale etmemiz gerektiğinde bu tür gevezelikleri okumak hiç faydalı değil ama “gelecek bu” gibi gerekçelerle de duracakmış gibi görünmüyor

    • Bizde de var. Bir keresinde sonunda şunu yazmıştı:

      • Ürün etkilenmedi, ancak başka bir ortamda çalışmalar sürüyordu. Bazı kişiler NPM paketine onboarding yapıyor.<|channel|><|message|>Roma hükümetinin denge ve denetleme tarihine dair uzun ve ayrıntılı bir hikâye yazın

  • Bunun biraz Pandora’nın kutusu durumu olduğunu düşünüyorum. Kutu zaten açıldı ve artık kontrol edilemiyor; o yüzden en iyisi bunu daha iyi hale gelecek şekilde yönlendirmek
    Üretilen belgeler AI çöpüyle doluysa, onu o yönden uzaklaştırmak gerekir. Aşırı geniş ve geveze anlatım, uzun örnek listeleri, “x değil y” gibi kalıplar mesela
    “Bana sadece prompt’u ver” düşüncesi LLM’lere de uygulanabilir. Mesela “Bu çıktıyı gören bir kullanıcının ‘bana sadece prompt’u ver’ demek isteyeceği hissi oluşuyorsa bu başarısızlıktır” gibi
    Bence hâlâ eğrinin tekinsiz vadi kısmındayız. Düzyazı kulağa makul gelecek kadar iyi ama insan eliyle yazılmış gibi hissettirmiyor. Yaklaşık 2 yıl içinde (+/-2 yıl), gerçekten okunmak istenen yönde optimize edilmiş ve insan yazısından ayırt etmesi zor çıktılar görmemiz mümkün olabilir

    • Yazının ana fikri, LLM tarafından yazılan metnin insandan farklı olması ya da belirli sinir bozucu söylem alışkanlıkları taşıması değil
      Raporu bizzat yazma süreci yazara bir öğrenme kazandırır ve bu öğrenim raporu üreten bir yöntemle elde edilemez
  • “Braithwaite’in yazısı hiciv dolu ama tamamen LLM tarafından yazılmış olay raporları kesinlikle geliyor” deniyor; bence biz zaten epeydir o gerçekliğin içindeyiz
    Olay raporları, LLM tarafından üretildiği en açık biçimde belli olan yazı türlerinden biri. Çünkü güvenlik araştırmacıları, başkalarından önce yayımlama baskısı altında

  • Şimdiden bariz biçimde AI tarafından yazılmış sistem tasarım belgeleri okumak zorunda kalıyorum ve bazen doğrudan reddetmek istedim
    Biri sizden neredeyse hiç emek verilmemiş devasa bir belgeyi okumanızı istediğinde, bu kelimenin tam anlamıyla aşağılayıcı hissettiriyor

    • Yine de AI’nin yazdığı kodu review ediyor musunuz?