Doğal Dil İşleme (NLP) Modelleri İçin Özel Veri Seti Hazırlama

Bir NLP projesinde model seçimine saatler ayırıp veri setini birkaç CSV dosyasından ibaret görmek, performans sorunlarının en yaygın nedenlerinden biridir. Doğal Dil İşleme (NLP) Modelleri İçin Özel Veri Seti Hazırlama süreci, modelin gerçek dünyada neyi öğrenebileceğini doğrudan belirler. On yılı aşkın yazılım ve veri projelerinde gördüğüm en net sonuç, iyi tanımlanmış ve düzenli kontrol edilen verinin çoğu zaman model mimarisinden daha fazla değer üretebildiğidir. Bu rehberde NLP modelleri için özel veri seti nasıl hazırlanır sorusunu veri toplama, temizleme, etiketleme, kalite kontrol, train-validation-test ayrımı, Türkçe metin işleme ve sürümleme başlıklarıyla ele alacağız. Ayrıca NER duygu analizi ve metin sınıflandırma için veri seti oluşturma gibi sık karşılaşılan kullanım senaryolarını gerçek proje yaklaşımıyla inceleyeceğiz.

NLP İçin Özel Veri Seti Nedir?

Özel NLP veri seti, belirli bir iş problemi, dil, sektör veya kullanıcı davranışını temsil edecek şekilde tasarlanmış metin koleksiyonudur. Bu veri yalnızca ham cümlelerden oluşmaz; etiket şeması, kaynak bilgisi, kalite ölçümü, lisans durumu ve bölme stratejisi de veri setinin parçasıdır. Hazır veri setleri hızlı başlangıç sağlar ancak çoğu zaman kurumun gerçek kullanıcı dilini tam olarak yansıtmaz. Özel veri seti, modelin eğitileceği veya değerlendirileceği gerçek kullanım dağılımına daha yakın örnekler üretmeyi hedefler. İyi hazırlanmış veri seti model performansının yanında hata analizi, güvenilirlik ve sonraki sürümlerin karşılaştırılmasını da kolaylaştırır.

Hazır Veri Seti ile Özel Veri Seti Arasındaki Fark

Hazır veri setleri genellikle akademik araştırma, ortak benchmark veya geniş kullanım amacıyla hazırlanır. Özel veri seti ise belirli kurumun, ürünün veya sektörün gerçek problemlerine göre şekillenir. Örneğin genel bir Türkçe duygu analizi veri seti, teknik destek taleplerindeki “servis yine düştü” gibi ifadeleri doğru yorumlamayabilir. Özel veri setinde bu tür örnekler gerçek üretim verisinden veya kontrollü sentetik üretimden eklenebilir. Böylece model, benchmark'ta iyi görünmek yerine gerçek iş akışında daha anlamlı sonuç üretmeye başlar.

NLP Modellerinde Veri Kalitesi Neden Model Mimarisinden Bile Kritik Olabilir?

Yanlış veya tutarsız etiketlenmiş veri, güçlü modelin bile yanlış ilişki öğrenmesine neden olabilir. Aynı intent için farklı annotator'lar farklı label kullanıyorsa modelin karar sınırı belirsizleşir. Duplicate ve leakage problemleri test skorunu yapay biçimde yükseltebilir. Eksik edge case'ler production ortamında model hatalarının hızla artmasına yol açabilir. Bu nedenle daha büyük modele geçmeden önce veri kalitesini ölçmek ve hata üreten segmentleri düzeltmek çoğu projede daha verimli bir adımdır.

Hangi Durumlarda Özel Veri Setine İhtiyaç Duyulur?

Hazır veri gerçek kullanıcı davranışını yeterince temsil etmiyorsa özel veri seti gerekir. Sektörel terimler, kurum içi intent'ler ve özel entity tipleri bu ihtiyacı artırır. Türkçe gibi morfolojik açıdan zengin dillerde genel veri setlerinin kapsamı belirli görevlerde yetersiz kalabilir. Modelin gerçek production dağılımındaki başarısının ölçülmesi için kurumun kendi test setine sahip olması da önemlidir. Özel veri seti hazırlama kararı, yalnızca veri sayısına değil mevcut verinin kullanım senaryosunu ne kadar iyi kapsadığına göre verilmelidir.

Sektöre özel terminoloji

Bankacılık, sağlık, üretim, yazılım veya hukuk gibi alanlar genel dil kullanımından farklı terimler içerir. Aynı kelime sektöre göre farklı anlam taşıyabilir ve model yanlış sınıflandırma yapabilir. Sektörel veri toplamak modelin gerçek kullanım ortamını daha iyi tanımasını sağlar. Terminoloji sözlüğü annotation guideline içine eklenebilir. Domain expert incelemesi özellikle teknik terimlerin doğru etiketlenmesinde önemli katkı sağlar.

Türkçe veya düşük kaynaklı diller

Düşük kaynaklı dillerde büyük ve dengeli veri setlerine ulaşmak daha zor olabilir. Türkçede ek yapısı ve karakter kullanımı veri çeşitliliğini ayrıca artırır. Hazır İngilizce veri setini yalnızca çevirmek aynı dil dağılımını oluşturmaz. Gerçek Türkçe kullanıcı ifadeleri, yazım hataları ve günlük dil örnekleri de bulunmalıdır. Böyle bir veri seti modelin yerel dil davranışlarını daha iyi öğrenmesine yardımcı olur.

Şirkete özel intent ve entity'ler

Her kurumun ürün, işlem ve müşteri süreçleri farklıdır. Genel intent setinde “abonelik_dondurma” veya “kurumsal_lisans_yenileme” gibi şirket özelinde gerekli sınıflar bulunmayabilir. NER tarafında kurumun ürün kodu veya dahili departman adı gibi entity tipleri gerekebilir. Bu durumda özel taxonomy hazırlanmalıdır. Production loglarından toplanan anonimleştirilmiş örnekler sınıfların gerçek kullanıcı diliyle doldurulmasını sağlar.

Hazır benchmark'ların gerçek kullanım senaryosunu temsil etmemesi

Benchmark sonuçları model karşılaştırması için yararlıdır ancak gerçek iş başarısını garanti etmez. Akademik veri setindeki metin uzunluğu, kullanıcı profilinizden tamamen farklı olabilir. Gerçek sistemde argo, kısa mesaj, yazım hatası ve code-switching görülebilir. Bu örnekler benchmark'ta bulunmuyorsa model production'da beklenmedik hatalar üretir. Kuruma özel test seti bu farkı ölçmek için gereklidir.

Veri Toplamadan Önce NLP Görevini Tanımlayın

Veri toplamaya başlamadan önce modelin hangi görevi çözeceğini açık biçimde tanımlamak gerekir. Aynı metin koleksiyonu text classification, NER ve summarization için farklı biçimde etiketlenir. Beklenen output net değilse annotation süreci kısa sürede tutarsız hale gelir. Başarı metriğinin de veri toplamadan önce seçilmesi gerekir. Bu yaklaşım gereksiz veri toplama maliyetini azaltır ve veri setinin doğrudan iş problemiyle ilişkili kalmasını sağlar.

Text Classification

Text classification bir metni önceden tanımlanmış sınıflardan birine veya birkaçına atamayı hedefler. Haber kategorisi, talep türü veya içerik konusu buna örnek olabilir. Label tanımları birbirinden açık biçimde ayrılmalıdır. Aynı metin birden fazla kategoriye ait olabiliyorsa multi-label yaklaşım düşünülmelidir. Veri seti gerçek production sınıf dağılımını ve zor ayrım yapılan örnekleri içermelidir.

Sentiment Analysis

Sentiment analysis metnin olumlu, olumsuz veya nötr gibi duygu kategorilerine ayrılmasını hedefler. Ancak ironi, bağlam ve alan özelindeki ifadeler annotation sürecini zorlaştırabilir. “Ürün hızlı geldi ama çalışmıyor” gibi karışık ifadeler için açık guideline gerekir. Aspect-based sentiment gerekiyorsa etiket şeması daha ayrıntılı tasarlanmalıdır. Duygu analizi veri setinde gerçek kullanıcı dili ve farklı ifade biçimleri dengeli biçimde temsil edilmelidir.

Intent Classification

Intent classification kullanıcının gerçekleştirmek istediği amacı belirlemeye çalışır. Chatbot ve destek sistemlerinde yaygın olarak kullanılır. Intent sınıfları iş süreçleriyle doğrudan ilişkili olduğu için şirket özelinde tasarlanması gerekir. Birbirine çok yakın intent'ler model için zor olabilir ve hard negative örnekler gerektirir. “Şifre değiştirme” ile “şifremi unuttum” gibi sınıfların guideline içinde net biçimde ayrılması önemlidir.

Named Entity Recognition (NER)

NER metin içindeki kişi, kurum, tarih, ürün veya başka özel varlıkları bulmayı hedefler. Entity sınırlarının nerede başlayıp bittiği annotation kalitesini doğrudan etkiler. “Diyarbakır Yazılım Topluluğu” tek entity olarak mı yoksa farklı parçalar halinde mi işaretlenecek önceden belirlenmelidir. Nested entity kullanılıyorsa veri formatı buna uygun seçilmelidir. NER duygu analizi ve metin sınıflandırma için veri seti oluşturma süreçleri birbirinden farklı annotation kuralları gerektirir.

Question Answering

Question answering veri seti bağlam, soru ve doğru cevap ilişkisini içerir. Extractive QA sisteminde cevabın context içindeki span bilgisi de kaydedilir. Cevaplanamaz sorular veri setine eklenerek modelin uydurma cevap üretme eğilimi ölçülebilir. Sorular yalnızca kolay ve doğrudan cümlelerden oluşmamalıdır. Gerçek kullanıcıların aynı bilgiyi farklı biçimlerde nasıl sorduğu veri setinde temsil edilmelidir.

Text Summarization

Summarization veri seti kaynak metin ile hedef özet çiftlerinden oluşur. Özetin uzunluk, ton ve bilgi kapsamı kuralları annotation guideline içinde belirtilmelidir. Farklı annotator'lar çok farklı özetler yazabileceği için kalite kontrol önemlidir. Sayısal ve kritik bilgilerin korunması ayrıca değerlendirilmelidir. Kurumsal summarization görevlerinde anonimleştirilmiş gerçek dokümanlar sentetik örneklerden daha değerli olabilir.

Machine Translation

Machine translation için kaynak ve hedef dilde hizalanmış cümle veya belge çiftleri gerekir. Çevirinin doğal ve anlam açısından doğru olması önemlidir. Sektörel terminoloji için glossary kullanılabilir. Otomatik çevrilmiş verinin insan doğrulamasından geçmesi kaliteyi artırır. Türkçe ile İngilizce arasındaki yapı farkı nedeniyle kelime kelime çeviri örnekleri model kalitesini düşürebilir.

Semantic Similarity

Semantic similarity görevinde iki metnin anlam açısından ne kadar yakın olduğu değerlendirilir. Veri seti benzer, kısmen benzer ve anlamı farklı ama kelimeleri yakın örnekler içermelidir. Kolay negatif örnekler modelin gerçek ayrım yeteneğini ölçmek için yetersizdir. Paraphrase ve hard negative örnekleri özellikle önemlidir. Annotation ölçeği binary veya sayısal skor biçiminde tasarlanabilir.

Instruction Tuning ve LLM Fine-Tuning

Instruction tuning veri seti kullanıcı talimatı ile beklenen model yanıtı arasındaki ilişkiyi öğretir. Instruction, input, output ve gerektiğinde system message alanları bulunabilir. Yanıtların yalnızca doğru değil stil ve güvenlik açısından da tutarlı olması gerekir. Aynı görevin farklı ifade edilmiş talimatları veri çeşitliliğini artırır. LLM fine-tuning verisi hazırlarken düşük kaliteli otomatik yanıtların büyük miktarda eklenmesi yerine daha küçük ama doğrulanmış örnek seti tercih edilebilir.

Göreve Göre Veri İhtiyacı Nasıl Değişir?

Her NLP görevi aynı miktarda ve aynı biçimde veri gerektirmez. Basit binary classification birkaç bin iyi örnekle anlamlı sonuç verebilirken geniş intent taxonomy daha fazla çeşitlilik ister. NER'de yalnızca toplam cümle sayısı değil her entity türünün kaç kez görüldüğü önemlidir. Summarization ve instruction tuning gibi üretim görevlerinde tek örnek hazırlama maliyeti daha yüksektir. Veri ihtiyacı model boyutu, domain çeşitliliği ve başarı hedefiyle birlikte değerlendirilmelidir.

NLP Veri Seti Tasarımına Nereden Başlanmalı?

İyi veri seti tasarımı modelin input ve output tanımından başlar. Ardından label taxonomy, edge case ve exclusion kuralları hazırlanır. Başarı metriği henüz veri toplanmadan belirlenirse hangi örneklerin daha değerli olduğu anlaşılır. Annotation guideline tasarım aşamasında oluşturulmalıdır. Bu hazırlık, daha sonra binlerce örneği yeniden etiketleme ihtiyacını ciddi biçimde azaltır.

Modelin Girdisini Tanımlayın

Modelin tek cümle, paragraf, konuşma geçmişi veya belge alıp almayacağı açık olmalıdır. Input uzunluğu veri setindeki text distribution'ı belirler. Production'da kullanıcı yazım hataları yapıyorsa training set yalnızca temiz cümlelerden oluşmamalıdır. Input içine metadata ekleniyorsa hangi alanların model tarafından görüleceği belirlenmelidir. Veri toplama sistemi bu formatı baştan koruyacak şekilde kurulmalıdır.

Beklenen Model Çıktısını Tanımlayın

Model output'u label, entity listesi, span, özet veya serbest metin olabilir. Output biçimi değerlendirme yöntemini belirler. Structured output gerekiyorsa schema veri setinde açık biçimde tanımlanmalıdır. Multi-label classification sisteminde birden fazla label aynı örnekte bulunabilir. Beklenen çıktı net değilse annotator kararları tutarsız hale gelir.

Label Taxonomy Oluşturun

Label taxonomy bütün sınıfların tanımını ve birbirleriyle ilişkisini belirler. Label isimleri kısa ama anlamı açık olmalıdır. Çok benzer sınıflar birleştirilebilir veya daha net kurallarla ayrılabilir. Hiyerarşik taxonomy gerekiyorsa ana ve alt sınıflar belirlenmelidir. Gerçek production örnekleri taxonomy tasarımını test etmek için kullanılmalıdır.

Inclusion ve Exclusion Kriterleri Belirleyin

Her veri örneğinin dataset'e alınması gerekli değildir. Çok kısa, anlamsız, izin problemi bulunan veya görevi temsil etmeyen metinler dışarıda bırakılabilir. Inclusion kriteri hangi örneklerin kabul edildiğini açıklar. Exclusion kriteri annotator'ların benzer kararlar vermesini sağlar. Bu kurallar veri kaynağı değiştiğinde yeniden gözden geçirilmelidir.

Edge Case'leri Önceden Tanımlayın

Edge case'ler modelin en çok hata yapabileceği sınır durumlarıdır. İroni, çoklu intent, eksik cümle veya code-switching buna örnek olabilir. Bu örnekler yalnızca production'da ortaya çıktıktan sonra fark edilmemelidir. Pilot annotation sırasında özellikle aranmalıdır. Edge case listesi zamanla living guideline içine eklenebilir.

Başarı Metriklerini Veri Toplamadan Önce Belirleyin

Accuracy bazı görevlerde yeterli olabilir ancak dengesiz sınıflarda yanıltıcıdır. Macro F1, per-class recall veya entity-level F1 daha anlamlı olabilir. İş açısından kritik sınıf için minimum recall hedefi tanımlanabilir. Bu hedef hangi veri segmentinin daha fazla toplanması gerektiğini gösterir. Model değerlendirme kriteri veri seti hazırlandıktan sonra değil proje başında belirlenmelidir.

NLP Verileri Nereden Toplanabilir?

NLP verileri kurum içi sistemlerden, açık veri kaynaklarından, API'lerden, web sayfalarından veya sentetik üretim yoluyla toplanabilir. Her kaynağın kalite, temsil ve lisans riski farklıdır. Şirket içi gerçek veriler kullanım senaryosunu iyi temsil eder ancak kişisel veri içerebilir. Açık veri hızlı başlangıç sağlar ancak domain uyumu kontrol edilmelidir. Veri provenance kaydı hangi örneğin nereden geldiğini izlemek için sürecin başından itibaren tutulmalıdır.

Şirket İçi Veri Kaynakları

Şirket içi kayıtlar modelin gerçek kullanıcı davranışını temsil etmesi açısından değerlidir. Destek konuşmaları, e-posta, CRM ve dokümanlar gerçek terminoloji içerir. Bu kaynaklar kullanılmadan önce erişim ve kişisel veri kuralları değerlendirilmelidir. Veriler mümkün olduğunda anonimleştirilmelidir. Kaynak sistem ve toplama tarihi metadata olarak saklanmalıdır.

Müşteri destek kayıtları

Destek kayıtları intent, sentiment ve question answering görevleri için zengin veri kaynağıdır. Kullanıcıların gerçek sorunları nasıl ifade ettiği görülebilir. Aynı ticket içinde müşteri ve destek çalışanı mesajları ayrıştırılmalıdır. Kişisel ve sipariş bilgileri temizlenmelidir. Çözülmüş ticket'lar doğru intent veya resolution label üretmek için ek sinyal sağlayabilir.

E-postalar

E-postalar kurumsal terminoloji ve doğal iletişim dili içerir. Ancak imza, quoted reply ve kişisel bilgi gibi temizlenmesi gereken alanlar bulunur. Aynı e-posta zinciri farklı örnekler halinde kullanılırsa duplicate leakage oluşabilir. Konu satırı ayrı özellik olarak değerlendirilebilir. Kullanım izni ve retention politikası veri toplama öncesinde belirlenmelidir.

Chatbot konuşmaları

Chatbot logları kullanıcıların kısa ve doğal ifadelerini içerir. Başarısız intent tahminleri yeni training data için özellikle değerlidir. Aynı kullanıcının arka arkaya yazdığı mesajlar conversation context içinde ele alınabilir. Kullanıcı ID anonimleştirilmelidir. Bot response'larının training örneği olarak kullanılması sırasında önceki model hatalarının tekrar veri setine taşınmamasına dikkat edilmelidir.

CRM kayıtları

CRM verileri müşteri talebi, işlem türü ve açıklama gibi yapılandırılmış ve metinsel alanları bir araya getirir. Mevcut kategori alanları weak supervision için başlangıç label'ı olabilir. Ancak CRM label'larının insanlar tarafından tutarlı girildiği varsayılmamalıdır. Örneklem üzerinde doğruluk kontrolü yapılmalıdır. Hassas müşteri verisi anonimleştirilmeden NLP pipeline'ına aktarılmamalıdır.

Dokümanlar

Şirket içi dokümanlar question answering, summarization ve RAG değerlendirme veri setleri için kullanılabilir. Belge sürümü ve tarih bilgisi önemlidir. Eski prosedürler güncel olmayan cevap üretimine neden olabilir. Kaynak doküman izinleri korunmalıdır. Bölüm başlığı ve sayfa bilgisi metadata olarak saklandığında error analysis daha kolay yapılır.

Açık Veri Kaynakları

Açık veri kaynakları pilot ve baseline hazırlığında önemli avantaj sağlar. Ancak her açık veri seti ticari kullanım veya yeniden dağıtım için uygun değildir. Dataset card ve lisans bilgisi incelenmelidir. Dil ve domain dağılımı kurum verisiyle karşılaştırılmalıdır. Açık veri genellikle özel veriyle birlikte kullanıldığında daha anlamlı başlangıç sağlar.

Hugging Face Datasets

Hugging Face Datasets birçok NLP veri setine ortak arayüz üzerinden erişim sağlar. Dataset card veri kaynağı, lisans ve kullanım amacı hakkında önemli bilgi sunabilir. Model training pipeline'ına doğrudan entegre edilebilir. Ancak veri setinin gerçekten gerekli lisans şartlarını taşıdığı ayrıca kontrol edilmelidir. Kuruma özel dönüştürülmüş sürüm ayrı revision altında tutulabilir.

Kaggle

Kaggle çok sayıda community dataset barındırır. Veri kaynağı ve lisans kalitesi setten sete değişebilir. Açıklaması yetersiz veri seti production training için risklidir. Duplicate veya yanlış label oranı örnekleme ile incelenmelidir. Kaggle verisi başlangıç araştırması için yararlı olsa da provenance doğrulaması yapılmadan kurumsal kullanıma alınmamalıdır.

Akademik veri setleri

Akademik veri setleri iyi dokümante edilmiş benchmark'lar sağlayabilir. Dataset oluşturma metodolojisi makaleden incelenebilir. Araştırma kullanım izni ile ticari kullanım izni aynı olmayabilir. Veri dağılımı gerçek production kullanıcılarını temsil etmeyebilir. Bu nedenle akademik benchmark yanında kurum özelinde test seti tutulmalıdır.

Kamu açık verileri

Kamu açık verileri Türkçe NLP projelerinde önemli kaynak olabilir. Karar, rapor veya istatistik metinleri belirli görevlerde kullanılabilir. Veri kullanım koşulları ve lisans yine kontrol edilmelidir. Resmi dil günlük kullanıcı dilinden farklı olduğu için domain farkı hesaba katılmalıdır. Kamu verisi tek başına müşteri destek veya sosyal medya kullanımını temsil etmez.

