RAG veya fine-tuning: doğru seçim

Müşterilerle konuştuğumuz hemen her yapay zekâ projesi aynı soruyla başlıyor: "Modeli kendi verilerimizle fine-tune etmeli miyiz?" Bazen yanıt evet. Çoğu zaman ise asıl ihtiyaç başka bir şey: güncel belgelerinizi bilen, kaynaklarını gösteren ve bir Salı öğleden sonra eğitim çalıştırması gerektirmeden güncellenebilen bir asistan. Bu makale, temel seçenekleri sade bir dille açıklıyor; her birinin ne zaman uygun olduğunu ve yanlış yaklaşımla aylar kaybetmeden nasıl karar vereceğinizi anlatıyor.

Kutudaki dört araç#

İnsanlar "modele işimizi öğretelim" dediğinde genellikle dört farklı teknikten birini kasteder. Bunlar farklı sorunları çözer ve birlikte kullanılabilir.

Retrieval-augmented generation (RAG)#

RAG modeli olduğu gibi bırakır. Bunun yerine, bir soru geldiğinde sistem önce kendi içeriğinizde — kılavuzlar, sözleşmeler, ticket'lar veya ürün kataloğu gibi — arama yapar ve en ilgili pasajları soruyla birlikte modele iletir. Model de bu pasajlara dayanarak yanıt verir.

Burada üç fikir önemlidir:

• Retrieval: doğru pasajları bulmak. Bu genellikle embedding'ler üzerinde anlamsal arama ile klasik anahtar kelime aramasının bir karışımıdır ve çoğu zaman bir yeniden sıralama (re-ranking) adımı izler.
• Grounding: modele sağlanan malzemeden yanıt vermesini ve malzeme yanıtı içermediğinde bunu söylemesini talimat olarak vermek.
• Citation'lar: yanıtın hangi belgeden, sayfadan veya pasajdan geldiğini göstermek, böylece bir insan bunu kontrol edebilir.

RAG; bilgi sık değiştiğinde, külliyat büyük olduğunda ve insanların yanıtları doğrulaması gerektiğinde parlar.

Fine-tuning#

Fine-tuning, bir modelin eğitimini kendi örneklerinizle sürdürerek davranışını değiştirir. Nasıl yanıt verileceğini öğretmede iyidir: tutarlı bir ton, katı bir çıktı formatı, alana özgü bir sınıflandırma şeması veya günde binlerce kez yapılan dar bir görev. Şu anda neyin doğru olduğunu öğretmek için ise kötü bir yoldur. Fine-tuning ile öğrenilen gerçekler güncellemesi zor, kaynağına izlenebilirliği zor şeylerdir; harmanlanabilir veya yanlış hatırlanabilir.

Fine-tuning ayrıca dar bir görevi daha küçük, daha ucuz ve daha hızlı bir modele taşımanızı sağlar; bu da yüksek hacimde çok önemli olabilir.

Prompt caching ile uzun bağlam#

Anthropic, OpenAI ve birkaç açık kaynak ailesinin modern modelleri çok uzun girdiler kabul eder. Bilgi tabanınız mütevazı boyuttaysa — örneğin bir ürün el kitabı, bir politika seti veya bir SSS kümesi — çoğu zaman tamamını doğrudan prompt'a koyabilirsiniz. İndeks yok, retrieval pipeline'ı yok, chunking kararları yok.

Bariz itiraz maliyet ve gecikmedir: aynı büyük belgeyi her istekte göndermek israftır. Prompt caching bunu çözer. Sağlayıcılar prompt'un sabit bir önekini önbelleğe alabilir; böylece tekrarlanan istekler önceden işlenmiş içeriği yeniden kullanır ve daha verimli faturalandırılıp sunulur. Sabit ve sınırlı bir bilgi kümesi için, caching'li uzun bağlam sıklıkla işe yarayan en basit çözümdür.

Yapılandırılmış çıktılar#

Birçok "yapay zekâ" projesi aslında bir çıkarım (extraction) projesidir: bir fatura, bir CV, bir sözleşme veya bir e-posta okuyup temiz alanlar üretmek. Burada kilit yetenek structured outputs'tur; model, tanımladığınız bir şemaya uyan veri döndürmekle kısıtlanır — örneğin belirli alanlar ve tipler içeren JSON. Bu, bilgiyle ilgili değildir. Formatın güvenilirliğiyle ilgilidir ve çıkarım görevlerinde fine-tuning ihtiyacını genellikle ortadan kaldırır.

Hangi yaklaşım ne zaman uygundur#

Bunu düşünmenin faydalı bir yolu: bilgiyi davranıştan ayırmak.

