Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Ubuntu 24.04 LTS üzerinde n8n, Ollama ve Qdrant bileşenlerini tek bir RAG hattında birleştirirken ağ, kalıcı veri, embedding uyumu, GPU, güvenlik ve yedeklemeyi birlikte ele alan kapsamlı rehber.
Komutları canlı sistemde uygulamadan önce sürüm, yedek, firewall ve geri dönüş planını kendi altyapınızda doğrulayın.
RAG zincirinde n8n orkestrasyonu, Ollama model/embedding çalıştırmasını, Qdrant ise vektör arama katmanını üstlenir. En sık sorun servislerin çalışmaması değil; yanlış container adresi, uyumsuz embedding dimension, yetersiz VRAM/RAM ve public bırakılmış servis portlarıdır.
Sağlıklı bir RAG kurulumu sadece üç container’ı ayağa kaldırmak değildir. Dokümanın parçalanması, aynı embedding modelinin ingest ve sorguda kullanılması, Qdrant collection dimension’ının embedding çıktısıyla eşleşmesi, n8n’in container içinden Ollama/Qdrant servis adlarına erişmesi ve verinin kalıcı volume üzerinde tutulması gerekir.
Kurulumdan production’a; mimari, kapasite, Docker ağı, embedding, güvenlik, performans, backup ve teşhisi tek akışta ele alıyoruz.
RAG akışında kaynak PDF, web içeriği veya kurumsal doküman önce temizlenir ve parçalara ayrılır. Her parça embedding modelinden geçirilerek sayısal vektöre dönüştürülür; vektör ve ilgili metadata Qdrant collection içine yazılır. Kullanıcı soru sorduğunda aynı embedding ailesiyle sorgu vektörü üretilir, Qdrant en yakın parçaları döndürür ve n8n bu bağlamı Ollama’daki sohbet modeline aktarır.
Bu katmanları birbirinden ayırmak teşhisi kolaylaştırır. Ollama cevabı üretiyor diye retrieval doğru çalışıyor varsayılmaz; Qdrant sonuç döndürüyor diye de doğru parçaların geldiği garanti değildir. Production kontrolünde retrieval kalitesi, cevap doğruluğu, p95 gecikme ve kaynak tüketimi ayrı metrikler olarak izlenmelidir.
Ubuntu Server’ın taban gereksinimi düşük olsa da RAG iş yükü model ve veri boyutuyla büyür. Ollama için asıl belirleyici model ağırlıkları, context uzunluğu ve GPU offload oranıdır. Qdrant tarafında vektör sayısı, dimension, payload indexleri, quantization, replication ve storage seçimi RAM/disk ihtiyacını belirler.
Ollama güncel dokümantasyonunda context varsayılanlarının VRAM’e göre değiştiğini belirtir; context büyüdükçe bellek ihtiyacı da artar. Bu nedenle 'model açıldı' testi yerine gerçek prompt uzunluğu, eşzamanlı kullanıcı ve retrieval sonuç sayısıyla test yapılmalıdır. NVMe disk özellikle yüksek ingest, snapshot ve büyük collection senaryolarında belirgin avantaj sağlar.
Aynı Docker Compose ağı içindeki n8n container’ı için localhost n8n container’ının kendisidir. Ollama ve Qdrant ayrı servislerse n8n credential veya node ayarlarında genellikle Compose servis adları kullanılmalıdır; örneğin http://ollama:11434 ve http://qdrant:6333. Host tarayıcısından test ederken ise yayınlanan localhost portları kullanılabilir.
Production tasarımında Qdrant 6333/6334 ve Ollama 11434 portlarını doğrudan internete açmak yerine private container ağı veya private VLAN tercih edilir. Dış erişim gerekiyorsa reverse proxy, TLS, authentication, allow-list ve rate limit ayrı katmanlarda uygulanmalıdır.
Collection oluşturulurken vector dimension embedding modelinin gerçek çıktısıyla eşleşmelidir. Model değişirse mevcut collection otomatik olarak uyumlu hale gelmez; yeni dimension veya distance metriği gerekiyorsa yeni collection, yeniden embedding ve kontrollü migration planlanmalıdır.
Chunk boyutu tek başına 'ne kadar büyük o kadar iyi' değildir. Çok küçük parçalar bağlamı kaybedebilir, çok büyük parçalar ise retrieval hassasiyetini düşürüp LLM context maliyetini artırabilir. Doküman türüne göre başlık, paragraf, tablo ve metadata sınırlarını koruyan bir chunk stratejisi; ardından gerçek soru setiyle recall/precision değerlendirmesi daha güvenilirdir.
Ingest workflow ile chat/retrieval workflow’unu ayırmak işletimi kolaylaştırır. Ingest tarafı dosya alma, metin çıkarma, temizleme, chunk, embedding ve Qdrant upsert adımlarını yürütür. Sorgu tarafı ise kullanıcı girdisini embedding’e çevirir, Qdrant’tan ilgili parçaları çeker, prompt bağlamını oluşturur ve Ollama chat modelini çağırır.
Aynı workflow içinde her soruda dokümanları yeniden embed etmek ciddi kaynak israfıdır. Ayrıca hata durumlarında hangi katmanın bozulduğunu anlamayı zorlaştırır. Workflow execution logları, Qdrant query sonuçları ve Ollama süreleri aynı request kimliğiyle ilişkilendirilebilirse production teşhisi belirgin şekilde kolaylaşır.
Qdrant’ın self-hosted açık kaynak kurulumu varsayılan haliyle production güvenliği sağlamaz; API key, network binding ve TLS bilinçli biçimde yapılandırılmalıdır. Qdrant dokümantasyonu self-hosted instance’ların erişilebildiği takdirde authentication olmadan istek kabul edebileceğini özellikle vurgular.
n8n tarafında encryption key, kullanıcı kimlik doğrulaması, webhook URL’leri ve credential saklama stratejisi yedek planıyla birlikte ele alınmalıdır. .env dosyaları web root altında tutulmamalı; backup alınırken secret’ların ayrı korunması gerekir. Ollama API’si de yalnız ihtiyaç duyan servislerden erişilebilir tutulmalıdır.
Qdrant için yalnız container image yedeği almak veriyi korumaz; kalıcı storage ve mümkünse Qdrant snapshot mekanizması ayrı planlanmalıdır. n8n için workflow/credential verisinin bulunduğu kalıcı veritabanı ve encryption key birlikte korunmalıdır. Model dosyaları yeniden indirilebilir olsa da büyük model cache’leri için restore süresi kapasite planına dahil edilmelidir.
Güncellemede bütün stack’i aynı anda yükseltmek yerine image sürümleri kaydedilir, backup alınır, staging üzerinde workflow testleri çalıştırılır ve sonrasında kontrollü geçiş yapılır. Embedding modelini değiştirmek uygulama güncellemesi değil veri migration’ıdır; yeniden indeks maliyeti önceden ölçülmelidir.
Tek metrik tokens/s değildir. İlk yanıt süresi, toplam cevap süresi, Qdrant query p95, embedding süresi, retrieval isabeti, context token sayısı, GPU/CPU kullanımı ve hata oranı birlikte izlenmelidir. Aynı test soruları ve aynı collection snapshot kullanılmadan iki sunucuyu kıyaslamak sağlıklı değildir.
Modelin tamamı GPU’da kalabiliyorsa latency genellikle daha öngörülebilir olur; CPU offload başladığında context ve concurrency artışı beklenenden fazla gecikme üretebilir. Ollama tarafında gerçek offload ve context değerleri `ollama ps` ile doğrulanabilir.
Kurulumdan production’a; mimari, kapasite, Docker ağı, embedding, güvenlik, performans, backup ve teşhisi tek akışta ele alıyoruz.
| Bileşen | Görev | Ağ / port | Production notu |
|---|---|---|---|
| n8n | Workflow orkestrasyonu, ingest ve chat akışı | 5678 yalnız reverse proxy/private ağ | Encryption key, DB backup, TLS ve erişim kontrolü |
| Ollama | LLM ve embedding modellerini çalıştırır | 11434 private container ağı | Model/VRAM/context doğrulanmalı; public API bırakılmamalı |
| Qdrant | Vektör + payload saklama ve similarity search | 6333 HTTP, 6334 gRPC; public yerine private | API key, bind, TLS, snapshot ve monitoring |
| PostgreSQL | n8n kalıcı verisi için önerilen DB katmanı | 5432 sadece internal ağ | Düzenli backup, güçlü parola ve disk izleme |
| Reverse Proxy | HTTPS, domain ve dış trafik girişi | 80/443 public | TLS, rate limit, header ve timeout ayarları |
Bu sonuç tahmindir; production kararı gerçek ölçüm ve test ile verilmelidir.
Sağlıklı bir RAG kurulumu sadece üç container’ı ayağa kaldırmak değildir. Dokümanın parçalanması, aynı embedding modelinin ingest ve sorguda kullanılması, Qdrant collection dimension’ının embedding çıktısıyla eşleşmesi, n8n’in container içinden Ollama/Qdrant servis adlarına erişmesi ve verinin kalıcı volume üzerinde tutulması gerekir.
| Belirti / problem | Muhtemel katman | İlk doğrulama |
|---|---|---|
| n8n Ollama’ya bağlanamıyor | Container network / yanlış localhost | n8n container içinden `http://ollama:11434` erişimini doğrulayın. |
| Qdrant dimension error veriyor | Embedding modeli ile collection schema uyumsuz | Embedding çıktısının dimension değerini ve collection vector config’i karşılaştırın. |
| RAG cevap veriyor ama yanlış kaynak getiriyor | Chunking / embedding / retrieval ayarı | Aynı gerçek soru setinde top-k sonuçlarını elle inceleyin; chunk metadata ve embedding modelini kontrol edin. |
| GPU var fakat Ollama CPU kullanıyor | Driver/runtime veya model offload | `nvidia-smi` ve `ollama ps` ile GPU görünürlüğü ve PROCESSOR alanını doğrulayın. |
| Qdrant restart sonrası veri yok | Kalıcı volume yanlış veya yok | Container mount ve Qdrant storage yolunu kontrol edin; snapshot stratejisini test edin. |
| n8n güncelleme sonrası credential açılamıyor | Encryption key değişmiş olabilir | Eski encryption key ve DB backup eşleşmesini doğrulayın; rastgele yeni key ile devam etmeyin. |
Kurulumdan production’a; mimari, kapasite, Docker ağı, embedding, güvenlik, performans, backup ve teşhisi tek akışta ele alıyoruz.
24.04 LTS güncellemelerini, disk alanını, Docker Engine/Compose ve gerekiyorsa NVIDIA container runtime’ı kontrol edin.
n8n, Ollama, Qdrant ve DB servislerinin aynı Compose ağında birbirini servis adıyla görebildiğini doğrulayın.
Model adını, dimension’ı, distance metriğini ve chunk stratejisini dokümante edin.
Kaynak → temizleme → chunk → embedding → Qdrant upsert zincirini ayrı workflow olarak test edin.
Soru → embedding → Qdrant top-k → prompt context → Ollama chat zincirini gerçek sorularla ölçün.
Public portları azaltın, TLS/API key/secret yönetimini tamamlayın ve restore testi yapın.
p95 latency, retrieval kalitesi, CPU/RAM/VRAM, disk ve hata oranını eşzamanlı yük altında kaydedin.
Kurulumdan production’a; mimari, kapasite, Docker ağı, embedding, güvenlik, performans, backup ve teşhisi tek akışta ele alıyoruz.
Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
docker --version && docker compose versiongit clone https://github.com/n8n-io/self-hosted-ai-starter-kit.git
cd self-hosted-ai-starter-kit
cp .env.example .envdocker compose --profile cpu pull
docker compose --profile cpu up -dnvidia-smi
docker compose --profile gpu-nvidia pull
docker compose --profile gpu-nvidia up -ddocker compose ps
curl -fsS http://127.0.0.1:6333/
curl -fsS http://127.0.0.1:11434/api/tagsollama list
ollama psdocker compose logs --tail=150 n8n qdrant
docker compose logs --tail=150 ollama-cpu ollama-gpu 2>/dev/null || trueModel, veri boyutu, eşzamanlı kullanıcı, GPU tercihi ve hedef latency bilgilerini paylaşırsanız CPU/RAM/VRAM/NVMe ve servis ayrıştırma planını teknik olarak değerlendirebiliriz.
Kurulumdan production’a; mimari, kapasite, Docker ağı, embedding, güvenlik, performans, backup ve teşhisi tek akışta ele alıyoruz.
Kurulumdan production’a; mimari, kapasite, Docker ağı, embedding, güvenlik, performans, backup ve teşhisi tek akışta ele alıyoruz.
Sağlıklı bir RAG kurulumu sadece üç container’ı ayağa kaldırmak değildir. Dokümanın parçalanması, aynı embedding modelinin ingest ve sorguda kullanılması, Qdrant collection dimension’ının embedding çıktısıyla eşleşmesi, n8n’in container içinden Ollama/Qdrant servis adlarına erişmesi ve verinin kalıcı volume üzerinde tutulması gerekir.
Evet. Küçük ve orta ölçekli RAG sistemlerinde aynı sunucu pratik olabilir; ancak CPU/RAM/VRAM ve disk contention gerçek yükle ölçülmelidir. Büyümede Qdrant, model serving ve workflow katmanlarını ayırmak daha yönetilebilir olabilir.
Genellikle hayır. n8n aynı private ağdaysa Qdrant’ı private tutmak daha güvenlidir. Dış istemci gerekiyorsa API key, TLS, network restriction ve mümkünse reverse proxy/VPN uygulanmalıdır.
Dimension ve embedding uzayı değişebileceği için mevcut vektörlerin yeni modelle karıştırılması doğru değildir. Yeni collection ve yeniden embedding migration’ı daha güvenilir yaklaşımdır.
Qdrant ve n8n için şart değildir. Ollama modelinin boyutuna, hedef latency’ye ve concurrency’ye göre GPU önemli hız kazandırabilir. Küçük modeller CPU’da da çalışabilir ancak production hedefi benchmark ile belirlenmelidir.
Resmî starter kit hızlı öğrenme ve PoC amacıyla güçlü bir başlangıçtır; production’da HA, güvenlik, yedekleme, secret yönetimi, monitoring ve ölçekleme ayrıca tasarlanmalıdır.
Qdrant dokümantasyonu kalıcı storage için POSIX uyumlu block-level storage ister ve NFS/object storage yaklaşımını çalışma storage’ı olarak uygun görmez. Snapshot/backup hedefi ayrı değerlendirilebilir.
Context token sayısı büyüdükçe modelin çalışma belleği de artar. Ollama dokümantasyonu büyük context’in daha fazla bellek gerektirdiğini belirtir; gerçek kullanım `ollama ps` ile kontrol edilmelidir.
Önceden hazırlanmış gerçek soru-cevap setinde retrieval top-k sonuçlarını, kaynak doğruluğunu, cevap doğruluğunu ve latency’yi birlikte ölçün. Sadece modelin akıcı cevap vermesi RAG’in doğru çalıştığını göstermez.
Model, veri boyutu, eşzamanlı kullanıcı, GPU tercihi ve hedef latency bilgilerini paylaşırsanız CPU/RAM/VRAM/NVMe ve servis ayrıştırma planını teknik olarak değerlendirebiliriz.