สร้างผลิตภัณฑ์ AI ให้ใช้งานได้จริง: คู่มือสำหรับทีมที่เริ่มต้น

เริ่มจากงานเดียวที่แคบและวัดผลได้

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

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

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

ข้อมูลพร้อมแค่ไหน ตรวจก่อนลงมือ

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

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

สร้างชุดทดสอบ (evaluation set) ก่อนปรับอะไรทั้งนั้น

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

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

สิ่งที่วัดไม่ได้ ก็ปรับให้ดีขึ้นไม่ได้เช่นกัน มีแต่ความรู้สึกว่าดีขึ้น

ให้คนอยู่ในลูป และออกแบบจุดที่คนเข้ามาตรวจ

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

UX ของจุดตรวจสำคัญพอ ๆ กับโมเดล ถ้าคนต้องอ่านยาวหรือหาที่มาเอง เขาจะกดอนุมัติโดยไม่อ่านภายในสัปดาห์ที่สอง ลองแสดงแหล่งอ้างอิง ไฮไลต์ส่วนที่โมเดลไม่มั่นใจ และทำให้การแก้ไขใช้เวลาไม่กี่วินาที เมื่อระบบแม่นยำสม่ำเสมอแล้วค่อยพิจารณาให้บางหมวดงานผ่านอัตโนมัติ โดยยังสุ่มตรวจต่อเนื่อง

ต้นทุนและความเร็ว คำนวณตั้งแต่ก่อนปล่อย

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

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

ปล่อยทีละขั้น และเฝ้าดูหลังปล่อย

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

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