การวัดความสามารถของ AI ในการทำงานระยะยาว

 (metr.org)
10 คะแนน โดย GN⁺ 2025-12-23 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการเสนอเกณฑ์ชี้วัดใหม่สำหรับวัดประสิทธิภาพ โดยอิงจาก ‘ความยาว’ ของงานที่โมเดล AI สามารถทำได้สำเร็จอย่างสมบูรณ์
  • มีการวิเคราะห์ว่าในช่วง 6 ปีที่ผ่านมา ความยาวของงานที่ AI สามารถทำสำเร็จได้ด้วยตัวเองเพิ่มขึ้นเป็นสองเท่าทุกประมาณ 7 เดือน
  • งานที่ผู้เชี่ยวชาญมนุษย์ใช้เวลาไม่เกิน 4 นาทีมีอัตราสำเร็จเกือบ 100% แต่งานที่ใช้เวลามากกว่า 4 ชั่วโมงมีอัตราสำเร็จน้อยกว่า 10%
  • หากแนวโน้มนี้ยังคงอยู่ คาดว่า ภายในไม่กี่ปี AI จะสามารถทำโปรเจกต์ระดับหลายสัปดาห์ได้อย่างอิสระ
  • งานวิจัยนี้มีนัยสำคัญต่อ เบนช์มาร์ก AI การคาดการณ์ความสามารถในอนาคต และการบริหารความเสี่ยง

ภาพรวมของงานวิจัย

  • METR เสนอวิธีใหม่ในการวัดว่า AI สามารถทำงานที่ยาวนานได้แค่ไหน
    • เกณฑ์การวัดคือเวลาที่ผู้เชี่ยวชาญมนุษย์ใช้ในการทำงานนั้น
    • ความสัมพันธ์ระหว่างความน่าจะเป็นที่โมเดลจะทำสำเร็จกับเวลาที่มนุษย์ใช้ทำงาน ถูกจำลองด้วย เส้นโค้งลอจิสติก
  • แนวทางนี้ถูกเสนอให้เป็นตัวชี้วัดที่มีประโยชน์ในการประเมิน ความพร้อมสำหรับการใช้งานจริงของ AI
    • ช่วยเติมเต็มข้อจำกัดของเบนช์มาร์กเดิมที่เน้นความสามารถในการแก้ปัญหาเดี่ยวเป็นหลัก

ผลลัพธ์สำคัญ

  • ขีดจำกัดประสิทธิภาพของโมเดลในปัจจุบัน
    • งานที่มนุษย์ทำได้ภายใน 4 นาที มีอัตราสำเร็จเกือบ 100%
    • งานที่ใช้เวลามากกว่า 4 ชั่วโมง มีอัตราสำเร็จน้อยกว่า 10%
    • ตัวอย่าง: Claude 3.7 Sonnet มีอัตราสำเร็จ 50% สำหรับงานที่มีความยาวประมาณ 1 ชั่วโมง
  • แนวโน้มการพัฒนาประสิทธิภาพ
    • ในช่วง 6 ปีที่ผ่านมา ความยาวของงานที่ทำสำเร็จได้ด้วยความเชื่อมั่น 50% เพิ่มขึ้นเป็นสองเท่าทุกประมาณ 7 เดือน
    • ผลการวิเคราะห์ในสเกลลอการิทึมยืนยันว่าเกิด การเติบโตแบบเอ็กซ์โปเนนเชียลอย่างต่อเนื่อง
    • หากแนวโน้มนี้ยังคงอยู่ ภายใน 2~4 ปีอาจสามารถทำงานระดับหลายสัปดาห์ได้

ระเบียบวิธีและการตรวจสอบ

  • การตรวจสอบโดยอิงชุดข้อมูล
    • มีการบันทึกเวลาที่มนุษย์ใช้ในการทำงานสำหรับกลุ่มงานที่หลากหลาย (เช่น ซอฟต์แวร์ การให้เหตุผล เป็นต้น)
    • ในชุดข้อมูล SWE-Bench Verified ก็พบการเพิ่มขึ้นแบบเอ็กซ์โปเนนเชียลในลักษณะใกล้เคียงกัน
    • ในข้อมูลดังกล่าว พบว่า ความเร็วในการเพิ่มขึ้นเป็นสองเท่าอยู่ต่ำกว่า 3 เดือน
  • การวิเคราะห์ความไว
    • มีการตรวจสอบความทนทานต่อปัจจัยต่าง ๆ เช่น การเลือกโมเดล การเลือกงาน และสัญญาณรบกวน
    • ในการจำลองเพื่อคาดการณ์ช่วงเวลาที่จะทำงานยาว 1 เดือนได้ แม้ความคลาดเคลื่อนในการวัดจะสูง แนวโน้มก็ยังคงเดิม

