Fable 5 vs. GPT-5.6 Sol: /goal ช่วยได้ไหมในปัญหา NP-hard?

• จากการให้แก้ปัญหาเพิ่มประสิทธิภาพเครือข่ายใยแก้วนำแสงที่ยังไม่เปิดเผยครั้งละ 30 นาที พบว่า Fable 5 ได้คะแนนดีที่สุดและมีประสิทธิภาพเสถียรที่สุด แต่ /goal ไม่ได้สร้างการปรับปรุงอย่างสม่ำเสมอ
• /goal ไม่ใช่แค่ฟีเจอร์ที่ทำให้ทำงานนานขึ้น แต่เปลี่ยน ลูปควบคุมและเส้นทางการสำรวจ จึงอาจทำให้ทั้งกลยุทธ์ที่ดีและกลยุทธ์ที่ผิดดำเนินต่อไปได้
• /goal ชนะ 4 จาก 6 การเปรียบเทียบระหว่าง Fable 5 กับ GPT-5.6 Sol แต่คะแนนเฉลี่ยกลับ แย่ลง 759 และ 868 คะแนน ตามลำดับ เพราะมีบางครั้งที่ประสิทธิภาพตกลงอย่างมาก
• Fable 5 โหมดปกติมีความเสถียรที่สุด ด้วยคะแนนเฉลี่ย 32,386 และช่วงคะแนน 319 คะแนน ส่วนโหมด /goal ทำสถิติดีที่สุดโดยรวมที่ 31,934 คะแนน
• ในงานเพิ่มประสิทธิภาพที่ยาก สิ่งสำคัญไม่ใช่ว่าทำซ้ำหรือไม่ แต่คือ คุณภาพของกลยุทธ์ที่ถูกทำซ้ำ และอัตราชนะรายครั้งกับประสิทธิภาพเฉลี่ยอาจให้ข้อสรุปตรงข้ามกันได้

---

ปัญหาเพิ่มประสิทธิภาพเครือข่ายใยแก้วนำแสง KIRO

• KIRO เป็นปัญหา Operations Research ที่เคยถูกส่งเข้าแฮ็กกาธอนสำหรับนักศึกษาวิศวกรรมในปี 2018 โดยต้องใช้เมทริกซ์ระยะทางแบบมีทิศทางของ Grenoble, Nice และ Paris เพื่อลดความยาวสายเคเบิลรวมให้ต่ำที่สุด
• เครือข่ายประกอบด้วยลูปซ้ำที่เริ่มจากฮับกระจายสัญญาณ และแขนงสั้นที่แยกออกจากทาวเวอร์บนลูป
  • ทาวเวอร์ทั้งหมดต้องปรากฏอย่างถูกต้องเพียงครั้งเดียว
  • ต้องเป็นไปตามข้อจำกัดเชิงโครงสร้างหลายอย่าง
  • ช่วงสายเคเบิลอาจมีต้นทุนต่างกันเมื่อกลับทิศทาง
  • คะแนนยิ่งต่ำยิ่งเป็นคำตอบที่ดีกว่า
• baseline ของมนุษย์คือ C++ solver ที่เคยเขียนขึ้นตลอดหนึ่งสัปดาห์เพื่อแก้ปัญหานี้

• ขนาดของพื้นที่ค้นหา

  • เนื่องจากจำนวนและขนาดของลูป รวมถึงจุดอ้างอิงและลำดับของแขนงแตกต่างกัน จึงยากที่จะคำนวณพื้นที่ค้นหาทั้งหมดด้วยสูตรปิดเพียงสูตรเดียว
  • แค่นับกรณีการจัดสรรเทอร์มินัล 532 จุดของ Paris ให้กับฮับกระจายสัญญาณ 11 จุด โดยไม่พิจารณาลำดับและแขนง ก็มี 11^532 แบบแล้ว
  • แม้จะคำนวณเฉพาะคำตอบที่ถูกต้องแบบจำกัด ซึ่งใช้ลูป 19 ลูปที่มีเทอร์มินัลลูปละ 28 จุดและไม่มีแขนง พื้นที่ค้นหาก็อยู่ราว 10^1223
  • เนื่องจาก 19 × 28 = 532 จึงครอบคลุมเทอร์มินัลทั้งหมด
  • แต่ละลูปไม่เกินขีดจำกัด 30 เทอร์มินัล
  • สูตรคำนวณคือ (532! / 19!) × 11^19 ≈ 10^1223

