Model Özelleştirme ve İnce Ayar · Danışmanlık

Fine-Tuning, RAG ve Prompt Yaklaşımı Değerlendirmesi

Müdahale kararı gözlenen hata ve güncelleme pattern'ini izliyor. Prompt, RAG, fine-tuning ve birleşik seçenekler aynı kısıtlarla, aynı sınırlı deneylerle karşılaştırılmadan öneri oluşmuyor.

Zayıf bir yanıt tek başına sorunun prompt'ta mı, RAG tarafında mı, fine-tuning ihtiyacında mı yoksa sistemin başka bir parçasında mı olduğunu söylemez. Önce hata ve güncelleme pattern'ini inceliyoruz. Ardından en küçük inandırıcı müdahale sınıfını sınırlı deneylerle sınayıp neyin geliştirmeye değer olduğuna bakıyoruz.

Test edilmiş seçenek karnesi, elenen alternatifler, açık istisnalar ve geliştirmeye geçme, ek kanıt isteme veya durma seçeneklerini taşıyan sonraki karar kaydı elinizde kalıyor.

Seçenekleri birlikte kıyaslayalımModel özelleştirmeyi incele
Fine-Tuning, RAG ve Prompt Yaklaşımı Değerlendirmesi illüstrasyonu: bir modeli hedef davranışa ve başlangıç seviyesine göre ayarlayan ekip

Birlikte çalıştığımız 500'den fazla markadan birkaçı

Tüm referansları gör
  • Bayer
  • Arabam.com
  • Tosla
  • Duru
  • Wall Street English
  • Doremusic

Adımlar, kapılar ve kararı verenler

Çalışma şeklimiz

Bir yöntem önermeden önce sorunun ne olduğunu ve ne sıklıkla değiştiğini anlamaya çalışıyoruz.

  1. Hataların arkasındaki pattern'i buluyoruz

    Gerçek örnekleri hata türüne, güncelleme ihtiyacına, önem derecesine ve mevcut baseline'a göre ayırıyoruz. Böylece birbirinden farklı zayıf yanıtları tek bir sorunmuş gibi ele almıyoruz.

    Yapay zeka desteği
    Gönderilen hata örneklerini model türe ve önem derecesine göre grupluyor. Ürün sorumlusu kümeleri inceleyip hangilerinin karar için anlamlı olduğunu belirliyor.
    İnsan onayı
    Toplanan kanıt önemli kararları ve kullanıcıları kapsıyor mu? Hangi hata kümesinin düzeltmeye en çok değdiğine ürün sorumlunuz karar veriyor.

  2. Müdahale sınıflarını daraltıyoruz

    Prompt, RAG, fine-tuning ve birleşik yaklaşımları teşhis edilen pattern'lerle eşleştiriyoruz. Veri ihtiyacına, bağımlılıklara, taşınabilirliğe, maliyete, latency'ye ve yenileme yüküne baktığımızda soruna veya mevcut koşullara uymayan seçenekler burada eleniyor.

    Yapay zeka desteği
    Her aday müdahale için bağımlılık ve maliyet karşılaştırmasını model taslaklıyor. Mühendislik lideri varsayımları tek tek inceliyor.
    İnsan onayı
    Her seçenek mevcut kısıtlar altında gerçekten uygulanabilir mi? Hangi seçeneklerin mevcut kısıtlar altında uygulanabilir olduğunu mühendislik lideriniz doğruluyor.

  3. En küçük inandırıcı kısa listeyi deniyoruz

    Sınırlı deneyleri gerçek ve olumsuz örneklerle ekibimiz yürütüyor. Daha hafif bir müdahalenin yeterli olup olmadığını ve hangi istisnaların açık kaldığını uzmanlarımız inceliyor.

    Yapay zeka desteği
    Deney çıktılarını model düzenliyor ve her seçenek için istisna kaydı taslaklıyor. Ürün ve değerlendirme uzmanları her bulguyu inceliyor.
    İnsan onayı
    Hangi seçenek birlikte belirlediğimiz kontrolleri en az gereksiz bağımlılıkla karşılıyor? Kısa listeyi sıralamadan önce istisnaları ürün sorumlunuz inceliyor.

  4. Bir şey geliştirmenin gerekip gerekmediğine karar veriyoruz

    Öneriyi, elenen seçenekleri, açık soruları, sorumluyu ve konunun yeniden ele alınacağı veya durdurulacağı tarihi kayda alıyoruz. Uygulama yalnızca ayrı bir kapsam onaylandığında başlıyor.

    Yapay zeka desteği
    İnsanların incelediği kanıtlardan kabul edilen ve elenen seçenekleri özetleyen ilk karar kaydını model hazırlıyor. Ürün sorumlusu kaydı düzeltiyor.
    İnsan onayı
    Sorumlu öneriyi onaylamaya, reddetmeye veya kanıtı genişletmeye hazır mı? Öneriyi ürün sorumlunuz onaylıyor, reddediyor veya ek kanıt istiyor.

