Bağlamsal Arama (Contextual Retrieval) teknolojisi

 (anthropic.com)
3 puan yazan GN⁺ 2024-09-22 | 1 yorum | WhatsApp'ta paylaş
  • Kurumsal bilgi tabanlı yapay zekada kullanılan RAG, belgeleri küçük parçalara ayırma sürecinde şirket adı, zaman gibi bağlamı kaybederek ilgili bilgileri gözden kaçırabilir
  • Anthropic'in Contextual Retrieval yaklaşımı, her parçanın önüne tüm belgeye göre kısa bir açıklama ekledikten sonra embedding ve BM25 indeksleri oluşturarak arama başarısızlık oranını düşürür
  • Deneylerde Contextual Embeddings, ilk 20 parça için arama başarısızlık oranını %5,7'den %3,7'ye, yani %35 azalttı; Contextual Embeddings ile Contextual BM25 birleşimi bunu %2,9'a, yani %49 düşürdü
  • Yeniden sıralama (reranking) eklendiğinde ilk 150 aday yeniden puanlanıp yalnızca ilk 20 modele aktarılıyor ve arama başarısızlık oranı %5,7'den %1,9'a, yani %67 azalıyor
  • Bilgi tabanı 200.000 tokenin altındaysa tamamını prompt'a koymak da mümkün, ancak daha büyük bilgi tabanlarında Contextual Retrieval ile yeniden sıralama kombinasyonu kullanım senaryosuna göre değerlendirilmelidir

RAG'in kaybettiği belge bağlamı

  • AI modelinin belirli bir işte faydalı olabilmesi için arka plan bilgisine erişmesi gerekir
    • Müşteri destek chatbot'u ilgili iş bilgisini bilmelidir
    • Hukuk analizi botunun geçmiş içtihat bilgisine ihtiyacı vardır
  • Geliştiriciler genelde model bilgisini Retrieval-Augmented Generation (RAG) ile güçlendirir
    • Bilgi tabanından ilgili bilgileri arar
    • Bulunan bilgileri kullanıcı prompt'una ekleyerek model yanıtını iyileştirir
  • Mevcut RAG, belgeleri parçalara ayırırken bağlamı kaldırdığı için ilgili bilgiyi bulamayabilir
  • Contextual Retrieval, RAG'in arama aşamasını iyileştiren bir yöntemdir ve iki alt tekniği birlikte kullanabilir
    • Contextual Embeddings: Bağlam eklenmiş parçalarla embedding üretir
    • Contextual BM25: Bağlam eklenmiş parçalarla BM25 indeksi oluşturur
    • Bu kombinasyon arama başarısızlık sayısını %49 azaltır; yeniden sıralamayla birleştirildiğinde bu oran %67'ye kadar çıkar
  • Claude ile Contextual Retrieval dağıtımı için bir cookbook sunuluyor

Küçük bilgi tabanlarında uzun prompt da mümkündür

  • Bilgi tabanı 200.000 tokenin altında, yani yaklaşık 500 sayfadan küçükse RAG olmadan tüm bilgi tabanı prompt'a eklenebilir
  • Claude'un prompt caching özelliği bu yaklaşımı daha hızlı ve daha maliyet verimli hale getirir
    • Sık kullanılan prompt'lar API çağrıları arasında önbelleğe alınabilir
    • Gecikme süresi 2 kattan fazla azaltılabilir
    • Maliyet en fazla %90 azaltılabilir
    • Nasıl çalıştığı prompt caching cookbook üzerinden görülebilir
  • Bilgi tabanı büyüdükçe daha ölçeklenebilir arama yöntemleri gerekir ve bu noktada Contextual Retrieval kullanılır