โมเดลและเงื่อนไขการรัน

• เปรียบเทียบตระกูล Claude ได้แก่ Fable 5·Opus 4.8·Sonnet 5 กับตระกูล GPT ได้แก่ GPT-5.6 Sol·Terra·Luna
• แต่ละโมเดลรันทั้งโหมดปกติและโหมดเนทีฟ /goal
  • เวลาสำหรับการเพิ่มประสิทธิภาพคือ 30 นาที
  • ขีดจำกัดเวลาของเอเจนต์ภายนอกคือ 1,900 วินาที
  • การตั้งค่า reasoning ใช้ค่าสูงสุดที่แต่ละโมเดลรองรับ
  • สภาพแวดล้อมการรันคือ Harbor 0.1.43, Docker และการยืนยันตัวตนแบบ subscription
• ก่อนอื่น รันแบบไม่มี hint เป็นเวลา 30 นาที ทั้งโหมดปกติและโหมด /goal สำหรับทุกโมเดลอย่างละหนึ่งครั้ง
• สำหรับ Fable 5 และ GPT-5.6 Sol ซึ่งเป็นเป้าหมายเปรียบเทียบหลัก ทำซ้ำจนได้ คู่รันที่จับคู่กัน 3 คู่ สำหรับแต่ละโมเดล
• โค้ดทั้งหมด พรอมป์ ตารางผลลัพธ์ เกณฑ์การตัดออก และ trace การรัน อยู่ที่ CLIArena และเป็นการทดลองต่อจาก บทความ benchmark ก่อนหน้า

ผลลัพธ์ของ Fable 5 และ GPT-5.6 Sol

• หากค่าคะแนน /goal ลบด้วยคะแนนโหมดปกติเป็นลบ แปลว่า /goal ให้ผลดีกว่า
• ผลการรันสามครั้งของ Fable 5 มีดังนี้
  • ครั้งที่ 1: โหมดปกติ 32,197 คะแนน, /goal 31,934 คะแนน ดีขึ้น 263 คะแนน
  • ครั้งที่ 2: โหมดปกติ 32,516 คะแนน, /goal 32,324 คะแนน ดีขึ้น 192 คะแนน
  • ครั้งที่ 3: โหมดปกติ 32,446 คะแนน, /goal 35,178 คะแนน แย่ลง 2,732 คะแนน
• ผลการรันสามครั้งของ GPT-5.6 Sol มีดังนี้
  • ครั้งที่ 1: โหมดปกติ 33,581 คะแนน, /goal 39,371 คะแนน แย่ลง 5,790 คะแนน
  • ครั้งที่ 2: โหมดปกติ 35,539 คะแนน, /goal 32,703 คะแนน ดีขึ้น 2,836 คะแนน
  • ครั้งที่ 3: โหมดปกติ 33,663 คะแนน, /goal 33,313 คะแนน ดีขึ้น 350 คะแนน

• เหตุผลที่อัตราชนะกับค่าเฉลี่ยสวนทางกัน

  • /goal ชนะ 4 จาก 6 ครั้ง แต่ทั้งสองโมเดลมักได้การปรับปรุงเล็กน้อยบ่อยครั้ง แลกกับการเจอประสิทธิภาพตกหนักเป็นบางครั้ง
  • Fable 5 โหมดปกติมีค่าเฉลี่ย 32,386 คะแนน ส่วน /goal เฉลี่ย 33,145 คะแนน จึง แย่ลง 759 คะแนน
  • เมื่อดูค่ามัธยฐาน ถือว่าดีขึ้น 192 คะแนน
  • GPT-5.6 Sol โหมดปกติมีค่าเฉลี่ย 34,261 คะแนน ส่วน /goal เฉลี่ย 35,129 คะแนน จึง แย่ลง 868 คะแนน
  • เมื่อดูค่ามัธยฐาน ถือว่าดีขึ้น 350 คะแนน
  • ค่าเฉลี่ยของ Fable 5 โหมดปกติดีกว่า Sol 1,875 คะแนน และค่าเฉลี่ย /goal ก็นำหน้า 1,984 คะแนนเช่นกัน
  • ความแตกต่างยังปรากฏในด้านเสถียรภาพด้วย
    • ผลลัพธ์ทั้งสามของ Fable 5 โหมดปกติอยู่ในช่วง 319 คะแนน
    • Sol โหมดปกติกระจายอยู่ในช่วง 1,958 คะแนน
  • Fable 5 /goal ทำคะแนนดีที่สุดโดยรวมที่ 31,934 คะแนน
  • configuration ที่ปลอดภัยที่สุดคือ Fable 5 โหมดปกติ

