- Skald, verileri üçüncü taraflara göndermeden tamamen self-host edilebilen bir RAG sistemi hedefiyle geliştirildi
- RAG bileşenleri vektör veritabanı, embedding modeli, LLM, reranker, belge ayrıştırıcı olarak ayrılıyor ve her bir unsur için açık kaynak alternatifler sunuluyor
- Skald’ın varsayılan yerel yığını Postgres+pgvector, Sentence Transformers, Docling, kullanıcı tanımlı LLM bileşenlerinden oluşuyor
- Benchmark sonuçlarında bulut tabanlı model (Voyage+Claude) ortalama 9.45 puan alırken, tamamen yerel GPT-OSS 20B 7.10~8.63 puan aralığında değerlendirildi
- Bu yaklaşım, veri gizliliğini korurken de yüksek performanslı RAG kurulabileceğini gösteriyor
RAG bileşenleri ve açık kaynak alternatifler
- Temel bir RAG, vektör veritabanı, embedding modeli, LLM bileşenlerinden oluşur; buna ek olarak reranker ve belge ayrıştırıcı da dahil olabilir
- Her bileşen, SaaS yerine yerel alternatiflerle değiştirilebilir
- Örnek tabloda sunulan alternatifler
- Vector DB: Pinecone, Weaviate Cloud → Qdrant, Weaviate, Postgres+pgvector
- Embeddings: OpenAI, Cohere → Sentence Transformers, BGE, E5
- LLM: GPT, Claude → Llama, Mistral, GPT-OSS
- Reranker: Cohere → BGE Reranker, Sentence Transformers Cross-Encoder
- Document Parsing: Reducto → Docling
- Skald, tamamen açık kaynak bir yığın hedefliyor ve her bileşeni yerelde çalıştırıyor
Skald’ın yerel yığın yapısı
- Vector DB: Postgres + pgvector kullanılıyor
- Mevcut altyapıya kolay entegre oluyor ve yüz binlerce belgeye kadar işleyebiliyor
- Vector Embeddings: Varsayılan olarak Sentence Transformers (all-MiniLM-L6-v2)
- Yalnızca İngilizce için, hız ile arama performansı arasında dengeli
- bge-m3 modeli (çok dilli destek) de test edildi
- LLM: Yerleşik olarak sunulmuyor, kullanıcı doğrudan kendisi çalıştırıyor
- Testlerde GPT-OSS 20B EC2 üzerinde çalıştırıldı
- Reranker: Varsayılan olarak Sentence Transformers Cross-Encoder; çok dilli model olarak bge-reranker-v2-m3 gibi seçenekler de kullanılabiliyor
- Document Parsing: Docling kullanılıyor ve
docling-serve ile çalıştırılıyor
Performans ve dağıtım sonuçları
- Tüm yığını içeren bir Skald production instance dağıtımı 8 dakika sürdü
- Postgres, embedding ve reranking servisleri ile Docling dahil
- LLM ayrı çalıştırıldı (
llama.cpp kullanıldı)
- Test veri kümesi, PostHog web sitesi içeriği (yaklaşık 2000 belge) ve özel hazırlanmış bir soru-cevap setinden oluştu
- Deney ayarları
- Vector search topK=100, Reranking topK=50, Query rewriting=Off
- Değerlendirme ölçütü doğruluk odaklı
Benchmark sonuçlarının karşılaştırması
- Voyage + Claude (bulut kurulumu)
- Ortalama puan 9.45, tüm yanıtlar doğru
- Voyage + GPT-OSS 20B (kısmen yerel)
- Ortalama puan 9.18, çoğu doğru ancak bazı bilgiler eksik
- Tamamen yerel + GPT-OSS 20B
- Temel İngilizce model (all-MiniLM-L6-v2 + ms-marco-MiniLM-L6-v2) : ortalama 7.10
- İngilizce sorgularda doğru, ancak çok dilli sorgular, belirsiz sorgular ve çok belgeli toplulaştırmada zayıf
- Çok dilli model (bge-m3 + mmarco-mMiniLMv2-L12-H384-v1) : ortalama 8.63
- Portekizce sorguları başarıyla işledi, ancak çok belgeli toplulaştırmada bazı eksikler vardı
- Başlıca sınırlama, birden fazla belgeye dağılmış bilgiyi birleştirerek işleme konusu
- Bulut modeller bunu yüksek performansla telafi ederken, yerel ortamda ek teknikler gerekiyor
Gelecek planları
- Skald, yerel RAG performansını artırmayı ve açık kaynak modeller için benchmark sonuçlarını yayımlamayı planlıyor
- Air-gapped ortamlarda yapay zeka araçları çalıştırmak zorunda olan şirketler için çözüm sunmayı hedefliyor
- Katılmak isteyenler GitHub(skaldlabs/skald) veya Slack topluluğu üzerinden iş birliği yapabilir
7 yorum
RAG için vektör veritabanı gerektiği fikri acaba nereden çıktı…
Vektör DB falan, aslında yapılması gereken şey sadece aramayı uygulamak gibi görünüyor...
Gemini: Evet, RAG'de (Retrieval-Augmented Generation) vektör veritabanı (Vector Database) kullanımıyla ilgili kavramsal temel, ilgili makalenin ilk kez yayımlandığı 2020 yılından itibaren atılmıştır.
RAG, temel olarak arama (Retrieval) ile üretimi (Generation) birleştiren bir yaklaşımdır ve bu arama aşamasında vektör gömmeleri ile bunları verimli biçimde depolayıp arayan vektör veritabanları kritik bir rol oynar.
💡 RAG ve vektör DB'nin başlangıç noktası
RAG'de vektör DB gerektiği fikri, aşağıdaki önemli makale ve kavramlardan doğmuştur.
Vektör veritabanlarının RAG'in vazgeçilmez bir parçası hâline gelmesinin temel nedeni şudur.
Özet: Vektör DB neden gereklidir?
Bir LLM'in eğitim almadığı güncel veya alana özgü bilgiye erişmesini sağlamak için, yalnızca anahtar kelime eşleştirmesine (geleneksel arama) değil, anlamsal benzerliğe dayalı bilgi bulmaya ihtiyaç vardır. Vektör DB, bu anlamsal benzerlik tabanlı aramayı verimli biçimde gerçekleştirmek için RAG çerçevesine doğal olarak entegre edilen temel teknolojidir.
Aslında RAG için gereken şey arama işlevi; dense vektörlerle embedding yapıp vectorDB’ye push etmek ve cosine similarity araması yapmak, arama motoru uygulamanın birçok yolundan yalnızca biri... Elbette vectorDB kullanmamak için özel bir neden yok, ama gerçekten şart mı diye sorunca, uzun zamandır gayet iyi kullanılan pek çok arama motoru algoritması varken insanın kafası biraz karışıyor.
Ucuz ve çoğu prodüksiyon LLM bunu kullanıyor.
Aslında web sunucusu da bu mantıkla, altyapı işlevleri eklenirse her şeyi disk üzerinde halledebilir; o zaman DBMS'ye de gerek kalmaz tabii haha
Kullanıcı sorgusunun embedding değerini (vektörünü) anahtar olarak kullanan bir tür benzerlik/anlamsal arama için bir veritabanına ihtiyaç duyulduğu doğru. Anahtar vektör biçiminde olduğu için vector DB de doğru.
Hacker News görüşü
Böyle bir sistem kurarken vektör veritabanı ya da embedding'lere takılıp kalmamak gerektiğini söylemek isterim
Tam metin arama veya
grep/rggibi araçlar çok daha hızlı ve ucuzdur, ayrıca indeksi korumaya da gerek yokturİyi bir LLM'e arama araçları verirseniz “dog OR canine” gibi sorguları kendisi üretip yinelemeli olarak iyileştirebilir
Üstelik bu şekilde chunking sorununu çözmeniz de gerekmez
Search Sensei üzerinden bakabilirsiniz
İlk yüklemede yaklaşık 50MB model ağırlığı ve onnx runtime indiriyor, ama sonrasında sorunsuz çalışıyor
Örneğin BM25, “j lo” ile “jlo”nun Jennifer Lopez anlamına geldiğini anlayamazken embedding tabanlı arama bu tür yazım hataları veya takma adları iyi yönetiyor
Arama, 2016~2024 arasındaki 1000 haber makalesi üzerinde yapılıyor
Ama BM25'in tek başına performansının paylaşılmamış olması üzücü
Kendi küçük testlerimde, sorgu kelimesini aynen içeren sayfaları embedding'in kaçırdığı durumlar oldu — sonuçta Ctrl+F kazandı
Lexical arama yüksek precision ama düşük recall sunarken, semantic arama bunun karşı tarafında duruyor
Daha çok “NOT” işleci gerektiğini düşündüm. RAG hakkında da daha fazla şey öğrenmek istiyorum
Bazı ajan tarzı araçların bu sorguları otomatik oluşturduğunu gördüm ama bunun prompt ile mi yönlendirildiğini yoksa varsayılan davranış mı olduğunu bilmiyorum
Düşük performansın sebeplerinden biri semantic chunking eksikliği olabilir
Belgenin tamamını embedding'e çevirmek, birden fazla kavramı karıştırdığı için doğruluğu düşürür
Spacy gibi araçlarla anlamsal birimlere ayırıp, her chunk'ın belge içinde hangi bağlamda olduğunu ekledikten sonra embedding'e çevirmek gerekir
Anthropic'in contextual retrieval yaklaşımı RAG sistemlerinde çok etkili oldu
Bağlam üretimi için GPT OSS 20B modeli kullanılabilir
Birden fazla belgenin bağlamını birleştirmeyi gerektiren sorularla test ettiğimiz için bir yanlış anlama olmuş gibi görünüyor
Neden semantic aramanın lexical aramadan üstün olduğu varsayılıyor, bunu merak ediyorum
2023'te Tantivy(BM25) ile karşılaştırdığımda sonuç farkı çok küçüktü
Recall'da biraz artış olsa bile, o karmaşık yapıyı kurmaya değip değmediğinden emin değilim
Geliştirici testlerinde recall %90'dı ama gerçek kullanıcı testlerinde bu oran %30 seviyesine düştü
Kullanıcılar belgedeki tam terimi bilmediği için yalnızca lexical arama yeterli olmadı
Üstüne bir ajan katmanı koyabilirsiniz ama latency artıyor ve kullanıcı memnuniyeti düşüyor
Wanderfugl'da BM25 puanı düşük kalan bölümleri semantic arama iyi buluyor
Sonuçta cevap hibrit sıralama olabilir
Sonuç olarak bu tamamen kullanım senaryosuna bağlı
E-posta, Slack, GDrive, kod, wiki vb. tüm verileri yerel ve çevrimdışı olarak sorgulayabileceğim bir açık kaynak araç arıyorum
Kendim kurmak ya da özelleştirmek istemiyorum; iyi varsayılan ayarlar ve model önerileri olsa güzel olurdu
GitHub bağlantısı
Temelde CRUD destekliyor ve vektör aramayı etkinleştirirseniz belgeleri veya notları embedding'e çeviriyor
Ollama ve OpenAI'yi embedding sağlayıcısı olarak destekliyor
MCP sunucusu hem semantic + BM25(qdrant fusion) aramayı sunuyor hem de MCP sampling ile yanıt üretiyor
Sunucu yanıtı kendisi üretmiyor; herhangi bir LLM/MCP istemcisiyle entegre olabiliyor
Bu MCP sampling/RAG deseni çok güçlü ve bunun başka veri kaynaklarına genellenmiş açık kaynak sürümleri de büyük ihtimalle çıkacaktır
Kullandığımız araç haiku.rag
Geliştirici dostu Python kodu, pydantic-ai tabanlı yapı, benchmark'lar ve gelişmiş alıntılama özellikleri sunuyor
Derin araştırma ajanını destekliyor ve uzun vadede sürdürülen gerçek bir açık kaynak proje
Varsayılan embedding modeli olarak Sentence Transformers (all-MiniLM-L6-v2) kullanıyorum ama bunun yalnızca İngilizceye yönelik olduğunu, bu yüzden Almanca bir RAG kurarken sorun çıkarabileceğini fark ettim
İngilizce dışı modellerin performansının nasıl olduğunu merak ediyorum
“Retrieval” bölümündeki RTEB Multilingual veya RTEB German başlıklarına göz atın
CPU tabanlı self-hosting yapacaksanız 100M parametrenin altındaki modellerle filtrelemek iyi olur
Ama Almanca için eğitim verisi görece fazla ve yeterince çok dilli model de var
Özellikle ticari API tabanlı modellerin çoğu çok dilli desteğe sahip
İlgili makale için Springer bağlantısına bakabilirsiniz
GPT-4 döneminde (8K context), bütün kitabı chunk'lara bölüp GPT-4'e vererek ilgili pasajları arayan bir betik yazmıştım
O zamanlar tek arama yaklaşık 1 dolara mal oluyordu ama artık çok daha ucuz
Anthropic'in contextual retrieval yazısında da, belge zaten context'e sığıyorsa RAG yerine doğrudan vermenin daha iyi olduğu söyleniyor
Yine de context uzadıkça kalite düşüyor, maliyet ve hız da sorun oluyor
Artık kitabın tamamını context'e koymak bile 1 sent seviyesinde mümkün
RAG'deki en zor kısım belge ayrıştırma
Sadece metinle çalışırken sorun yok ama tablolar, çok sayfalı tablolar, grafikler, içindekiler, dipnotlar vb. olduğunda doğruluk hızla düşüyor
Bunu iyileştirmek için RAPTOR deseni gibi, LLM'in içeriği özetleyip sorular üreterek vektör veritabanına kaydettiği yaklaşımlar var
Ama her durumda işe yarayan genel amaçlı bir RAG pipeline'ı hâlâ zor bir problem
Vektör veritabanlarının uzun metin gruplarıyla mı yoksa tablo biçimiyle mi daha iyi başa çıktığını da merak ediyorum
Tam metin aramayı RAG'e uygulayan bu yeni bakış açısı ilginç geldi
Ajan tarzı araç döngüsü ve bulanık arama (fuzzy search) işleme yöntemi hakkındaki içgörüler etkileyiciydi
Bu tür sistemler için değerlendirme veri kümelerinin standartlaştırılmış olup olmadığını merak ediyorum
Belgeler ve soru setlerinden oluşan, belirli belge ya da chunk'ın en ilgili sonuç olarak çıkması gereken türden benchmark'lar olsa iyi olurdu