การตีความและข้อจำกัด

  • ช่วยอธิบาย ช่องว่างระหว่างผลลัพธ์บนเบนช์มาร์กของ AI กับประโยชน์ใช้สอยจริง
    • แม้จะเหนือกว่ามนุษย์ในโจทย์ลักษณะข้อสอบ แต่ ยังทำโปรเจกต์ระยะยาวในโลกจริงได้ไม่ดีนัก
  • ยอมรับ ความไม่แน่นอนของการคาดการณ์จากการลากเส้นแนวโน้มต่อไปในอนาคต
    • หากใช้เฉพาะข้อมูลปี 2024~2025 ช่วงเวลาที่จะทำงานระดับรายเดือนได้จะ เร็วขึ้นราว 2.5 ปี
    • มีการกล่าวถึงความเป็นไปได้ที่แนวโน้มล่าสุด อาจทำนายประสิทธิภาพในอนาคตได้ดีกว่าข้อมูลในอดีต

บทสรุปและความสำคัญ

  • แนวทางการวัดประสิทธิภาพ AI ด้วย ‘ความยาวของงาน’
    • ทำให้สามารถวัดเชิงปริมาณการพัฒนาประสิทธิภาพในงานหลายระดับความยากและหลายโดเมนได้
    • ช่วยให้ตีความผลลัพธ์เชิงสัมบูรณ์ที่ เชื่อมโยงโดยตรงกับผลกระทบในโลกจริง ได้
  • หาก การเติบโตแบบเอ็กซ์โปเนนเชียลอย่างต่อเนื่อง ยังคงดำเนินต่อไป
    • มีแนวโน้มว่า ภายใน 10 ปี AI จะสามารถทำโปรเจกต์อัตโนมัติระดับรายเดือนได้
    • ซึ่งมาพร้อมทั้ง ประโยชน์มหาศาลและความเสี่ยงมหาศาล
  • ข้อมูลงานวิจัยและโค้ดวิเคราะห์ เผยแพร่บน GitHub เพื่อสนับสนุนงานวิจัยต่อยอดและการทดลองทำซ้ำ

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
crawler 2025-12-23

ดูเหมือนจะเป็นเบนช์มาร์กที่ดีมากนะครับ
ช่วงนี้พอดูเครื่องมือ AI สำหรับเขียนโค้ดหลาย ๆ ตัว มักจะให้วางแผนล่วงหน้าแล้วค่อยทำงานในโหมด Agent เลยอยากรู้เหมือนกันว่าสิ่งนี้ส่งผลต่ออัตราความสำเร็จในระยะยาวอย่างมีนัยสำคัญจริงหรือเปล่า
 