/goal เดียวกัน แต่ implementation ต่างกัน

• โมเดลประเมินแยกของ Claude Code

  • /goal ของ Claude Code ทำงานเป็น Stop hook ระดับ session
  • ทุกครั้งที่โมเดลหลักจบหนึ่ง turn โมเดลประเมินค่าเริ่มต้นคือ Haiku จะอ่านเงื่อนไขเป้าหมายกับบทสนทนา แล้วตอบ yes หรือ no พร้อมเหตุผล
  • หากเป็น no จะเริ่ม turn ใหม่ และหากเป็น yes จะปลดเป้าหมายออก
  • โมเดลประเมินไม่สามารถใช้เครื่องมือหรือตรวจไฟล์ได้ และตัดสินได้เฉพาะหลักฐานที่ปรากฏในประวัติบทสนทนาเท่านั้น
  • มันตรวจจับสถานการณ์ที่จบงานเร็วเกินไปได้ แต่บอกไม่ได้ว่าคุ้มไหมที่จะวน solver เพิ่มอีก 10 ล้านครั้ง
  • เนื่องจาก Claude Code ไม่ใช่โอเพนซอร์ส ข้อมูล implementation จึงอ้างอิงจาก เอกสาร goal ของ Anthropic

• สถานะถาวรและเครื่องมือ lifecycle ของ Codex

  • Codex CLI 0.144.4 ที่ใช้ใน benchmark มองเป้าหมายเป็น สถานะถาวร ที่ผูกกับ thread
  • TUI บันทึกเป้าหมายของ thread ที่ใช้งานอยู่ และ SQLite บันทึกสถานะกับการใช้งบประมาณ
    • implementation ของ TUI
    • schema ของ SQLite
  • โมเดลงานได้รับเครื่องมือ create_goal, get_goal, update_goal
  • เมื่อ thread กลายเป็น idle ขณะที่เป้าหมายยัง active ระบบจะฉีด turn ถัดไปที่มีเป้าหมายและการตรวจสอบการทำงานเสร็จ
    • implementation ของ runtime
    • พรอมป์ต่อเนื่อง
  • Claude ให้โมเดลประเมินอิสระตัดสินการเสร็จงาน แต่โมเดลนั้นดูได้เฉพาะประวัติบทสนทนา
  • ใน Codex โมเดลงานใช้ไฟล์และเครื่องมือได้ ประกาศการเสร็จงานเอง และถ้าเป้าหมายถาวรยัง active อยู่ ก็จะกลับมาทำงานต่อ

วิธีที่ /goal ขยายผลกลยุทธ์

• งานเขียนโค้ดทั่วไปตรวจสอบความคืบหน้าได้ง่าย เช่น ใช้ turn เพิ่มเพื่อแก้เทสต์หรือทำ migration ให้เสร็จ
• ในงานเพิ่มประสิทธิภาพ หลังจากเอเจนต์เลือก solver แล้ว เวลาที่เพิ่มเข้ามาอาจ ขยายผลทั้งการตัดสินใจที่ดีและไม่ดี
• กรณีที่ /goal ช่วยได้ มีดังนี้
  • ทำให้พอร์ตโฟลิโอที่คอมไพล์เร็วของ Fable 5 รันต่อไป
  • ทำให้กลยุทธ์แบ่ง chain ใหม่ที่ประสบความสำเร็จของ Sol ดำเนินต่อไป
• ในทางกลับกัน ก็มีกรณีที่ทำให้ประสิทธิภาพแย่ลง
  • Fable 5 สร้าง solver ที่ช้าแล้วรันต่อไปเรื่อย ๆ
  • Sol ยึดติดกับ exhaustive search ที่ไล่ดูทุกจุดอ้างอิง
• ค่ามัธยฐานดีขึ้นเล็กน้อย แต่หางของผลลัพธ์แย่ ๆ กลับแย่ลงมากกว่า ทำให้ประสิทธิภาพเฉลี่ยลดลง

