Selam arkadaşlar, yine ben.
İlk Beyefendi yazısının sonunda kendime şu soruyu bırakmıştım:
Bir sonraki sürümde neyi daha iyi yapabilirim?
Modeli bir süre kullandıktan sonra cevabın “biraz daha fazla Türkçe veri” olmadığını gördüm. Beyefendi düzgün cümleler kurabiliyor, talimatları takip ediyor ve ilk bakışta makul cevaplar verebiliyordu. Fakat mantık isteyen bir soruda bazen kestirme yola sapıyor, bazen de yanlış cevabı son derece ikna edici bir Türkçeyle sunuyordu.
Kısacası Türkçe konuşması, Türkçe muhakeme ederken güvenilir olduğu anlamına gelmiyordu.
Beyefendi 2’de hedefi bu yüzden değiştirdim: Qwen temel modelinin İngilizce görevlerdeki gücünü mümkün olduğunca korurken Türkçe ile İngilizce arasındaki farkı ölçebildiğim, eğitim ve değerlendirme hatalarını saklamadığım ve kanıtlamadığım bir başarıyı yayımlanmış gibi göstermediğim bir model yapmak istedim.
Bu uzun soluklu görevi Codex’e 26 Temmuz 2026 Pazar günü saat 15:48’de verdim ve çalışmayı 30 Temmuz Perşembe saat 15:48 itibarıyla kapattım. Yani bu ikinci Beyefendi çalışma penceresi takvim üzerinde tam 4 gün, 96 saat sürdü. Bu, bilgisayarın 96 saat kesintisiz eğitim yaptığı anlamına gelmiyor; eğitim, değerlendirme, hata ayıklama, doğrulama, bekleme ve paketleme arasında geçen gerçek takvim süresi.
Bu yazı ilk yazının devamı. Fakat baştan söyleyeyim: Bu bir “artık İngilizceyle eşit derecede zeki” zafer yazısı değil. Eğitimi tamamlanmış, dosyaları doğrulanmış ve private Hugging Face reposuna yüklenmiş gerçek bir geliştirme checkpoint’inin; geçtiği, geçemediği ve yarım bıraktığı kapılarla birlikte hikâyesi.
Önce sonuç: bugün elimde ne var?
Elimde Qwen/Qwen3.5-9B tabanının sabit bir revision’ı üzerinde eğitilmiş, 384 optimizer adımını tamamlamış bir PEFT/LoRA adapter var. Proje içindeki adı V21 S2, seçilen dosya ise checkpoint-384.
Nihai eğitim zarfı şöyle:
AlanDeğerTemel modelQwen/Qwen3.5-9BSabit revisionc202236235762e1c871ad0ccb60c8ee5ba337b9aEğitim kaydı6.266Eğitim biçimiCompletion-only QLoRAQuantization4-bit NF4, BF16 hesaplamaLoRARank 16, alpha 32Seed20260731Learning rate1e-6Optimizer adımı384Gradient accumulation8İşlenen microbatch3.072Nihai ortalama train loss0,8622880603Eğitim süresi7.791,2278 saniye — 2 saat 9 dakika 51 saniyeTepe GPU allocated / reserved17,125 / 17,448 GiBAdapter boyutu86.624.424 baytAdapter SHA-256ce3e946660cb27dca3979558b11d1ea138ce6ac3e49d9ed88f75ba0e7dc897c2
Eğitim terminal kaydı completed; adapter ve config dosyaları Safetensors ve PEFT sözleşmeleri açısından açılarak kontrol edildi. Ancak modelin son public-development değerlendirmesi dondurulmuş kalite kapılarının yalnızca 2/5’ini geçti. Protected-final hiç çalıştırılmadı ve formal bir seçim receipt’i yazılmadı.
Bu yüzden doğru adı Beyefendi v2 — V21 private development checkpoint. “Release-qualified”, “final benchmarkı geçti” veya “Türkçede İngilizce kadar zeki” demiyorum.
Bu ayrım yazının geri kalanındaki her şeyden daha önemli.
Dokuz milyar parametre neden tek başına çözüm olmadı?
İlk Beyefendi Qwen/Qwen3.5-2B üzerine kuruluydu. Bu çalışma için Qwen/Qwen3.5-9B ailesine geçtim. Daha büyük taban daha geniş kapasite, daha güçlü İngilizce davranış ve daha rahat bir LoRA çalışma alanı sağladı. Ama model boyutunu büyütmek Türkçe muhakeme farkını kendiliğinden kapatmadı.
Hatta ölçüm düzeni zayıfsa daha büyük modelin çok basit bir riski var: Daha iyi görünen, daha akıcı ve daha ikna edici yanlışlar üretebilir.
Bu nedenle V5, V6, V7, V9 ve V21 adları ürün sürümleri değil. Bunlar aynı Qwen3.5-9B tabanı çevresinde dondurulmuş farklı eğitim veya kurtarma programları. Her birinin veri, seed, optimizer adımı, loss maskesi, checkpoint kimliği ve kalite kapısı kayıt altına alındı. Bir koşu bozulduğunda aynı namespace’i sessizce değiştirip yeniden kullanmak yerine yeni kimlik açıldı.
Bu yaklaşım klasör sayısını artırdı. Buna karşılık “hangi sonuç hangi kodla, hangi veriyle ve hangi adapter’la oluştu?” sorusunun cevabını korudu.
Eğitim verisinde asıl değişiklik: 500 muhakeme örneği
Ana Qwen hattında eğitim kümesi 6.266 kayıttan oluşuyordu. V6 tanı koşuları, learning rate’i değiştirmekle Türkçe-İngilizce farkının kapanmadığını gösterdi. İngilizce tarafı büyük ölçüde korunurken Türkçe doğru sayısı istenen tabana ulaşamıyor, bazı koşullarda cevaplar belirli bir seçeneğe yığılıyordu.
V7’de satır sayısını artırmadım. 6.266 sayısını korudum; fakat Türkçe muhakeme kaynaklarından gelen 500 örneğin hedefini değiştirdim. Yalnız final cevabı öğretmek yerine doğrulanmış kaynak gerekçesi ile final cevabı birlikte korundu:
<think>
Muhakeme:
{reasoning_content}
</think>
{final_answer}
Dağılım 5.766 düz assistant hedefi ve 500 tam muhakeme izli hedefti. Bu 500 örneğin 100’ü matematik, 300’ü talimat takibi, 100’ü bilim kaynağından geldi.
Burada “modelin gerçek iç düşüncesini yakaladım” gibi bir iddiam yok. Bunlar eğitim hedefi olarak kullanılan doğrulanmış kaynak gerekçeleri. Gerekçe öğretmek modelin gerçekten daha iyi muhakeme edeceğini garanti etmez; yalnızca sınanabilir bir hipotez üretir.
Completion-only loss’ta tek tokenlık hata neden bütün koşuyu geçersiz kıldı?
Bu projede en fazla vakit alan problemlerden biri model kalitesi değil, loss’un tam olarak doğru tokenlara uygulanmasını kanıtlamaktı.
İlk V7 denemesi GPU açılmadan durdu. Genel prefix kontrolü, thinking açık örneklerle düz assistant hedeflerini aynı serialization rejiminde sınamaya çalışıyordu. İkinci deneme gerçek eğitime başladı; fakat 6.266 satırın 5.766’sında assistant sınırı bir token kayıyordu. Loss grafiği yine hareket edebilirdi, ama eğitim artık yazdığım deney değildi. Bu koşuyu sekizinci adımda bilerek iptal ettim ve kısmi checkpoint’i sonraki programa taşımadım.
Üçüncü sürüm satıra özel davranmaya başladı:
5.766 düz hedef için
enable_thinking=false500 açık muhakeme hedefi için
enable_thinking=true6.266/6.266 satırda exact completion prefix
Sıfır truncation
Maksimum tam uzunluk 896 token
Bu, modelin daha zeki olduğunun kanıtı değildi. Fakat loss’un eğitmek istediğim assistant tokenlarına uygulandığının kanıtıydı. Bence güvenilir bir model çalışmasında önce bu seviyeyi geçmek gerekiyor.
Ne tür eğitimler yaptım ve gerçekten ne kadar sürdü?
Pazar 15:48’de başlayan bu goal içindeki Qwen3.5-9B hattında, gerçek training_summary.json ve train_runtime alanıyla doğrulanabilen 17 tamamlanmış eğitim koşusu var. Toplamları 69.589,2393 saniye, yani 19 saat 19 dakika 49 saniye.
Proje klasörünün tarihsel ledger’ında goal öncesindeki ilk 2B Beyefendi hattından iki tamamlanmış koşu daha duruyor. Onları da silmeden saydığımda envanter 19 koşu ve 20 saat 9 dakika 24 saniye oluyor. Ancak bu iki eski koşuyu “Pazar günü başlayan Beyefendi 2 çalışmasında harcanmış süre” diye sunmuyorum.
Bu rakama evaluation inference, veri hazırlığı, tokenizer preflight, hash/manifest üretimi, başarısız olmadan önce eğitime hiç ulaşmayan programlar, bilerek iptal edilen kısmi koşular, kod düzeltme ve bekleme süresi dahil değil. Goal başlangıcından 30 Temmuz 15:48’deki kapanışa kadar geçen takvim süresi 96 saat.
Yani “19 saat 19 dakika tamamlanmış Qwen eğitimi” ile “96 saatlik çalışma penceresi” aynı şey değil.
Koşuları ailelerine göre topladığımda tablo şöyle:
Program ailesiTamamlanan koşuToplam süreNe için yapıldı?İlk Beyefendi 2B ana SFT + smoke200:49:34Goal öncesi tarihsel kayıt; Pazar sonrası toplama dahil değilQwen3.5-9B temel SFT100:56:23Yeni 9B taban hattını kurmakStage3A smoke200:00:14Veri ve allocator ön kontrolleriV5 tanı/full/replica710:30:09LR, replay ve seed etkisini karşılaştırmakV6 smoke + iki tanı302:04:186.266 satırlık yeni tarifin dar tanısıV7 SR + W202:32:23Muhakeme izi ve ağırlıklı curriculum hipotezleriV9 S1101:06:30Dondurulmuş S1 eğitim zarfıV21 S2102:09:51Config-loader kurtarmasıyla 384 adımlık nihai geliştirme adayıBu goal: Qwen3.5 toplamı1719:19:49Pazar 15:48 sonrası tamamlanmış Qwen hattıTarihsel ledger toplamı1920:09:24Goal öncesindeki iki 2B koşu dahil
Tam koşu dökümü de burada. Loss değerlerini farklı veri ve hedef dağılımlarında birbirleriyle doğrudan “düşük olan daha zeki” diye karşılaştırmamak gerekiyor. İlk iki satır goal öncesi tarihsel bağlam; 3–19 arasındaki 17 satır bu Pazar başlayan Qwen3.5 çalışmasına ait.
#KoşuAdımLRTrain lossSüre1İlk Beyefendi ana SFT4842e-42,244100:49:172İlk Beyefendi smoke12e-42,093700:00:173Qwen3.5-9B temel SFT1992e-51,477800:56:234Stage3A invalid-data smoke13e-61,176900:00:085Stage3A pre-allocator smoke13e-60,810000:00:076V5 tanı A — replay1255e-60,609900:33:347V5 tanı B — replay1251e-50,597300:33:468V5 tanı C — replay yok1251e-50,250300:33:209V5 full B4601e-50,570602:11:1610V5 full A4605e-60,590302:11:5711V5 replica — seed 202607294601e-50,553102:13:3912V5 replica — seed 202607304601e-50,580402:12:3813V6 smoke12e-60,483600:00:2914V6 tanı A1962e-60,877901:03:2615V6 tanı B1961e-60,941201:00:2316V7 SR1962e-50,648701:33:0517V7 W1962e-60,826900:59:1818V9 S11962e-60,847501:06:3019V21 S23841e-60,862302:09:51
Ham sayıların makinece okunabilir özeti de data-summary.json dosyasında.
Bu dört günde Codex hesabında ne kadar token göründü?
Görevi yalnız GPU saatiyle anlatmak eksik kalırdı. Bu çalışma penceresinin sonunda kayda alınan üst seviye Codex hesap sayaçları şunlardı:
Hesap metriğiKaydedilen değerLifetime tokens11,5BPeak tokens2,2BCurrent streak18 günLongest streak18 günLongest task21 saat 12 dakika
26–30 Temmuz için kayda alınan günlük hesap değerleri:
TarihGünlük hesap düzeyi token aktivitesi26 Temmuz937,1M27 Temmuz1,3B28 Temmuz1,4B29 Temmuz2,2B30 Temmuz, saat 15:48 itibarıyla385,8MGörüntülenen beş günün toplamı6,2229B
Burada özellikle dürüst bir sınır koyuyorum: Codex hesap istatistikleri tokenları görev bazında ayırmıyor. Dolayısıyla 6,2229B tokenın tamamı yalnız Beyefendi’ye harcandı diyemem. Söyleyebildiğim şey, Beyefendi 2’nin çalıştırıldığı aynı 26–30 Temmuz penceresinde hesabın günlük aktivitesinde bu toplamın görünmüş olması. Bu görev zincirinin tek parça çalışma uzunluğu açısından hesap istatistikleri ayrıca 21 saat 12 dakikalık bir “longest task” değeri gösteriyor; bunun hangi task kimliğine ait olduğu ayrıca belirtilmiyor.
V5 ve V6: skor yükselirken neden yine “başarısız” dedim?
V5’te Qwen3.5-9B tabanını, farklı learning rate ve replay tariflerini, ardından iki farklı seed replica’sını karşılaştırdım. Bazı adaylar iki dilde de tabandan daha yüksek doğru sayısına çıktı. Fakat önceden yazılmış dil farkı ve seçenek çökmesi kapıları geçilmedi.
Sonucu gördükten sonra eşiği gevşetmedim. Daha güzel görünen ikinci seed’i birincil adayın yerine koymadım. Başarısız adapter’ı sonraki programın gizli başlangıç noktası yapmadım.
V6’da 512 eşlenmiş İngilizce/Türkçe geliştirme çifti üzerinde iki dar tarif denedim. Her iki aday İngilizce tabanı yaklaşık korusa da Türkçe tabana ulaşamadı; dil farkı küçülmedi ve cevaplarda belirli seçeneğe yığılma görüldü. Bu yüzden üçüncü bir learning rate’i sonradan icat etmek yerine program failed_no_expansion ile kapandı.
Bu iki nesil bana basit bir şey öğretti: İngilizce kapasiteyi bozmamak ile Türkçe muhakeme açığını kapatmak aynı hedef değil.
V7, W ve V9: model kadar eğitim altyapısını da sınamak
V7 SR, 500 tam muhakeme izli örnek hipotezini 196 adım boyunca sınadı. Fresh-development tarafında MASSIVE ve XQuAD’ın paralel İngilizce/Türkçe sürümleri kullanıldı. Aynı prompt şablonu, aynı evaluator, greedy decoding ve thinking=false ile ölçüm yapıldı.
SR adayı toplamda İngilizce 501/512, Türkçe 486/512 doğruya ulaştı. MASSIVE tarafı ilerledi; fakat XQuAD Türkçe skoru en iyi baseline’ın bir doğru gerisinde kaldı ve XQuAD dil farkı dondurulmuş eşiği geçemedi. Bu nedenle SR seçilmedi.
Ardından aynı veri, seed, 196 adım, loss ve kalite kapılarını koruyan W kurtarması eğitildi. W, İngilizcede 500/512, Türkçede 485/512 yaptı; buna rağmen XQuAD dil farkı 6 kaldı. Kural farkın 6’dan kesin olarak küçük olmasını istiyordu. W de seçilmedi.
V9’da S1 eğitimi 196/196 adımı gerçekten tamamladı. Fakat bütün V9 programı başarıyla bitmedi: immutable training envelope, S1 tamamlandıktan sonra ve kalıcı bir S2 çıktısı oluşmadan terminal oldu. S1 adapter baytları korundu; V9 kapsamında var olmayan S2 sonradan varmış gibi anlatılmadı.
Bu aşamada çalışma bir model eğitiminden çok fail-closed altyapı programına dönüşmüştü. Parser, config türü, LOCAL_RANK, reducer şeması, adapter lineage, dataset hash’i ve response-free aggregate gibi konuların her biri ayrı namespace ve receipt ile sınandı.
V21: aynı sözleşmeyi bozmadan çalışan S2 kurtarması
V16 ve V18, S2 modelini yüklemeden önce iki farklı sözleşme hatasında durmuştu. V21 bunların sessiz retry’si değildi. Ayrı kimlikli, immutable bir kurtarma programıydı. Config yükleyici strict JSON-first çalışıyor; içerik JSON değilse YAML fallback’e geçiyordu. Veri, seed, completion-only loss, weighted-step sözleşmesi ve kalite kapıları değişmedi.
V21 384/384 optimizer adımını tamamladı. 76 gerçek log noktasından oluşturulan loss izi aşağıda:
Loss tek başına kalite kanıtı değil. Grafik, eğitimin gerçekten ilerlediğini, 384. adıma ulaştığını ve dondurulmuş zarfın içinde kaldığını gösteriyor.
Terminal stdout’sunun cevap içermeyen, blog için yeniden çizilmiş görüntüsü de adapter hash’ini, adım sayısını ve completed durumunu birlikte gösteriyor:
Son değerlendirme: 1.376 tahmin tamamlandı, formal seçim tamamlanmadı
V23 public-development yürütmesinde 1.376/1.376 inference satırı tamamlandı. Fakat inference sonrasındaki reducer aşaması eksik bir sembol nedeniyle terminal hata verdi. Bu yüzden runner formal selection receipt’i üretmedi.
Ham ve indirgenmiş dosyaların hash’leri korunarak yapılan forensik pair-level indirgeme şu sayıları verdi:
BölümİngilizceTürkçeDondurulmuş kapıBirleşik canonical321 / 344315 / 344EN ≥ 323, TR ≥ 316MASSIVE236 / 256234 / 256EN ≥ 238, TR ≥ 235XQuAD85 / 8881 / 88Dil farkı 4; gereken <3MASSIVE permütasyon249 / 256247 / 256Tanı sonucuXQuAD permütasyon88 / 8883 / 88Tanı sonucu
Birleşik dil farkı 6 ve <7 kapısını geçti. Format/runtime tarafındaki üst seviye kontrol de geçti. Fakat doğru sayıları ve XQuAD farkı dahil bütün üst kapılar birlikte değerlendirildiğinde sonuç 2/5.
Bu rakamların adı özellikle “forensik public-development sonucu”. Formal seçim değil. Protected-final çalıştırılmadı. Dolayısıyla bu yazıdan “Beyefendi 2 İngilizce zekâ seviyesine ulaştı” sonucu çıkarılamaz.
Model ilk sürümden daha büyük, eğitim hattı çok daha sıkı ve kullanılabilir bir checkpoint üretti. Ama koyduğum asıl benchmark hedefi henüz kanıtlanmadı. Eğitimi burada bitirme kararı aldıktan sonra doğru hareket, bir koşu daha başlatmak değil; mevcut en iyi tamamlanmış adayı olduğu haliyle paketlemekti.
Pazar 15:48’den Perşembe 15:48’e: 96 saatte neler oldu?
Bu Beyefendi 2 goal’ı 26 Temmuz Pazar 15:48’de başladı. Doğrulanmış private Hugging Face staging 30 Temmuz’da tamamlandı ve çalışma Perşembe 15:48’de kapatıldı. Böylece kullanıcı talebinden yazının kapanışına kadar geçen takvim penceresi tam 4 gün, yani 96 saat oldu.
Bu sürenin tamamı GPU eğitimi değildi. Büyük bölümü yanlış koşuyu erken durdurmak, veri ve tokenizer sözleşmelerini doğrulamak, tamamlanmış artefaktı yanlış evaluator’la ölçmemek, hash zincirlerini kapatmak ve sonuçları “başarılıymış” gibi göstermeyen bir yayın paketi hazırlamakla geçti.
İşin en yorucu yanı modelin iki saat eğitilmesi değil, o iki saatin gerçekten yazdığım deneye ait olduğunu ispatlamaktı.
Paketleme: yalnız adapter değil, onu açıklayan kanıtlar
Nihai paket merge edilmiş 9B temel ağırlık değil. Qwen3.5-9B’nin sabit revision’ı üzerine takılan yaklaşık 86,6 MB’lık LoRA adapter’ı. Bunun yanında:
adapter_config.jsonveadapter_model.safetensorsSabit tokenizer ve chat template dosyaları
Yerel interaktif sohbet başlatıcısı
Python dependency listesi
Lisans ve third-party notices
Vikipedi eğitim attribution kaydı
Response-free development evidence
Dosya boyutları ile SHA-256 değerlerini taşıyan immutable release manifest
pakete dahil edildi.
Yerel release manifesti add-only çalışmayı, silme yetkisi verilmediğini, private görünürlük zorunluluğunu ve public_release_qualified=false durumunu açıkça taşıyor.
Hugging Face’e nasıl gönderdim?
Paket Ibrahimsait/Beyefendi-v2 reposuna private olarak yüklendi. Repo önceden yalnız .gitattributes içeriyordu; hiçbir dosya silinmedi ve görünürlük değiştirilmedi. 14 hedef dosya tek commit ile eklendi.
Doğrulanmış commit:
08c134f1716f87cd23116642cf4d6f9480848e88
Yükleme sonrasında 14 dosyanın tamamı bu exact commit’ten yeniden stream edildi; boyut ve SHA-256 değerleri yerel paketle byte-exact karşılaştırıldı. Hugging Face, büyük tokenizer.json için .gitattributes dosyasına 51 baytlık zorunlu LFS kuralı ekledi. Bu otomatik ek de eski ve yeni hash’iyle ayrıca receipt’e yazıldı.
Gerçek private model sayfası da şu anda böyle görünüyor:
Repo private olduğu için bağlantı yalnız yetkili hesapta açılıyor: https://huggingface.co/Ibrahimsait/Beyefendi-v2.
Modeli yerelde nasıl konuşarak deneyebilirim?
Paketle birlikte gelen chat_beyefendi.py, Qwen3.5-9B’nin sabit revision’ını 4-bit NF4 olarak açıyor ve V21 adapter’ını PEFT ile bağlıyor. Tek seferlik prompt veya sürekli terminal sohbeti kullanılabiliyor.
Proje bilgisayarındaki çalışma komutu:
wsl.exe -d Ubuntu --cd /mnt/c/Users/saita/Documents/BeyefendiLLM -- `
env HF_HUB_OFFLINE=1 TRANSFORMERS_OFFLINE=1 `
TOKENIZERS_PARALLELISM=false PYTHONDONTWRITEBYTECODE=1 CUDA_VISIBLE_DEVICES=0 `
/home/saita/.cache/beyefendi-v2-venv/bin/python -B `
scripts/chat_beyefendi_v21.py `
--adapter release/final/beyefendi-v2-v21-private-development
Model yüklendikten sonra terminal Siz> istemini gösteriyor. /reset konuşma geçmişini temizliyor, /exit kapatıyor. Bu, yeni bir eğitim başlatmıyor; yalnızca dondurulmuş adapter’ı inference için yüklüyor.
Bu çalışma neyi kanıtlıyor, neyi kanıtlamıyor?
Kanıtladığı şeyler:
9B Qwen tabanı üzerinde 6.266 satırlık completion-only QLoRA eğitimi tekrarlanabilir ve 24 GB sınıfı tek GPU’da tamamlanabilir.
V21 checkpoint-384 gerçekten tamamlandı; adapter dosyaları okunuyor ve hash’leri donduruldu.
Pazar başlayan Qwen3.5 goal’ında 17 tamamlanmış koşunun doğrulanabilir eğitim süresi 19 saat 19 dakika 49 saniye.
Goal başlangıcından 30 Temmuz 15:48’deki kapanışa kadar geçen takvim penceresi 4 gün, yani 96 saat.
Aynı 26–30 Temmuz penceresi için kaydedilen toplam hesap düzeyi Codex token aktivitesi 6,2229B; hesap istatistikleri bunu görev bazında ayırmıyor.
Private Hugging Face staging 14 hedef dosya için byte-exact doğrulandı.
Model bugün yerel terminalden konuşulabilir bir geliştirme paketi halinde.
Kanıtlamadığı şeyler:
Genel zekâ veya bütün Türkçe görevlerde üstünlük.
Türkçe ve İngilizce muhakemenin eşitliği.
Protected-final başarısı.
Public, production-ready veya güvenlik açısından tamamlanmış bir release.
Daha düşük train loss’un otomatik olarak daha iyi model olduğu.
Tek seed ve tek donanım penceresindeki sonucun başka sistemlere aynen taşınacağı.
Başlangıçtaki hedefim, Qwen’in İngilizce mantık başarısını Türkçede de yakalayan bir Beyefendi yapmaktı. Bugünkü dürüst cevap şu: Bu hedefe ulaştığımı kanıtlayamadım. Fakat artık elimde “bir yerlerde duran adapter” değil; sınırları yazılmış, dosyaları doğrulanmış, private olarak arşivlenmiş ve doğrudan konuşulabilen bir model var.
Türkçe konuşmak ile Türkçe düşünmek arasındaki mesafe
İlk Beyefendi projesinde en büyük dersim veriyi açıklayabilmekti. Bu ikinci çalışmada buna bir yenisi eklendi: Sonucu açıklayabilmek.
Bir modelin düzgün Türkçe yazması kolayca etkileyici görünebilir. Bir loss grafiğinin aşağı gitmesi de insanı rahatlatabilir. Fakat model geliştirmede asıl zor sorular başka yerde:
Doğru tokenları mı eğittim? Yanlış adapter’ı mı ölçtüm? Geliştirme setine bakıp eşiği sonradan mı değiştirdim? Tamamlanmamış programı tamamlanmış mı saydım? Başarısız bir reducer’ın arkasındaki sayıları formal benchmark gibi mi sundum? Yüklediğim dosya gerçekten yerelde doğruladığım dosyayla aynı mı?
Beyefendi 2 bu soruların hepsine mükemmel cevap veren bir model olmadı. Ama projenin kendisi bu sorulardan kaçmayan bir sisteme dönüştü.
Eğitim faslı burada bitti. Bundan sonraki ilk iş yeni bir run açmak değil, modelle konuşmak, gerçek kullanım hatalarını toplamak ve bir gün yeniden eğitim yapılacaksa bugünkü public-development sonuçlarını yeni final testi gibi kullanmamak.
İlk yazının sonunda “bir sonraki sürümde neyi daha iyi yapabilirim?” diye sormuştum.
Bu defaki cevabım daha net:
Yalnızca daha iyi cevap veren bir model değil, neden o cevaba güvendiğimi gösterebildiğim bir süreç kurmalıyım.
Şimdilik kendinize iyi bakın.
I.S.A