Bedrock-RL: เขียน Minecraft ใหม่ทั้งเกมด้วย C/CUDA ให้ผลลัพธ์เหมือนเดิมทุกครั้ง แล้วใช้เทรน VLM agent ด้วย RL — พร้อมตัวอย่างที่ผู้เขียนบอกเองว่า "ยังไม่มีนัยสำคัญทางสถิติ"

งานเทรน agent ที่ “มองเห็นแล้วลงมือทำ” ในโลกเสมือนติดคอขวดเดิมมาหลายปี — สภาพแวดล้อมที่ใช้ทดสอบมักช้า และที่แย่กว่าคือ ผลลัพธ์ไม่เหมือนเดิมเมื่อรันซ้ำ ซึ่งทำให้เทียบผลการทดลองสองครั้งแทบไม่ได้ ผลคืองานส่วนใหญ่จึงหนีไปทำ behavior cloning จากวิดีโอมนุษย์แทน RL จริง ๆ

19 สิงหาคม 2026 มีเฟรมเวิร์กชื่อ Bedrock-RL ปล่อยออกมาบน Hugging Face และ GitHub (สัญญาอนุญาต MIT) ที่พยายามแก้ปัญหานี้ตรงจุด: จับคู่ Netherite — Minecraft ที่ถูกเขียนขึ้นใหม่ด้วย C/CUDA ให้ทำงานแบบ deterministic — เข้ากับ verl สำหรับ distributed RL แล้วเปิดให้เทรน vision-language model เป็น agent ในเกมได้จริง

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

ทำไม determinism ถึงเป็นเรื่องใหญ่

ผู้เขียนอธิบายปัญหาไว้ตรง ๆ ว่า Java client ของ Minecraft “ช้า ไม่ deterministic และเป็นศัตรูกับการรัน rollout แบบขนาน” ซึ่งเป็นสามคุณสมบัติที่ขัดกับ RL ทุกข้อ

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

Netherite แก้ทั้งสามข้อโดยเขียน simulation ใหม่ใน C/CUDA ผลพลอยได้ที่สำคัญคือ สร้าง episode ชุด train/dev/test ที่แยก seed กันแบบไม่ทับซ้อน (seed-disjoint) แล้วรันซ้ำได้เหมือนเดิมทุกครั้ง — ซึ่งเป็นเงื่อนไขพื้นฐานของการทดลองที่เชื่อถือได้ แต่หายากมากในงาน embodied agent

อีกจุดที่ออกแบบมาดีคือ renderer แยกออกจาก state เอนจินให้ state เดียวกัน แล้วเลือกได้ว่าจะเรนเดอร์เป็นแบบ semantic (นามธรรม), texture แบบ procedural ของ Netherite เอง หรือกราฟิก Minecraft ของจริง — และเขียน renderer เองก็ได้ แปลว่าทดลองได้ว่า “โมเดลต้องการรายละเอียดภาพมากแค่ไหนถึงจะทำงานนี้ได้” โดยไม่ต้องเปลี่ยนอย่างอื่นเลย

สิ่งที่ประกอบเข้าไปได้ และวิธีนิยามงาน

Bedrock-RL ออกแบบเป็นชิ้นส่วนที่สลับได้ผ่าน import path — task, sampler, qualifier, policy, executor, writer เปลี่ยนได้ทีละชิ้น ส่วนตัวงานนิยามด้วย YAML ตรงไปตรงมา:

name: farm_one_log_sdg
goal: Find a nearby tree, harvest one natural log, and collect it.
success: {type: item_gained, item: log, count: 1, reward: 1.0}

วิธีเทรนที่รองรับครอบคลุมกว่าที่คาด:

• RL: GRPO, RLOO, REINFORCE++, ReMax พร้อมเลือก policy loss แบบ vanilla หรือ GSPO
• SFT: เทรนจาก episode ที่สำเร็จและตรวจสอบแล้ว
• SDFT: on-policy self-distillation จาก demonstration
• SDPO: self-distilled policy optimization
• OPD / MOPD: on-policy distillation จากครูหนึ่งตัวหรือหลายตัว

รันได้ทั้งบนเครื่องตัวเองผ่าน uv, หลายโหนด, หรือส่งขึ้น Modal ด้วย --modal --gpu H100 โดยใช้ manifest ไฟล์เดียวกัน และ run directory resume ได้เมื่องานล้ม

ตัวเลขที่ผู้เขียนเลือกจะไม่โฆษณา

ตัวอย่าง end-to-end ที่แถมมาคืองาน equip_pickaxe — สอน Qwen3-VL 2B ให้เลือกไอเทมที่ถูกต้องจาก hotbar ผลหลังรัน GRPO ไป 10 ก้าว:

นโยบาย	Dev success (temp 0)	Pass@3 (temp 1)
Base	27/288 (9.4%)	31/288 (10.8%)
GRPO step 10	39/288 (13.5%)	64/288 (22.2%)

ตรงนี้คือส่วนที่น่าสนใจจริง ๆ ถ้าเป็นรีลีสทั่วไป พาดหัวคงเป็น “GRPO ดัน success rate ขึ้น 44%” (9.4% → 13.5%) แต่ผู้เขียนกลับรายงานว่าการปรับปรุงในโหมดลองครั้งเดียวนั้น ไม่มีนัยสำคัญทางสถิติ (p = 0.169) ส่วนที่มีนัยสำคัญจริงคือ pass@3 (p = 1.03 × 10⁻⁷) แล้วสรุปด้วยประโยคว่า

