Sakana Fugu มาแล้ว — API ที่จัดทีมโมเดล แบ่งบทบาททำงานแทน เคลมแตะระดับ Fable 5

แล็บ AI จากญี่ปุ่นชื่อ Sakana ปล่อยของใหม่ชื่อ Sakana Fugu ออกมา ให้นึกภาพง่าย ๆ ว่ามันคือ "หัวหน้าทีมโมเดล" ที่ยัดอยู่หลัง API เดียว แทนที่จะถามโมเดลตัวเดียวแบบปกติ คุณส่งคำถามหนึ่งครั้ง ระบบจะแบ่งบทบาทให้โมเดลหลายตัว ทั้งโมเดลปิดและโมเดลเปิด โดยอัตโนมัติ — บางตัวเป็น "ตัวคิด" (Thinker) วางแผน บางตัวเป็น "ตัวลงมือ" (Worker) ทำงานจริง และบางตัวเป็น "ตัวตรวจ" (Verifier) คอยเช็กงาน แล้วคุมให้ทุกตัวทำงานประสานกันหลายขั้นจนได้คำตอบที่ดีที่สุด จุดสำคัญคือมันไม่ใช่ต่างคนต่างตอบแล้วโหวต แต่เป็นการจัดทีมแบ่งหน้าที่กันทำให้จบเป็นงานเดียว

จุดสะดวกคือคุณไม่ต้องไปสมัครหรือจัดการแต่ละโมเดลเอง ตัว API จัดการเรื่องเลือกโมเดล แบ่งบทบาท และคุมงานให้อัตโนมัติ คุณแค่ถือคีย์เดียวแล้วใช้ (เบื้องหลังอ้างอิงงานวิจัย TRINITY และ Conductor ที่เพิ่งนำเสนอใน ICLR 2026)

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

ฝั่ง benchmark ที่ผู้ผลิตปล่อยมา บน Terminal Bench ตัว Fugu Ultra ทำได้ราว 82.1 เทียบกับ Fable 5 ที่ 80.4 ส่วน LiveCodeBench ได้ราว 93.2 / 92.9 / 89.8 แต่บน SW-Bench Pro ฝั่ง Fable 5 ยังนำอยู่ โดยรวมมันเคลมว่าเสมอหรือชนะ Fable 5 บนหลาย benchmark ขอย้ำว่าตัวเลขพวกนี้เป็นของบริษัทเอง

อย่างแรกคือเรื่องความเร็ว ทั้ง Fugu และ Fusion เป็นระบบ one-shot คุณส่งคำถามแล้วรอ 5–10 นาทีกว่าจะได้คำตอบ คุยโต้ตอบไป-มาเร็ว ๆ แบบ CLI ไม่ได้ ฉะนั้นมันไม่เหมาะเป็นตัวรันงานรายวัน แต่เหมาะกับงานชิ้นใหญ่ที่ต้องการคำตอบดีที่สุดในครั้งเดียว

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

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

ฟันธง: รอ/ลองเฉพาะงานใหญ่ — เอาไว้ใช้ตอนต้องการคำตอบดีที่สุดสำหรับงานสำคัญ เช่น สร้างฟีเจอร์ใหม่หรือตัดสินใจชิ้นโต ไม่ใช่งานโค้ดรายวันที่ต้องแก้ไป-มา และก่อนผูกงานจริง ให้เทสต์โจทย์ของตัวเองเทียบกับ Fusion หรือโมเดลที่ใช้อยู่ก่อนเสมอ บทเรียนเดิมยังใช้ได้: สร้างระบบให้สลับโมเดลได้ อย่าผูกทุกอย่างไว้กับโมเดลตัวเดียว เผื่อวันหนึ่งตัวที่ใช้อยู่หายไป