การเลือกระหว่าง OpenAI, Anthropic และ Google ควรเริ่มจากงานที่ผลิตภัณฑ์ต้องทำให้สำเร็จ ชื่อผู้ให้บริการเพียงอย่างเดียวยังกว้างเกินไป สิ่งที่ต้องนำมาเทียบคือโมเดลรุ่นใด ใช้ผ่านบริการใด ตั้งค่าอย่างไร และอยู่ภายใต้ข้อตกลงการใช้งานแบบไหน
สมมติธุรกิจจำหน่ายอุปกรณ์ต้องการผู้ช่วยรับข้อความภาษาไทยจากลูกค้าแล้วจัดทำคำขอบริการฉบับร่าง ระบบต้องรักษารหัสสินค้า แยกอาการที่ลูกค้าแจ้งออกจากสาเหตุที่ยืนยันแล้ว ถามข้อมูลที่ขาด และเตรียมช่องข้อมูลให้ทีมบริการ การตอบอ่านลื่นจึงเป็นเพียงส่วนหนึ่งของงาน อีกส่วนคือการรู้ว่าหลักฐานยังไม่พอให้สรุปอะไร
กำหนดขอบเขตผลิตภัณฑ์ก่อนเลือกโมเดล
เริ่มจากระบุข้อมูลเข้าและผลลัพธ์ที่ต้องการ ในตัวอย่างนี้ ข้อมูลเข้าอาจมีข้อความ รูปสินค้า และประวัติซื้อเฉพาะส่วนที่ผู้ใช้มีสิทธิ์เห็น ผลลัพธ์ประกอบด้วยรหัสสินค้า อาการที่แจ้ง ข้อมูลที่ยังขาด และขั้นตอนถัดไปที่เสนอ ส่วนการนัดหมายบริการจริงเป็นอีกคำสั่งหนึ่ง ซึ่งต้องมีสิทธิ์และการยืนยันแยกต่างหาก
ขอบเขตนี้ช่วยให้การทดลองยุติธรรม หากตัวเลือกหนึ่งได้รับข้อความที่จัดรูปแบบแล้ว แต่อีกตัวต้องอ่านภาพไม่ชัด หรือบางตัวค้นประวัติซื้อได้แต่บางตัวเห็นเพียงแชท ผลที่ได้ย่อมตอบไม่ได้ว่าความต่างมาจากโมเดลหรือข้อมูล ต้องแยกก่อนว่างานใดเป็นหน้าที่อ่านเอกสาร ค้นข้อมูล ใช้กฎธุรกิจ หรือให้โมเดลตีความ แล้วเทียบภายใต้หน้าที่เดียวกัน
ควรแยกบัญชีแชทที่พนักงานใช้จาก API หรือบริการที่นำมาประกอบเป็นผลิตภัณฑ์ด้วย การคิดค่าใช้จ่าย การดูแลบัญชี เงื่อนไขข้อมูล และความสามารถที่เปิดใช้อาจต่างกัน ประสบการณ์ที่พนักงานชอบในแอปแชทเป็นข้อมูลประกอบได้ แต่ยังไม่ยืนยันว่าระบบที่จะเชื่อมให้ลูกค้าใช้ผ่านเกณฑ์ของธุรกิจ
แต่ละผู้ให้บริการต้องตรวจอะไร
เอกสารเลือกโมเดลของ OpenAI ให้พิจารณาประเภทงาน คุณภาพ ความเร็ว และค่าใช้จ่าย พร้อมระบุว่าความพร้อมใช้งานและเครื่องมือขึ้นอยู่กับผลิตภัณฑ์และรุ่นโมเดล เวลาบันทึกผลทดลองจึงควรลงรุ่นและการตั้งค่าที่ใช้จริง ไม่เขียนเพียงว่าเลือก OpenAI
Anthropic มีเอกสาร Structured outputs สำหรับกำหนดรูปแบบคำตอบ พร้อมเงื่อนไขความเข้ากันได้และข้อจำกัดของ schema หากต้องสร้างข้อมูลคำขอบริการ ควรทดลองด้วยโครงสร้างข้อมูลและช่องทางเรียกใช้ที่จะนำไปใช้จริง แม้ระบบอ่าน JSON ได้สำเร็จ ก็ยังต้องตรวจว่าค่านั้นถูกต้องตามงานธุรกิจหรือไม่
คู่มือ Structured outputs ของ Google แยกเช่นกันระหว่างรูปแบบที่ถูกต้องกับค่าที่ถูกต้อง และให้แอปตรวจความหมายของผลลัพธ์เพิ่มเติม โมเดลอาจคืนรหัสสินค้าที่มีรูปแบบครบ แต่รหัสนั้นไม่มีอยู่ในแค็ตตาล็อกจริง
| ประเด็นตัดสินใจ | หลักฐานที่ควรเก็บ | สิ่งที่ยังใช้แทนกันไม่ได้ |
|---|---|---|
| ความถูกต้องของงาน | ช่องข้อมูลถูก ยอมรับเมื่อไม่แน่ใจ และเสนอขั้นตอนที่ใช้ได้ | ย่อหน้าที่อ่านดูดี |
| ภาษาไทยและอังกฤษ | ข้อความลูกค้าจริง ภาษาปน และคำย่อในงาน | ตัวอย่างทั่วไปที่แปลมา |
| การเรียกเครื่องมือ | เลือกคำสั่งและข้อมูลถูก พร้อมอ่านผลตอบกลับ | ข้อความว่าดำเนินการแล้ว |
| ความเหมาะกับผลิตภัณฑ์ | รูปแบบข้อมูล สิทธิ์ บริการที่ใช้ และข้อตกลงข้อมูล | รายการความสามารถกว้าง ๆ |
| ภาระหลังเปิดใช้ | เวลารอ ความล้มเหลว งานตรวจ และการกู้สถานะ | ราคา Token เพียงอย่างเดียว |
เกณฑ์เหล่านี้ใช้กับทั้งสามผู้ให้บริการ ไม่ได้หมายความว่ารายใดชนะในหมวดใดเสมอ โมเดลและความสามารถเปลี่ยนได้ แต่การทดลองควรทำซ้ำเพื่อเทียบกับผลเดิมได้
ออกแบบการทดลองให้พบข้อผิดพลาดได้จริง
เลือกคำขอเก่าที่มีสิทธิ์นำมาใช้และครอบคลุมงานหลัก พร้อมตัดข้อมูลส่วนบุคคลที่ไม่จำเป็นออก อย่าเลือกเฉพาะคำถามสะอาด ควรมีภาพไม่ชัด รหัสสินค้าขัดกัน ประวัติซื้อที่หาไม่พบ และคำขอที่อยู่นอกหน้าที่ระบบ ให้ทีมบริการกำหนดผลลัพธ์ที่ยอมรับได้ก่อนเห็นคำตอบของโมเดล
แยกชุดสำหรับปรับระบบกับชุดที่เก็บไว้ทดสอบ ชุดแรกใช้แก้คำสั่งและคำอธิบายเครื่องมือ ส่วนชุดหลังใช้ดูว่าการปรับนั้นช่วยกับข้อมูลที่ยังไม่เคยใช้จริงหรือไม่ หากปรับตามตัวอย่างทุกชิ้นจนจำรูปแบบได้ ผลทดลองอาจดูดีเกินการใช้งานจริง
รอบแรกให้ข้อมูลและข้อกำหนดผลลัพธ์เทียบเคียงกัน จากนั้นจึงเปิดให้ปรับการตั้งค่าของแต่ละตัวเลือกอย่างเหมาะสมและบันทึกไว้ พารามิเตอร์ชื่อคล้ายกันอาจไม่ได้มีความหมายตรงกันทุกบริการ ความยุติธรรมจึงไม่ใช่การบังคับทุกค่าต้องเหมือนกัน เก็บทั้งผลตั้งต้นและผลหลังปรับ เพื่อเห็นว่าประโยชน์เพิ่มมาจากส่วนไหน
ถ้าทำได้ ให้ผู้ตรวจอ่านคำตอบโดยไม่เห็นชื่อผู้ให้บริการ บันทึกชนิดข้อผิดพลาดแยกจากคะแนนรวม การจัดรูปแบบไม่ตรงเล็กน้อยกับการนัดบริการผิดบัญชีลูกค้าไม่ควรถูกเฉลี่ยจนดูเท่ากัน กรณีสำคัญควรทดลองซ้ำเพื่อดูความแปรปรวน ไม่สรุปจากคำตอบที่ถูกเพียงครั้งเดียว
คิดต้นทุนต่อหนึ่งงานที่ทีมยอมรับได้
สำหรับธุรกิจตัวอย่าง หน่วยที่มีความหมายคือคำขอบริการที่ทีมรับไปทำต่อได้ภายใต้ระดับการตรวจที่กำหนด ต้นทุนจึงรวมการเรียกโมเดล อ่านเอกสาร ค้นข้อมูล ใช้เครื่องมือ ลองใหม่ และเวลาที่คนใช้แก้ข้อผิดพลาด คำตอบที่มีค่าเรียกต่ำอาจสร้างงานเพิ่ม หากทีมต้องกลับไปถามลูกค้าใหม่หลายรอบ
วัดเวลาที่ผู้ใช้รอครบกระบวนการด้วย รวมทั้งการค้นข้อมูลและระบบปลายทาง ควรดูทั้งเวลาปกติและกรณีที่ช้าเมื่อมีผู้ใช้พร้อมกัน หากระบบประวัติซื้อหมดเวลาบ่อย การเปลี่ยนโมเดลอย่างเดียวจะไม่แก้คอขวดนั้น
ผู้ให้บริการสำรองต้องถือเป็นอีกการตั้งค่าหนึ่งที่ต้องทดสอบ ตรวจว่าส่งข้อมูลเดียวกันไปได้ภายใต้ข้อตกลงหรือไม่ และผลลัพธ์ผ่านเกณฑ์เดียวกันหรือไม่ หากคำสั่งนัดหมายถูกส่งไปแล้วแต่ไม่ได้รับคำตอบกลับ ต้องตรวจสถานะให้แน่ชัดก่อนลองผ่านระบบสำรอง มิฉะนั้นอาจสร้างรายการซ้ำทั้งที่โมเดลทั้งสองทำตามคำสั่งถูกแล้ว
เก็บเหตุผลการเลือกไว้ใช้ตอนรุ่นเปลี่ยน
บันทึกบริการ รุ่น การตั้งค่า วันที่ทดลอง รุ่นชุดข้อมูล ข้อผิดพลาดที่ยอมไม่ได้ และผู้รับผิดชอบทบทวนให้ครบ อธิบายว่าตัวเลือกนี้เหมาะกับงานตรงไหน ยังมีข้อจำกัดใด และเหตุการณ์ใดต้องทดสอบใหม่ เช่น โมเดลเปลี่ยน รูปแบบเอกสารใหม่ หรือกฎบริการของธุรกิจเปลี่ยน
การใช้หลายโมเดลทำได้เมื่อมีกฎแบ่งงานและผลทดลองรองรับ งานดึงช่องข้อมูลที่ตรงไปตรงมาอาจต้องการต่างจากงานตรวจหลักฐานขัดกัน แต่ควรมีระบบตั้งต้นที่วัดผลได้ก่อน เพื่อให้การเพิ่มเส้นทางใหม่มีประโยชน์ชัดเจนและไม่ซ่อนความซับซ้อนเพิ่ม
หากกำลังวางเครื่องมือให้ทั้งทีม อ่านต่อเรื่องพื้นที่ทำงาน AI กลาง ส่วนธุรกิจที่ยังตัดสินใจว่าจะซื้อหรือสร้าง สามารถใช้กรอบเลือกซอฟต์แวร์สำเร็จรูป เชื่อมต่อ หรือพัฒนาเอง ประกอบได้
Talvyn Labs ช่วยเปลี่ยนคำขอจริงของธุรกิจให้เป็นชุดทดลองโมเดลและขอบเขต AI Product ที่เดินหน้าพัฒนาได้ นำตัวอย่างข้อมูลกับผลลัพธ์ที่ทีมต้องยอมรับมาเริ่มวางเกณฑ์ เชื่อมข้อมูลที่จำเป็น และสร้างขั้นตอนทำงานรอบโมเดลที่เลือก รวมถึงกรณีที่ต้องส่งให้คนตัดสินใจ
เลือกโมเดลให้ตรงงาน แล้วสร้าง AI Product ที่ใช้ได้จริง
ให้ Talvyn Labs นำตัวอย่างงานของคุณมาทดสอบผู้ให้บริการ วางเกณฑ์รับผล และพัฒนาระบบที่เชื่อมข้อมูลกับเครื่องมือของธุรกิจ
เริ่มพัฒนา AI Product จากงานของคุณ