Paano Gumawa ng Knowledge Base: Mga Artikulo, Search, Permiso at AI na Sagot

Ang knowledge base ay isang searchable na aklatan ng mga sagot: paano gawin ang isang bagay, paano ayusin ang isang bagay, ano ang tuntunin. Para makagawa nito, kailangan mo ng mga artikulong nakapangkat sa ilang malinaw na kategorya, editor na talagang gagamitin ng mga sumusulat, search na makakahanap ng tamang artikulo mula sa mga salitang tunay na tina-type ng mga tao, at desisyon kung sino ang puwedeng magbasa ng ano: publiko, mga customer na naka-login, o staff lang. Kayang gumawa ng AI app builder ng istruktura, editor, at search sa maikling session. Ang nagpapagamit ng knowledge base ay ang pagsusulat at pag-aalaga dito, kaya idisenyo mula sa unang araw para madaling i-edit at madaling makita ang mga lipas nang artikulo.

Alamin muna kung para kanino ito

Magkakaiba ang gamit ng magkakatulad na feature sa iba-ibang site:

• Public help center — para sa mga customer at prospect. Dapat mabilis, ma-index ng search engine, at nakasulat sa sarili nilang mga salita.
• Docs para sa customer lang — nasa likod ng login, para sa mga nagbabayad na customer o partner.
• Internal na knowledge base — mga patakaran, proseso, at paano-gawin para sa staff. Dapat pribado; mas mahalaga ang search at pagiging bago kaysa sa disenyo.

Kadalasang nagmumula ang pagtagas sa paghahalo ng publiko at internal na artikulo sa iisang site. Kung kailangan mo ang pareho, bigyan ng malinaw na visibility setting ang bawat artikulo, o magpatakbo ng dalawang magkahiwalay na site.

Ano ang kailangan ng app

Data

Dalawang field ang gumagawa ng malaking trabaho: may-ari (sino ang nagpapanatiling tama ang artikulo) at huling na-review (kailan huling kinumpirma ng isang tao na totoo pa rin ito). Sama-sama, nagbibigay ito ng listahan ng mga artikulong walang tumingin sa loob ng anim na buwan.

Mga page

• Reader: home na may search at kategorya, mga page ng kategorya, mga page ng artikulo na may table of contents, kaugnay na artikulo, at tanong na "Nakatulong ba ito?"
• Editor: listahan ng artikulo na may filter (draft, lipas na, mababa ang rating), editor na may preview, at kasaysayan ng revision.
• Admin: mga kategorya, user at role, at ulat ng mga search na walang resulta.

Mga permiso

Nakikita ng mambabasa ang mga na-publish na artikulong pinapayagan silang makita. Gumagawa at nag-e-edit ng artikulo ang mga editor, marahil limitado sa ilang kategorya. Nagpa-publish, nag-a-archive, at namamahala ng user ang mga admin. Para sa internal na knowledge base, kailangan ng login ng lahat; para sa public help center, mga sumusulat lang ang nangangailangan nito.

Mga desisyon at trade-off

Editor: Markdown o rich text

Mabilis, portable, at maayos na nakikisama sa version history ang Markdown, pero may mga sumusulat na hindi ito gusto. Pamilyar ang rich-text editor na may heading, listahan, larawan, callout, at code block. Anuman ang piliin mo, mag-imbak ng nilalaman sa format na maie-export mo sa hinaharap.

Search

Sapat na ang basic na database text search para sa ilang daang artikulo kung hahanapin ang mga pamagat, buod, at nilalaman, at mas mataas ang ranggo ng tugma sa pamagat. Lampas doon, o kung mahalaga ang typo at magkasingkahulugang salita ("invoice" vs "bill"), gumamit ng tamang full-text search o hosted na search service. Tinatalakay ng aming gabay sa pagdaragdag ng search ang mga opsyon. I-log ang bawat query na walang resulta: libreng listahan ito ng mga artikulong dapat mong isulat.

AI na sagot

Karaniwan na ngayon ang kahon na "magtanong" na sumasagot mula sa mga artikulo mo. Gumagana ito sa pamamagitan ng pagkuha ng pinakakaugnay na bahagi ng teksto at paghiling sa language model na sumagot lang mula roon; tingnan ang ano ang RAG. Laging ipakita ang mga pinagmulang artikulo, payagan ang "hindi ko alam," at tandaang uulitin nito nang may kumpiyansa ang anumang lipas sa mga artikulo mo. Buuin ito pagkatapos maging maayos ang mga artikulo, hindi bago.

Versioning at review

Panatilihin ang mga revision para makita kung sino ang nagbago ng ano at para makapag-rollback. Para sa mga regulated na nilalaman (HR policy, safety procedure), magdagdag ng hakbang ng pag-apruba bago i-publish ang pagbabago.

Prompt na gumagana

