วิธีสร้างฐานความรู้: บทความ การค้นหา สิทธิ์การเข้าถึง และคำตอบจาก AI

ฐานความรู้คือคลังคำตอบที่ค้นหาได้: จะทำสิ่งหนึ่งอย่างไร จะแก้ปัญหาอย่างไร กฎคืออะไร การสร้างฐานความรู้ต้องมีบทความที่จัดกลุ่มเป็นไม่กี่หมวดหมู่ที่ชัดเจน มีตัวแก้ไขที่ผู้เขียนใช้จริง มีการค้นหาที่พบบทความที่ถูกต้องจากคำที่ผู้คนพิมพ์จริงๆ และต้องตัดสินใจว่าใครอ่านอะไรได้ ได้แก่ สาธารณะ ลูกค้าที่เข้าสู่ระบบ หรือพนักงานเท่านั้น ตัวสร้างแอปด้วย AI สามารถสร้างโครงสร้าง ตัวแก้ไข และการค้นหาได้ในเซสชันสั้นๆ สิ่งที่ทำให้ฐานความรู้มีประโยชน์คือการเขียนและการดูแลรักษา ดังนั้นควรออกแบบให้แก้ไขง่ายและสังเกตบทความที่ล้าสมัยตั้งแต่วันแรก

ตัดสินใจก่อนว่าใครคือผู้ใช้

ฟีเจอร์เดียวกันรองรับเว็บที่ต่างกันมาก:

• ศูนย์ช่วยเหลือสาธารณะ สำหรับลูกค้าและผู้ที่สนใจ ต้องเร็ว เครื่องมือค้นหาจัดทำดัชนีได้ และเขียนด้วยภาษาของพวกเขา
• เอกสารเฉพาะลูกค้า อยู่หลังการเข้าสู่ระบบ สำหรับลูกค้าที่จ่ายเงินหรือพันธมิตร
• ฐานความรู้ภายใน นโยบาย กระบวนการ และวิธีทำสำหรับพนักงาน ต้องเป็นส่วนตัว การค้นหาและความทันสมัยสำคัญกว่าการออกแบบ

การรวมบทความสาธารณะกับภายในไว้ในเว็บเดียวคือจุดที่ข้อมูลรั่วไหลบ่อยที่สุด ถ้าจำเป็นต้องมีทั้งสองอย่าง ให้ตั้งค่าการมองเห็นของแต่ละบทความให้ชัดเจน หรือแยกเป็นสองเว็บ

แอปต้องมีอะไรบ้าง

ข้อมูล

สองฟิลด์ทำงานหนักมาก ได้แก่ เจ้าของ (ใครรับผิดชอบให้บทความถูกต้อง) และ วันที่ตรวจทานล่าสุด (มีคนยืนยันว่ายังใช้ได้เมื่อไร) เมื่อรวมกันแล้วคุณจะแสดงรายการบทความที่ไม่มีใครตรวจมาหกเดือนได้

หน้า

• ผู้อ่าน: หน้าแรกพร้อมการค้นหาและหมวดหมู่ หน้าหมวดหมู่ หน้าบทความพร้อมสารบัญ บทความที่เกี่ยวข้อง และคำถาม “บทความนี้มีประโยชน์ไหม?”
• ผู้แก้ไข: รายการบทความพร้อมตัวกรอง (ร่าง ที่ล้าสมัย คะแนนต่ำ) ตัวแก้ไขพร้อมพรีวิว และประวัติการแก้ไข
• แอดมิน: หมวดหมู่ ผู้ใช้และบทบาท และรายงานการค้นหาที่ไม่พบผลลัพธ์

สิทธิ์การเข้าถึง

ผู้อ่านเห็นบทความที่เผยแพร่แล้วซึ่งตนมีสิทธิ์ดู ผู้แก้ไขสร้างและแก้ไขบทความ อาจจำกัดให้เฉพาะบางหมวดหมู่ แอดมินเผยแพร่ เก็บถาวร และจัดการผู้ใช้ สำหรับฐานความรู้ภายใน ทุกคนต้องเข้าสู่ระบบ ส่วนศูนย์ช่วยเหลือสาธารณะ เฉพาะผู้เขียนเท่านั้นที่ต้องเข้าสู่ระบบ

การตัดสินใจและข้อแลกเปลี่ยน

ตัวแก้ไข: Markdown หรือ rich text

Markdown เร็ว พกพาได้ และทำงานกับประวัติเวอร์ชันได้ดี แต่ผู้เขียนบางคนอาจรู้สึกไม่คุ้นเคย ตัวแก้ไข rich-text ที่มีหัวข้อ รายการ รูปภาพ กล่องข้อความเน้น และบล็อกโค้ด จะคุ้นมือกว่า ไม่ว่าจะเลือกแบบไหน ให้เก็บเนื้อหาในรูปแบบที่ส่งออกได้ในภายหลัง

การค้นหา

