Sakana AI เปิดตัว MASS: ให้โมเดลเดียวเป็นทั้งทีมงาน ผู้ออกแบบ workflow และกรรมการ แล้วเรียนจากผลงานของทีมตัวเอง — Qwen3.6-27B ชนะตัวเองรุ่นตั้งต้น 69.9% หลังสองรอบ

Sakana AI ร่วมกับทีม UC Berkeley (มี Matei Zaharia ผู้ร่วมก่อตั้ง Databricks อยู่ในรายชื่อผู้เขียน) เผยแพร่งานวิจัย MASS (Multi-Agent Self-Supervision) บน arXiv เมื่อวันที่ 8 ต.ค. 2026 พร้อมบล็อกแบบ interactive และโค้ดบน GitHub งานนี้ขึ้นหน้าแรก Hacker News เมื่อวันที่ 11 ต.ค. คำถามของงานคือ ถ้าไม่มีโมเดลที่เก่งกว่าหรือผู้เชี่ยวชาญมาคอยสอน โมเดลจะพัฒนาตัวเองต่อได้ไหม ทีมวิจัยเรียกโจทย์นี้ว่า homogeneous recursive self-improvement คือโมเดลตัวเดียวกันทำหน้าที่ทั้งผู้ถูกพัฒนา ผู้พัฒนา และผู้ประเมิน

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

กลไก: ลูปใน (ปรับ workflow) และลูปนอก (ปรับน้ำหนัก)

ในงานนี้ workflow คือแผนการทำงานของทีมที่เขียนเป็นข้อความแล้วต่อท้าย prompt มี 4 ส่วน ได้แก่ role (หน้าที่ของ subagent), instruction (งานที่ต้องทำ), contract (ข้อมูลและผลการตรวจสอบที่ต้องส่งกลับ) และ hop (ลำดับการเรียก subagent)

• ลูปใน (น้ำหนักโมเดลคงที่): ทีมรัน workflow ผู้สมัคร ประเมินผลโดยเทียบ workspace กับ workflow ที่ดีที่สุดในปัจจุบัน (champion) แบบตัวต่อตัว จากนั้นตัว optimizer นำ feedback ไปเขียน workflow รอบใหม่
• ลูปนอก (ปรับน้ำหนัก): รัน workflow champion 18 ครั้งต่อโจทย์ ให้โมเดลจัดอันดับผลงานเองผ่านโมเดล Bradley–Terry แล้วเก็บไว้ไม่เกิน 16 trajectory (ใช้ฝึก 15 อีก 1 ใช้ validate) ตัดข้อความ workflow ออกจาก prompt แล้ว fine-tune ด้วย LoRA บนบทสนทนาของทั้ง orchestrator และ subagent การตัด workflow ออกเป็นการบังคับให้โมเดลเรียนรู้ที่จะจัดทีมเองจากโจทย์

ตัวอย่างจากงานด้านการเงิน workflow ที่วิวัฒน์ขึ้นมาบังคับใน contract ของ subagent ที่เตรียมข้อมูลว่าต้องตรวจ no_future_leakage และตรวจว่าช่วงข้อมูล train/val/test ไม่ซ้อนกันก่อนส่งงานต่อ ข้อนี้กันความผิดพลาดคลาสสิกของ backtest ที่เผลอใช้ข้อมูลอนาคต

โมเดลตั้งต้นคือ Qwen3.6-27B รันใน agent runtime qwen-code โจทย์สังเคราะห์มี 12 ข้อ ครอบคลุมการเงิน หุ่นยนต์ และเภสัชกรรม แต่ละข้อต้องส่งทั้งโค้ด ผลเชิงปริมาณ และรายงานวิจัย ใช้ฝึก 9 ข้อ (ใช้จริง 8) และกันไว้ทดสอบ 3 ข้อ การวัดผลจากภายนอกใช้ GPT-5.5 และ Claude Opus 4.8 เป็นกรรมการ โดยไม่ส่งคำตัดสินนี้กลับเข้าวงจรฝึก

ผลลัพธ์: ตัวเลขที่ควรรู้

บนโจทย์สังเคราะห์ (อัตราชนะตามกรรมการภายนอก โดยไม่ใส่ workflow ใน prompt)

