Onsite offline LLM med RAG: tilgangskontroll per chunk og vLLM

Et onsite offline LLM-system svarer på interne spørsmål ut fra bedriftens egne kilder: wikien, gamle e-poster, databaser og dokumenter. Alt kjører lokalt, og ingen data går ut av huset. Det er aktuelt når de interne dataene ikke kan lastes opp i en skytjeneste.

Arkitektur

Systemet består av fire deler som alle kjører lokalt:

• Et web-UI med en enkel chat-flate tar imot spørsmålet.
• En RAG-motor, for eksempel LlamaIndex, indekserer dokumentene, henter de relevante tekstbitene og bygger konteksten.
• En vektordatabase, for eksempel Qdrant, lagrer bitene med tilgangsfilter per chunk.
• En LLM servert med vLLM skriver svaret.

Embeddings lages med en flerspråklig modell som håndterer norsk.

Kildene deles i biter (chunks). Hver bit får sin egen embedding, som lagres i vektordatabasen. Et spørsmål embeddes på samme måte, de nærmeste bitene hentes, og LLM-en svarer bare ut fra disse.

Kjør alt i Docker Compose

Hele stacken kjører på én arbeidsstasjon. Identiteten hentes fra katalogtjenesten bedriften allerede har, så du trenger ikke et eget brukerregister.

services:
vllm:
image: vllm/vllm-openai:latest
command: --model --port 8000
qdrant:
image: qdrant/qdrant:latest
rag:
build: ./rag
depends_on: [vllm, qdrant]
web:
build: ./web
depends_on: [rag]1. Tilgangskontroll per chunk fra første indekseringDen vanligste feilen i slike systemer er lekkasje mellom brukere: et spørsmål gir svar med tekst fra dokumenter brukeren ikke har tilgang til. Årsaken er nesten alltid at tilgangskontrollen legges på etter at indeksen er fylt med ufiltrerte biter.

Lagre tilgangsmetadata på hver chunk og filtrer i selve søket. Da kan ingen uautorisert bit havne i konteksten LLM-en får.

filter = {
"must": [
{"key": "acl", "match": {"any": bruker_grupper}}
]
}
# søk mot Qdrant med filter, ALDRI utenLegg dette inn ved første indeksering. Å ettermontere tilgangskontroll på en ferdig indeks er dyrt og lett å gjøre feil.

2. Server modellen med vLLM

Når flere ansatte bruker systemet samtidig, avgjør batching hvor mye maskinen yter. En enbruker-server setter forespørslene i kø og blir treg under last. vLLM batcher forespørslene og holder gjennomstrømmingen oppe med mange samtidige brukere. Velg LLM-server etter hvor godt den håndterer samtidige brukere.