ผู้ช่วยตอบจากคลังความรู้องค์กร (RAG)

งานส่วนใหญ่อยู่ที่เอกสาร ไม่ได้อยู่ที่ตัวโมเดล

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

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

• รวบรวมเอกสารจากไดรฟ์ที่แชร์กัน อีเมล และระบบเอกสารเดิม
• อ่านไฟล์สแกนด้วย OCR และตัดส่วนที่ซ้ำทุกหน้าออก
• ตัดเป็นท่อนที่จบความในตัวเอง พร้อมติดชื่อเอกสารและหัวข้อ
• แปลงเป็นเวกเตอร์ (embedding) สำหรับค้นตามความหมาย
• วางรอบปรับปรุงดัชนี และวิธีปลดเอกสารฉบับที่ยกเลิกแล้ว

คำตอบที่ตรวจสอบไม่ได้ ก็ยังใช้งานจริงไม่ได้

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

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

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

ไม่ใช่ทุกคนควรค้นเจอทุกเอกสาร

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

โดยปกติเราสืบทอดสิทธิ์จากระบบต้นทางที่องค์กรใช้อยู่แล้ว ทั้งระดับโฟลเดอร์ ฝ่าย หรือโครงการ เพื่อไม่ให้เกิดตารางสิทธิ์ชุดที่สองที่ต้องมาไล่ดูแลแยกกัน และเก็บบันทึกไว้ว่าใครถามอะไร ระบบหยิบเอกสารใดมาตอบ เจ้าของข้อมูลจึงย้อนตรวจได้ ทั้งหมดนี้เป็นเรื่องเดียวกับ PDPA และการกำกับดูแลข้อมูล ซึ่งต้องคิดตั้งแต่วันออกแบบ ไม่ใช่ตามมาทีหลัง

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

อยู่ในช่องทางที่คนใช้อยู่แล้ว

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

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

• ใช้งานผ่าน LINE OA และ Web Chat บนเว็บไซต์หรืออินทราเน็ต
• ผูกบัญชี LINE กับบัญชีพนักงาน สิทธิ์ทำงานเหมือนกันทุกช่องทาง
• กดลิงก์เปิดเอกสารต้นทางได้จากในแชท
• ส่งต่อให้เจ้าหน้าที่ในห้องแชทเดิมเมื่อระบบตอบไม่ได้