Web Scraping ile Metin Toplama

Web scraping metin toplamak için kullanılabilir ancak teknik olarak erişilebilir içerik otomatik olarak serbest kullanım anlamına gelmez. robots, kullanım koşulları ve telif durumu değerlendirilmelidir. Sayfa HTML'i temizlenirken asıl metin ile navigasyon içerikleri ayrıştırılmalıdır. URL ve crawl tarihi provenance kaydına eklenebilir. Veri toplama hızı siteye gereksiz yük oluşturmayacak şekilde sınırlandırılmalıdır.

API'lerden Veri Toplama

API veri toplama yapılandırılmış erişim sağladığı için scraping'e göre daha düzenli olabilir. Rate limit ve kullanım şartlarına uyulmalıdır. API response version değişiklikleri veri formatını etkileyebilir. Ham response ile temizlenmiş metin ayrı saklanabilir. API credential'ları dataset repository'sinde tutulmamalıdır.

Kullanıcı Üretimli İçerikler

Kullanıcı yorumları, forum mesajları ve sosyal medya içeriği doğal dil çeşitliliği sağlar. Yazım hatası, emoji ve argo açısından gerçek kullanım dağılımını temsil edebilir. Buna karşılık kişisel veri ve kullanım izni açısından daha yüksek risk taşır. Toxic içerik annotation ekibinin çalışma güvenliği açısından da ele alınmalıdır. Veri kullanım amacı ve saklama süresi açık biçimde belirlenmelidir.

Sentetik Veri Oluşturma

Sentetik veri az görülen sınıfları desteklemek veya özel edge case üretmek için kullanılabilir. Gerçek verinin yerini tamamen alması önerilmez. Üretim prompt'u modelin kendi dil kalıplarını veri setine taşıyabilir. İnsan doğrulaması sentetik örnek kalitesini artırır. Sentetik kaynak etiketi metadata içinde tutulmalıdır.

LLM Kullanarak Training Data Üretme

LLM belirli intent veya entity örneklerini hızlı üretmek için kullanılabilir. Few-shot prompt ile istenen stil ve sınıf açıklaması verilebilir. Çıktıların tekrar eden pattern ve yanlış label açısından incelenmesi gerekir. Aynı LLM ile üretip aynı model ailesini fine-tune etmek bias riskini artırabilir. Gerçek kullanıcı örnekleriyle karşılaştırma yapılmadan sentetik veriye yüksek ağırlık verilmemelidir.

Veri Toplama Aşamasında Hukuk, Etik ve Gizlilik

NLP veri seti oluştururken teknik kalite kadar veri kullanım hakkı ve gizlilik de önemlidir. Kişisel veri, telif hakkı ve kaynak lisansı veri toplama planının ilk aşamasında değerlendirilmelidir. Sonradan veri setinden belirli örnekleri çıkarmak provenance yoksa zorlaşır. Veri minimization yalnızca gerekli içeriğin tutulmasını sağlar. Veri güvenliği ve yerellik hakkında daha geniş bir bakış için https://www.diyarbakiryazilim.com.tr/posts/makine-ogrenimi-modellerinde-veri-guvenligi-ve-yerellik içeriği de incelenebilir.

KVKK ve Kişisel Veriler

Türkçe şirket verilerinde isim, telefon, adres veya müşteri numarası gibi kişisel bilgiler bulunabilir. Bu verilerin eğitim amacıyla kullanılması için hukuki dayanak ve amaç değerlendirilmelidir. Gerekli olmayan alanlar veri setinden çıkarılabilir. Kişisel veri bulunan dataset erişimi rol bazlı sınırlandırılmalıdır. KVKK açısından kesin uygulama kurumun veri işleme sürecine göre hukuk ve veri koruma uzmanlarıyla değerlendirilmelidir.

Personally Identifiable Information (PII)

PII bir kişiyi doğrudan veya dolaylı tanımlayabilecek bilgileri kapsar. E-posta, telefon ve açık kimlik bilgileri sık örneklerdir. Regex ve NER tabanlı PII taraması otomatik ön kontrol sağlayabilir. Otomatik sistem bütün PII türlerini yakalayamayacağı için örnek insan review yapılmalıdır. Ham ve anonimleştirilmiş dataset farklı erişim seviyelerinde tutulabilir.

Hassas Verilerin Anonimleştirilmesi

Anonimleştirme kişiyi veya hassas kaydı tanımlayan bilgilerin kaldırılmasını ya da dönüştürülmesini hedefler. İsim yerine PERSON_001 gibi placeholder kullanılabilir. Tarih veya konum bilgisi görevin gerektirdiği ölçüde genelleştirilebilir. Dönüşüm modeli öğrenilecek NLP görevini bozmamalıdır. Anonimleştirme sonrasında yeniden tanımlama riskinin düşük olduğu kontrol edilmelidir.

Telif Hakkı ve Veri Kullanım İzinleri

İnternette bulunan metnin erişilebilir olması eğitim verisi olarak sınırsız kullanılabileceği anlamına gelmez. Kaynak içeriğin lisansı ve kullanım şartları incelenmelidir. Kurum içi dokümanlarda da fikri mülkiyet sahipliği netleştirilmelidir. Veri kaynağı ve izin durumu dataset metadata'sında tutulabilir. Hukuki belirsizliği olan içerik production training setinden çıkarılabilir.

Web Scraping ve Kullanım Koşulları

Scraping öncesinde ilgili sitenin kullanım koşulları incelenmelidir. Teknik erişim ile kullanım hakkı aynı şey değildir. Rate limit ve robot politikaları dikkate alınmalıdır. Toplanan içeriğin yeniden dağıtımı ayrıca farklı haklar gerektirebilir. Kurumsal projelerde hukuk incelemesi scraping pipeline kurulmadan önce yapılmalıdır.

Dataset Lisansları

Dataset lisansı verinin nasıl kullanılabileceğini ve dağıtılabileceğini belirler. Model training, ticari kullanım ve yeniden yayınlama izinleri birbirinden farklı olabilir. Lisans metadata'sı dataset version ile birlikte saklanmalıdır. Birden fazla kaynağın birleştirildiği dataset'te lisans uyumluluğu ayrıca değerlendirilmelidir. “Açık veri” ifadesi tek başına bütün kullanım haklarını açıklamaz.

Apache

Apache lisansı genellikle geniş kullanım hakları sağlayan lisans türlerinden biridir. Ancak dataset'in gerçekten bu lisans altında yayınlandığı doğrulanmalıdır. Attribution ve notice gereksinimleri ilgili sürüme göre incelenmelidir. Model ve dataset lisansı birbirinden ayrı olabilir. Kurum hukuk ekibi production kullanımı öncesinde ilgili koşulları kontrol etmelidir.

MIT

MIT lisansı yazılım tarafında yaygın ve görece izin verici bir lisanstır. Dataset bağlamında kullanılıyorsa veriyi oluşturan tarafın gerçekten ilgili haklara sahip olup olmadığı ayrıca önemlidir. Lisans metni veri provenance kaydıyla birlikte saklanabilir. Attribution gereksinimi değerlendirilmelidir. Bir dataset'in GitHub repository'sinde MIT dosyası bulunması veri içindeki üçüncü taraf içeriğin durumunu otomatik çözmez.

Creative Commons

Creative Commons lisansları farklı koşullar içerir. BY, NC veya SA gibi ekler kullanım biçimini önemli ölçüde etkileyebilir. Ticari kullanım özellikle NC koşulunda dikkatle değerlendirilmelidir. Derivative work ve redistribution şartları da önemlidir. Dataset card'daki lisans kodu tek başına yeterli görülmeden resmi lisans metni incelenmelidir.

Ticari kullanım kısıtları

Bazı dataset'ler yalnızca akademik veya kişisel kullanım için sunulabilir. Şirket içi model geliştirme bu kapsamın dışında kalabilir. Fine-tuning ve model çıktısının ticari üründe kullanılması ayrıca incelenmelidir. Veri seti lisansı izin vermiyorsa alternatif kaynak bulunmalıdır. Lisans kontrolünü training tamamlandıktan sonra yapmak gereksiz proje riski oluşturur.

Data Provenance Neden Kaydedilmelidir?

Data provenance her örneğin hangi kaynaktan ve hangi tarihte geldiğini izlenebilir hale getirir. Lisans veya silme talebi ortaya çıktığında etkilenen örnekler bulunabilir. Model hatası belirli veri kaynağına bağlıysa analiz kolaylaşır. Sentetik ve gerçek veri birbirinden ayrılabilir. Dataset card ve versioning sistemi provenance bilgisini özetlemek için kullanılabilir.

Ham Metin Verisi Nasıl Temizlenir?

Ham metin temizleme işlemi veri kalitesini artırmayı hedefler ancak anlam taşıyan bilgiyi yok etmemelidir. Duplicate, HTML artığı, encoding sorunu ve anlamsız metinler ilk kontrol alanlarıdır. Modern transformer modellerinde agresif normalizasyon çoğu zaman gereksizdir. Temizleme adımları kod olarak sürümlenmelidir. Ham veri korunarak temizlenmiş veri yeniden üretilebilir hale getirilmelidir.

Duplicate Verilerin Temizlenmesi

Duplicate örnekler modelin bazı metinleri gereğinden fazla öğrenmesine neden olabilir. Aynı örnek train ve test setine düşerse değerlendirme skoru yapay biçimde yükselir. Exact duplicate ilk aşamada kolayca bulunabilir. Near ve semantic duplicate kontrolleri daha gelişmiş benzerlik yöntemleri gerektirir. Duplicate temizliği split işleminden önce yapılması gereken temel kontrollerden biridir.

Exact duplicate

Exact duplicate birebir aynı metnin veri setinde birden fazla kez bulunmasıdır. Normalize edilmiş text hash değeri kullanılarak hızlı tespit edilebilir. Label'lar farklıysa veri kalitesi problemi ayrıca incelenmelidir. Bir örneğin hangi kayıttan tutulacağı provenance bilgisine göre belirlenebilir. Duplicate rate kalite dashboard'unda takip edilebilir.

Near duplicate

Near duplicate küçük yazım veya format farkları bulunan büyük ölçüde aynı metinlerdir. Noktalama ve whitespace farkı klasik exact hash yöntemini aşabilir. Karakter veya token tabanlı benzerlik metrikleri kullanılabilir. Aynı e-posta zincirinin farklı imzalarla kaydedilmiş kopyaları buna örnektir. Near duplicate leakage test skorunu ciddi biçimde etkileyebilir.

Semantic duplicate

Semantic duplicate kelimeler farklı olsa bile anlam olarak çok yakın örnekleri ifade eder. Embedding similarity bu örnekleri bulmak için kullanılabilir. Aynı kullanıcı sorusunun farklı paraphrase biçimleri tamamen duplicate sayılmayabilir, bu nedenle threshold dikkatle seçilmelidir. Test setinde train örneklerine çok yakın semantic kopyalar varsa değerlendirme zorlaşır. İnsan örneklemesi otomatik similarity sonuçlarını doğrulamak için yararlıdır.

HTML ve Markdown Kalıntılarının Temizlenmesi

Web veya doküman kaynaklarında HTML tag ve Markdown işaretleri metne karışabilir. Görev bu format bilgisini kullanmıyorsa gereksiz kalıntılar temizlenebilir. Link text'i anlam taşıyorsa korunmalıdır. Kod blokları teknik destek veya coding dataset'inde önemli olabilir ve kaldırılmamalıdır. Temizleme kuralı veri kaynağı ve NLP görevine göre belirlenmelidir.

URL ve E-posta Adreslerinin Yönetilmesi

URL ve e-posta adresleri bazı görevlerde entity veya güvenlik sinyali olabilir. Bu nedenle otomatik olarak silmek yerine placeholder ile değiştirmek daha uygun olabilir. PII amacıyla e-posta adresleri anonimleştirilebilir. URL domain bilgisi classification için önemliyse kontrollü biçimde korunabilir. Normalizasyon kararı modelin hedef görevine bağlıdır.

Emoji ve Özel Karakterlerin Yönetilmesi

Emoji özellikle sentiment ve sosyal medya verilerinde güçlü anlam taşır. Olumlu veya olumsuz duygu sinyali tamamen kaybolmamalıdır. Bazı modeller emoji token'larını doğrudan işleyebilir. Bozuk veya anlamsız kontrol karakterleri ise temizlenebilir. Özel karakterleri topluca silmek modern NLP projelerinde çoğu zaman gereksiz bilgi kaybı oluşturur.

Gereksiz Whitespace ve Satır Sonları

Fazla boşluk ve anlamsız satır sonları text normalization sırasında azaltılabilir. Ancak paragraf ayrımı summarization ve document task'lerinde bilgi taşıyabilir. Birden fazla boşluk tek boşluğa dönüştürülebilir. Kod veya tablo içeren metinlerde whitespace yapısı korunmalıdır. Temizleme işlemi görev bazında uygulanmalıdır.

Encoding Problemleri

Türkçe karakterlerin bozuk görünmesi encoding hatasının güçlü göstergesidir. UTF-8 standardizasyonu çoğu pipeline için iyi başlangıçtır. “Ä°” veya benzeri bozulmuş karakterler kaynak encoding yanlış yorumlandığında ortaya çıkabilir. Veriyi sessizce dönüştürmek yerine bozuk kayıt sayısı raporlanmalıdır. Encoding sorunu kaynak sistem seviyesinde çözülebiliyorsa en doğru yaklaşım budur.

Bozuk veya Eksik Metinlerin Filtrelenmesi

Boş, anlamsız veya yalnızca sistem mesajı içeren kayıtlar training'e değer katmaz. Minimum uzunluk kuralı uygulanabilir ancak kısa intent örnekleri yanlışlıkla silinmemelidir. Eksik source veya label bilgisi olan kayıtlar ayrı kalite kuyruğuna alınabilir. Filter edilen örnek sayısı raporlanmalıdır. Çok yüksek filter oranı veri toplama pipeline'ında sorun olduğunu gösterebilir.

Toxic ve Zararlı İçeriklerin Yönetimi

Toxic içerik bazı görevlerde modelin gerçek kullanım ortamını temsil edebilir. Tamamen silmek modelin kötüye kullanım örneklerini tanımamasına neden olabilir. Bununla birlikte annotator güvenliği ve psikolojik yükü dikkate alınmalıdır. Hassas içerik için özel erişim ve işaretleme yöntemi uygulanabilir. Veri setinde tutulup tutulmayacağı kullanım amacı ve güvenlik politikasına göre belirlenmelidir.

NLP İçin Metin Normalizasyonu

Metin normalizasyonu her projede aynı kuralların uygulanacağı mekanik bir işlem değildir. Lowercase, noktalama silme ve stemming gibi klasik adımlar modern transformer modellerinde her zaman gerekli değildir. Fazla normalizasyon modelin gerçek kullanıcı girdisini görmesini engelleyebilir. Eğitim ve production preprocessing aynı olmalıdır. Her dönüşümün performans etkisi ablation testiyle ölçülebilir.

Lowercase Yapılmalı mı?

Lowercase kararı kullanılan model ve göreve göre verilmelidir. Cased model kullanılıyorsa büyük harf bilgisi önemli olabilir. Türkçede “I” ve “İ” dönüşümleri locale açısından ayrıca dikkat gerektirir. NER görevinde büyük harf entity sinyali taşıyabilir. Varsayılan olarak bütün metni lowercase yapmak yerine tokenizer ve model tasarımına uygun davranmak daha sağlıklıdır.

Noktalama İşaretleri Silinmeli mi?

Noktalama işaretleri cümle yapısı, duygu ve anlam hakkında bilgi taşır. Sentiment analizinde “!” veya “?” önemli sinyal olabilir. Transformer tokenizer'lar noktalama işaretlerini işleyebilir. Gürültü oluşturan özel durumlar ayrı temizlenebilir. Bütün noktalama işaretlerini silmek modern NLP pipeline'ında çoğu zaman gerekli değildir.

Stop Words Silinmeli mi?

Klasik bag-of-words sistemlerinde stop word temizliği faydalı olabilir. Transformer tabanlı modeller bağlam ilişkisini kullandığı için stop word'leri silmek cümle anlamını bozabilir. Negation içeren kısa kelimeler özellikle önemlidir. “Bu ürün iyi değil” örneğinde “değil” kelimesini kaldırmak duygu etiketini tersine çevirebilir. Bu nedenle stop word temizliği model türüne göre test edilmelidir.

Stemming ve Lemmatization Gerekli mi?

Stemming ve lemmatization klasik NLP sistemlerinde vocabulary boyutunu azaltmak için kullanılır. Modern subword tokenizer'lar morfolojik çeşitliliği farklı biçimde yönetir. Türkçede yanlış kök bulma anlam kaybına neden olabilir. Transformer fine-tuning için çoğu zaman ham kelime biçimini korumak daha uygundur. Geleneksel model kullanılıyorsa etkisi validation set üzerinde ölçülebilir.

Modern Transformer Modellerinde Aşırı Temizleme Neden Zararlı Olabilir?

Transformer modelleri noktalama, büyük harf ve kelime biçimlerinden bağlam bilgisi öğrenebilir. Bu işaretleri kaldırmak training ile gerçek kullanıcı girdisi arasında dağılım farkı oluşturur. Sosyal medya dilindeki emoji ve tekrarlar duygu sinyali taşıyabilir. Temizleme yalnızca açık teknik gürültüyü hedeflemelidir. Daha fazla preprocessing her zaman daha iyi model anlamına gelmez.

Türkçe NLP Veri Setlerinde Özel Dikkat Gerektiren Noktalar

Türkçe eklemeli dil yapısı, karakter özellikleri ve günlük kullanım çeşitliliği nedeniyle veri hazırlamada özel dikkat ister. İngilizce için hazırlanmış preprocessing kuralını doğrudan Türkçeye uygulamak hatalı sonuç üretebilir. I, İ, ı ve i dönüşümleri en sık görülen teknik problemlerden biridir. Yazım hataları ve code-switching gerçek kullanıcı verisinde sık görülür. Türkçe özel veri seti hazırlama süreci bu çeşitliliği koruyarak modelin gerçek kullanım ortamını öğrenmesini sağlamalıdır.

Türkçenin Eklemeli Dil Yapısı

Türkçede kelime köklerine çok sayıda ek gelebilir ve tek kelime uzun anlam dizisi taşıyabilir. Bu durum vocabulary ve tokenization davranışını etkiler. Aynı intent farklı ek kombinasyonlarıyla ifade edilebilir. Veri seti yalnızca sözlük biçimindeki kelimelerden oluşmamalıdır. Subword tokenizer seçimi Türkçe üzerinde ayrıca test edilmelidir.

I/ı ve İ/i Problemi

Türkçe büyük ve küçük harf dönüşümü İngilizce locale kurallarından farklıdır. “I” karakterinin küçüğü “ı”, “İ” karakterinin küçüğü “i” olmalıdır. Standart yazılım fonksiyonları yanlış locale ile kullanıldığında veri bozulabilir. Bu durum entity ve kelime eşleşmesini etkiler. Text normalization pipeline Türkçe locale testleri içermelidir.

Cased ve Uncased Veri Hazırlama

Cased model büyük harf bilgisini korur ve NER gibi görevlerde avantaj sağlayabilir. Uncased model farklı yazım biçimlerine karşı daha dayanıklı olabilir. Ancak Türkçe karakter dönüşümleri doğru yapılmalıdır. Veri setinin production girişini temsil etmesi en önemli kriterdir. Model karşılaştırması aynı test seti üzerinde yapılmalıdır.

Türkçe Karakterlerin Korunması

ç, ğ, ı, İ, ö, ş ve ü karakterleri anlam taşıyan normal Türkçe karakterlerdir. ASCII dönüşümü bazı kelimeleri belirsiz hale getirebilir. Kullanıcı gerçekten “cagri” yazıyorsa bu örnek ayrıca bulunabilir ancak temiz “çağrı” metni zorla ASCII'ye çevrilmemelidir. Encoding pipeline bu karakterleri eksiksiz korumalıdır. Character corruption kalite testleriyle otomatik tespit edilebilir.

Yazım Hataları

Gerçek kullanıcılar mobil cihaz ve hızlı mesajlaşma nedeniyle yazım hataları yapar. Training set tamamen düzeltilmiş metinden oluşursa model production'da zorlanabilir. Orijinal ve normalize edilmiş metin ayrı alanlarda tutulabilir. Bazı hatalar sentetik olarak üretilebilir. Ancak sentetik typo dağılımı gerçek kullanıcı verisiyle karşılaştırılmalıdır.

Argo ve Günlük Dil

Argo ve günlük konuşma intent veya sentiment üzerinde güçlü anlam taşır. Kurumsal chatbot gerçek kullanıcı mesajlarını alıyorsa bu ifadeleri tamamen temizlemek doğru değildir. Annotation guideline saldırgan veya argo ifadelerin nasıl etiketleneceğini açıklamalıdır. Annotator güvenliği için içerik uyarısı kullanılabilir. Veri seti resmi Türkçe ile günlük Türkçe arasında dengeli kapsama sahip olmalıdır.

Sosyal Medya Türkçesi

