Sådan bygger du en vidensbase: Artikler, søgning, rettigheder og AI-svar

En vidensbase er et søgbart bibliotek af svar: hvordan man gør noget, hvordan man løser noget, hvad reglen er. For at bygge en skal du have artikler grupperet i nogle få tydelige kategorier, en editor, som dine skribenter faktisk bruger, en søgning der finder den rigtige artikel ud fra de ord, folk rent faktisk skriver, og en beslutning om, hvem der må læse hvad — offentligheden, kunder der er logget ind, eller kun medarbejdere. En AI-app-builder kan lave strukturen, editoren og søgningen i en kort session. Det, der gør en vidensbase nyttig, er skrivningen og vedligeholdelsen, så design fra dag ét til nem redigering og til at spotte forældede artikler.

Beslut først, hvem den er til

De samme funktioner kan bruges til meget forskellige sites:

• Offentligt hjælpecenter — til kunder og potentielle kunder. Skal være hurtigt, kunne indekseres af søgemaskiner og skrevet med deres egne ord.
• Kun for kunder — bag et login, til betalende kunder eller partnere.
• Intern vidensbase — politikker, processer og guides til medarbejdere. Skal være privat; søgning og aktualitet betyder mere end design.

At blande offentlige og interne artikler på ét site er der, de fleste læk opstår. Hvis du har brug for begge dele, så giv hver artikel en klar synlighedsindstilling, eller kør to separate sites.

Hvad appen har brug for

Data

To felter gør meget af arbejdet: ejer (hvem der holder artiklen korrekt) og sidst gennemgået (hvornår nogen sidst bekræftede, at den stadig er sand). Sammen gør de det muligt at liste artikler, som ingen har tjekket i seks måneder.

Sider

• Læser: forside med søgning og kategorier, kategorisider, artikelsider med indholdsfortegnelse, relaterede artikler og en prompt »Var dette nyttigt?«.
• Editor: artikelliste med filtre (kladder, forældede, lavt bedømte), en editor med forhåndsvisning og revisionshistorik.
• Admin: kategorier, brugere og roller samt rapporter over søgninger uden resultater.

Rettigheder

Læsere ser de udgivne artikler, de må se. Editorer opretter og redigerer artikler, måske begrænset til bestemte kategorier. Admins udgiver, arkiverer og administrerer brugere. Til en intern vidensbase skal alle have et login; til et offentligt hjælpecenter er det kun skribenterne, der skal logge ind.

Beslutninger og afvejninger

Editor: Markdown eller rich text

Markdown er hurtig, portabel og fungerer godt med versionshistorik, men nogle skribenter synes, den er afskrækkende. En rich-text-editor med overskrifter, lister, billeder, callouts og kodeblokke føles bekendt. Uanset hvad du vælger, skal indholdet gemmes i et format, du kan eksportere senere.

Søgning

Simpel tekstsøgning i databasen er nok til nogle hundrede artikler, hvis du søger i titler, resuméer og brødtekst og rangerer titelmatch højere. Ud over det, eller hvis stavefejl og synonymer betyder noget (»faktura« vs. »regning«), brug rigtig fuldtekstsøgning eller en hostet søgetjeneste. Vores guide til at tilføje søgning gennemgår mulighederne. Log hver forespørgsel, der ikke giver resultater: det er en gratis liste over artikler, du skal skrive.

AI-svar

En »stil et spørgsmål«-boks, der svarer ud fra dine artikler, er nu almindelig. Den fungerer ved at hente de mest relevante passager og bede en sprogmodel svare udelukkende ud fra dem — se hvad RAG er. Vis altid kildeartiklerne, tillad »jeg ved det ikke«, og husk at den med stor sikkerhed gentager alt forældet i dine artikler. Byg den, efter artiklerne er i god form, ikke før.

Versionering og gennemgang

Gem revisioner, så du kan se, hvem der ændrede hvad, og rulle tilbage. Til reguleret indhold (HR-politik, sikkerhedsprocedurer) skal du tilføje et godkendelsestrin, før en ændring udgives.

En første prompt, der virker

