RAG Mimari Diyagramı: Bir Retrieval-Augmented Generation Uygulamasının Parçaları Nasıl Birleşir

Çoğu RAG mimari diyagramında üç kutu vardır: bir kullanıcı, bir vektör veritabanı ve bir LLM. Bu resim, fikri bir toplantıda anlatmaya yeter. Sistemi işletecek kimseye yardım etmez; çünkü yanıt kalitesini ve güvenliği belirleyen kararlar onda yoktur: belgeler nasıl parçalanıyor, hangi embedding modeli kullanılıyor, hangi parçayı kim görebiliyor, sonuçlar nasıl sıralanıyor ve yanıtların iyi olduğunu kim nasıl biliyor?

Bu rehber, getirmeyle zenginleştirilmiş üretim (retrieval-augmented generation) yapan bir uygulamanın tam resmini, ortak modeller ve depolar etrafında iki yol olarak çiziyor; ardından neyin etiketleneceğini ve en sık yapılan hataları ele alıyor.

Tek değil, iki yol

Terim, bir dil modelini Wikipedia'nın yoğun bir vektör dizinini üretim sırasında tarayan bir getiriciyle birleştiren Lewis ve arkadaşlarından (2020) gelir. Production'daki RAG uygulamalarının çoğu fikri korur ama parçaları birlikte eğitmez: ilgili pasajları getir, prompta koy ve modelden onlara dayanarak yanıt vermesini iste.

Bu da her RAG uygulamasına iki yol verir:

• Veri alımı (ingestion) arka planda sürekli çalışır. Belgeleri parçalara, vektörlere ve meta veriye dönüştürür.
• Sorgu her soru için bir kez çalışır. Bir soruyu kaynaklı bir yanıta dönüştürür.

İki yol ortak parçalarda buluşur: iki yolda da aynı sürümde olması gereken embedding modeli, vektör dizini ve meta veri deposu. Yalnızca sorgu yolunu gösteren bir diyagram, sistemin yarısını ve hataların çoğunu gizler.

Veri alımı yolu

1. Kaynaklar ve değişiklik algılama. Bağlayıcılar, webhook'lar ya da bir tarayıcı yeni, değişen ve silinen belgeleri fark eder ve kuyruğa iş koyar. Silmeler ve izin değişiklikleri de birer iştir.
2. Ayrıştırma. Metni yapıyı koruyarak çıkarın: başlıklar, listeler, tablolar ve başlık, URL, sahip, son güncelleme ve erişim kontrol listesi gibi meta veriler.
3. Parçalama. Önce belgenin yapısına, sonra boyuta göre bölün. Parça boyutu ve örtüşme, evrensel sayılar değil, kendi sorularınıza göre ayarladığınız parametrelerdir. Bir paragrafın tek başına anlamlı kalması için her parçada başlık yolunu tutun.
4. Embedding. Tek bir embedding modelini çağırın ve sürümünü sabitleyin. Model adını ve sürümünü her vektörle birlikte saklayın. Farklı modellerden gelen vektörler karşılaştırılamaz; modeli değiştirmek, tüm külliyatı yeniden embedding'den geçirmek demektir.
5. İndeksleme. Her parçayı vektörü, belge kimliği, parça numarası, sürümü ve erişim etiketleriyle upsert edin. Hibrit arama planlıyorsanız vektör dizininin yanında bir anahtar kelime dizini de tutun.
6. Yenileme ve silme. Upsert'leri idempotent yapın, kaldırılan belgelerin parçalarını silin ve güncelliği takip edin: kaynaktaki bir değişikliğin dizine ulaşması ne kadar sürüyor?

Sorgu yolu