Sosyal medya metinlerinde kısaltma, emoji, tekrarlı harf ve noktalama kullanımı yaygındır. “çoook iyi” gibi ifadeler sentiment açısından güçlü sinyaldir. Kullanıcı adları ve URL'ler anonimleştirilebilir. Hashtag'lerin anlam taşıyıp taşımadığı göreve göre değerlendirilmelidir. Sosyal medya verisiyle eğitilen model normal kurumsal metne taşınırken domain farkı ölçülmelidir.

Code-Switching

Türkçe kullanıcılar teknik ve günlük konuşmalarda sıkça İngilizce kelimeler kullanabilir. “Deploy sonrası servis crash oldu” gibi cümleler yazılım ekiplerinde normaldir. Bu örnekleri temizlemek gerçek dağılımı bozabilir. Model tokenizer'ının iki dili de yeterli biçimde desteklemesi gerekir. Code-switching oranı dataset statistics içinde raporlanabilir.

Türkçe-İngilizce karışık metinler

Türkçe-İngilizce karışık metinler özellikle teknoloji ve iş dünyasında sık görülür. Entity ve intent annotation kuralları bu tür cümleleri kapsamalıdır. İngilizce teknik terimler Türkçeye zorla çevrilmemelidir. Gerçek kullanım oranı train ve test setlerinde benzer tutulabilir. Language detection sistemi bu metinleri tek dil olarak yanlış filtrelememelidir.

Bölgesel Dil Kullanımı ve Diyalektler

Bölgesel ifadeler modelin farklı kullanıcı gruplarını anlamasını etkileyebilir. Yalnızca standart İstanbul Türkçesine benzer metinlerle eğitim yapmak coverage boşluğu oluşturabilir. Diyalekt verisi toplanırken kullanıcı gizliliği ve temsil dengesi önemlidir. Annotation guideline yerel ifadelerin standart anlamını açıklayabilir. Diyarbakır ve çevresinde kullanılabilecek yerel ifade veri setleri topluluk projeleri için de değerli bir çalışma alanı sunar.

Sektöre Özel Türkçe Terminoloji

Sektörel terimler çoğu genel dil modelinde farklı anlamda yorumlanabilir. Finans, hukuk, sağlık ve yazılım alanlarında Türkçe ile İngilizce terimler sık karışır. Terminoloji sözlüğü annotation sürecine dahil edilmelidir. Domain expert belirli örneklerde final karar verebilir. Model evaluation seti sektörün en kritik terimlerini içermelidir.

NLP Verisi Nasıl Etiketlenir?

Doğal dil işleme için metin verisi toplama temizleme ve etiketleme süreci veri setinin güvenilirliğini doğrudan belirler. Manuel annotation yüksek kalite sağlar ancak maliyetlidir. Model-assisted veya LLM-assisted yöntemler annotator hızını artırabilir. Weak supervision büyük hacimli kaba label üretmek için kullanılabilir. En iyi sonuç çoğu projede human-in-the-loop ve ölçülebilir kalite kontrolün birlikte kullanılmasından gelir.

Manual Annotation

Manual annotation insan annotator'ın örneği okuyup guideline'a göre label vermesidir. Karmaşık bağlam ve domain bilgisi gereken görevlerde güçlü yöntemdir. İnsan hatası ve subjektif kararlar yine mümkündür. Double annotation ve agreement ölçümü kaliteyi artırır. Annotator eğitimi veri seti hazırlama maliyetinin önemli bölümüdür.

Model-Assisted Annotation

Model-assisted annotation mevcut baseline modelin tahminini annotator'a öneri olarak sunar. İnsan doğruysa onaylar, yanlışsa düzeltir. Bu yöntem kolay örneklerde annotation hızını artırabilir. Annotator'ın model önerisine aşırı güvenmesi bias oluşturabilir. Belirli oranda prediction gizlenerek bağımsız kalite kontrol yapılmalıdır.

LLM-Assisted Annotation

LLM-assisted annotation label tanımı ve örneklerle büyük dil modelinden ön etiket üretmeyi kullanır. Karmaşık metinlerde açıklama üretmesi annotator kararını kolaylaştırabilir. Ancak LLM'in güvenilirliği label ve domain'e göre değişir. High confidence tahminler bile örneklem insan review'dan geçmelidir. LLM çıktısı nihai ground truth olarak otomatik kabul edilmemelidir.

Weak Supervision

Weak supervision kural, sözlük veya mevcut sistem sinyallerini kullanarak programatik label üretir. CRM kategorisi veya keyword rule başlangıç etiketi sağlayabilir. Bu label'lar gürültülü olabilir ve quality estimation gerekir. Büyük hacimde data bootstrap etmek için değerlidir. Daha küçük golden dataset ile weak label kalitesi ölçülebilir.

Active Learning

Active learning modelin en belirsiz veya en bilgilendirici örneklerini annotator'a gönderir. Böylece her örneği etiketlemek yerine en değerli veriye odaklanılır. Low-confidence prediction ve decision boundary yakınındaki örnekler seçilebilir. Production model geliştirme döngüsünde maliyeti azaltabilir. Selection bias oluşmaması için rastgele örnekler de kalite kontrol amacıyla tutulmalıdır.

Human-in-the-Loop Yaklaşımı

Human-in-the-loop otomasyon ile insan kararını birleştirir. Model kolay örnekleri ön etiketler, insan zor veya kritik örnekleri inceler. Domain expert yalnızca anlaşmazlık veya yüksek riskli sınıflarda devreye girebilir. Bu yapı annotation maliyetini kontrol altında tutarken kaliteyi korur. Workflow ve escalation kuralları baştan tanımlanmalıdır.

Annotation Guideline Nasıl Hazırlanır?

Annotation guideline annotator'ların aynı metin için benzer karar vermesini sağlayan temel dokümandır. Her label'ın tanımı, olumlu ve olumsuz örnekleri bulunmalıdır. Boundary case ve kararsız durumlar açıkça açıklanmalıdır. Guideline ilk günden mükemmel olmak zorunda değildir ve pilot annotation ile geliştirilir. Yaşayan doküman yaklaşımı yeni edge case'lerin sürece eklenmesini sağlar.

Her Label'ın Açık Tanımını Yazın

Label tanımı kısa ama ayırt edici olmalıdır. Benzer sınıflar arasındaki fark özellikle açıklanmalıdır. Tanım iş ekibi ve annotator tarafından aynı şekilde anlaşılmalıdır. Bir label başka label'ın alt kümesi gibi görünüyorsa taxonomy yeniden değerlendirilebilir. Belirsiz label doğrudan düşük agreement üretir.

Pozitif Örnekler Ekleyin

Pozitif örnek annotator'a label'ın hangi durumlarda uygulanacağını gösterir. Farklı cümle uzunluğu ve ifade biçimleri seçilmelidir. Yalnızca kolay örnekler guideline'ın gerçek değerini düşürür. Argo ve yazım hatası gibi production örnekleri de bulunabilir. Her önemli alt kullanım için birkaç temsilci örnek eklenmelidir.

Negatif Örnekler Ekleyin

Negatif örnek label'ın hangi benzer durumlarda kullanılmaması gerektiğini açıklar. Özellikle birbirine yakın intent'lerde çok değerlidir. “Şifre değiştirme” label'ı için “şifremi unuttum” negatif örnek olabilir. Bu yaklaşım decision boundary'yi annotator açısından netleştirir. Hard negative örnekler zamanla guideline'a eklenebilir.

Boundary Case'leri Belirleyin

Boundary case iki veya daha fazla label arasında kalan örneklerdir. Bu tür örnekler annotation anlaşmazlığının ana kaynağı olabilir. Guideline öncelik veya tie-break kuralı tanımlayabilir. Gerekirse yeni “other” veya multi-label yaklaşımı düşünülmelidir. Boundary case sayısı taxonomy kalitesi hakkında sinyal verir.

Kararsız Durumlar İçin Kurallar Tanımlayın

Annotator bazı örneklerde yeterli bağlam bulamayabilir. Tahmin yapmak yerine “uncertain” veya review flag mekanizması kullanılabilir. Bu örnekler adjudication kuyruğuna gönderilir. Zorunlu label verme hatalı ground truth üretir. Uncertain oranı yüksekse guideline veya taxonomy yeniden tasarlanmalıdır.

Guideline'ı Pilot Annotation ile Test Edin

Pilot aşamada birkaç annotator aynı yüzlerce örneği bağımsız etiketleyebilir. Agreement metriği sorunlu label'ları gösterir. Tartışmalı örnekler üzerinden guideline güncellenir. Ana annotation başlamadan önce bu iterasyon birkaç kez yapılabilir. Küçük pilot maliyeti binlerce hatalı etiketi sonradan düzeltmekten daha düşüktür.

Living Guideline Yaklaşımı

Production verisi yeni ifade ve edge case'ler getirdikçe guideline güncellenmelidir. Her değişikliğin version ve tarih bilgisi tutulmalıdır. Eski dataset hangi guideline version ile etiketlendiği bilgisini taşımalıdır. Büyük kural değişikliği eski label'ların yeniden değerlendirilmesini gerektirebilir. Guideline değişiklik günlüğü annotator eğitiminde kullanılabilir.

NLP Görevlerine Göre Etiket Formatları

Veri formatı NLP görevinin label yapısını eksiksiz taşımalıdır. Classification için text ve label yeterli olabilirken NER token veya span bilgisi ister. QA veri setinde context, question ve answer span gerekir. Instruction tuning conversation formatı kullanabilir. Format seçimi training framework ve annotation aracının desteğiyle birlikte düşünülmelidir.

Text Classification Dataset Formatı

Text classification veri setinde temel olarak metin ve label alanı bulunur. Metadata alanları kaynak, tarih veya language bilgisi taşıyabilir. Tek label veya çoklu label ihtiyacı baştan belirlenmelidir. CSV basit projelerde yeterli olabilir. Daha karmaşık metadata için JSONL veya Parquet daha uygun olabilir.

Text

Text alanı modelin gerçek input olarak göreceği metni taşır. Preprocessing sonrası değer ile ham metin ayrı alanlarda saklanabilir. Boş veya yalnızca whitespace içeren text kayıtları kalite testinde yakalanmalıdır. Text encoding UTF-8 olarak standartlaştırılabilir. Çok uzun metinlerin length distribution'ı ayrıca izlenmelidir.

Label

Label modelin öğrenmesi gereken hedef sınıfı temsil eder. İnsan tarafından okunabilir string ve sayısal ID mapping birlikte tutulabilir. Label isimleri eğitim boyunca değiştirilmemelidir. Taxonomy değişirse dataset major version artırılabilir. Invalid label kalite kontrol pipeline'ında otomatik yakalanmalıdır.

Multi-class classification

Multi-class problemde her örnek yalnızca tek sınıfa aittir. Softmax tabanlı model output sık kullanılır. Sınıflar birbirini dışlamalıdır. Annotator iki label arasında kalıyorsa taxonomy problemi olabilir. Class distribution train, validation ve test setlerinde raporlanmalıdır.

Multi-label classification

Multi-label problemde tek metin birden fazla sınıfa ait olabilir. Label listesi JSON array veya binary indicator biçiminde tutulabilir. Evaluation metriği micro ve macro F1 gibi değerleri içerebilir. Label co-occurrence analizi veri kalitesini anlamaya yardımcı olur. Annotation tool'un çoklu seçim desteklemesi gerekir.

Sentiment Analysis Dataset Formatı

Basit sentiment veri seti text ve sentiment label alanlarından oluşabilir. Positive, negative ve neutral yaygın sınıflardır. Mixed sentiment veya aspect-specific ihtiyaç varsa schema genişletilebilir. Class imbalance özellikle neutral verinin fazla olduğu sistemlerde kontrol edilmelidir. İnsan değerlendirmesinde ironik ifadeler için özel guideline bulunmalıdır.

Positive

Positive örnek metinde açık olumlu değerlendirme veya memnuniyet bulunduğunu gösterir. Yalnızca olumlu kelime eşleşmesi yeterli değildir. “Ürün güzel görünüyordu ama hiç çalışmadı” negatif olabilir. Context bütün olarak okunmalıdır. Annotator örnekleri guideline içinde farklı ifade biçimleriyle gösterilmelidir.

Negative

Negative label şikayet, memnuniyetsizlik veya olumsuz değerlendirmeyi temsil eder. Argo ve ironi bu sınıfta zor örnekler oluşturabilir. Bir sorun bildirimi her zaman duygusal negatiflik anlamına gelmeyebilir. Domain'e göre kural belirlenmelidir. Support ticket ve review sentiment görevleri aynı taxonomy'yi kullanmak zorunda değildir.

Neutral

Neutral metin güçlü olumlu veya olumsuz görüş içermeyen ifadeleri kapsar. Bilgi soruları genellikle neutral olabilir. Ancak “ürün bugün geldi” gibi çıplak bilgi ile gizli memnuniyetsizlik ayrımı dikkat gerektirir. Neutral sınıf çoğu dataset'te fazla olabilir. Class distribution ve agreement ayrıca izlenmelidir.

NER Dataset Formatı

NER veri seti entity konumunu ve türünü taşımalıdır. Token-level veya character span formatı kullanılabilir. BIO ve BIOES yaygın tagging şemalarıdır. Tokenizer alignment özellikle subword model kullanıldığında önemlidir. Nested entity gerekiyorsa basit BIO formatı yeterli olmayabilir.

Token-level annotation

Token-level annotation her token için entity etiketi verir. CoNLL formatında yaygın olarak kullanılır. Annotation tokenizer ile training tokenizer farklıysa hizalama problemi oluşabilir. Noktalama ve birleşik kelimeler token sınırını etkiler. Ham character span bilgisini ayrıca saklamak yeniden tokenization için faydalıdır.

BIO tagging

BIO şeması Beginning, Inside ve Outside etiketlerini kullanır. Bir entity'nin ilk token'ı B, sonraki token'ları I ile işaretlenir. Entity dışındaki token'lar O olur. Basit ve yaygın framework desteğine sahiptir. Invalid transition kontrolü dataset quality testine eklenebilir.

BIOES tagging

BIOES tek token entity ve entity sonunu ayrı label'larla gösterir. B, I, O yanında E ve S kullanılır. Bazı model ve görevlerde sınır öğrenmesini kolaylaştırabilir. Label sayısı BIO'ya göre daha fazladır. Annotation export ve training pipeline aynı şemayı desteklemelidir.

Nested entities

Nested entity bir entity span'in başka entity içinde bulunmasıdır. Basit BIO formatı aynı token için tek label taşıdığı için yetersiz olabilir. Span-based format daha uygun olabilir. Gerçek iş ihtiyacı yoksa gereksiz nested schema annotation maliyetini artırır. Taxonomy tasarımında önce kullanım senaryosu doğrulanmalıdır.

Question Answering Dataset Formatı

QA veri seti context, question ve answer ilişkisini taşımalıdır. Extractive sistemlerde answer start ve end span bilgisi gerekir. Bir sorunun birden fazla doğru cevabı olabilir. Unanswerable örnekler model güvenilirliği için değerlidir. Belge ve soru ID bilgisi leakage kontrolünü kolaylaştırır.

Context

Context cevabın bulunacağı kaynak metindir. Belge başlığı ve kaynak ID metadata olarak eklenebilir. Çok uzun belge segmentlere ayrılıyorsa hangi parçanın aynı kaynağa ait olduğu korunmalıdır. Aynı document chunk'larının train ve test'e dağılması leakage oluşturabilir. Context temizliği answer span konumunu bozmamalıdır.

Question

Question gerçek kullanıcıların soru biçimini temsil etmelidir. Aynı bilgi farklı cümlelerle sorulabilir. Yalnızca doküman cümlesini soru biçimine çevirmek kolay benchmark oluşturur. Paraphrase ve dolaylı sorular veri kalitesini artırır. Kullanıcı dilindeki yazım hataları belirli oranda korunabilir.

Answer

Answer beklenen doğru yanıtı taşır. Extractive QA'da context içinden alınır. Generative QA'da doğal dil yanıtı olabilir. Birden fazla kabul edilebilir cevap varsa liste olarak tutulabilir. Ground truth uzman review'dan geçmelidir.

Answer span

Answer span cevabın context içindeki başlangıç ve bitiş konumudur. Text normalization span offset'lerini değiştirebilir. Bu nedenle span annotation temizlik sonrası veya character mapping korunarak yapılmalıdır. Otomatik validator answer text ile context slice değerini karşılaştırabilir. Hatalı span training sürecini doğrudan bozar.

Answerable / unanswerable questions

Unanswerable sorular modelin kaynakta olmayan bilgi üretmemeyi öğrenmesine yardımcı olur. Sadece cevaplanabilir örneklerle eğitim yapılan model her soruya yanıt verme eğilimi gösterebilir. Negatif sorular gerçek document domain'inden seçilmelidir. Çok kolay alakasız sorular yeterli değildir. Hard unanswerable örnekler benzer kavram içeren ama cevabı bulunmayan sorulardır.

Summarization Dataset Formatı

Summarization veri seti source text ve target summary çiftlerinden oluşur. Özet stilinin abstractive veya extractive olması belirlenmelidir. Uzunluk hedefi ve kritik bilgi kuralları guideline'a eklenmelidir. Kaynak ile özet arasında factual consistency kontrol edilebilir. Belge provenance ve version bilgisi saklanmalıdır.

Source text

Source text özetlenecek asıl içeriği taşır. Çok uzun belgeler model context limitine göre bölünebilir. Bölme strategy training ve production'da benzer olmalıdır. Kaynak içindeki tablo ve başlıkların korunma biçimi göreve göre belirlenir. Duplicate document kontrolü split öncesinde yapılmalıdır.

Target summary

Target summary modelin üretmesi beklenen referans özettir. Tek doğru özet olmadığı için birden fazla referans kaliteyi artırabilir. Özet kaynaktaki bilgiyi değiştirmemelidir. Sayısal ve tarih bilgileri özellikle kontrol edilmelidir. Annotator'a uzunluk ve ton beklentisi açık biçimde verilmelidir.

LLM Instruction Dataset Formatı

Instruction dataset kullanıcı talebi ile ideal response çiftlerini içerir. Tek turn veya multi-turn conversation formatı kullanılabilir. System message davranış ve persona kurallarını belirleyebilir. Output'ların kalite ve güvenlik review'dan geçmesi gerekir. Instruction çeşitliliği modelin aynı görevi farklı ifade biçimleriyle anlamasına yardımcı olur.

Instruction

Instruction kullanıcının modelden ne istediğini açıklar. Kısa, uzun ve farklı tonlarda örnekler bulunmalıdır. Aynı template'i küçük değişikliklerle binlerce kez üretmek gerçek çeşitlilik sağlamaz. Gerçek kullanıcı talimatları anonimleştirilerek kullanılabilir. Instruction ile output uyumu otomatik ve insan kontrolünden geçmelidir.

Input

Input instruction'ın çalışacağı ek bağlamı içerir. Bazı örneklerde boş olabilir. Belge, tablo veya müşteri mesajı bu alanda bulunabilir. Hassas veri anonimleştirilmelidir. Input uzunluk dağılımı production kullanımına yakın olmalıdır.

Output

Output ideal model yanıtını temsil eder. Doğru, güvenli ve istenen formatta olmalıdır. LLM ile üretilen output insan doğrulamasından geçirilebilir. Çok uzun veya gereksiz açıklamalar task hedefini bozabilir. Output kalite rubric'i annotation guideline içinde tanımlanmalıdır.

System message

System message modelin genel davranışını ve kurallarını belirleyebilir. Dataset'te sistem mesajı training framework formatıyla uyumlu tutulmalıdır. Her örnekte gereksiz farklı system prompt kullanmak behavior consistency'yi bozabilir. Kurumsal assistant persona ayrı versionlanabilir. Safety ve policy talimatlarının output ile çelişmediği kontrol edilmelidir.

Conversation format

Multi-turn dataset user ve assistant rollerini sıralı biçimde taşır. Her mesaj role ve content alanına sahip olabilir. Conversation kesilirken önceki bağlamın answer için gerekli olup olmadığı değerlendirilmelidir. Aynı conversation'ın farklı parçalarının split'lere dağılması leakage oluşturabilir. Conversation ID group split için kullanılabilir.

Preference Dataset Formatı

Preference dataset aynı prompt için daha iyi ve daha kötü yanıt çiftleri içerir. Alignment ve preference optimization yöntemlerinde kullanılabilir. Chosen ve rejected response arasındaki kalite farkı net olmalıdır. İki yanıt da kötü ise tercih verisi değeri düşer. Preference criteria annotator'lar arasında açık şekilde paylaşılmalıdır.

Prompt

Prompt iki response'un değerlendirilmesine temel olan kullanıcı talebidir. Gerçek kullanım senaryolarından seçilmesi önemlidir. Çok kolay prompt'lar tercih farkını ölçmekte yetersiz olabilir. Güvenlik ve factuality gibi farklı rubric boyutları için dengeli örnekler hazırlanabilir. Prompt kaynağı provenance metadata'sında tutulabilir.

Chosen response

Chosen response annotator tarafından daha iyi bulunan yanıttır. Doğruluk, yararlılık ve format gibi kriterler değerlendirilir. Neden seçildiği isteğe bağlı reason alanında tutulabilir. Çok küçük fark bulunan çiftler uncertainty olarak işaretlenebilir. Domain expert yüksek riskli görevlerde review yapabilir.

