Multi-tenant RAG: nauki iz 17 faz projekta EinCoreRAG

Pri gradnji podjetniških AI sistemov je prvo vprašanje vsakega CISO: „Kako jamčite, da moji podatki ne bodo pricurljali drugemu najemniku?“

V EinCoreRAG smo izolacijo izvedli na dveh ključnih ravneh: relacijski podatkovni bazi in vektorski bazi.

1. Relacijska raven: PostgreSQL Row-Level Security (RLS)

Avtorizacija na ravni aplikacije je krhka. Že en sam manjkajoč WHERE tenant_id = ? lahko razkrije občutljive podatke.

Zato smo izolacijo prestavili v sam database engine s pomočjo PostgreSQL RLS:

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

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

Naša API plast na začetku vsake zahtevne transakcije nastavi spremenljivko app.current_tenant_id. Tako vse poizvedbe naravno filtrirajo podatke, ki pripadajo drugim najemnikom.

2. Vektorska raven: Qdrant zbirke

Vektorske baze postavljajo drugačen izziv. Sprva smo razmišljali o eni skupni zbirki s tenant_id payload filtrom.

Na koncu smo prešli na zbirke na posameznega najemnika v Qdrantu iz treh razlogov:

1. Resnična izolacija: kompromitirana ali napačno nastavljena poizvedba ne more prečkati meje med zbirkami.
2. Zmogljivost: HNSW indeksi delujejo bolje, ko jim ni treba krmariti po ogromnih, raznolikih grafih.
3. Data residency: posamezne zbirke najemnikov je mogoče usmeriti v določene geografske regije ali namenske gruče.

Rezultat

Kombinacija RLS in ločenih vektorskih zbirk ustvarja arhitekturo „fail-closed“. Tudi če aplikacijska logika vsebuje napako, sami podatkovni motorji zavrnejo postrežbo zapisov iz drugih najemnikov.

To objavo je redigiral naš avtomatizirani varnostni cevovod, ki je odstranil notranje topološke podrobnosti.