1. Kullanıcıyı tanımlayın. Getirme başlamadan önce kullanıcının gruplarını çözümleyin.
2. Soruyu yeniden yazın (isteğe bağlı). "Peki yükleniciler için?" gibi bir devam sorusunun, konuşmayla birlikte bağımsız bir sorguya dönüşmesi gerekir.
3. Getirin. Vektör araması benzer anlamdaki pasajları bulur; anahtar kelime araması hata kodları ve ürün adları gibi birebir terimleri. Hibrit arama ikisini de çalıştırır ve listeleri birleştirir; bunu çoğu zaman her belgeyi listeler boyunca toplanan 1/(k + sıra) değeriyle puanlayan reciprocal rank fusion ile yapar. Orijinal RRF makalesi k değerini 60'ta sabitlemiştir.
4. İzne göre sorgunun içinde filtreleyin. Kullanıcının gruplarını erişim etiketleri üzerinde bir filtre olarak geçin; böylece kullanıcının göremeyeceği parçalar prompta hiç ulaşmaz. Deponuzun filtreleri nasıl uyguladığını kontrol edin. pgvector'ün dokümantasyonu, yaklaşık indekslerde filtrenin indeks taramasından sonra çalıştığını belirtir: HNSW'nin varsayılan ef_search değeri 40 iken satırların %10'una uyan bir filtre ortalama yaklaşık 4 satır döndürür. Yinelemeli taramalar, kısmi indeksler ya da bölümleme bunu çözer.
5. Yeniden sıralayın. Bol getirin, örneğin 50 aday, ve bir yeniden sıralama modelinin onları soruya göre puanlamasına izin verin. En iyi birkaçını tutun, örneğin 8'ini.
6. Promptu oluşturun. Talimatlar, kimlikleri ve başlıklarıyla seçilen parçalar ve soru; hepsi bir token bütçesi içinde. Parça kimliğiyle kaynak gösterilmesini isteyin.
7. Üretin ve kaynak gösterin. LLM'i çağırın, yanıtı akış olarak iletin ve parça kimliklerini kullanıcının kontrol edebileceği linklere çevirin.

İki yolun çevresinde

• Getirilen metne güvenilmeyen girdi gibi davranın. Bir belge, modele yönelik talimatlar içerebilir. OWASP bunu dolaylı prompt enjeksiyonu olarak listeler. Modelin erişebildiği araçları ve verileri kullanıcının kendi erişimi kadar dar tutun.
• Her isteği izleyin. Yeniden yazılan sorguyu, getirilen ve yeniden sıralanan parça kimliklerini puanlarıyla, prompt sürümünü, model sürümlerini ve her adımın gecikmesini loglayın.
• Sabit bir soru setiyle değerlendirin. Parçalama, modeller, getirme ya da promptta yapılan her değişiklikte çalıştırın. RAGAS makalesi üç faydalı boyut tanımlar: getirilen bağlama sadakat, yanıtın alakası ve bağlamın alakası. Beklenen kaynağın ilk sonuçlarda çıkıp çıkmadığını da kontrol edin.
• Önbelleği dikkatle kullanın. Sorgu embedding'lerini önbelleğe almak genellikle güvenlidir. Yanıtları önbelleğe almak ise yalnızca izin seti başına güvenlidir.

Diyagram

Nasıl okunur:

• Solda, veri alımı. Kaynaktaki değişiklikler kuyrukta işlere dönüşür. Veri alımı worker'ı her belgeyi ayrıştırıp parçalar, embedding modelini çağırır, parçaları ve vektörleri erişim etiketleriyle vektör dizinine upsert eder ve belge meta verisini Postgres'e yazar.
• Ortada, ortak modeller ve depolar. Sürümü sabitlenmiş aynı embedding modeli iki yola da hizmet eder. LLM de buradadır ve yalnızca sorgu yolu tarafından çağrılır.
• Sağda, sorgu. RAG API'si kullanıcının gruplarını bulur, soruyu embedding'e çevirir, izin filtresiyle hibrit arama yapar, 50 adayı yeniden sıralayıcıya gönderir ve en iyi 8 parçayla LLM'i çağırır.
• Sol altta. Adım başına örnek bir gecikme bütçesi; böylece yavaş bir yanıt, bütçesini aşan adıma kadar izlenebilir.

Neler etiketlenmeli

• Her model düğümünde model sürümleri, embedding modeli dahil.
• Parçalama parametreleri, veri alımı worker'ında ya da bir notta.
• İzinlerin nerede uygulandığı, bir dipnotta değil, getirme kenarının üzerinde.
• Adımlar arasında kaç sonucun aktığı: 50 getirilen, 8 prompta giren.
• Güncellik ve gecikme hedefleri: kaynaktaki bir değişiklik ne kadar sürede aranabilir hâle gelir ve sorgu adımı başına bütçe ne kadardır.

Sık yapılan hatalar

