ผมเคยศึกษา Conversation Design เยอะมาก พยายามจะนำมาทำ ChatBot โดยเฉพาะกับ Google DialogFlow แต่สุดท้ายก็ยอมแพ้ เพราะการออกแบบบทสนทนาที่มีคุณภาพนั้นยากสุด ๆ แค่ทำ Flow การซื้อของง่าย ๆ ก็ยากแล้ว เพราะ path ที่เกิดขึ้นได้นั้นมันเยอะมาก
แค่การทำให้มันรู้จักคำทักทายทุกแบบก็เหนื่อยแล้ว ‘What’s up’ ‘Hi there’ ‘Hello’ ‘สวัสดี’ ‘สวัสดีครับ’ ‘หวัดดี’ ‘ว่าไง’ … และอีกเยอะมาก
แต่พอมี LLM (Large Language Models) เกิดขึ้น ความฝันนั้นกลับมาอีกครั้ง!🤩 มันทำให้เราสามารถกำหนด branding ได้อย่างชัดเจน ว่าเราอยากให้มันตอบแบบสุภาพ หรือแม้แต่ตอบแบบหมา (“มนุษย์! ชอบสินค้าของเราไหม”) เราก็สามารถกำหนดได้หมด! ความสนใจที่กลับมาทำให้ผมเริ่มทำ DealDroid อย่างจริงจัง
แต่การเริ่มต้นใหม่นี้มากับความท้าทายใหญ่มาก นั่นคือ ‘LLM เป็น High-Uncertainty System’ หลายคนเรียกว่า “โรงงานผลิตบั๊ก” 😫 ไม่เหมือนระบบคอมพิวเตอร์แบบเดิมที่ input เดียวกันจะได้ output เดียวกันเสมอ แต่ AI นั้นต่างออกไป! มันทำงานใน ‘พื้นที่สีเทา’ ที่ยากมากสำหรับเราที่จะควบคุม ดังนั้น Conversation Design ในยุคนี้ ไม่ใช่แค่การออกแบบบทสนทนาที่สวยงาม แต่คือการ ป้องกันความไม่แน่นอนนี้! 💪
วันนี้อยากเริ่มแชร์เรื่อง Conversation Design โดยเน้นเรื่อง Guard Rails ซึ่งเป็นแนวทางที่พัฒนามาจากการทำ AI Research ที่ผมทำอยู่ เพราะถ้าเราอยากให้พ่อค้าแม่ค้าเชื่อใจ Bot เราต้องกำหนด Guard Rails สำหรับปัญหาต่าง ๆ หลักการที่ได้ผลดีที่สุดที่เราใช้แก้ Hallucination คือเทคนิค ‘Validate-before-Response’ หรือที่หลายคนเรียกว่า ‘2-Agent Check’! 🚀
อธิบายง่าย ๆ คือเราให้ Agent 1 generate คำตอบตาม role-play ที่กำหนด แต่ก่อนส่งให้ลูกค้า เราจะส่งคำตอบนั้นไปให้ Agent 2 ตรวจสอบความถูกต้องตาม context และ rules ที่เราตั้งไว้ ถ้าผิด Agent 2 จะบอก Agent 1 ว่าทำไมผิด และ Agent 1 ต้องหาคำตอบใหม่ หลักการนี้แหละที่ทำให้คุณภาพของบทสนทนาดีขึ้นอย่างมาก
นี่คือ Guard Rails เฉพาะที่ผมใช้:
AI มี knowledge base ของตัวเอง มันเลยมีราคาคร่าว ๆ อยู่ในหัว ถ้ามีคนถาม และราคาไม่ได้อยู่ใน Prompt AI จะแต่งราคาขึ้นมาเอง โดยเฉพาะเมื่อลูกค้าถามซ้ำซาก และเราสั่ง AI ให้พยายามตอบ ตัวอย่างเช่น การตั้ง primary task ใน prompt ตอนต้นว่า:
“You are a sales expert. Your primary task is to analyze the user’s message and all provided context, then generate a natural conversational response to keep the response concise and natural for a chat message.”
ดูแล้วดีนะ ใช้เทคนิค Role Play ใน Prompt Engineering แต่ปัญหาคือเมื่อลูกค้ายืนกราน “ราคาเท่าไหร่!!!” Bot จะพยายาม analyze และ Keep response (เพราะมันเป็น Primary task) จนอาจพูดราคาที่ผิดออกมา
วิธีแก้ไม่ใช่แก้ที่ Prompt ตัวแรก แต่คือส่งคำตอบไปให้ AI ตัวที่สอง (บางคนเรียกว่า Agent อีกตัว) AI ตัวที่สองไม่มีหน้าที่ generate text มีหน้าที่แค่ verify text ถ้าผิดก็จะ flag ว่าทำไมผิด และส่งกลับไปให้ AI ตัวแรกหาคำตอบใหม่
อันนี้คล้ายข้อแรกมาก แต่มักเกิดความผิดพลาดเมื่อลูกค้าอ้างว่าร้านมี Promotion แบบนั้นแบบนี้ Bot ที่พยายามช่วยเหลือและตอบสนอง จะเล่นตามและยืนยัน Promotion นั้น บางทีถึงขั้นคำนวณส่วนลดให้ ถึงแม้เราจะระบุใน Prompt อย่างเข้มงวดว่าห้ามพูดถึง promotion ที่ไม่ได้ระบุไว้ แต่พอลูกค้ายืนยันว่ามี Bot ก็จะถือว่าคำกล่าวอ้างนั้นเป็น context ที่ถูกต้อง
วิธีแก้ก็เหมือนเดิม โยนไปให้ AI ตัวที่สอง แต่คครั้งนี้ AI มีบทบาทเดียวคือตรวจสอบ ตัวอย่างเช่น:
Set "has_hallucinated_content" to true when you find:
- บริการจัดส่ง/ขนส่ง หรือนโยบายที่ไม่ได้กล่าวถึงใน Context
- การรับประกัน หรือนโยบายการคืนสินค้าที่เกินกว่าที่ระบุใน Context
- โปรโมชั่น ส่วนลด หรือข้อเสนอพิเศษที่ไม่ได้กล่าวถึงใน Contextในกรณีนี้ ผมสั่งให้ AI ตัวที่สอง return JSON file บอกมันว่าเมื่อไหร่ต้อง flag ว่าเป็น hallucinated content และเราส่ง content ที่ AI ตัวแรกตัดสินใจไปให้ตรวจสอบ
อันนี้ยากมากสำหรับคนที่สร้าง bot โดยเฉพาะเมื่อเรา ไม่สามารถเช็ค stock แบบ real-time ตลอดเวลา เราต้องเตรียมคำตอบสำรองไว้สำหรับเมื่อลูกค้าถาม และถ้าลูกค้ายืนกราน (พยายามบังคับให้ Bot ตอบ) เราต้องมีคำตอบที่เตรียมไว้สำหรับสถานการณ์ที่ถูกบังคับเหล่านี้ด้วย
ตัวอย่างของ Hallucination:
"เหลืออีกแค่ 3 ถุง!" -> ถ้าไม่มีข้อมูล stock แต่ลูกค้าบังคับให้ตอบ
"Limited edition" -> ถ้าถามเรื่อง limitation bot จะพยายามขาย
และการบอกว่ามันจำกัดอาจเพิ่มยอดขาย
"สินค้าหมด" -> เพราะ bot เข้าใจว่า "discontinued" คือ "ไม่มีสต็อก"ปัญหาไม่ได้อยู่แค่จำนวน แต่ยังเกี่ยวกับสินค้า Limited Edition ที่ Bot อาจเข้าใจผิดว่าคำถามทั่วไปเป็นคำถามเกี่ยวกับสต็อก และให้คำตอบผิดโดยอ้างอิงสต็อก หรือถ้าสินค้าถูก discontinued แต่เรายังขาย เราต้องกำหนดว่า Bot ควรตอบอย่างไร และควรแนะนำสินค้าทางเลือกอะไร
อีกวิธีที่เป็นไปได้คือส่งต่อบทสนทนาให้เจ้าหน้าที่คน เมื่อลูกค้าถามเรื่องสต็อก Bot สามารถตอบว่า “ไม่แน่ใจนะครับ ให้ตรวจสอบกับทีมก่อน” แล้วส่งอีเมลให้เจ้าหน้าที่เข้ามารับเคสต่อ
อันนี้สนุกดี โดยเฉพาะกับความหลากหลายของภาษาใน SEA คุณอาจได้ภาษาจีน ญี่ปุ่น หรือแม้กระทั่งไทยผสมลาวในคำตอบ เช่น:
อย่างไรก็ตาม เราไม่สามารถให้มันเช็คแค่ภาษาเดียว เพราะการผสมไทยกับอังกฤษเป็นเรื่องปกติ:
ดังนั้น เราต้องอนุญาตให้ใช้ Borrowed Words ได้ นอกจากนี้ ถ้าลูกค้าเริ่มใช้คำเหล่านี้ การตอบตามจะทำให้การสื่อสารดีขึ้น Guard Rail ต้องมีเงื่อนไขที่ละเอียด และ ทดสอบหนัก ๆ เพื่อจัดการกับสถานการณ์เหล่านี้อย่างถูกต้อง
ต้องยอมรับว่าไม่ง่ายเพราะปัจจัยหลายอย่าง AI จะตัดสินใจอย่างไรว่าใครเป็นคู่แข่ง? ตัวอย่างเช่น ถ้าเราเปรียบเทียบ DJI กับ GoPro, Bot อาจเห็น DJI เป็นโดรน และ GoPro เป็นกล้อง วางไว้คนละโดเมน หรืออาจเห็นว่า GoPro สามารถติดกับ DJI ได้ ทำให้เป็นสินค้าเสริม หรือแม้แต่สมมติว่า GoPro เป็นสินค้าของเราเอง ทั้งที่เราอยากให้ GoPro ถูกมองว่าเป็นคู่แข่ง เพราะ DJI ก็ขายกล้องเหมือนกัน
วิธีแก้คือต้องกำหนดว่าใครคือคู่แข่งของเรา และบอก Bot อย่างชัดเจนไม่ให้พูดถึงพวกเขา แต่ระวัง ถ้าลูกค้าขอเปรียบเทียบ Bot จะอยู่ในจุดที่ยาก: เราห้ามพูดถึง แต่ลูกค้าอยากให้พูดถึง และ Bot มักจะให้ความสำคัญกับลูกค้ามากกว่า ดังนั้น เราต้องกำหนด safe landing ให้ Bot
เราต้องสั่งให้มันรู้ว่าจะพูดถึงคู่แข่งอย่างไร ถ้าจำเป็นต้องพูด
นอกจากนี้ยังมีรายละเอียดอย่าง การกำหนด “Forbidden Topics” และการทำให้แน่ใจว่า “remove white space” (ซึ่งเป็นรายละเอียดเล็ก ๆ ที่ปรับปรุงคุณภาพบทสนทนา) รวมถึงการจบประโยคด้วยคำถาม หรือการผลักดันลูกค้าไปสู่ Conversion ถัดไปใน Marketing Funnel
และถ้าเราอยากให้ Guard Rails ไม่ใช่แค่ป้องกันข้อผิดพลาด แต่แนะนำการแก้ไข นั่นก็เป็นความท้าทายที่สนุก เพราะเราไม่ต้องการให้มันคิดคำตอบใหม่ แค่แก้ไขข้อความที่มีอยู่ ซึ่งต้องการเงื่อนไขที่แตกต่างจากตอน generate ข้อความครั้งแรก (จะแชร์เรื่องนี้ทีหลัง)
Conversation Design สนุกไม่แพ้การออกแบบ UI หรือการเป็น UX Writer! เพราะทุกครั้งที่เราแก้ ‘Guard Rail’ มันเหมือนการปรับปรุง UX ของบทสนทนาอย่างต่อเนื่อง
ความท้าทายที่ใหญ่ที่สุดคือความไม่แน่นอนของ AI แต่นั่นแหละที่บังคับให้เรา Empathy AI 🧠 เราต้องยอมรับว่า ‘AI ไม่สามารถไว้ใจได้ตลอดเวลา’ การตั้ง Guard Rails จะช่วยให้ทีมเชื่อใจ Bot มากขึ้นอย่างแน่นอน
✨ สรุป: Conversation Design สำหรับ AI ที่ใช้ LLM ไม่ใช่แค่การออกแบบ ‘เส้นทางที่ถูกต้อง’ แต่ต้องรวมถึงการตั้ง ‘ขอบเขตที่ไม่ผิด’ ขอบเขตนี้ต้องไม่กว้างจนอนุญาตให้เกิดข้อผิดพลาด และไม่แคบจนจำกัดเสรีภาพของ AI… เพราะในบทสนทนาจริง สิ่งที่ไม่คาดคิดจะเกิดขึ้นได้เสมอ 😊
แล้วคุณล่ะ เจอ Hallucination อะไรบ้าง? มี Guard Rails ไหนที่ใช้แล้วได้ผลอยากจะแชร์? ผมกำลังสนุกกับการศึกษา Conversation Design และเรียนรู้อยู่ตลอด แนะนำแหล่งข้อมูลดี ๆ ได้นะครับ!
Product Vision
"Experience is in the detail"