การค้นหาข้อความในฐานข้อมูลพื้นฐานเพียงพอสำหรับบทความหลายร้อยชิ้น ถ้าค้นหาจากชื่อเรื่อง บทสรุป และเนื้อหา และให้ความสำคัญกับการตรงชื่อเรื่องมากกว่า แต่ถ้ามีจำนวนมากขึ้น หรือการพิมพ์ผิดและคำพ้องความหมายสำคัญ (เช่น “ใบแจ้งหนี้” กับ “บิล”) ให้ใช้ full-text search ที่เหมาะสมหรือบริการค้นหาแบบโฮสต์ คู่มือการเพิ่มการค้นหาให้แอปของคุณ อธิบายตัวเลือกต่างๆ บันทึกทุกคำค้นที่ไม่มีผลลัพธ์ เพราะเป็นรายการบทความที่ควรเขียนโดยไม่ต้องเสียค่าใช้จ่าย

คำตอบจาก AI

กล่อง “ถามคำถาม” ที่ตอบจากบทความของคุณเป็นเรื่องปกติแล้ว ทำงานโดยค้นหาข้อความที่เกี่ยวข้องมากที่สุด แล้วให้โมเดลภาษาตอบจากข้อความเหล่านั้นเท่านั้น ดูRAG คืออะไร เสมอควรแสดงบทความต้นทาง อนุญาตให้ตอบว่า “ไม่ทราบ” และจำไว้ว่าโมเดลจะพูดซ้ำสิ่งที่ล้าสมัยในบทความของคุณด้วยความมั่นใจ สร้างฟีเจอร์นี้หลังจากบทความอยู่ในสภาพดีแล้ว ไม่ใช่ก่อน

การเก็บเวอร์ชันและการตรวจทาน

เก็บประวัติการแก้ไขไว้เพื่อดูว่าใครเปลี่ยนอะไรและย้อนกลับได้ สำหรับเนื้อหาที่มีกฎระเบียบ (นโยบาย HR ขั้นตอนความปลอดภัย) ให้เพิ่มขั้นตอนการอนุมัติก่อนเผยแพร่การเปลี่ยนแปลง

พรอมต์แรกที่ใช้ได้จริง

สร้างศูนย์ช่วยเหลือสาธารณะสำหรับ Parcelly แอปพิมพ์ฉลากจัดส่งสำหรับร้านค้าออนไลน์ขนาดเล็ก หน้าแรกมีช่องค้นหาขนาดใหญ่และหกหมวดหมู่ (เริ่มต้นใช้งาน, พิมพ์ฉลาก, ขนส่ง, การเรียกเก็บเงิน, การคืนสินค้า, การแก้ไขปัญหา) บทความมีชื่อเรื่อง บทสรุป เนื้อหาเป็น Markdown พร้อมรูปภาพและกล่องข้อความเน้น หมวดหมู่ แท็ก สถานะ (ร่าง เผยแพร่แล้ว เก็บถาวร) เจ้าของ และวันที่ตรวจทานล่าสุด หน้าบทความแสดงสารบัญ บทความที่เกี่ยวข้อง และคำถาม “บทความนี้มีประโยชน์ไหม?” แบบใช่/ไม่ใช่ พร้อมความคิดเห็นที่ไม่บังคับ การค้นหาครอบคลุมชื่อเรื่อง บทสรุป และเนื้อหา โดยให้การตรงชื่อเรื่องอยู่อันดับแรก และบันทึกทุกคำค้นพร้อมว่าได้ผลลัพธ์หรือไม่ มีพื้นที่แก้ไข (ต้องเข้าสู่ระบบ บทบาทผู้แก้ไขและแอดมิน) แสดงรายการร่าง บทความที่ไม่ได้ตรวจทานใน 180 วัน และบทความที่คะแนนช่วยเหลือต่ำ พร้อมเก็บประวัติการแก้ไข แต่ละบทความมีชื่อหน้าและคำอธิบายเมตาของตัวเองสำหรับเครื่องมือค้นหา ดีไซน์สะอาด สงบ อ่านง่าย และออกแบบสำหรับมือถือเป็นหลัก

ขั้นตอนการสร้าง

1. ลิสต์บทความ 20–30 ชิ้นแรก จากคำถามจริงของฝ่ายสนับสนุนก่อนเริ่มสร้างอะไร รายการนี้จะกำหนดหมวดหมู่
2. สร้างเว็บ และตรวจการอ่านบนโทรศัพท์ ได้แก่ ความยาวบรรทัด หัวข้อ และรูปภาพ
3. ตัวแก้ไขและบทบาท ผู้เขียนต้องเพิ่มและแก้ไขบทความได้โดยไม่ต้องถามนักพัฒนา
4. การค้นหา แล้วทดสอบด้วยคำที่ลูกค้าใช้จริง รวมถึงคำที่สะกดผิด
5. ความคิดเห็นและการบันทึกการค้นหา
6. รายงานบทความที่ล้าสมัย จากเจ้าของและวันที่ตรวจทานล่าสุด
7. พื้นฐาน SEO สำหรับเว็บสาธารณะ: ชื่อเรื่องและคำอธิบายที่ไม่ซ้ำ URL ที่สะอาด และแผนผังเว็บไซต์ ดูSEO สำหรับเว็บไซต์ที่สร้างด้วย AI
8. ลิงก์จากผลิตภัณฑ์และคำตอบของฝ่ายสนับสนุน แล้วดูบันทึกที่ไม่มีผลลัพธ์ทุกสัปดาห์
9. คำตอบจาก AI เมื่อเนื้อหาแน่นแล้ว

