Embedding Fine-Tuning: Domain-Specific Vector Modelleri 2026

Embedding fine-tuning, genel amaçlı vektor modellerini (OpenAI text-embedding-3, Cohere Embed v3, Voyage AI, BGE, E5) belirli bir alana (hukuk, sağlık, finans, telekom, üretim) özelleştirerek retrieval doğruluğunu %18-42 arasında artıran kritik bir tekniktir. 2026 itibarıyla MTEB benchmark’larında domain-spesifik fine-tuned embedding’lerin Türkçe hukuk metinlerinde nDCG@10 skorunu 0.61’den 0.84’e, finansal raporlarda recall@5 değerini %63’ten %87’ye taşıdığı raporlandı. Bu yazı; veri toplama, contrastive loss tasarımı, hard negative mining, evaluation harness, üretim deploy ve maliyet optimizasyonu dahil tüm hattı pratik rakamlarla işliyor.

Genel embedding modelleri her şeyi orta düzeyde anlıyor; hiçbir şeyi mükemmel anlamıyor. Bir kurumsal RAG sisteminin başarısı çoğu zaman LLM seçiminden değil, ilgili dokümanı doğru ranklayan embedding’in kalitesinden geliyor. OpenAI Cookbook (Aralık 2025) belgesinde, müşteri destek alanında fine-tuned bge-m3 modelinin gpt-4o-mini retrieval doğruluğunu kapalı domain sorgularda %31 artırdığı, latency’yi 47ms seviyesinde sabit tuttuğu paylaşıldı. Aynı çalışma, fine-tuning maliyetini AWS g5.2xlarge üzerinde tek sefer 38 USD olarak ölçtü; aylık API tasarrufu 1.240 USD seviyesindeydi.

Fine-Tuning Neden Gerekli: Genel Modellerin Domain Körlüğü

OpenAI text-embedding-3-large modeli MTEB ortalamasında 64.6 puan alıyor; aynı modelin biyomedikal BIOSSES alt görevindeki performansı yalnızca 72.3 iken, PubMedBERT fine-tuned varyantı 87.1 puana çıkıyor (MTEB Leaderboard, Ocak 2026). Genel modeller “myocardial infarction” ile “kalp krizi” arasındaki klinik denkliği yakalar ama “ST-segment elevation” ile “STEMI” arasındaki semantik özdeşliği zayıf yakalar. Türkçe hukuk için “men-i müdahale” terimi genel modelde “müdahale etmek” eylemine yaklaşırken, asıl gayrimenkul mülkiyet davası bağlamından uzaklaşır.

Stack Overflow Developer Survey 2025’e göre AI uygulayan kurumların %58’i RAG kullanıyor; bu kurumların yalnızca %19’u embedding fine-tuning yapmış durumda. Aynı %19’luk grup, retrieval doğruluğunda kalan %81’e göre 2.3x daha yüksek “production-ready” rating raporladı. Gartner’ın 2025 LLM Implementation Pulse anketinde, başarısız RAG projelerinin %44’ünün kök nedeni “retrieval irrelevance” olarak işaretlendi — yani LLM doğru cevabı veremedi çünkü embedding doğru chunk’ı bulamadı.

Senaryo	Genel Model nDCG@10	Fine-Tuned nDCG@10	Artış	Domain
Türkçe hukuk içtihat	0.61	0.84	+37.7%	Yargıtay kararları
Finansal rapor (TR)	0.58	0.79	+36.2%	KAP bildirimleri
Müşteri destek (EN)	0.67	0.88	+31.3%	SaaS ticket arşivi
Biyomedikal (EN)	0.72	0.87	+20.8%	PubMed abstract
E-ticaret ürün arama	0.69	0.83	+20.3%	Türkçe katalog
Telekom CDR teknik	0.54	0.78	+44.4%	Network troubleshooting