“We ship it as an end-to-end pipeline check with raw records and seed-clustered intervals, not a benchmark claim.”

— เราปล่อยมันในฐานะการตรวจสอบว่า pipeline ทำงานครบวงจร ไม่ใช่การเคลมเบนช์มาร์ก

ระเบียบวิธีที่ใช้ก็เข้มกว่าค่าเฉลี่ยในวงการนี้มาก: ใช้ dev prompt ที่แช่แข็งไว้ 288 ชุด สำหรับเลือก checkpoint, รายงาน Wilson confidence interval และ CI แบบ seed-clustered, ใช้ exact paired test ไม่ใช่แค่ค่ากลาง และ เปิด test split หลังจากเลือก checkpoint จาก dev เสร็จแล้วเท่านั้น — ซึ่งเป็นการป้องกัน p-hacking ที่รายงานผลโมเดลจำนวนมากข้ามไปเฉย ๆ

ข้อควรรู้: โปรเจกต์นี้ยังใหม่มาก (GitHub มีราว 126 ดาว, commit บน main ยังนับได้ไม่กี่ครั้ง) และผลที่แสดงเป็นงานระดับ “เลือกไอเทมให้ถูก” ยังห่างจากงานยาว ๆ อย่างสร้างบ้านหรือหาแร่หลายชั้นอยู่มาก

มุมมอง AI Curator

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

ลองคิดดูว่าถ้าโปรเจกต์นี้เลือกอีกทาง — รายงานแค่ 9.4% → 13.5% ใส่กราฟแท่งสวย ๆ ไม่พูดถึงค่า p เลย — มันคงได้แชร์บน X มากกว่านี้หลายเท่า และแทบไม่มีใครตรวจสอบได้ เพราะสภาพแวดล้อมส่วนใหญ่รันซ้ำแล้วไม่ได้ผลเดิมอยู่แล้ว การที่ Bedrock-RL ทำ determinism ให้ได้ก่อน แล้วค่อยรายงานผลอย่างระมัดระวัง คือลำดับที่ถูกต้อง แต่เป็นลำดับที่แรงจูงใจในวงการกำลังผลักให้ทุกคนทำกลับกัน

มีอีกประเด็นที่แอบซ่อนอยู่ในตัวเลข และคุ้มที่จะหยิบมาพูด: ช่องว่างระหว่าง single-attempt กับ pass@3 กว้างขึ้นหลังเทรน (จาก 9.4/10.8 เป็น 13.5/22.2) นี่เป็นรูปแบบที่เจอซ้ำ ๆ ในงาน agent — RL มักทำให้โมเดล “มีโอกาสทำถูกอยู่ในตัวเลือกที่มันสุ่มออกมา” ก่อนที่จะ “ทำถูกตั้งแต่ครั้งแรก” ซึ่งแปลว่าถ้าคุณกำลังประเมิน agent ด้วยตัวเลข pass@k อย่างเดียว คุณอาจกำลังวัดสิ่งที่ระบบจริงของคุณใช้ไม่ได้ เพราะโปรดักชันส่วนใหญ่ยอมให้ลองครั้งเดียว

สำหรับทีมในไทย ผมเห็นการใช้งานที่ตรงมากสองแบบ

แบบแรก — นี่คือสนามฝึกที่ต้นทุนต่ำจริง โมเดลตัวอย่างคือ Qwen3-VL 2B ไม่ใช่โมเดลระดับหลายร้อยพันล้านพารามิเตอร์ นักศึกษาหรือทีมวิจัยขนาดเล็กที่มี GPU ตัวเดียวลองทำ RL กับ VLM แบบครบวงจรได้จริงโดยไม่ต้องขอทุนก้อนใหญ่ และเพราะทุกอย่างเป็น MIT กับ deterministic การทำซ้ำผลของคนอื่นจึงเป็นไปได้ — ซึ่งเป็นจุดเริ่มต้นของงานวิจัยที่ดีเสมอ

แบบที่สอง และผมคิดว่าใช้ได้กว้างกว่า — ยกระเบียบวิธีของโปรเจกต์นี้มาใช้กับ eval ของคุณเอง ทีมที่ทำ AI agent ในไทยส่วนใหญ่ประเมินผลด้วยการรันชุดทดสอบชุดเดียวซ้ำ ๆ ปรับ prompt แล้วดูว่าคะแนนขึ้นไหม ซึ่งคือการ overfit บนชุดทดสอบตรง ๆ สามอย่างที่ยกมาใช้ได้ทันทีโดยไม่ต้องแตะ Minecraft เลยคือ: แยก dev กับ test ออกจากกันจริงและอย่าเปิด test จนกว่าจะเลือกเวอร์ชันเสร็จ, รายงาน confidence interval ไม่ใช่แค่ตัวเลขเดียว, และ ถามทุกครั้งว่าส่วนต่างที่เห็นนั้นใหญ่กว่า noise หรือเปล่า ต้นทุนของสามข้อนี้คือเวลาไม่กี่ชั่วโมง ส่วนต้นทุนของการไม่ทำคือการเอาโมเดลที่ “ดูเหมือนดีขึ้น” ขึ้นโปรดักชันแล้วมารู้ทีหลังว่ามันไม่ได้ดีขึ้นเลย

แหล่งข่าว

• Bedrock-RL: a deterministic Minecraft framework for training and benchmarking VLM agents — Hugging Face Blog
• michaelbf16/bedrock-rl — GitHub (MIT)