AI · Data · Säkerhet · 2026
Behörighetsstyrd AI-sökning i många företags data
En AI-sökassistent (RAG) för många kundföretag, byggd på PostgreSQL och pgvector för en SaaS-produkt: personalen får bara svar ur poster de har behörighet till.
- 01FrågaStälld med medarbetarens egna ord.
- 02PlanModellen väljer sökning, SQL eller båda, styrd av verksamhetsbegrepp.
- 03BehörighetsfilterSpärrFöretagets schema, grupper och personer som posten delats med avgör vad som får läsas.
- 04RerankingHybridsökning, sedan reranking i samma process som lyfter den bästa posten först.
- 05SvarMed källor och Rätt/Fel-markering för att granska missar.
- frågor med rätt post först efter reranking, tidigare 28
- 34/40
- frågetyper besvarade med SQL-planering, tidigare 5
- 12/13
- per fråga med begreppsväljaren, tidigare runt 38 s
- ~12 s
Utgångsläge
Data får inte gå mellan kundföretag, och en HR-post får inte nå en säljare. Eftersom kunderna sätter upp tjänsten själva gick det inte att be dem strukturera om sin data.
Min roll
Ensam utvecklare: arkitektur, kod, utvärdering och uppsättningen med Docker Compose.
Vad jag byggde
- Arkitektur: pgvector som primär vektordatabas och Pinecone bakom samma gränssnitt, så att funktionerna inte behöver särfall per databas.
- Frontend: Chattvy med källhänvisningar och Rätt/Fel-markeringar med kommentarer för att granska missar.
- Backend: FastAPI-tjänst; connectors för PostgreSQL och Dropbox märker varje textbit med företag, grupper och personer den delats med.
- Data och AI: Hybridsökning, reranking i samma process och modellplanerad sökning, SQL eller båda, styrd av verksamhetsbegrepp.
- Säkerhet: Modellskriven SQL körs skrivskyddat bakom row-level security och en parserkontroll; uppladdade filer tolkas i tidsbegränsade barnprocesser.
- Infrastruktur och DevOps: Docker Compose; ett kommando bygger varje företags schema, index och inloggningar från konfiguration.
- Test: 486 automatiska tester, bland annat för isolering i båda databaserna; fem före/efter-utvärderingar avgjorde vad som fick stanna.
Svåra problem och beslut
- Delat index eller schema per företag. Jag valde scheman, så att det är databasen och inte applikationskoden som stoppar läsningar mellan företag. Priset: fler objekt.
- Modellskriven SQL. Jag valde en synkad kopia framför kundernas skarpa databaser: ingen last hos kunden, men datan är bara så färsk som senaste synken.
- För många begrepp. Med 300 verksamhetsbegrepp tog varje fråga runt 38 sekunder; en väljare kortade det till runt 12 sekunder, med rätt begrepp för 41 av 41 testfrågor.
Resultat
På ett syntetiskt utvärderingsset: reranking satte rätt post först för 34 av 40 frågor (tidigare 28); SQL-planering besvarade 12 av 13 frågetyper (tidigare 5); begreppen lyfte ett formuleringstest från 44 till 51 av 53.
Teknik
Python, FastAPI, PostgreSQL, pgvector, Pinecone, Ollama, Dropbox API
Områden
Arkitektur, Frontend, Backend, Data, AI, Säkerhet, Infrastruktur och DevOps, Test
Period
oktober 2026 – pågår