Rejected response

Rejected response chosen yanıtından daha düşük tercih puanı alan seçenektir. Yanlış bilgi, format ihlali veya gereksiz uzunluk nedeniyle reddedilebilir. Bilinçli olarak zararlı veya aşırı kötü response üretmek veri dağılımını bozabilir. Gerçek model hatalarından gelen rejected örnekler değerlidir. Response kaynak modeli metadata olarak kaydedilebilir.

Annotation Kalitesi Nasıl Ölçülür?

Annotation kalitesi yalnızca kaç örnek etiketlendiğiyle ölçülmez. Annotator'ların aynı örnek üzerindeki anlaşma düzeyi önemli göstergedir. Golden dataset ve per-annotator accuracy operasyonel kaliteyi takip eder. Anlaşmazlıklar adjudication süreciyle çözülür. NLP veri setlerinde annotation kalite kontrol ve train validation test ayrımı model güvenilirliğinin temel parçalarıdır.

Inter-Annotator Agreement Nedir?

Inter-Annotator Agreement birden fazla annotator'ın aynı örneklerde ne kadar benzer karar verdiğini ölçer. Basit yüzde agreement başlangıç bilgisi sağlar. Şans eseri aynı label seçimini hesaba katmak için Kappa veya Alpha metrikleri kullanılabilir. Düşük agreement guideline veya taxonomy problemini gösterebilir. Her label için ayrı agreement analizi daha ayrıntılı bilgi verir.

Cohen's Kappa

Cohen's Kappa iki annotator arasındaki agreement'i şans faktörünü hesaba katarak ölçer. Classification gibi kategorik görevlerde sık kullanılır. Class imbalance metriğin yorumunu etkileyebilir. Tek sayı üzerinden kalite kararı vermek yerine confusion pair'leri de incelenmelidir. Pilot annotation değerlendirmesinde yararlı bir metriktir.

Fleiss' Kappa

Fleiss' Kappa ikiden fazla annotator bulunan kategorik annotation süreçlerinde kullanılabilir. Her örnek aynı sayıda annotator tarafından değerlendiriliyorsa uygulaması kolaydır. Label dağılımı skorun davranışını etkiler. Çok düşük skor guideline belirsizliğini gösterebilir. Kappa yanında örnek bazlı disagreement review yapılmalıdır.

Krippendorff's Alpha

Krippendorff's Alpha farklı veri türleri ve eksik annotation durumlarında esnek bir agreement metriğidir. Kategorik ve bazı ordinal görevlerde kullanılabilir. Annotator sayısının değiştiği sistemlerde faydalı olabilir. Hesaplama yöntemi görev ölçeğine göre seçilmelidir. Tek başına kullanılmak yerine qualitative review ile desteklenmelidir.

Golden Dataset Kullanımı

Golden dataset uzmanlar tarafından yüksek güvenle etiketlenmiş küçük referans settir. Annotator kalitesi düzenli olarak bu örneklerle kontrol edilebilir. Golden örneklerin tamamı annotator tarafından ezberlenmeyecek şekilde yönetilmelidir. Yeni guideline version çıktığında golden set yeniden doğrulanmalıdır. Model evaluation test setinden ayrı tutulması önerilir.

Annotator Accuracy Takibi

Annotator accuracy golden örnekler veya adjudicated sonuçlarla karşılaştırılarak ölçülebilir. Hata oranı label bazında incelenmelidir. Belirli sınıfta sürekli hata yapan annotator ek eğitim alabilir. Metrik cezalandırma amacıyla değil süreç iyileştirme için kullanılmalıdır. Çok düşük agreement bütün annotator'larda görülüyorsa sorun bireysel değil guideline kaynaklı olabilir.

Adjudication Süreci

Adjudication annotator anlaşmazlıklarının final karara dönüştürüldüğü süreçtir. Senior annotator veya domain expert devreye girebilir. Karar yalnızca mevcut örneği çözmekle kalmamalı, guideline'a yeni kural olarak yansıtılmalıdır. Sık tekrarlanan disagreement pattern'leri taxonomy değişikliğini gerektirebilir. Adjudication decision log gelecekteki annotation kalitesini artırır.

Etiket anlaşmazlıklarının çözülmesi

İki annotator farklı label verdiğinde örnek otomatik olarak çoğunluk oyu ile kapanmak zorunda değildir. Özellikle kritik sınıflarda gerekçe incelenmelidir. Annotator'lar guideline üzerinden kısa açıklama ekleyebilir. Final reviewer karar verir. Benzer disagreement örnekleri batch halinde ele alınarak tutarlı karar sağlanabilir.

Domain expert review

Hukuk, sağlık veya teknik ürün terminolojisi gibi alanlarda genel annotator yeterli bilgiye sahip olmayabilir. Domain expert yalnızca zor örnekleri inceleyerek maliyeti kontrol edebilir. Uzman kararı guideline'a dönüştürülmelidir. Her örneğin expert review'dan geçmesi gerekli değildir. Risk tabanlı review yaklaşımı daha verimlidir.

Kaç Kişi Veri Etiketlemeli?

Annotator sayısı veri hacmi, görev zorluğu ve kalite hedefiyle belirlenmelidir. Tek annotator hızlı ve ucuz olabilir ancak bias ve hata riski yüksektir. Kritik örneklerde double veya triple annotation daha güvenilir sonuç sağlar. Domain expert tüm veri setini etiketlemek yerine anlaşmazlıkları çözebilir. Annotation maliyeti ile kalite arasındaki denge pilot çalışma sonunda ölçülmelidir.

Tek Annotator'ın Riskleri

Tek annotator'ın hatasını doğrudan ground truth olarak kabul etmek kolaydır. Kişisel yorum ve guideline yanlış anlaması bütün dataset'e yayılabilir. Agreement metriği hesaplanamaz. Golden set yalnızca bireysel accuracy ölçümü sağlayabilir. Küçük pilot bile ikinci annotator ile doğrulanmalıdır.

Double Annotation

Double annotation aynı örneğin iki bağımsız kişi tarafından etiketlenmesidir. Agreement hesaplamak ve disagreement kuyruğu oluşturmak için güçlü başlangıçtır. Maliyeti tek annotation'a göre yaklaşık iki katına çıkarır. Bütün dataset yerine belirli örnek yüzdesinde uygulanabilir. Zor sınıflarda coverage oranı yükseltilebilir.

Triple Annotation

Triple annotation üç bağımsız karar sağlayarak çoğunluk oyu ve daha güçlü agreement analizi sunar. Subjektif sentiment veya preference görevlerinde yararlı olabilir. Maliyet ciddi biçimde artar. Yüksek riskli veya golden subset üzerinde kullanılabilir. Domain expert kararının yerini her zaman çoğunluk oyu almamalıdır.

Domain Expert Ne Zaman Gereklidir?

Label kararı özel uzmanlık gerektiriyorsa domain expert gerekir. Tıbbi entity, hukuki belge sınıflandırması veya teknik hata kodu buna örnektir. Uzman her kolay örneği etiketlemek zorunda değildir. Annotation guideline hazırlanması ve adjudication aşaması daha yüksek değer sağlayabilir. Expert zamanı en belirsiz örneklere ayrılmalıdır.

Annotation Maliyeti ile Kalite Arasındaki Denge

Bütün örnekleri üç kişiyle etiketlemek her proje için ekonomik değildir. Risk seviyesi yüksek sınıflarda daha fazla annotator kullanılabilir. Model-assisted annotation kolay örneklerde maliyeti düşürebilir. Agreement ve error rate verisi annotation stratejisinin zaman içinde ayarlanmasını sağlar. Kalite maliyet hesabı yalnızca örnek başına ücret üzerinden yapılmamalıdır.

Dataset Class Imbalance Nasıl Yönetilir?

Class imbalance bazı sınıfların diğerlerinden çok daha az örneğe sahip olmasıdır. Production dağılımı gerçekten dengesiz olabilir ve dataset bunu tamamen yapay biçimde eşitlememelidir. Ancak az sınıflar model tarafından hiç öğrenilemiyorsa targeted data collection gerekebilir. Oversampling, class weight ve synthetic example yöntemleri kullanılabilir. Başarı metriği accuracy yerine macro F1 ve per-class recall gibi değerlerle desteklenmelidir.

Sınıf Dağılımını Ölçme

Her label için örnek sayısı ve oranı raporlanmalıdır. Train, validation ve test setlerinin dağılımı ayrı gösterilmelidir. Çok az örnekli sınıflar otomatik uyarı üretebilir. Production log dağılımı dataset ile karşılaştırılmalıdır. Zaman içindeki değişiklik data drift göstergesi olabilir.

Minority Class Problemi

Minority class az örneğe sahip olduğu için model tarafından çoğunluk sınıfına karıştırılabilir. Kritik bir fraud veya güvenlik intent'i az görülse bile yüksek iş değerine sahip olabilir. Bu durumda örnek sayısı hedefli olarak artırılmalıdır. Recall özellikle izlenmelidir. Class weight tek başına yetersiz kalırsa veri toplama gerekir.

Oversampling

Oversampling minority örneklerin training sırasında daha sık gösterilmesini sağlar. Basit tekrar overfitting riski oluşturabilir. Augmentation veya synthetic variation ile desteklenebilir. Validation ve test setinde doğal dağılım korunmalıdır. Oversampling yalnızca training pipeline'a uygulanmalıdır.

Undersampling

Undersampling majority class örneklerinin bir bölümünü kaldırır. Training süresini azaltabilir. Ancak değerli çeşitliliğin kaybolmasına neden olabilir. Majority class içindeki hard negative örnekler korunmalıdır. Büyük veri setlerinde kontrollü sampling yararlı olabilir.

Class Weight

Class weight loss function içinde az sınıflara daha yüksek önem verilmesini sağlar. Veri setinin kendisini değiştirmeden training davranışını etkiler. Aşırı yüksek weight modelin false positive oranını artırabilir. Validation üzerinde optimize edilmelidir. Model training config dataset version ile birlikte kaydedilmelidir.

Targeted Data Collection

Az veya sorunlu sınıf için bilinçli veri toplamak çoğu zaman en güçlü çözümdür. Production loglarından ilgili intent aranabilir. Kullanıcı araştırması veya controlled prompt generation yapılabilir. Yeni örnekler mevcut distribution'ı taklit etmelidir. Sadece kolay ve açık örnekler eklemek gerçek model sorununu çözmeyebilir.

Synthetic Minority Examples

LLM ile az sınıf için sentetik metin üretilebilir. Farklı ton, uzunluk ve yazım biçimi istenebilir. İnsan doğrulaması yanlış veya birbirine çok benzeyen örnekleri temizler. Sentetik data oranı metadata'da izlenmelidir. Gerçek production minority örnekleri geldikçe sentetik verinin ağırlığı azaltılabilir.

Long-Tail Intent ve Entity'ler

Uzun kuyrukta çok az görülen ama önemli intent ve entity'ler bulunabilir. Bunları dataset'ten tamamen çıkarmak model kapsamını azaltır. Az sayıda örnekli sınıflar hierarchy veya fallback modeliyle yönetilebilir. Active learning yeni örnekleri zaman içinde toplar. Per-class metric long-tail performansını görünür hale getirir.

Dataset Coverage Nasıl Ölçülür?

Coverage veri setinin gerçek production dünyasının ne kadarını temsil ettiğini ölçmeye çalışır. Sadece toplam örnek sayısı güçlü coverage anlamına gelmez. Dilsel çeşitlilik, domain, edge case ve rare intent dağılımı incelenmelidir. Hard negative ve farklı kullanıcı grupları test setinde bulunmalıdır. Coverage boşlukları model error analysis ile birlikte sürekli güncellenmelidir.

Production Distribution ile Training Distribution Karşılaştırması

Training ve production sınıf oranları karşılaştırılabilir. Text length, language ve source distribution da önemlidir. Büyük fark model drift veya data mismatch gösterebilir. Model prediction histogram'ı ek sinyal sağlar. Düzenli monitoring yeni dataset toplama önceliklerini belirler.

Demografik ve Dilsel Çeşitlilik

Kullanıcı grupları farklı dil ve ifade biçimleri kullanabilir. Veri seti yalnızca belirli bir yazım tarzını temsil ederse model bazı gruplarda daha fazla hata yapabilir. Hassas demografik bilgi toplamak ayrıca gizlilik ve etik değerlendirme gerektirir. Dilsel çeşitlilik anonim metin özellikleri üzerinden de analiz edilebilir. Bölgesel ve code-switching örnekler coverage içinde değerlendirilebilir.

Domain Coverage

Bir model birden fazla ürün veya iş alanında kullanılıyorsa her domain yeterli örneğe sahip olmalıdır. Genel sınıf dağılımı iyi görünürken belirli ürün için coverage çok düşük olabilir. Domain metadata bu analizi kolaylaştırır. Per-domain metrics raporlanabilir. Yeni ürün eklendiğinde dataset update planı yapılmalıdır.

Edge Case Coverage

Edge case coverage modelin sınır durumlarını ne kadar gördüğünü gösterir. İroni, çoklu intent veya bozuk metin gibi kategoriler tag ile işaretlenebilir. Test setinde bilinçli sayıda edge case bulunmalıdır. Model sadece ortalama kullanıcı örneğinde değil zor örneklerde de değerlendirilmelidir. Production hataları yeni edge case taxonomy oluşturabilir.

Rare Intent Coverage

Nadir intent az görülür ama iş açısından kritik olabilir. Train ve test setinde tamamen eksik olması risklidir. Synthetic ve targeted collection ile desteklenebilir. Per-intent recall özellikle takip edilmelidir. Rare intent fallback rule veya human handoff ile de desteklenebilir.

Hard Negative Examples

Hard negative görünüşte hedef sınıfa çok benzeyen ama başka sınıfa ait örneklerdir. Model karar sınırını öğrenmek için çok değerlidir. Benzer kelime kullanımı ama farklı intent içeren örnekler toplanabilir. Production confusion matrix hard negative kaynaklarını gösterir. Data-centric iyileştirmede öncelikli veri tiplerinden biridir.

Hard Negative Mining Nedir?

Hard negative mining modelin en çok karıştırdığı negatif örnekleri sistematik biçimde bulma sürecidir. Rastgele alakasız negatifler model için çok kolaydır ve gerçek karar sınırını geliştirmez. Embedding similarity veya yanlış yüksek confidence tahminleri aday olarak kullanılabilir. İnsan review doğru label'ı doğrular. Bu örnekler sonraki training version'a eklenerek iteratif model gelişimi sağlanır.

Kolay Negatif Örnekler Neden Yetersizdir?

“Şifre sıfırlama” intent'i için hava durumu sorusunu negatif vermek model için çok kolaydır. Gerçek sorun “şifre değiştir” ile “şifremi unuttum” arasındaki ayrımdır. Kolay negatifler yüksek accuracy üretip yanıltıcı güven verebilir. Test seti benzer sınıfları ayıran zor örnekler içermelidir. Hard negative oranı dataset quality metriği olarak izlenebilir.

Modelin Karıştırdığı Örnekleri Training Data'ya Eklemek

Confusion matrix hangi sınıfların birbirine karıştığını gösterir. Yanlış tahmin edilen örnekler insan review ile doğrulanabilir. Benzer yeni örnekler production'dan veya targeted collection'dan eklenir. Aynı hatalı örneği onlarca kez kopyalamak yerine çeşitlilik sağlanmalıdır. Retraining sonrası confusion değişimi ölçülmelidir.

Semantic Similarity ile Hard Negative Bulma

Embedding kullanılarak farklı label'lara ait ama semantik olarak yakın metinler bulunabilir. Bu çiftler model için potansiyel zor örneklerdir. Similarity threshold otomatik karar yerine candidate selection için kullanılabilir. İnsan label doğrulaması yapılmalıdır. Embedding modelinin domain'e uygunluğu sonucu etkiler.

Iteratif Dataset Geliştirme

Dataset tek sefer hazırlanıp unutulan artifact değildir. Model hataları yeni veri toplama planını yönlendirmelidir. Hard negative, edge case ve düşük confidence örnekler yeni version'a eklenir. Retraining sonrası aynı test seti ve yeni challenge set ile değerlendirme yapılır. Dataset versioning bu döngüyü izlenebilir hale getirir.

Sentetik Veri NLP Veri Setlerinde Nasıl Kullanılır?

Sentetik veri özellikle az sınıf, privacy ve edge case üretiminde yararlı olabilir. Gerçek veriyi tamamen değiştirmemelidir çünkü production dağılımındaki ince ayrıntıları kaçırabilir. LLM aynı stil ve kelimeleri tekrar ederek çeşitliliği yapay biçimde yüksek gösterebilir. Human validation ve similarity filtering bu riski azaltır. Sentetik veri oranı ve kaynak modeli metadata olarak saklanmalıdır.

Synthetic Data'nın Avantajları

Az görülen intent için hızlı örnek üretilebilir. Hassas gerçek müşteri verisi yerine güvenli test metinleri oluşturulabilir. Belirli edge case kontrollü şekilde çoğaltılabilir. Annotation maliyeti ilk aşamada azalabilir. Farklı prompt stratejileriyle çeşitlilik artırılabilir.

Synthetic Data'nın Riskleri

LLM yanlış label'a uygun görünen metin üretebilir. Üretilen örnekler birbirine çok benzeyebilir. Gerçek kullanıcı yazım hatası ve dil çeşitliliği yeterince temsil edilmeyebilir. Kaynak modelin bias'ı training set'e aktarılabilir. Büyük miktar tek başına kalite garantisi değildir.

LLM ile Sentetik Metin Üretme

Prompt içinde label tanımı, pozitif ve negatif örnekler verilebilir. Farklı ton, uzunluk ve kullanıcı profili istenebilir. Her batch farklı generation seed veya template kullanabilir. Output duplicate ve semantic similarity kontrolünden geçirilmelidir. İnsan örneklemesi düzenli yapılmalıdır.

Sentetik Label Üretme

LLM mevcut metne label önerisi de verebilir. Confidence veya explanation eklenebilir. Bu etiket weak label olarak tutulmalıdır. High-risk sınıflar insan tarafından doğrulanmalıdır. Golden dataset üzerinde LLM annotator accuracy ölçülebilir.

Human Validation

İnsan doğrulaması sentetik verinin göreve gerçekten uygun olup olmadığını kontrol eder. Bütün örnekleri tek tek incelemek yerine stratified sampling uygulanabilir. Kritik veya low-confidence örnekler yüzde yüz review edilebilir. Hatalı üretim pattern'i prompt güncellemesine yol açar. Validation sonucu sentetik üretim pipeline'ının kalite metriği olur.

Gerçek ve Sentetik Veri Oranı

Tek evrensel doğru oran yoktur. Başlangıçta gerçek verinin çoğunlukta tutulması daha güvenlidir. Minority class içinde sentetik oran daha yüksek olabilir. Model performansı farklı oranlarla validation üzerinde test edilebilir. Production feedback geldikçe gerçek örneklerin payı artırılmalıdır.

Synthetic Data ile Gerçek Dünya Dağılımı Arasındaki Fark

Sentetik model genellikle daha düzgün ve açıklayıcı cümleler üretir. Gerçek kullanıcılar kısa, hatalı ve bağlamı eksik mesajlar yazabilir. Text length, vocabulary ve typo distribution iki veri kaynağında karşılaştırılmalıdır. Büyük fark varsa synthetic prompt strategy güncellenebilir. Dataset card sentetik verinin oranını açık biçimde belirtmelidir.

LLM ile Veri Etiketleme Güvenilir midir?

LLM veri etiketlemede hız sağlayabilir ancak doğruluğu görev ve domain'e göre değişir. Zero-shot kolay taxonomy'de işe yarayabilir. Few-shot örnekler karar kalitesini artırabilir. Human review özellikle düşük confidence ve kritik sınıflarda gereklidir. LLM-as-annotator performansı golden dataset üzerinde ölçülmeden ground truth üretmek için kullanılmamalıdır.

Zero-Shot Annotation

Zero-shot yöntemde modele yalnızca label tanımları verilir. Hızlı pilot ve taxonomy testi için kullanılabilir. Benzer sınıflarda hata oranı artabilir. Prompt wording sonucu ciddi biçimde etkileyebilir. Golden set comparison yapılmalıdır.

Few-Shot Annotation

Few-shot yaklaşım her label için birkaç örnek sunar. Model boundary case'leri daha iyi anlayabilir. Örnek seçimi bias oluşturabileceği için dengeli olmalıdır. Prompt token maliyeti yükselir. Aynı model version ve prompt template pinlenmelidir.

LLM-as-Annotator

LLM-as-annotator otomatik veya yarı otomatik annotation pipeline'ı kurar. Output label yanında reasoning veya confidence alınabilir. Reasoning'in doğru olması label'ın doğru olduğu anlamına gelmez. İnsan annotator ile agreement ölçülebilir. Model version değiştiğinde annotation consistency yeniden test edilmelidir.

Confidence-Based Human Review

LLM yüksek confidence örnekleri otomatik kabul, düşük confidence örnekleri human review'a gönderebilir. Confidence'ın kalibre edilmiş olması önemlidir. Modelin kendi ürettiği 0.99 değeri gerçek olasılık olarak kabul edilmemelidir. Golden set üzerinde threshold belirlenebilir. Random audit otomatik kabul edilen örneklerde kalite kaymasını yakalar.

