ออกแบบลูปด้วย Fable 5

• เสนอ 2 เทคนิคหลักเพื่อใช้งาน Claude Fable 5 รุ่นระดับ Mythos-class ให้เกิดประโยชน์สูงสุด ซึ่งได้เปลี่ยนวิธีทำงานภายในของ Anthropic ได้แก่ self-correction loop และ memory
• goal·rubric ที่ออกแบบมาอย่างดีจะฉีด feedback เข้าไปในสภาพแวดล้อม ทำให้ Claude ทำงาน→เก็บ feedback→แก้ไขตัวเอง วนซ้ำจนกว่าจะบรรลุเป้าหมาย
• ในโจทย์วิศวกรรม ML แบบ Parameter Golf นั้น Fable 5 ปรับปรุง training pipeline ได้ ราว 6 เท่า เมื่อเทียบกับ Opus 4.7
• ผ่าน memory ซึ่งเป็น outer loop ที่ข้าม session ได้ Claude สามารถนำสิ่งที่บันทึกไว้ระหว่าง session กลับมาใช้ซ้ำใน session ถัดไป
• ประเด็นสำคัญคือ แทนที่จะ prompt หรือบังคับโมเดลโดยตรง การ ออกแบบลูปให้โมเดลแก้ไขตัวเองและจัดการบริบทด้วยตนเอง มีประสิทธิภาพกว่า

---

Self-correction loop (ลูปแก้ไขตัวเอง)

• แนวทางทั่วไปในการยกระดับประสิทธิภาพงานคือ ปล่อยให้โมเดล hillclimb บนเกณฑ์การประเมิน
  • bcherny กล่าวไว้ว่า "งานของตัวเองคือ การเขียนลูป"
  • /goal ของ Claude Code และ Outcomes ของ Claude Managed Agent คือ primitive ที่นำสูตรนี้ไปใช้กับงานเฉพาะ
• goal หรือ rubric ที่ออกแบบมาดีจะเพิ่ม feedback ให้กับสภาพแวดล้อมที่ Claude ทำงานอยู่ จากนั้นจึงทำงาน เก็บ feedback แก้ไขตัวเอง และดำเนินต่อไปจนกว่าจะตรงตาม goal/rubric

การทดสอบ Parameter Golf

• Parameter Golf คือชาเลนจ์วิศวกรรม ML แบบโอเพนซอร์ส ที่ให้ฝึกโมเดลประสิทธิภาพสูงสุดที่บรรจุใน artifact ขนาด 16MB บน 8xH100 ภายใน 10 นาที
  • ทดสอบความสามารถในการแก้ไขไฟล์ train_gpt.py เพียงไฟล์เดียว รันการฝึก โมเดล polling log ตรวจคะแนน และตัดสินใจการทดลองถัดไป
  • คล้ายกับโปรเจ็กต์ autoresearch ของ karpathy
• ใช้ Claude Managed Agents(CMA) เพื่อเปรียบเทียบ Fable 5 กับ Opus 4.7
  • CMA มีทั้ง agent harness และ sandbox แบบโฮสต์ให้ จึงเหมาะกับงานระยะยาวของ Fable 5
  • สำหรับ Parameter Golf มีการจัดเตรียม GPU 8xH100 เป็น self-hosted sandbox

ความสำคัญของผู้ให้คะแนน

• ยืนยันได้ว่าโมเดลมีปัญหากับ self-critique ต่อผลลัพธ์ของตนเอง (Prithvi Rajasekaran อธิบายไว้ในบล็อกวิศวกรรม)
• verifier sub-agent ทำได้ดีกว่า self-critique เพราะให้คะแนนใน context window ที่เป็นอิสระ
  • Outcomes ของ CMA จะสร้าง grader sub-agent ขึ้นมาให้อัตโนมัติเพื่อจัดการเรื่องนี้
• มีการให้ rubric ที่มีเกณฑ์ตรวจสอบได้ 9 ข้อ (เช่น รัน baseline, ทำการทดลอง 20 ครั้ง ฯลฯ) และให้รันได้นานสูงสุด 8 ชั่วโมง
  • Outcomes grader จะอนุญาตให้ Claude จบงานได้ก็ต่อเมื่อยืนยันแล้วว่าผ่านเกณฑ์การทดลองทั้งหมด

เปรียบเทียบผลลัพธ์

