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ım Model özelleştirmeyi incele

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

Tüm referansları gör

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

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. Hangi hata kümesinin düzeltmeye en çok değdiğine ürün sorumlunuz karar veriyor.
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. Hangi seçeneklerin mevcut kısıtlar altında uygulanabilir olduğunu mühendislik lideriniz doğruluyor.
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. Kısa listeyi sıralamadan önce istisnaları ürün sorumlunuz inceliyor.
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. Öneriyi ürün sorumlunuz onaylıyor, reddediyor veya ek kanıt istiyor.

Ö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.

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

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

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ç

Ö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

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.

Ekibe göre

Sektöre göre

Araca göre

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

Çalışma şeklimiz

Hataların arkasındaki pattern'i buluyoruz

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

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

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

Elinize geçenler

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

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

Olumsuz vaka bulguları ve açık istisna raporu

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