LLM Annotation Bias

LLM eğitim verisinden gelen kültürel ve dilsel bias taşıyabilir. Belirli argo veya bölgesel ifadeleri yanlış yorumlayabilir. Türkçe özel kullanımda test edilmelidir. Model-assisted annotation insan annotator'ı da aynı hataya yönlendirebilir. Bağımsız blind review bias riskini azaltır.

İnsan ve LLM Etiketlerini Karşılaştırma

Aynı golden subset hem insan hem LLM tarafından etiketlenebilir. Accuracy, agreement ve sınıf bazlı hata dağılımı karşılaştırılır. LLM'in güçlü olduğu kolay sınıflar otomasyona alınabilir. Zor sınıflar insan annotation'da bırakılabilir. Bu hibrit yaklaşım maliyet ve kalite dengesini iyileştirir.

Train, Validation ve Test Seti Nasıl Oluşturulur?

Train, validation ve test ayrımı modelin öğrenme, ayar ve tarafsız değerlendirme ihtiyaçlarını birbirinden ayırır. Split yalnızca rastgele satır bölmek değildir. Aynı kullanıcı, belge veya conversation farklı split'lere düşerse leakage oluşabilir. Temporal ve group-based split gerçek production senaryosunu daha iyi temsil edebilir. Oranlar veri miktarı ve görev yapısına göre belirlenmelidir.

Training Set

Training set model parametrelerini öğrenmek için kullanılır. En büyük veri bölümü genellikle buradadır. Augmentation ve oversampling yalnızca training tarafında uygulanabilir. Label kalitesi model davranışını doğrudan etkiler. Training data version model artifact ile ilişkilendirilmelidir.

Validation Set

Validation set hyperparameter ve model seçimi için kullanılır. Training sırasında model bu örneklerden doğrudan öğrenmemelidir. Validation'a tekrar tekrar bakmak zamanla overfit riski oluşturabilir. Class ve domain dağılımı uygun olmalıdır. Büyük model değişikliklerinde validation set performansı karşılaştırılabilir.

Test Set

Test set final tarafsız değerlendirme için saklanmalıdır. Model geliştirme sırasında sürekli kullanılmamalıdır. Her denemede test sonucuna göre model ayarlamak test setine overfit etmektir. Production'a yakın dağılım içermelidir. Test set erişimi belirli ekiplerle sınırlandırılabilir.

Stratified Split

Stratified split sınıf oranlarını farklı split'lerde benzer tutmaya çalışır. Dengesiz classification problemlerinde faydalıdır. Ancak aynı kullanıcı veya belge leakage riski varsa yalnızca stratification yeterli değildir. Group bilgisiyle birlikte kullanılabilir. Çok az örnekli sınıflarda split dikkatle yapılmalıdır.

Group-Based Split

Group-based split aynı kullanıcı, conversation veya document ID'yi tek split içinde tutar. Bu yöntem benzer örneklerin train ve test arasında sızmasını azaltır. Müşteri destek verisinde ticket ID iyi group alanı olabilir. NER dokümanlarında document ID kullanılabilir. Group dağılımı class balance'ı bozuyorsa özel algoritma gerekebilir.

Temporal Split

Temporal split eski veriyi training, daha yeni veriyi validation veya test olarak kullanır. Production gelecekteki veriye uygulanacaksa gerçekçi değerlendirme sağlar. Yeni ürün veya kampanya drift'i görülebilir. Veri tarih bilgisinin güvenilir olması gerekir. Temporal leakage feature engineering sırasında da kontrol edilmelidir.

Domain-Based Split

Domain-based split belirli ürün, sektör veya kaynak alanını testte tutabilir. Modelin unseen domain genelleme yeteneğini ölçmek için kullanılır. Production'da yeni domain'e çıkış planlanıyorsa değerlidir. Test daha zor olabilir. Baseline ve domain-specific metric birlikte raporlanmalıdır.

NLP Datasetlerinde Data Leakage Nasıl Önlenir?

Data leakage modelin test bilgisine training sırasında doğrudan veya dolaylı erişmesidir. Duplicate ve aynı document parçaları en sık görülen kaynaklardır. Kullanıcı veya conversation seviyesinde split yapılmaması da leakage yaratabilir. Preprocessing pipeline test istatistiğini training'e taşımamalıdır. Train-test similarity analizi leakage kontrolünün düzenli parçası olmalıdır.

Exact Duplicate Leakage

Aynı metnin train ve test setinde bulunması en açık leakage türüdür. Hash karşılaştırmasıyla tespit edilebilir. Preprocessing sonrası normalize edilmiş hash ayrıca kullanılmalıdır. Duplicate label farklıysa veri hatası olarak incelenmelidir. Split öncesi global dedup en güvenli yaklaşımdır.

Semantic Duplicate Leakage

Paraphrase veya çok benzer cümleler exact hash kontrolünden kaçabilir. Embedding similarity bu örnekleri tespit etmeye yardımcı olur. Threshold çok düşük seçilirse doğal benzer örnekler yanlışlıkla duplicate sayılabilir. İnsan örnek review gerekir. Test seti challenge değerini koruyacak şekilde düzenlenmelidir.

Aynı Dokümanın Farklı Parçalarının Split'lere Dağılması

Uzun doküman chunk'lara bölündüğünde aynı belgenin parçaları train ve test'e düşebilir. Model doküman stilini ve bilgiyi training'de görmüş olur. Document ID group split bu problemi çözer. RAG evaluation dataset'inde özellikle önemlidir. Chunk ID yanında parent document ID tutulmalıdır.

Aynı Kullanıcının Verilerinin Farklı Split'lere Dağılması

Kullanıcıların kendine özgü ifade biçimi vardır. Aynı kullanıcının mesajları train ve test'e bölünürse model kullanıcı stilini ezberleyebilir. User-level group split daha gerçekçi performans ölçebilir. Privacy için gerçek user ID yerine stable anonymized ID kullanılabilir. Yeni kullanıcı generalization önemli kullanım senaryosudur.

Preprocessing Leakage

Vocabulary veya normalization parametreleri bütün dataset üzerinden öğrenilirse test bilgisi training pipeline'a sızabilir. Klasik ML sistemlerinde TF-IDF vocabulary yalnızca train üzerinde fit edilmelidir. Feature scaling aynı prensibe uyar. Transformer tokenizer genellikle önceden sabittir ancak özel tokenizer eğitiminde split kuralı önemlidir. Pipeline aşamaları açık biçimde belgelenmelidir.

Benchmark Contamination

Özellikle büyük dil modellerinde benchmark örnekleri ön eğitim verisinde bulunmuş olabilir. Bu durum model başarısını yapay yükseltebilir. Kuruma özel yeni test seti contamination riskini azaltır. İnternette yayınlanmamış anonim örnekler daha gerçekçi değerlendirme sağlar. Public benchmark tek performans kaynağı olarak kullanılmamalıdır.

Train-Test Similarity Analizi

Embedding veya n-gram similarity train ve test arasındaki yakınlığı ölçebilir. En yüksek benzer çiftler insan tarafından incelenebilir. Çok yüksek similarity oranı split strategy problemini gösterebilir. Rapor dataset quality checklist'e eklenebilir. Her yeni dataset version'da tekrar çalıştırılmalıdır.

NLP Dataset'i Hangi Formatlarda Saklanmalı?

Dataset formatı veri büyüklüğü, görev ve kullanılan framework'e göre seçilmelidir. CSV basit classification için yeterliyken nested metadata JSONL ile daha kolay taşınır. Parquet büyük dataset'lerde depolama ve okuma performansı sunar. NER için CoNLL formatı yaygındır. Format değişse bile schema ve version bilgisi korunmalıdır.

CSV

CSV insan tarafından kolay incelenir ve spreadsheet araçlarıyla uyumludur. Text içinde newline ve virgül bulunduğunda escaping hataları oluşabilir. Nested label yapısı için uygun değildir. Küçük classification dataset'lerinde pratik seçimdir. Encoding açık biçimde UTF-8 tutulmalıdır.

JSON

JSON nested yapı ve metadata taşımak için uygundur. Büyük tek dosya memory kullanımını artırabilir. Conversation ve QA dataset'lerinde okunabilir yapı sağlar. Schema validator kullanılabilir. Dosya indentation production storage boyutunu artırabilir.

JSONL

JSONL her satırda bağımsız JSON object tutar. Büyük dataset streaming için uygundur. Hatalı tek satır bütün dosyanın parse edilmesini engellemez. LLM instruction ve preference dataset'lerinde sık kullanılır. Schema bütün satırlarda tutarlı olmalıdır.

Parquet

Parquet columnar ve sıkıştırılmış veri formatıdır. Büyük dataset'lerde depolama ve okuma performansı güçlüdür. Hugging Face Datasets ile iyi çalışır. İnsan tarafından doğrudan okunması CSV kadar kolay değildir. Production pipeline ve dataset artifact storage için uygundur.

CoNLL

CoNLL formatı token-level NER ve sequence labeling görevlerinde yaygındır. Genellikle token ve label satır bazında tutulur. Cümleler boş satırla ayrılabilir. Nested entity veya zengin metadata için sınırlı kalabilir. Export formatı olarak güçlüdür.

Arrow

Apache Arrow columnar in-memory format sunar. Hugging Face Datasets dahili olarak Arrow tabanlı yapıları kullanabilir. Büyük dataset işlemlerinde memory mapping avantaj sağlar. Kullanıcı çoğu zaman doğrudan Arrow dosyasını yönetmek zorunda kalmaz. Framework entegrasyonu veri pipeline'ını hızlandırabilir.

Hugging Face Dataset Formatı

Hugging Face Dataset schema, features ve split bilgisini birlikte yönetebilir. DatasetDict train, validation ve test setlerini tek yapı altında tutar. Map, filter ve shuffle işlemleri reproducible pipeline'a dönüştürülebilir. Hub revisions versioning sağlar. Private dataset repository kurum içi kullanımda değerlendirilebilir.

Göreve Göre En Uygun Format Nasıl Seçilir?

Basit tabular classification için CSV yeterli olabilir. Conversation ve QA için JSONL daha esnektir. Büyük ölçekli training için Parquet avantaj sağlar. NER interoperability için CoNLL tercih edilebilir. Asıl kriter training tool, annotation export ve versioning sürecinin aynı schema'yı güvenilir biçimde taşımasıdır.

Hugging Face Datasets ile Özel Veri Seti Hazırlama

Hugging Face Datasets özel NLP veri setlerini yüklemek, dönüştürmek ve training pipeline'a bağlamak için kullanışlı bir araçtır. CSV, JSON ve Parquet kaynakları tek API üzerinden işlenebilir. Dataset ve DatasetDict yapıları schema bilgisini korur. Map işlemi preprocessing adımlarını uygulanabilir hale getirir. Veri seti private Hub repository veya kurum içi storage üzerinde sürümlenebilir.

load_dataset

load_dataset yerel veya uzaktaki birçok veri formatını ortak API ile yükler. CSV ve JSON file path'leri doğrudan verilebilir. Split tanımları ayrı dosyalarla oluşturulabilir. Dataset script kullanılıyorsa source logic versionlanmalıdır. Remote code kullanımında güvenlik politikası dikkate alınmalıdır.

Dataset

Dataset tek bir veri tablosunu column-based yapı içinde temsil eder. Select, filter ve map işlemleri uygulanabilir. Schema features üzerinden görülebilir. Büyük dataset memory mapping ile verimli kullanılabilir. Transformation sonucu yeni fingerprint üretilebilir.

DatasetDict

DatasetDict train, validation ve test gibi split'leri tek dictionary altında tutar. Aynı preprocessing fonksiyonu bütün split'lere uygulanabilir. Split adlarının standardize olması training script'lerini kolaylaştırır. Test split yanlışlıkla training'e verilmemelidir. Dataset card split statistics içermelidir.

Feature ve ClassLabel Tanımlama

Features her sütunun veri tipini açık biçimde tanımlar. ClassLabel string label ile numeric ID mapping sağlar. Invalid label load aşamasında yakalanabilir. NER için Sequence ve ClassLabel birlikte kullanılabilir. Schema değişikliği dataset version açısından önemli breaking change olabilir.

CSV ve JSON Dosyalarını Yükleme

Yerel CSV ve JSON dosyaları dataset loader ile kolayca okunabilir. Encoding ve column type sorunları yükleme sırasında kontrol edilmelidir. Train ve validation file mapping açık verilebilir. Büyük JSON array yerine JSONL daha streaming-friendly olabilir. Ham dosya checksum reproducibility için kaydedilebilir.

Dataset Üzerinde map() Kullanımı

map fonksiyonu normalization, tokenization veya feature extraction için kullanılabilir. Batched processing performansı artırabilir. Fonksiyon deterministic olmalıdır. Cache tekrar işlemleri hızlandırır. Map code version dataset transformation provenance içinde tutulmalıdır.

Dataset'i Hub'a Yükleme

Dataset Hub paylaşım ve versioning için kullanılabilir. Hassas şirket verisi public repository'ye yüklenmemelidir. Private repository veya kurum politikası uygun alternatif olabilir. Dataset card lisans, kullanım amacı ve limitation bilgisi içermelidir. Revision pinning model training reproducibility sağlar.

Tokenization Veri Hazırlığının Hangi Aşamasında Yapılmalı?

Tokenization genellikle temizlenmiş ve split edilmiş dataset üzerinde model training pipeline'a yakın aşamada yapılmalıdır. Raw text kaybolmamalıdır çünkü tokenizer değişebilir. Model ile tokenizer uyumlu olmalıdır. Maximum sequence length, truncation ve padding politikası training performansını etkiler. NER gibi görevlerde token-label alignment ayrıca kontrol edilmelidir.

Tokenizer Model ile Neden Uyumlu Olmalıdır?

Pretrained model belirli tokenizer vocabulary ve special token düzeniyle eğitilmiştir. Farklı tokenizer kullanmak embedding mapping'i bozabilir. Model checkpoint ile tokenizer version birlikte pinlenmelidir. Fine-tuning dataset'i raw text olarak da saklanmalıdır. Tokenizer update yeni preprocessing version sayılmalıdır.

Subword Tokenization

Subword yöntemleri nadir kelimeleri daha küçük parçalara böler. Türkçenin eklemeli yapısında kelime sonları birden fazla token olabilir. NER label alignment bu nedenle önemlidir. Token fertility model memory ve context kullanımını etkiler. Türkçe text üzerinde tokenizer istatistiği ölçülebilir.

Maximum Sequence Length

Maximum sequence length modelin tek örnekte işleyebileceği token sayısını sınırlar. Dataset text length distribution incelenmeden keyfi değer seçilmemelidir. Çok düşük limit kritik bilgiyi truncation ile kaybedebilir. Çok yüksek limit training memory maliyetini artırır. P95 token length başlangıç referansı olabilir.

Truncation

Truncation uzun örneklerin maksimum uzunluğa kesilmesidir. Classification'da önemli bilgi metnin sonunda bulunabilir. Head-only kesmek hatalı olabilir. Sliding window veya head-tail stratejisi değerlendirilebilir. Kesilen örnek oranı dataset report'ta tutulmalıdır.

Padding

Padding farklı uzunluktaki sequence'leri batch içinde aynı uzunluğa getirir. Gereksiz padding GPU hesaplama maliyetini artırır. Static ve dynamic yöntemler farklı kullanım alanlarına sahiptir. Padding token attention mask ile gerçek içerikten ayrılır. Model tokenizer config ile uyumlu olmalıdır.

Static padding

Static padding bütün örnekleri sabit maksimum uzunluğa tamamlar. Implementation basittir. Kısa metin ağırlıklı dataset'te çok fazla boş token oluşturabilir. Bazı accelerator optimizasyonlarında faydalı olabilir. Maliyet benchmark ile ölçülmelidir.

Dynamic padding

Dynamic padding yalnızca mevcut batch içindeki en uzun sequence kadar padding ekler. Genellikle training verimliliğini artırır. Data collator bu işi batch zamanında yapabilir. Sequence length'e göre bucketing ek verim sağlayabilir. Evaluation pipeline aynı attention behavior'ı kullanmalıdır.

Attention Mask

Attention mask modelin gerçek token ile padding token'ı ayırmasını sağlar. Tokenizer çoğu zaman otomatik üretir. Yanlış mask modelin padding'e attention vermesine neden olabilir. Custom preprocessing bu alanı bozmadığından emin olmalıdır. Unit test birkaç örnek üzerinde kontrol sağlayabilir.

Token Type IDs

Bazı model mimarileri segment ayrımı için token type ID kullanır. BERT-style sentence pair görevlerinde görülebilir. Her model bu alanı kullanmaz. Tokenizer output'una göre training code esnek olmalıdır. Gereksiz field zorla üretmek gerekmez.

NER'de Token-Label Alignment

Tek kelime subword parçalarına bölündüğünde tek word label birden fazla token'a hizalanmalıdır. İlk subword'e label verip diğerlerini ignore etmek yaygın yaklaşımdır. Alternatif olarak label bütün subword'lere yayılabilir. Training loss davranışı seçilen yönteme göre değişir. Alignment code unit test ve sample visualization ile doğrulanmalıdır.

NLP Veri Seti Kalitesi Nasıl Kontrol Edilir?

Dataset quality kontrolü otomatik test ve manuel örnekleme yöntemlerini birlikte kullanmalıdır. Missing data, invalid label, duplicate, length ve class distribution temel kontrollerdir. Leakage ve PII scan production readiness açısından önemlidir. Annotation agreement insan etiketlerinin tutarlılığını gösterir. Her dataset version aynı kalite pipeline'ından geçmelidir.

Missing Data

Text veya label alanı eksik örnekler training hatasına veya anlamsız öğrenmeye neden olabilir. Null, empty string ve whitespace-only durumları ayrı kontrol edilmelidir. Bazı metadata alanları isteğe bağlı olabilir. Schema hangi alanların zorunlu olduğunu tanımlamalıdır. Missing rate threshold üzerinde olduğunda pipeline fail edilebilir.

Invalid Labels

Taxonomy dışında label bulunması veri hatasıdır. Büyük-küçük harf veya yazım farklılığı da yeni sınıf gibi görülebilir. ClassLabel veya schema validation bunu engelleyebilir. Deprecated label migration planı olmalıdır. Invalid label raporu kaynağa göre ayrıştırılabilir.

Duplicate Rate

Duplicate rate exact ve near duplicate oranını gösterir. Çok yüksek oran veri toplama pipeline'ın tekrar kayıt ürettiğini gösterebilir. Class distribution duplicate sonrası değişebilir. Train-test leakage ayrıca kontrol edilmelidir. Dataset card temizleme sonrası duplicate istatistiğini içerebilir.

Text Length Distribution

Karakter ve token uzunluğu dağılımı model input profilini gösterir. Çok kısa veya aşırı uzun outlier'lar incelenmelidir. Production distribution ile karşılaştırma yapılabilir. Truncation rate hesaplanabilir. Farklı domain'ler ayrı histogram ile analiz edilebilir.

Label Distribution

Label distribution class imbalance ve eksik sınıfları görünür yapar. Split bazında karşılaştırılmalıdır. Production label tahminiyle trend analizi yapılabilir. Çok az örnekli label için targeted collection planlanabilir. Taxonomy değişikliği distribution tarihçesiyle izlenmelidir.

Vocabulary Coverage

Vocabulary coverage kullanılan model tokenizer'ın dataset metinlerini ne kadar verimli parçaladığını gösterir. Unknown token oranı bazı tokenizer'larda önemli metriktir. Subword token sayısı kelime başına ölçülebilir. Türkçe ve code-switching segmentleri ayrı karşılaştırılabilir. Çok yüksek fragmentation model seçimini etkileyebilir.

Language Detection

Dataset içinde beklenmeyen diller bulunabilir. Otomatik language detection kaba kalite kontrol sağlar. Kısa metinlerde yanlış tahmin oranı yüksek olabilir. Türkçe-İngilizce code-switching yanlışlıkla filtrelenmemelidir. Language field metadata olarak saklanabilir.

Annotation Agreement

Agreement annotation guideline kalitesini izler. Label veya annotator bazında hesaplanabilir. Zaman içinde düşüş yeni annotator eğitimi ihtiyacını gösterebilir. Yeni taxonomy version sonrası tekrar ölçülmelidir. Düşük agreement verisi doğrudan model training'e alınmadan review edilebilir.

Leakage Tests

Leakage test exact duplicate, group overlap ve semantic similarity kontrolünü içerir. Train ve test user ID intersection otomatik hesaplanabilir. Document ID overlap sıfır olmalıdır. Embedding-based similarity yüksek çiftleri raporlayabilir. Dataset release gate leakage test başarısını zorunlu kılabilir.

PII Scan

PII scan e-posta, telefon ve belirli kimlik pattern'lerini arayabilir. NER tabanlı detector kişi ve konumları da bulabilir. False positive ve false negative mümkündür. Hassas dataset'te manual sample review eklenmelidir. Bulunan PII remediation log tutulmalıdır.

Manual Sample Review

