Onsite offline LLM: internt spørsmål-og-svar uten sky

Ansatte bruker altfor lang tid på å lete etter svar som allerede står skrevet ned et sted i firmaet: i wikien, i en gammel e-post, i en database eller i et dokument ingen husker navnet på. Samtidig kan ikke de interne dataene lastes opp i en skytjeneste. Da sitter man igjen med ett fornuftig alternativ: et onsite offline LLM-system som svarer på interne spørsmål ut fra bedriftens egne kilder, med full datakontroll og ingen trafikk ut av huset.

Arkitektur

Systemet er en kjede av fire deler. Et web-UI tar imot spørsmålet. En RAG-motor henter de relevante tekstbitene og bygger konteksten. En vektordatabase lagrer bitene og lar deg søke i dem. Og en LLM skriver selve svaret. Alt sammen kjører lokalt, ingenting ringer hjem.

• Web-UI: en enkel chat-flate mot RAG-motoren.
• RAG-motor: for eksempel LlamaIndex, som indekserer dokumentene og styrer både søk og generering.
• Vektordatabase: for eksempel Qdrant, med tilgangsfilter per chunk.
• LLM: servert med vLLM.
• Embeddings: en flerspråklig modell som faktisk takler norsk.

Kildene deles opp i biter (chunks). Hver bit får sin egen embedding, og embeddingene legges i vektordatabasen. Kommer det et spørsmål, embeddes spørsmålet på samme måte, de nærmeste bitene hentes fram, og LLM-en svarer kun ut fra det den fikk servert. Ikke noe mer.

Kjør alt i Docker Compose

Hele stacken kjører på én arbeidsstasjon. Identiteten henter du fra katalogtjenesten bedriften allerede har, så du slipper å bygge og vedlikeholde nok et 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]

Punkt 1: tilgangskontroll per chunk fra dag én

Den klassiske tabben i slike systemer er lekkasje på tvers av brukere. Noen stiller et helt uskyldig spørsmål og får tilbake tekst fra dokumenter de aldri skulle hatt tilgang til. Grunnen er nesten alltid den samme: tilgangen legges på for sent, etter at indeksen allerede er full av ufiltrerte biter.

Løsningen er å lagre tilgangsmetadata på hver enkelt chunk og filtrere i selve søket, ikke i etterkant. Da finnes det rett og slett ingen vei for en uautorisert bit inn i konteksten LLM-en får se.

filter = {
  "must": [
    {"key": "acl", "match": {"any": bruker_grupper}}
  ]
}
# søk mot Qdrant med filter, ALDRI uten

Legg dette inn allerede ved første indeksering. Å ettermontere tilgangskontroll på en ferdig indeks er både dyrt og lett å gjøre feil.

Punkt 2: bruk vLLM, ikke en enbruker-server

Så snart flere ansatte bruker systemet samtidig, er det batchingen som avgjør hvor mye du får ut av maskinen. En enbruker-server tar forespørslene i kø og legger seg flat under last. vLLM batcher dem i stedet, og holder gjennomstrømmingen oppe selv når mange spør på én gang.

Velg altså LLM-server etter hvor godt den takler samtidige brukere, ikke etter hvor lett den var å få opp å kjøre på laptopen.

Oppsummert

Onsite RAG gir svar på interne spørsmål uten at data forlater huset. To ting avgjør om det holder i produksjon: håndhev tilgangskontroll per chunk fra start, og server modellen med vLLM så snart mer enn én person skal bruke den. Resten er detaljer.