• Taze veya değişen bilgi ve insanların doğrulaması gereken yanıtlar: RAG kullanın; malzeme yeterince küçükse uzun bağlam kullanın. İkisi de belgeleri güncelleyerek bilgiyi güncellemenizi sağlar ve ikisi de citation'ları destekler.
• Bağlam penceresine sığan, sabit ve sınırlı bilgi: uzun bağlam ve prompt caching ile başlayın. Malzeme bunu aştığında veya belge başına ince taneli erişim kontrolü gerektiğinde RAG'a geçin.
• Birçok çıktıda tutarlı üslup, ton veya format: önce net talimatlar ve prompt'ta birkaç iyi örnek deneyin. Hacminizde bu yeterli değilse fine-tuning meşru bir seçenektir.
• Yüksek ölçekte dar sınıflandırma veya yönlendirme: daha küçük bir modeli fine-tune etmek veya iyi tasarlanmış bir prompt ile daha küçük bir genel model kullanmak çoğu zaman en ekonomik yoldur.
• Belgelerden alan çıkarımı: yapılandırılmış çıktılar; isteğe bağlı olarak belge girdileri ve citation'larla birleştirilerek her çıkarılan değer izlenebilir hale getirilir.

Bunlar birbirini dışlamaz. Olgun bir sistem bilgi için RAG, yanıt formatı için yapılandırılmış çıktılar ve gelen istekleri yönlendirmek için küçük bir fine-tune edilmiş model kullanabilir.

Yan yana karşılaştırma#

Pratik bir karar kontrol listesi#

Bir mimari seçmeden önce şu soruları dürüstçe yanıtlayın:

1. Görev tam olarak nedir? Soru yanıtlama, metin taslağı hazırlama, sınıflandırma mı, çıkarım mı? Girdi ve ideal çıktı için beş gerçek örnek yazın.
2. Temeldeki bilgi ne sıklıkla değişiyor? Günlük veya haftalık değişimler sizi fine-tuning'den güçlü biçimde uzaklaştırır.
3. Kullanıcıların yanıtları doğrulaması gerekiyor mu? Hukuk, finans, uyum, destek veya sağlık bağlamlarında citation'lar genellikle pazarlık konusu değildir.
4. Bilgi tabanı ne kadar büyük? Bir bağlam penceresine rahatça sığıyorsa önce caching'li uzun bağlamı deneyin.
5. Kim neyi görebilir? Farklı kullanıcılar farklı belgelere erişebiliyorsa tek bir paylaşılan prompt ya da her şeyle eğitilmiş bir model değil, izin filtrelemeli retrieval gerekir.
6. Hangi hacmi ve gecikmeyi bekliyorsunuz? Dar bir görevde yüksek hacim, daha küçük veya fine-tune edilmiş modellerin kendini amorti ettiği yerdir.
7. Etiketli örnekleriniz var mı? Yeterli sayıda iyi örnek olmadan fine-tuning, iyi yazılmış bir prompt'u nadiren geçer.
8. Başarıyı nasıl ölçeceksiniz? Bunu yanıtlayamıyorsanız durun ve önce bir değerlendirme seti oluşturun.

Yanıtların çoğu "değişen bilgi, citation gerekli, orta hacim" yönündeyse RAG veya uzun bağlam istiyorsunuz. "Sabit görev, katı format, çok yüksek hacim" yönündeyse fine-tuning veya daha küçük bir modeli düşünün.

Yaygın tuzaklar#

"Neredeyse çalışan" yapay zekâ sistemlerini incelerken en sık gördüğümüz sorunlar bunlar.

• Kötü chunking. Belgeleri keyfi sabit boyutlu parçalara bölmek tabloları ikiye keser, başlıkları içeriklerinden ayırır ve bağlamı kaybeder. Belgenin yapısı boyunca parçalayın ve başlık, bölüm, tarih gibi yararlı metadata'yı koruyun.
• Değerlendirme yokluğu. Test seti olmadan her değişiklik bir tahmindir. Ekipler prompt'ları kurcalar, model değiştirir ve chunk boyutlarıyla oynar — işlerin iyiye mi kötüye mi gittiğini bilmeden.
• Bayat indeksler. Kaynak belgeler güncellendi, indeks güncellenmedi. Asistan kendinden emin biçimde geçen yılın politikasını aktarır. Yeniden indeksleme içerik iş akışının parçası olmalı; manuel bir sonradan akla gelen iş değil.
• Citation'sız halüsinasyon. Sistem bir yanıtın nereden geldiğini göstermiyorsa kullanıcılar dayanaklı bir yanıtla uydurulmuş birini ayırt edemez. Citation şartı koyun ve modele kaynaklar sessizken "bilmiyorum" demesini öğretin.
• Mahremiyet ve GDPR. Belgelerdeki, prompt'lardaki ve log'lardaki kişisel veriler hâlâ kişisel veridir. Hangi sağlayıcının, hangi bölgede, hangi veri işleme sözleşmesiyle işlediğini ve log'ların ne kadar saklandığını bilin. Kişisel veriler üzerinde fine-tuning ekstra dikkat ister, çünkü sonradan çıkarmak zordur.
• Belgelerden prompt injection. Getirilen içerik güvenilmeyen girdidir. Bir belge, modele talimat vermeye çalışan metin içerebilir — örneğin kurallarını yok saymasını veya başka verileri açığa çıkarmasını isteyen. Getirilen metni veri olarak ele alın, modelin araçlarla neler yapabileceğini sınırlayın ve belge içeriğine asla izin verme yetkisi tanımayın.

