Haftalık yazı

Tüm yazılar

Lore Hafta 4: veriyi türüne göre saklamak, yapay zekanın yazdığı içeriği ölçekte denetlemek ve bir ürünü veri olarak tanımlamak

Lab, haftalık yazı. Sınır: Bu sayı 2 Kasım Pazartesi 00.00 ile 8 Kasım Pazar 21.00 arasında merge edilen pull request'leri kapsıyor, İstanbul saati. Okuma zamanı: Bu kayıtları 8 Kasım Pazar günü 21.06 ile 21.07 arasında okuduk.

Soyut illüstrasyon: ikiye ayrılan bir çizgi, üç katmandan geçen kartlar ve tek bir motoru besleyen bir dosya.

Bir dakikada

Pazar 21.00 sınırına kadar bu hafta 52 pull request merge ettik. Sınav hazırlık uygulamamız Lexicon bunların 20'sini aldı, AutoReal 11, lorelabs.co 10, guno 6 ve Playables 2. Kalan 3'ü şirket içi araçlara gitti. Playables bu hafta lorelabs.co'da canlı bir ürün sayfasına dönüştü.

Bu hafta üç yeni fikir anlatmak istiyoruz:

  1. Veriyi tek bir sayıyla değil, türüne göre saklamak. Her yükleme için tek bir saklama kuralının neden uymadığını ve yerine neyin geldiğini anlatıyoruz.
  2. Yapay zekanın yazdığı içeriği ölçekte denetlemek. Üretilen 508 alıştırma kartını nasıl denetlediğimizi ve küçük bir örneklemin neyi kanıtlayıp neyi kanıtlayamadığını anlatıyoruz.
  3. Bir ürünü veri olarak tanımlamak. Tek bir sınav motorunun her sınavın yazılı tanımını nasıl okuduğunu ve yeni bir sınavın neden yeni ekranlarla değil bir dosyayla başladığını anlatıyoruz.

Bizi yeni okuyorsanız: branch'ler ve onay adımları Lore Hafta 1, CI ve kontrol dakikaları Lore Hafta 2 konusuydu. Model sağlayıcısı değiştirmek ve kullanım sınırları Lore Hafta 3 konusuydu. Burada onları tekrarlamıyoruz.

Haftamıza bir bakış

Haftaya nasıl baktık

Her depomuzda bu hafta merge edilen bütün pull request'leri listeledik, açıklamalarını okuduk. Ayrıca her ürünün state dosyasını, yani şu an neyin var olduğunu anlatan kısa belgeyi, haftanın başında ve sonunda karşılaştırdık. Bu sayım şirket içi depoları da kapsıyor, bu yüzden ana sayfamızdaki yalnızca ürünleri sayan geliştirme günlüğünden büyüktür.

Önce bir düzeltme yapıyoruz. Geçen hafta sayımı pazar akşamı erken saatte yaptık ve 66 merge bildirdik. Sayı, haftanın nerede bittiğine bağlı. Artık kullandığımız pazar 21.00 sınırıyla Lore Hafta 3'te 77 merge vardı. Takvim haftasını pazar gece yarısına kadar sayınca 88 merge çıkıyor. Bu üç sayı üç farklı zaman aralığını kapsıyor, bu yüzden bu sayıyla karşılaştırılabilecek olan yalnızca 77'dir. Bu haftadan itibaren her sayı kendi sınırını, yani pazartesi 00.00 ile pazar 21.00 arasını, ve kayıtları okuduğumuz saati ayrı ayrı söylüyor.

Fikir 1: veriyi tek bir sayıyla değil, türüne göre saklamak