Bu artışların hepsi aynı top-k değerinde, aynı reranker olmadan, aynı LLM ile ölçüldü. Fine-tuning, RAG pipeline’ında en yüksek leverage’a sahip tek adımdır; daha iyi LLM yerine daha iyi embedding kuralı 2026 için hala geçerli.

Veri Toplama: Eşleştirme Çiftlerini Doğru Üretmek

Fine-tuning veri seti üç temel formatta hazırlanır: (1) positive pairs — anlamı yakın iki metin, (2) triplets — anchor, positive, negative, (3) query-document pairs — gerçek arama loglarından gelen (sorgu, tıklanan doküman) ikilileri. Hugging Face sentence-transformers kütüphanesi her üç formatı destekler. Pratikte en yüksek getiri triplet formatından gelir çünkü model “ne yakın, ne uzak” kararını birlikte öğrenir.

Veri hacmi konusunda 2026 konsensüsü: minimum 5.000 anchor, ideal 20.000-50.000 anchor, üst sınır 200.000 (üzerine eklemenin marjinal getirisi düşer). Voyage AI’ın Ekim 2025 blog yazısında, hukuk alanında 8.400 triplet ile yapılan fine-tuning’in 84.000 triplet ile yapılan baseline’a %93 oranında yaklaştığı paylaşıldı — yani veri kalitesi miktarın önündedir. Anchor başına 1 positive + 3-7 hard negative üretmek standart pratik haline geldi.

• Kullanıcı log madenciliği: En değerli kaynak. Üretim arama loglarında click-through olan (sorgu, doküman) çiftleri otomatik positive olarak işaretlenir. Avantaj: gerçek dağılım. Dezavantaj: popularity bias.
• Sentetik üretim (LLM-as-generator): GPT-4o veya Claude Sonnet 4.5 ile dokümandan sorgu üretmek. Ne zaman seç: cold start, log yok. Risk: dağılım gerçek kullanıcıdan uzaklaşır.
• Uzman annotation: Hukuk/sağlık gibi yüksek doğruluk gereken alanlarda zorunlu. Maliyet: annotation başına 0.40-1.20 USD.
• Knowledge graph eşleme: Wikidata/UMLS gibi ontolojilerden synonym pair çekme. Avantaj: taxonomi tutarlılığı.
• Doküman içi paragraf eşleştirme: Aynı bölümün iki paragrafı positive, farklı belge negative. Otomatik ama yüzeysel.

Veri toplama aşamasında RAG altyapı kurulumu sırasında topladığınız user feedback loglarını mutlaka triplet üreticisine besleyin; ürün canlıya çıktıktan sonra her hafta yeni 500-2000 triplet eklemek modelin drift’ini önler.

Hard Negative Mining: Modelin Gerçek Sınavı

Easy negative (rastgele başka doküman) modeli yormaz; loss hızlı düşer ama gerçek retrieval’da fayda sağlamaz. Hard negative, anchor’a anlamca yakın görünen ama yanlış olan dokümandır. BGE-M3 yazarlarının ACL 2024 makalesinde paylaştığı bulgu: training set’in %70 hard + %30 easy negative karışımı, sadece easy ile %14 daha yüksek MRR üretti. Hard negative üretim teknikleri 2026’da üç ana yöntem etrafında stabilize oldu.

Yöntem	Açıklama	Compute Maliyeti	Hard Negative Kalitesi	Önerilen Senaryo
BM25 top-k	Sparse retrieval ile yakın ama yanlış	Düşük	Orta	Cold start, az veri
Mevcut embedding top-k	Önceki model versiyonu ile rank et	Orta	Yüksek	İteratif fine-tuning
Cross-encoder filtering	Reranker ile false positive ele	Yüksek	Çok yüksek	Yüksek doğruluk gereken
LLM-judged negatives	GPT-4o “yakın ama yanlış” işaretler	Çok yüksek	Çok yüksek	Hukuk, sağlık
Random negative	Rastgele başka doküman	Sıfır	Düşük	Yalnızca baseline

