n8n ile RAG: Kendi Verinizle Kurumsal AI Chatbot
Kendi verinizle AI n8n RAG chatbot, şirketinizin belgelerini ve veri tabanlarını vektör deposuna yükleyerek LLM'in yalnızca kendi verilerinizden yanıt üretmesini sağlar. Böylece hallüsinasyon riski azalır, yanıtlar denetlenebilir hale gelir ve kurumsal gizlilik korunur.
RAG Nedir ve Neden n8n?
RAG (Retrieval-Augmented Generation), bir LLM'e soru sorulduğunda önce vektör deposundan ilgili metin parçacıklarını bulup bunları prompt'a ekleyen bir mimaridir. Model yalnızca bu bağlam içinden yanıt üretir; böylece güncel olmayan veya uydurulmuş bilgi riski ortadan kalkar.
Geleneksel LLM entegrasyonlarında model, yalnızca eğitim verisine dayanır. Şirket içi politika belgeleri, ürün kılavuzları, sözleşme arşivleri veya CRM notları bu eğitim setinin dışındadır. RAG bu boşluğu kapatır: her kullanıcı sorusu önce bir embedding modeli aracılığıyla vektöre dönüştürülür, ardından vektör deposunda anlam benzerliğine göre en uygun belgeler aranır ve bulunan parçacıklar LLM prompt'una eklenerek model bu bağlam içinden yanıt verir.
n8n bu pipeline'ı görsel bir iş akışı tuvalinde kurgulamamızı sağlar. n8n'in kurumsal otomasyon yetenekleri sayesinde belge yükleme (ingest), embedding üretimi, vektör deposuna yazma ve son kullanıcı sorgu akışı — hepsi tek bir workflow içinde birleştirilebilir. IT ekipleri Python scripti veya FastAPI sunucusu kurmak zorunda kalmadan, operasyon ve iş birimlerinin de anlayabileceği görsel bir pipeline elde eder.
n8n'in bu alanda öne çıkardığı başka bir avantaj da self-hosting seçeneğidir. Veri egemenliği gerektiren sektörlerde (bankacılık, sağlık, kamu) n8n ve vektör deposu şirketin kendi sunucularında çalıştırılabilir; hiçbir kurumsal veri dışarıya akmaz.
RAG Mimarisi: Embedding, Vector Store, Retrieval
Bir RAG pipeline'ı üç temel adımdan oluşur: belgeleri parçalara bölüp vektöre dönüştürme (ingest & embed), bu vektörleri bir vector store'a yazma ve kullanıcı sorusunu da vektöre çevirerek en yakın parçacıkları geri getirme (retrieval).
n8n içinde bu adımların her biri özel node'larla karşılanır. Belge yükleme için HTTP Request veya Google Drive node'u; parçalama için Text Splitter node'u; vektöre dönüştürme için Embeddings node'u (OpenAI, Cohere veya yerel model); vektör deposuna yazma için ilgili Vector Store Insert node'u kullanılır.
- Belge toplama: PDF, DOCX, web sayfası veya API yanıtı n8n workflow'una alınır.
- Parçalama (chunking): Büyük belgeler anlam bütünlüğü korunarak 500-1000 token'lık parçalara bölünür.
- Embedding üretimi: Her parça, seçilen embedding modeli aracılığıyla yüksek boyutlu bir vektöre dönüştürülür.
- Vector Store'a yazma: Vektörler ve orijinal metin meta verisiyle birlikte seçilen vektör deposuna kaydedilir.
- Kullanıcı sorusu embedding'i: Gelen kullanıcı sorusu aynı embedding modelinden geçirilir.
- Similarity search: Vektör deposu, kullanıcı sorusuna en yakın N parçacığı (top-k) döner.
- Prompt oluşturma: Bulunan parçacıklar sistem prompt'una eklenerek LLM'e gönderilir.
- Yanıt üretimi: LLM yalnızca sağlanan bağlam içinden yanıt oluşturur ve kullanıcıya iletilir.
Bu pipeline'ı iki ayrı workflow olarak tasarlamak iyi bir pratiktir: biri ingest (belge yükleme) akışı, diğeri query (sorgulama) akışı. İngest akışı yeni belgeler sisteme girdiğinde tetiklenir; query akışı ise webhook veya chat arayüzü üzerinden anlık sorguları işler.
Vector Store Seçimi: Pinecone, Qdrant, Weaviate, Supabase pgvector, Milvus
n8n, beş farklı vektör deposunu yerel node'larla destekler. Seçim; yönetilen hizmet mi yoksa self-hosted mi olduğuna, veri egemenliği gereksinimlerine, ölçek beklentisine ve ekip yetkinliğine göre yapılmalıdır.
Her vektör deposunun farklı güçlü yönleri vardır. Aşağıdaki tablo kurumsal seçim kriterlerini özetlemektedir:
| Vector Store | Yönetim Modeli | Self-Host | n8n Node | Öne Çıkan Özellik | Uygun Senaryo |
|---|---|---|---|---|---|
| Pinecone | Tam yönetilen (SaaS) | Hayır | Evet | Sıfır altyapı yükü, otomatik ölçekleme | Hızlı prototip, küçük-orta ölçek |
| Qdrant | Yönetilen veya self-host | Evet | Evet | Yüksek performans, filtreleme zenginliği | Kurumsal self-hosting, KVKK uyumu |
| Weaviate | Yönetilen veya self-host | Evet | Evet | Hibrit arama (vektör + anahtar kelime) | Çok modlu içerik, semantik arama |
| Supabase pgvector | Yönetilen veya self-host | Evet | Evet | PostgreSQL üzerinde vektör; mevcut DB ile birleşim | Mevcut Postgres altyapısını genişletme |
| Milvus | Yönetilen veya self-host | Evet | Evet | Milyar ölçek vektör, Kubernetes native | Büyük kurumsal ölçek, yüksek hacimli üretim |
Kurumsal dağıtımda en sık karşılaşılan tercih Qdrant veya Weaviate'tir; her ikisi de Docker veya Kubernetes üzerinde self-hosted çalışır ve n8n workflow'u ile doğrudan entegre olur. Mevcut PostgreSQL altyapısı olan organizasyonlar için Supabase pgvector, ek bir servis kurmadan vektör yeteneği kazanmanın en pratik yoludur.
Adım Adım: Belgeden Chatbot'a (n8n Workflow)
n8n'de eksiksiz bir RAG chatbot için iki ayrı workflow kurulur: belgeleri vector store'a yükleyen ingest akışı ve kullanıcı sorularını karşılayan query akışı. Her iki akış da görsel olarak bağlanır; kod yazımına gerek yoktur.
n8n AI Agent kurulum rehberimizde temel LLM entegrasyonu anlatılmaktadır. RAG için bu temele ek olarak vector store node'larını ve embedding node'larını eklemeniz yeterlidir.
İngest Workflow
Ingest workflow'u şu node zinciriyle kurulur: Trigger (Manuel veya Schedule) → Belge Kaynağı (Google Drive, S3, HTTP) → Text Splitter (chunk size: 800 token, overlap: 100) → Embeddings Node (örn. OpenAI text-embedding-3-small) → Vector Store Insert (Qdrant / Weaviate / pgvector). Her belge parçacığı, orijinal dosya adı, sayfa numarası ve tarih gibi meta verilerle birlikte kaydedilir; bu meta veriler daha sonra yanıtların kaynaklarını göstermekte kullanılır.
Query Workflow
Query workflow'u şu zinciri izler: Chat Trigger (Webhook veya n8n Chat node) → Embeddings Node (kullanıcı sorusu için) → Vector Store Retrieval (top-k: 4-6 parçacık) → LLM Chain (sistem prompt'u + bağlam + kullanıcı sorusu) → Yanıt Çıktısı. LLM Chain node'unda sistem prompt'u, modele yalnızca sağlanan bağlam içinden yanıt vermesini ve bilinmiyorsa açıkça belirtmesini söylemelidir.
Sohbet geçmişini korumak için Memory node'u zincire eklenir. Bu sayede chatbot, önceki mesajları hatırlayarak bağlamlı yanıtlar üretir; müşteri destek ve iç yardım masası senaryolarında kritik öneme sahiptir.
LLM ve Prompt Entegrasyonu
n8n'in LLM Chain ve AI Agent node'ları OpenAI, Anthropic, Azure OpenAI ve Ollama gibi yerel modelleri destekler. Prompt tasarımı, RAG'ın doğruluğunu doğrudan etkiler; sistem prompt'u modeli sağlanan bağlamla sınırlamalı ve kaynakları belirtmesini talep etmelidir.
n8n'de LLM seçimi büyük esneklik sunar. GPT-4o veya Claude gibi bulut tabanlı modeller yanı sıra Ollama aracılığıyla yerel olarak çalıştırılan açık kaynaklı modeller (Llama 3, Mistral, Phi-3) de kullanılabilir. Yerel model tercihinde tüm LLM işlemleri şirket altyapısında gerçekleşir; API maliyeti sıfırlanır ve veri gizliliği tam anlamıyla sağlanır.
Etkili bir RAG sistem prompt'u şu unsurları içermelidir: (1) Modelin kimliğini ve görevini tanımlayan kısa bir rol tanımı, (2) Yalnızca sağlanan bağlamdan yanıt verme talimatı, (3) Bağlamda bulunmayan sorular için 'Bu konuda bilgim bulunmuyor, lütfen ilgili departmanla iletişime geçin' gibi açık bir geri çekilme ifadesi, (4) Gerekirse kaynağı belirtme talimatı (dosya adı, sayfa numarası).
| LLM Seçeneği | Erişim Modeli | Veri Gizliliği | Maliyet | Önerilen Kullanım |
|---|---|---|---|---|
| GPT-4o (OpenAI) | API (bulut) | Veri OpenAI'ye gider | Yüksek | Yüksek kalite üretim, genel amaç |
| Claude 3.5 Sonnet (Anthropic) | API (bulut) | Veri Anthropic'e gider | Orta-Yüksek | Uzun bağlam, güvenli yanıt |
| Azure OpenAI | API (Azure bulut) | Veri AB/TR bölgesinde kalabilir | Orta-Yüksek | Microsoft altyapısı kullanan kurumlar |
| Ollama (yerel model) | Self-hosted | Veri dışarı çıkmaz | Düşük (altyapı maliyeti) | Tam veri egemenliği gerektiren kurumlar |
Doğruluk ve Değerlendirme: AI Evaluations
n8n'in AI Evaluations özelliği, hazırlanan bir test veri kümesini otomatik olarak workflow'dan geçirir ve her yanıtı doğruluk, bağlılık ve ilgililik açısından puanlar. Bu sayede retrieval kalitesi sistematik biçimde izlenebilir.
Bir RAG chatbot'un canlıya alınmadan önce doğruluk testinden geçirilmesi zorunludur. n8n'in AI Evaluations node'u bu süreci otomatize eder: soru-cevap çiftlerinden oluşan bir test veri kümesi hazırlanır, her soru workflow'dan geçirilir ve üretilen yanıt beklenen yanıtla karşılaştırılarak bir puan atanır.
Değerlendirme metrikleri genellikle şu üç boyutu kapsar: retrieval doğruluğu (ilgili parçacığın gerçekten getirilip getirilmediği), yanıt bağlılığı (modelin yalnızca sağlanan bağlamı kullanıp kullanmadığı) ve yanıt alaka düzeyi (soruyu doğrudan yanıtlayıp yanıtlamadığı). Bu metriklerin hepsinin belirli bir eşiğin üzerinde olması, üretim ortamına geçiş kriteri olarak belirlenebilir.
Değerlendirme sonuçları n8n içinde bir veri tabanına yazılabilir veya Slack bildirimi olarak gönderilebilir. Düzenli aralıklarla çalışan bir Evaluations workflow'u, yeni belgeler eklendikçe veya embedding modeli güncellendiğinde regresyon tespiti sağlar. Kurumsal n8n kullanım senaryoları arasında bu tür otonom kalite döngüsü giderek yaygınlaşmaktadır.
Veri Gizliliği ve Kurumsal Dağıtım (KVKK Uyumu)
KVKK ve GDPR kapsamında kişisel veri içeren belgelerle çalışırken n8n'i self-hosted olarak, vektör deposuyla birlikte şirket altyapısında çalıştırmak veri egemenliğini garanti eder. Bulut LLM API'leri kullanılıyorsa veri işleme anlaşması (DPA) zorunludur.
n8n güvenlik ve kurumsal yönetişim rehberimizde ayrıntılı güvenlik konfigürasyonu anlatılmaktadır. RAG bağlamında dikkat edilmesi gereken başlıca noktalar şunlardır: vektör deposuna yazılan belge parçacıklarında kişisel veri maskesi uygulanması, embedding API çağrılarının TLS ile şifrelenmesi, n8n workflow erişiminin rol tabanlı yetkilendirmeyle kısıtlanması ve audit log'larının tutulması.
Sağlık, finans veya kamu sektörü gibi yüksek düzenleyici baskı altındaki organizasyonlar için önerilen mimari şu bileşenlerden oluşur: n8n self-hosted (Docker/Kubernetes), Qdrant veya Weaviate self-hosted, Ollama veya Azure OpenAI (AB bölgesi) ve PostgreSQL (metadata depolama). Bu yapıda hiçbir veri organizasyon dışına çıkmaz.
KVKK kapsamında dikkat edilmesi gereken bir diğer nokta, vektör deposundaki verilerin silinme hakkıdır. Bir kişinin verileri kaldırılmak istendiğinde yalnızca ilgili belge parçacıklarının vector store'dan temizlenmesi yetmez; aynı zamanda yeniden embedding çalıştırılmalıdır. Bu süreci otomatize eden bir 'veri silme workflow'u' kurumsal RAG sistemlerinin vazgeçilmez bir bileşenidir.
Sık Sorulan Sorular
RAG nedir ve normal LLM'den farkı nedir?
RAG (Retrieval-Augmented Generation), LLM'e soru sorulmadan önce ilgili belge parçacıklarını vektör deposundan getirip prompt'a ekleyen bir mimaridir. Normal LLM yalnızca eğitim verisinden yanıt üretirken RAG, modeli şirketin güncel ve özel verisiyle besler; hallüsinasyon ve güncel olmayan bilgi riskini azaltır.
n8n'de hangi vector store'u seçmeliyim?
Hızlı prototip için Pinecone (yönetilen), veri egemenliği için Qdrant veya Weaviate (self-hosted), mevcut PostgreSQL altyapısı varsa Supabase pgvector, büyük ölçekli üretim için Milvus önerilir. Seçim maliyet, ölçek ve KVKK gereksinimlerine göre yapılmalıdır.
n8n'de RAG kurmak için kod bilmek gerekiyor mu?
Hayır. n8n'in görsel workflow editörü sayesinde embedding, vector store yazma, similarity search ve LLM Chain adımlarının tamamı sürükle-bırak ile kurulabilir. Ancak özel belge ön işleme veya kimlik doğrulama gerektiren senaryolarda küçük JavaScript/Python kod parçacıkları yazılabilir.
Yerel (on-premise) LLM kullanabilir miyim?
Evet. n8n, Ollama entegrasyonu sayesinde Llama 3, Mistral veya Phi-3 gibi açık kaynaklı modelleri yerel olarak çalıştırmanıza olanak tanır. Bu durumda hem LLM hem de vector store şirket altyapısında konuşlanır; API maliyeti sıfırlanır ve tam veri egemenliği sağlanır.
RAG chatbot'un doğruluğu nasıl ölçülür?
n8n'in AI Evaluations node'u ile soru-cevap çiftlerinden oluşan bir test kümesi workflow'dan geçirilir; retrieval doğruluğu, yanıt bağlılığı ve alaka düzeyi puanlanır. Bu puanlar düzenli aralıklarla izlenerek yeni belgeler eklendiğinde regresyon erken tespit edilir.
KVKK kapsamında kurumsal veri güvenliği nasıl sağlanır?
n8n ve vector store'un self-hosted çalıştırılması, veri egemenliğini garanti eder. Kişisel veri içeren belgeler için maskele-sonra-embed yaklaşımı, rol tabanlı erişim kontrolü, TLS şifreleme ve audit log zorunludur. Bulut LLM kullanılıyorsa yazılı veri işleme anlaşması (DPA) imzalanmalıdır.
n8n RAG chatbot'un kurumsal maliyeti nedir?
Maliyet üç kalemden oluşur: n8n (self-hosted ücretsiz, cloud Enterprise lisanslı), embedding ve LLM API ücretleri (yerel model kullanılırsa sıfır), vector store (Qdrant/Weaviate self-hosted ücretsiz, Pinecone kullanım başı ücretli). Küçük-orta ölçek için aylık toplam maliyet çoğunlukla API ücretleri kadardır.
Sonuç
n8n ile RAG mimarisi, kurumsal organizasyonların kendi belgelerini ve verilerini kaynak alan, denetlenebilir ve gizlilik uyumlu AI chatbot'lar kurmasını mümkün kılmaktadır. Görsel workflow editörü sayesinde embedding'den vector store yönetimine, LLM entegrasyonundan otomatik kalite değerlendirmesine kadar tüm pipeline tek bir araçta tamamlanabilir.
Hangi vector store'u seçeceğinizi ve KVKK uyumlu mimariyi nasıl kurgulayacağınızı belirlemek için Sora AI ekibimizle ücretsiz bir keşif görüşmesi yapabilirsiniz. Sora Yazılım olarak n8n tabanlı kurumsal AI pipeline'larını tasarlama ve yönetme konusunda Türkiye'nin önde gelen teknoloji ortağıyız.