Full Taxonomy of Label Types: From Classification to Preference, 14 Formats

Neden Tam Taksonomi Önemli?#

• Model olası tavanı düşer
• Etiketleme maliyeti 2-10x artabilir
• Aynı veriyi tekrar etiketlemek zorunda kalırsınız (yıkıcı)

Üç Eksende Sınıflandırma#

1) Single-Label Classification (Tekli Sınıflandırma)#

"Ürün vaktinde geldi"  →  pozitif
"Kargo gecikti"        →  negatif
"Açıklamada yazandı"   →  nötr

• ❌ "Diğer" sınıfı koymak çoğu zaman tuzak — etiketleyiciler kararsız kalınca buraya doluyor.
• ❌ Sınıf sayısı 8'den fazlaysa annotator yorulur, IAA düşer.
• ❌ Hiyerarşi gerektiren bir taxonomy için bu format dar gelir → multi-label veya hierarchical kullan.

2) Multi-Label Classification (Çoklu Etiket)#

"Galatasaray UEFA Avrupa Ligi'nde Ajax'ı 2-1 yendi, transfer dönemi açıldı"
  → [spor, futbol, avrupa-ligi, transfer]

• ❌ "Bu etiketler bağımsız değil" — örneğin "spor" varsa "futbol" otomatik anlamına gelir. Hiyerarşik düşün.
• ❌ Etiket sayısı 20'yi geçince annotator hata oranı patlar. Hierarchical multi-label kullan veya alt task'lara böl.
• ❌ Negatif etiketler genellikle örtük — "spor değil mi?" diye sormuyorsun. Bu, weak negative örnekleri zorlar.

3) Hierarchical Classification (Hiyerarşik)#

elektronik
  └─ telefon
       ├─ akıllı telefon
       │    ├─ android
       │    └─ ios
       └─ tuşlu
  └─ bilgisayar
       ├─ dizüstü
       └─ masaüstü

• ❌ Hiyerarşi 4'ten derin olunca annotator hata patlar.
• ❌ "Aile" — bir örneğin birden fazla path'i varsa multi-label hierarchical olur.
• ❌ Schema versiyon kontrolü kritik. "Yeni alt kategori ekledim" deyince eski tüm etiketler ne olacak?

4) Ordinal Classification (Sıralı)#

Yorum kalite skoru:
  1 - Çok kötü
  2 - Kötü
  3 - Orta
  4 - İyi
  5 - Çok iyi

• ❌ Likert skala anchor noktaları annotator'a göre değişir — "3" senin için orta, benim için kötü olabilir. Anchor örnekleri kılavuza koy.
• ❌ Skala 7'yi geçince annotator orta noktaları kullanır (center bias).
• ❌ Ordinal metriklerini gerçekten ordinal modelle eğit (cross-entropy değil ordinal loss).

5) Named Entity Recognition (NER) — Span Annotation#

"Trendyol İstanbul'da kuruluyor ve Aslı Erdoğan ile çalışıyor."
   ──┬───  ──────┬──                       ─────┬────
   ORG          LOC                              PER

• ❌ "Aslı Erdoğan" tek varlık mı yoksa iki ("Aslı", "Erdoğan")? Schema'da netleş.
• ❌ Nested entities ("İstanbul Boğazı" hem LOC hem LOC içinde başka LOC) — schema desteği lazım.
• ❌ Türkçe agglutinasyon ("İstanbul'da" → span "İstanbul" mi yoksa "İstanbul'da" mı?).
• ❌ BIO/BIOES/IO encoding seçimi modelin tipini etkiler.

6) Span Classification (Genel)#

"Yatırımcılar borsadan çıkıyor [çünkü faiz oranları yükseliyor]."
                                ───────── PREMISE ─────────

7) Relation Extraction (RE)#

"Trendyol, Demirören Holding tarafından satın alındı."
   ──┬───                ────┬──────────
   Şirket-A           Şirket-B
        └─── ilişki: SATIN_ALINDI_BY ──→

