TB
← Tüm yazılar

Context + RAG + Fine-tune birlikte nasil çalışır?

Bağlam muhendisligi, RAG ve fine-tuning birbirinin yerine gecen degil tamamlayici katmanlardir; doğru siralama ve gorev ayrimi tutarlı ve güncel bir AI sistemi kurar. Tek basina RAG veya tek basina fine-tune çoğu üretim senaryosunda yetersiz kalir.

Modern üretim AI sistemleri genelde uc katmanı bir arada kullanır: context engineering (anlik bağlam ve prompt yapisı), RAG (dis bilgi getirme) ve fine-tuning (model davranisini kalıcı egilim olarak sekilleme). Bunlari tek bir teknik sanmak en yaygın mimari hatadir.

Her katmanin sorumlulugu

Context engineering, tek bir istek icinde modele neyin ve hangi sıra ile verilecegini tasarlar: sistem talimati, few-shot örnekler, kullanıcı mesaji, tool ciktilari. RAG, sabit prompt'a sigmayan bilgiyi vektor veya keyword aramasi ile getirir. Fine-tuning, model agirliklarinda domain dili, format ve karar egilimlerini kodlar.

Pratik kural: fact → RAG, form → fine-tune, anlik durum → context. Ürün fiyatlari RAG'den gelmeli; JSON çıktı formati fine-tune ile pekistirilebilir; kullanıcının son mesaji context'te kalir.

Neden hepsi birden?

Yalnizca RAG: model tonu ve format tutarsiz kalir, her istekte uzun talimat token yakar. Yalnizca fine-tune: bilgi kesilir, güncelleme icin yeniden egitim gerekir. Yalnizca context: token limiti ve maliyet hizla patlar. Ucunun birlesimi maliyet, guncellik ve tutarlılık dengesini sağlar.

Tipik istek akisi

  1. Kullanıcı sorusu gelir; context'e oturum ozeti eklenir.
  2. RAG sorgusu uretilir; ilgili parçalar alinir ve kaynak referansi tutulur.
  3. Fine-tune edilmis model, sabit sistem sablonu + RAG parcalari + kullanıcı girdisi ile cevap üretir.
  4. Cevap faithfulness kontrolunden gecer; gerekirse ikinci retrieval turu yapilir.
async function answer(query: string, session: Session) {
  const summary = await contextBuilder.summarize(session.messages);
  const chunks = await retriever.search(query, { tenant: session.tenant, topK: 8 });
  const prompt = assemblePrompt({
    system: tunedBehaviorTemplate,
    context: summary,
    evidence: chunks,
    user: query
  });
  return generate(prompt, { model: "ft-gpt-4o-mini-v2" });
}

Token butcesi yönetimi

Toplam pencere sinirlidir. Öncelik sırası tanimlayin: sistem talimati ve güvenlik kurallari kirpilmaz; RAG parcalari skorla siralanir; oturum ozeti dinamik kirpilir. Fine-tune sayesinde uzun format talimatlari prompt'tan cikarilabilir — bu dogrudan token tasarrufu sağlar.

Chunk boyutu ve overlap RAG kalitesini belirler. Cok küçük parça bağlam kopuklugu, cok büyük parça gurultu yaratir. Domain testleri ile optimal chunk genelde 512-1024 token arasinda bulunur; ancak teknik dokumantasyonda tablo iceren parçalar icin yapilandirilmis bolme (structured chunking) gerekebilir.

Hybrid retrieval

Sadece vektor arama yeterli degildir. BM25 + vektor + metadata filtresi (tenant, sürüm, dil) birlikte kullanın. Fine-tune edilmis bir query rewriter modeli kisa kullanıcı sorularini arama dostu hale getirebilir; bu fine-tune RAG'i destekler, yerine gecmez.

Fine-tune ne zaman, RAG ne zaman?

Fine-tune icin uygun: sabit çıktı semasi, marka tonu, siniflandirma, niyet tespiti, tool seçim egilimi. RAG icin uygun: sik değişen politikalar, ürün kataloglari, ic wiki, müşteri spesifik dokumanlar. Ikisi de gerektirmeyen: genel akil yürütme gorevleri — burada güçlü base model + iyi context yeterli olabilir.

Fine-tune verisi RAG parcalarini kopyalamamali; aksi halde model eski fact'leri ezberler ve RAG'i ignore eder. Egitim orneklerinde bilgi bilincli olarak retrieval'a birakilir; fine-tune yalnizca nasil kullanilacagini ogretir.

Tutarlılık ve celiski çözümü

RAG parcasi ile fine-tune edilmis egilim celisebilir. Örneğin eski politika fine-tune verisinde kalmis, yeni politika RAG'de. Çözüm: RAG parcalarina sürüm ve tarih metadata'si ekleyin; prompt'ta "en güncel sürüm onceliklidir" kuralini context katmaninda sabitleyin. Fine-tune verisini periyodik temizleyin.

Faithfulness katmanı: cevaptaki her iddia kaynak chunk ile eslestirilir. Eslesmeyen cumle yeniden uretilir veya "bilgi yetersiz" denir. Bu katman uc teknolojinin ortak çıkış noktasidir.

Cok dilli senaryolar

Fine-tune Türkçe format icin, RAG cok dilli doküman icin ayarlanabilir. Cross-lingual embedding ile Ingilizce doküman Türkçe soruya cevap verebilir; context katmanı cevap dilini zorlar. Dil karisimi metriklerle izlenmeli.

Maliyet ve operasyon