Adı konmuş, sizde kalan çıktılar

Elinize geçenler

Önerinin dayanağını ve ilk bakışta uygun görünüp kanıt karşısında elenen seçenekleri birlikte teslim ediyoruz.

  • Matris

    Gözlenen hata seçenek karnesi ve deney planı

    Prompt, RAG, fine-tuning ve birleşik seçenekleri gözlenen hatalar ile mevcut kısıtların karşısına koyuyor, yalnızca inandırıcı kalan seçenekleri deneye taşıyoruz.

  • Mimari dokümanı

    Baseline kanıtı ve müdahale bağımlılık haritası

    Gerçek örneklerle baseline kanıtının yanında varsayımları, açık soruları, veri ihtiyaçlarını ve değerlendirmeyi etkileyen sistem bağımlılıklarını topluyoruz.

  • Test kanıtı

    Olumsuz vaka bulguları ve açık istisna raporu

    Deney sonuçları önemli vaka ve hata türlerine göre ayrılıyor. Olumsuz örnekler ile kritik istisnalar güçlü sonuçların yanında görünür kalıyor.

  • Karar kaydı

    Önerilen seçenek, elenen alternatifler ve teslim özeti

    Öneriyi ve elenen alternatifleri, koşullar, açık maddeler, sorumlu kişi ve sonraki karar noktasıyla birlikte kısa bir kayıtta topluyoruz.

Kapsam ve dürüst sınırlar

Bu çalışmanın size uyduğu durumlar

Fine-tuning, RAG veya prompt çalışması gerçek soruna uyduğu gösterilmeden uygulama taahhüdüne dönüşüyorsa önce bu değerlendirmeyi yapmak gerekir.

Şu durumlarda iyi bir seçim

  • Ekipler zayıf yanıtları yeniden üretiyor, ama sorunun bilgi, talimat, görev davranışı veya sistem tasarımından hangisinde olduğunu aynı biçimde yorumlamıyor.
  • Güncelleme sıklığı, latency, maliyet, veri hakkı ve bakım yükü farklı yönlere işaret ediyor, bu yüzden tercih edilen müdahale savunulamıyor.
  • Temsili hatalar ve baseline bulunuyor, ancak en küçük inandırıcı seçenekler aynı kabul kontrolleriyle henüz karşılaştırılmıyor.
  • Prompt, RAG, fine-tuning ve birleşik tasarımlar tartışılıyor, ama hata ve güncelleme incelemesi hangi müdahalenin soruna uyduğunu göstermiyor.
  • Kanıt, bağımlılık, kısıt, varsayım ve istisna vakaları ayrı notlarda duruyor, bu yüzden seçenekler aynı temelde karşılaştırılamıyor.
  • Kısa liste makul görünüyor, ama sınırlı deneyler ve olumsuz vakalar en hafif müdahalenin yeterli olup olmadığını henüz göstermiyor.
  • Öneri bekleniyor, ancak elenen alternatifler, açık koşullar, sorumlu kişi ve sonraki karar kapısı henüz kayda girmiyor.

Şu durumlarda başka bir çalışma daha doğru

  • Popüler veya kurum içinde desteklenen tekniğin önce seçilmesini istiyorsunuz. Bu değerlendirme seçenekleri gözlenen hata pattern'ine göre sıralıyor.
  • Seçilen çözümün hemen geliştirilmesini istiyorsunuz. Değerlendirme kısa listeyi test ediyor, uygulama ise deney ve kapsam onaylarını bekliyor.
  • Bir tekniğin bütün kalite, güvenlik, maliyet veya bakım dengesini kaldırmasını bekliyorsunuz. Her seçeneğin kararda taşınması gereken kendi yükü bulunuyor.