Byg et offentligt hjælpecenter for Parcelly, en app til fragtlabels for små onlinebutikker. Forsiden har en stor søgeboks og seks kategorier (Kom i gang, Udskrivning af labels, Transportører, Fakturering, Retur, Fejlfinding). Artikler har en titel, et resumé, et indhold i Markdown med billeder og callouts, kategori, tags, status (kladde, udgivet, arkiveret), ejer og dato for sidste gennemgang. Artikelsider viser en indholdsfortegnelse, relaterede artikler og et »Var dette nyttigt?«-ja/nej med en valgfri kommentar. Søgningen dækker titler, resuméer og indhold, med titelmatch rangeret først, og logger hver forespørgsel og om den gav resultater. Et redigeringsområde (kræver login, roller editor og admin) viser kladder, artikler der ikke er gennemgået inden for 180 dage, og artikler med lav hjælpsomhedsscore, og det gemmer revisionshistorik. Hver artikel har sin egen sidetitel og metabeskrivelse til søgemaskiner. Rent, roligt og læsevenligt design. Mobile-first.

Byggetrin

1. Lav en liste over de første 20–30 artikler ud fra rigtige supportspørgsmål, før du bygger noget. Listen former kategorierne.
2. Generer sitet og tjek læsningen på en telefon — linjelængde, overskrifter, billeder.
3. Editor og roller. Skribenter skal kunne tilføje og rette artikler uden at bede en udvikler om det.
4. Søgning, og test den med de ord, kunderne faktisk bruger, inklusive stavefejl.
5. Feedback og søgelogning.
6. Rapport over forældede artikler baseret på ejer og dato for sidste gennemgang.
7. SEO-grundlag for et offentligt site: unikke titler, beskrivelser, rene URL'er, et sitemap. Se SEO for AI-byggede hjemmesider.
8. Link til den fra dit produkt og dine supportsvar, og følg listen over søgninger uden resultater ugentligt.
9. AI-svar, når indholdet sidder godt.

Almindelige fejl

• At organisere efter afdeling i stedet for efter, hvad læseren prøver at gøre.
• Lange artikler der dækker fem opgaver. Én opgave pr. artikel, med en titel der siger, hvad den løser.
• Ingen ejer pr. artikel. Ingen opdaterer noget, og tilliden falder efter det første forkerte svar.
• Interne noter i offentlige artikler. Brug separat synlighed, og gennemgå før udgivelse.
• Søgning, der kun matcher titler. Læsere skriver symptomer, ikke artikelnavne.
• Skærmbilleder uden alt-tekst eller kontekst. De bliver hurtigt forældede; beskriv trinnet med ord også.

Hvornår et færdigt produkt er det bedre valg

Hvis dit team allerede arbejder i et dokumentations- eller wikiværktøj, er en intern vidensbase der oftest den nemmeste vej — vores sammenligning af Notion og Confluence dækker to almindelige valg. Hvis du bruger et helpdesk-produkt, kan dets indbyggede hjælpecenter koble artikler til sager og foreslå artikler til kunder, hvilket er svært at genskabe. Docs-site-generatorer er ideelle til udviklerdokumentation, der ligger sammen med koden.

Byg dit eget, når du har brug for din egen struktur eller dine egne rettigheder (artikler pr. kunde, pr. lokation eller pr. rolle), vil have vidensbasen inde i dit produkt i stedet for på et separat site, har brug for gennemgangs- og godkendelsestrin, som en wiki ikke håndhæver, eller vil have AI-svar over dit indhold uden endnu et abonnement. Det passer naturligt sammen med en brugerdefineret helpdesk.

Sådan bygger du det med Mythex

På Mythex beskriver du vidensbasen i chatten, og den bygges i en live-forhåndsvisning; artikler, revisioner og feedback gemmes i en Postgres-database, som agenten tilføjer, når det er nødvendigt, og billeder lægges i projektets filopbevaring. Editor-logins bruger en godkendelsesmetode, du vælger, da Mythex ikke har et indbygget slutbrugerlogin. Til AI-svar bruger du din egen AI-udbyders API-nøgle, gemt som projekthemmelighed, og forbruget faktureres hos din udbyder og ikke med Mythex-kreditter (AI-opskriften). Nye Mythex-apps bruger som standard en klientrenderet React-SPA, som er svagere for søgemaskiner, så til et offentligt hjælpecenter bør du bede om en statisk-venlig eller serverrenderet opsætning såsom Next.js (SEO-opskriften).

Til en startprompt kan du prøve skabelonerne produktvidenshub eller team-dokumentationsapp.

Spørgsmål