ข้อจำกัดในการตีความผลลัพธ์

• สิ่งที่ทดลองคือ ปัญหา NP-hard หนึ่งปัญหา ที่ยังไม่เปิดเผย จึงไม่ควรถูกมองเป็น leaderboard การเขียนโค้ดทั่วไป
• มีเพียง Fable 5 และ Sol ที่ได้คู่รันที่จับคู่กันอย่างสะอาดอย่างละ 3 คู่
• การเปรียบเทียบโมเดลอื่นมีพรอมป์ เวอร์ชัน wrapper และเวลาจำกัดที่แตกต่างกันปะปนอยู่
• เนื่องจากรันแบบลำดับผ่านบริการ subscription สถานะของบริการอาจเปลี่ยนไประหว่างการทดลอง
• metadata ของงานบันทึกว่าใช้ CPU 1 ตัว แต่ container เห็น CPU 8 ตัว ซึ่งเอื้อให้พอร์ตโฟลิโอแบบขนานของ Fable 5 ได้เปรียบ
• เนื่องจาก wrapper กำหนดให้มี checkpoint ระหว่างทางและการตรวจสอบขั้นสุดท้าย output ทั้งหมดของ Fable 5 และ Sol ที่นับคะแนนจึงถูกต้อง
• สิ่งที่วัดไม่ใช่ตัวโมเดลล้วน ๆ แต่เป็นระบบทั้งหมดที่รวม โมเดล·CLI·พรอมป์·บริการ subscription·harness

ข้อมูลสำหรับทำซ้ำและข้อสรุป

• CLIArena เปิดเผยงาน benchmark, wrapper, สคริปต์วิเคราะห์, ตัวสร้างกราฟ และบันทึกหลักฐานทั้งหมด
• ไดเรกทอรีงานดิบมีขนาดใหญ่จึงถูกตัดออกจาก Git แต่ในบันทึกมีคะแนนทั้งหมดที่เปิดเผยได้ ผลลัพธ์รายเมือง เวลาที่ใช้ กลยุทธ์ รายการที่ตัดออก และ run ID
• คำสั่งรันหลักมีดังนี้

RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh
uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...

• /goal ไม่ได้ทำให้ประสิทธิภาพดีขึ้นหรือแย่ลงแบบเหมารวม และแม้จะชนะการรันรายครั้งส่วนใหญ่ ก็อาจทำให้ประสิทธิภาพเฉลี่ยที่สังเกตได้แย่ลง
• ในงานเพิ่มประสิทธิภาพที่ยาก สิ่งที่สำคัญกว่าคือคุณภาพของกลยุทธ์ที่ลูปนั้นทำซ้ำ ไม่ใช่ คุณภาพของลูปควบคุมเอง

[GN⁺]

ความคิดเห็นจาก Hacker News

• กราฟด้านบนค่อนข้างชวนสับสน เขียนไว้ว่า “ยิ่งต่ำยิ่งดี” แต่แกน y ถูกกลับด้าน ทำให้ในเชิงภาพด้านบนดูดีกว่า ส่วนในเชิงตัวเลขคือยิ่งต่ำยิ่งดี

  • ดูไม่เหมือนว่าแกนถูกกลับด้านนะ 32,000 อยู่ด้านล่าง และ 40,000 อยู่ด้านบน ดังนั้นอาจถูกแก้หลังจากมีคอมเมนต์ก็ได้

