วิธีเลือก Sampling Data เพื่อจูนโมเดลภาษา: เพิ่มคุณภาพโดยไม่เพิ่มงบเทรนเกินจำเป็น

การเลือกข้อมูลเพื่อจูนโมเดลภาษาให้คุ้ม ไม่ใช่การใส่ข้อมูลให้มากที่สุด แต่คือการเลือกชุดข้อมูลที่ตรงกับงานและจุดผิดพลาดที่ต้องแก้ก่อน หากงบจำกัดให้เริ่มจากข้อมูลที่สะอาด แยกชุดประเมินชัดเจน แล้วเลือกวิธีสุ่มตามปัญหาจริงของโมเดล
ใช้ random sampling เมื่อต้นทางมีการกระจายเหมาะสม ใช้ stratified sampling เมื่อมีกลุ่มข้อมูลไม่สมดุล และใช้ hard-example หรือ diversity sampling เมื่อพบว่าโมเดลผิดซ้ำหรือได้ข้อมูลคล้ายกันมากเกินไป
ต้นทุนของรอบจูนไม่ได้มีแค่เวลา GPU แต่รวมถึงการติดป้ายข้อมูล การตรวจสิทธิ์ข้อมูล และเวลาทีมในการตรวจผลลัพธ์ด้วย
จึงควรนิยามเป้าหมายคุณภาพและข้อผิดพลาดที่ยอมรับไม่ได้ก่อนเลือกตัวอย่างเสมอ
แพลตฟอร์มติดป้ายข้อมูล เครื่องมือ MLOps และบริการคลาวด์ GPU มีประโยชน์เมื่อทีมต้องติดตามที่มาของข้อมูล ควบคุมรอบประเมิน หรือจัดการงานที่มีหลายชุดข้อมูล
ไม่มีขนาดข้อมูลหรือเทคนิค sampling แบบเดียวที่รับประกันผลลัพธ์ดีที่สุดกับทุกงาน

ภาพรวมอย่างรวดเร็ว

• งบจำกัด: เริ่มจากลบข้อมูลซ้ำ ตรวจฉลาก และสุ่มข้อมูลที่ตรงงานจริงก่อนเพิ่มปริมาณข้อมูล
• ข้อมูลไม่สมดุล: ใช้ stratified sampling เพื่อให้กลุ่มย่อย เช่น เจตนา ภาษา หรือหมวดเอกสาร ได้รับการคัดเลือกอย่างควบคุมได้
• โมเดลผิดซ้ำ: ใช้ hard-example sampling หรือ diversity sampling หลังมีระบบประเมินที่เชื่อถือได้

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

คำตอบสั้น: เลือกชุดข้อมูลจูนโมเดลภาษาอย่างไรให้คุ้มทรัพยากร

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

เริ่มจากนิยามงาน เกณฑ์สำเร็จ และข้อผิดพลาดที่ยอมรับไม่ได้

งาน chatbot อาจต้องครอบคลุมเจตนาผู้ใช้ที่หลากหลาย งานจัดหมวดหมู่เอกสารอาจต้องระวังคลาสส่วนน้อย ส่วนงาน extraction ต้องสนใจรูปแบบข้อความที่แตกต่างกัน การระบุกรณีสำคัญเหล่านี้ทำให้ทีมสร้างชั้นข้อมูลสำหรับ stratified sampling หรือระบุ hard examples ได้ตรงจุดกว่าเดิม

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

ขนาดข้อมูลมากไม่เท่ากับคุณภาพสูงเสมอไป

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

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

ตารางเปรียบเทียบวิธีสุ่มข้อมูลและความคุ้มค่าของแต่ละแบบ

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

Random sampling เหมาะเมื่อใด

Random sampling เหมาะเมื่อข้อมูลต้นทางมีการกระจายที่เหมาะสม และทีมต้องการชุดข้อมูลตัวแทนโดยใช้ขั้นตอนที่เรียบง่าย วิธีนี้ช่วยลดภาระการคัดเลือกด้วยมือ และเหมาะเป็นจุดเริ่มต้นของการทดลองหลายแบบ

ข้อจำกัดสำคัญคือ random sampling ไม่รับประกันว่ากลุ่มย่อยที่พบไม่บ่อยจะถูกเลือกเพียงพอ หากงานมีเจตนาบางประเภท ภาษาบางกลุ่ม หรือเอกสารบางโดเมนที่มีความสำคัญสูง ควรตรวจสัดส่วนหลังสุ่มทุกครั้ง

