Cara Membuat Knowledge Base: Artikel, Pencarian, Izin Akses, dan Jawaban AI

Knowledge base adalah perpustakaan jawaban yang bisa dicari: cara melakukan sesuatu, cara memperbaiki sesuatu, apa aturannya. Untuk membuatnya, Anda membutuhkan artikel yang dikelompokkan ke dalam beberapa kategori yang jelas, editor yang benar-benar dipakai penulis Anda, pencarian yang menemukan artikel yang tepat dari kata-kata yang benar-benar diketik orang, dan keputusan tentang siapa yang boleh membaca apa — publik, pelanggan yang sudah login, atau hanya staf. AI app builder bisa menghasilkan struktur, editor, dan pencarian dalam satu sesi singkat. Yang membuat knowledge base berguna adalah penulisan dan perawatannya, jadi rancang sejak hari pertama agar mudah diedit dan mudah menemukan artikel yang sudah usang.

Tentukan dulu untuk siapa

Fitur yang sama bisa melayani situs yang sangat berbeda:

• Pusat bantuan publik — untuk pelanggan dan calon pelanggan. Harus cepat, bisa diindeks mesin pencari, dan ditulis dengan bahasa mereka.
• Dokumentasi khusus pelanggan — di balik login, untuk pelanggan berbayar atau mitra.
• Knowledge base internal — kebijakan, proses, dan panduan langkah demi langkah untuk staf. Harus privat; pencarian dan kesegaran isi lebih penting daripada desain.

Mencampur artikel publik dan internal dalam satu situs adalah sumber kebocoran paling umum. Jika Anda membutuhkan keduanya, beri setiap artikel pengaturan visibilitas yang jelas, atau jalankan dua situs terpisah.

Yang dibutuhkan aplikasi

Data

Dua field bekerja sangat keras: pemilik (siapa yang menjaga artikel ini tetap akurat) dan terakhir ditinjau (kapan seseorang terakhir memastikan isinya masih benar). Bersama-sama, keduanya memungkinkan Anda mendaftar artikel yang belum diperiksa siapa pun selama enam bulan.

Halaman

• Pembaca: beranda dengan pencarian dan kategori, halaman kategori, halaman artikel dengan daftar isi, artikel terkait, dan pertanyaan "Apakah ini membantu?".
• Editor: daftar artikel dengan filter (draf, usang, rating rendah), editor dengan pratinjau, dan riwayat revisi.
• Admin: kategori, pengguna dan peran, serta laporan pencarian tanpa hasil.

Izin akses

Pembaca melihat artikel terbit yang boleh mereka lihat. Editor membuat dan mengedit artikel, mungkin dibatasi pada kategori tertentu. Admin menerbitkan, mengarsipkan, dan mengelola pengguna. Untuk knowledge base internal, semua orang butuh login; untuk pusat bantuan publik, hanya penulis yang butuh.

Keputusan dan trade-off

Editor: Markdown atau rich text

Markdown cepat, portabel, dan cocok dengan riwayat versi, tetapi sebagian penulis merasa kurang nyaman. Editor rich-text dengan heading, daftar, gambar, callout, dan blok kode terasa lebih familiar. Apa pun pilihannya, simpan konten dalam format yang bisa Anda ekspor nanti.

Pencarian

Pencarian teks database dasar sudah cukup untuk beberapa ratus artikel jika Anda mencari di judul, ringkasan, dan isi, serta memberi peringkat lebih tinggi pada kecocokan judul. Lebih dari itu, atau jika salah ketik dan sinonim penting ("invoice" vs "tagihan"), gunakan full-text search yang layak atau layanan pencarian hosted. Panduan kami tentang menambahkan pencarian membahas pilihannya. Catat setiap kueri yang tidak menghasilkan apa-apa: itu adalah daftar gratis tentang artikel apa yang perlu ditulis.

Jawaban AI

Kotak "ajukan pertanyaan" yang menjawab dari artikel Anda sekarang sudah umum. Cara kerjanya: mengambil bagian yang paling relevan lalu meminta language model menjawab hanya dari bagian tersebut — lihat apa itu RAG. Selalu tampilkan artikel sumber, izinkan jawaban "saya tidak tahu", dan ingat bahwa sistem ini akan dengan yakin mengulang apa pun yang sudah usang di artikel Anda. Bangun fitur ini setelah artikelnya rapi, bukan sebelumnya.

Versi dan peninjauan

Simpan revisi agar Anda bisa melihat siapa mengubah apa dan mengembalikannya. Untuk konten yang diatur (kebijakan SDM, prosedur keselamatan), tambahkan langkah persetujuan sebelum perubahan diterbitkan.

Prompt pertama yang berhasil