Genel RAG ve BM25'in rolü

  • Büyük bir bilgi tabanı bağlam penceresine sığmadığında yaygın çözüm RAG'dir
  • RAG'in ön işleme akışı şöyledir
    • Belge korpusu genelde yüzlerce tokenin altında küçük metin parçalarına bölünür
    • Embedding modeliyle parçalar anlam taşıyan vektör embedding'lerine dönüştürülür
    • Embedding'ler anlamsal benzerlik araması yapılabilen bir vektör veritabanında saklanır
  • Çalışma anında kullanıcı sorgusuna anlamsal olarak en yakın parçalar vektör veritabanından bulunur ve ilgili parçalar üretici modelin prompt'una eklenir
  • Embedding modelleri anlamsal ilişkileri iyi yakalar, ancak tam string eşleşmelerini kaçırabilir
  • BM25 (Best Matching 25), sözcük eşleşmesini kullanan bir sıralama fonksiyonudur ve özellikle benzersiz tanımlayıcılar veya teknik terimler içeren sorgularda etkilidir
    • BM25, TF-IDF kavramına dayanır
    • TF-IDF, koleksiyon içinde belirli bir kelimenin belgede ne kadar önemli olduğunu ölçer
    • BM25, belge uzunluğunu hesaba katar ve terim sıklığına doygunluk fonksiyonu uygular; böylece yaygın kelimeler sonuçlara hakim olamaz
  • Örneğin teknik destek veritabanında "Error code TS-999" arandığında, embedding modeli genel hata kodu belgelerini bulabilir ama tam "TS-999" eşleşmesini kaçırabilir
  • BM25 bu string'i doğrudan bularak ilgili belgeyi tanımlar

Embedding ve BM25'i birlikte kullanan RAG

  • RAG, daha doğru parçalar bulmak için embedding ile BM25'i birleştirebilir
    • Bilgi tabanını küçük parçalara böler
    • Her parça için TF-IDF encoding ve anlamsal embedding üretir
    • BM25 ile tam eşleşme temelli üst sıralı parçaları bulur
    • Embedding ile anlamsal benzerlik temelli üst sıralı parçaları bulur
    • Rank fusion tekniğiyle sonuçları birleştirip yinelenenleri kaldırır
    • İlk K parçayı prompt'a koyarak yanıt üretir
  • Bu yaklaşım tam terim eşleşmesi ile geniş anlamsal kavrayış arasında denge kurar
  • Tek bir prompt'a sığmayacak kadar büyük bilgi tabanlarına kadar maliyet verimli şekilde ölçeklenebilir
  • Ancak mevcut RAG sistemlerinin, belgeleri parçalara ayırırken bağlamı bozma sınırlaması vardır
  • SEC bildirimlerine dayalı bir bilgi tabanında "What was the revenue growth for ACME Corp in Q2 2023?" diye sorulması buna tipik bir örnektir
    • İlgili parça yalnızca "The company's revenue grew by 3% over the previous quarter." içerebilir
    • Bu parça tek başına hangi şirketten ve hangi dönemden söz edildiğini göstermez
    • Bu yüzden hem arama hem kullanım aşamasında doğru bilgiyi değerlendirmek zorlaşır

Contextual Retrieval nasıl çalışır

  • Contextual Retrieval, her parçayı embedding'e dönüştürmeden ve BM25 indeksi oluşturmadan önce parçaya özgü açıklayıcı bağlamı başına ekler
    • Embedding'e uygulanırsa Contextual Embeddings
    • BM25 indeksine uygulanırsa Contextual BM25
  • SEC bildirimi örneğinde orijinal parça şöyledir
The company's revenue grew by 3% over the previous quarter.
  • Bağlamlandırılmış parça şu hale gelir
This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter.
  • Geçmişte de aramayı iyileştirmek için bağlam kullanan yöntemler önerildi
  • Bu yöntemler, Contextual Retrieval'ın parça bazlı bağlam ekleme yaklaşımından farklıdır

Claude ile parça bağlamı üretmek

  • Binlerce ya da milyonlarca parçayı insanların tek tek etiketlemesi gerçekçi değildir
  • Anthropic, Claude'un tüm belge bağlamına dayanarak her parça için kısa ve parçaya özgü bir bağlam üretmesini sağlayan bir prompt hazırladı
  • Claude 3 Haiku için kullanılan prompt şöyledir
