Andrej Karpathy derin öğrenme: Yapay zekayı ürüne taşıma dersleri

Neden derin öğrenme gerçek ürünlerde genellikle zor hissedilir

Bir derin öğrenme demosu sihir gibi gelebilir. Bir model temiz bir paragraf yazar, bir nesneyi tanır veya zor bir soruyu cevaplar. Sonra o demoyu her gün insanlar tarafından basılan bir düğmeye dönüştürmeye çalışırsınız ve işler karışır. Aynı prompt farklı davranır, uç durumlar birikir ve "vay" anı destek bileti haline gelir.

Bu boşluk, Andrej Karpathy’nin çalışmalarının yapıcılar üzerinde neden etki bıraktığını açıklar. O, sinir ağlarını gizemli nesneler olarak görmek yerine tasarladığınız, test ettiğiniz ve sürdürdüğünüz sistemler olarak ele alan bir zihniyeti teşvik etti. Modeller işe yaramaz değil; ürünler sadece tutarlılık ister.

Takımlar "pratik" yapay zeka istediklerinde genellikle dört şeyi kastediyorlar:

• Tekrarlanabilir: sadece seçkin demolar değil, yaygın girdilerde de öngörülebilir davranmalı.
• Ölçülebilir: "iyi"yi his yerine sayıyla tanımlayabilmelisiniz.
• Sürdürülebilir: veri, prompt veya modeli güncellerken her şeyi bozmamalısınız.
• İşletilebilir: yayın sonrası hataları, maliyeti, gecikmeyi ve kaliteyi izleyebilmelisiniz.

Takımlar zorlanır çünkü derin öğrenme olasılıksaldır ve bağlama duyarlıdır; oysa ürünler güvenilirlik üzerinden değerlendirilir. Soruların %80'ini iyi yanıtlayan bir sohbet botu, geri kalan %20 güvenli, yanlış ve tespit edilmesi zor ise yine de bozuk hissi verebilir.

Örnek: müşteri desteği için bir "otomatik cevap" asistanı. Birkaç el ile seçilmiş ticket'ta harika görünür. Prodüksiyonda müşteriler argo yazar, ekran görüntüsü ekler, dilleri karıştırır veya politika uç durumlarını sorar. Artık korumalar, net reddetme davranışı ve taslağın gerçekten ajanta yardımcı olup olmadığını ölçme yolu gerekir.

Erken çalışmalar: sinir ağlarını sihir değil mühendislik gibi ele almak

Birçok kişi Karpathy'nin işlerini soyut matematik yerine pratik örnekler yoluyla tanıdı. İlk projeler bile basit bir noktayı vurguladı: sinir ağları, test edebileceğiniz, bozup düzeltebileceğiniz yazılım gibi ele alındığında işe yarar.

"Model çalışıyor" demekte takılmak yerine odak, onu dağınık, gerçek veride çalışır hâle getirmeye kayar. Bu, veri boru hatları, sıkıcı nedenlerle başarısız olan eğitim çalışmaları ve küçük bir şeyi değiştirince değişen sonuçlar anlamına gelir. Bu dünyada derin öğrenme mistik olmaktan çıkıp mühendislik gibi hissettirir.

Karpathy tarzı yaklaşım sır saklamakla değil, alışkanlıklarla ilgilidir:

• Basit ama yenebileceğiniz bir baz ile başlayın.
• "Daha iyi"yi belirleyen tek bir metrik seçin.
• Sonucu bilmek için bir seferde bir şeyi değiştirin.
• Sadece nihai skoru değil, hataları ve örnekleri inceleyin.

Bu temel daha sonra önem kazanır çünkü ürün AI çoğunlukla aynı oyun, sadece bahisler daha yüksek. Erken aşamada zanaatı kurmazsanız (net girdiler, net çıktılar, tekrarlanabilir çalışmalar), AI özelliği göndermek tahmin oyununa dönüşür.

Çalışan mühendisler için sinir ağlarını anlaşılır kılmak

Karpathy'nin etkisinin büyük kısmı, sinir ağlarını üzerinde akıl yürütebileceğiniz bir şey olarak ele almasıydı. Açık açıklamalar işi bir "inanış sistemi" olmaktan çıkarıp mühendisliğe dönüştürür.

