- Hacker News'te bir kullanıcı, yerel ortamda Retrieval-Augmented Generation (RAG) sistemini nasıl kurduklarını soruyor
- Yerel RAG'da vektör DB olmadan da SQLite FTS5, BM25 ve grep gibi metin aramayla işin rahatça yürütülebildiği yönünde güçlü bir eğilim var
- Kod aramada embedding'lerin yavaş ve gürültülü olduğuna dair çok sayıda deneyim paylaşılırken, BM25+trigram gibi anahtar kelime tabanlı yaklaşımların daha iyi olduğu da sıkça savunuluyor
- Vektör arama gerektiğinde bile Postgres+pgvector, SQLite'ta vektör BLOB saklama veya FAISS'i belleğe yükleme gibi hafif kurulumlarla çözüm üreten örnekler öne çıkıyor
- BM25+vektör birleşimiyle yapılan hibrit arama ve RRF (Reciprocal Rank Fusion), yeniden sıralama, çoklu sorgu genişletme gibi kombinasyonlarla arama kalitesinin artırılabildiği belirtiliyor
- “RAG=vektör DB” anlayışına saplanmak yerine, belge türü, ölçek ve operasyon yüküne göre basit arama → hibrit → ajanik yapı arasında seçim yapma eğilimi görülüyor
Arama aşamasında öne çıkan ortak sonuçlar
- Vektör DB ya da grafın zorunlu olduğu varsayımı yerine, mevcut altyapıya, dosya türlerine ve gereken performansa göre basit başlamak daha yaygın bir yaklaşım
- Ajanın dosya sistemini ya da API'leri doğrudan sorguladığı yöntemlerin kurulum ve bakım açısından daha kolay, ancak biraz daha yavaş olabileceği belirtiliyor
- “RAG'ın LLM'e verdiği şey, arama sonuçlarından gelen kısa metin parçalarıdır” anlayışı, performans iyileştirme odağını arama kalitesine kaydırıyor
- “RAG tanımı” konusunda, vektör DB olmasa da retrieval+generation varsa bunun RAG sayılacağı görüşüyle, pratikte çoğu zaman vektör DB varsayılarak kullanıldığı görüşü birlikte yer alıyor
Embedding modelleri ve vektör arama
- MongoDB tarafından geliştirilen mdbr-leaf-ir embedding modeli yalnızca CPU üzerinde çalışıyor ve bu boyuttaki modeller arasında çeşitli liderlik tablolarında 1. sıraya yerleşmiş durumda
- Standart 2vCPU sunucuda saniyede yaklaşık 22 belge ve 120 sorgu işleyebiliyor
- BEIR benchmark'ında 53.55 puan aldı (
all-MiniLM-L12-v2 ise 42.69)
- model2vec/minish gibi statik kelime embedding'leri daha hızlı çıkarım sağlıyor, ancak arama doğruluğu daha düşük
- Yalnızca tokenization + lookup table + ortalama aldığı için transformer tabanlı modellere göre daha hızlı
- Meta-Llama-3-8B ile metin chunk'ları için vektör üretip bunları SQLite BLOB sütununda saklayarak FAISS ile arama yapan yaklaşımlar da kullanılıyor
- 5 milyon chunk için yaklaşık 40 GB bellek kullanılıyor
- A6000 üzerinde
faiss-gpu çok hızlı; M1 Ultra'da faiss-cpu daha yavaş ama günde birkaç sorguluk kullanım için yeterli
Kod arama için öneriler
- Kod için vektör veritabanı kullanmaktan kaçınılması ve BM25+trigram kombinasyonunun tercih edilmesi öneriliyor
- Embedding'ler yavaş ve koda çok uygun değil
- Yeniden sıralayıcı yoksa gürültü artıyor, dosyaları yeniden indeksleme yükü de yüksek oluyor
- Arama yanıt süresi hızlı, sonuç kalitesi de yüksek
- PostgreSQL'de plpgsql_bm25 ile BM25 araması uygulanabiliyor
- pgvector ile birleşen hibrit arama + Reciprocal Rank Fusion desteği var
- Dosya yolu + imza bilgisine embedding uygulayıp BM25 ile füzyon yapmak iyi sonuç verebiliyor
- gpt-oss 20B modelini
ripgrep ile birlikte while döngüsünde çalıştıran ajanik yaklaşımın da etkili olduğu belirtiliyor
Veritabanı tabanlı çözümler
- SQLite FTS5: Markdown dosya tabanlı belgeler için uygun; vektör DB olmadan da RAG kurulabiliyor
- Her dosyada kısa bir açıklama alanı tutup belge gezintisini anahtar kelime aramayla yapmak mümkün
- SQLite'a
fp16 vektörleri BLOB olarak kaydedip, filtrelerle alt küme oluşturduktan sonra benzerlik hesabını bellekte çalıştıran tasarımlar da mümkün
sqlite-vec, sqlite-vector, vec0, SQLite'ın bm25 seçeneği gibi alternatifler mevcut- “SQLite şaşırtıcı derecede iyi çalışıyor”
- PostgreSQL + pgvector: Mevcut Postgres bilgisinden yararlanılabiliyor ve operasyon ekibine devretmek daha kolay
- Hibrit BM25, çoklu sorgu genişletme ve yeniden sıralama destekleyen llmemory kütüphanesi de var
- LanceDB: Gömülü bir vektör DB olarak pratik kullanım sunuyor
- Ollama'nın nomic-embed-text embedding'i ile birlikte kullanılıyor
- DuckDB: Vektör benzerlik araması için eklenti sağlıyor; 3 GB altındaki küçük projeler için uygun
- Meilisearch, Typesense, Manticore: Elasticsearch/OpenSearch'e göre operasyonu daha basit
Hibrit ve ajanik arama
- nori(usenori.ai): SQLite + vec0 + fts5 ile anlamsal ve kelime aramasını birleştiriyor
- Turbopuffer: Vektör + BM25 hibrit aramayı destekliyor
- Yalnızca ajanik arama ile metin aramasını birleştirerek bile oldukça iyi sonuç alınabildiği belirtiliyor
- Vektör arama ve graph RAG eklenirse hız ve kalite tarafında bir miktar daha iyileşme görülebiliyor
- Claude Code ve Codex'in arka planda ripgrep kullandığı ifade ediliyor
- Dosya yollarına embedding uygulamak da etkili; BM25 ile füzyon yapıldığında daha da iyileşiyor
BM25 kullanım örnekleri
- shebe: BM25 tabanlı kod tabanı indeksleme ve arama için CLI/MCP aracı
- Özellikle refactoring iş akışlarında faydalı (ör. Istio yükseltmesi sırasında değişmesi gereken yerleri listelemek)
- Vakaların %85'inde vektör DB olmadan yalnızca etiket eşleştirme yeterli oluyor
- Operatörlerin hem girdilere hem belgelere etiket ekleyerek %100 eşleşme sağladığı örnekler var
- Bazı görüşlere göre çoğu vektör DB, “bulamama sorununu çözmek için elde tutulan çekiç” gibi
Özel araçlar ve kütüphaneler
- qmd: Markdown dosyalarında arama için CLI aracı; bulanık sorgularda
fzf'den daha iyi sonuç veriyor
- ck: Rust tabanlı anlamsal grep aracı
- Kiln: Sürükle-bırak ile dosya eklemeye izin veriyor ve farklı ayarları karşılaştırabiliyor
- Çıkarma yöntemi, embedding modeli ve arama biçimi (BM25, hibrit, vektör) karşılaştırılabiliyor
- Arama doğruluğunu değerlendirme ve değerlendirme veri kümesini otomatik üretme özellikleri sunuyor
- libragen: Sürüm kontrollü RAG içerik kütüphanesi oluşturmak için CLI/MCP sunucusu
- GitHub deposunu RAG DB'ye dönüştürebiliyor
- piragi: Basit bir Python RAG kütüphanesi; yerel, S3, API gibi çeşitli kaynakları destekliyor
- ragtune: Yerel RAG aramasını debug etmek ve benchmark yapmak için CLI aracı
Belge işleme ve OCR
- discovery: Qwen-3-VL-8B ile belge OCR yapıp vektörleri ChromaDB'de saklıyor
- BM25 + embedding hibrit RAG uyguluyor
- docling: Belge çıkarımı için araç; çeşitli RAG projelerinde kullanılıyor
- PDF dönüştürmede tablo, çoklu sütun ve sayfaya taşan tablo işlemleri zor olabiliyor
- En iyi sonuçları Mistral OCR modeli veriyor (kapalı model)
Bellek ve bağlam yönetimi
- RAG'ın LLM'e ilettiği şey yalnızca kısa arama sonucu dizeleri
- Küçük modellerde
TOP_K=5 civarı sınır olarak görülüyor; bunun üstünde bağlam unutulması yaşanabiliyor
- Dosya ve klasörleri önceden özetleme yöntemiyle iyileştirme yapılabiliyor
- Sonnet + 1M context window ile her şeyi doğrudan bağlama koyan kullanım da mevcut
- Oturum dosyalarında anlamsal aramayla Claude Code için bellek sistemi kuran örnekler var
Kurumsal ve büyük ölçekli kullanım
- Günde 300 bin müşteri etkileşimi işlenirken gecikme ve hassasiyet kritik hale geliyor
- Embedding + tam metin arama + IVF-HNSW hibrit yaklaşımı kullanılıyor
- Yaklaşık 600 dağıtık sistem arasında bilgi yayılımını yönetmek önemli bir sorun
- KAG (Knowledge Augmented Generation) yaklaşımıyla iş kurallarını eşleme denemeleri yapılıyor
- 500 binden fazla haber makalesi için Postgres vektör DB ile tamamen yerel RAG kurulumunun başarıyla yapıldığı aktarılıyor
Diğer araçlar ve yaklaşımlar
- AnythingLLM: Belgeler için paketlenmiş vektör DB sunuyor
- LibreChat: Belgeler için paketlenmiş vektör DB içeriyor
- ChromaDB: Obsidian eklentisiyle anlamsal/hibrit arama uyguluyor
- SurrealDB: Yerel vektörleştirmeyle birlikte kullanılıyor
- OData sorgu arayüzü: LLM'e araç olarak verildiğinde etkili; 40 bin satırlık Excel analizi yapılabiliyor
- Nextcloud MCP Server: Vektör DB olarak Qdrant kullanıyor ve kişisel belgelerde anlamsal arama sağlıyor
- LSP (Language Server Protocol): Claude Code'a eklendi ancak şu anda hatalar var
- TreeSitter daha faydalı olabilir (sembol adına göre sorgulama, tanım/kullanım yerini bulma)
3 yorum
Korece desteğinin iyi olup olmadığından emin değilim.
Şirket içindeki kaba saba bir RAG sisteminin performansını gördükten sonra, böyle bir gönderiyi görünce bakış açımın biraz değiştiğini düşünüyorum
Hacker News yorumları
Ekibimiz bir Soru-Cevap veritabanı işletiyor
Soruları ve yanıtları hem trigram indeks hem de embedding ile indeksleyip Postgres'te saklıyoruz
Arama sırasında
pgvectorile trigram aramayı birlikte kullanıyor, sonuçları ilgililik skoru ile birleştiriyoruzArama aşamasında CPU dostu, yüksek verimli bir metin embedding modeli geliştirdik
MongoDB/mdbr-leaf-ir modeli, aynı boyuttaki modeller arasında liderlik tablosunda 1. sırada yer alıyor
Snowflake/snowflake-arctic-embed-m-v1.5 modeliyle uyumlu
search-sensei demosu üzerinden semantic arama vs BM25 vs hybrid karşılaştırması yapılabiliyor
Örneğin embedding modeli, “j lo”nun “Jennifer Lopez” anlamına geldiğini fark ediyor
Ayrıca eğitim reçetesini da yayımladık; orta seviye donanım ile bile kolayca eğitilebiliyor
Nisan 2024'ten beri Meta-Llama-3-8B ile vektör üretiyorum
Python ve Transformers'ı RTX-A6000 üzerinde kullandım; hızlıydı ama gürültü ve ısı çok fazlaydı
Sonra M1 Ultra'ya geçip Apple'ın MLX kütüphanesini kullandım; hız benzer kaldı ama sistem çok daha sessizdi
Llama modeli 4k boyutlu olduğu için fp16 için 8KB/parça ediyor; bunu SQLite'ın BLOB sütununa
numpy.save()ile kaydediyorumArama sırasında SQLite'tan tüm vektörleri yükleyip
numpy.arrayhaline getiriyor, ardından FAISS ile arama yapıyorumRTX6000 üzerindeki faiss-gpu son derece hızlı, M1 Ultra'daki faiss-cpu da benim kullanımım için (günde birkaç sorgu) fazlasıyla yeterli
5 milyon parça için bellek kullanımı yaklaşık 40GB; iki sistem de bunu rahatlıkla kaldırabiliyor
Karmaşık belgelerin çoğu Markdown dosyası
tobi/qmd adlı basit CLI aracını öneririm
Eskiden fzf tabanlı bir iş akışı kullanıyordum ama bu araç daha iyi fuzzy search sunuyor
Kod aramada kullanmıyorum
Kod araması için vektör veritabanı kullanmayın diye öneriyorum
Embedding'ler yavaş ve kod için uygun değil
BM25 + trigram kombinasyonu daha iyi sonuç veriyor, yanıt süresi de daha hızlı
plpgsql_bm25 projesine bakabilirsiniz
BM25 ile pgvector'ü Reciprocal Rank Fusion ile birleştiren örnekler ve Jupyter not defterleri de var
Kod için eğitilmemiş model kullanınca vektör arama çok fazla noise üretiyor
Şu anda
gpt-oss 20Byi ripgrep ile döngüye sokmak çok daha hızlı ve doğruBM25 ile birleştirilince (fusion) daha da iyileşiyor
Yerel RAG denemeleri için local-LLM-with-RAG oluşturdum
Ollama'nın “nomic-embed-text” modeliyle embedding üretiyor, vektör veritabanı olarak LanceDB kullanıyorum
Son zamanlarda bunu “agentic RAG” olarak güncelledim ama küçük projeler için fazla gelebilir
fp16 vektörleri SQLite'ta BLOB olarak saklıyor, filtrelemeden sonra belleğe yükleyip matris-vektör çarpımı (matvec) ile benzerlik hesaplıyorum
numpy veya torch çoklu iş parçacığı/BLAS/GPU kullandığında bu yöntem çok hızlı
Darboğaz oluşursa sqlite-vector tarafına geçmeyi planlıyorum
Tarih veya konum gibi filtreler veriyi ciddi biçimde azalttığı için verimli oluyor
Arka uç, değiştirilebilir bir arayüzün arkasına gizlenmiş durumda
Belgelerimin %95'i küçük Markdown dosyaları olduğu için SQLite FTS5 ile düz metin arama indeksi kullanıyorum
İndeks zaten hazır olduğundan bunu doğrudan mastra agent'a bağladım
Her dosyada kısa bir açıklama alanı var; anahtar kelime aramasından sonra açıklama eşleşirse tüm belgeyi yüklüyorum
Kurulum yaklaşık bir saat sürdü ve son derece iyi çalışıyor
Embedding tabanlı arama daha yaygın olsa da özünde aynı şey
Postgres'e alışık olduğumuz için PGVector ile başladık
Sonradan, istemdeki yarı yapılandırılmış alanların içerikle %100 eşleştiğini fark ettik
Çünkü operatörler hem girdilere hem de belgelere etiket eklemeye başlamıştı (yaklaşık 50 belge)
Bu yüzden önce alanlarda arama yapıp ilgili dosyayı isteme ekliyoruz, ardından embedding araması yapıyoruz
Sonuç olarak vakaların %85'inde vectordb gerekmiyor
llmemory'yi geliştirdim ve hem yerelde hem de şirket uygulamalarında kullanıyorum
PostgreSQL + pgvector tabanlı; hibrit BM25, multi-query expansion ve reranking özelliklerini içeriyor
İlk kez kamuya açıyorum, bu yüzden ufak tefek hatalar olabilir
Performansından oldukça memnunum