Multi-tenant RAG: lekcije iz 17 faza EinCoreRAG-a

Kada gradite enterprise AI sisteme, prvo pitanje svakog CISO-a glasi: „Kako garantujete da moji podaci neće procuriti drugom tenant-u?“

U EinCoreRAG-u smo to rešili nametanjem izolacije na dva ključna sloja: relacionoj bazi i vektorskoj bazi.

1. Relacioni sloj: PostgreSQL Row-Level Security (RLS)

Autorizacija na nivou aplikacije je krhka. Jedan izostavljen WHERE tenant_id = ? može da otkrije osetljive podatke.

Zato smo izolaciju spustili u sam database engine pomoću PostgreSQL RLS-a:

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation_policy ON documents
    USING (tenant_id = current_setting('app.current_tenant_id'));

Naš API sloj postavlja varijablu app.current_tenant_id na početku svake request transakcije. Time se garantuje da svi upiti prirodno odsecaju podatke koji pripadaju drugim tenant-ima.

2. Vektorski sloj: Qdrant kolekcije

Vektorske baze imaju drugačiji izazov. Prvobitno smo razmatrali jednu deljenu kolekciju sa tenant_id payload filterom.

Na kraju smo prešli na kolekcije po tenant-u u Qdrant-u iz tri razloga:

1. Stvarna izolacija: kompromitovan ili pogrešno konfigurisan upit ne može da pređe granicu kolekcije.
2. Performanse: HNSW indeksi rade bolje kada ne moraju da navigiraju kroz ogromne, raznorodne grafove.
3. Data residency: kolekcije pojedinih tenant-a mogu da se rutiraju u određene geografske regione ili na namenske klastere.

Rezultat

Kombinacija RLS-a i razdvojenih vektorskih kolekcija stvara „fail-closed“ arhitekturu. Čak i ako aplikativna logika ima propust, sami database engine-i odbijaju da posluže zapise koji pripadaju drugom tenant-u.

Ovaj tekst je redaktovan našim automatskim bezbednosnim pipeline-om, sa uklonjenim internim topološkim detaljima.