โมเดล 125M ที่เล่นเปียโนต่อจากคุณได้บน iPhone — และบทเรียนวิศวกรรมที่ใช้ได้กับโมเดลเล็กทุกตัว: DPO ดันคะแนนจาก 24.5% เป็น 69%

20 สิงหาคม 2026 Simon Edwardsson เผยแพร่บันทึกการสร้าง RollTab — แอปที่เล่นเปียโนต่อจากสิ่งที่คุณเพิ่งเล่นไป แบบเดียวกับที่ GitHub Copilot เติมโค้ดให้ แต่ input คือคีย์บอร์ด MIDI และทุกอย่างรันบน iPhone โดยไม่ต้องต่อเน็ต

เหตุผลที่โพสต์นี้ขึ้นอันดับต้น ๆ ของ Hacker News (กว่า 500 คะแนน) ไม่ใช่เพราะเป็นแอปเปียโน แต่เพราะมันเป็น บันทึกวิศวกรรมโมเดลเล็กที่ครบถ้วนผิดปกติ — รวมทั้งส่วนที่ล้มเหลว ซึ่งหายากมากในบล็อกสายนี้ ผู้เขียนเรียกผลงานตัวเองว่า “GPT-2 แต่สำหรับเปียโน” และบทเรียนเกือบทุกข้อในนั้นย้ายไปใช้กับโดเมนอื่นได้ทันที

บทเรียนที่ 1: การออกแบบ tokenization สำคัญกว่าที่คิด

โจทย์แรกคือจะแทนโน้ตดนตรีเป็นโทเคนยังไง ผู้เขียนลองสองแบบก่อนจะทิ้งทั้งคู่:

• แบบ note-on / note-off (แยกเหตุการณ์กดและปล่อยเป็นคนละโทเคน) — “มีแนวโน้มไหลออกนอกลู่” เกิดโน้ตค้างที่ไม่มีการปล่อย
• แบบ grammar-masked — ช้าเกินไป เพราะต้องรัน transformer สี่รอบต่อหนึ่งโน้ต

ทางออกสุดท้ายคือ หนึ่งโน้ต = หนึ่งโทเคน ที่ประกอบด้วยห้าฟิลด์เชิงหมวดหมู่พร้อมกัน: [event_type, pitch_id, delta_id, duration_id, velocity_id] โดยแต่ละฟิลด์มี vocabulary แยกกัน (pitch 128 ค่าตามมาตรฐาน MIDI, delta_onset คือระยะเวลาจากโน้ตก่อนหน้า, duration, และ velocity ที่แบ่งเป็นช่วง ๆ) แล้วรวมเข้าด้วยกันด้วย additive embedding

ผลคือโมเดลเดินหน้าทีละ “หนึ่งโน้ตเต็ม” ต่อหนึ่ง forward pass ซึ่งคือเหตุผลที่มันเร็วพอจะทันการเล่นจริง ส่วน loss ก็คือผลรวมของห้าหัว: type_loss + pitch_loss + delta_loss + duration_loss + velocity_loss

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

บทเรียนที่ 2: ทำความสะอาดข้อมูล ชนะการเพิ่มข้อมูล

ชุดข้อมูลคือไฟล์ MIDI ไม่กี่แสนไฟล์ รวมราว 300 ล้านเหตุการณ์โน้ต ส่วนใหญ่เป็นเพลงคลาสสิกที่หมดลิขสิทธิ์แล้ว และประโยคที่ผู้เขียนย้ำคือ “การทำความสะอาดและคัดเลือกข้อมูลสำคัญกว่าการเพิ่มข้อมูลเข้าไปเฉย ๆ”

การทำความสะอาดรวมถึงการตัดข้อมูลซ้ำด้วย fingerprint ที่ไม่ขึ้นกับการย้ายคีย์ (transposition-invariant) และกรองไฟล์ที่มีหลายแทร็กแบบผิดปกติออก ส่วน augmentation ใช้การย้ายคีย์ทั้งเพลง ปรับความเร็วแบบสม่ำเสมอ และเขย่าค่า duration/velocity เล็กน้อย

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

บทเรียนที่ 3: validation loss โกหกได้

เทคนิคที่ผู้เขียนบอกว่าได้ผลคือ scheduled sampling — ค่อย ๆ เพิ่มสัดส่วนที่โมเดลต้องใช้คำทำนายของตัวเองแทนคำตอบจริงระหว่างเทรน จาก 0% ไปถึง 50%

ประเด็นสำคัญคือมัน ทำให้ validation loss แย่ลง แต่คุณภาพเวลาปล่อยให้โมเดลเล่นยาว ๆ ดีขึ้น เหตุผลตรงไปตรงมา: ตอนใช้งานจริงโมเดลต้องต่อยอดจากเอาต์พุตตัวเอง ถ้าเทรนโดยป้อนคำตอบจริงให้ตลอด (teacher forcing) มันจะไม่เคยเรียนวิธีกู้ตัวจากความผิดพลาดของตัวเอง — ปัญหา exposure bias คลาสสิกที่ยังหลอกหลอนงาน autoregressive ทุกประเภท

นี่คือเหตุผลที่ผู้เขียนสรุปว่า metric อัตโนมัติ (n-gram ของ pitch, entropy, ความหนาแน่นของโน้ต, การตรวจช่วงเงียบยาว) “มีประโยชน์สำหรับจับความล้มเหลวที่ชัดเจน แต่ไม่ดีพอจะใช้เลือกโมเดลที่ดีที่สุด”