Optimize etmeden önce değerlendirin#

Herhangi bir yapay zekâ projesindeki en değerli adım, aynı zamanda en gösterişsiz olandır: mimariyi seçmeden önce bir değerlendirme seti oluşturun.

İyi bir başlangıç seti, her biri beklenen yanıtı veya alıntılanması gereken belgeleri içeren birkaç düzine ile birkaç yüz arası gerçek soru veya girdiden ibarettir. Sonra ölçün:

• Retrieval kalitesi: sistem doğru pasajları buldu mu?
• Yanıt kalitesi: yanıt doğru, eksiksiz ve kaynaklara dayalı mı?
• Citation doğruluğu: alıntılanan pasajlar iddiayı gerçekten destekliyor mu?
• Reddetme davranışı: gerektiğinde "bilmiyorum" diyor mu?
• Format uyumu: çıkarım için her çıktı şemaya uyuyor mu?

Bu yerine oturduğunda karşılaştırmalar somutlaşır. Uzun bağlamı RAG'a, bir modeli diğerine veya fine-tune edilmiş bir modeli prompt'lu bir modele karşı, genel benchmark'lar yerine kendi verilerinizle test edebilirsiniz. Çoğu zaman en ucuz düzeltmenin daha büyük bir model veya bir eğitim çalıştırması değil, daha iyi retrieval veya daha net bir prompt olduğunu göreceksiniz.

Model ile otomatik puanlama bunu hızlandırabilir, ancak özellikle başlarda insan denetçilerle nokta kontrolü yapın.

Kendi demolarımız kalıpları nasıl gösteriyor#

Önerdiğimiz şeyi uygulamaya çalışıyoruz ve bu sitedeki iki demo kalıpları iş başında gösteriyor.

sigmacode Assistant, hizmetlerimiz ve yaklaşımımız hakkındaki soruları yanıtlar. Bilgi tabanı küçük ve bilinçli olarak dondurulmuş olduğundan, bir retrieval pipeline'ı yerine prompt caching'li uzun bağlam prompt'u kullanır: tüm bilgi tabanı önbelleğe alınmış bir prompt önekinde durur ve model yalnızca ondan yanıt vermekle talimatlandırılır. Sınırlı bir bilgi kümesi için bu, bir vektör indeksinden daha basit kurulur ve doğru tutması daha kolaydır.

Document Q&A demosu ise diğer tarafı gösterir. Bir belge sağlarsınız, sorular sorarsınız ve her yanıt dayandığı pasajları gösteren citation'larla gelir. Grounding'li yapay zekânın temel vaadi budur: her iddia kaynağıyla karşılaştırılarak kontrol edilebilir.

Demoların ikisi de fine-tuning gerektirmedi. Bu tipiktir. Çoğu kurumsal bilgi sorununda, özel eğitimden çok grounding ve iyi değerlendirme önemlidir.

Kısa versiyon#

• Bilgi büyükse, sık değişiyorsa, erişim kontrolü gerekiyorsa veya alıntılanması gerekiyorsa RAG kullanın.
• Bilgi sabitse ve pencereye sığıyorsa prompt caching'li uzun bağlam kullanın.
• Yüksek hacimde tutarlı davranış veya dar görevler için fine-tuning veya daha küçük modeller kullanın — gerçekler için değil.
• Çıkarım ve bir sistemin ayrıştırması gereken her çıktı için yapılandırılmış çıktılar kullanın.
• Önce değerlendirin, sonra sayıların gösterdiğini optimize edin.

Bu seçenekleri gerçek bir proje için tartıyorsanız, 20+ yıllık deneyime sahip bir tech lead'in yönettiği AI & Automation ekibimiz kapsamı belirlemenize, bir değerlendirme seti oluşturmanıza ve gerçekten ölçebileceğiniz bir ilk sürüm çıkarmanıza yardımcı olabilir. Bize ulaşın ve neyi çözmeye çalıştığınızı anlatın.