Nedir? Saklama kuralı, bir ürünün müşterinin verdiği bir şeyi ne kadar süre tuttuğunu belirler. Veri korumadan gelen iki fikir burada yol gösterir: yalnızca amacın gerektirdiğini tutmak ve onu yalnızca amacın gerektirdiği süre kadar saklamak. Kişisel Verilerin Korunması Kanunu (KVKK) 4. maddesinde ikisini de genel ilkeler arasında sayar. Kanuna göre kişisel veriler "işlendikleri amaçla bağlantılı, sınırlı ve ölçülü" olmalı ve "işlendikleri amaç için gerekli olan süre kadar" muhafaza edilmelidir. Bu ilkeleri burada tasarım fikri olarak kullanıyoruz. Bu yazı hukuki görüş değildir ve bir uyum iddiası taşımaz.

Neden önemli? Bu ilkelere uymanın kolay yolu her şey için tek bir sayıdır: her yüklemeyi 30 gün sonra silmek. Bunu anlatmak da kurmak da kolaydır. Ancak tek bir sayı birbirinden çok farklı şeyleri aynıymış gibi ele alır.

Sade bir dille nasıl işler? Süreyi amaç belirler. Bir kişinin fotoğrafı kişisel veridir ve bir pazarlama gönderisi ona kısa bir süre ihtiyaç duyar. Bir logo ya da ürün fotoğrafı ise çoğu zaman marka ürünümüzü kullandığı sürece markaya hizmet eder. Bu çizgi her zaman net değildir. Bir logoda bir ad ya da yüz bulunabilir, bir ürün fotoğrafında da bir kişi görünebilir. Yani marka varlıkları da kişisel veri içerebilir. Burada yalnızca dosyanın türü değil, görüntünün ne içerdiği ve ne için kullanıldığı da önemlidir. Bu yüzden kuralı türe göre yazarız: her tür kendi amacını söyler, her amaç da kendi süresini belirler.

Bizde ne oldu? AutoReal küçük işletmeler için sosyal medya gönderileri hazırlıyor ve bu hafta işletme sahibinin kendi fotoğraflarını kullanmaya başladı. İlk plan her yüklemeyi 30 gün tutuyordu. Planı gerçek kullanımla karşılaştırınca sorun ortaya çıktı: kural her ay markanın logosunu ve ürün fotoğraflarını silecekti, işletme sahibi de onları yeniden yüklemek zorunda kalacaktı. Kuralı ikiye ayırdık. Tasarımımıza göre kişilerin fotoğrafları 30 gün sonra silinecek şekilde ayarlanıyor, logolar ve diğer marka fotoğrafları ise marka var olduğu sürece saklanıyor. Bu, iç kuralımızın tarifidir. Hukuki bir değerlendirme ya da kuralın nasıl uygulandığına dair bir kayıt değildir. Değişikliği yalnızca bir ürüne değil şirket standardımıza da yazdık, böylece bir sonraki ürün ayrılmış kuralla başlıyor.

Biz nerede duruyoruz? Türe göre yazılmış bir kural, arkasındaki ayırma adımı kadar iyidir. Bu yüzden ayırma adımının da kendi ölçümü gerekiyor ve bu iş listemizde duruyor. Aynı yönde bir not daha ekliyoruz: guno bu hafta kullanıcının sabah kurulum cevaplarını saklamaya başladığında herkese açık gizlilik sayfası da aynı hafta bunu söyleyecek şekilde güncellendi.

Bir kural ikiye ayrıldı

Fikir 2: yapay zekanın yazdığı içeriği ölçekte denetlemek

Nedir? Lexicon sözcükleri alıştırma kartlarıyla öğretiyor: bir anlam, bir örnek cümle ve sık yapılan bir hata. Her kartın ilk sürümünü bir yapay zeka modeli yazıyor. Bu hafta kullanıcılara henüz açılmamış ikinci bir sınav için 508 kart ürettik.

Neden önemli? Bir model akıcı ama yanlış bir şey öğreten bir cümle yazabilir. Tek bir yanlış kart küçük bir sorundur, ancak 508 kartı her prompt değişikliğinde tam dikkatle okumak mümkün değildir.