Otomatik testler dilsel kalite ve anlam hatalarını tamamen yakalayamaz. Her version'da rastgele ve risk bazlı örnek seçimi insan tarafından incelenebilir. Label, text cleaning ve metadata birlikte kontrol edilir. Review sonucu kalite checklist'e kaydedilir. Sistematik hata bulunursa daha geniş veri segmenti taranmalıdır.

NLP Dataset Quality Checklist

Quality checklist veri seti release öncesinde temel riskleri hızlı doğrulamaya yardımcı olur. Temsil, label açıklığı, edge case, denge, duplicate, leakage, PII ve lisans kontrolleri birlikte ele alınmalıdır. Tek bir kontrolün başarılı olması genel kaliteyi garanti etmez. Checklist otomatik pipeline ve insan sign-off kombinasyonu olabilir. Her dataset release aynı standardı uygulamalıdır.

Veriler Görevi Temsil Ediyor mu?

Dataset gerçek input uzunluğu ve dil stilini yansıtmalıdır. Production source dağılımı ile karşılaştırma yapılmalıdır. Yalnızca kolay akademik örnekler yeterli değildir. Edge case ve long-tail sınıflar bulunmalıdır. Kullanıcı araştırması temsil boşluklarını gösterebilir.

Label'lar Açık ve Birbirinden Ayrılabilir mi?

Annotator iki label arasında sık kararsız kalıyorsa taxonomy sorunu olabilir. Definition ve negative example'lar incelenmelidir. Agreement sınıf bazında ölçülmelidir. Gerekirse sınıflar birleştirilebilir. Model confusion aynı problemi doğrulayabilir.

Edge Case'ler Var mı?

Edge case dataset'te bilinçli biçimde bulunmalıdır. Sadece ortalama örneklerden oluşan test gerçek riskleri göstermez. Production hata logları yeni case kaynağıdır. Her edge category metadata tag alabilir. Coverage zaman içinde izlenebilir.

Dataset Dengeli mi?

Denge her sınıfın eşit sayıda olması anlamına gelmez. Production dağılımı ve iş kritiklik seviyesi birlikte düşünülmelidir. Minority class yeterli öğrenme örneğine sahip olmalıdır. Test set doğal dağılıma yakın olabilir. Macro F1 dengesiz performansı görünür yapar.

Duplicate Veriler Temizlendi mi?

Exact ve near duplicate kontrolleri yapılmalıdır. Train-test overlap sıfıra yakın olmalıdır. Same document chunk leakage ayrıca incelenmelidir. Duplicate removal sonrası class distribution yeniden hesaplanmalıdır. Dedup logic versionlanmalıdır.

Split'lerde Leakage Var mı?

User, document ve conversation group overlap kontrol edilmelidir. Semantic similarity yüksek örnekler review edilmelidir. Preprocessing fit yalnızca train üzerinde yapılmalıdır. Test set model development'tan izole tutulmalıdır. Leakage test raporu release artifact'e eklenebilir.

PII Temizlendi mi?

Dataset kullanım amacı PII gerektirmiyorsa kişisel bilgiler kaldırılmalıdır. Regex ve NER scanner kullanılabilir. İnsan sample review ek güvence sağlar. Anonimleştirme placeholder'ları tutarlı olmalıdır. Ham veri daha sıkı access control altında tutulmalıdır.

Veri Kaynakları ve Lisansları Kaydedildi mi?

Her source'un provenance kaydı olmalıdır. Lisans veya kullanım izni belgelenmelidir. Mixed dataset'te kaynak oranları raporlanmalıdır. Lisans değişikliği ilgili örnekleri bulmayı kolaylaştırmalıdır. Dataset card bu bilgiyi özetler.

Dataset Versioning Neden Gereklidir?

Dataset zaman içinde yeni örnek, düzeltilmiş label ve farklı split içerir. Versioning olmadan hangi modelin hangi veriden üretildiğini bilmek zorlaşır. Kod gibi dataset de değişiklik günlüğüne sahip olmalıdır. DVC, Git LFS veya Hub revisions araç olarak kullanılabilir. Model artifact metadata'sında dataset version bulunması reproducibility sağlar.

Dataset'i Kod Gibi Sürümlemek

Her değişiklik reason ve author bilgisiyle kaydedilebilir. Küçük düzeltme ile taxonomy değişikliği birbirinden ayrılmalıdır. Release tag training pipeline tarafından kullanılabilir. Eski version gerektiğinde yeniden açılabilir. Tam dataset binary olarak Git'e eklenmek yerine uygun storage çözümü kullanılmalıdır.

Semantic Dataset Versioning

Major, minor ve patch benzeri version modeli dataset değişikliklerine uygulanabilir. Label schema değişimi major version olabilir. Yeni örnek eklenmesi minor, birkaç label düzeltmesi patch sayılabilir. Kurallar kurum tarafından açık biçimde tanımlanmalıdır. Model compatibility bu version bilgisiyle değerlendirilebilir.

Değişiklik Günlüğü

Changelog yeni eklenen, silinen ve düzeltilen veri segmentlerini açıklar. Split değişikliği ayrıca belirtilmelidir. PII remediation veya lisans nedeniyle silinen kaynaklar kaydedilebilir. Performance etkisi model benchmark ile ilişkilendirilebilir. Dataset card release history bölümü olarak kullanılabilir.

DVC

DVC büyük veri artifact'lerini Git metadata'sıyla birlikte sürümlemek için kullanılabilir. Dataset dosyaları object storage üzerinde tutulabilir. Pipeline stage ve dependency ilişkisi tanımlanabilir. Hash değişiklikleri reproducibility sağlar. Ekip mevcut DevOps altyapısıyla entegrasyonu değerlendirmelidir.

Git LFS

Git LFS büyük dosyaları Git repository pointer'larıyla yönetir. Küçük ve orta dataset projelerinde kolay olabilir. Çok büyük dataset ve sık değişiklikte storage maliyeti artabilir. Access control repository ile ilişkilidir. Hassas veri için ayrı güvenlik değerlendirmesi yapılmalıdır.

Hugging Face Dataset Revisions

Hub repository revision ve commit mekanizması dataset versioning sağlayabilir. Training script belirli revision'a pinlenebilir. Private repository kurumsal veriler için kullanılabilir. Dataset card her release ile güncellenebilir. Kurumun veri yerelliği ve erişim politikası platform seçimini belirlemelidir.

Model Versiyonu ile Dataset Versiyonunu Eşleştirmek

Her model registry kaydı kullanılan dataset version'ı içermelidir. Tokenizer ve training code version da eklenebilir. Model performans değişikliğinin veri mi kod mu kaynaklı olduğu böylece analiz edilir. Rollback sırasında aynı kombinasyon yeniden oluşturulabilir. MLOps metadata store bu ilişkiyi merkezi tutabilir.

Dataset Card Nasıl Hazırlanır?

Dataset card veri setinin ne olduğunu, nereden geldiğini ve hangi sınırlara sahip olduğunu açıklar. Yeni ekip üyesi yalnızca dosya adından dataset amacını anlayamaz. Kaynak, lisans, dil, schema ve statistics temel alanlardır. Known limitations ve bias bölümü güvenli kullanım için önemlidir. Intended ve out-of-scope kullanım açık biçimde yazılmalıdır.

Dataset Açıklaması

Açıklama veri setinin hangi NLP görevi için üretildiğini belirtir. Toplama dönemi ve domain bilgisi eklenebilir. Örnek sayısı ve split dağılımı özetlenebilir. Annotation yöntemi kısa biçimde açıklanmalıdır. Okuyucu dataset'i neden kullanacağını hızlıca anlamalıdır.

Veri Kaynakları

Her ana kaynak türü listelenmelidir. Şirket içi, açık veri ve sentetik oranı belirtilebilir. Collection date ve sampling yöntemi önemlidir. Gizlilik nedeniyle exact source paylaşılmıyorsa kategori düzeyinde açıklama yapılabilir. Provenance ayrıntısı internal registry'de tutulabilir.

Lisans

Dataset lisansı veya internal kullanım şartı belirtilmelidir. Birden fazla kaynak varsa lisans durumu açıklanmalıdır. Redistribution mümkün değilse açıkça yazılmalıdır. Model training kullanım hakkı ayrıca belirtilebilir. Hukuk onay tarihi internal metadata'da saklanabilir.

Dil

Ana dil ve varsa code-switching oranı belirtilmelidir. Türkçe bölgesel veya sektörel özellikler açıklanabilir. Otomatik language detection yöntemi kullanıldıysa yazılabilir. Çok dilli dataset'te dil dağılımı tablo halinde verilebilir. Bu bilgi model ve tokenizer seçimini etkiler.

Label Schema

Bütün label isimleri ve tanımları dataset card'da bulunmalıdır. Deprecated label varsa belirtilmelidir. Multi-label veya hierarchy yapısı açıklanmalıdır. NER entity türleri listelenmelidir. Annotation guideline daha ayrıntılı dokümana link verebilir.

Dataset Statistics

Örnek sayısı, label distribution ve text length temel istatistiklerdir. Duplicate removal sonrası değerler verilmelidir. Train, validation ve test ayrı raporlanmalıdır. Sentetik veri oranı belirtilebilir. Agreement score kalite hakkında ek bilgi sağlar.

Known Limitations

Dataset'in eksik olduğu domain ve kullanıcı grupları açıkça yazılmalıdır. Örneğin sosyal medya Türkçesi az olabilir. Rare intent coverage sınırlı olabilir. Veri toplama tarihinden sonra yeni ürünler bulunmayabilir. Model kullanıcıları bu sınırlamaları bilerek risk yönetebilir.

Bias ve Riskler

Veri kaynağı belirli kullanıcı grubunu fazla temsil edebilir. LLM-generated örnekler kaynak model bias'ını taşıyabilir. Toxic veya hassas içerik bulunabilir. Bu riskler saklanmak yerine belgelenmelidir. Mitigation ve kullanım uyarısı eklenebilir.

Intended Use

Dataset'in hedeflenen kullanım alanı net biçimde yazılmalıdır. İç intent classifier training veya Türkçe NER benchmark gibi açıklama verilebilir. Ticari ürün kullanım izni varsa belirtilmelidir. Evaluation ve training amacı farklı olabilir. Intended use model kartıyla birlikte değerlendirilebilir.

Out-of-Scope Use

Dataset'in uygun olmadığı kullanım alanları belirtilmelidir. Örneğin sağlık kararı veya hukuki tavsiye için tasarlanmamış olabilir. Başka dilde model training için yeterli olmayabilir. Hassas demografik karar sistemlerinde kullanılmaması gerekebilir. Açık sınırlar yanlış kullanımı azaltır.

Özel Veri Setinin Model Performansına Etkisi Nasıl Ölçülür?

Özel veri setinin değeri model benchmark değişimiyle ölçülmelidir. Önce baseline model ve sabit test set oluşturulur. Yeni data version aynı training recipe ile denenir. Accuracy, precision, recall, F1 ve confusion matrix karşılaştırılır. Error analysis hangi veri değişikliğinin hangi sınıfta fayda sağladığını gösterir.

Baseline Model Oluşturma

Baseline basit ama tekrarlanabilir bir model olmalıdır. İlk dataset version ile eğitilir. Hyperparameter ve random seed kaydedilir. Daha karmaşık modelden önce veri değişiklikleri baseline üzerinde test edilebilir. Bu yaklaşım iyileştirmenin model mi data mı kaynaklı olduğunu ayırır.

Accuracy

Accuracy doğru tahminlerin toplam tahminlere oranıdır. Dengeli sınıflarda anlaşılır metriktir. Dengesiz dataset'te çoğunluk sınıfı skoru yükseltebilir. Kritik az sınıfların hatası görünmez kalabilir. Bu nedenle diğer metriklerle birlikte kullanılmalıdır.

Precision

Precision modelin bir sınıf olarak tahmin ettiği örneklerin ne kadarının gerçekten o sınıfa ait olduğunu ölçer. False positive maliyeti yüksek görevlerde önemlidir. Spam veya risk tespiti buna örnek olabilir. Per-class precision raporlanmalıdır. Threshold ayarı precision-recall dengesini değiştirir.

Recall

Recall gerçek pozitiflerin ne kadarının model tarafından bulunduğunu gösterir. Kaçırma maliyeti yüksek sınıflarda kritik metriktir. Minority class recall düşükse targeted data collection gerekebilir. Confusion matrix hangi sınıfa kaydığını gösterir. Recall tek başına false positive sayısını açıklamaz.

F1 Score

F1 precision ve recall'un harmonik ortalamasıdır. İki metriği dengeli değerlendirmek için kullanılır. Binary ve multiclass görevlerde farklı averaging seçenekleri bulunur. Threshold selection F1'e göre optimize edilebilir. İş metriğiyle uyumu yine kontrol edilmelidir.

Macro F1

Macro F1 her sınıfa eşit ağırlık vererek F1 ortalaması alır. Dengesiz dataset'lerde minority class performansını görünür hale getirir. Çok az örnekli sınıf skoru dalgalanabilir. Support sayısıyla birlikte raporlanmalıdır. Veri seti iyileştirme kararında güçlü metriktir.

Per-Class Metrics

Toplam skor bazı sınıflardaki ciddi problemi gizleyebilir. Her label için precision, recall ve F1 ayrı incelenmelidir. İş açısından kritik sınıflar minimum threshold'a sahip olabilir. Data collection priority bu sonuçlara göre belirlenebilir. Version karşılaştırması sınıf bazında yapılmalıdır.

Confusion Matrix

Confusion matrix hangi sınıfların birbirine karıştığını gösterir. Hard negative mining için temel kaynaktır. Benzer intent pair'leri hızlıca görünür olur. Normalize edilmiş matrix class imbalance etkisini azaltarak okunabilir. Her model release hata analizi toplantısında kullanılabilir.

Error Analysis

Error analysis yanlış tahminleri elle veya otomatik kategorilerle inceler. Hata veri eksikliği, yanlış label veya model kapasitesi kaynaklı olabilir. Her hata için yeni veri toplamak gerekli değildir. Sistematik pattern'ler önceliklendirilmelidir. Sonuç yeni dataset version backlog'una dönüştürülür.

Data-Centric AI ile NLP Modelini Geliştirme

Data-centric yaklaşım model mimarisini sürekli değiştirmek yerine veri kalitesini sistematik olarak iyileştirmeye odaklanır. Yanlış label, eksik segment ve hard negative örnekler model hatalarının ana kaynağı olabilir. Aynı model daha iyi veriyle belirgin performans artışı gösterebilir. Dataset ve error analysis döngüsü sürekli çalışmalıdır. Bu yaklaşım özellikle kurumsal özel NLP projelerinde ölçülebilir ve sürdürülebilir ilerleme sağlar.

Modeli Değiştirmeden Önce Veriyi İyileştirmek

İlk refleks daha büyük transformer kullanmak olmamalıdır. Confusion matrix ve low-confidence örnekler veri problemini gösterebilir. Yanlış label temizliği performansı model değişiminden daha fazla artırabilir. Deney aynı baseline modelle tekrar edilmelidir. Maliyet ve latency avantajı korunur.

Hatalı Etiketleri Bulmak

Modelin yüksek confidence ile ground truth'tan farklı tahmin verdiği örnekler label error adayı olabilir. Confident learning benzeri yöntemler kullanılabilir. İnsan review final kararı verir. Hatalı label düzeltilirken guideline güncellenebilir. Error rate data source veya annotator bazında analiz edilebilir.

Eksik Veri Segmentlerini Tespit Etmek

Model belirli domain veya text length grubunda daha kötü çalışabilir. Slice-based evaluation bu segmentleri gösterir. Türkçe-İngilizce karışık metin veya uzun ticket'lar örnek olabilir. Yeni data collection yalnızca bu segmentlere odaklanabilir. Böylece veri bütçesi daha verimli kullanılır.

Model Hatalarını Yeni Training Data'ya Dönüştürmek

Production yanlış tahminleri human review queue'ya alınabilir. Doğru label belirlendikten sonra sonraki training set'e eklenir. Aynı hataya benzer örnekler de toplanabilir. Veri eklendi diye mevcut test set değiştirilmemelidir. Yeni challenge set ayrı tutulabilir.

Dataset → Training → Error Analysis → Dataset Döngüsü

Bu döngü model geliştirmeyi sürekli süreç haline getirir. Her dataset version yeni training run üretir. Evaluation yeni hata segmentlerini gösterir. Veri ekibi bu segmentlere göre yeni örnek toplar veya label düzeltir. Versioning bütün zinciri izlenebilir kılar.

Production Verileriyle Dataset Nasıl Sürekli Geliştirilir?

Production sistemi gerçek kullanıcı dilinin en değerli kaynağıdır. Model hataları, düşük confidence ve yeni intent'ler kontrollü biçimde veri geliştirme kuyruğuna alınabilir. PII ve kullanıcı izinleri bu süreçte korunmalıdır. Human review doğru label üretir. Periyodik retraining ve drift monitoring veri setinin güncel kalmasını sağlar.

Model Hatalarını Loglamak

Yanlış tahmin olduğu kullanıcı veya operasyon sistemi tarafından bildirilebilir. Tam prompt yerine gerektiğinde anonimleştirilmiş örnek data lake'e aktarılabilir. Prediction, confidence ve model version metadata olarak kaydedilir. Hata kategorisi insan review sonrasında eklenir. Bu log yeni dataset backlog'unun temelidir.

Low-Confidence Prediction'ları Toplamak

Düşük confidence örnekler decision boundary yakınında olabilir. Active learning için değerlidir. Confidence threshold calibration ile belirlenmelidir. Bütün düşük confidence örnekleri saklamak privacy ve storage yükü oluşturabilir. Sampling ve anonimleştirme uygulanabilir.

Human Review Queue

Review queue modelin belirsiz veya kullanıcı tarafından işaretlenmiş örneklerini toplar. Priority kritik intent ve yüksek trafik segmentine göre verilebilir. Annotator mevcut prediction'ı doğrular veya düzeltir. Review sonucu guideline'a yeni case ekleyebilir. Queue SLA production model kalitesini etkiler.

Active Learning

Active learning review bütçesini en değerli örneklere ayırır. Uncertainty, diversity ve model disagreement kriterleri kullanılabilir. Aynı tip yüzlerce örneğin kuyruğa gelmesi engellenebilir. Random control sample bias kontrolü sağlar. Retraining sonrası selection policy yeniden değerlendirilebilir.

Yeni Edge Case'leri Dataset'e Eklemek

Production yeni ürün veya kullanıcı davranışı nedeniyle daha önce görülmeyen case getirir. Bu örnekler özel tag ile dataset'e eklenebilir. Sadece tek örnek yerine benzer varyasyonlar toplanmalıdır. Test ve training dağılımına kontrollü biçimde eklenir. Dataset card limitation bölümü güncellenebilir.

Periodic Retraining

Retraining sabit takvim veya drift sinyaline göre yapılabilir. Her hafta training yapmak gerekli olmayabilir. Yeterli yeni veri biriktiğinde ve kalite review tamamlandığında yeni model hazırlanır. Aynı test set ile regression yapılır. Production promotion ayrı MLOps süreciyle yürütülmelidir.

Data Drift Monitoring

Data drift input dağılımının training verisinden zamanla uzaklaşmasıdır. Text length, language, embedding distribution ve predicted class oranı izlenebilir. Büyük değişim yeni veri toplama ihtiyacını gösterebilir. Drift her zaman model performans düşüşü anlamına gelmez. Labeled sample evaluation ile etkisi doğrulanmalıdır.

NLP Veri Seti Hazırlamak İçin En İyi Programlama Dili Hangisidir?

NLP veri hazırlamada Python en yaygın seçeneklerden biridir ancak tek doğru dil değildir. pandas, Hugging Face Datasets, Transformers ve spaCy gibi geniş ekosistem güçlü avantaj sağlar. R istatistiksel analizde, SQL büyük veri kaynaklarından seçim yapmada kullanılabilir. Asıl önemli konu script'lerin yeniden üretilebilir ve test edilebilir data pipeline'a dönüştürülmesidir. Programlama dili iyi süreç tasarımının yerini alamaz.

Python Neden Öne Çıkıyor?

Python NLP ve machine learning ekosisteminin büyük bölümüne doğrudan erişim sağlar. Veri temizleme, annotation export ve model training aynı dil içinde yürütülebilir. Notebook prototipi production script'e dönüştürülebilir. Unit test ve type checking büyük pipeline'larda önem kazanır. Dependency versionları lock file ile sabitlenmelidir.

pandas

pandas küçük ve orta ölçekli tabular veri temizliği için oldukça kullanışlıdır. Missing, duplicate ve label distribution kontrolleri hızlı yapılabilir. Çok büyük dataset'te memory sınırı görülebilir. Parquet ve chunk processing yardımcı olur. DataFrame dönüşümleri version-controlled script içinde tutulmalıdır.

Hugging Face Datasets

Datasets büyük veri ve NLP training pipeline'ı için verimli yapı sağlar. Map ve filter işlemleri uygulanabilir. DatasetDict split yönetimini kolaylaştırır. Parquet ve Arrow desteği performans avantajı sunar. Hub veya local storage ile versioning uygulanabilir.

Transformers

Transformers tokenizer ve pretrained model entegrasyonu sağlar. Veri setinin model-specific tokenization adımı bu ekosistemle yürütülebilir. Data collator dynamic padding sağlar. Training pipeline dataset schema ile uyumlu olmalıdır. Model ve tokenizer version pinlenmelidir.

