Slik bygger du en kunnskapsbase: artikler, søk, tilganger og AI-svar

En kunnskapsbase er et søkbart bibliotek med svar: hvordan du gjør noe, hvordan du løser noe, hva regelen er. For å bygge en trenger du artikler gruppert i noen få tydelige kategorier, en redigeringsløsning forfatterne faktisk bruker, søk som finner riktig artikkel ut fra ordene folk virkelig skriver, og en beslutning om hvem som kan lese hva — offentligheten, kunder som er logget inn, eller kun ansatte. Et AI-verktøy for app-bygging kan lage strukturen, redigeringsverktøyet og søket i én kort økt. Det som gjør en kunnskapsbase nyttig, er skrivingen og vedlikeholdet, så design for enkel redigering og for å oppdage utdaterte artikler fra første dag.

Bestem først hvem den er for

De samme funksjonene brukes på svært ulike nettsteder:

• Offentlig hjelpesenter — for kunder og potensielle kunder. Må være raskt, indekserbart av søkemotorer og skrevet med deres ord.
• Dokumentasjon kun for kunder — bak innlogging, for betalende kunder eller partnere.
• Intern kunnskapsbase — retningslinjer, prosesser og veiledninger for ansatte. Må være privat; søk og aktualitet betyr mer enn design.

Hvis du blander offentlige og interne artikler på ett nettsted, oppstår de fleste lekkasjene. Trenger du begge deler, gi hver artikkel en tydelig synlighetsinnstilling, eller kjør to separate nettsteder.

Hva appen trenger

Data

To felt gjør mye av jobben: eier (hvem som holder artikkelen korrekt) og sist gjennomgått (når noen sist bekreftet at den fortsatt stemmer). Sammen lar de deg liste opp artikler ingen har sjekket på seks måneder.

Sider

• Leser: forside med søk og kategorier, kategorisider, artikkelsider med innholdsfortegnelse, relaterte artikler og en «Var dette nyttig?»-melding.
• Redaktør: artikkelliste med filtre (utkast, utdaterte, lavt vurderte), en redigerer med forhåndsvisning, og revisjonshistorikk.
• Admin: kategorier, brukere og roller, og rapporter over søk uten resultater.

Tilganger

Lesere ser publiserte artikler de har lov til å se. Redaktører oppretter og redigerer artikler, kanskje begrenset til bestemte kategorier. Admin publiserer, arkiverer og administrerer brukere. For en intern kunnskapsbase trenger alle innlogging; for et offentlig hjelpesenter er det bare forfatterne som trenger det.

Beslutninger og avveininger

Redigerer: Markdown eller rik tekst

Markdown er raskt, bærbart og fungerer godt med versjonshistorikk, men noen forfattere synes det er fremmedartet. En redigerer for rik tekst med overskrifter, lister, bilder, bokser med merknader og kodeblokker føles kjent. Uansett hva du velger, lagre innholdet i et format du kan eksportere senere.

Søk

Enkelt tekstsøk i databasen er nok for noen hundre artikler hvis du søker i titler, sammendrag og innhold, og rangerer treff i tittelen høyere. Utover det, eller hvis skrivefeil og synonymer betyr noe («faktura» mot «regning»), bruk ordentlig fulltekstsøk eller en hostet søketjeneste. Vår guide til å legge til søk går gjennom alternativene. Logg hvert søk som gir ingen treff: det er en gratis liste over artikler du bør skrive.

AI-svar

En «still et spørsmål»-boks som svarer fra artiklene dine er nå vanlig. Den fungerer ved å hente de mest relevante avsnittene og be en språkmodell svare kun ut fra dem — se hva RAG er. Vis alltid kildeartiklene, la svaret være «jeg vet ikke», og husk at den med sikkerhet vil gjenta alt utdatert i artiklene dine. Bygg den etter at artiklene er i god form, ikke før.

Versjonering og gjennomgang

Behold revisjoner slik at du kan se hvem som endret hva, og rulle tilbake. For regulert innhold (HR-retningslinjer, sikkerhetsprosedyrer) legg til et godkjenningstrinn før en endring publiseres.

En første prompt som fungerer

