Ako funguje multi-tenant vektorová databáza pre viacero klientov

Multi-tenant vektorová databáza umožňuje jednej AI infraštruktúre bezpečne obsluhovať viacero klientov naraz, pričom dáta každého z nich zostávajú logicky oddelené a nikdy sa nemiešajú vo výsledkoch vyhľadávania. Namiesto samostatnej databázy pre každého klienta sa používa jedna zdieľaná databáza s metadátovým označením, napríklad client_id alebo institution_id, ktoré pri každom vyhľadávaní filtruje výsledky tak, aby agent alebo chatbot videl výhradne dáta, ku ktorým má daný klient oprávnenie.

Prečo je multi-tenant architektúra dôležitá

Pre firmy, ktoré budujú AI riešenie pre viacero klientov naraz, je tento prístup zásadný z dvoch dôvodov:

• Efektivita nákladov a údržby – jedna spravovaná infraštruktúra namiesto desiatok samostatných databáz znižuje prevádzkové náklady aj zložitosť správy.
• Škálovateľnosť – pridanie nového klienta znamená pridanie metadátového filtra, nie budovanie novej infraštruktúry od nuly.

Bez správne navrhnutej architektúry firma buď duplikuje infraštruktúru pre každého klienta, čo je drahé a ťažko škálovateľné, alebo riskuje, že sa dáta rôznych klientov premiešajú vo výsledkoch. To je bezpečnostné aj compliance riziko.

Ako funguje oddelenie dát v praxi

1. Označenie pri indexovaní – každý dokument sa pri vložení do databázy označí metadátami, ktoré identifikujú vlastníka: klienta, inštitúciu, oddelenie alebo úroveň prístupu.
2. Filtrovanie pri vyhľadávaní – keď používateľ položí otázku, systém pridá filter podľa jeho identity a prístupových práv predtým, než prebehne sémantické vyhľadávanie.
3. Vrátenie len oprávnených výsledkov – aj keby databáza obsahovala tisíce dokumentov od desiatok klientov, odpoveď stojí výhradne na dátach, ku ktorým má pýtajúci sa prístup.

Tento prístup je odlišný od jednoduchšieho riešenia „jedna databáza na klienta", ktoré sa ľahšie implementuje, ale je výrazne drahšie a náročnejšie na škálovanie pri desiatkach či stovkách klientov.

Kľúčové architektonické rozhodnutia

Druhý riadok je najčastejšia chyba. Keď sa filtruje až po vyhľadávaní, dokumenty cudzieho klienta sa do systému dostanú a spoliehate sa na to, že ich aplikácia odfiltruje. Súvisí to priamo s tým, čo rozoberá článok o bezpečnostných rizikách LLM.

Prípad použitia: platforma pre viacero inštitúcií rovnakého typu

Typickým scenárom je AI produkt pre viacero organizácií rovnakého druhu: viacero univerzít, pobočiek reťazca alebo klientov v rovnakom odvetví. Každá inštitúcia má vlastné dokumenty, no všetky zdieľajú rovnakú aplikačnú logiku a infraštruktúru.

Multi-tenant databáza s filtrovaním podľa inštitúcie potom umožňuje:

• Nasadiť nového klienta rýchlo, bez budovania novej infraštruktúry.
• Garantovať, že dáta jednej inštitúcie sa nikdy nezobrazia používateľom inej.
• Škálovať produkt na desiatky klientov s minimálnym nárastom nákladov na klienta.
• Centrálne spravovať aktualizácie naprieč všetkými klientmi súčasne.

Tento model je typický pre B2B SaaS AI produkty, kde sa rovnaká platforma predáva viacerým organizáciám v rámci jedného odvetvia. Vrstva, ktorá nad ňou beží, býva RAG.

Bezpečnostné aspekty, ktoré sa nedajú podceniť

• Testovanie izolácie dát – pred nasadením treba overiť, že filtrovanie funguje spoľahlivo aj v okrajových prípadoch.
• Audit prístupov – logovanie, kto a kedy pristupoval k akým dátam, je dôležité pre compliance najmä v regulovaných odvetviach.
• Zálohovanie a izolácia pri výpadku – problém u jedného klienta nesmie ovplyvniť dostupnosť ani bezpečnosť dát ostatných.

Izoláciu dát v multi-tenant systéme treba testovať rovnako dôsledne ako samotné odpovede. Chyba sa tu neprejaví zlou odpoveďou, ale odpoveďou z cudzích dokumentov.