spaCy

spaCy tokenization, NER ve linguistic preprocessing için güçlü araçtır. Custom pipeline ve rule-based matcher annotation destek amacıyla kullanılabilir. Türkçe desteğinin kullanım senaryosuna uygunluğu test edilmelidir. Prodigy ile annotation ekosistemine entegre olabilir. Rule-based prelabeling manual annotation hızını artırabilir.

scikit-learn

scikit-learn baseline classification ve metric hesaplama için değerlidir. Stratified split, confusion matrix ve class weight araçları sağlar. Basit TF-IDF model güçlü baseline olabilir. Büyük transformer'dan önce data kalitesini test etmek için kullanışlıdır. Pipeline ve random seed reproducibility için sabitlenmelidir.

R Ne Zaman Kullanılabilir?

R istatistiksel analiz ve veri görselleştirmede güçlü seçenek olabilir. Veri bilim ekibi R konusunda deneyimliyse annotation quality ve distribution analizi burada yapılabilir. Model training başka sistemde olsa bile export standard formatta tutulabilir. Python zorunluluğu yoktur. Ortak schema ekipler arasındaki entegrasyonu kolaylaştırır.

SQL'in Veri Hazırlamadaki Rolü

Şirket içi NLP verisi çoğu zaman CRM veya data warehouse içinde bulunur. SQL doğru örnekleri seçmek ve metadata ile birleştirmek için temel araçtır. Sampling query version control altında tutulmalıdır. PII alanları mümkünse kaynak sorguda çıkarılabilir. Temporal split database tarih alanı üzerinden üretilebilir.

Programlama Dilinden Daha Önemli Olan Veri Pipeline Tasarımı

Tek seferlik notebook üretim ortamında sürdürülebilir değildir. Raw, cleaned, labeled ve split data aşamaları açık olmalıdır. Her step deterministic ve versionlanmış code ile çalışmalıdır. Quality gate pipeline'ı hatalı dataset release'ini engeller. Dil seçimi bu mimarinin ardından gelir.

NLP Veri Etiketleme Araçları

Annotation aracı multi-user çalışma, review ve export sürecini kolaylaştırır. Label Studio, Doccano, Prodigy ve Argilla farklı kullanım profilleri sunar. Araç seçerken yalnızca UI görünümüne değil workflow ve API desteğine bakılmalıdır. NER, classification ve preference annotation ihtiyaçları farklı olabilir. Export formatı training pipeline'a kolay bağlanmalıdır.

Label Studio

Label Studio birçok veri türü ve NLP görevi için esnek annotation interface sunar. Custom label configuration hazırlanabilir. Multi-user ve review süreçleri deployment şekline göre yapılandırılabilir. API entegrasyonu prelabeling ve export automation için kullanılabilir. Kurumsal deployment'ta authentication ve data storage politikası değerlendirilmelidir.

Doccano

Doccano özellikle text classification, sequence labeling ve translation görevlerine odaklanır. Basit arayüz annotator onboarding'i kolaylaştırabilir. Açık kaynak deployment mümkündür. Export formatı training script ile eşleştirilmelidir. User permission ve backup production annotation projelerinde önemlidir.

Prodigy

Prodigy aktif learning ve model-in-the-loop annotation workflow'larıyla bilinir. spaCy ekosistemiyle yakın entegrasyon sağlayabilir. Hızlı keyboard-driven annotation deneyimi sunar. Ticari lisans modeli kurum tarafından değerlendirilmelidir. Custom recipe geliştirmek teknik ekip gerektirebilir.

Argilla

Argilla human feedback ve NLP dataset workflow'larında kullanılabilir. Model prediction ve annotation birlikte gösterilebilir. Review ve feedback process desteklenebilir. LLM data curation senaryolarında değerlendirilebilir. Deployment ve access control kurumun güvenlik gereksinimlerine göre ayarlanmalıdır.

Hugging Face Ekosistemi

Hugging Face dataset storage, model training ve evaluation aşamalarını ortak ekosistemde birleştirebilir. Annotation araçlarından export edilen veri Dataset formatına dönüştürülebilir. Hub private repository collaboration sağlayabilir. Dataset card ve revisions dokümantasyonu güçlendirir. Hassas veri yerelliği kurum politikasına göre değerlendirilmelidir.

Araç Seçerken Nelere Dikkat Edilmeli?

Araç NLP görevinizi doğal biçimde desteklemelidir. Annotator sayısı, review workflow ve authentication önemli kriterlerdir. API otomasyonu büyük veri projelerinde ciddi zaman kazandırır. Export formatı vendor bağımlılığını azaltmalıdır. Self-hosting ihtiyacı güvenlik politikasıyla birlikte değerlendirilmelidir.

Multi-user annotation

Birden fazla annotator aynı projede güvenli biçimde çalışabilmelidir. Task assignment duplicate veya double annotation stratejisini desteklemelidir. User bazında ilerleme ölçülebilir. Yetki rolleri annotator ve reviewer'ı ayırmalıdır. Shared account kullanılmamalıdır.

Review workflow

Annotation doğrudan final kabul edilmemelidir. Reviewer disagreement ve low-confidence örnekleri inceleyebilmelidir. Adjudication sonucu kayıt altında tutulmalıdır. Golden sample mekanizması faydalıdır. Review history audit ve kalite analizi için kullanılabilir.

API desteği

API veri import, prelabeling ve export otomasyonunu sağlar. Production loglarından yeni task otomatik oluşturulabilir. Authentication token secure storage'da tutulmalıdır. API version değişiklikleri integration test ile takip edilmelidir. Rate limit ve batch işlemleri büyük dataset'te önemlidir.

Export formatları

Tool-specific export tek seçenek olmamalıdır. JSON, JSONL, CSV veya CoNLL gibi açık formatlar tercih edilir. Character span ve metadata kaybolmadan export edilmelidir. Dataset schema validator conversion sonrası çalıştırılmalıdır. Tool değişimi data migration sorununa dönüşmemelidir.

Open Source ve İşbirliği ile NLP Dataset Geliştirme

Açık kaynak dataset projeleri Türkçe NLP ekosistemine doğrudan katkı sağlar. Annotation guideline, schema ve quality script'lerinin paylaşılması başka ekiplerin katkısını kolaylaştırır. GitHub issue ve pull request modeli veri katkısına uyarlanabilir. Kişisel veri ve telif problemi olan örnekler public repository'ye eklenmemelidir. Açık dataset yayınlanmadan önce lisans ve data card hazırlanmalıdır.

Açık Kaynak Dataset Oluşturmanın Avantajları

Topluluk farklı dil ve bölge örnekleri sağlayarak coverage'ı artırabilir. Hatalı label'lar issue olarak raporlanabilir. Dataset yönteminin açık olması akademik ve endüstriyel kullanımı kolaylaştırır. Benchmark standardı oluşabilir. Katkı süreci quality gate ile korunmalıdır.

GitHub ile Dataset Projesi Yönetme

Repository guideline, scripts ve küçük sample data için kullanılabilir. Büyük dataset release artifact veya harici storage'da tutulabilir. Issue tracker label hatası ve yeni sınıf talebi için kullanılabilir. Pull request otomatik quality test çalıştırabilir. Contribution guide veri formatını açıklar.

Annotation Guideline'ı Açık Kaynak Paylaşma

Guideline paylaşımı dataset'in nasıl üretildiğini şeffaf hale getirir. Başka ekipler label interpretation'ı anlayabilir. Community feedback belirsiz kuralları iyileştirir. Guideline version dataset release ile eşleştirilmelidir. Hassas kurum içi örnekler anonim örneklerle değiştirilebilir.

Community Annotation

Topluluk annotation büyük veri hacminde katkı sağlayabilir. Annotator eğitimi ve golden test kaliteyi korur. Her contribution doğrudan final label olarak kabul edilmemelidir. Review ve agreement mekanizması uygulanmalıdır. Katılımcılara veri kullanım ve etik kurallar açıklanmalıdır.

Pull Request ile Veri Katkısı

Veri katkısı standard JSONL veya başka açık formatta yapılabilir. CI duplicate, schema ve PII test çalıştırabilir. Reviewer linguistic ve label quality kontrol eder. Kabul edilen katkı changelog'a eklenir. Büyük binary dosyalar repository'yi şişirmemelidir.

Dataset Issue Tracker

Issue tracker yanlış label, duplicate ve coverage gap raporlarını toplar. Her issue dataset version ile ilişkilendirilebilir. Yeni taxonomy önerisi tartışılabilir. Security veya PII issue public disclosure gerektirmiyorsa private channel kullanılmalıdır. Kapanan issue changelog'a referans olabilir.

Veri Setinin Hugging Face Hub'da Yayınlanması

Hub dataset discovery ve erişim kolaylığı sağlar. Dataset card eksiksiz hazırlanmalıdır. Lisans ve intended use açık olmalıdır. Sensitive veya redistribution kısıtlı veri public yüklenmemelidir. Revision sistemi release management için kullanılabilir.

Diyarbakır Yazılım Topluluğu İçin NLP Dataset Proje Fikirleri

Diyarbakır Yazılım Topluluğu için Türkçe ve yerel dil kullanımına odaklanan NLP projeleri hem teknik öğrenme hem açık veri üretimi açısından değerli olabilir. Proje seçiminde veri izni ve kişisel veri güvenliği baştan ele alınmalıdır. Küçük ama iyi dokümante edilmiş dataset büyük fakat kontrolsüz veri setinden daha yararlıdır. Topluluk projeleri hakkında https://www.diyarbakiryazilim.com.tr/projects adresi üzerinden mevcut çalışmalar incelenebilir. Topluluğun yaklaşımı ve iletişim bilgileri için https://www.diyarbakiryazilim.com.tr/about sayfası kullanılabilir.

Türkçe Yerel Ağız ve İfade Veri Seti

Bölgesel ifade ve günlük dil örnekleri Türkçe NLP coverage'ına katkı sağlayabilir. Veri gönüllü ve açık izinle toplanmalıdır. Hassas kimlik bilgileri bulunmamalıdır. Standard Türkçe karşılığı metadata olarak eklenebilir. Dialect classification amacı yerine language understanding benchmark gibi daha güvenli kullanım tasarlanabilir.

Diyarbakır İşletmeleri İçin Müşteri Yorumları Dataset'i

İzinli ve açık kaynaklı yorumlardan sentiment veya topic dataset hazırlanabilir. İşletme ve kullanıcı kimliği anonimleştirilmelidir. Telif ve platform kullanım koşulları kontrol edilmelidir. Positive, negative ve neutral guideline toplulukla geliştirilebilir. Dataset yalnızca izin verilen içeriklerden oluşturulmalıdır.

Türkçe Intent Classification Benchmark

Yerel hizmetler ve günlük dijital işlemler için intent taxonomy hazırlanabilir. Katılımcılar farklı ifade biçimleri üretebilir. Double annotation ve agreement ölçümü uygulanabilir. Baseline model sonuçları açık biçimde paylaşılabilir. Benchmark hem eğitim hem portföy projesi olarak kullanılabilir.

Yerel Kültür ve Tarih İçin Question Answering Dataset'i

Açık ve güvenilir kaynaklardan Diyarbakır kültür ve tarihi hakkında QA dataset oluşturulabilir. Her answer source citation metadata'sı taşımalıdır. Cevaplanamaz sorular ayrıca eklenebilir. Telif durumu kaynak bazında kontrol edilmelidir. Uzman veya kaynak doğrulaması factual quality'yi artırır.

Açık Kaynak Türkçe NER Dataset'i

Kişi, kurum, konum ve yerel entity tiplerini içeren Türkçe NER dataset hazırlanabilir. Public kaynakların kullanım izni kontrol edilmelidir. BIO ve span formatları birlikte sunulabilir. Double annotation agreement ölçümü yapılabilir. Dataset card Türkçe tokenization özelliklerini açıklayabilir.

Topluluk Tabanlı Veri Etiketleme Etkinlikleri

Annotation etkinlikleri dataset engineering sürecini uygulamalı öğretir. Katılımcılar guideline, label ve quality review deneyimi kazanır. Küçük golden set ile kalite ölçülebilir. Kişisel veri içermeyen örnekler kullanılmalıdır. Etkinlik çıktısı açık kaynak contribution'a dönüştürülebilir.

Annotation workshop

Workshop küçük classification veya NER dataset'i üzerinde yapılabilir. Önce guideline açıklanır. Katılımcılar aynı örnekleri bağımsız etiketler. Agreement hesaplanıp tartışılır. Son bölümde guideline nasıl iyileştirilir birlikte değerlendirilir.

Dataset hackathon

Hackathon takımların veri toplama, temizleme ve baseline model süreçlerini uçtan uca deneyimlemesini sağlar. Aynı raw data farklı ekipler tarafından işlenebilir. Quality score ve model result birlikte değerlendirilebilir. Telif ve PII kuralları etkinlik öncesi belirlenmelidir. Sonuçlar açık repository'de paylaşılabilir.

GitHub contribution sprint

Contribution sprint mevcut dataset issue'larını çözmeye odaklanabilir. Duplicate cleanup, label fix veya documentation görevleri seçilebilir. Pull request CI quality test çalıştırır. Yeni katılımcılar için küçük issue'lar hazırlanabilir. Review süreci gerçek açık kaynak deneyimi sağlar.

Dataset quality review

Quality review etkinliği model training yerine veri hatalarını bulmaya odaklanır. Duplicate, PII, label inconsistency ve leakage testleri çalıştırılır. Katılımcılar manuel sample review yapar. Bulunan sorunlar issue tracker'a eklenir. Dataset engineering'in model geliştirmedeki rolü uygulamalı görülür.

NLP Alanında Yazılımcı Olmak İçin Ne Öğrenilmeli?

NLP alanında ilerlemek isteyen geliştirici yalnızca transformer kütüphanelerini öğrenmemelidir. Veri analizi, regex, annotation, evaluation ve MLOps bilgisi günlük işte büyük rol oynar. Türkçe gibi dillerde linguistic özellikleri anlamak avantaj sağlar. Küçük açık kaynak dataset projeleri teori ile pratiği birleştirir. Veri seti hazırlama ve model geliştirme becerisi portföyde güçlü bir farklılık oluşturabilir.

Python

Python veri temizleme ve model training ekosisteminin temel araçlarından biridir. pandas ve Datasets öğrenmek iyi başlangıçtır. Script yazma yanında virtual environment ve dependency management bilinmelidir. Unit test data pipeline güvenilirliğini artırır. Küçük notebook kodu zamanla modüler pipeline'a dönüştürülmelidir.

Veri Analizi

Distribution, missing value ve outlier kavramları NLP dataset'lerinde de önemlidir. Histogram ve group-by analizleri data coverage'ı gösterir. Class imbalance erken fark edilmelidir. Production ve training distribution karşılaştırılabilir. Model sonucu veri analizi olmadan doğru yorumlanamaz.

Regex ve Text Processing

Regex PII detection, text cleaning ve pattern extraction için güçlü araçtır. Çok karmaşık regex bakım maliyetini artırabilir. Unicode ve Türkçe karakterler test edilmelidir. Regex label kuralı olarak weak supervision sağlayabilir. Her pattern unit test ile doğrulanmalıdır.

NLP Fundamentals

Tokenization, morphology, sequence labeling ve language modeling temelleri anlaşılmalıdır. Word embedding ile contextual embedding farkı önemlidir. Evaluation metric task'a göre seçilmelidir. Data leakage ve preprocessing kavramları model kadar önemlidir. Teori gerçek dataset üzerinde uygulanmalıdır.

Machine Learning

Train-validation-test, overfitting ve bias-variance temel kavramlardır. Baseline model oluşturma becerisi güçlüdür. Accuracy dışındaki metrikler öğrenilmelidir. Feature ve label leakage anlaşılmalıdır. Transformer kullanmak klasik ML bilgisini gereksiz hale getirmez.

Transformers

Attention ve pretrained model mantığını anlamak modern NLP için önemlidir. Tokenizer ve model input formatları öğrenilmelidir. Fine-tuning memory ve sequence length davranışı bilinmelidir. Model card ve license okumak teknik becerinin parçasıdır. Daha büyük modelin her zaman daha iyi olmadığını benchmark gösterir.

Hugging Face

Datasets, Transformers ve Hub birlikte güçlü workflow sunar. Custom dataset yükleme ve tokenization öğrenilebilir. Trainer veya alternatif training loop denenebilir. Model ve dataset revisions pinlenmelidir. Private data kullanımında security policy dikkate alınmalıdır.

Veri Etiketleme ve Dataset Engineering

Label taxonomy ve annotation guideline hazırlama temel beceridir. Agreement metric ve adjudication öğrenilmelidir. Dataset versioning ve card hazırlamak profesyonel süreç oluşturur. PII ve lisans kontrolü teknik pipeline'a eklenmelidir. Veri hatalarının model hatasına nasıl dönüştüğü error analysis ile görülmelidir.

Model Evaluation

Evaluation yalnızca tek skor üretmek değildir. Per-class metric, confusion matrix ve slice analysis öğrenilmelidir. Test contamination ve repeated tuning riski bilinmelidir. Human evaluation generative görevlerde önemlidir. Production metric ile offline benchmark ilişkilendirilmelidir.

MLOps ve DataOps

Dataset, code ve model version ilişkisi MLOps'un temelidir. Data quality pipeline otomatik çalışmalıdır. Model registry hangi dataset version kullanıldığını bilmelidir. Retraining ve deployment kontrollü süreç olmalıdır. Monitoring data drift ve model hata sinyallerini toplar.

Portföy İçin NLP Veri Seti Projeleri

İyi bir NLP portföy projesi yalnızca model notebook'u değil veri tasarım sürecini de göstermelidir. Dataset card, annotation guideline ve quality report güçlü katkı sağlar. Türkçe görev seçmek yerel ekosistem için değer üretir. Açık lisanslı veya kendi oluşturduğunuz veriler kullanılmalıdır. Sonuç GitHub ve uygun durumda Hugging Face üzerinden paylaşılabilir.

Türkçe Sentiment Dataset

Küçük ama dengeli Türkçe sentiment dataset hazırlanabilir. Positive, negative ve neutral guideline açık yazılmalıdır. İroni ve mixed sentiment edge case olarak eklenebilir. Agreement ölçümü raporlanmalıdır. Baseline transformer ve klasik model karşılaştırılabilir.

Intent Classification Dataset

Örneğin e-ticaret destek intent'leri için taxonomy hazırlanabilir. Her label pozitif ve hard negative örnekler içerebilir. Synthetic data belirli sınıfları destekleyebilir. Split user-independent biçimde tasarlanabilir. Confusion matrix üzerinden dataset iyileştirme döngüsü gösterilebilir.

Named Entity Recognition Dataset

Türkçe ürün, kurum veya konum entity dataset'i hazırlanabilir. Span ve BIO export sağlanabilir. Token-label alignment script yazılabilir. Agreement ve entity distribution raporlanabilir. PII kullanılacaksa açık kaynak veya sentetik metin tercih edilmelidir.

Question Answering Dataset

Açık dokümanlardan extractive QA dataset oluşturulabilir. Context, question, answer ve span formatı hazırlanır. Unanswerable sorular eklenir. Document-level split uygulanır. Baseline QA model evaluation yapılabilir.

Instruction-Tuning Dataset

Küçük Türkçe instruction dataset farklı görevleri kapsayabilir. İnsan yazımı ve LLM-assisted örnekler ayrı metadata taşıyabilir. Output kalite rubric hazırlanmalıdır. JSONL conversation formatı kullanılabilir. Dataset card sentetik oranı ve limitation bilgisi içermelidir.

Açık Kaynak Türkçe Benchmark

Birden fazla NLP görevini küçük benchmark paketi altında birleştirmek mümkündür. Classification, NER ve QA ayrı split'lere sahip olabilir. Benchmark test seti sık değiştirilmemelidir. Evaluation script repository'ye eklenmelidir. Community contribution yeni challenge set ile yapılabilir.

Uçtan Uca Özel NLP Veri Seti Hazırlama Workflow'u

Uçtan uca workflow iş probleminden başlayıp versionlanmış dataset release ile tamamlanır. Her aşama sonraki adımın kalitesini etkiler. PII ve lisans kontrolü annotation'dan önce yapılmalıdır. Baseline model training dataset kalitesini gerçek metrikle test eder. Doğal Dil İşleme (NLP) Modelleri İçin Özel Veri Seti Hazırlama sürecinin sürdürülebilir olması için bütün workflow otomasyon ve insan review ile desteklenmelidir.

1. İş Problemini Tanımlayın

Model hangi iş sonucunu iyileştirecek açıkça belirlenmelidir. Kullanıcı ve decision flow anlaşılmalıdır. Yanlış prediction'ın maliyeti değerlendirilmelidir. Başarı metriği iş hedefiyle ilişkilendirilmelidir. NLP görevi bu problemden türetilmelidir.

2. NLP Görevini Seçin

Classification, NER veya generation ihtiyacı netleştirilmelidir. Tek model birden fazla görev yapacaksa her görev ayrı değerlendirilmelidir. Output schema belirlenmelidir. Baseline yaklaşım seçilebilir. Veri formatı göreve göre planlanır.

3. Label Schema Oluşturun