Stratified sampling สำหรับข้อมูลไม่สมดุล

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

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

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

Hard-example และ diversity sampling สำหรับรอบปรับปรุงคุณภาพ

Hard-example sampling มุ่งเลือกตัวอย่างที่โมเดลทำผิดหรือมีความไม่แน่นอนสูง เหมาะกับรอบที่ทีมมีผลประเมินเดิมอยู่แล้ว และต้องการใช้ทรัพยากรกับจุดที่มีโอกาสปรับปรุงมากกว่าเดิม

อย่างไรก็ตาม วิธีนี้ต้องอาศัย ระบบวัดผลหรือรอบประเมินที่เชื่อถือได้ หากเกณฑ์วัดไม่ชัด ทีมอาจเลือกข้อมูลที่ดูยากแต่ไม่เกี่ยวกับเป้าหมายของผลิตภัณฑ์

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

ขั้นตอนคัดเลือกข้อมูลก่อนจูนโมเดลภาษา

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

ตรวจข้อมูลซ้ำ ข้อมูลปนเปื้อน และคุณภาพฉลาก

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

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

แยก train, validation และ test เพื่อวัดผลอย่างน่าเชื่อถือ

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

ควรเก็บเหตุผลว่าทำไมตัวอย่างหนึ่งจึงอยู่ใน train, validation หรือ test โดยเฉพาะเมื่อใช้ stratified, hard-example หรือ diversity sampling วิธีนี้ช่วยให้การเปรียบเทียบรอบทดลองมีความหมายมากขึ้น

บันทึกเหตุผลการเลือกข้อมูลเพื่อทำซ้ำและตรวจสอบได้

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

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

จุดผิดพลาดที่ทำให้งบ GPU เพิ่ม แต่โมเดลไม่ดีขึ้น

งบคลาวด์ GPU มักเพิ่มจากการเทรนซ้ำที่ยังไม่ได้แก้ต้นเหตุของปัญหา ก่อนขยายชุดข้อมูลหรือเพิ่มรอบเทรน ควรย้อนดูคุณภาพข้อมูล การรั่วของชุดประเมิน และความตรงกันระหว่างชุดเทรนกับงานจริงก่อน

เพิ่มข้อมูลที่ซ้ำหรือไม่ตรงกับงานจริง

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

ทำ oversampling จนโมเดลจำรูปแบบเดิม

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

วัดผลด้วยชุดทดสอบที่รั่วจากข้อมูลเทรน

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

เลือกแนวทางตามประเภทงานและขนาดทีม

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

Chatbot และงานตอบคำถามที่ต้องครอบคลุมเจตนาหลากหลาย

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

ควรแยกกรณีที่ผิดเพราะข้อมูลไม่พอ ออกจากกรณีที่คำสั่งไม่ชัดหรือฉลากไม่สอดคล้องกัน เพราะแต่ละปัญหาอาจต้องแก้ด้วยวิธีต่างกัน

งานจัดหมวดหมู่เอกสารที่มีคลาสส่วนน้อย

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

หากเอกสารมีเนื้อหาคล้ายกันมาก diversity sampling ช่วยลดการเลือกเอกสารที่ให้สัญญาณซ้ำเดิม และทำให้ทีมเห็นช่องว่างของข้อมูลได้ชัดขึ้น

ทีมองค์กรที่ต้องคุมข้อมูลส่วนบุคคลและงบคลาวด์

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

ค่าใช้จ่ายจริงของ GPU คลาวด์ เครื่องมือติดป้ายข้อมูล และบริการภายนอกแตกต่างตามผู้ให้บริการ ภูมิภาค สเปก และปริมาณใช้งาน จึงควรเปรียบเทียบเงื่อนไขการใช้งานและขอบเขตงานก่อนตัดสินใจ

เลือกวิธี sampling และเครื่องมือสนับสนุน: สรุปก่อนตัดสินใจ

ให้ตัดสินใจจาก คุณภาพที่ต้องการ ต้นทุนข้อมูล เวลาเทรน และความสามารถในการตรวจสอบ หากปัญหาคือข้อมูลไม่สมดุล ให้เริ่มจาก stratified sampling หากปัญหาคือโมเดลผิดในกรณีเดิมซ้ำ ๆ ให้พิจารณา hard examples และหากข้อมูลคล้ายกันมากให้ตรวจด้วย diversity sampling

เกณฑ์เปรียบเทียบค่าใช้จ่ายติดป้ายข้อมูลกับค่าเทรนบน GPU

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

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