Fine-tune baslangic maliyeti yüksek, inference bazen ucuz (kisa prompt). RAG her istekte retrieval + daha uzun prompt maliyeti getirir. Context ozetleme ek model çağrısı demektir. Toplam maliyet modellemesini senaryo basina yapin; sadece token fiyatina bakmayin.

Güncelleme hizi: RAG indeksi saatlik guncellenebilir; fine-tune haftalik pipeline gerektirir. Acil politika degisikliginde RAG yeterliyken fine-tune gecikmesi kabul edilebilir. Ürün lansmaninda her iki kanal da senkronize edilmeli.

Eval ve birlikte ölçüm

Uc katmanı ayri ayri eval edin: retrieval recall@k, fine-tune format uyumu, end-to-end task success. Bir katmandaki regresyon digerini maskeleyebilir. Örneğin retrieval duserse fine-tune'lu model yanlış ama güvenli gorunen cevap üretir.

Ablation testi yapin: RAG kapali, fine-tune kapali, yalnizca base model. Hangi katman gercekten katki sagliyor nicel olarak gorun. Gereksiz katman operasyon yukunu artirir.

Güvenlik ve veri sınırları

RAG indeksine hangi dokumanlarin girdigi harness policy ile kontrol edilmeli. Fine-tune verisinde gizli müşteri verisi olmamali. Context oturumunda hassas bilgi minimum tutulmali. Uc katman da tenant izolasyonunu korumali; vektor filtresi tek savunma hatti olmamali.

Pratik mimari özet

Context + RAG + fine-tune birlikte calistiginda sistem hem güncel bilgi sunar hem tutarlı davranir hem de token verimliligi kazanir. Tasarım karari "hangisini secelim" degil "hangi sorumluluk hangi katmanda" sorusudur. Bu ayrim netlestiginde ekip gereksiz yeniden egitimlerden ve sisirilmis prompt'lardan kurtulur.

Uretimde başarı, uc katmanin ortak observability graph'inda izlenmesiyle surdurulur: retrieval hit, prompt token dagilimi, fine-tune model surumu ve çıktı kalite skoru ayni dashboard'da birlesmelidir.

Ek derinlemesine notlar

Üretim ortamlarinda bu konunun pratik etkisi çoğu zaman dokumantasyondaki teorik anlatimdan farklı seyler cikar. Ekipler ilk deploy sonrasinda gerçek trafik altinda gecikme dagiliminin staging ortamindaki tahminlerden sapabildigini görür. Bu nedenle metrikleri erken tasmak ve esik degerleri gerçek veriye gore kalibre etmek kritik oneme sahiptir.

Operasyonel olgunluk, hata oranini sifira indirmekten ziyade hatalari hızlı tespit edip sinirli etki alaniyla izole edebilmektir. Canary release, feature flag ve otomatik rollback mekanizmalarini harness ve eval katmanlariyla birlikte düşünmek gerekir. Aksi halde model veya indeks guncellemesi tüm kullanıcıları ayni anda etkiler.

Capraz fonksiyonel sahiplik de başarı icin sarttir. Platform muhendisligi altyapiyi, ML ekibi modeli, ürün ekibi deneyimi, güvenlik ekibi politika ve denetimi sahiplenmelidir. Tek bir "AI ekibi" hepsini tasimaya calistiginda bilgi silolari ve gecikmeler olusur. RFC süreci ile mimari kararlar kayıt altina alinmali; "neden RAG yerine fine-tune sectik" sorusunun cevabi alti ay sonra hala bulunabilmelidir.

Son olarak maliyet ve kalite dengesi statik degildir. Saglayici fiyatlandirmasi, yeni model aileleri ve hardware gelismeleri uc ayda bir dengeyi degistirebilir. Üretim yiginini periyodik olarak yeniden degerlendirmek — gereksiz katmanı kapatmak, cache stratejisini guncellemek, daha küçük ama yeterli modele gecmek — sürdürülebilir operasyonun parcasidir.

Ek derinlemesine notlar

Üretim ortamlarinda bu konunun pratik etkisi çoğu zaman dokumantasyondaki teorik anlatimdan farklı seyler cikar. Ekipler ilk deploy sonrasinda gerçek trafik altinda gecikme dagiliminin staging ortamindaki tahminlerden sapabildigini görür. Bu nedenle metrikleri erken tasmak ve esik degerleri gerçek veriye gore kalibre etmek kritik oneme sahiptir.

Operasyonel olgunluk, hata oranini sifira indirmekten ziyade hatalari hızlı tespit edip sinirli etki alaniyla izole edebilmektir. Canary release, feature flag ve otomatik rollback mekanizmalarini harness ve eval katmanlariyla birlikte düşünmek gerekir. Aksi halde model veya indeks guncellemesi tüm kullanıcıları ayni anda etkiler.

Capraz fonksiyonel sahiplik de başarı icin sarttir. Platform muhendisligi altyapiyi, ML ekibi modeli, ürün ekibi deneyimi, güvenlik ekibi politika ve denetimi sahiplenmelidir. Tek bir "AI ekibi" hepsini tasimaya calistiginda bilgi silolari ve gecikmeler olusur. RFC süreci ile mimari kararlar kayıt altina alinmali; "neden RAG yerine fine-tune sectik" sorusunun cevabi alti ay sonra hala bulunabilmelidir.

Son olarak maliyet ve kalite dengesi statik degildir. Saglayici fiyatlandirmasi, yeni model aileleri ve hardware gelismeleri uc ayda bir dengeyi degistirebilir. Üretim yiginini periyodik olarak yeniden degerlendirmek — gereksiz katmanı kapatmak, cache stratejisini guncellemek, daha küçük ama yeterli modele gecmek — sürdürülebilir operasyonun parcasidir.