Label isim ve tanımları yazılmalıdır. Birbirine yakın sınıflar tartışılmalıdır. Edge case ve multi-label ihtiyacı belirlenmelidir. Domain expert görüşü alınabilir. Schema versionlanmalıdır.

4. Veri Kaynaklarını Belirleyin

Şirket içi ve açık kaynaklar listelenmelidir. Her source için izin ve lisans durumu kontrol edilir. Production temsil değeri değerlendirilir. Collection yöntemi belgelenir. Provenance field tasarlanır.

5. Verileri Toplayın

Raw data immutable alanda saklanabilir. Collection date ve source ID eklenir. API veya SQL query versionlanır. Rate limit ve kullanım şartlarına uyulur. İlk distribution report hazırlanır.

6. PII ve Lisans Kontrolü Yapın

PII scanner ve insan review uygulanır. Gereksiz kişisel alanlar çıkarılır. Lisans şüpheli kaynaklar quarantine edilir. Hukuk onayı gerekiyorsa training öncesinde alınır. Provenance kayıtları tamamlanır.

7. Veriyi Temizleyin

Duplicate, encoding ve bozuk text temizlenir. Gereksiz HTML artığı kaldırılır. Türkçe karakterler korunur. Aşırı normalization yapılmaz. Temizleme code ve metrics versionlanır.

8. Annotation Guideline Hazırlayın

Label definition, positive, negative ve boundary örnekleri yazılır. Uncertain policy belirlenir. Domain terminology eklenir. Guideline reviewer tarafından incelenir. İlk version pilot için yayınlanır.

9. Pilot Annotation Yapın

Küçük ama çeşitli sample seçilir. En az iki annotator bağımsız çalışır. Zor örnekler özellikle dahil edilir. Annotation süresi ölçülür. Tool ve workflow problemi bu aşamada görülür.

10. Agreement Ölçün

Cohen's Kappa veya uygun metric hesaplanır. Label bazlı disagreement incelenir. Düşük agreement sınıfları yeniden tanımlanır. Guideline update edilir. Gerekirse ikinci pilot yapılır.

11. Ana Annotation Sürecini Çalıştırın

Task'lar annotator'lara kontrollü dağıtılır. Double annotation oranı risk bazlı seçilir. Golden sample araya eklenebilir. Progress ve accuracy izlenir. Problem görülen label için annotation durdurulup guideline düzeltilebilir.

12. Quality Assurance Yapın

Schema, missing ve invalid label testleri çalışır. Agreement ve annotator accuracy raporlanır. Random manual review yapılır. Adjudication kuyruğu kapatılır. QA başarısızsa dataset release edilmez.

13. Duplicate ve Leakage Kontrolü Yapın

Exact ve semantic duplicate analizi yapılır. User, document ve conversation group'ları çıkarılır. Split öncesi global dedup uygulanır. Similarity candidate'ları insan review'dan geçebilir. Leakage report kaydedilir.

14. Train/Validation/Test Split Oluşturun

Göreve göre stratified veya group split uygulanır. Temporal yapı gerekiyorsa tarih kullanılır. Test set erişimi sınırlandırılabilir. Split statistics kontrol edilir. Aynı group'un birden fazla split'te olmadığı doğrulanır.

15. Hugging Face Dataset Formatına Dönüştürün

Dataset veya DatasetDict oluşturulur. Features ve ClassLabel tanımlanır. Schema validation çalışır. Parquet artifact üretilebilir. Revision ve fingerprint kaydedilir.

16. Tokenization Yapın

Model-specific tokenizer version pinlenir. Max length distribution'a göre seçilir. Truncation ve padding policy tanımlanır. NER alignment test edilir. Raw text ayrı tutulur.

17. Baseline Model Eğitin

Basit ve tekrarlanabilir model seçilir. Seed ve hyperparameter kaydedilir. Validation metric izlenir. Model artifact dataset version ile etiketlenir. Training log sonraki karşılaştırma için saklanır.

18. Error Analysis Yapın

Confusion matrix ve yanlış örnekler incelenir. Hata taxonomy oluşturulur. Data problem ve model problem ayrıştırılır. Hard negative adayları çıkarılır. Kritik sınıflar önceliklendirilir.

19. Eksik Veri Segmentlerini Tamamlayın

Coverage gap için targeted collection yapılır. New edge case ve minority examples eklenir. Sentetik data gerekiyorsa human review uygulanır. Yeni örnekler ayrı provenance taşır. Dataset minor version hazırlanır.

20. Dataset'i Sürümleyin ve Dokümante Edin

Release version ve changelog yayınlanır. Dataset card güncellenir. Quality report artifact olarak saklanır. Training-ready immutable revision oluşturulur. Model registry bu version'a referans verir.

Özel NLP Veri Seti Hazırlarken En Sık Yapılan Hatalar

Özel NLP veri seti hazırlama ve veri etiketleme hizmeti planlanırken yalnızca örnek sayısına odaklanmak en yaygın hatalardan biridir. Görev tanımı, taxonomy, agreement ve leakage kontrolleri çoğu zaman daha yüksek öneme sahiptir. Türkçe preprocessing hataları data kalitesini sessizce bozabilir. PII ve lisans konularını son aşamaya bırakmak proje riskini artırır. Sürdürülebilir dataset programı versioning ve production feedback döngüsünü ilk günden planlamalıdır.

Görevi Tanımlamadan Veri Toplamak

Çok veri toplamak doğru veri toplamak anlamına gelmez. Output ve metric tanımlı değilse hangi örneğin değerli olduğu bilinmez. Annotation sonradan değişebilir. Gereksiz data privacy ve storage yükü oluşturur. Önce iş problemi ve task belirlenmelidir.

Label'ları Belirsiz Tanımlamak

Belirsiz label düşük agreement üretir. Model aynı metni farklı sınıflara öğrenir. Negative example eksikliği boundary kararını zorlaştırır. Pilot annotation sorunu erken gösterir. Taxonomy gerekli durumda sadeleştirilmelidir.

Tek Annotator Kullanmak

Tek kişinin bias'ı dataset'e yayılabilir. Agreement ölçülemez. Golden test yalnızca sınırlı kontrol sağlar. En azından pilot ve kritik subset double annotation yapılmalıdır. Domain expert disagreement review'da kullanılabilir.

Annotation Agreement Ölçmemek

Annotator'lar aynı guideline'ı farklı anlayabilir. Yüksek örnek sayısı bu problemi çözmez. Kappa veya Alpha gibi metric kullanılabilir. Sınıf bazlı disagreement incelenmelidir. Düşük agreement model ceiling'ini sınırlar.

Sadece Kolay Örnekleri Toplamak

Kolay örnekler yüksek offline skor oluşturabilir. Production'da hard negative ve edge case daha zordur. Confusion pair'leri bilinçli eklenmelidir. Active learning zor örnek bulabilir. Test set özellikle challenge örnekleri içermelidir.

Class Imbalance'ı Görmezden Gelmek

Çoğunluk sınıfı accuracy'yi yapay yükseltebilir. Minority recall düşük kalabilir. Distribution ölçülmelidir. Targeted collection ve class weight seçenekleri kullanılabilir. Macro F1 raporlanmalıdır.

Duplicate Verileri Farklı Split'lere Dağıtmak

Bu hata test skorunu doğrudan şişirir. Exact ve semantic duplicate temizliği split öncesinde yapılmalıdır. Same document veya conversation group birlikte tutulmalıdır. Leakage test otomatik olmalıdır. Release quality gate overlap olduğunda fail etmelidir.

Test Setini Defalarca Kullanarak Overfit Etmek

Her model denemesini test skoruna göre ayarlamak test setini validation'a dönüştürür. Test sonucu yalnızca final karar noktalarında kullanılmalıdır. Development için validation set bulunmalıdır. Gerekirse yeni hidden test set hazırlanır. Benchmark governance bu riski azaltır.

Gereğinden Fazla Text Cleaning Yapmak

Noktalama, emoji ve büyük harf anlam taşıyabilir. Transformer modelleri ham yapıyı işleyebilir. Aşırı temiz metin production input'tan uzaklaşır. Her transformation etkisi validation ile test edilmelidir. Teknik gürültü ile dilsel bilgi ayrılmalıdır.

Türkçe Karakterleri Kaybetmek

ASCII normalization Türkçe kelimeleri bozabilir. Yanlış encoding farklı token distribution üretir. I ve İ dönüşümü locale-aware olmalıdır. Quality test bozuk karakter pattern'lerini aramalıdır. Raw data mümkün olduğunca korunmalıdır.

PII ve Telif Haklarını Görmezden Gelmek

Model başarılı olsa bile hukuki olarak kullanılamayan dataset ciddi proje kaybıdır. Veri izni başta kontrol edilmelidir. PII anonimleştirilmelidir. Provenance silme ve lisans yönetimini kolaylaştırır. Hukuk ve güvenlik review training öncesinde yapılmalıdır.

Dataset Versioning Yapmamak

Versioning yoksa model sonuçları yeniden üretilemez. Hangi label'ın ne zaman değiştiği bilinmez. Test set değişikliği performans karşılaştırmasını bozar. Dataset release immutable olmalıdır. Model metadata dataset version taşımalıdır.

Model Hatalarını Dataset Geliştirmede Kullanmamak

Production hataları en değerli veri kaynaklarından biridir. Aynı modeli tekrar eğitmek yeni bilgi eklemez. Error analysis veri eksik segmentlerini gösterir. Human review ile yeni ground truth üretilebilir. Dataset ve model birlikte iteratif geliştirilmelidir.

Sık Sorulan Sorular

Doğal Dil İşleme (NLP) Modelleri İçin Özel Veri Seti Hazırlama konusunda en sık sorulan sorular veri miktarı, format, annotation ve split yöntemi etrafında toplanır. Tek bir doğru örnek sayısı veya split oranı bütün projelere uygulanamaz. Görev, class dağılımı ve production koşulları kararı değiştirir. Aşağıdaki yanıtlar güçlü bir başlangıç çerçevesi sunar. Gerçek proje kararı küçük pilot, kalite ölçümü ve baseline model sonucuyla verilmelidir.

NLP için veri seti nasıl hazırlanır?

Önce iş problemi ve NLP görevi tanımlanır. Label schema ve annotation guideline hazırlanır. Veriler izinli kaynaklardan toplanır, temizlenir ve kişisel bilgiler kontrol edilir. Annotation kalite ölçümü yapıldıktan sonra leakage güvenli train, validation ve test split oluşturulur. Dataset versionlanır, dokümante edilir ve baseline model ile test edilir.

NLP modeli eğitmek için kaç örnek gerekir?

Tek bir sabit sayı yoktur. Basit binary classification yüzlerce veya birkaç bin kaliteli örnekle başlayabilir. Çok sayıda intent veya nadir entity daha fazla veriye ihtiyaç duyabilir. Pretrained transformer ve fine-tuning veri ihtiyacını azaltabilir. En doğru yaklaşım learning curve ölçüp yeni data eklendiğinde performansın nasıl değiştiğine bakmaktır.

NLP verileri nasıl etiketlenir?

Manual, model-assisted, LLM-assisted veya weak supervision yöntemleri kullanılabilir. Label guideline açık olmalıdır. Kritik subset birden fazla annotator tarafından etiketlenebilir. Agreement ve golden accuracy ölçülmelidir. Anlaşmazlıklar adjudication ile final karara dönüştürülmelidir.

NLP için en iyi veri formatı hangisidir?

Tek bir en iyi format yoktur. Basit classification için CSV yeterli olabilir. LLM conversation ve QA için JSONL daha esnektir. Büyük dataset'te Parquet güçlü performans sağlar. NER interoperability için CoNLL kullanılabilir.

Train, validation ve test oranları ne olmalıdır?

80/10/10 veya 70/15/15 gibi oranlar başlangıç örneği olabilir ancak zorunlu değildir. Veri azsa validation ve test yeterli güvenilir örnek içermelidir. Split oranından daha önemli konu leakage olmamasıdır. Group ve temporal split gerçek production senaryosunu daha iyi temsil edebilir. Test set değişmeden korunmalıdır.

NLP veri setindeki sınıf dengesizliği nasıl çözülür?

Önce production dağılımı ile dataset dağılımı karşılaştırılır. Minority class için targeted data collection uygulanabilir. Oversampling, class weight ve sentetik veri destek olabilir. Test setin yapay şekilde tamamen dengelenmesi her zaman doğru değildir. Macro F1 ve per-class recall izlenmelidir.

Türkçe NLP veri seti hazırlarken nelere dikkat edilmelidir?

Türkçe karakterler ve locale-aware case dönüşümü korunmalıdır. Eklemeli dil yapısı tokenizer davranışını etkiler. Yazım hatası, argo ve code-switching gerçek kullanıcı dağılımında bulunabilir. Aşırı stemming veya ASCII normalization yapılmamalıdır. Bölgesel ve sektör özelindeki terminoloji coverage kapsamında değerlendirilmelidir.

ChatGPT veya başka bir LLM veri etiketlemek için kullanılabilir mi?

Evet, LLM prelabeling ve annotation desteği için kullanılabilir. Ancak nihai ground truth olarak otomatik kabul edilmemelidir. Golden dataset üzerinde LLM annotation accuracy ölçülmelidir. Düşük confidence ve kritik örnekler insan review'a gönderilmelidir. LLM bias ve prompt değişikliği tutarlılığı etkileyebilir.

Sentetik veri NLP modellerinde kullanılabilir mi?

Evet, özellikle minority class ve edge case üretiminde yararlı olabilir. Gerçek veri dağılımını tamamen değiştirmemelidir. Duplicate ve style repetition kontrol edilmelidir. Human validation kaliteyi artırır. Sentetik veri oranı ve kaynak modeli dataset metadata'sında tutulmalıdır.

Hugging Face'e özel veri seti nasıl yüklenir?

Önce Dataset veya DatasetDict oluşturulabilir. Schema ve split'ler doğrulanmalıdır. Dataset card hazırlanmalıdır. Hassas veri için private repository kullanılmalıdır. Belirli revision training script'te pinlenebilir.

NER veri seti nasıl hazırlanır?

Önce entity taxonomy ve boundary kuralları tanımlanır. Metinler character span veya token-level biçimde etiketlenir. BIO veya BIOES export hazırlanabilir. Tokenizer kullanıldığında token-label alignment yapılmalıdır. Entity-level F1 ve annotation agreement ölçülmelidir.

BERT için veri seti nasıl hazırlanır?

Dataset BERT tokenizer ile tokenization öncesinde temiz raw text olarak hazırlanmalıdır. Classification label schema açık olmalıdır. Train-validation-test leakage güvenli biçimde ayrılmalıdır. Tokenization model checkpoint ile uyumlu tokenizer kullanılarak yapılır. Padding, truncation ve attention mask training pipeline'da uygulanır.

LLM fine-tuning veri seti nasıl hazırlanır?

Instruction, input ve output çiftleri kaliteli ve görev odaklı hazırlanmalıdır. Conversation format gerekiyorsa role yapısı korunmalıdır. LLM-generated yanıtlar human validation'dan geçirilmelidir. Duplicate ve template repetition azaltılmalıdır. Evaluation için training'den bağımsız gerçek kullanıcı prompt seti tutulmalıdır.

Dataset leakage nasıl tespit edilir?

Exact hash overlap, user group overlap ve document ID intersection kontrol edilir. Semantic similarity train ve test arasında yüksek yakınlıkları gösterebilir. Preprocessing pipeline yalnızca train istatistiğiyle fit edilmelidir. Public benchmark contamination ayrıca değerlendirilmelidir. Her dataset release otomatik leakage testinden geçmelidir.

Dataset versioning neden önemlidir?

Versioning hangi modelin hangi veriden üretildiğini gösterir. Label ve split değişiklikleri izlenebilir. Reproducibility ve rollback kolaylaşır. Dataset card ve changelog her release ile güncellenebilir. Model registry dataset revision'a referans verebilir.

Doğal Dil İşleme (NLP) modelleri için özel veri seti nasıl hazırlanır?

NLP modelleri için özel veri seti nasıl hazırlanır sorusunun ilk cevabı veri toplamaya başlamadan görevi ve başarı kriterini tanımlamaktır. Ardından gerçek kullanım senaryosunu temsil eden izinli veri kaynakları seçilir, ham metin temizlenir ve gerekli kişisel bilgiler anonimleştirilir. Label taxonomy ve annotation guideline oluşturulduktan sonra pilot etiketleme yapılıp annotator agreement ölçülmelidir. Ana annotation sonrasında duplicate, leakage, class distribution ve PII kalite kontrolleri çalıştırılmalıdır. Son aşamada veri train, validation ve test split'lerine ayrılır, versionlanır, dataset card hazırlanır ve baseline model üzerinde değerlendirilir.

NLP veri setlerinde veri temizleme, etiketleme ve ön işleme süreçleri nasıl uygulanmalıdır?

Temizleme işlemi teknik gürültüyü azaltmalı ancak dilsel anlamı taşıyan emoji, noktalama veya Türkçe karakterleri gereksiz yere yok etmemelidir. Exact ve semantic duplicate, encoding hatası, HTML kalıntısı ve eksik kayıtlar otomatik pipeline ile kontrol edilebilir. Etiketleme açık guideline, örnekler, agreement ölçümü ve gerektiğinde adjudication ile yürütülmelidir. Tokenization gibi model-specific ön işleme adımları raw dataset'ten ayrı ve yeniden üretilebilir tutulmalıdır. Modern transformer modellerinde aşırı lowercase, stemming veya stop word temizliği varsayılan çözüm olarak kullanılmamalıdır.

Metin sınıflandırma, duygu analizi ve Named Entity Recognition (NER) için veri seti formatı nasıl oluşturulmalıdır?

Metin sınıflandırmada temel schema text ve label alanlarından oluşabilir; multi-label görevlerde label listesi kullanılmalıdır. Duygu analizinde positive, negative ve neutral gibi sınıflar açık guideline ile tanımlanmalı ve ironik veya karışık örnekler ayrıca ele alınmalıdır. NER veri setinde entity sınırları character span veya token-level annotation biçiminde tutulabilir. BIO veya BIOES formatı training export için yaygın çözümdür ve subword tokenizer kullanıldığında token-label alignment yapılmalıdır. Bütün görevlerde source, dataset version ve gerekli metadata alanları kalite ve provenance için saklanmalıdır.

NLP modellerinde veri kalitesi, sınıf dengesi ve eğitim-doğrulama-test ayrımı nasıl yönetilmelidir?

Veri kalitesi missing value, invalid label, duplicate, annotation agreement, PII ve leakage testleriyle düzenli ölçülmelidir. Class imbalance gerçek production dağılımı dikkate alınarak targeted collection, class weight veya kontrollü sentetik veriyle yönetilebilir. Accuracy tek başına yeterli olmadığı için macro F1 ve per-class recall gibi metrikler kullanılmalıdır. Train-validation-test split oluştururken aynı kullanıcı, document veya conversation'ın birden fazla split'e dağılması engellenmelidir. Test set geliştirme kararlarında tekrar tekrar kullanılmamalı ve tarafsız final değerlendirme için korunmalıdır.

NLP için özel veri seti hazırlama ve model geliştirme konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

NLP veri seti hazırlama ve yapay zeka danışmanlığı yakınımda şeklinde araştırma yaparken yalnızca model eğitimi sunan değil veri toplama, annotation guideline, kalite ölçümü ve MLOps süreçlerini birlikte ele alan teknik yaklaşım tercih edilmelidir. Diyarbakır'daki yazılım topluluğu, proje ve eğitim çalışmaları hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about sayfasını inceleyebilirsiniz. Topluluk tarafından geliştirilen veya paylaşılan proje çalışmalarına https://www.diyarbakiryazilim.com.tr/projects adresinden ulaşabilirsiniz. Özel NLP veri seti hazırlama ve veri etiketleme hizmeti değerlendirilirken veri lisansı, kişisel veri, annotation kalite ölçümü ve dataset versioning gibi başlıkların proje kapsamına dahil edilmesi önemlidir. Küçük bir pilot dataset ile başlayıp baseline model ve error analysis sonucuna göre veri kapsamını büyütmek hem maliyet hem kalite açısından daha kontrollü bir yöntemdir.

Sonuç

Doğal Dil İşleme (NLP) Modelleri İçin Özel Veri Seti Hazırlama, yalnızca veri toplama ve birkaç label ekleme işi değildir. Başarılı süreç görev tanımı, veri provenance, kişisel veri kontrolü, annotation guideline, agreement ölçümü, duplicate temizliği, leakage kontrolü, versioning ve model evaluation aşamalarını tek zincirde birleştirir. Özellikle Türkçe NLP projelerinde karakter yapısı, eklemeli dil özellikleri, günlük dil, code-switching ve sektörel terminoloji dataset tasarımında bilinçli biçimde ele alınmalıdır. Model performansını geliştirmek isteyen ekiplerin daha büyük modele geçmeden önce yanlış label'ları, hard negative örnekleri ve coverage boşluklarını incelemesi çoğu zaman daha etkili sonuç verir. Türkçe NLP, açık kaynak veri setleri ve topluluk tabanlı yapay zeka projeleri üzerine çalışmak için https://www.diyarbakiryazilim.com.tr adresi üzerinden Diyarbakır Yazılım Topluluğu ile bağlantı kurabilirsiniz.