วิธีสร้างแชทบอท: สถาปัตยกรรม, ข้อมูล, ความปลอดภัย, และการประเมินผล

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

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

ประเด็นสำคัญ

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

กำหนดงานก่อนเลือกโมเดล

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

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

ใช้สถาปัตยกรรมแบบชั้นหลายระดับ

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

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

ออกแบบการสนทนา, ความรู้, และการรับมือและกลับสู่การทำงานเมื่อเกิดปัญหาร่วมกัน

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

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

ประเมินและดำเนินการระบบทั้งหมด

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

กำหนดเวอร์ชันของพรอมต์, ดัชนี, โมเดล, นโยบาย, และเครื่องมือ ตรวจสอบการสนทนาตัวอย่างด้วยการควบคุมความเป็นส่วนตัว, เฝ้าดูการเปลี่ยนแปลงของข้อมูลหรือพฤติกรรมและรูปแบบความล้มเหลวที่เกิดซ้ำ พร้อมเตรียมการย้อนกลับเวอร์ชัน ระเบียบปฏิบัติการนี้เชื่อมการพัฒนาแชทบอทกับ AIOps และการตอบสนองต่อเหตุการณ์

ส่วนประกอบหลักของแชทบอทโดยละเอียด

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

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

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

การดึงข้อมูล, เครื่องมือ, และการทำธุรกรรม

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

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

ธุรกรรมต้องการการยืนยันในจุดที่ยืนยันดำเนินการจริง แสดงฟิลด์สำคัญให้ผู้ใช้เห็น—ผู้รับ, จำนวน, ที่อยู่, วันที่, หรือการเปลี่ยนแปลงการเข้าถึง—และไม่ถือว่า ‘ใช่’ เก่าเป็นการอนุมัติสำหรับการกระทำใหม่ สำหรับงานหลายขั้นตอน, เก็บระบบจัดการสถานะ (state machine) ไว้นอกโมเดลเพื่อให้การลองใหม่หรือข้อความที่จัดลำดับใหม่ไม่ข้ามขั้นตอนตรวจสอบที่จำเป็น

แผนการสร้างและประเมินผลเชิงปฏิบัติ

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

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

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

ตัวอย่างการทำงาน: แชทบอทสนับสนุนตั้งแต่ต้นแบบจนถึงการผลิต

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

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

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

รายการตรวจสอบการนำไปใช้เชิงปฏิบัติ

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

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

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

คำถามที่พบบ่อย

แชทบอทจำเป็นต้องใช้โมเดลภาษาขนาดใหญ่หรือไม่?

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

ควรทดสอบอะไรบ้างก่อนการเปิดตัว?

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

แหล่งอ้างอิงหลัก

• Rasa: สถาปัตยกรรมแพลตฟอร์ม
• NIST AI 600-1: โปรไฟล์ Generative AI
• OWASP: 10 อันดับแรกสำหรับแอปพลิเคชัน LLM