• Claude มีแนวโน้มจะลืมคำสั่งในงานระยะยาวที่ลากต่อเนื่องหลายสัปดาห์ ต่อให้ย้ำว่าสำคัญแค่ไหนก็ตาม ผมไม่ได้ใช้ /goal แต่เดาว่ามันน่าจะช่วยให้จดจำคำสั่งหลักได้จริง ๆ กรณีนี้ดูเหมือนจะพูดถึงเซสชันสั้น ๆ ที่ปัญหานี้เกิดน้อยกว่า

  • ผมลองใส่ ปริมาณการใช้คอนเท็กซ์ ไว้ในแถบสถานะของ Claude Code แล้วดูเหมือนว่ามันเริ่ม “ล้า” จริง ๆ ตั้งแต่ประมาณ 50~60% ผมขอให้แก้สภาพแวดล้อมทดสอบและเพิ่มเทสต์ มันผัดไปโดยบอกว่าเป็น “งานโครงสร้างพื้นฐานค่อนข้างมาก” แต่หลังจาก /compact แล้วขอใหม่ มันก็ทำให้โดยไม่บ่น
    อย่างไรก็ตาม /compact มีข้อผิดพลาดบ่อย จึงไม่แนะนำให้ใช้ระหว่างทำงานอยู่ มันมีประโยชน์เมื่อเปลี่ยนไปงานใหม่ที่เกี่ยวข้องกัน แต่ไม่เหมาะกับการแก้สิ่งที่ต้องใช้บริบทของกระบวนการสร้าง เช่น deadlock ในโค้ดที่เพิ่งเขียน เพราะมันจะทิ้งกระบวนการคิดไป
  • นี่เป็นหนึ่งในข้อดีของ pi ผมทำ คำสั่ง /protect เพื่อไม่ให้ข้อความถูกนำไปบีบอัด และยังปกป้องสกิลโดยอัตโนมัติด้วย สำหรับงานระยะยาวก็ใช้ประมาณว่า /protect your goal is...
  • จากที่ใช้ Claude และ GPT เป็นเวลานานในหลายสภาพแวดล้อมการรัน ผมเห็นด้วยว่าสาเหตุคือ การบีบอัดคอนเท็กซ์ การบีบอัดของ Codex รักษาบทสนทนาต่อเนื่องได้เป็นธรรมชาติราวกับเวทมนตร์ แต่กับ Claude ต้องคอยจัดการจังหวะการบีบอัดอย่างละเอียด
  • คุณภาพตกลงตั้งนานก่อนจะถึงจุดบีบอัดแล้ว การแจ้งเตือนเรื่องการบีบอัดเหมือนป้าย “ปั๊มน้ำมันถัดไปอีก 100 ไมล์” แต่จริง ๆ คุณอยู่กลางแดนรกร้างไปแล้ว
    ไม่จำเป็นต้องมีขั้นตอนซับซ้อนเกินไป แต่ลำดับที่ดีคือ แยกงาน → วางแผนในคอนเท็กซ์ใหม่ → ลงมือในคอนเท็กซ์ใหม่ → /code-review ในคอนเท็กซ์ใหม่ → แก้ไขในคอนเท็กซ์ใหม่ ใน Fable 5 ถ้าคอนเท็กซ์เกิน 50% คุณภาพจะตกลงอย่างมาก จนบางทีมีการใช้งานแบบเดียวกันโผล่ใน codebase ซ้ำถึงสี่ครั้ง การให้มันรีวิวงานของตัวเองในเซสชันเดียวกันก็คล้ายกับให้เด็กนักเรียนตรวจข้อสอบของตัวเอง
  • ใน คอนเท็กซ์ประมาณ 700,000 โทเค็น Fable ก็มีวิจารณญาณตกลงอย่างมากเช่นกัน การตัดสินใจของ OpenAI ที่จำกัดคอนเท็กซ์ของ Codex ไว้ที่ 400,000 อาจถูกต้อง และดูเป็นจุดเหมาะสมที่ยังเชื่อถือบริบทส่วนใหญ่ได้

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

  • Ultra mode ควรเขียนเอกสารให้ชัดขึ้นหรือใส่ข้อความเตือน นักพัฒนาหลายคนรวมถึงผมเข้าใจว่ามันเป็นฟีเจอร์ครอบจักรวาลที่ทำให้โมเดลทำงานหนักขึ้นและให้ผลลัพธ์ดีกว่า แต่ในงานจำนวนมากมันอาจทำผลงานแย่ลงด้วยซ้ำ และค่าใช้จ่ายสูงขึ้นแน่นอน