Sade bir dille nasıl işler? Üç katman kullandık. Önce bir model kartı yazıyor. Sonra ayrı bir model geçişi her kartı bir doğruluk kuralları listesine göre okuyor ve kartı ya düzeltiyor ya da bir kişinin karar vermesi için işaretliyor. Son olarak kartları yazmamış bir iç gözden geçiren bir örneklem okuyor. Denetleyici onaylamadan hiçbir kart uygulamaya geçemiyor, işaretli kartlar da reddediliyor.

Bizde ne oldu? İlk deneme ikinci katmana neden ihtiyaç olduğunu gösterdi. Çalışma notlarımıza göre 65 kartlık başlangıç setinde sık yapılan hata notlarının çoğu yüzde ile yüzde puanı karıştırıyordu. Dört kart da "the number of" ifadesine yüzde bağlıyordu, bu da yanlış bir İngilizce kullanımdır. Yalnızca prompt'u sıkılaştırmak, yeniden yazılan 27 kartın 10'unda yine açık bir hata bıraktı. Denetleyici devreye girdikten sonra 508 kartın 37'si olduğu gibi geçti, 471'i düzeltildi. Ardından yeni bir incelemeyle altı kart elle düzeltildi. Bu sayıları kart dosyalarının kendisinden yeniden saydık. Bundan ayrı olarak bir iç gözden geçiren 50 kartlık bir örneklem okudu, on setin her birinden 5 kart. Sınırda 1 hata bildirdi, o hata da düzeltildi. Bu, ayrıca gözden geçirilmiş bir iç örneklemdir, bağımsız bir değerlendirme değildir. Kayıtlarımız kartların tam olarak nasıl seçildiğini göstermiyor. Anlaştığımız eşik yüzde 3'ün altında bir hata oranıydı.

Başkaları ne diyor? Modeli hakem olarak kullanmak üzerine yapılan bir araştırma (Zheng ve arkadaşları, 2023), güçlü modellerin uzman tercihleriyle aşağı yukarı uzmanların birbiriyle anlaştığı kadar anlaştığını gösterdi. Aynı araştırma model hakemlerin uzun cevapları ve kendi üsluplarını kayırmak gibi bilinen eğilimleri olduğunu da gösterdi. Bu yüzden denetleyicimiz son adım değil: kartları yazmamış bir iç gözden geçiren bir örneklem okuyor.

Biz nerede duruyoruz? Küçük bir örneklemin kanıtlayamayacağı kısım şu. 50 kartta 1 hata yüzde 2 eder, ancak yalnızca 50 kartla belirsizlik geniştir. 50 kart rastgele seçilmiş olsaydı, yaklaşık yüzde 95'lik Wilson aralığı (NIST istatistik el kitabında anlatılıyor) yaklaşık yüzde 0,4 ile yüzde 10,5 arasında olurdu. Bu aralık örnekleme varsayımlarına dayanır ve gerçek hata oranı için garantili bir sınır değildir. Örneklem rastgele değilse 508 kartın tamamının hata oranını gösteremez. Yani örneklem yüzde 3 eşiğimizin altında olduğumuzu göstermiyor. Önerilen bir sonraki adım, büyüklüğü bu tür bir hesapla belirlenen daha büyük ve rastgele bir örneklemdir.

50'de 1 size ne söyler

Fikir 3: bir ürünü veri olarak tanımlamak

Nedir? Lexicon tek bir sınavla başladı ve ekranları o sınava göre yazılmıştı. Bu hafta uygulamayı her sınavın bir veri dosyasında tanımlanacağı şekilde yeniden kurduk: sınavın adı, puan ölçeği, bölümleri, alıştırma görevleri ve ona ait sözcük setleri bu dosyada duruyor. Ortak bir motor bu dosyayı okuyor. Karşılama akışı, günlük oturum ve alıştırma ekranları sınavın ayrıntılarını kendileri tutmuyor, neyi göstereceklerini motora soruyor.

Neden önemli? Bir sınavın ayrıntıları birçok ekranın içine dağılmışsa ikinci bir sınav hepsini kopyalayıp düzenlemek demektir ve kopyalar zamanla birbirinden ayrılır. Ayrıntılar tek bir dosyada durduğunda ise ikinci sınav büyük ölçüde ikinci bir dosyadır ve her ekran ikisini aynı şekilde ele alır.