• "AI" adlı tek bir kutu. Getirme, yeniden sıralama ve üretim farklı şekillerde bozulur ve ayrı kutulara ihtiyaç duyar.
• Veri alımı yolu yok. Bayat ya da eksik yanıtlar çoğu zaman orada başlar.
• İzin yok. Dizin farklı kitlelere yönelik belgeler içeriyorsa, erişim etiketleri olmayan bir diyagram bir veri sızıntısını anlatır.
• Değerlendirme yok. Bir soru seti olmadan prompt ya da parça boyutunda yapılan her değişiklik bir tahmindir.
• Karışık embedding sürümleri. Külliyatın yarısını yeni bir modelle yeniden embedding'den geçirmek, aramayı sessizce bozar.

RAG ne zaman doğru yanıt değildir

• Yanıt yapılandırılmış verideyse. Tablo satırlarını embedding'e çevirmek yerine veritabanını ya da bir API'yi sorgulayın.
• Görev bütün bir belge gerektiriyorsa. Tek bir sözleşmeyi özetlemek, sığıyorsa sözleşmenin tamamı promptta olduğunda daha iyi sonuç verir.
• Külliyat çok küçükse. Birkaç sayfa doğrudan prompta girebilir.
• İhtiyacınız daha fazla bilgi değil, farklı bir davranışsa. Bu bir prompt ya da fine-tuning sorunudur.

Kuyruklarla olay güdümlü veri alımı için olay güdümlü mimari diyagramı rehberine bakın.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Temel paketinden iki Çerçeve ekleyin: solda "Ingestion path", sağda "Query path".
3. Veri alımı çerçevesine kaynak belgeler için Veri paketinden bir Nesne deposu, veri alımı işleri için Veri paketinden bir Kuyruk ve veri alımı worker'ı için C4 Modeli paketinden bir Konteyner ekleyin.
4. Ortaya embedding modeli için ML paketinden bir Model, ML paketinden bir Vektör dizini, meta veri ve izinler için Veri paketinden bir Postgres ve LLM için ikinci bir Model ekleyin.
5. Sorgu çerçevesine kullanıcı için C4 Modeli paketinden bir Kişi, RAG API'si için bir Konteyner ve yeniden sıralayıcı için ML paketinden bir Model ekleyin.
6. Her kenarı, "top 50" ve "top 8" dahil, üzerinden akan şeyle etiketleyin ve gecikme bütçesini Temel paketinden bir Markdown bloğuna koyun.

Örnek 13 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor. Bir AI ajanıyla çalışıyorsanız, iki yolun tarifinden yola çıkarak ilk sürümü MCP üzerinden sizin için çizebilir; AI ajanlarıyla mimari diyagram nasıl oluşturulur yazısına bakın. Genel yöntem için yazılım mimarisi diyagramı nasıl çizilir yazısına göz atın.

SSS

RAG için ayrı bir vektör veritabanına ihtiyacım var mı? Hayır. Zaten çalıştırdığınız bir veritabanındaki vektör eklentisi, örneğin PostgreSQL'de pgvector, ya da vektör desteği olan bir arama motoru birçok uygulama için yeterlidir. Külliyatın boyutuna, filtreleme ihtiyacınıza ve ekibinizin iyi işletebildiği şeylere göre seçin.

Hangi parça boyutunu kullanmalıyım? Evrensel bir sayı yok. Başlıklara ve paragraflara göre bölün, ardından birkaç boyutu ve örtüşmeyi kendi soru setinizde karşılaştırın.

İzin kontrolleri nerede yapılmalı? Veri alımında, her belgenin erişim listesini parçalarına kopyalayarak; getirmede de bu listeye göre filtreleyerek. İçeriği gizlemek için asla prompta güvenmeyin.

Bir RAG uygulamasını nasıl değerlendiririm? Beklenen kaynaklarıyla birlikte gerçek sorulardan oluşan sabit bir set tutun. Getirmenin bu kaynakları bulup bulmadığını ve yanıtların getirilen bağlama sadık ve soruyla alakalı olup olmadığını ölçün.

LLM, RAG yerine araç mı çağırmalı? Canlı ya da yapılandırılmış veri için evet: asıl kayıt sistemini sorgulayan bir araç, kopyalardan oluşan bir dizinden iyidir. Birçok uygulama ikisini birden kullanır.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.