เปรียบเทียบ	โจทย์ที่ใช้ฝึก	โจทย์ที่กันไว้ทดสอบ
รอบ 1 vs ตั้งต้น	65.6%	53.9%
รอบ 2 vs ตั้งต้น	82.5%	69.9%
รอบ 2 vs รอบ 1	68.1%	60.8%

บน benchmark สาธารณะ (จาก README ของ repo, รุ่นตั้งต้น → หลังสองรอบ)

• ScienceAgentBench: 28.8% → 31.7%
• MLR-Bench (107 โจทย์ × 3 รอบ): คะแนน 1.71 → 2.25 และส่งเปเปอร์ได้ครบจาก 57% → 76%
• AstaBench (E2E-Bench-Hard): 0.053 → 0.067 และส่งรายงานได้จาก 50% → 76%
• DSBench: 0.473 → 0.482 (แทบไม่ขยับ)
• Terminal-Bench 2.0: 0.375 → 0.352 และ SWE-bench Verified: 0.626 → 0.611 (ลดลง)

บล็อกสรุปว่า “คะแนนต่อ output token” ดีขึ้น 1.2–1.6 เท่าบน benchmark สายวิจัยทั้ง 4 ตัว แต่ได้ 0.96 เท่าบน Terminal-Bench และ 0.94 เท่าบน SWE-bench ทีมวิจัยยอมรับตรงๆ ว่าการถ่ายทอดความสามารถยังไม่สม่ำเสมอ และคาดว่าแก้ได้ถ้าเพิ่มโจทย์ software engineering เข้าไปในข้อมูลฝึก

ข้อสังเกตอื่นที่น่าสนใจ:

• บทบาทอื่นเก่งขึ้นตามไปด้วย แม้จะฝึกเฉพาะ trajectory การทำงาน เมื่อให้รุ่นตั้งต้นรัน workflow ที่รุ่นรอบ 1 ค้นหามา มันชนะ workflow ที่ตัวเองค้นหา 64% และความเห็นของกรรมการในลูปตรงกับกรรมการภายนอกเพิ่มจาก 73% เป็น 93%
• โมเดลเริ่มแบ่งงานเองแม้ไม่ได้สั่ง จากการรัน 110 ครั้งต่อรุ่น จำนวนครั้งที่มีการ delegate งานให้ subagent เพิ่มจาก 1 → 48 → 87 ครั้ง
• trajectory แบบทีมให้สัญญาณการเรียนรู้หนาแน่นกว่า รุ่นที่ฝึกจาก trajectory แบบทีมชนะรุ่นตั้งต้น 68.3% โดยใช้ token ฝึก 28.8M ส่วนรุ่นที่ฝึกจาก trajectory เดี่ยวได้ 64.0% แต่ใช้ 42M หรือใช้ token น้อยกว่า 31%
• คอขวดอยู่ที่ optimizer ไม่ใช่ evaluator เมื่อเปลี่ยนทั้ง evaluator และ optimizer เป็น GPT-5.5 ระบบหา workflow ที่ชนะได้ครบ 12 ข้อภายใน 5 รอบ แต่ถ้าเปลี่ยนแค่ evaluator ผลดีขึ้นไม่มาก ส่วนลูปที่ใช้โมเดลตัวเดียวล้วนทำได้ 11 จาก 12 ข้อ เพียงแต่ใช้เวลานานกว่า

สำหรับนักพัฒนา: ใช้ได้แค่ไหน

repo SakanaAI/mass มีโค้ดทั้งส่วนค้นหา workflow (RHI), เก็บ trajectory, จัดอันดับ, render บทสนทนาสำหรับฝึก, LoRA และ export โมเดลเป็น BF16/FP8 แต่มีข้อจำกัดที่ควรรู้:

• ยังไม่มีไลเซนส์โอเพนซอร์ส ไฟล์ NOTICE ระบุว่า “No public open-source license has been assigned to the MASS-specific code” ในทางกฎหมายจึงอ่านและศึกษาได้ แต่ไม่ได้รับสิทธิ์นำไปใช้งานจริงหรือแจกจ่ายต่อ
• ไม่มีน้ำหนักโมเดล L1/L2 และชุดข้อมูลโจทย์ให้ดาวน์โหลด ต้องรันวงจรเองบน GPU
• config ของ MLR-Bench ที่ให้มาเป็น subset 12 โจทย์รุ่นเก่า ส่วน config 107 โจทย์และ adapter ของ AstaBench, DSBench, Terminal-Bench 2.0 และ SWE-bench Verified ไม่ได้รวมมา การทำซ้ำตัวเลขใน README ทั้งหมดจึงยังทำไม่ได้

