RAG ve Vektör Veritabanları
Kuruma özel veriyle çalışan AI agent'lar: doküman parçalama, embedding, vektör arama, kaynaklı yanıt üretimi.
Bu bölümde
RAG (Retrieval-Augmented Generation), bir LLM'e dışarıdan bilgi enjekte ederek kuruma özel sorulara doğru cevap vermesini sağlayan tekniktir. Saf LLM'in iki temel sorunu vardır: (1) eğitim verisinden sonraki bilgileri bilmez, (2) sizin şirket içi PDF'lerinizi, sözleşmelerinizi, ürün dokümanlarınızı hiç görmemiştir. RAG bu boşluğu doldurur: önce sorunuza en yakın 3-5 belge parçasını vektör veritabanından çekeriz, sonra LLM'e "sadece bu kaynaklara dayanarak yanıt ver" deriz. Bu bölümde n8n'in Vector Store, Embeddings, Document Loader ve Text Splitter node'larını kullanarak PDF'ten cevap üreten bir RAG asistanı kuracaksınız.
Konular
- Embeddings nedir, hangi modeli seçmeli
- Vektör veritabanı seçenekleri: Pinecone, Qdrant, Supabase pgvector
- Document Loader: PDF, web, Drive'dan içe aktarma
- Text Splitter ile chunking stratejileri
- Retrieve and Generate akışı (RAG)
- Kaynak gösterimi ve halüsinasyonu azaltma
RAG akışının iki ayağı: Ingestion ve Retrieval
Her RAG sisteminde iki ayrı workflow vardır. Ingestion (besleme): PDF/Drive/web sayfası → parçalara böl → her parça için embedding üret → vektör DB'ye yaz. Bu işlem yalnızca yeni belge geldiğinde çalışır. Retrieval (sorgu): kullanıcı sorusu gelir → soruyu embedding'e çevir → vektör DB'de en yakın N parçayı bul → LLM'e bağlam olarak ver → kaynaklı yanıt üret. n8n'de bu iki akış genelde iki ayrı workflow olarak kurulur; aynı vektör DB'yi paylaşırlar.
Embeddings: yazıyı sayıya çeviren motor
Embedding, bir metni 1536 (veya 3072) boyutlu bir sayı vektörüne dönüştürür. Anlamca yakın iki metnin vektörleri birbirine yakın olur — RAG'in tüm sihri budur. Pratik seçenekler: OpenAI text-embedding-3-small (ucuz, hızlı, çoğu işe yeter), text-embedding-3-large (daha doğru, daha pahalı), Cohere embed-multilingual-v3 (Türkçe için güçlü), Ollama nomic-embed-text (lokal, ücretsiz, gizlilik). Önemli: ingestion ile retrieval AYNI modeli kullanmak zorundadır; aksi halde vektörler karşılaştırılamaz.
Vektör veritabanı seçimi: Pinecone, Qdrant, Supabase pgvector
Pinecone: yönetilen SaaS, kurulum yok, milyonlarca vektörde bile düşük gecikme, ücretsiz katmanı küçük projeler için yeterli. Qdrant: açık kaynak, hem cloud hem self-host, metadata filtreleme çok güçlü ("sadece son 30 günün belgelerinde ara"). Supabase pgvector: zaten Postgres kullanıyorsanız ek araç gerekmez, küçük-orta projeler için ideal. Kural: prototipte Supabase pgvector, üretimde milyon+ vektör varsa Pinecone veya Qdrant.
Document Loader: PDF, web ve Drive'dan veri çekmek
n8n'in 'Default Data Loader' node'u dosya/text içeriğini RAG akışına sokar. Yaygın kaynaklar: PDF (Drive/S3/local), Google Docs (Docs node ile çek), web sayfası (HTTP Request + HTML Extract), Notion (Notion node ile sayfa içeriği). PDF için n8n PDF Loader'ı veya HTTP ile çekip Code node'da pdf-parse kütüphanesiyle metne çevirebilirsiniz. Önerilen sıralama: dosyayı önce text'e çevir → temizle (\n\n fazlaları, sayfa numaraları) → sonra splitter'a ver.
Text Splitter: chunking stratejileri
Bir PDF'i bütün olarak embedding'leyemezsiniz — model token limiti var ve aramada çok genel sonuç çıkar. Bu yüzden belgeyi 'chunk' denen parçalara böleriz. Strateji 1 — Recursive Character Splitter: paragraf → cümle → karakter hiyerarşisinde böler (en yaygın, varsayılan). Strateji 2 — Token Splitter: model token sayısına göre böler (token-bilinçli akışlarda). Pratik değerler: chunk size 800-1200 token, overlap 100-200 token (overlap olmadan iki chunk arasındaki bağlam kaybolur). Çok küçük chunk: bağlam yetersiz. Çok büyük chunk: arama isabetsiz. Belge tipine göre ayarlanır.
Retrieval akışı: soruya en yakın parçayı bulmak
Sorgu workflow'u şöyle çalışır: Webhook ile soru gelir → soruyu aynı embedding modeliyle vektöre çevir → Vector Store node'una 'Retrieve' modunda ver → top_k=5 (en yakın 5 chunk) çek → bu chunk'ları AI Agent'a 'context' olarak system prompt'a göm → agent yanıt üretir. n8n'de 'Vector Store Retrieve as Tool' moduyla agent doğrudan kendi araç gibi vektör DB'ye sorgu atabilir — bu daha güçlüdür çünkü agent gerektiğinde aramayı tekrarlar.
Kaynak gösterme ve halüsinasyonu azaltma
RAG'in en büyük zaafı: model retrieve edilen kaynaktan değil, kendi 'bildiklerinden' cevap vermeye eğilimlidir. Çözümler: (1) system prompt'a 'sadece <context> içindeki bilgilere dayanarak cevap ver, kaynakta yoksa "bilmiyorum" de' yaz. (2) Her chunk'ı 'metadata: { source: "sözleşme-v3.pdf", page: 12 }' ile yükle ve yanıtta kaynakları zorla yazdır. (3) Düşük benzerlik skoru (örn. < 0.7) gelirse 'ilgili bilgi bulamadım' fallback'ine düş. (4) Structured Output ile { answer, sources[], confidence } şemasına bağla — model 'kaynak yok' diyemediği zaman alanı boş bırakamaz.
Maliyet ve hız: pratik ipuçları
1000 sayfalık bir kurumsal arşivi text-embedding-3-small ile beslemek ~$1-2'dir, retrieval başına ~$0.0001. En büyük gizli maliyet LLM'in yanıt üretimidir — top_k çok büyük olursa prompt'a 20-30k token gönderirsiniz. Pratik kural: top_k=5, chunk_size=1000 token başlangıç değeri olarak güvenlidir. Hız için: embedding'leri batch halinde (Split In Batches → 100 chunk birden) gönderin. Aynı belge yeniden geldiğinde tekrar yüklememek için chunk'ın hash'ini metadata'ya yazıp ingestion öncesi kontrol edin.
Bu bölümün workflow'u (n8n editör görünümü)