บทเรียนที่ 4: DPO ให้ผลตอบแทนสูงสุด และวิธีสร้างข้อมูลก็สำคัญ

ขั้นที่ให้ผลมากที่สุดคือ Direct Preference Optimization หลังเทรนเสร็จ วิธีเก็บข้อมูล preference คือสร้างการเล่นต่อหลายเวอร์ชันจาก prompt เดียวกัน แล้วให้ Gemini 3.5 Flash เป็นผู้ตัดสินว่าอันไหนดีกว่า

รายละเอียดที่ควรจำสำหรับใครที่ใช้ LLM-as-judge: ผู้เขียนพบว่า การตัดสินแบบจับคู่เทียบ (pairwise) ได้ผลดีกว่าการให้คะแนนเป็นค่าสัมบูรณ์ และเขาลด position bias ด้วยการสลับลำดับแล้วเทียบซ้ำ — สองข้อนี้คือมาตรฐานที่คนมักข้าม

ตัวเลขผลลัพธ์:

การตั้งค่า	คะแนน preference
โมเดลก่อนทำ DPO	24.55%
DPO (β = 0.03)	57.14%
DPO ชุดข้อมูล consensus (β = 0.03)	69.05%

และค่า β = 0.10 “ดันแรงเกินไปจนแย่ลง” — บทเรียนเดิมที่เจอซ้ำในทุกงาน preference optimization คือ ดันให้ห่างจากโมเดลอ้างอิงมากไปแล้วโมเดลจะพัง

การประเมินใช้การสร้างการเล่นต่อจากเพลงที่กันไว้ โดย prompt ยาว 4–32 โน้ต ซึ่งพบว่า prompt สั้น 4 โน้ตยากที่สุด ส่วน 16–32 โน้ตให้ผลเสถียรกว่ามาก

บทเรียนที่ 5: ข้อจำกัดของ Core ML ที่คนทำ on-device ควรรู้

โมเดลสามขนาดถูกเทรน (33M, 64M, 125M) และตัว 125M คือตัวที่ปล่อยลงมือถือ ผ่านการแปลง PyTorch → Core ML พร้อมควอนไทซ์ INT8 ได้ความเร็วราว 108 โน้ตต่อวินาที บน iPhone 15 ซึ่งเร็วกว่าความเร็วที่มนุษย์เล่นได้มาก

ข้อจำกัดที่น่าสนใจที่สุดคือเรื่อง KV cache: Core ML ไม่เปิดให้เข้าถึง Q, K, V โดยตรง จึงทำ ring buffer ไม่ได้ ผลคือเมื่อ context ใกล้ครบ 512 โน้ต โมเดลต้อง สร้าง cache ใหม่ทั้งหมด (ตอน inference จึงลดหน้าต่างลงเหลือ 384 โน้ตแบบไดนามิกเพื่อจัดการเรื่องนี้) และการเปิดแอปครั้งแรกยัง “ช้าน่ารำคาญ” ระหว่างที่ runtime ของ Apple ปรับแต่งโมเดล

ผู้เขียนระบุปัญหาที่ยังเหลือตรง ๆ ว่า “บางครั้งมันวนซ้ำ และ prompt สั้น ๆ ยังยาก” ส่วนสิ่งที่ลองแล้วไม่เวิร์กมีทั้ง Mirostat (ได้ผลไม่ปะติดปะต่อ) และการเทรนใหม่แบบ born-again (ไม่ดีขึ้น)

แอป RollTab ดาวน์โหลดฟรีบน App Store สำหรับ iOS/iPad ที่ต่อคีย์บอร์ด MIDI — แต่ โค้ดและน้ำหนักโมเดลไม่ได้เปิด ซึ่งเป็นข้อจำกัดที่ต้องบอกให้ชัด บทความให้รายละเอียดพอจะทำตามได้ แต่ไม่ใช่ของที่หยิบมารันเองได้เลย

มุมมอง AI Curator

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

ถ้าไล่ดูว่าอะไรให้ผลตอบแทนสูงสุดในโปรเจกต์นี้ จะได้ลำดับที่ขัดกับสิ่งที่คนส่วนใหญ่ทำ: การออกแบบ tokenization มาก่อน แล้วการทำความสะอาดข้อมูล แล้ว post-training ด้วย DPO — ส่วนการเพิ่มขนาดโมเดลกับการเพิ่มปริมาณข้อมูลอยู่ท้ายสุด ตัวเลข 24.55% → 69.05% นั้นได้มาโดยไม่แตะขนาดโมเดลเลยแม้แต่นิดเดียว

นี่คือสิ่งที่นักพัฒนาไทยควรเก็บไปใช้ที่สุด เพราะโจทย์จำนวนมากในไทยเป็นโจทย์เฉพาะทางที่ไม่มีโมเดลสำเร็จรูปรองรับ — การจำแนกเอกสารราชการ การแปลงคำพูดภาษาไทยผสมอังกฤษ การจัดหมวดสินค้าอีคอมเมิร์ซ — และเป็นโจทย์ที่โมเดล 100M–1B พารามิเตอร์ที่ออกแบบดี ๆ มักชนะการยิง API โมเดลยักษ์ ทั้งในแง่ต้นทุน ความเร็ว และความเป็นส่วนตัวของข้อมูล งบเทรนระดับนี้อยู่ในวิสัยที่ทีมเล็กหรือแม้แต่คนเดียวทำได้จริง

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

แหล่งข่าว

• Teaching a 125M model to autocomplete piano — simedw.com (20 ส.ค. 2026, แหล่งข้อมูลหลัก)
• การอภิปรายบน Hacker News