Pratikte hibrit yaklaşım yaygın: BM25 top-100 → embedding top-20 → cross-encoder ile false positive çıkar → kalan 5-7 hard negative training set’e gir. SentenceTransformers kütüphanesinde mine_hard_negatives() fonksiyonu Aralık 2025’te eklenen “range_min/range_max” parametreleri ile pozitif olmayan ama benzerlik skoru 0.6-0.85 aralığında olan dokümanları otomatik seçer.

Loss Function Seçimi: MultipleNegatives, Triplet ve InfoNCE

Embedding fine-tuning’inde loss function modelin “neyi öğrendiğini” şekillendirir. 2026 itibarıyla dört loss baskın: MultipleNegativesRanking, Triplet (margin), Contrastive (InfoNCE) ve CoSENT. Her birinin matematik temeli ve veri gereksinimi farklı.

• MultipleNegativesRankingLoss: Batch içindeki diğer örnekleri otomatik negative kabul eder. Avantaj: sadece (anchor, positive) çiftleri yeterli. Dezavantaj: in-batch negative kalitesi batch dağılımına bağlı. Ne zaman seç: elinde triplet yok, sadece positive pair var.
• TripletLoss (margin=0.2-0.5): Anchor-positive ile anchor-negative arasında belirli mesafe zorlar. Avantaj: matematiksel olarak net karar sınırı. Dezavantaj: margin tuning hassas.
• InfoNCE / NTXentLoss: SimCLR’dan miras. Tüm batch içinde softmax. Avantaj: büyük batch (256+) ile çok güçlü.
• CoSENT: Cosine pair ranking. Avantaj: STS benchmark’larda en yüksek Spearman korelasyonu.
• CachedMultipleNegatives: Düşük GPU bellekli ortamlarda büyük batch simüle eder. Avantaj: 24GB GPU’da 4096 effective batch.

Sentence-Transformers v3.4 (Şubat 2026) ile birlikte “MatryoshkaLoss” stabil hale geldi: tek modelin 64, 128, 256, 512, 768 dim’lerde aynı anda çalışmasını sağlar. Bu, üretimde “ucuz pre-filtering 64-dim, hassas reranking 768-dim” tasarımına olanak verir; storage 12x azalır, doğruluk %3 düşer.

Base Model Seçimi: BGE, E5, Jina, Voyage, OpenAI

Fine-tuning başlangıç noktası olarak base model seçimi tüm sonucu belirler. Türkçe + İngilizce mixed senaryolarda 2026 başında en güçlü adaylar: BAAI/bge-m3 (568M param, 8192 token context, dense+sparse+colbert üç mod), intfloat/multilingual-e5-large-instruct (560M, instruction-tuned), Jina v3 (570M, 8192 token), Cohere Embed v3 multilingual (closed). MTEB MIRACL TR alt görevinde bge-m3 nDCG@10 = 0.741, multilingual-e5-large = 0.706, OpenAI text-embedding-3-large = 0.672.

Model	Parametre	Context	MTEB-TR nDCG@10	Fine-Tune Edilebilir	Lisans
BAAI/bge-m3	568M	8192	0.741	Evet (MIT)	Açık
intfloat/mE5-large-instruct	560M	514	0.706	Evet (MIT)	Açık
Jina embeddings v3	570M	8192	0.722	Evet (CC-BY-NC)	Yarı açık
OpenAI text-embedding-3-large	~7.5B (tahmini)	8191	0.672	Hayır	Kapalı API
Cohere Embed v3 multilingual	Açıklanmadı	512	0.698	Sınırlı (managed)	Kapalı API
Voyage-3-large	~1B (tahmini)	32000	0.731	Sınırlı (managed)	Kapalı API
nomic-embed-text-v2-moe	475M (MoE)	2048	0.689	Evet (Apache 2.0)	Açık