<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.
  • Üretilen bağlam metni genelde 50 ila 100 token olur; parçanın önüne eklenir ve ardından embedding ile BM25 indeksi oluşturmak için kullanılır
  • Prompt caching kullanılırsa her parça için referans belgeyi yeniden göndermek gerekmez
    • Belge bir kez önbelleğe alınır ve daha önce önbelleğe alınmış içerik referans gösterilir
    • 800 tokenlik parça, 8k tokenlik belge, 50 tokenlik bağlam talimatı ve parça başına 100 tokenlik bağlam varsayılırsa, bağlamlandırılmış parça üretiminin tek seferlik maliyeti belge başına 1 milyon token için 1,02 dolardır

Deney yöntemi ve arama performansı

  • Deneyler farklı bilgi alanları, embedding modelleri, arama stratejileri ve değerlendirme metrikleri üzerinde yapıldı
    • Kod tabanları
    • Romanlar
    • ArXiv makaleleri
    • Bilimsel makaleler
  • Her alan için soru ve yanıt örnekleri Appendix II içinde yer alıyor
  • Grafikler tüm bilgi alanlarının ortalama performansını gösteriyor ve en iyi embedding yapılandırması olan Gemini Text 004 ile ilk 20 parça aramasını kullanıyor
  • Değerlendirme metriği 1 - recall@20
    • İlgili belgenin ilk 20 parça içinde bulunamama oranını ölçer
  • Genel sonuçlarda değerlendirilen tüm embedding-kaynak kombinasyonlarında bağlamlandırma uygulandığında performans iyileşti
  • Performans iyileşmesi şöyleydi
    • Contextual Embeddings: İlk 20 parça arama başarısızlık oranını %5,7 → %3,7, yani %35 azalttı
    • Contextual Embeddings + Contextual BM25: Arama başarısızlık oranını %5,7 → %2,9, yani %49 azalttı

Uygulamada dikkat edilmesi gerekenler

  • Parça sınırları, arama performansını etkileyebilir
    • Parça boyutu
    • Parça sınırları
    • Parça örtüşmesi
  • Contextual Retrieval test edilen tüm embedding modellerinde performansı artırdı, ancak artış miktarı modele göre değişebilir
    • Gemini embedding'leri ile Voyage embedding'leri özellikle etkiliydi
  • Sağlanan genel prompt iyi çalışıyor, ancak alan veya kullanım senaryosuna özel özelleştirilmiş contextualizer prompt ile daha iyi sonuçlar alınabilir
    • Örnek: Yalnızca bilgi tabanındaki diğer belgelerde tanımlanan temel terimler için glossary eklemek
  • Bağlam penceresine daha fazla parça koymak, ilgili bilginin dahil olma olasılığını artırır
    • Ancak bilgi arttıkça modelin dikkatinin dağılma riski olduğundan bir sınır vardır
    • 5, 10 ve 20 parça ile yapılan denemelerde en iyi performansı 20 parça verdi
    • Gerçek kullanım senaryosunda deney yapmak gerekir
  • Yanıt üretiminde bağlamlandırılmış parçaların gönderilmesi ve hangi kısmın bağlam, hangisinin orijinal parça olduğunun ayrıştırılması iyileşme sağlayabilir
  • Değerlendirme mutlaka yapılmalıdır

Yeniden sıralamayla ek iyileştirme

  • Yeniden sıralama, büyük bilgi tabanlarında ilk aramada bulunan aday parçalar arasından en ilgili olanları modele ileten bir filtreleme tekniğidir
  • Bu aşama, modelin işleyeceği bilgi miktarını azaltarak yanıt kalitesi, maliyet ve gecikme üzerinde etkili olabilir
  • Süreç şöyledir
    • İlk aramayla potansiyel olarak ilgili üst sıralı parçalar alınır
    • Deneylerde ilk 150 kullanıldı
    • Üst N parça ile kullanıcı sorgusu yeniden sıralama modeline verilir
    • Yeniden sıralama modeli her parçaya ilgi ve önem puanı atar
    • Üst K parça seçilir
    • Deneylerde ilk 20 kullanıldı
    • Seçilen parçalar model bağlamı olarak eklenir ve nihai sonuç üretilir
  • Deneyler Cohere reranker ile yapıldı
  • Voyage reranker da var, ancak test etmeye zaman olmadı
  • Farklı alanlarda yeniden sıralama aşaması eklendiğinde arama daha da optimize edildi
  • Reranked Contextual Embedding + Contextual BM25, ilk 20 parça arama başarısızlık oranını %5,7 → %1,9, yani %67 azalttı