Bu takımlar için önemlidir çünkü ilk prototipi gönderene genellikle onu sürdürecek kişi takip etmez. Modelin ne yaptığını açıklayamıyorsanız, muhtemelen hata ayıklayamazsınız ve kesinlikle prodüksiyonda destekleyemezsiniz.

Sürdürmeyi planlayacakmış gibi açıklayın

Erken netlik zorlayın. Özelliği inşa etmeden önce modelin ne gördüğünü, ne çıktığını ve nasıl daha iyi olduğunu anlayacağınızı yazın. Çoğu AI projesi matematikte değil, temelde başarısız olur.

Kısa bir kontrol listesi ileride işe yarar:

• Girdi ve çıktı tam olarak ne (format, sınırlar, redaksiyon)?
• Yenmeniz gereken bazeline ne (kurallar, arama, şablonlar veya daha küçük bir model)?
• "İyi" nasıl görünür (bir sayı, bir rubrik veya her ikisi)?
• Hangi hatalar kabul edilemez (güvenlik, gizlilik, marka tonu)?
• Kim sonuçları ne sıklıkla inceler?

Tekrar üretilebilirlik açıklamanın bir parçasıdır

Açık düşünce disiplinli deneylerde görünür: yeniden çalıştırılabilecek tek bir script, sabit değerlendirme veri setleri, versiyonlanmış prompt'lar ve loglanan metrikler. Baseline'lar sizi dürüst tutar ve ilerlemeyi görünür kılar.

Prototipten prodüksiyona: yayınlandığında ne değişir

Bir prototip bir fikrin işe yaradığını kanıtlar. Yayınlanan bir özellik, gerçek insanlar için, karışık koşullarda, her gün işe yaradığını kanıtlar. Bu boşluk birçok AI projesinin takıldığı yerdir.

Araştırma demosu yavaş, pahalı ve kırılgan olabilir, yetenek gösterdiği sürece. Prodüksiyon öncelikleri tersine çevirir. Sistem tuhaf girdiler, sabırsız kullanıcılar ve trafik sıçramaları olsa bile öngörülebilir, gözlemlenebilir ve güvenli olmalıdır.

Aniden önem kazanan kısıtlar

Prodüksiyonda gecikme bir özelliktir. Model 8 saniye sürerse kullanıcı vazgeçer veya düğmeye tekrar tekrar basar ve her tekrar için ödeme yaparsınız. Maliyet de ürün kararı olur çünkü küçük bir prompt değişikliği faturanızı iki katına çıkarabilir.

İzleme vazgeçilmezdir. Hizmetin çalıştığını bilmenin ötesinde, çıktının zaman içinde kabul edilebilir kalitede kaldığını bilmeniz gerekir. Veri kaymaları, yeni kullanıcı davranışları ve yukarı akış değişiklikleri performansı sessizce bozabilir.

Güvenlik ve politika kontrolleri "iyi olur"dan zorunluya geçer. Zararlı istekleri, özel verileri ve uç durumları tutarlı ve test edilebilir bir şekilde ele almalısınız.

Takımlar genellikle aynı soruları cevaplamak zorunda kalır:

• Maksimum kabul edilebilir yanıt süresi ve istek başı maliyet nedir?
• Model başarısız olduğunda veya zaman aşımına uğradığında geri dönüş ne olur?
• Kaliteyi hangi metrikler tanımlar ve hangi eşikler uyarı tetikler?
• Güvenli olmayan veya uyumsuz çıktıları nasıl önlersiniz?
• Kalite düşerse nasıl hızlı geri alırsınız?

Model becerisinden fazlası gerekir

Prototip tek kişiyle yapılabilir. Yayınlamak genellikle ürünün başarıyı tanımlaması, veri işinin girişleri ve değerlendirme setlerini doğrulaması, altyapının güvenilir çalışması ve QA'nın hata modlarını test etmesi gibi rolleri gerektirir.

"Makinemde çalışıyor" bir sürüm kriteri değildir. Bir sürüm, kullanıcılar üzerinde yük altında, loglama, korumalar ve bunun yardımcı mı yoksa zararlı mı olduğunu ölçme yolları ile çalışıyor demektir.

Mühendislik kültürü: varsayımlar, bazeline ve yineleme

Karpathy'nin etkisi sadece teknik değil, kültüreldir. O, sinir ağlarını herhangi bir mühendislik sistemi gibi inşa edip test edip geliştirebileceğiniz bir şey olarak ele aldı.