Sade bir dille nasıl işler? Kod genel olarak bir sınavı nasıl çalıştıracağını biliyor. Dosya ise bu sınavın neleri içerdiğini söylüyor. Ayarlardaki kısa bir liste de kullanıcıların hangi sınavları görebileceğini belirliyor. Yeni bir sınav bu listede yokken yazılabiliyor, test edilebiliyor ve içerikle doldurulabiliyor, kullanıcılara da ancak listeye eklendiğinde ulaşıyor. Aynı fikir bu hafta daha küçük bir biçimde de görüldü. Uygulama artık desteklenen en düşük sürümünü bir ayardan okuyor. Böylece eski bir uygulama yeni bir sürüm çıkmadan kullanıcıdan güncelleme isteyebiliyor.

Bizde ne oldu? Değişikliği her biri kendi pull request'inde olan küçük adımlarla yaptık. Önce mevcut sınavın tanımını yazdık ve uygulama tamamen aynı göründü. Ardından profil alanlarını, sonra bir sınav için doğru görevi seçen sunucu yolunu, en son da ekranları grup grup taşıdık. Testler yeni ekranların metinlerini eski ekranların metinleriyle karşılaştırdı. İkinci sınav da 508 kartıyla birlikte yeni bir tanım olarak eklendi ve görünür listenin dışında kaldı.

Başkaları ne diyor? Pete Hodgson'ın Martin Fowler'ın sitesinde yayımlanan feature toggle yazısı bu tür bir anahtarı anlatıyor ve maliyetine dikkat çekiyor. Yazıya göre her toggle kodda test edilmesi ve sonra kaldırılması gereken bir koldur. Bu yüzden toggle'lar az ve kısa ömürlü olmalıdır.

Biz nerede duruyoruz? Motor ikinci sınavı başlatmayı ucuzlattı. Bedeli ise şu: ikinci sınavı henüz gerçek kullanıcılar görmedi ve kartlar gizli kaldıkça uygulamaya yaklaşık 2,1 MB ekliyor. Sınav tamamen açıldığında anahtarı kaldırmayı da unutmamamız gerekiyor.

Ne öğrendik

  1. Süreyi amaç belirler. Tek bir saklama sayısını kurmak kolaydı ama gerçek kullanıma uymadı. Kuralı türe göre yazmak sorunu çözdü, şirket standardına yazmak da bir sonraki ürünün oradan başlamasını sağlıyor.
  2. Denetleyicinin de bir denetleyicisi olmalı. İkinci model geçişi kartların çoğunu düzeltti. Ayrıca gözden geçirilen bir iç örneklem de denetleyicinin kaçırdığı bir hatayı buldu.
  3. Küçük bir örneklem bir hüküm değil kaba bir aralık verir. 50'de 1 yüzde 2 gibi görünüyor. Ancak rastgele örneklemde bile yaklaşık aralık yüzde 0,4 ile 10,5 arasındadır, rastgele olmayan bir örneklem de bütün set adına konuşamaz.
  4. Önce tanımlayın, sonra ekranları kurun. Sınavın ayrıntılarını ikinci sınavdan önce veriye taşımak, motor yeniden kurulurken ilk sınavı değiştirmeden korudu.
  5. Sayıyı aralığıyla birlikte verin. Geçen haftanın 66, 77 ve 88 sayılarının üçü de farklı aralıklar için doğru. Başlangıcı, bitişi ve okunduğu saat yazılmayan bir sayı az şey söyler.

Bundan sonra ne olacak

  • Kartlar için önerilen bir sonraki adım, büyüklüğü yukarıdaki hesapla belirlenen daha büyük ve rastgele bir örneklemdir.
  • Playables'ta markaların çalıştığı alana göre ayrılmış yeni marka işleri incelemede bekliyor.