Bunlardan biri sizin durumunuza daha yakınsa, buradan başlayın: Model özelleştirmeyi incele

AI'ı production'a taşıyan mühendisler

Zeo'nun kod yazıp teslim eden tarafı burası. Kıdemli mühendislerimiz agent, chatbot ve RAG sistemleri geliştiriyor, çevrelerindeki otomasyon ve veri işlerini üstleniyor, sistemler canlıya çıktıktan sonra da işletmeyi sürdürüyor. 2011'den beri 500'den fazla markayla çalıştık.

Bu konuda ürettiğimiz içerikler

YazıCan MutioğluFew-Shot Prompting Tekniği Nedir? Nasıl Kullanılır?YazıCan MutioğluOpenAI Modelleri ve OpenAI API KullanımıYazıEzgi Gülsen YaylıYapay Zekada Chain of Thought (Düşünce Zinciri) ile Yönlendirme

Kullandığımız araçlar

Bu işin arkasındaki araçlar

  • OpenAI

    Prompting ve fine-tuning adaylarında aynı kalan temel model ailesi

  • LlamaIndex

    Gerçek RAG adayını kurarak karşılaştırmaya taşıdığımız orchestration framework'ü

  • PromptLayer

    Adil karşılaştırma için denenen tüm prompt varyantlarını kaydettiğimiz sistem

  • Braintrust

    Prompting, RAG ve fine-tuning seçeneklerini aynı vakalarda karşılaştıran değerlendirme ortamı

  • Ragas

    Zayıf RAG yanıtının kaynağını ayırmak için kullandığımız değerlendirme aracı

  • Unsloth

    Fine-tuning seçeneğini düşük maliyetle test etmemize yardımcı olan araç

Sonraki adım

Yöntemi seçmeden önce hatayı doğru okuyun

Örnekleri, baseline'ı ve karar verecek sorumluyu getirin. Hangi müdahale sınıfının test edilmeye değer olduğuna, ardından bir şey geliştirmenin gerekip gerekmediğine bakalım.
Seçenekleri karşılaştıralım

Karar vermeden önce

Sık duyduğumuz sorular

Değerlendirmeye hangi bilgilerle gelmeliyiz?

Temsili başarılı ve hatalı örnekleri, mevcut prompt veya RAG düzenini, model kısıtlarını ve güncelleme sıklığını bilmemiz gerekiyor. Latency ve maliyet sınırlarını, kullanılabilir veriyi, kullanım haklarını ve bilinen bağımlılıkları da paylaşıyorsunuz. Son olarak hangi müdahalenin ilerleyeceğine karar verecek kişiyi belirliyoruz.

Her değerlendirme tek bir yöntem önerisiyle mi biter?

Hayır. Kanıtlar birleşik bir tasarımı, dar bir prompt değişikliğini, ek RAG çalışmasını, bir fine-tuning deneyini veya şimdilik hiçbir yeni müdahale yapılmamasını destekleyebilir. Elenen seçenekleri ve nedenlerini karar kaydında tutuyoruz.

Bir öneri ne zaman onaya hazır olur?

Birlikte belirlediğimiz kabul kontrollerinin sonuçları ve kritik istisnaların durumu görünür olmalıdır. Kanıtın gerçek hata ve güncelleme pattern'lerini karar verecek kadar kapsaması gerekiyor. İşi sonraki ekibe aktaracak sorumlu da belli olmalı. Kanıt veya bağımlılıklar eksik kaldığında öneriyi koşullu bırakıyoruz. Ürün sorumlunuz bu durumda uygulamayı erken onaylamak zorunda kalmadan ek çalışma isteyebilir.

Bu değerlendirme neyi vaat etmiyor?

Seçilen yöntemin bütün kalite, güvenlik, maliyet veya bakım dengesini ortadan kaldıracağını vaat etmiyoruz. Öneri, gözlenen hata ve güncelleme pattern'leriyle mevcut kısıtlara bağlı kalıyor. Bu koşullar önemli ölçüde değişirse kararı yeniden inceliyoruz. Uygulama ise ayrıca onaylanmış bir kapsam gerektiriyor.