Doğruluğun Marjinal Maliyeti

Doğruluğun marjinal maliyeti sıfıra yaklaşıyor. Bunun, yazılım mühendisliği uygulamalarınız açısından ne anlama geldiğini iyice kavramanız gerekiyor. İşleri doğru bir şekilde yapmaya takıntılı olmalısınız.

Değişen Bir Manzara

Eskiden bir mühendis, saf teknik yetenekleriyle kendini diğerlerinden ayırabilirdi: verimli algoritmik düşünme, ölçeklenebilir dağıtık sistemler, hata ayıklayıcıdaki duraklama noktalarını elle tek tek inceleme. Bu durum, giderek hızlanan bir tempoyla geçerliliğini yitiriyor. Otomatik araçlar, herkesin doğru kod yazmasını mümkün kılıyor.

Şu anda kendinizi diğerlerinden ayırt etmek için geliştirmeniz gereken en önemli beceri, bir “burun”dur: doğru olmayan şeyleri sezme yeteneği ve bunları doğru hale getirme iradesi.

Yavaş Bir API’yi Tespit Etmek

Pangram’da yeni bir model eğitiyoruz (bunu itiraf ederek çok fazla bilgi sızdırdığımı sanmıyorum) – bu model, önceki modellerimizden daha büyük, daha akıllı ve aynı zamanda *daha hızlı* olacak. Bu son üstünlük, sırf doğru yapmak için işlere takıntılı olmasaydık mümkün olmazdı. Çünkü yapabiliriz. Çünkü işimizle gurur duyuyoruz. Çünkü bir gün API’mızı test ederken “bu kesinlikle bundan daha hızlı olmalı” diye hissettim.

O zamanlar, o tavşan deliğine girmemin tam olarak nasıl bir fayda sağlayacağını bilmenin bir yolu yoktu. Elimde sadece işleri doğru yapmamız gerektiğine dair bir inanç ve Fable yanımda olduğu sürece her şeyin mümkün olduğuna dair bir inanç vardı.

Sadece birkaç gün sonra bu süreci başarıyla atlattık ve kendi ürünümüzü kullanma sürecimi zorlaştıran gecikme sorununu aştık. Fable sayesinde, karmaşık dağıtık API orkestratörümüz için tamamen yerel bir test ortamı oluşturabildim. Kodumuzdaki tüm sorunlu noktalar için hipotezler oluşturduk ve her biri için düzeltmeleri test ettik. Karmaşık Redis işlemlerini ardışık olarak düzenledik ve davranışların korunmasını doğruladık. Üretim trafiğine dayalı farklı yük modellerinin simülasyonlarını çalıştırdık ve gerekli altyapıyı tahmin ettik.

Ajanlar olmasaydı bu, savunulamaz ve önerilemez bir proje olurdu; mühendislik çalışmaları haftalar ya da aylar sürerdi. Bunun yerine, arka planda eğitim çalışmam tamamlanırken bu bir yan proje olarak yürütüldü.

Bu çabalarımızın karşılığında, GPU kullanım oranında yaklaşık 5 katlık bir artış elde ettik — %20’den (ayy!) %98’e çıktık ve iş hacmimiz de fiziksel sunucularımızla aynı seviyeye ulaştı. Bunun maliyeti bizim için çok düşüktü. Bu bize her şeyi kazandırdı. Yeni modelimizi barındırmanın maliyeti, çok pahalı olmaktan çıkıp adeta bir fırsat haline geldi.

Koku Algınızı Geliştirme

Ne yazık ki koku duyunuzu geliştirmek için tek bir kolay püf noktası yok, ancak bu, geliştirebileceğiniz bir beceridir. İşte benim için işe yarayan yöntemler (sanırım):

Ağrıya karşı dayanıklılığı düşük

Sizi sinirlendiren her şey, muhtemelen kullanıcılarınızı da sinirlendirir — bunu sadece dişinizi sıkıp atlatmaya çalışmayın. Kendinizle uyum içinde olmanız gerekir: Gün içinde size hafif bir tedirginlik veren şeylerin neler olduğuna, kod tabanının bilinçaltında kaçındığınız kısımlarına ya da yaparken biraz fazla huzursuz olduğunuz görevlere dikkat edin. İşte kazanımlar elde edilebilecek nokta budur. Benim API optimizasyonu konusundaki derinlemesine çalışmam da işte bu şekilde başladı.