Bygg et offentlig hjelpesenter for Parcelly, en app for fraktetiketter for små nettbutikker. Forsiden har et stort søkefelt og seks kategorier (Kom i gang, Skrive ut etiketter, Transportører, Fakturering, Retur, Feilsøking). Artikler har tittel, sammendrag, innhold i Markdown med bilder og merknadsbokser, kategori, emneord, status (utkast, publisert, arkivert), eier og dato for siste gjennomgang. Artikkelsider viser innholdsfortegnelse, relaterte artikler og et «Var dette nyttig?» ja/nei-valg med valgfri kommentar. Søket dekker titler, sammendrag og innhold, med treff i tittelen rangert først, og logger hvert søk og om det ga resultater. Et redaktørområde (krever innlogging, roller redaktør og admin) lister utkast, artikler som ikke er gjennomgått på 180 dager og artikler med lave nytteskårer, og beholder revisjonshistorikk. Hver artikkel har sin egen sidetittel og metabeskrivelse for søkemotorer. Ren, rolig og lesbar design. Mobil først.

Byggetrinn

1. List opp de første 20–30 artiklene basert på ekte supportspørsmål før du bygger noe. Listen former kategoriene.
2. Generer nettstedet og sjekk lesbarheten på telefon — linjelengde, overskrifter, bilder.
3. Redaktør og roller. Forfattere må kunne legge til og rette artikler uten å spørre en utvikler.
4. Søk, og test det med ordene kundene faktisk bruker, inkludert skrivefeil.
5. Tilbakemeldinger og søkelogging.
6. Rapport over utdaterte artikler basert på eier og dato for siste gjennomgang.
7. SEO-grunnlag for et offentlig nettsted: unike titler, beskrivelser, rene URL-er og et sitemap. Se SEO for AI-bygde nettsider.
8. Lenk til den fra produktet og support-svarene dine, og følg loggen over søk uten resultater hver uke.
9. AI-svar, når innholdet er solid.

Vanlige feil

• Å organisere etter avdeling i stedet for etter hva leseren prøver å gjøre.
• Lange artikler som dekker fem oppgaver. Én oppgave per artikkel, med en tittel som sier hva den løser.
• Ingen eier per artikkel. Ingen oppdaterer noe, og tilliten synker etter første feil svar.
• Interne notater i offentlige artikler. Bruk egen synlighet, og gå gjennom før publisering.
• Søk som bare matcher titler. Lesere skriver symptomer, ikke artikkelnavn.
• Skjermbilder uten alt-tekst eller kontekst. De blir raskt utdaterte; beskriv også steget med ord.

Når et ferdig produkt er det bedre valget

Hvis teamet ditt allerede jobber i et dokumentasjons- eller wikiverktøy, er en intern kunnskapsbase der vanligvis den enkleste veien — vår sammenligning av Notion og Confluence dekker to vanlige valg. Hvis du bruker et produkt for kundestøtte, lenker den innebygde hjelpesenteren artikler til saker og foreslår artikler til kunder, noe som er vanskelig å gjenskape. Generatorer for dokumentasjonssider er ideelle for utviklerdokumentasjon som ligger sammen med koden.

Bygg din egen når du trenger egen struktur eller egne tilganger (artikler per kunde, per sted eller per rolle), vil ha kunnskapsbasen inne i produktet ditt i stedet for på et eget nettsted, trenger gjennomgangs- og godkjenningstrinn som en wiki ikke håndhever, eller vil ha AI-svar over innholdet ditt uten et ekstra abonnement. Den passer naturlig sammen med et eget kundestøttesystem.

Bygge den med Mythex

På Mythex beskriver du kunnskapsbasen i chatten, og den bygges i en live-forhåndsvisning; artikler, revisjoner og tilbakemeldinger lagres i en Postgres-database som agenten legger til når det trengs, og bilder havner i prosjektets fillagring. Innlogging for redaktører bruker en autentiseringsløsning du velger, siden Mythex ikke har innebygd innlogging for sluttbrukere. For AI-svar bruker du din egen AI-leverandørs API-nøkkel, lagret som hemmelighet i prosjektet, og bruken belastes din leverandørkonto, ikke Mythex-kreditter (AI-oppskriften). Nye Mythex-apper har som standard en React-enkeltsideapp som gjengis i nettleseren, og det er svakere for søkemotorer. For et offentlig hjelpesenter bør du derfor be om et statisk-vennlig eller server-gjengitt oppsett, for eksempel Next.js (SEO-oppskriften).

Som utgangspunkt for prompten kan du prøve malene produktkunnskapshub eller app for teamdokumentasjon.

Spørsmål