Kod yazmadan önce varsayımları yazmakla başlar. Bir özellik çalışması için neyin doğru olması gerektiğini söyleyemiyorsanız, sonra hata ayıklayamazsınız. Örnekler:

• "Kullanıcılar önerilen cevabı doğruysa ve tonlarına uyuyorsa kabul ederler."
• "800 ms altında gecikme gerekli, yoksa insanlar kullanmayı bırakır."

Bunlar test edilebilir ifadeler.

Baseline'lar sonra gelir. Baseline işe yarayabilecek en basit şeydir ve gerçeklik kontrolünüzdür. Kurallar, arama şablonu veya iyi bir UI ile "hiçbir şey yapmamak" olabilir. Güçlü baseline'lar haftalarınızı süs bir modele harcamaktan korur.

Enstrümantasyon yinelemeyi mümkün kılar. Sadece demolara bakıyorsanız, sezgilere göre yönlendirirsiniz. Birçok AI özelliği için küçük bir sayı seti ilerleyip ilerlemediğinizi söyler:

• Benimseme (kim deniyor ve kullanmaya devam ediyor)
• Kalite (kabul oranı, göndermeden önce yapılan düzenlemeler, beğeni/olumsuz oy)
• Hız (gecikme ve ilk faydalı çıktıya süre)
• Maliyet (token, compute, insan inceleme zamanı)
• Güvenlik (politika ihlalleri, hassas veri sızıntıları, jailbreak denemeleri)

Sonra sık döngülerle yineleyin. Bir şeyi değiştirin, baseline ile karşılaştırın ve ne denediğinizi ve neyin hareket ettiğini basitçe kaydedin. Gerçek ilerleme bir grafikte kendini gösterir.

Adım adım: bir AI özelliğini yayınlamak için basit bir iş akışı

AI'yı göndermek en iyi şu şekilde işler: mühendislik gibi davranın: net hedefler, bir baseline ve hızlı geri bildirim döngüleri.

1. Kullanıcı sorununu bir cümleyle belirtin. Gerçek bir kişinin söyleyebileceği şekilde yazın: "Destek ajanları yaygın sorular için cevap taslağı hazırlamakla çok zaman harcıyor." Bir cümlede söyleyemiyorsanız, özellik muhtemelen çok büyük.

2. Ölçülebilir bir çıktı seçin. Haftalık takip edebileceğiniz bir sayı seçin. İyi seçimler: görev başına kazandırılan süre, ilk taslak kabul oranı, yapılan düzenlemelerde azalma veya ticket defleksiyon oranı. İnşa etmeden önce "yeterli"nin ne olduğuna karar verin.

3. Yenmeniz gereken baseline'ı tanımlayın. Basit bir şablon, kurallara dayalı yaklaşım veya "sadece insan" ile karşılaştırın. AI ana metrikte baseline'ı geçmiyorsa, yayınlamayın.

4. Temsili verilerle küçük bir test tasarlayın. Gerçeğe uyan örnekler toplayın, dağınık vakaları dahil edin. Her gün zihinsel olarak üzerine yazmayacağınız küçük bir değerlendirme seti tutun. Geçme ve başarısızlık tanımını yazın.

5. Bayrak arkasında yayınlayın, geri bildirim toplayın ve yineleyin. Küçük bir iç grup veya kullanıcı yüzdesiyle başlayın. Girdi, çıktı ve bunun yardımcı olup olmadığı bilgisini loglayın. İlk önce en önemli hata modunu düzeltin, sonra aynı testi yeniden çalıştırın ki gerçek ilerlemeyi görün.

Taslak araçları için pratik bir desen: "göndermeye kadar geçen saniye" ve "küçük düzenlemelerle kullanılan taslakların yüzdesi"ni ölçün.

Net varsayımlar ve ölçülebilir çıktılar (ne yazmalısınız)

Birçok AI özellik başarısızlığı model başarısızlığı değildir. Aslında "başarı ne demek olduğunda anlaşamadık" başarısızlığıdır. Derin öğrenmenin pratik hissettirmesini istiyorsanız, daha fazla prompt yazmadan önce varsayımları ve ölçümleri yazın.