เมื่อใดควรใช้แพลตฟอร์มติดป้ายข้อมูล MLOps หรือผู้ให้บริการภายนอก

แพลตฟอร์มติดป้ายข้อมูลเหมาะเมื่อมีผู้ทำงานหลายคน ต้องควบคุมแนวทางฉลาก หรือต้องตรวจทานความสอดคล้องเป็นระบบ เครื่องมือ MLOps เหมาะเมื่อทีมต้องติดตามเวอร์ชันข้อมูล การทดลอง และผลประเมินข้ามหลายรอบ

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

เช็กลิสต์สุดท้ายก่อนเริ่ม fine-tuning

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

เกณฑ์การเลือกและสรุปเปรียบเทียบ

เลือก random sampling เมื่อข้อมูลต้นทางกระจายเหมาะสมและต้องการเริ่มอย่างเรียบง่าย
เลือก stratified sampling เมื่อเจตนา ภาษา โดเมน หรือคลาสมีสัดส่วนไม่สมดุล
เลือก hard-example sampling เมื่อมีผลประเมินที่เชื่อถือได้และรู้ว่าโมเดลพลาดกรณีใดบ่อย
เลือก diversity sampling เมื่อข้อมูลซ้ำหรือคล้ายกันมากจนความครอบคลุมยังไม่ดี
เลือกเครื่องมือติดป้ายข้อมูลหรือ MLOps เมื่อทีมต้องควบคุมฉลาก ติดตามเวอร์ชัน และตรวจสอบกระบวนการอย่างต่อเนื่อง

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

บทส่งท้าย

การจูนโมเดลภาษาอย่างคุ้มค่าเริ่มจากการเลือกข้อมูลที่ตอบโจทย์ ไม่ใช่จากการขยายชุดข้อมูลโดยอัตโนมัติ Random, stratified, hard-example และ diversity sampling มีบทบาทต่างกันตามปัญหาที่ทีมกำลังเจอ

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

ข้อมูลที่ควรรู้

1. ข้อมูลที่น้อยแต่ตรงงานและมีฉลากสอดคล้อง อาจมีประโยชน์กว่าข้อมูลจำนวนมากที่ซ้ำหรือไม่เกี่ยวข้อง
2. Hard-example sampling ต้องมีระบบประเมินที่ไว้ใจได้ มิฉะนั้นอาจเลือกข้อมูลผิดเป้าหมาย
3. การแยกชุด test ออกจากการเทรนช่วยลดความเสี่ยงของผลประเมินที่ดูดีเกินจริง
4. ข้อมูลลูกค้า ข้อมูลส่วนบุคคล และข้อมูลอ่อนไหวต้องผ่านการตรวจสิทธิ์และนโยบายก่อนนำมาใช้
5. เครื่องมือ MLOps มีคุณค่าเมื่อช่วยให้ทีมทำซ้ำ ตรวจสอบ และเปรียบเทียบการทดลองได้จริง

สรุปข้อสำคัญ

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

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

Q1. ถ้ามีงบจำกัด ควรเพิ่มจำนวนข้อมูลหรือเลือก hard examples สำหรับจูนโมเดลภาษาก่อน?

A1. ให้เริ่มจากตรวจคุณภาพข้อมูลเดิม ลบข้อมูลซ้ำ และดูข้อผิดพลาดบนชุด validation ที่แยกไว้ก่อน หากมีหลักฐานว่าโมเดลผิดซ้ำในกรณีเฉพาะ และระบบประเมินเชื่อถือได้ hard-example sampling อาจช่วยโฟกัสทรัพยากรได้ แต่ไม่ควรคาดหวังผลลัพธ์ที่รับประกันกับทุกงาน

Q2. Stratified sampling เหมาะกับโมเดลภาษาไทยที่มีข้อมูลหลายหมวดหมู่อย่างไร?

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

Q3. ควรจ้างติดป้ายข้อมูลภายนอกเมื่อใด และต้องเปรียบเทียบค่าใช้จ่ายด้านใดบ้าง?

A3. อาจพิจารณาเมื่อทีมต้องการกำลังคนเพิ่ม หรือต้องการกระบวนการติดป้ายและตรวจทานที่เป็นระบบ ควรเปรียบเทียบขอบเขตงาน คุณภาพและความสอดคล้องของฉลาก การควบคุมสิทธิ์ข้อมูล เงื่อนไขการจัดเก็บข้อมูล และต้นทุนรวมเทียบกับเวลาทีมและค่าเทรนบน GPU