🎙️ เรื่องเล่าจาก Scaling Laws: เมื่อ compute ไม่ใช่พระเจ้าองค์เดียว และ data คือสิ่งที่เรากำลังขาดแคลน Kushal Chakrabarti เขียนบทความที่พลิกความเข้าใจเดิมเกี่ยวกับ The Bitter Lesson โดยชี้ว่า เราอ่านบทเรียนนี้ “กลับด้าน” มานานหลายปี เพราะจริง ๆ แล้ว Scaling Laws บอกเราว่า compute (C) ไม่ได้ทำงานลอย ๆ—มันต้องจับคู่กับ data (D) อย่างถูกสัดส่วน และความสัมพันธ์นั้นคือ C ∼ D² แปลว่า ถ้าเราจะเพิ่ม GPU เป็นสองเท่า เราต้องเพิ่มข้อมูลอีก 40% ไม่งั้นก็เหมือนจุดไฟเผาเงินเล่น เพราะ compute ที่มากขึ้นจะไม่มีประโยชน์ถ้าไม่มีข้อมูลที่มากพอให้มันเรียนรู้ ปัญหาคือ เรากินข้อมูลจากอินเทอร์เน็ตไปหมดแล้ว และไม่มี “อินเทอร์เน็ตที่สอง” ให้เทรน GPT-6 ได้อีกต่อไป ข้อมูลที่มีคุณภาพสูงจริง ๆ เหลืออยู่แค่ประมาณ 10 ล้านล้าน token เท่านั้น ซึ่งไม่พอสำหรับโมเดลระดับ 100B+ parameters ที่ต้องใช้ข้อมูลมหาศาลต่อ parameter ดังนั้น ทีม AI ต้องเลือกทางเดินใหม่: จะเป็น “Architect” ที่ออกแบบโมเดลให้ฉลาดขึ้นโดยใช้ข้อมูลเท่าเดิม หรือเป็น “Alchemist” ที่สร้างข้อมูลใหม่จากการเรียนรู้ของโมเดลเอง เช่น self-play, RLHF, หรือ agentic feedback loop ✅ Scaling Laws และความเข้าใจใหม่ ➡️ ความสัมพันธ์ระหว่าง compute กับ data คือ C ∼ D² ➡️ เพิ่ม GPU โดยไม่เพิ่มข้อมูล = ประสิทธิภาพลดลง ➡️ Chinchilla model ของ DeepMind ยืนยันว่า model size ควรสอดคล้องกับ data size ✅ ปัญหาคอขวดด้านข้อมูล ➡️ อินเทอร์เน็ตถูกใช้หมดแล้ว ไม่มีแหล่งข้อมูลใหม่ขนาดใหญ่ ➡️ ข้อมูลคุณภาพสูงเหลือเพียง ~10T token หลังกรองซ้ำและคุณภาพ ➡️ GPT-6 ต้องการข้อมูลระดับ ~20 token ต่อ parameter ซึ่งไม่พอในปัจจุบัน ✅ ทางเลือกของทีมวิจัย AI ➡️ Architect: พัฒนาโมเดลให้ฉลาดขึ้นโดยใช้ข้อมูลเท่าเดิม เช่น Mamba, HRM, ParScale ➡️ Alchemist: สร้างข้อมูลใหม่จาก self-play, RLHF, agentic feedback loop ➡️ ทั้งสองแนวทางต้องทำงานร่วมกันเพื่อผลลัพธ์ที่ดีที่สุด ✅ กลยุทธ์สำหรับผู้นำองค์กร ➡️ Incumbent’s Gambit: ลงทุน 70% กับ Architect เพื่อความมั่นคง และ 30% กับ Alchemist เพื่อ hedge ➡️ Challenger’s Gambit: ลงทุน 70% กับ Alchemist เพื่อ leapfrog และ 30% กับ Architect เพื่อความต่อเนื่อง ➡️ การจัดพอร์ตวิจัยต้องสะท้อนความเสี่ยงและเป้าหมายขององค์กร https://obviouslywrong.substack.com/p/the-bitter-lesson-is-misunderstood