“Kolay şeyler kolay olmalı” derim. Bu, hem kod tabanınız için (örneğin, basit bir eğitim ablasyonunu çalıştırmak zihinsel çaba gerektirmemelidir) hem de ürününüz için (örneğin, tek bir API çağrısı, ileri geçişin kendisinden neredeyse hiç daha yavaş olmamalıdır) geçerlidir. “Bu kadar zor olmamalı” diye düşündüğünüzde, sorunu giderin! Artık ajanlarınız var! Bir çalışma ağacı oluşturun ve Codex’i çalıştırın /hedef Hadi bakalım – ne kaybedeceksin ki?

Her şeyi temel ilkelerden yola çıkarak sorgulayın

Ajanlar bu işi çok kolaylaştırıyor. “Toplu iş boyutumuz, GPU özelliklerimiz ve parametre sayımız göz önüne alındığında bu görevin ne kadar sürmesi gerekir?” “Veri ve sorgu hacmimiz göz önüne alındığında bu sağlayıcıya ne kadar harcama yapmalıyız?” Neyin doğru olduğunu bildiğinizde, neyin yanlış olduğunu tespit etmek çok daha kolay oluyor.

Desteklediğimiz her model/düğüm/istek şekli topolojisi için bunu yapıyorum — vLLM kurulumumuzu, teorik sınıra yakın olduğumuzdan emin olmak için bu şekilde ayarlıyorum. API işleme kapasitemiz ile bir bare metal düğümde elde ettiğimiz sonuçlar arasında bir fark olduğunu da bu şekilde fark ettim.

Bu ilke, kod tabanınız için de geçerlidir. Eğer bir soyutlama size tuhaf geliyorsa, “bu işler hep böyle yürür” gibi bir cevabı öylece kabul etmeyin. Sözleşmeyi temel ilkelerden yola çıkarak yeniden düşünün — şu anda bildiklerimizi göz önünde bulundurursak, bu sözleşme nasıl olmalı? Sizin göreviniz, ajanın hangi yöne yönlendirilmesi gerektiğini belirlemektir. Ajan ise bir gecede yeniden yapılandırma işlemini gerçekleştirebilir ve doğruluğu teyit edebilir.

Meraklı olun, bol bol okuyun

Pangram’daki ilk haftamda hayata geçirdiğim en sevdiğim optimizasyonlardan biri, DeepSeek V4 hibrit seyrek dikkat mekanizmasından esinlenmişti.

Yaptığım optimizasyonun sinir ağı mimarisiyle, hele ki özellikle dikkat mekanizmasıyla hiçbir ilgisi yoktu. Bu, insan ve yapay zeka tarafından üretilen metinler arasındaki sınırları tespit etmek için kullandığımız algoritmada yapılan bir iyileştirmeydi; bu işlem eskiden sınırsız sayıda ikinci bir çıkarım aşaması gerektiriyordu.

Mümkün olduğunca çok sayıda zeki insandan olabildiğince fazla ilginç fikir toplayın. Artık sizin göreviniz, sonsuz bir merakla hareket etmek, bağlantılar kurmak ve “ya eğer…” diye sormaktır. Unutmayın, bir şeyi öğrenmenin marjinal maliyeti sıfıra yaklaşıyor.

Jetonlarınızı kullanın

Her pazar, Codex’i rastgele bir yere koyduğum bir ritüelim var /hedef Sıfırlanmadan önce haftalık jetonlarımı kullanmaya çalışmak için. Çoğu zaman kodu bir kenara atıyorum ya da unutulmuş bir taslak PR’da tozlanıyor. Bazen de karşılığını alıyorum. Bu alıştırmadan neredeyse her zaman bir şeyler öğreniyorum. Her halükarda bana hiçbir maliyeti yok. Bazıları buna slot makinesi oynamak diyor, ama ben oynamazsan kazanamazsın diyorum