LLM’ler aynı anda yalnızca sınırlı miktarda metni “görebilir” (bağlam kapasitesi). Bu, küçük görevlerde işe yarar ancak bilgi tabanı binlerce sayfaya yayıldığında yetersiz kalır. Bağlam kapasitesi yeterli olsa bile “samanlıkta iğne” sorunu nedeniyle performans düşebilir.
RAG (“erişim destekli üretim”), bir bilgi tabanını (belgeler, vikiler, politikalar, transkriptler vb.) tuttuğunuz, kullanıcı sorgusunda semantik arama yaparak embedding’ler aracılığıyla en alakalı bölümleri getirdiğiniz ve ardından bu parçaları soruyla birlikte LLM’ye ilettiğiniz çok yaygın bir yaklaşım hâline geldi. Bu, modelin bağlamını sınırlar ve doğru uygulandığında yanıt kalitesini artırıp halüsinasyonları azaltabilir.
pgai, güvenilir açık kaynaklı PostgreSQL veritabanı üzerinde “yapay zekâ destekli erişim” iş akışları oluşturmanıza yardımcı olan açık kaynaklı bir Postgres uzantısı ve tamamlayıcı araç setidir.
Temel fikir, veritabanını embedding’ler için “yalnızca depolama alanı” olarak görmek yerine standart RAG işlem hattının daha büyük bir bölümünü veritabanı katmanına taşımaktır (alma → parçalara ayırma → embedding oluşturma → embedding’leri eşitlenmiş tutma).
İlk izlenimimiz umut verici olduğu yönünde; ancak RAG işlem hattınız biraz bile karmaşıklaştığında, özellikle parçalara ayırma yaklaşımları bakımından, uygunluğunu yitiriyor. Yine de bu projeyi yakından takip edeceğiz.
RAG oluşturmanın birçok yolu var. Farklı RAG yaklaşımlarını daha ayrıntılı incelemek için Özelleştirilmiş RAG Çözümlerinden Pratik Örnekler başlıklı yazıyı okuyun. Kalite önem kazandıkça tasarım seçenekleri şaşırtıcı ölçüde çeşitlenir. Yaygın “varsayılan” yaklaşım genellikle şöyledir:
Bir grup belge alın.
Bunları parçalara ayırın. Bunu yapmanın birçok farklı yöntemi vardır (ör. paragraflar, semantik gruplamalar).
Her parçayı bir embedding’e dönüştürün.
Embedding’leri bir vektör veritabanında (Pinecone, Milvus vb.) veya pgvector kullanarak Postgres’te saklayın.
Sorgu sırasında en yakın parçaları arayın `ve bunları LLM’ye iletin (yine... bunu yapmanın da birçok yolu vardır).
Birçok teknoloji yığınında (1)–(3) arasındaki adımlar, uygulama kodunda veya bir veri işlem hattında, veritabanının dışında gerçekleşir. Veritabanı çoğunlukla şunlar için kullanılır:
embedding’leri saklama
embedding’lerde arama yapma
pgai, bu ayrımı belirsizleştirmeyi amaçlayan bir Postgres uzantısıdır (açık kaynaklıdır ve Timescale tarafından geliştirilmiştir).
pgai, embedding’leri uygulamanızın elle yönettiği öğeler olmaktan çıkarıp bir veritabanı özelliğine dönüştürür:
Hangi tablo veya belgeler için embedding oluşturulacağını tanımlarsınız.
Embedding modelini ve parçalara ayırma stratejisini belirtirsiniz.
Kaynak verileriniz değiştikçe embedding’leri güncel tutmak dâhil geri kalan her şeyi pgai yönetir.
Sunduğu avantajlar cazip:
Bakım gerektiren özel bağlayıcı kod miktarı azalır.
Temel kaynak belgeler değiştikçe embedding’leri “güncel” tutmak kolaylaşır.
Yeniden denemeleri, hız sınırlarını, başarısız işleri vb. Postgres/pgai yönetir.
Okuyucuya not: pgai, bir diğer çok popüler RAG Postgres uzantısı olan pgvector’ı içerir. pgvector, Postgres’e vektör depolama ve benzerlik araması ekler. pgai ise bunun üzerine kurularak parçalara ayırma, embedding oluşturma ve embedding’leri güncel tutma gibi RAG işlem hattı adımlarını otomatikleştirir.
1) Çalışır hâle getirmek kolay.
Her şey yolunda gittiğinde süreç oldukça basit:
Timescale Docker imajlarını (veritabanı + worker) indirin.
Embedding sağlayıcınızın API anahtarını girin.
Vektörleştiriciyi tanımlamak için az miktarda SQL çalıştırın (temelde: ne için embedding oluşturulacağı, içeriğin nasıl parçalara ayrılacağı ve hangi modelin kullanılacağı).
Ardından pgai, bir vektörleştirme worker’ının ayrı bir süreç olarak çalışmasını ve embedding’leri eşzamansız biçimde üretmesini sağlar (ör. her 5 dakikada bir veya istediğiniz sıklıkta).
2) Tüm işlem hattını veritabanının “yakınında” çalıştırmak güzel.
pgai, tablolardaki içeriği alabilir; ayrıca S3 gibi yerlerden belge yükleyip bunları ayrıştırabilir, parçalara ayırabilir ve embedding’lerini oluşturabilir. PDF, Markdown vb. farklı metin belgesi biçimlerini de işleyebilir.
1) Kontrolün büyük bölümünü kaybediyorsunuz (ve RAG bazen kontrol gerektirir).
Yanıt kalitesi açısından yüksek performanslı RAG sistemleri genellikle aşağıdakiler gibi özel işlem hatları gerektirir:
özel parçalara ayırma kuralları (başlıklara, sayfalara, konuşmacı sıralarına vb. göre)
meta verileri dikkate alan parçalara ayırma (bölüm başlıklarını, zaman damgalarını, yazarları ve belge türünü koruma)
her belge türü için farklı embedding stratejileri
pgai, yukarıdaki konularda daha az esneklik sunuyor.
Şu anda iki temel parçalara ayırma stratejisi vardır: karakter tabanlı metin ayırıcı ve özyinelemeli karakter tabanlı metin ayırıcı. Ayrıca parçalara ayırmama seçeneği de bulunur. Bu, bazı kullanım alanları için yeterli olabilir ancak üretimdeki birçok RAG sistemi daha fazla özelleştirme gerektirir.
Timescale’in Chonkie gibi kütüphanelerde gördüğümüz daha gelişmiş parçalara ayırma stratejilerinden bazılarını bünyesine katması ve benzer şekilde Anthropic’in bağlamsal erişimi gibi ileri tasarımları desteklemesi harika olurdu.
2) Çok modlu değil, metin öncelikli.
Birçok ilginç RAG problemi artık yalnızca metinden ibaret değil:
diyagram içeren PDF’ler
ekran görüntüleri / görseller
ses kayıtları
video klipler
Bu kaynaklardan “metin çıkarabilseniz” bile bu, gerçek anlamda çok modlu bir embedding işlem hattıyla aynı şey değildir.
pgai gelecekte çok modlu modelleri uçtan uca desteklerse (S3’te saklanan büyük görselleri, sesleri ve videoları güçlü bir eşitleme sistemiyle yükleme → parçalara ayırma → embedding oluşturma), bu etkileyici olur. Ancak bugün yalnızca metin embedding’lerine yönelik bir iş akışıdır.
3) Yalnızca embedding’lere ihtiyacınız varsa pgai’ye ihtiyacınız olmayabilir.
Veri alma işlem hattınız zaten özelse (veya özel olması gerekiyorsa) “metin parçaları için embedding oluşturmak” RAG’nin en zor kısmı değildir. Böyle bir durumda pgai, sorunun en kolay kısmını çözer.
Ayrıca bilgi tabanınız seyrek güncelleniyorsa otomatik embedding eşitlemesinin sağladığı değer de azalır.
pgai’yi kullanmanın özellikle iyi bir yolu, veritabanlarınız üzerinde metinden SQL’e bir arayüz devreye almak olabilir. Bu, pgai’nin sunduğu semantic_catalog modülüyle oldukça kolay biçimde yapılabilir. Kurulumu şu şekilde yapmanız yeterlidir:
Bash
Ardından pgai semantic-catalog create ile semantik kataloğun veri sözlüklerinizi taramasını sağlayın. Bu işlem, veri deponuzdan aşağıdakine benzer bir bağlam üretir:
Plain Text
Bu bağlam artık pgai tarafından çeşitli şekillerde kullanılabilir:
Semantik arama yoluyla:
Bu sorgu, doğal dildeki sorgunuzla alakalı olabilecek tabloları, işlevleri ve diğer nesneleri döndürür:
Bash
Ham bağlamı alma:
Bu işlem, doğal dildeki sorgunuzla ilgili ham YAML bağlamını oluşturur:
Bash
SQL üretme:
Dilerseniz sorgunuzu yanıtlamak için gereken ham SQL’i doğrudan oluşturabilirsiniz. Önceki adımdaki bağlam bir LLM’ye gönderilir ve yanıt üretilir:
Bash
Nispeten basit bir RAG sistemi oluşturuyorsanız ve aşağıdakileri istiyorsanız pgai’yi denemeye değer:
ana kayıt sisteminiz olarak Postgres,
minimum bağlayıcı kod,
otomatik olarak eşitlenmiş kalan embedding’ler,
veritabanlarınıza metinden SQL’e çözümünü hızlıca uygulamak,
yeni RAG araçlarını ve Postgres uzantılarını denemek.
RAG işlem hattınız aşağıdakilerden herhangi birini gerektiriyorsa pgai için beklemek daha doğru olabilir:
yoğun şekilde özelleştirilmiş veri alma veya parçalara ayırma mantığı
farklı ayrıştırma gereksinimlerine sahip çok sayıda belge türü
çok modlu embedding’ler
Son olarak pgvector’ın yaygın biçimde benimsendiği açık olsa da pgai’nin aynı düzeyde ilgi ve dolayısıyla destek görüp görmeyeceği belirsizdir (yaklaşık 18 aydır mevcut olduğu da unutulmamalı).
pgai, rutin operasyonel işlerin daha fazlasını veritabanlarına yaptırarak uygulama kodunu basitleştiren ilginç bir RAG yaklaşımıdır.
Şu anda:
basit RAG kurulumlarında kullanışlı ve gerçekten keyifli
daha özel işlem hatları için yeterince esnek değil (özellikle çok modlu olanlarda)
Umut veriyor ve nasıl gelişeceğini görmek için kesinlikle takip edilmeye değer.