GN⁺ 2025-12-23
ความคิดเห็นจาก Hacker News
  • ช่วงนี้ผมขอแค่ให้ “เพิ่ม vector search” ในโปรเจ็กต์งานอดิเรกของตัวเอง แต่ Opus กลับไปตั้งค่า manticore, ดึง embedding model มา, ทำเครื่องมือสำหรับย้ายจาก keyword index เดิม และจัดการฝั่ง frontend ให้เสร็จเลย
    เป็นพรอมป์ตสั้นๆ แค่บรรทัดเดียวแบบทวีต แต่เสร็จใน 15 นาที ระหว่างนั้นผมก็นั่งเล่น Kirby Air Riders อยู่
    แต่สิ่งที่น่าเสียดายคือผ่านกระบวนการนี้มาแล้ว ผมกลับ ไม่ได้เรียนรู้อะไรเลยเกี่ยวกับการสร้าง vector search สุดท้ายเป้าหมายคือฟีเจอร์ ส่วนการเรียนรู้เป็นเรื่องรอง
    • ผมไม่คิดว่าการทำแบบช้าๆ ตั้งใจให้ใช้เวลานาน จะเป็นวิธีเรียนที่มีประสิทธิภาพกว่าเสมอไป
      แทนที่จะใช้เวลา 4 ชั่วโมงทำเอง ผมว่าให้เอเจนต์ทำเสร็จใน 15 นาที ระหว่างนั้นเราไปทำอย่างอื่น แล้วค่อยกลับมาใช้สัก 30 นาทีอ่านโค้ด แก้ไข และถามคำถาม ยังมีประสิทธิภาพกว่ามาก
      การเรียนรู้อย่างจดจ่อ 30 นาที อาจดีกว่าการลองผิดลองถูก 4 ชั่วโมงก็ได้
    • แต่พอทำแบบนั้น สุดท้ายก็จะได้ ก้อนโค้ดยักษ์ที่ดูแลรักษาไม่ได้
      AI เองก็จะค่อยๆ ทำโครงสร้างโค้ดหลุดมือไป และสุดท้ายคุณก็กลายเป็นลูกค้าที่ต้องพึ่ง Opus
    • Opus กับ Anthropic นั้นสุดยอดจริง แต่ทุกครั้งที่ใช้มันให้ความรู้สึกเหมือน ฟาสต์ฟู้ดทางปัญญา
      เมื่อก่อนการเปิดเพลงแล้วแก้ปัญหาด้วย Scala เป็นอะไรที่สนุก แต่ตอนนี้การได้แค่ผลลัพธ์อย่างง่ายดายกลับทำให้รู้สึกว่างเปล่า
    • ผมเห็นด้วยเต็มที่กับประโยคที่ว่า “ผมต้องการฟีเจอร์ ไม่ได้อยากเรียนรู้วิธีสร้างมัน”
      ตอนผมทำโมเดลเทรด ผมก็อยากให้ LLM เขียนโค้ดแทนมากกว่าจะไปนั่งเรียนกราฟเอง
      แบบนี้ทำให้ ไม่ต้องเสียเวลากับการจัดการ API จุกจิก และโฟกัสได้เฉพาะส่วนที่ต้องใช้การตัดสินใจจริงๆ
    • โค้ด vector search นั้น พอจะ แชร์ได้ไหม
  • ก่อนจะได้เจอกับแนวคิดเรื่อง “งานยาว (long task) ” ด้วยตัวเอง ผมก็ไม่ค่อยเข้าใจมันเท่าไร
    ตอนพอร์ต Python HTML5 parser ไปเป็น JavaScript ผมลองให้ Codex CLI รันกับ html5lib-tests จำนวน 9,200 รายการ แล้วการได้เห็นมันวนลูปแก้ปัญหาอยู่นานกว่า 4 ชั่วโมงก็น่าประทับใจมาก
    ผมสรุปเรื่องนี้ไว้ในโพสต์ ที่นี่
    • “งาน 4 ชั่วโมง” ของ METR ไม่ได้หมายความว่า AI ใช้เวลาจริง 4 ชั่วโมง แต่หมายถึง งานที่มนุษย์จะใช้เวลาประมาณ 4 ชั่วโมงตามระดับความยาก
      Opus 4.5 ทำงานระดับนี้ได้ด้วยความน่าเชื่อถือ 50% และเวลาในการรันจริงสั้นกว่านั้นมาก
      ต่อจากนี้ถ้าผ่านเกณฑ์ 8 ชั่วโมงหรือ 40 ชั่วโมงได้เมื่อไรคงน่าสนใจกว่านี้มาก
    • ตัวชี้วัดนี้ไม่ได้วัดความเร็วจริงของ AI แต่เป็นการวัด ระดับความยากตามมาตรฐานมนุษย์
      มันแสดงให้เห็นชัดว่าถึง benchmark จะถูกทำลายได้เร็ว แต่การทำงานจริงให้เป็นอัตโนมัติยังยากอยู่มาก
    • “human hours equivalent” ของ METR สิ่งสำคัญคือ ใช้มนุษย์แบบไหนเป็นเกณฑ์
      ถ้าเป็นคนที่คุ้นกับ jq, ecosystem ของ PyPI หรือ annotation ของ TypeScript ก็อาจทำเสร็จได้เร็วกว่ามาก
      สุดท้ายเสน่ห์ของ AI ก็คือ การได้ความช่วยเหลือระดับผู้เชี่ยวชาญแบบทันที
    • แต่พอรันงานยาวด้วย Codex หรือ Claude code ก็จะมี หน้าต่างขอสิทธิ์เด้งขึ้นมาถี่เกินไป และมักหยุดกลางทางบ่อย
      โมเดลส่วนใหญ่จะพูดทำนองว่า “ไปขั้นถัดไปกัน” แล้วหยุดเอง
    • GPT5.2 โดยเฉพาะจะ เรียกหาข้อมูลจากผู้ใช้มากเกินไป จนสั่งให้ทำงานต่อเนื่องเกิน 2 นาทีได้ยาก
      ไม่รู้ว่ามีใครแก้ปัญหานี้ได้บ้างไหม
  • ผมยังประเมินโมเดลด้วยความระมัดระวัง แต่ ความต่างระหว่าง Opus 4.5 กับ Sonnet 4.5 นั้นรู้สึกได้ชัด
    ตอนนี้ช่องว่างด้านราคาก็แคบลงกว่าเดิมมาก เลยมีความคุ้มค่าสำหรับใช้งานจริงมากขึ้น และ Haiku 4.5 ถ้าเปิด reasoning ก็ใช้ได้ดีพอสมควร
    เหมาะเป็นพิเศษกับเครื่องมือเล็กๆ หรือการแก้ไขหน้าเดียว
  • ผมคิดว่าการเรียนรู้ซอฟต์แวร์แบ่งเป็นสองช่วงคือ การสำรวจ (exploration) กับ การใช้ประโยชน์ (exploitation)
    ด้วย LLM ทำให้สองช่วงนี้ถูกผสานเข้าด้วยกันอย่างเป็นธรรมชาติ
    เช่น ตอนทำแอนิเมชันด้วย AnimeJS ผมเรียนรู้จากการดู CCAgent เขียนโค้ด แล้วค่อยกลับมาจัดโครงสร้างและ refactor ด้วยตัวเอง
    แบบนี้จะได้ทั้ง การประหยัดเวลา และ การควบคุมเชิงสร้างสรรค์ ไปพร้อมกัน
  • Opus ดูเหมือนเป็นก้าวกระโดดใหญ่กว่า GPT 5.1 แต่ถ้าวัดที่ เกณฑ์ความน่าเชื่อถือ 80% GPT 5.1 ก็ยังเหนือกว่า
    พูดอีกอย่างคือ งานสั้นเหมาะกับ GPT 5.1 แต่งานยาวเหมาะกับ Opus มากกว่า
    • ถ้าสำเร็จแค่ 50% ก็ถือว่า เปลืองโทเค็นราคาแพง มาก แต่ผมคาดว่าราวปีหน้าโมเดลโอเพนซอร์สก็น่าจะมาถึงระดับนี้ได้
  • ประเด็นสำคัญของ METR คือการวัดความซับซ้อนโดยอิงจาก ‘เวลาที่เทียบเท่ามนุษย์’
    ถ้าโยนงาน 4 ชั่วโมงให้ทำด้วยอัตราสำเร็จ 50% มันก็แทบจะเป็น การพนัน และถ้าล้มเหลวแล้วต้องมาดีบักต่อ ต้นทุนก็สูงมาก
    เพราะงั้นผมคิดว่าควรมี จุดตรวจให้มนุษย์รีวิว ทุกๆ 30 นาที
    แต่ความสามารถที่ AI จะ กู้สถานการณ์เองได้เมื่อไปติดกลางทาง ก็สำคัญเหมือนกัน
    • แต่ในเวลา 30 นาที AI สร้างสิ่งที่ต้องตรวจเยอะมากจนการรีวิวแทบเป็น ฝันร้าย
      ภายนอกดูเหมือนปกติดี แต่มีบั๊กแบบละเอียดที่มักจะมาโผล่ทีหลัง
      เพราะงั้นงานสำคัญผมยัง ไม่ใช้เอเจนต์ แถมมันยังดึงความสนุกของการทำงานออกไปอีก
    • ต่อให้เสียเวลาไป 4 ชั่วโมง ถ้าระหว่างนั้นเราไปทำอย่างอื่นได้ ก็ไม่ได้ถือว่าขาดทุน
      ถ้ามีโอกาสครึ่งหนึ่งที่จะได้ผลลัพธ์ มันก็อาจเป็น การเดิมพันที่คุ้มค่าเมื่อเทียบกับเวลา
    • ถึงจะล้มเหลว จริงๆ แล้วสิ่งที่เสียไปมีแค่ไม่กี่นาทีที่ AI ใช้ทำงาน ดังนั้นสำหรับ การสำรวจต้นแบบ มันยอดเยี่ยมมาก
      เราลองได้หลายแนวทางอย่างรวดเร็ว และแม้แต่ความล้มเหลวก็ยังได้บทเรียน
  • น่าจะต้องมีกราฟสำหรับเกณฑ์ความน่าเชื่อถือ 95% หรือ 99% ด้วย
    จะได้เห็นชัดขึ้นว่าทำไม LLM ถึงยัง ล้มเหลวบ่อยกับงานที่มนุษย์ทำได้ง่าย
  • ผมคิดว่าการเพิ่มประสิทธิภาพสมรรถนะเป็น benchmark ที่ดีในการวัด ความฉลาดที่ใช้งานได้จริง ของ AI
    เพราะตรวจผลได้ด้วยตัวเลข โค้ดยิ่งสั้นยิ่งดี และต้องใช้ การคิดเชิงระบบ ไม่ใช่แค่การจับมาผสมกันเฉยๆ
    เท่าที่ผมเห็นมา ตอนนี้ Gemini Pro 3 ทำ optimization โค้ด SIMD ได้ดีที่สุด
  • ปัญหาของอัตราสำเร็จ 50% คือ พอลองใหม่ ความน่าจะเป็นกลับลดลงอย่างรวดเร็ว
    ถ้างาน 4 ชั่วโมงต้องทำซ้ำหลายครั้ง โอกาสสำเร็จอาจลดเหลือ 6.25%
    • แต่ก็ไม่ใช่ว่าจะเป็นแค่ “โชคไม่ดี” เสมอไป เพราะงานที่ล้มเหลวหนึ่งครั้งแล้ว โอกาสสำเร็จในการลองครั้งถัดไปอาจไม่เหมือนเดิม
      ขึ้นอยู่กับลักษณะของงาน