Gumawa ng public help center para sa Parcelly, isang shipping label app para sa maliliit na online shop. Home page na may malaking search box at anim na kategorya (Getting started, Printing labels, Carriers, Billing, Returns, Troubleshooting). May pamagat, buod, nilalamang nasa Markdown na may larawan at callout, kategorya, tag, status (draft, published, archived), may-ari, at petsa ng huling review ang mga artikulo. Ipinapakita ng mga page ng artikulo ang table of contents, kaugnay na artikulo, at "Nakatulong ba ito?" na oo/hindi na may opsyonal na komento. Sakop ng search ang mga pamagat, buod, at nilalaman, na may mga tugma sa pamagat sa unang ranggo, at nila-log nito ang bawat query at kung may resulta. May editor area (kailangan ng login, mga role na editor at admin) na naglilista ng mga draft, artikulong hindi na-review sa loob ng 180 araw, at mga artikulong mababa ang helpful score, at nagtatago ng kasaysayan ng revision. May sariling page title at meta description ang bawat artikulo para sa search engine. Malinis, kalmado, at madaling basahin na disenyo. Mobile-first.

Mga hakbang sa pagbuo

1. Ilista ang unang 20–30 artikulo mula sa totoong tanong ng support bago gumawa ng kahit ano. Hinuhubog ng listahang iyon ang mga kategorya.
2. Buuin ang site at suriin ang pagbabasa sa telepono: haba ng linya, heading, larawan.
3. Editor at mga role. Kailangang makapagdagdag at makapag-ayos ng artikulo ang mga sumusulat nang hindi humihingi ng tulong sa developer.
4. Search, at subukan gamit ang mga salitang talagang ginagamit ng mga customer, kasama ang maling spelling.
5. Feedback at search logging.
6. Ulat ng lipas nang artikulo batay sa may-ari at petsa ng huling review.
7. SEO basics para sa public site: natatanging pamagat, deskripsyon, malilinis na URL, at sitemap. Tingnan ang SEO para sa mga website na gawa ng AI.
8. I-link ito sa product mo at sa mga sagot ng support, saka bantayan lingguhan ang log ng walang resulta.
9. AI na sagot, kapag maayos na ang nilalaman.

Mga karaniwang pagkakamali

• Pag-aayos ayon sa departamento sa halip na ayon sa gustong gawin ng mambabasa.
• Mahahabang artikulong sumasaklaw sa limang gawain. Isang gawain bawat artikulo, na may pamagat na nagsasabi kung anong problema ang nilulutas.
• Walang may-ari bawat artikulo. Walang nag-a-update ng anuman, at bumababa ang tiwala pagkatapos ng unang maling sagot.
• Internal na tala sa public na artikulo. Gumamit ng hiwalay na visibility at mag-review bago mag-publish.
• Search na tugma lang sa pamagat. Sintomas ang tina-type ng mambabasa, hindi pangalan ng artikulo.
• Screenshot na walang alt text o konteksto. Mabilis itong lumipas sa panahon; ilarawan din sa salita ang hakbang.

Kailan mas mabuting ready-made na produkto

Kung nasa documentation o wiki tool na ang team mo, kadalasang pinakamadaling landas ang internal na knowledge base doon; sakop ng aming paghahambing ng Notion at Confluence ang dalawang karaniwang pagpipilian. Kung gumagamit ka ng helpdesk product, naka-link ng built-in na help center nito ang mga artikulo sa ticket at iminumungkahi ang mga artikulo sa customer, na mahirap gayahin. Ang mga docs-site generator ay mainam para sa developer documentation na nakatabi sa code.

Gumawa ng sarili mo kapag kailangan mo ng sarili mong istruktura o permiso (mga artikulo bawat kliyente, bawat lokasyon, o bawat role), gusto mong nasa loob ng product mo ang knowledge base sa halip na sa hiwalay na site, kailangan ng review at approval na hindi kayang ipatupad ng wiki, o gusto mo ng AI na sagot sa nilalaman mo nang walang isa pang subscription. Natural itong kasama ng isang custom na helpdesk.

Pagbuo nito gamit ang Mythex

Sa Mythex, inilalarawan mo ang knowledge base sa chat at ginagawa ito sa live preview; naka-imbak sa Postgres database na idinadagdag ng agent kapag kailangan ang mga artikulo, revision, at feedback, at napupunta sa file storage ng project ang mga larawan. Ang login ng editor ay gumagamit ng auth approach na pipiliin mo, dahil walang built-in na end-user login ang Mythex. Para sa AI na sagot, ginagamit mo ang sarili mong API key ng AI provider na nakatago bilang project secret, at ang paggamit ay sinisingil sa account ng provider mo at hindi sa Mythex credits (AI recipe). Ang mga bagong Mythex app ay default na client-rendered React single-page app, na mahina para sa search engine, kaya para sa public help center, humiling ng static-friendly o server-rendered na setup gaya ng Next.js (SEO recipe).

Para sa panimulang prompt, subukan ang product knowledge hub o team docs app na template.

Mga tanong