Buat pusat bantuan publik untuk Parcelly, aplikasi label pengiriman untuk toko online kecil. Beranda dengan kotak pencarian besar dan enam kategori (Memulai, Mencetak label, Kurir, Tagihan, Pengembalian, Pemecahan masalah). Artikel memiliki judul, ringkasan, isi dalam Markdown dengan gambar dan callout, kategori, tag, status (draf, terbit, diarsipkan), pemilik, dan tanggal terakhir ditinjau. Halaman artikel menampilkan daftar isi, artikel terkait, dan pertanyaan "Apakah ini membantu?" ya/tidak dengan komentar opsional. Pencarian mencakup judul, ringkasan, dan isi dengan kecocokan judul diurutkan paling atas, dan mencatat setiap kueri serta apakah menghasilkan hasil. Area editor (butuh login, peran editor dan admin) menampilkan draf, artikel yang belum ditinjau selama 180 hari, dan artikel dengan skor membantu yang rendah, serta menyimpan riwayat revisi. Setiap artikel punya judul halaman dan meta description sendiri untuk mesin pencari. Desain bersih, tenang, dan mudah dibaca. Utamakan ponsel.

Langkah membangun

1. Daftar 20–30 artikel pertama dari pertanyaan dukungan yang nyata sebelum membangun apa pun. Daftar itu yang membentuk kategori.
2. Hasilkan situsnya dan periksa keterbacaan di ponsel — panjang baris, heading, gambar.
3. Editor dan peran. Penulis perlu menambah dan memperbaiki artikel tanpa meminta bantuan developer.
4. Pencarian, lalu uji dengan kata-kata yang benar-benar dipakai pelanggan, termasuk salah eja.
5. Umpan balik dan pencatatan pencarian.
6. Laporan artikel usang berdasarkan pemilik dan tanggal terakhir ditinjau.
7. Dasar SEO untuk situs publik: judul dan deskripsi unik, URL yang bersih, sitemap. Lihat SEO untuk website yang dibuat dengan AI.
8. Tautkan dari produk dan balasan dukungan Anda, lalu pantau log tanpa hasil setiap minggu.
9. Jawaban AI, setelah isinya kokoh.

Kesalahan umum

• Mengatur berdasarkan departemen alih-alih berdasarkan apa yang ingin dilakukan pembaca.
• Artikel panjang yang membahas lima tugas. Satu tugas per artikel, dengan judul yang menjelaskan masalah yang diselesaikannya.
• Tidak ada pemilik per artikel. Tidak ada yang memperbarui apa pun, dan kepercayaan turun setelah satu jawaban yang salah.
• Catatan internal di artikel publik. Gunakan visibilitas terpisah, dan tinjau sebelum menerbitkan.
• Pencarian yang hanya cocok dengan judul. Pembaca mengetik gejala, bukan nama artikel.
• Screenshot tanpa alt text atau konteks. Screenshot cepat usang; jelaskan langkahnya dengan kata-kata juga.

Kapan produk siap pakai lebih baik

Jika tim Anda sudah bekerja di alat dokumentasi atau wiki, knowledge base internal di sana biasanya jalur termudah — perbandingan Notion vs Confluence kami membahas dua pilihan umum. Jika Anda memakai produk helpdesk, pusat bantuan bawaannya menautkan artikel ke tiket dan menyarankan artikel kepada pelanggan, dan itu sulit ditiru. Generator situs dokumentasi ideal untuk dokumentasi developer yang disimpan berdampingan dengan kode.

Bangun sendiri ketika Anda membutuhkan struktur atau izin akses sendiri (artikel per klien, per lokasi, per peran), ingin knowledge base berada di dalam produk Anda alih-alih di situs terpisah, membutuhkan langkah peninjauan dan persetujuan yang tidak diterapkan wiki, atau ingin jawaban AI atas konten Anda tanpa langganan lain. Ini cocok dipasangkan dengan helpdesk kustom.

Membangunnya dengan Mythex

Di Mythex, Anda mendeskripsikan knowledge base di chat dan dibangun di pratinjau langsung; artikel, revisi, dan umpan balik disimpan di database Postgres yang ditambahkan agent saat dibutuhkan, dan gambar masuk ke file storage proyek. Login editor memakai pendekatan autentikasi yang Anda pilih, karena Mythex tidak punya login pengguna akhir bawaan. Untuk jawaban AI, Anda memakai API key dari penyedia AI Anda sendiri yang disimpan sebagai secret proyek, dan penggunaannya ditagihkan ke akun penyedia Anda, bukan kredit Mythex (resep AI). Aplikasi Mythex baru secara default berupa single-page app React yang di-render di klien, yang kurang baik untuk mesin pencari, jadi untuk pusat bantuan publik mintalah pengaturan yang ramah static atau di-render di server seperti Next.js (resep SEO).

Untuk prompt awal, coba template pusat pengetahuan produk atau aplikasi dokumentasi tim.

Pertanyaan