• Anthropic กำลังตามหลัง OpenAI อย่างมากในด้านการเขียนโค้ด จนถึงเดือนมีนาคมที่ผ่านมา ผมใช้ Claude Code จัดการ รีโพซิทอรีขนาดรวม 400,000 บรรทัด ในแพ็กเกจพื้นฐาน แต่มันช้ามาก และแม้จะมีเทสต์, observability, เอกสาร และสถาปัตยกรรมแบบแบ่งชั้น ก็ยังแก้ปัญหาได้ไม่ถูกต้อง
  เราเป็นทีม 3 คนที่ส่งมอบงานให้รัฐบาลท้องถิ่น หลังย้ายมา Codex ก็สบายขึ้นมาก และความกังวลเรื่องโควตาการใช้งานก็หายไป ตอนนี้แต่ละสมาชิกใช้บัญชี Codex Plus คนละสองบัญชีเพื่อดูแลทั้งหมด Anthropic ควรสร้างโมเดลที่มีประสิทธิภาพมากกว่าจะปลุกปั่นความกลัว และไม่ใช่ทุกคนจำเป็นต้องใช้ Fable

  • สำหรับผม Opus 4.8 ยอดเยี่ยมมาก ส่วน Codex ก็เฉย ๆ น่าจะขึ้นอยู่กับผู้ใช้และงาน
  • แตกต่างกันมากตามโดเมนปัญหาและภาษา GPT แย่มากในการเขียน Elixir และงานปลายเปิด ตอนนี้ Opus แข็งแกร่งกว่าใน Elixir และ Fable เข้าใจโดเมนปัญหาเองได้ดีกว่าทั้งสองมาก
    ตลอด 6 สัปดาห์ที่ผมเปลี่ยนไปใช้ GPT มันให้ความมั่นใจผิด ๆ อย่างต่อเนื่อง จนสุดท้ายต้องหยุดใช้โดยสิ้นเชิง และงานช่วงนั้นแทบถือว่าเสียเปล่า ตอนนี้ผมใช้ Opus/Fable กับ DeepSeek Pro ผสมกัน DeepSeek เหนือกว่าอย่างชัดเจนในแง่ความคุ้มค่าและความเร็ว และเพียงพอสำหรับงาน implement 90% แต่จะพังเมื่อพยายามใช้ฟีเจอร์ runtime ในช่วง compile-time ของ Elixir ปัญหาเริ่มต้น Fable ช่วยจัดระเบียบได้อย่างรวดเร็ว
    โมเดลแต่ละตัวมีจุดแข็งเฉพาะที่ค้นพบได้ยาก ดังนั้นในอนาคตอันใกล้คงยังไม่เหลือใช้แค่ตัวเดียว เมื่อต้องการคุณภาพ ผมยินดีแลกกับประสิทธิภาพ

