AI ซื้อมาหลายอย่างแต่ก็ยังใช้งานไม่ได้: ระบบพนักงานดิจิทัลออกแบบและพัฒนาอย่างไร

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

เริ่มต้นด้วยการแยกแยะให้ชัดเจนว่า ทำไมหน้าต่างแชทจึงไม่สามารถทำหน้าที่เป็นตำแหน่งงานได้

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

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

ตรรกะทางธุรกิจ: ในระบบควรมีวัตถุอย่างน้อยเจ็ดประเภท

เมื่อสร้างระบบพนักงานดิจิทัล ควรเริ่มต้นด้วยการระบุวัตถุทางธุรกิจลงในข้อกำหนด ก่อนจะพูดถึงการเลือกโมเดล

1. แฟ้มประวัติของตำแหน่งงาน: ชื่อหรือชื่อตำแหน่ง หมายเลขประจำตัว หน้าที่ความรับผิดชอบ สถานะออนไลน์ และผู้รับบริการ หากไม่มีแฟ้มประวัติ ก็ไม่มีที่มาสำหรับกำหนดสิทธิ์และการประเมินผลงาน
2. พรมแดนความสามารถ: สามารถอ่านเอกสารใดได้ เขียนฟิลด์ใดได้ และไม่สามารถรับปากอะไรได้ พรมแดนเหล่านี้ควรสามารถปรับเปลี่ยนได้โดยผู้ดูแล ไม่ใช่ถูกกำหนดตายตัวไว้ในคำสั่งเริ่มต้น
3. SOP / ทักษะเชิงกระบวนการ: แยกกระบวนการที่ซับซ้อนออกเป็นขั้นตอน รองรับการแตกแขนงตามเงื่อนไข การเรียกใช้เครื่องมือ การค้นหาความรู้ และการส่งต่อไปยังมนุษย์
4. องค์ความรู้: แยกหัวข้อ กฎเกณฑ์ แหล่งที่มา และคู่มือการปฏิบัติไว้ต่างหาก การตอบคำถามต้องสามารถอ้างอิงแหล่งที่มาได้ และการค้นหาต้องสามารถปรับแต่งได้
5. การเชื่อมต่อเครื่องมือ: อินเทอร์เฟซ HTTP หรือ MCP เพื่อตรวจสอบวงเงิน สร้างเอกสาร หรือปรับเปลี่ยนสถานะ ไม่ใช่แค่สร้างข้อความเพียงอย่างเดียว
6. งานตามกำหนดเวลา: รายงานประจำวัน งานติดตามที่ล่าช้า และการตรวจสต็อก เป็นงานที่ต้องทำเป็นระยะ ๆ ไม่ควรรอให้ผู้ใช้เริ่มพูดก่อน
7. Trace และการรับฟีดแบ็ก: บันทึกเส้นทาง ขั้นตอน เครื่องมือ ความรู้ และคำตอบ; คะแนนชื่นชมหรือคำติชม รวมถึงการรับช่วงต่อโดยมนุษย์ จะถูกนำเข้าสู่กระบวนการปรับปรุงรอบถัดไป

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

ตรรกะการออกแบบ: บทบาท สถานะแมชชีน และการแบ่งระดับความรู้

วิธีแบ่งบทบาท

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

ใช้สถานะแมชชีนกับ SOP ไม่ใช่แค่อาศัยความทรงจำจากการสนทนา

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

อย่าทำให้ความรู้เป็นเหมือนสุ่มผสม

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

การพัฒนาสู่การใช้งานจริง: อินเทอร์เฟซ การแยกตัว การเฝ้าระวัง และการตรวจรับ

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

• ช่องทางการดำเนินงาน: กระแสแบบซิงโครนัสเหมาะสำหรับการสนทนา ขณะที่ Run + กระแสเหตุการณ์แบบอะซิงโครนัสเหมาะสำหรับการเชื่อมต่อหลังจากขาดการเชื่อมต่อและคิวงาน ทั้งสองใช้แกนกลางเดียวกัน
• ตัวตนของช่องทาง: WeChat, Enterprise WeChat, Feishu และ DingTalk สามารถใช้เป็นทางเข้าได้ แต่ตัวตนของพนักงาน บทสนทนา และ Trace ต้องเป็นเอกภาพ ห้ามให้แต่ละช่องทางสร้างความทรงจำของตนเอง
• ความปลอดภัย: การกำหนดค่าโมเดลอ้างอิงเฉพาะหมายเลขการกำหนดค่าที่มีอยู่ ไม่ส่งคืนรหัสลับของซัพพลายเออร์ ผลลัพธ์จากเครื่องมือเมื่อเข้าสู่ Trace ต้องผ่านการลบข้อมูลส่วนบุคคล
• ความช่วยเหลือโดยมนุษย์: กรณีล่าช้า ความน่าเชื่อถือต่ำ ละเมิดสิทธิ์ และผู้ใช้ขอเปลี่ยนเป็นมนุษย์เอง ทั้งสี่กรณีต้องสามารถส่งต่อบริบทได้อย่างครบถ้วน

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

ลำดับการเปิดใช้งาน: เริ่มด้วยงานซ้ำชุดหนึ่ง

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

วิธีวัดว่าการออกแบบทำถูกต้องหรือไม่: ช่วงที่เคยพึ่งพาการกระตุ้นจากกลุ่มหรือการกรอกแบบฟอร์ม ไม่ใช่เส้นทางหลักอีกต่อไป บันทึกการประชุม การเร่งรัด และการสรุปสามารถตรวจสอบกับเอกสารได้ สถานการณ์ที่ไม่ชัดเจนมีผู้รับผิดชอบในการยกระดับ งานที่ละเอียดอ่อนมีผู้ตรวจสอบ และสามารถตรวจสอบบันทึกได้ การประเมินว่าการพัฒนาผ่านเกณฑ์หรือไม่ ให้ดูว่าSOP เดียวกันที่ถูกขัดจังหวะสามารถกลับมาได้หรือไม่、คำตอบสามารถอ้างอิงแหล่งที่มาได้หรือไม่、กรณีพิเศษสามารถเข้าสู่รอบปรับปรุงถัดไปได้หรือไม่สามข้อนี้ผ่านแล้ว ค่อยขยายตำแหน่งงาน ซึ่งมั่นคงกว่าการวางช่องทางสนทนาไว้มากมายก่อนหน้า

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