ข้อผิดพลาดที่พบบ่อย

• จัดตามแผนก แทนที่จะจัดตามสิ่งที่ผู้อ่านพยายามทำ
• บทความยาวที่ครอบคลุมห้างาน บทความหนึ่งควรมีหนึ่งงาน พร้อมชื่อที่บอกว่าแก้ปัญหาอะไร
• ไม่มีเจ้าของสำหรับแต่ละบทความ ไม่มีใครอัปเดตอะไรเลย และความเชื่อถือจะลดลงหลังจากคำตอบผิดครั้งแรก
• บันทึกภายในในบทความสาธารณะ ใช้การมองเห็นแยกกัน และตรวจทานก่อนเผยแพร่
• การค้นหาที่ตรงแค่ชื่อเรื่อง ผู้อ่านพิมพ์อาการ ไม่ได้พิมพ์ชื่อบทความ
• ภาพหน้าจอที่ไม่มี alt text หรือบริบท ภาพจะล้าสมัยเร็ว ให้อธิบายขั้นตอนด้วยคำพูดควบคู่กันไปด้วย

เมื่อไรที่ผลิตภัณฑ์สำเร็จรูปดีกว่า

ถ้าทีมของคุณทำงานในเครื่องมือเอกสารหรือวิกิอยู่แล้ว ฐานความรู้ภายในในเครื่องมือนั้นมักเป็นทางที่ง่ายที่สุด เปรียบเทียบ Notion กับ Confluence ครอบคลุมตัวเลือกยอดนิยมสองแบบ ถ้าคุณใช้ผลิตภัณฑ์ helpdesk ศูนย์ช่วยเหลือในตัวจะเชื่อมบทความกับตั๋วและแนะนำบทความให้ลูกค้า ซึ่งทำซ้ำได้ยาก ตัวสร้างเว็บเอกสารเหมาะกับเอกสารสำหรับนักพัฒนาที่เก็บคู่กับโค้ด

สร้างเองเมื่อคุณต้องการโครงสร้างหรือสิทธิ์การเข้าถึงของตัวเอง (บทความต่อลูกค้า ต่อสถานที่ หรือต่อบทบาท) ต้องการให้ฐานความรู้อยู่ในผลิตภัณฑ์ของคุณแทนที่จะเป็นเว็บแยก ต้องการขั้นตอนการตรวจทานและอนุมัติที่วิกิไม่บังคับใช้ หรือต้องการคำตอบ AI จากเนื้อหาของคุณโดยไม่ต้องมีการสมัครสมาชิกเพิ่ม มันจับคู่กับhelpdesk แบบกำหนดเองได้อย่างเป็นธรรมชาติ

สร้างกับ Mythex

บน Mythex คุณอธิบายฐานความรู้ในแชท แล้วมันจะถูกสร้างในพรีวิวสด บทความ การแก้ไข และความคิดเห็นถูกเก็บในฐานข้อมูล Postgres ที่เอเจนต์เพิ่มเมื่อจำเป็น และรูปภาพเข้าไปในที่เก็บไฟล์ของโปรเจกต์ การเข้าสู่ระบบของผู้แก้ไขใช้วิธียืนยันตัวตนที่คุณเลือก เพราะ Mythex ไม่มีการเข้าสู่ระบบสำหรับผู้ใช้ปลายทางในตัว สำหรับคำตอบ AI คุณใช้กุญแจ API ของผู้ให้บริการ AI ของคุณเอง เก็บเป็นความลับของโปรเจกต์ และค่าใช้งานจะเรียกเก็บผ่านบัญชีผู้ให้บริการของคุณ ไม่ใช่เครดิตของ Mythex (สูตร AI) แอป Mythex ใหม่เริ่มเป็นแอปหน้าเดียว React ที่เรนเดอร์ฝั่งไคลเอนต์ ซึ่งด้อยกว่าสำหรับเครื่องมือค้นหา ดังนั้นสำหรับศูนย์ช่วยเหลือสาธารณะ ให้ขอการตั้งค่าแบบ static หรือเรนเดอร์บนเซิร์ฟเวอร์ เช่น Next.js (สูตร SEO)

สำหรับพรอมต์เริ่มต้น ลองใช้เทมเพลตฮับความรู้ของผลิตภัณฑ์ หรือแอปเอกสารทีม

คำถาม