• ❌ Cümleler arası ilişkiler (cross-sentence) çok zor.
• ❌ Aynı entity çifti için birden fazla ilişki mümkün mü? Schema'da kararlaştır.
• ❌ "Hiçbir ilişki yok" (negative pairs) örneklenmiyorsa model yanlı öğrenir.

8) Bounding Box (BBox) — Object Detection#

[image]
  ┌────┐     ← araba
  │ 🚗 │
  └────┘
        ┌──┐   ← yaya
        │🚶│
        └──┘

• ❌ Sıkı kutu mu gevşek kutu mu? Schema kararlaştır.
• ❌ Kısmen görünen (occluded) nesneler dahil mi?
• ❌ Çok küçük (< 32px) nesneler dahil mi?
• ❌ Iki nesne üst üste — iki ayrı BBox çiz veya bir?

9) Polygon Annotation#

Yaprak şeklinde organik nesne → BBox kullanışsız, polygon kesin

• ❌ Kaç vertex? Çok az → kaba; çok çok → annotator yorulur. Tipik 8-30.
• ❌ Polygon vs mask trade-off: storage vs precision.
• ❌ Concave (içbükey) polygon desteği bazı modellerde yok.

10) Semantic Segmentation#

• ❌ "Don't care" pikseller var mı? (sınır pikselleri, çok küçük detaylar)
• ❌ Mask boyutu storage problemi olabilir (1080p → 2MB mask).
• ❌ Pixel-exact karar genelde mümkün değil; bir tolerans kabul edilmeli (Modül 7).

11) Instance + Panoptic Segmentation#

• Instance segmentation: Her sınıfın her örneğini ayrı renkle (2 araba = 2 farklı maske).
• Panoptic segmentation: Instance + Semantic birleşimi. Her piksel hem sınıf hem instance ID alır.

12) Keypoint Annotation#

Burun, sol göz, sağ göz, sol kulak, sağ kulak,
sol omuz, sağ omuz, sol dirsek, sağ dirsek,
sol bilek, sağ bilek, sol kalça, sağ kalça,
sol diz, sağ diz, sol ayak bileği, sağ ayak bileği

13) Ranking & Preference Annotation#

Soru: "İstanbul'da 1 günlük gezi planı önerir misin?"

Yanıt A: [Çok detaylı, 8 mekan, ulaşım dahil]
Yanıt B: [Kısa, 3 mekan]

Tercih: A daha iyi (helpfulness: 4 vs 2)

• ❌ "Berabere" seçeneği: Net analiz için tehlikeli. Forced choice öner.
• ❌ Çok uzun yanıtlar — annotator yorulur, sondaki detayları kaçırır.
• ❌ Annotator bias: aynı kişiden 100+ tercih → mental drift.

14) Free-Form Generation (Open-Ended Annotation)#

Prompt: "İstanbul'un en eski semtleri hangileridir?"

Annotator yanıtı: "İstanbul'un en eski semtleri tarihte
ön plana çıkmış olan Eminönü, Fatih, Eyüpsultan ve
Beyazıt'tır. Bunlardan Eminönü Bizans döneminden..."

• ❌ Yazma stili tutarsız → modelin "kişiliği" gürültülü.
• ❌ Kılavuz çok katı → cevaplar formula gibi, çeşitlilik düşer.
• ❌ Annotator kalitesi her şey. 1 kötü annotator = 100 zayıf SFT örneği.

Karşılaştırma Tablosu — Hızlı Referans#

Özet#

• Format seçimi schema'dan önce gelir.
• Klasik formatlar (1-12) hâlâ AI'ın %70'ini oluşturur.
• Modern formatlar (13-14) RLHF/SFT'in temeli — burası geleceğin sıcak alanı.
• Karmaşık problemler birden fazla format birleştirir (hibrit): örneğin BBox + classification + keypoint.