Vedlegg B — Arkitektur
Dette vedlegget inneholder et forslag til arkitektur på NAIS plattformen D.6 i Nav.
I hovedsak foreslås det at man skiller på backend for brukergrensesnittet og backend for KBS systemet og lar disse snakke med hverandre over et HTTP API. Dette tillater at disse komponentene kan utvikles uavhengig av hverandre og kan benytte forskjellige rammeverk. De fleste rammeverk for språkmodeller sikter på å støtte Python og det vil derfor være mer naturlig å implementere KBS systemet i Python. Samtidig utvikles de fleste NAIS applikasjoner i dag i Kotlin og de fleste utviklere kan dette bedre enn Python. Denne arkitekturen tillater derfor at Data Scientister kan enklere samarbeide med utviklere ved at komponentene kan utvikles hver for seg. Forhåpentligvis gjør det også at selve chatten kan gjenbrukes av flere prosjekter da den er mer uavhengig fra kunnskapsbasen og språkmodellen enn selve KBS systemet1.
Det andre hovedpoenget med denne arkitekturen er å kjøre selve KBS systemet på NAIS plattformen og ikke på Azure eller Vertex AI sine no/low-code løsninger. Dette gir sterkere kontroll over systemet samtidig som man gjør seg mer uavhengig av tilbyder av språkmodell og det vil være med på å gi bedre kontroll over kostnader.
Det er viktig i denne oversikten å presisere at man ikke trenger å bruke språkmodell, embedding modell eller vektordatabase fra samme tilbyder. Det vil være fullt mulig å kombinere slik man måtte ønske, f.eks. bruke språkmodell fra Vertex AI, embedding modell fra Azure OpenAI og Postgres (Cloud SQL) som vektordatabase (se Kapittel 2 for mer utfyllende informasjon om valget av tilbyder).
Det anbefales å tilpasse KBS systemet per kunnskapsbase da dette gir best resultater, samtidig som det er viktig å lære av hverandre.↩︎