• Fable 5 ปรับปรุง training pipeline ได้ ราว 6 เท่า มากกว่า Opus 4.7
  • เมื่อลองแยกการทดลองเป็นแบบเชิงโครงสร้าง (เปลี่ยนสถาปัตยกรรม) และแบบเชิงสเกลาร์ (ปรับค่าคงที่) Fable 5 จะ กล้าเดิมพันกับการเปลี่ยนแปลงเชิงโครงสร้างที่ใหญ่กว่า และมีความยืดหยุ่นในการฟื้นตัว (ทะลุผ่าน quantization regression ไปจนทำผลงานสูงสุดได้)
• Opus 4.7 หลังจากได้ผลดีเล็กน้อยในครั้งแรก ก็วนใช้เทมเพลตเดิมเป็นส่วนใหญ่: ปรับค่าสเกลาร์·วัดผล·ถ้าดีก็คงไว้

Memory (หน่วยความจำ)

• ทำหน้าที่เป็น outer loop ที่ข้าม session ได้ โดยค้นหาและนำ memory ที่เขียนไว้ระหว่าง session ก่อนหน้ากลับมาใช้ซ้ำ
• ทีม pgasawa เปิดตัว Continual Learning Bench 1.0
  • เป็น benchmark เชิงปฏิบัติจริงตัวแรกที่ใช้วัดว่า AI system ปรับปรุงตัวเองได้มากเพียงใดในสภาพแวดล้อมออนไลน์
  • benchmark เดิมมักสมมติว่าโมเดลเป็น stateless และประมวลผลแต่ละตัวอย่างแยกจากกัน

โครงสร้างการทดสอบ

• ในหนึ่งในโจทย์ของ benchmark มีการเปรียบเทียบ Fable 5·Opus 4.7·Sonnet 4.6
  • เป็นโจทย์ตอบคำถามตามลำดับโดยมีสิทธิ์เข้าถึง SQL database แต่ละคำถามคือ agent session แยกกัน และมี memory ให้ใช้
• ใช้ memory ของ CMA โดยให้ mounted filesystem ที่แชร์ข้าม session ได้กับแต่ละ agent

ขั้นตอนของการใช้ memory อย่างมีประสิทธิภาพ

• การใช้ memory อย่างมีประสิทธิภาพจะแข็งแกร่งขึ้นผ่านลำดับ fail(บันทึกสิ่งที่ผิด)·investigate(หาสาเหตุ)·verify(ทำให้เป็นข้อเท็จจริงที่ตรวจสอบแล้ว)·distill(สกัดเป็นกฎทั่วไป)·consult(อ้างอิงกฎ)
• Sonnet 4.6 มักหยุดอยู่ใกล้ขั้นที่ 1
  • ที่เก็บข้อมูลมีแต่โน้ตความล้มเหลวและรายการข้อคาดเดาที่ยังไม่คลี่คลาย ("maybe prc instead of prc_usd?") และแทบไม่อ้างอิงโน้ตก่อนหน้า
  • หากต้องการให้ประสิทธิภาพดีขึ้น จำเป็นต้องมีคำแนะนำด้าน memory รายโจทย์
• Opus 4.7 มักหยุดอยู่ใกล้ขั้นที่ 3
  • สร้าง schema reference ที่ระบุความไม่แน่นอน ("possibly prc in cents? Verify.") แต่มี coverage ของการตรวจสอบเพียง 7~33% (median ราว 17%)
• Fable 5 มีแนวโน้มจะทำครบกระบวนการ
  • ในรันที่ดีที่สุด มี coverage ของการตรวจสอบสูงสุด 73% (22 จาก 30) และ distill สิ่งที่เรียนรู้ให้เป็นกฎทั่วไปที่ช่วยงานในอนาคตได้

สรุป

• แทนที่จะ prompt หรือบังคับ Fable 5 โดยตรง วิธีที่มีประสิทธิภาพกว่าคือ ออกแบบลูป ให้มันตอบสนองต่อ feedback จากสภาพแวดล้อม (/goal, Outcomes) เพื่อแก้ไขตัวเอง และใช้ memory เพื่อจัดการบริบทด้วยตนเอง
• แนะนำให้ลองทดสอบ Fable 5 โดยตรงกับโจทย์ที่ท้าทาย พร้อมใช้ลูปการแก้ไขตัวเองและ memory