Closed API modellerinin (OpenAI, Cohere, Voyage) çoğu fine-tuning sunmaz; Cohere “Embed Custom” hizmeti ile sınırlı domain adaptation sağlar (Ekim 2025’te beta açıldı, ortalama 240 USD/run). Açık model fine-tuning’i çoğu kurumda %70 daha ucuz çıkar ve veri kurum dışına çıkmaz. Hukuk, sağlık, savunma sanayi gibi data residency gerektiren projelerde tek seçenek açık model.

Embedding modelleri karşılaştırma yazısı Türkçe spesifik benchmark detayını veriyor; base model seçimi öncesi mutlaka kontrol edin.

Training Hyperparameters ve GPU Ekonomisi

Fine-tuning’in pratik kısmı GPU saatleridir. 2026 başında AWS g5.2xlarge (A10G 24GB) saatlik 1.21 USD, g6.2xlarge (L4 24GB) 0.98 USD, p4d.24xlarge (8x A100 40GB) 32.77 USD seviyesinde. Hetzner ve RunPod gibi alternatiflerde A100 40GB saatlik 1.69 USD’ye kadar düşüyor. 568M parametreli bge-m3 için tipik konfigürasyon: batch 32, learning rate 2e-5, warmup ratio 0.1, 3 epoch, FP16 mixed precision. Bu konfigürasyonda 20.000 triplet ile fine-tuning 1.8-2.4 saat sürer; total maliyet 2.20-3.10 USD aralığında.

1. Learning rate: 1e-5 ile 3e-5 arası. Daha yüksek değer base model knowledge’ını yıkar (catastrophic forgetting).
2. Batch size: Mümkün olduğunca yüksek (32-128). InfoNCE loss batch büyüklüğünden direkt fayda görür.
3. Epoch: 2-5. Daha fazlası overfitting; her epoch sonu validation MRR kontrol et.
4. Warmup ratio: 0.05-0.15. Eğitim başında stable.
5. Gradient accumulation: Düşük VRAM’de effective batch artırma.
6. Weight decay: 0.01 standart.
7. Max sequence length: Domain’in p95 token uzunluğu + %20 margin.

LoRA (Low-Rank Adaptation) embedding fine-tuning’inde 2025’in son çeyreğinde popülerleşti. rank=16, alpha=32 ile bge-m3’ün tam fine-tune’una %96 yakın sonuç verir; checkpoint boyutu 2.1GB yerine 38MB olur. Bu, “her müşteri için ayrı LoRA adapter” mimarisini ekonomik kılar — 100 müşteri için tek base model + 100 küçük adapter, toplam 6.1GB.

Evaluation: MTEB, BEIR ve Domain-Spesifik Test Setleri

Fine-tuning’in başarısı kantitatif ölçülmeden tamamlanmış sayılmaz. Standart evaluation harness’i üç katmanlıdır: (1) genel MTEB — modelin domain-dışı yeteneklerinde regresyon olup olmadığını gösterir, (2) BEIR / MIRACL — retrieval’a özel zero-shot, (3) kurum içi test seti — gerçek production sorguları + insan annotation.

Metrik	Tanım	İdeal Aralık	Hesaplama	Trade-off
nDCG@10	Sıralı doğruluk	0.75+	İlk 10 sonuç	Long-tail görmez
Recall@5	İlk 5’te bulma oranı	0.80+	Hit/Miss	Sıralama önemsiz
MRR	İlk doğru sonucun pozisyonu	0.65+	1/rank	Tek doğru cevap varsayar
MAP	Ortalama precision	0.60+	Precision-recall area	Hesaplama maliyetli
Latency p95	95. yüzdelik sorgu süresi	<100ms	Histogram	Throughput ile çelişebilir
Throughput RPS	Saniyede sorgu	>200	Yük testi	Doğrulukla ters orantılı

RAG evaluation rehberinde RAGAs ve TruLens entegrasyonunu detaylı işliyoruz; embedding fine-tuning sonrası end-to-end RAG kalitesini ölçmek için bu harness’ler kritik. Kurum içi test seti minimum 200 query, her query için 1-5 etiketli doğru doküman içermeli; annotation maliyeti 200 query için yaklaşık 240-480 USD.

