RAG neden bu kadar çok RAM'e ihtiyaç duyar?

Hızlı vektör araması indeksin bellekte yerleşik olmasını ister. Her belge parçası bir embedding'e dönüşür — birkaç yüz ile birkaç bin float'lık bir vektör — ve milyonlarca parçada bu birikir. İndeksi diske itin, arama gecikmesi fırlar; kendi kendine barındırmanızın tüm nedenini (hız + kontrol) korumak, onu RAM'de tutmak demektir.

Belirli bir korpus için ne kadar RAM?

Kaba his: birkaç yüz bin embedding 2–4 GB'a gayet iyi oturur. Düşük milyonlar, etrafındaki uygulama ve işletim sistemiyle, 16–32 GB'dasınız. Onlarca milyon ya da yüksek boyutlu vektörler ve 48–80 GB'a girersiniz, ondan sonra sunucular arasında bölersiniz. Boyut ve indeks türü bunu çok oynatır, bu yüzden kendinizinkini ölçün.

pgvector mı, Qdrant gibi özel bir motor mu?

Zaten Postgres çalıştırıyorsanız, pgvector en az çaba yoludur — bir uzantı, bir veritabanı. Ağır filtrelemeli milyonlarca vektör için, amaca özel bir motor ayrı servisini hak eder. Zaten işlettiğinizle başlayın; yalnızca arama yavaşladığında taşıyın.

Yönetilen bir vektör servisi yerine neden kendiniz barındırasınız?

İki gerçek neden: embedding'leriniz genellikle özel veri kodlar (belgeler, notlar, müşteri içeriği) ve kendi kendine barındırmak bunu kontrol ettiğiniz bir sunucuda tutar. Ve düz maliyettir — yönetilen servisler vektör ve sorguya göre sayaç işletir, bir VPS ise sorgu başına fatura olmayan tek bir aylık rakamdır.

Ölçekli kendi kendine barındırılan RAG: bir vektör indeksi gerçekte ne kadar RAM yer

Her RAG öğreticisi birkaç yüz belgeli bir dizüstünde çalışır ve zahmetsiz hissettirir. Sonra onu gerçek bir korpusa yöneltirsiniz — bir şirketin belgeleri, yıllarca biriken talepler, bir bilgi tabanı — ve birden bellek tüm konu oluverir.

RAG CPU ile ölçeklenmez. RAM ile ölçeklenir.

İndeks neden bellek ister

Getirme, her metin parçasını bir embedding'e dönüştürerek çalışır — bir vektör, birkaç yüz ile birkaç bin sayı uzunluğunda. Arama, sorgu vektörünüzü hepsiyle karşılaştırmak demektir, hızlıca. "Hızlı" işlevsel sözcüktür: düşük gecikme için indeksin RAM'de yaşaması gerekir. Diskte çalışır, ama her sorgu bir ceza öder ve düşük gecikmeli getirme en baştan kendi kendine barındırmanın amacıydı.

Yani bellek faturası iki şeyle ölçeklenir: kaç parçanız olduğu ve her vektörün ne kadar geniş olduğu.

Gerçek rakamlar, kabaca

Kendinizinkini ölçün — boyut ve indeks türü bunu çok oynatır — ama başlangıç hissi olarak:

Birkaç yüz bin embedding — 2–4 GB'a rahat. Kişisel bir bilgi tabanı, tek bir ürünün belgeleri.
Düşük milyonlar — uygulama, model istemcisi ve işletim sistemiyle birlikte, 16–32 GB planlayın. Bu, ciddi bir şirket bilgi tabanı ya da çok kaynaklı bir RAG.
Onlarca milyon ya da yüksek boyutlu vektörler — şimdi 48–80 GB'dasınız, ondan sonra birkaç kutu arasında. Büyük belge yığınları, çok kiracılı getirme ya da aynı anda birkaç indeksi sıcak tutuyorsunuz.

Büyük bir indeks de tutan bir çoklu ajan sistemi her iki maliyeti de aynı kutuya yığar — 32 GB'lık bir plan işte böyle sessizce 64 GB'lık birine dönüşür.

Motor seçimi, kısaca

Zaten Postgres çalıştırıyorsanız, pgvector en az çaba seçeneğidir — dadılık edilecek yeni bir servis değil, bir uzantıdır. Milyonlarca vektörünüz olduğunda ve hızlı filtreli arama istediğinizde, Qdrant ya da Weaviate gibi özel bir motor ayrı süreci hak eder. İlk gün onu aşırı mühendislemeyin; zaten işlettiğinizi çalıştırın ve arama gerçekten yavaşladığında ayırın.

Neden kendi kendine barındırma zahmeti

İnsanların bunu gerçekten yapma nedeni iki tanedir ve hiçbiri "birkaç dolar kurtarmak" değildir:

Gizlilik. Embedding'ler soyut değildir — geldikleri metni kodlarlar. Belgeleriniz, müşterilerinizin içeriği, dahili notlarınız, vektörlere dönüştürülüp üçüncü bir tarafın sunucularına gönderiliyor. Kendi kendine barındırmak bunu kontrol ettiğiniz bir makinede tutar. Veri, aynı zamanda kripto parayla ve KYC olmadan ödeyeceğiniz kadar hassassa, yönetilen bir vektör bulutu tüm amacı boşa çıkarır.

Düz maliyet. Yönetilen vektör servisleri, saklanan vektörlere ve çalıştırılan sorgulara göre faturalandırır. Bir VPS tek bir aylık rakamdır ve onu istediğiniz kadar sert kullanabilirsiniz. Ölçekte, öngörülebilir olan sayaçlıyı yener.

Bunun boyutlandırma için anlamı

Tahmin ederek değil, korpusunuzu ölçerek başlayın. Embedding sayınızı ve boyutunuzu alın, bir örnek yükleyin, yerleşik belleği izleyin, dışarı doğru tahmin edin. Sonra indeks artı etrafındaki her şey için pay bırakan bir plan seçin — uygulama, model istemcisi, büyümek için yer.

Gizlice tutulan birkaç milyon vektörün ötesindeki her şey için, Pro serisi özel bir IP ve her gece yedeklerle 32 ile 80 GB arasında çalışır, ki bu indeks ürünün kendisi olduğunda ve onu kaybetmek acıttığında önemlidir.