Maliyet ve gecikme dengesi

  • Yeniden sıralama çalışma anında ek bir adım getirdiği için kaçınılmaz olarak küçük bir gecikme ekler
  • Yeniden sıralama modeli tüm parçaları paralel puanlasa bile gecikme ve maliyet etkisi hesaba katılmalıdır
  • Daha fazla parçayı yeniden sıralamak performansı artırabilir, ancak maliyet ve gecikmeyi de yükseltir
  • Daha az parçayı yeniden sıralamak maliyet ve gecikmeyi düşürür, ancak performans artışı sınırlı kalabilir
  • Uygun denge, belirli kullanım senaryosunda farklı ayarlar denenerek bulunmalıdır

Birlikte kullanıldığında sonuçlar

  • Farklı veri kümesi türlerinde embedding modeli, BM25 kullanımı, Contextual Retrieval kullanımı, yeniden sıralama kullanımı ve top-K arama sayısı kombinasyonları karşılaştırıldı
  • Sonuç özeti şöyledir
    • Embeddings + BM25, yalnızca embedding kullanımından daha iyidir
    • Test edilen embedding'ler arasında Voyage ve Gemini en iyi sonucu verdi
    • Modele ilk 20 parçanın verilmesi, ilk 10 veya ilk 5 parçadan daha etkiliydi
    • Parçalara bağlam eklemek arama doğruluğunu belirgin biçimde artırdı
    • Yeniden sıralama, kullanılmamasına göre daha iyidir
    • Performansı en üst düzeye çıkarmak için Voyage veya Gemini tabanlı Contextual Embeddings, Contextual BM25, yeniden sıralama aşaması ve prompt'a 20 parça ekleme birlikte kullanılabilir
  • Geliştiriciler bu yaklaşımı Contextual Retrieval cookbook ile deneyebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-22