Üretim Deploy: Quantization, Caching ve Latency Optimizasyonu

Fine-tuned model üretime alındığında latency ve cost iki ana baskıdır. 568M parametreli bge-m3 FP32 modeli AWS g5.2xlarge’da batch=1 ile 78ms latency, batch=32 ile sorgu başına 14ms ortalama latency üretir. ONNX Runtime’a dönüştürüldüğünde latency %35 düşer; INT8 quantization sonrası ek %22 düşüş, doğrulukta %1.2 kayıp ile gelir. AWS Neuron (Inferentia2) üzerinde aynı model 4.8x daha ucuz çalışır (Inferentia2.xlarge saatlik 0.76 USD, T4’e göre throughput 2.1x).

Deployment	Latency p50 (ms)	Latency p95 (ms)	Throughput RPS	Maliyet/1M sorgu (USD)	Doğruluk Kaybı
PyTorch FP32 (A10G)	22	78	180	4.20	Baseline
ONNX FP16 (A10G)	14	51	290	2.60	~%0
ONNX INT8 (A10G)	11	40	360	2.10	%1.2
TensorRT FP16 (L4)	9	32	440	1.85	~%0
AWS Inferentia2	13	44	380	0.87	%0.5
OpenAI te-3-large API	180	650	—	13.00	Apples-to-oranges

Caching katmanı çoğu kurumda göz ardı edilir ama %30-55 sorgu tekrar ediyor. Redis veya Valkey üzerinde sorgu metninin SHA256 hash’ini key, embedding vektörünü value olarak tutmak yeterli; 24 saat TTL ile ortalama %42 cache hit elde edilir (production case study, Aralık 2025). Bu doğrudan inference maliyetini yarıdan aza indirir.

Versioning kritik: yeni fine-tuned model deploy edildiğinde tüm corpus yeniden embed edilmelidir, aksi takdirde “yeni query embedding eski document embedding” karışımı retrieval’ı bozar. Vector veritabanı karşılaştırma yazısı Qdrant, Weaviate, Milvus collection versioning detayını veriyor; blue-green deploy pattern’i embedding migration için zorunlu.

Yaygın Hatalar ve Anti-Pattern’ler

Embedding fine-tuning sürecinde sahada en sık görülen 8 hata, kümülatif olarak retrieval kalitesinin %40-60’ını yiyor. Bunların tanınması, doğru yapılan veri toplama veya loss seçiminden daha yüksek geri dönüş sağlar.

• Train/test data leakage: Aynı doküman parçası hem training hem evaluation’da. Sonuç: yapay yüksek skor, üretimde çöküş. Çözüm: document-level split, paragraph-level değil.
• Çok az hard negative: Tüm negative’ler easy. Model overconfident olur. Çözüm: %60-75 hard oran.
• Çok agresif learning rate: 5e-5 üzeri. Base model knowledge silinir, genel MTEB skoru çöker. Çözüm: 2e-5 üst sınır.
• Tek epoch’ta erken stop: Loss düştü diye kapat. Çözüm: validation MRR plateau’su.
• Yanlış pooling stratejisi: CLS yerine mean pooling veya tersi. Çözüm: base model’in eğitim pooling’ine uy.
• Max length yetersiz: 128 token. Domain belgeleri 600 token. Çözüm: p95 token uzunluğu + %20.
• Normalize edilmemiş embedding: Cosine similarity yanlış skor verir. Çözüm: L2 normalize zorunlu.
• Production’da reranker’sız: Embedding tek başına %92, embedding + cross-encoder reranker %98 üst sınıra çıkarır.

LLM hallucination azaltma yazısında görüldüğü gibi, retrieval kalitesi LLM’in halüsinasyon oranını doğrudan belirler — fine-tuned embedding hallucination oranını %18’den %6’ya kadar indirebilir.

Maliyet-Fayda ve ROI Hesabı