• /goal ในงานของผมเข้ามาแทนที่โหมดวางแผนแล้ว และผมใช้วิธีต่อไปนี้กับงาน AI 95%
  ก่อนอื่นให้มันอ่านฟีเจอร์เฉพาะอย่างหนึ่งและตรวจสอบว่าเข้าใจครบถ้วนหรือไม่ หากมีรายละเอียดตกหล่นในสรุปก็ให้ทำซ้ำ ถามเวลาปัจจุบัน จากนั้นใช้ /goal ให้เขียนเอกสารออกแบบเชิงเทคนิคที่ไม่กำกวมภายในช่วงเวลาหนึ่ง และให้สะท้อน carry_forward_requirements.md กับ testing_best_practices.md อย่างชัดเจน ใส่การอ้างอิงโค้ด/เอกสารและรายการเปลี่ยนแปลงที่เป็นรูปธรรมเพื่อให้ผู้ลงมือทำที่ไม่มีบริบทก็ทำตามได้ และให้ใช้เวลาทั้งหมดตรวจทาน ไม่ให้จบก่อนเวลา
  แค่บังคับให้ GPT เขียนเอกสารออกแบบเพียง 10 นาที ผลลัพธ์ก็แข็งแรงกว่าโหมดวางแผนมาก ช่วยประหยัดเวลาที่ต้องใช้แก้ร่างได้

  • การให้จบตามเวลาดูคล้ายกับการกำหนดเงื่อนไขจบของฟังก์ชันรีเคอร์ซีฟด้วย เวลาที่ผ่านไป แทนที่จะเป็นผลลัพธ์จากการทำงานจริง
    ผมใส่เป้าหมายที่ชัดเจนซึ่งเอเจนต์ต้องทำให้สำเร็จไว้ใน /goal กำหนดเงื่อนไขที่การออกแบบและสถาปัตยกรรมต้องเป็นไปตาม แล้วเทียบผลลัพธ์ไปเรื่อย ๆ และให้จบเมื่อบรรลุครบทั้งหมดจะดีกว่า ไม่ว่าจะ 10 นาทีหรือ 10 ชั่วโมง แก่นของ /goal คือการทำผลลัพธ์เฉพาะให้เสร็จสมบูรณ์
  • ถ้าจะให้เอเจนต์บรรลุเป้าหมายได้อย่างเสถียร ขั้นตอนการสร้างสมมติฐาน ดูเหมือนสำคัญที่สุด การเริ่มจากพื้นที่ค้นหาที่ถูกต้องตั้งแต่แรกเป็นตัวทำนายความสำเร็จที่ดีที่สุด และไม่ว่าโมเดลจะเก่งแค่ไหน วิธีที่ให้มันฝ่าทุกสมมติฐานตั้งแต่ต้นด้วยลูปขนาดมหึมาลูปเดียวก็น่าจะเป็นทางตันในงานจริง
    ในโดเมนที่ซับซ้อน การมอบหมายการสืบค้นเชิงลึกให้เป็นการเรียกใช้เครื่องมือแยกต่างหากเป็นวิธีที่ดีที่สุดในการวางรากฐานให้เอเจนต์ หากให้ลูปหลักของเอเจนต์ทำการสืบค้นเอง คุณภาพจะแย่ลงเพราะ RLHF มีแนวโน้มจะรักษาคอนเท็กซ์และรีบตอบ แต่ถ้าให้เป็นเครื่องมือ มันสามารถสืบค้นได้หลายครั้งราวกับไม่รู้ว่ากำลังใช้โทเคนเป็นพันล้าน และแม้จะเสียโทเคนมากไปกับการสร้างและตรวจสอบสมมติฐานอย่างอิสระ ก็สามารถขยาย พื้นที่ค้นหาได้ 10~100 เท่า ก่อนเปลี่ยนสภาพแวดล้อม ในหลายกรณี ลำดับความสำคัญ ความถูกต้อง > เวลา > ต้นทุน นั้นสมเหตุสมผล
  • การมองว่า LLM “เข้าใจอย่างครบถ้วน” ในบางสิ่งนั้นดูแปลก คล้ายเทคนิคพรอมป์อย่าง “จนกว่าจะมั่นใจ 95%” และอยากรู้ว่ามีผลต่องานจริงอย่างไรบ้าง ถ้าเขียนว่า “จนกว่าจะเข้าใจอย่างแน่ชัด” แล้วอะไรเปลี่ยนไปก็ยังน่าสงสัย

• สงสัยว่า /goal คืออะไร

  • ทั้ง Codex และ Claude Code มีให้ใช้ แต่กลไกต่างกันเล็กน้อย
    Claude Code ให้ Haiku อ่านประวัติการสนทนาและตัดสินว่าเป้าหมายเสร็จแล้วหรือไม่ หากยังไม่เสร็จก็ป้อนงานที่เหลือกลับเข้าโมเดลหลัก ใน Codex เครื่องมือที่โมเดลหลักเรียกใช้ได้จะทำงานร่วมกับสภาพแวดล้อมการรันรอบข้าง และถ้าไม่มีเครื่องหมายว่าเสร็จแล้วก็จะพรอมป์ซ้ำ
    เป็นฟีเจอร์ที่พยายามแก้สถานการณ์ที่โมเดลทำงานเสร็จแค่บางส่วนแล้วหยุดเพราะปัญหาด้านความใส่ใจ แทนที่ผู้ใช้จะต้องเร่งให้ทำต่อเอง ระบบจะสั่งเพิ่มอัตโนมัติเพื่อผลักดันให้งานเสร็จ
  • ถ้าใช้ /goal ใน Claude ตั้งแต่แรก มันจะไม่หยุดจนกว่าจะบรรลุเป้าหมายหรือใช้ความเป็นไปได้ของพรอมป์จนหมด ให้ความรู้สึกแบบ “นี่คือภารกิจ จงทำ” และผมใช้สัปดาห์ละไม่กี่ครั้ง
  • เป็นฟีเจอร์ที่รัน LLM ซ้ำจนกว่า เงื่อนไขเป้าหมาย จะถูกเติมเต็ม
  • พูดให้ถูกคือ มันทำซ้ำจนกว่าจะตัดสินเองว่าเป้าหมายเสร็จแล้ว
  • โครงสร้างคือเอเจนต์เองรัน LLM ซ้ำแล้วตัดสินว่าจะหยุดหรือไม่ /goal คล้ายกับการวางเอเจนต์แม่เพิ่มอีกชั้นเหนือสิ่งนั้น แล้วสั่งซ้ำว่า “ยังไม่เสร็จ ทำต่อ” จนกว่าเอเจนต์ลูกจะตัดสินว่าเสร็จแล้ว