Hacker News yorumları

  • Kamu kurumları için kurumsal RAG geliştiriyoruz. RAGAS metrikleriyle deneysel A/B testleri yaptığımızda, sentetik değerlendirme sorularına göre hibrit aramanın (anlamsal arama + vektör) arkasına LLM tabanlı yeniden sıralama eklemek büyük bir değişiklik yaratmadı; HyDE ise yanıt kalitesini ve arama kalitesini ciddi biçimde düşürdü.
    Uzman soruları ve gerçek kullanıcı sorularıyla RAGAS değerlendirmelerini hâlâ daha fazla yapmamız gerekiyor.
    Bu yüzden üretim/kurumsal RAG’de hibrit aramanın genelde iyi olduğu yeni bir şey değil; ancak tek bir yöntem her zaman kazanmaz. Bizim durumumuzda vektör benzerliğinin yanında ikinci yöntem olarak yalnızca Azure AI Search’ün anlamsal araması yeterli oldu. Başka yerlerde BM25 veya ince ayarlanmış sorgu son işleme için küçük bir dil modeli iyi olabilir; sonuçta kullanım senaryosuna göre sürekli test etmek gerekiyor.
    Sırada RAPTOR, SelfRAG, ajan tabanlı RAG, sorgu iyileştirme (genişletme ve alt sorgular) ve GraphRAG’ı denemeyi planlıyoruz.
    Şimdiye kadarki ders şu: bir temel çizgi ve deney grupları belirleyip RAGAS gibi metriklerle sıfır hipotezini çürütmeye çalışmak gerekiyor; değerlendirme soru/yanıtları için de uzmanların yazdığı Q&A, loglardan elde edilen gerçek kullanıcı soruları ve kaynak belgelerden üretilen sentetik Q&A olmak üzere üç tür kullanılmalı.

    • Yorumda kullandığın kısaltmaları açıklayabilir ya da açıklayan bağlantılar verebilir misin?
    • HippoRAG hakkında ne düşündüğünü merak ediyorum. Zaten denediniz mi, yoksa ileride deneme planınız var mı?

  • Bu yöntemde en hoşuma giden şey, prompt caching’den iyi yararlanması.
    Önbelleğe alınmış prompt’lar genelde normal maliyetin yaklaşık 1/10’u düzeyinde olduğu için, her chunk’ı kaynak belgenin tamamıyla birlikte çalıştırmak gibi bir numara eskiden maliyet açısından mantıksızdı ama artık mümkün.
    Önbelleklemenin sağladığı maliyet düşüşü sayesinde buna benzer epey iyi tekniğin önünün açılacağını düşünüyorum.
    Bağlamsal arama notu: https://simonwillison.net/2024/Sep/20/introducing-contextual... ve prompt caching notu: https://simonwillison.net/2024/Aug/14/prompt-caching-with-cl...

    • Blogunu takip ediyorum ve LLM’lerle ilgili yazıların neredeyse hepsini okuyorum. Çeşitli LLM’leri ve özellikleri keşfetmenin aylık maliyetinin aşağı yukarı ne kadar olduğunu merak ediyorum.
      En yeni modelleri ve özellikleri takip etmek için ne kadar harcamak gerektiğine dair fikir vermesi açısından faydalı bir bağlam olurdu.
    • Embedding için önceden hesaplanabilecek çok şey var. Önbelleğe almak yerine ön hesaplama yapılabilir; böylece ETL’de yaygın olarak kullanılan birçok teknik devreye girebilir.
      Geleneksel arama geçmişinden bakınca, RAG’ı hazır embedding modelleri ve vektör aramayla sınırlamak oldukça safça bir strateji gibi görünüyor. Vektör arama kendi başına o kadar iyi değil; LLM’e sağlanacak bağlamı iyileştirmek için ek bilgi erişim stratejileri gerekiyor. Burada yapılan da aslında tam olarak bu.
      Microsoft daha önce bir Graph RAG makalesi yayımlamıştı; indeks verilerinden entity extraction ile oluşturulan kavram grafiğini temel alarak RAG ile vektör aramayı birleştiriyor. Bu sayede eşleşen chunk’larla bağlamsal olarak ilişkili bilgiler yukarı çekilebiliyor.
      Vektör arama olmadan da epey yol alınabileceğine dair bir hissim var. Maliyeti de çok daha düşük olur. Geleneksel bir arama motoru ve iyi ayarlanmış sorgular yeterli. Elbette kilit nokta sorgu ayarı; genel amaçlı senaryolara çok uymayabilir ama daha özelleşmiş kullanım durumlarında işe yarayabilir.
    • Maliyet bunun bir boyutu, peki ya veri toplama süresi? Bu yöntem pipeline’a kayda değer bir işleme süresi eklemiyor mu?

  • Biraz bağlam eklersek, bu yaklaşım o kadar da yeni değil. RAG sonuçlarını iyileştirmenin yaygın yollarından biri, eşleşebilecek anlamsal yüzey alanını artırmak için temel chunk’ları LLM ile “genişletmek”.
    HyDE[1] ile sorgu genişletme çalıştırılırsa daha da iyileşebilir; ama her zaman daha iyi sonuç vermediği için ben bunu alternatif bir yol olarak kullanıyorum.
    Anthropic’in burada yeni olarak ne sunduğundan pek emin değilim. Cookbook koduna bakınca da yalnızca ilgili bağlamı üretme sürecini gösteriyor; “bağlamsal arama” için API’de fiilen değişen bir şey yok.
    Değişen şey, bir ay önce sunulan prompt caching; uzun belgenin tamamını bağlam olarak verip tek tek chunk’lara çok düşük maliyetle daha iyi bağlam eklemeyi mümkün kılıyor. Caching, geliştiricilere açmak için harika bir özellik ve değerini teslim ediyorum.
    Ancak bunun dışında belirli bir RAG iş akışını gösteren bir cookbook’tan ibaret görünüyor.
    Ek olarak Cohere, kullandığım API’ler arasında en sevdiklerimden biri. Herhangi bir bağlantım yok; Cohere RAG API diğer sağlayıcılardan farklı olarak çok iyiydi. Şiddetle öneririm.
    1: https://arxiv.org/abs/2212.10496

    • Yenilik, bu yaklaşımın maliyetini karşılanabilir kılmak için caching kullanmasında gibi görünüyor. Uygulama biçimi, chunk oluştururken her seferinde LLM’den tam bağlam içinde atomik chunk üretmesini istemek şeklinde.
      Veride on binlerce chunk varsa bunun hepsini yapmak gerekir ve maliyetli olur. Belgeleri önbelleğe almak bu maliyeti azaltabilir.
    • Yaklaşık bir ay önce bunu Prompt Caching ile yapmayı denemiştim, ama önbelleğe alınmış prompt’un maksimum ömrünün 5 dakika olduğunu gördüm.
      Benim RAG gereksinimlerime pek uymuyor; muhtemelen çoğu kişi için de öyledir. Çünkü sorgu gelecek ay ya da bir yıl sonra çalıştırılabilir. Bu politikanın değiştiğini de sanmıyorum; bu yüzden RAG bağlamında Prompt Caching’den söz edilmesi bana biraz şaşırtıcı geliyor.

  • Biz de benzer bir şey yapıyoruz. Önce belgeleri h1, h2, h3 başlıklarına göre parçalara ayırıyor, parçanın başına başlıkları bağlam olarak ekliyoruz.
    Varsayımsal bir örnekle, özgün parça “Yetişkinler için genel doz günde 3 kez 1-2 adet 200 mg tablet veya kapsüldür” ise, artık # Fever, ## Treatment, bir ayırıcı çizgi ve ardından aynı içerik yer alıyor.
    Oldukça iyi çalışıyor gibi görünüyor ve belge indekslerken LLM de gerekmiyor.

    • LLM’in uzun bir yazının ya da ses transkriptinin Alan Watts tarafından yazılıp yazılmadığını nasıl bildiğini hep merak etmişimdir. Bu tür metadata anotasyonları, Llama modeli gibi şeylerin eğitim verileri hazırlanırken yaygın olmuş olmalı.
      “ChatGPT Aralık ayında yavaşladı” tartışmasının kökeni de bu olabilir. Yani o “tarih” metadata’sı, ChatGPT’ye daha az yardımcı olması gerektiğini bildirmiş olabilir.
    • 100 sayfayı aşan uzun belgeler veya belge kümeleri tabanlı soru-cevap üzerinde çalışıyorum ve benzer bir yaklaşım benimsedim.
      Önce her sayfayı özetleyip başlıklandırıyor ve alt bölüm listesini çıkarıyorum. Sonra tüm özetleri birleştirip modelden hiyerarşik bir indeks oluşturmasını istiyorum. Model tüm kümeyi bir ağaç halinde düzenliyor; sorgu anında da ağaç içindeki yolu ek bağlam olarak birleştiriyorum.
    • Eklenen başlıkları hangi biçimde koyacağınıza dair farklı yöntemleri deneyip denemediğinizi merak ediyorum. Ben de benzer bir şey yaptığım için soruyorum.

  • Bu teknik pek hoşuma gitmiyor. Sunulan senaryonun yaygın bir sorun olduğuna katılıyorum, ama önerilen çözüm bana yapay geliyor.
    Vektör embedding’lerinde kelime torbası sıkıştırması benzeri bir özellik var ve ilk satır sonu metin bloğuna aşırı indekslenebiliyor. Sonuçta vektörün belirli bir indeksi eskisine göre 0’a çok daha fazla yaklaşabiliyor. Kuantizasyondan geçince sonunda 0 oluyor ve yoğun vektörün hassasiyetinin büyük kısmı kaybedilebiliyor. IDF araması bunu bir ölçüde telafi etse de yeterli değil.
    Embedding’i, belge başlığına, özetine, abstract’ına vb. daha yakın hareket edecek şekilde “semantik olarak boost” ederseniz, bu “bağlam” önekinin recall avantajını elde ederken temel vektörü kirletmemiş olursunuz. Uygulama açısından bu, ağırlıklı toplamdır. Artırma aşamasında bağlam penceresine koyarken belge eşleşirse özet parçasını da birlikte enjekte edebilirsiniz. Kişisel olarak çok daha temiz bir çözüm.
    Trieve API’deki “semantic boost” açıklaması[1]:
    semantic_boost: Bir parçanın embedding vektörünü mesafe ifadesi yönünde hareket ettirmek için kullanışlıdır. Örneğin chunk_html’i iphone olan bir parçayı, distance_phrase olarak flagship, distance_factor olarak 0.25 kullanarak “flagship” terimine %25 daha yakın itebilirsiniz. Kavramsal olarak bu, chunk_html’in innerText vektörü ile distance_phrase vektörü arasında bir Öklid/L2 mesafe çizgisi çizmek ve bu çizgi boyunca chunk_html vektörünü distance_factorL2Distance kadar daha yakına veya uzağa taşımaktır.
    [1]:https://docs.trieve.ai/api-reference/chunk/create-or-upsert-...

    • Alakasız bir soru ama vektör veritabanları modeller arasında uyumlu mu? Embedding’lerin modele özgü olduğunu bildiğim için muhtemelen hayır diye tahmin ediyorum.
      Öyleyse vektör DB tek bir LLM’e, hatta Claude-3.5 Sonnet gibi tek bir sürüme bağlı kalıyor; 3.5 Haiku’ya veya Opus’a bile taşınamıyor ve ChatGPT ya da Llama’ya geçmek için yeniden indeksleme gerekiyor demek değil mi?

  • En yararlı gördüğüm teknik, bir parçanın kendisine referans veren öğelere yönelik birden çok işaretçi taşıdığı bağlı liste stratejisi uygulamak. Bunu manuel yapıyorum, ama belirli bir düğüme referans verilebilecek yöntem çeşitliliği ciddi ölçüde artıyor.
    Başka türlü bakarsak, yorumlar gibi. Bu yazının altındaki tüm yorumlar, ana yazıyı işaret eden pointer’lar olarak görülebilir. Bazı yorumların ana yazıyla semantik mesafesi yakındır, bazıları ise yazarın algısı nedeniyle daha uzaktır. Ama her yoruma parent_id verirseniz ana yazıya erişim yolları artar.
    Bu tekniğin bir örneğini burada görebilirsiniz [1]. Son kullanıcının hangi sorguyu yapacağını tahmin etmeye çalışmıyor; sadece kullanıcının konuşmasına izin verip bunu pointer olarak indeksliyor. Bir nesneyi ifade etmenin seçenekleri sınırlıdır, ama bazı ifadeler çekirdek nesnenin anlamından çok, çok, çok uzaktadır.
    [1] - https://x.com/yourcommonbase/status/1833262865194557505

  • Küçük veri kümelerinde en iyi yanıtı almak için 200 bin token’ı öylece koymanın yeterli olduğu sözü benim deneyimimle uyuşmuyor.
    Prompt büyüdükçe çıktının tutarlılığının azaldığını ve yönergelere uymanın da kötüleştiğini sık görüyorum. Hatta bunun 25k tokendan çok daha düşük aralıklarda bile olduğu izlenimine kapılıyorum. Başkaları da yaşıyor mu, bunu önlemek için iyi bilinen yöntemler var mı merak ediyorum.

  • İlginç. Benim yaşadığım sorun, RAG ile bilgi parçacıkları değil, uygulanabilir kuralları aramak. Bağlama yalnızca o bağlama uygulanabilecek kurallar enjekte edilmeli
    Henüz denemedim ama belirli bir kuralın uygulanıp uygulanamayacağını değerlendiren küçük bir sınıflandırıcı eğitmenin işe yarayabileceğini düşünüyorum. Ana LLM, mevcut bağlamda o kuralın gerçekten uygulanıp uygulanmadığını belirleme rolünü üstlenir
    Örneğin bir LLM ile çok kullanıcılı bir dungeon oyunu oynadığımızı varsayalım. Geçmişte karakterin taksilerle ilgili kötü bir davranışta bulunduğunu ve oyunun “Taksiye binmeye her çalıştığında kovulur. ‘Kim olduğunu biliyoruz ve taksi şirketinin müdüründen resmen özür dileyene kadar seni müşteri olarak kabul etmeyeceğiz’” şeklinde bir kural oluşturduğunu düşünelim. Özür dilerse kural kaldırılır. Taksi şirketinin müdürü başka bir oyuncu da olabilir, kendi NPC taksi filosunun uygulayacağı kuralı ilk tetikleyen kişi de olabilir
    Etkin kural sayısı açısından bunun ne kadar ölçekleneceğini ve geleneksel RAG’nin ne ölçüde uygulanabileceğini merak ediyorum. Bir kuralın uygulanıp uygulanmadığını belirlemek, bir bilgi parçacığının ilgili olup olmadığını belirlemekten daha soyut ve zor bir problem gibi görünüyor
    Bunu özellikle zorlaştıran temel nokta, bilgi aramada olmayan bağımlılık döngüsü. Bir kuralın uygulanıp uygulanmadığını saptamak için önce o kuralı arayıp bulmak gerekiyor. Bu problem nasıl çözülebilir?

    • Oyun içi bağlam sorguda düzgün biçimde tarif edilirse, RAG’de kullanılan geleneksel vektör arama bu durumda da uygun görünüyor
      Örnek sorgu, LLama 3.1 8B’nin yardımıyla yazılırsa, kara elf ordusunun yaklaştığı, Grimgold Ironfist’in çaresiz bir durumda olduğu; geçmişte cüce milisinin gururlu bir üyesiyken şimdi canının %35 olduğu, envanterinde eski bir kazma, bir su kovası, bayat ekmek ve 17 altın sikke bulunduğu; Taxi Guild ile “sorunlu geçmişine” rağmen yoldaki bir taksiyi durdurmaya çalıştığı gibi yeterince ayrıntılı yazılabilir
      Vektör deposundan getirilecek kural örneği, karakter adı/özellikleri ile taksi ve Taxi Guild ifadeleri nedeniyle vektörel yakınlık oluşacağından bulunacaktır
      “Taxi Guild, Grimgold’a ağır bir ceza uyguladı. Taksi durdurmaya her çalıştığında derhal araçtan atılır. Guild fermanında şöyle yazar: ‘Grimgold Ironfist, itibarı kötü sakallı cüce, Golden Horse Cab Company’nin müdürü Thorgrim Stonebeard’dan resmen özür dileyene kadar üyelerin işlettiği hiçbir taksiye binemez. Buna uyulmaması, hizmetlerimizden kalıcı olarak men edilmesiyle sonuçlanır’” gibi bir kural

  • “Bilgi tabanı 200.000 tokenden küçükse (yaklaşık 500 sayfa)” diyorlar; keşke Anthropic sadece tokenizer’ı yayımlasa da tahmin yürütmek zorunda kalmasak

    • Yanıtları token bazında stream ettikleri için tersine mühendislik mümkün olmaz mı?

  • Tüm AI sektörünün bir tur atıp sonunda TF-IDF’ye geri döneceği günü bekliyorum

    • Evet, bana da biraz komik geldi. elasticsearch gibi ürünlerin zaten klasik metin eşleştirme algoritmalarını varsayılan olarak desteklediğini sanıyorum