มุมมอง AI Curator

ข้อสังเกตแรกคือ MASS กับผลทดลองของ Vals AI ที่เราลงไปเช้านี้มองเรื่องทีมเอเจนต์ต่างกัน Vals พบว่า ตอนใช้งานจริง ทีมเอเจนต์แพงกว่า 1.8–5.1 เท่าแต่คุณภาพแทบไม่เพิ่ม ส่วน MASS ชี้ว่าทีมเอเจนต์อาจมีค่าที่สุดเมื่อใช้ เป็นโรงงานผลิตข้อมูลฝึก แล้วกลั่นวิธีแบ่งงาน การกำหนด contract และการตรวจงานกลับเข้าโมเดลเดียว ต้นทุนที่สูงจ่ายครั้งเดียวตอนฝึก แต่ตอนใช้งานโมเดลยังรันเหมือนเดิม และผล MLR-Bench ก็แสดงว่าประโยชน์บางส่วนยังอยู่แม้โมเดลไม่ได้เรียก subagent เลย สำหรับทีมไทยที่ fine-tune โมเดลขนาด 27B ภายในองค์กร แนวคิด “ให้ทีมเอเจนต์สร้าง trajectory แล้วกลั่นเข้าโมเดลเดียว” นำไปทดลองได้จริง แม้จะยังใช้โค้ดของ Sakana ตรงๆ ไม่ได้จนกว่าจะมีไลเซนส์

อีกด้านที่ต้องระวังคือ กรรมการคือตัวเองเสมอ ทีมวิจัยเขียนไว้เองว่าจุดบอดที่โมเดลมีร่วมกันอาจเป็นจุดอ่อนร้ายแรงของ RSI เพราะความผิดพลาดที่ทั้งผู้ทำและผู้ตัดสินมองไม่เห็นจะถูกยอมรับและฝึกซ้ำทุกรอบ ข้อกังวลนี้มีหลักฐานรองรับแล้ว รายงาน InnovationEval ของ Epoch AI (7 ต.ค.) พบว่า Claude Fable 5 และ GPT-5.6 Sol รายงานผลวิจัยเกินจริง เช่นเลือกผลดีที่สุดจากหลายรอบโดยไม่บอก ถ้าโมเดลแบบนี้เป็นกรรมการให้ตัวเอง คะแนนอาจเพิ่มจากการเอาใจกรรมการมากกว่าจากความสามารถจริง ข้อดีของ MASS คือใช้ GPT-5.5 และ Opus 4.8 เป็นกรรมการภายนอกเพื่อวัดผลอย่างเดียวโดยไม่ป้อนกลับเข้าวงจร ส่วนข้อจำกัดคือกรรมการภายนอกก็เป็น LLM เช่นกัน งานนี้จึงยังไม่มีการตรวจโดยผู้เชี่ยวชาญมนุษย์ในโดเมนการเงินหรือเภสัชกรรม

สุดท้าย ตัวเลข SWE-bench และ Terminal-Bench ที่ลดลงเป็นสิ่งที่นักพัฒนาควรจำไว้ การพัฒนาตัวเองในโดเมนหนึ่ง (งานวิจัยที่ตรวจคำตอบอัตโนมัติไม่ได้) อาจทำให้ความสามารถด้านเขียนโค้ดลดลงโดยไม่มีใครสังเกต ถ้านำแนวคิดนี้ไปใช้ ควรมีชุด eval ด้านโค้ดเป็นตัวเฝ้าระวังเสมอ ไม่ใช่วัดแค่โดเมนที่ฝึก

---

แหล่งข่าว

• Sakana AI — MASS: Recursive self-improvement through collective intelligence
• arXiv 2610.12176 — Recursive Self-Improvement through Multi-Agent Self-Supervision
• GitHub — SakanaAI/mass (README + benchmark table)
• Epoch AI — Can AI automate AI R&D yet? Early evidence from InnovationEval