Özelliğinizi gerçek kullanımda bozabilecek varsayımlarla başlayın. Yaygın olanlar veriye ve insanlara dair: giriş metni tek bir dilde, kullanıcıların tek bir niyetle gelmesi, UI'nın yeterli bağlam sağlaması, uç durumların nadir olması ve dün geçerli olan desenin gelecek ay da geçerli kalacağı (drift). Ayrıca henüz ele almayacağınız şeyleri de yazın: alay, hukuki tavsiye veya uzun belgeler gibi.

Her varsayımı test edilebilir hale getirin. Faydalı format: "X varsayımı doğruysa, sistem Y yapmalı ve bunu Z ile doğrulayabiliriz." Somut tutun.

Bir sayfada yazmaya değer beş şey:

• Girdiler: modelin ne gördüğü (alanlar, sınırlar, redaksiyonlar) ve "yeterince temiz" ne demek
• Çıktı sözleşmesi: döndürmesi gereken (format, ton, izin verilen eylemler)
• Çevrimdışı değerlendirme: puanlama kurallarıyla küçük etiketli bir set (geç/kaldı + metrik)
• Çevrimiçi metrik: kullanıcıların yaptığı (kabul oranı, düzenlemeler, zaman tasarrufu, yeniden açılan ticket)
• Korumalar: ne zaman reddedeceği, soru soracağı veya daha basit bir akışa döneceği

Çevrimdışı ve çevrimiçi ölçümleri ayrı tutun. Amaç çevrimdışı metriklerin görevi öğrenip öğrenmediğini söylemesi, çevrimiçi metriklerin ise özelliğin insanlara yardımcı olup olmadığını söylemesidir. Bir model çevrimdışında iyi puan alıp yine de kullanıcıları sinirlendirebilir çünkü yavaş, aşırı emin veya önemli vakalarda yanlış olabilir.

"Yeterince iyi"yı eşikler ve sonuçlar olarak tanımlayın. Örnek: "Çevrimdışı: değerlendirme setinde en az %85 doğru; Çevrimiçi: taslakların en az %30'u küçük düzenlemelerle kabul ediliyor." Bir eşiği kaçırırsanız önceden ne yapacağınızı belirleyin: bayrak arkasında tutmak, dağıtımı düşürmek, düşük güven vakalarını şablona yönlendirmek veya durup daha fazla veri toplamak.

Takımlar AI'ı ürüne eklerken yapılan yaygın hatalar

Takımlar genellikle bir AI özelliğini normal bir UI değişikliği gibi ele alırlar: yayınla, gör ne oluyor, sonra ayarla. Bu çabuk kırılır çünkü model davranışı prompt, drift ve küçük yapılandırma değişiklikleriyle değişebilir. Sonuç, yardımcı olduğunu kanıtlayacak açık bir delil olmadan çok çaba harcanmasıdır.

Pratik kural basittir: baseline'ı ve ölçümü isimlendiremiyorsanız, henüz yayınlamıyorsunuz demektir.

En yaygın hata modları:

• Bir AI olmayan baseline olmadan başlatmak, böylece gelişim kanıtlanamaz.
• Gecikme ve maliyeti görmezden gelerek kalite peşinde koşmak (%%3'lük bir kazanç 5x yavaşlama için değmez).
• Enstrümantasyon yerine belirsiz geri bildirimlere güvenmek ("kullanıcılar seviyor").
• Gerçek trafiğe uymayan küçük veya seçilmiş bir test seti üzerinde ayar yapmak.
• Prompt veya model güncellemesi tuhaf çıktılar ürettiğinde geri çekme planı olmaması.

Somut örnek: destek cevapları için AI eklediniz. Sadece beğeni sayısını takip ediyorsanız, ajanların taslakları gözden geçirirken daha fazla zaman harcadığını veya cevapların doğru ama çok uzun olduğunu kaçırabilirsiniz. Daha iyi ölçüler "küçük düzenlemelerle gönderilenlerin yüzdesi" ve "göndermeye kadar geçen medyan süre"dir.

Yayından önce hızlı kontrol listesi

Yayın gününü bir demo değil, mühendislik devri olarak ele alın. Özelliğin ne yaptığını, nasıl işe yaradığını ve bozulduğunda ne yapacağınızı sade sözlerle açıklayabilmelisiniz.

Yayınlamadan önce emin olun ki:

• Bir paragraflık problem tanımı ve hedef kullanıcılar var.
• Ölçülmüş bir baseline (basit olsa bile) var.
• Kullanıcı değerine bağlı bir birincil çevrimiçi metrik ve girdileri, çıktıları ve sonuçları yakalayan loglar var.
• Bir güvenlik incelemesi: olası hata modları, kimlerin zarar görebileceği ve UI'nın ne yaptığı (uyarı, engelle, onay iste) var.
• Bir geri çekme planı ve sahibi: ne tetikleyince geri çekilecek ve ilk saatte ne kontrol edilecek.

Ayrıca gerçeğe benzeyen, kenar durumları içeren ve haftalar boyunca karşılaştırma yapmaya yetecek kadar stabil bir çevrimdışı değerlendirme seti tutun. Prompt, model veya veri temizliğinde değişiklik yaptığınızda aynı seti yeniden çalıştırın ve ne değiştiğini görün.

Örnek senaryo: bir AI destek taslak özelliği yayınlamak

Bir destek ekibi, ticket görünümünde cevap taslağı hazırlayan bir asistan istiyor. Ajan mesajları otomatik göndermiyor. Asistan bir taslak öneriyor, kullandığı ana noktaları vurguluyor ve ajana gönderme ve düzenleme için soruyor. Bu tek tercih riski düşük tutar ve öğrenmeyi sağlar.

Önce sayısal olarak "daha iyi" ne demek karar verin. Mevcut loglardan ilk günden ölçebileceğiniz çıktıları seçin:

• Ortalama işlem süresi (açılmadan çözülmeye kadar)
• Düzenleme oranı (ajanların taslakta ne kadar değişiklik yaptığı)
• Eskalasyon oranı (ticket'ların üst seviyelere aktarılması)
• Yeniden açılma oranı (7 gün içinde yeniden açılan ticket'lar)
• Müşteri memnuniyeti puanı (zaten takip ediyorsanız)

Modele başlamadan önce sıkıcı ama gerçek bir baseline belirleyin: kaydedilmiş şablonlar + basit bir kurallar katmanı (iade mı, kargo mu, parola sıfırlama mı tespit et ve en iyi şablonu doldur). AI bu baseline'ı geçemiyorsa hazır değil.

Küçük bir pilot çalıştırın. Birkaç ajanın isteğe bağlı kullanımına açın, önce tek bir ticket kategorisi ile sınırlayın (ör. sipariş durumu). Her taslakta hızlı bir geri bildirim isteyin: "yararlı" veya "yararlı değil" ve kısa bir neden. Sadece tıklamayı değil, ajanın neyi değiştirdiğini yakalayın.

Yayın kriterlerini önceden tanımlayın ki sonra tahminde olmayasınız. Örnek: işlem süresi %10 iyileşir, eskalasyon veya yeniden açılma oranı artmaz ve ajanlar taslakları en az %30 oranında az düzenlemeyle kabul eder.

Ayrıca geri çekme tetiklerini belirleyin: eskalasyonlarda ani artış, memnuniyette düşüş veya tekrar eden politika hataları.

Sonraki adımlar: bu dersleri bir sonraki AI sürümünüze uygulayın

2–4 hafta içinde yayınlayabileceğiniz bir AI fikri seçin. Ölçülebilir, hata ayıklanabilir ve geri çekilebilir olabilecek kadar küçük tutun. Amaç modeli zeki olduğunu kanıtlamak değil; mevcut olandan daha güvenilir şekilde bir kullanıcı sonucunu iyileştirmektir.

Fikri bir sayfa plana dönüştürün: özellik ne yapar, ne yapmaz ve nasıl çalıştığını bileceksiniz. Bir baseline ve takip edeceğiniz tam metrik dahil edin.

Hızlı uygulama için Koder.ai (koder.ai), sohbet arayüzüyle web, sunucu ve mobil uygulamalar oluşturmayı destekler; snapshot/rollback ve kaynak kodu dışa aktarma gibi derin kontrol gerektiğinde işe yarayan özellikler sunar.

Sürdürmeniz gereken alışkanlık basit: her AI değişikliği yazılı bir varsayım ve ölçülebilir bir çıktı ile gelsin. Derin öğrenme böylece sihir olmaktan çıkar, gönderebileceğiniz bir işe dönüşür.