03 Ara 2025·5 dk
Andrej Karpathy derin öğrenme: Yapay zekayı ürüne taşıma dersleri
Andrej Karpathy’nin derin öğrenme yaklaşımı, sinir ağlarını açık varsayımlar, ölçümler ve mühendislik odaklı iş akışıyla nasıl ürüne dönüştüreceğinizi gösteriyor.
Andrej Karpathy’nin derin öğrenme yaklaşımı, sinir ağlarını açık varsayımlar, ölçümler ve mühendislik odaklı iş akışıyla nasıl ürüne dönüştüreceğinizi gösteriyor.
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:
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.
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:
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.
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.
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:
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.
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.
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:
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.
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:
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:
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.
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.
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.
Ö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.
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.
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.
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.
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:
Ç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 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ı:
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ı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:
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.
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:
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ı.
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.
Çünkü demolar genellikle temiz, elle seçilmiş girdiler üzerinde hazırlanır ve değerlendirme daha çok sezgidir; oysa gerçek ürünler dağınık girdiler, kullanıcı baskısı ve tekrar eden kullanım ile karşılaşır.
Aradaki farkı kapatmak için bir girdi/çıktı sözleşmesi tanımlayın, temsil eden veride kaliteyi ölçün ve zaman aşımı veya düşük güven durumları için geri dönüş yolları tasarlayın.
Kullanıcı değerine bağlı tek bir metriği seçin ve haftalık takip edilebilir olsun. İyi varsayılanlar:
Hedeflenen "yeterli" değeri prompt'ları veya modelleri ayarlamadan önce belirleyin.
Gerçekçi şekilde gönderilebilecek en basit alternatifi kullanın:
AI ana metrikte (ve gecikme/maliyet bozulmadan) baseline'ı geçmiyorsa, henüz yayınlamayın.
Gerçek trafiğe benzeyen, sadece en iyi örneklerden oluşmayan küçük bir set tutun.
Pratik kurallar:
Bu, ilerlemeyi görünür kılar ve istemeden gerilemeleri azaltır.
Öngörülebilir, test edilebilir korumalarla başlayın:
Korumaları opsiyonel süs değil, ürün gereksinimi olarak görün.
Hem sistem sağlığını hem de çıktı kalitesini izleyin:
Ayrıca hata tekrar üretmek ve ilk desenleri düzeltmek için girdileri/çıktıları (gizlilik kontrolleri ile) loglayın.
Önceden maksimum bütçe belirleyin: hedef gecikme ve istek başı maksimum maliyet.
Sonra tahmin etmeden harcamayı düşürün:
Küçük bir kalite artışı genellikle üretimde büyük maliyet veya hız kaybına değmez.
Özelliği bir bayrak arkasında yayınlayın ve kademeli olarak dağıtın.
Pratik bir dağıtım planı:
Geri çekme başarısızlık değildir; AI'yı sürdürülebilir kılmanın parçasıdır.
Minimum rolleri kapsayın (tek kişi birden fazla şapka taksa bile):
Herkes metrikte, baseline'da ve geri çekme planında hemfikir olduğunda yaymak daha kolaydır.
Fikri hızlıca çalışan bir uygulamaya taşımak istediğinizde ama mühendislik disiplinini korumak istediğinizde kullanın.
Pratik iş akışı:
Araç hızlandırır; yine de net varsayımlar ve ölçülebilir çıktılar gerekir.