• หลังเปิดตัว ผมใช้ทั้ง GPT 5.6 Sol Xhigh และ Fable 5 ไปมาก ความฉลาดใกล้เคียงกับ 5.5 แต่ดูเหมือนเพิ่มความดื้อ/อึดแบบสุดขั้ว ทำให้อัตราการทำงานสำเร็จและความสามารถในการแข่งเบนช์มาร์กดีขึ้น ในทางกลับกันมีโอกาสสูงขึ้นที่จะใช้วิธีผิดปกติหรืออันตราย จึงต้องคอยเฝ้าดู
  ช่วงหลังมันพยายามอ่านตัวแปรสภาพแวดล้อมของระบบปฏิบัติการที่ไม่เกี่ยวกับงานผ่าน CLI และเมื่อเข้าถึงคีย์ SSH ไม่สำเร็จ ก็ขอสิทธิ์ควบคุมคอมพิวเตอร์ หลังจากหยุดแล้วถามเหตุผล มันตอบว่าพยายามค้นหา key โดยไปรื้อ 1Password เอง และเมื่อซักต่อก็ยอมรับว่าไม่จำเป็นต้องใช้ตัวแปรสภาพแวดล้อมของระบบปฏิบัติการ หลังจากนั้นผมปิดโหมด “approve for me” และใช้เฉพาะกับการเปลี่ยนแปลงง่าย ๆ กับการแก้บั๊กเท่านั้น
  Fable ไม่เพียงฉลาดกว่า แต่ยังมี insight สูงกว่า จับเจตนาได้ดี และอาศัยความรู้โลกจริงทำตัวเหมือนผู้จัดการผลิตภัณฑ์ที่เชี่ยวชาญโดเมน มันยังเสนอสิ่งที่ไม่คาดคิดด้วย แต่กับ GPT 5.6 ต้องสั่งแบบตรงตามตัวอักษรมากกว่ามาก

  • Fable ดูเป็นโมเดลที่ใหญ่กว่า ทำให้ต้นทุนการรันสูงกว่า และในงานวิศวกรรมซอฟต์แวร์ทั่วไปไม่ได้ดูเหนือกว่า แต่ในงานที่ต้องใช้ความฉลาดล้วน ๆ ขนาดอาจเป็นข้อได้เปรียบ
    ใน DeepSWE 1.1 5.6-Sol xhigh ได้คะแนนสูงกว่า Fable 5 เล็กน้อย ขณะที่ใช้โทเคนครึ่งหนึ่งและต้นทุนราวหนึ่งในสาม ในทางกลับกัน ดัชนีความฉลาดของ Artificial Analysis นั้น Fable 5 นำเล็กน้อย แต่ต้นทุนสูงกว่าสามเท่า
    เวลาจะเขียนโค้ด ผมส่งงานเดียวกันให้ทั้งสองโมเดลเพื่อรับคำตอบหลายแบบ แต่ผลลัพธ์ค่อนข้างเป็นอัตวิสัย จึงคาดเดายากว่าฝั่งไหนจะชนะ งานในต้นฉบับมีข้อดีตรงที่วัดเป็นตัวเลขได้ แต่งานซอฟต์แวร์จำนวนมากประเมินแบบนั้นได้ยาก

• GPT เพิ่งเอาชนะผู้เข้าร่วมมนุษย์ระดับท็อปใน AtCoder Heuristic Contest ดังนั้นควรจะแข็งแกร่งกว่าในโจทย์เพิ่มประสิทธิภาพแบบนี้ ดูเหมือน Anthropic จะโฟกัสกับประเภทนี้ค่อนข้างน้อยกว่า

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

• การประเมินมีเพียงครั้งเดียวต่อโมเดล และเป็นพื้นที่ปัญหากว้างที่ต้องลองหลายครั้งถึงจะแก้ได้ดี ผลลัพธ์ส่วนใหญ่จึงดูเหมือน noise

  • จริง ๆ แล้วมีการรันเพิ่มอีกมากโดยเปลี่ยนพรอมป์และเวลารัน แต่ทุกครั้งผลของ /goal เล็กน้อยหรือไม่มีนัยสำคัญ