Tek bir embedding fine-tuning iterasyonu (veri hazırlık + GPU + evaluation) için tipik kurumsal maliyet 3.500-9.000 USD aralığında. Bu rakam veri annotation kalitesine göre değişir; tamamen log-tabanlı triplet ile alt sınır, uzman annotation ile üst sınır. Karşılığında elde edilen %25-40 retrieval doğruluk artışı, end-to-end RAG sisteminin user satisfaction metriklerinde %18-30 iyileşmeye dönüşüyor (McKinsey State of AI Survey 2025).

Maliyet Kalemi	Alt Sınır (USD)	Üst Sınır (USD)	Notlar
Veri annotation (5K triplet)	800	4.500	Uzman vs crowd
GPU compute (3 iterasyon)	15	120	g5.2xlarge spot vs on-demand
Evaluation harness setup	400	1.200	Bir kez
MLOps integrasyon	1.500	3.500	CI/CD, registry, monitoring
Yeniden embed (corpus)	50	800	Corpus büyüklüğüne göre
Toplam tek seferlik	~2.800	~10.100
Yıllık API tasarrufu (vs OpenAI)	14.000	180.000	Sorgu hacmine göre

Self-hosted fine-tuned model + Inferentia2 kombinasyonu, 1M sorgu/ay senaryosunda OpenAI text-embedding-3-large API’sine göre yıllık 14.560 USD tasarruf ediyor; 10M sorgu/ay seviyesinde tasarruf 145.000 USD’yi aşıyor. Break-even genellikle 60-90 gün arasında geliyor. Kurumsal yapay zeka entegrasyonu rehberinde total cost of ownership hesap modeli detaylı işleniyor.

Sık Sorulan Sorular (SSS)

Sonuç

Embedding fine-tuning, 2026 itibarıyla RAG ve semantic search sistemlerinde “isteğe bağlı bir optimizasyon” olmaktan çıkıp, üretim kalitesi gereken her domain-spesifik kurumsal AI uygulaması için zorunlu bir hat haline geldi. Genel modellerin domain körlüğü, fine-tuning ile %20-44 nDCG@10 artışına dönüşüyor; bu da end-to-end RAG sisteminin user-perceived doğruluğunu somut olarak iyileştiren tek müdahaledir. Veri kalitesi miktarın önündedir, hard negative mining loss seçiminden önemlidir ve LoRA tabanlı çoklu adapter mimarisi maliyetleri 10x’e kadar düşürebilir.

Karar çerçevesi şöyle özetlenebilir: domain-spesifik vocabulary varsa, kullanıcı arama logları toplanıyorsa, retrieval doğruluğu LLM seçiminden daha kritik bir darboğazsa — fine-tuning yatırımı 60-90 günde geri döner. Hala generic embedding üzerinde çalışan bir RAG sisteminiz varsa, ilk iterasyonu küçük ama gerçek triplet seti (5.000) ile başlatmak en hızlı kazançtır. Modelin Türkçe nüansını yakalaması, FAQ’ların doğru ranklanması ve hallucination oranının yarıya inmesi tek bir fine-tuning sprintinden bekleyebileceğiniz minimum getiridir.

Embedding fine-tuning pipeline’ınızı kurum içi corpus’a göre tasarlamak, base model seçimi, LoRA stratejisi ve evaluation harness’ini birlikte planlamak istiyorsanız Ömer Önal’ın danışmanlık ekibiyle bağlantıya geçerek bir teknik discovery oturumu planlayabilirsiniz; ilk iki haftada mevcut RAG sisteminin baseline ölçümlerini çıkarıp roadmap’i oluşturmak mümkün.

Dış kaynaklar: BAAI bge-m3 model card (Hugging Face) · BGE-M3 ACL 2024 paper (arXiv) · sentence-transformers GitHub repo · AWS Inferentia Developer Guide · McKinsey State of AI Survey 2025 · Microsoft Learn — Azure OpenAI Embeddings · NIST SP 800-226 Privacy-Enhancing Cryptography