3.1 จำนวนวันทำงานของ Agent ต่อหนึ่งวันทำงานของมนุษย์: การคำนวณขีดความสามารถในการรีวิวที่ยังไม่มีใครทำ

OpenAI เผยตัวเลขตัวหนึ่งเมื่อสัปดาห์นี้ที่ควรค่าแก่การจับตามากกว่าตัวเลขดอลลาร์ที่อยู่ข้าง ๆ กัน ณ กลางเดือนสิงหาคม องค์กรวิจัยของบริษัทใช้แรงงานจากเอเจนต์ 3.1 วันทำการ ต่อวันทำการของมนุษย์ 1 วัน ประโยคที่ถูกอ้างกันมากคือเรื่องค่าใช้จ่าย: นักวิจัยระดับมัธยฐานรัน inference มากกว่า $600 ต่อวันในราคา API แต่ประโยคที่สำคัญสำหรับใครก็ตามที่ดูแลทีมคืออีกประโยคหนึ่ง

เอเจนต์ 3 วัน ต่อมนุษย์ 1 วัน หมายความว่าวันทำงานของมนุษย์กลายเป็นคอขวด ผลลัพธ์ทุกชิ้นที่เอเจนต์สร้างขึ้นต้องมีคนอ่าน ตัดสิน และยอมรับ และคนคนนั้นมีวันทำงานแค่หนึ่งวัน ไม่ใช่สามวัน บทความนี้จะคิดเลขให้ดูและชี้ว่า คิวเกิดขึ้นตรงไหน

TL;DR

โพสต์ "Research acceleration" ของ OpenAI ระบุว่าแรงงานเอเจนต์อยู่ที่ 3.1 วันทำการต่อวันทำการของมนุษย์ ชี้ให้เห็นแนวโน้มที่นักวิจัยรันเอเจนต์สี่ตัวหรือมากกว่าพร้อมกัน และรายงานว่างานที่สำเร็จซึ่งใช้เวลา 4-8 ชั่วโมงมากกว่าครึ่งต้องมีการแทรกแซงจากมนุษย์อย่างน้อยหนึ่งครั้ง เมื่อนำมารวมกัน วันทำงานหนึ่งวันจึงมีหลายช่วงที่เอเจนต์หยุดและกำลังรอคนอยู่ บวกกับงานที่เสร็จแล้วไหลมาเรื่อย ๆ รอการยอมรับ คิวที่เต็มขึ้นมาคือ "ผลลัพธ์ที่รอคน" และเครื่องมือส่วนใหญ่ไม่ได้แสดงคิวนี้ Sharkly ทำให้คิวนั้นชัดเจน: สถานะรอ (waiting states) บน Task, Inbox ที่จัดเส้นทางไปยังผู้รับผิดชอบ และการยอมรับเป็นบันทึกการเปลี่ยนสถานะ

ตัวเลข

ข้อมูลทั้งหมดด้านล่างมาจากโพสต์ของ OpenAI เว้นแต่จะระบุไว้เป็นอย่างอื่น

การตีความโพสต์เดียวกันของ Simon Willison เสริมภาพรูปร่างของเส้นโค้ง: ค่าใช้จ่ายต่อนักวิจัยเพิ่มจากเกือบศูนย์ในเดือนกุมภาพันธ์เป็นประมาณ $600 ภายในปลายเดือนสิงหาคม โดยมีการไต่ขึ้นอย่างชันระหว่างเดือนกรกฎาคมถึงสิงหาคม ซึ่งเขาคาดว่าเกิดขึ้นพร้อมกับการเข้าถึงโมเดลภายในองค์กรที่ภายหลังเปิดตัวในชื่อ GPT-6 Astra

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

การคำนวณ

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

ถ้างานยาวที่สำเร็จมากกว่าครึ่งต้องมีการแทรกแซงอย่างน้อยหนึ่งครั้ง เมื่อมีเอเจนต์รันอยู่สี่ตัว คนคนหนึ่งควรคาดว่าจะถูกเอเจนต์สองหรือสามตัวขัดจังหวะในระหว่างทำงานหนึ่งงาน ณ เวลาที่ตัวเขาไม่ได้เลือกเอง การขัดจังหวะเหล่านี้ไม่ใช่ความล้มเหลว เอเจนต์ที่หยุดและถามย่อมดีกว่าเอเจนต์ที่เดาแล้วส่งงานไป ต้นทุนอยู่ที่ว่าคำถามนั้นไปตกอยู่ตรงไหนต่างหาก

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

คิวที่ไม่มีใครทำแดชบอร์ด

ทุกทีมที่รันเอเจนต์มีสองคิว คิวแรกคืองานที่รอเอเจนต์: backlog ที่มองเห็นได้ในเครื่องมือติดตามงานที่ทีมใช้ คิวที่สองคืองานที่รอคน: ผลลัพธ์ที่ต้องยอมรับ คำถามที่ต้องตอบ ความล้มเหลวที่ต้องคัดแยก คิวที่สองคือคิวที่โตในอัตรา 3.1 ต่อ 1 และเป็นคิวที่เครื่องมือส่วนใหญ่ไม่แสดง

Sharkly มองคิวนั้นเป็นวัตถุหลัก Task คือหน่วยหลักของงาน และสถานะ Task กับสถานะการทำงานของ Agent ถูกแยกออกจากกัน: Task ที่ Started แล้วสามารถแสดง Working, Waiting for human reply, Waiting for human review หรือ Error สถานะรอเหล่านี้เป็นพลเมืองชั้นหนึ่ง ไม่ได้อนุมานจาก log ที่เงียบ ๆ

สถานะเหล่านี้ถูกจัดเส้นทางไปที่ใดที่หนึ่ง Inbox คือคิวส่วนตัวของกิจกรรมใน Task โดยส่วน Primary จะเก็บ Task ที่มีสัญญาณที่ต้องได้รับความสนใจ: รอคำตอบจากคุณ รอการตรวจทานจากคุณ งานที่ล้มเหลวหรือถูกบล็อก การกล่าวถึงโดยตรง การมอบหมายให้คุณ มันจัดกลุ่มกิจกรรมตาม Task ดังนั้นเอเจนต์สี่ตัวที่รายงานใน Task เดียวจึงเป็นหนึ่งแถว ไม่ใช่สี่การแจ้งเตือน Slack เป็นช่องทางขาออกแบบไม่บังคับ การปิดการแจ้งเตือนในกลุ่มนั้นไม่ได้ลบบันทึกใน Inbox

การตอบกลับคือวิธีที่งานดำเนินต่อไป คอมเมนต์บน Task ที่มี Agent ซึ่งพร้อมและถูกมอบหมายอยู่ สามารถเริ่มรันต่อเนื่องโดยใช้เธรดเป็นบริบท ดังนั้นการตอบคำถามจึงทำงานนั้นต่อจากเดิม ไม่ใช่เริ่มใหม่

การยอมรับผลงานหน้าตาเป็นอย่างไรในสัดส่วนนี้

ที่เอเจนต์หนึ่งตัวต่อคนหนึ่งคน การตรวจทานแบบไม่เป็นทางการก็พอไหว แต่ที่เอเจนต์สามวันต่อมนุษย์หนึ่งวันทำแบบนั้นไม่ได้ เพราะคนที่ตรวจทานจะไม่ใช่คนที่เริ่มรัน และรันนั้นอาจจบไปแล้วหลายชั่วโมง

การยอมรับใน Sharkly คือการที่คนคนหนึ่งเปลี่ยนสถานะ Task หลังจากอ่านหลักฐานแล้ว คำตอบสุดท้ายของ Agent ถูกเก็บไว้บน Task ส่วน execution log บันทึกเหตุผลที่รันถูกจัดเข้าคิว เวลาเริ่มและสิ้นสุด การเรียกใช้เครื่องมือ เหตุการณ์ใน Runtime และรายละเอียดความล้มเหลว ไว้ในแท็บ Executions ซึ่งแยกจากไทม์ไลน์คอมเมนต์ อ่านสรุปก่อน จากนั้นอ่าน log แล้วจึงอ่าน diff การ merge pull request ที่เชื่อมโยงไว้ไม่ได้เปลี่ยนสถานะ Task ดังนั้นการ merge จึงไม่มีทางถูกเข้าใจผิดว่าเป็นการตัดสินใจ กระบวนการตรวจทานแบบ human-in-the-loop ของเราอธิบายประตูทั้งห้าตามลำดับ

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

ควรใช้วันทำงานของมนุษย์ไปกับอะไร

ใช้วันทำงานของมนุษย์ไปกับทิศทางและการยอมรับ: ปั้นตั๋วงาน ให้อำนาจ อ่านหลักฐาน ตัดสินใจเรื่อง merge และ release ปล่อยให้การลงมือทำ การทดสอบ และการรายงานเป็นหน้าที่ของเอเจนต์ เอเจนต์ค้นคว้า ลงมือทำ ทดสอบ และรายงาน คนกำหนดทิศทาง ให้อำนาจ และยอมรับผลลัพธ์ สัดส่วนในโพสต์ของ OpenAI คือหน้าตาของสัญญานี้เมื่อมันทำงานได้ผล

ใช้วันทำงานของมนุษย์ไปกับการกำกับดูแลเฉพาะเมื่องานนั้นต้องการคนเฝ้าดูแบบเรียลไทม์จริง ๆ: การเปลี่ยนแปลงใน production ที่ย้อนกลับไม่ได้ การรันในไดเรกทอรีที่งานอื่นพึ่งพาอยู่ Sharkly ไม่ใช่ตัวแทนของ Claude Code, Codex หรือ Runtime ที่ลงมือทำงาน มันคือชั้นที่ทำให้บริบท ความคืบหน้า อุปสรรค ผลลัพธ์ และการตรวจทานโดยมนุษย์มองเห็นได้ตั้งแต่วันที่ขอจนถึงวันเปิดตัว เพื่อให้วันทำงานของมนุษย์หมดไปกับการตัดสินใจ ไม่ใช่กับการตามหาว่าเทอร์มินัลไหนมีคำถามค้างอยู่

คำถามที่พบบ่อย

ตัวเลข 3.1 มาจากไหน? มาจากโพสต์ของ OpenAI ชื่อ "Research acceleration: the view inside OpenAI" ซึ่งระบุว่า ณ กลางเดือนสิงหาคม องค์กรวิจัยใช้แรงงานจากเอเจนต์ 3.1 วันทำการต่อวันทำการของมนุษย์ 1 วัน

สิ่งนี้ใช้กับทีมวิศวกรรมผลิตภัณฑ์ด้วยไหม? ตัวเลขเฉพาะเจาะจงมาจากองค์กรวิจัย แต่ทิศทางของสัดส่วนนี้ใช้ได้กับทุกทีมที่เปลี่ยนจากเอเจนต์หนึ่งตัวไปเป็นหลายตัว: ผลผลิตของเอเจนต์โตเร็วกว่าความสามารถในการตรวจทาน

ตัวเลขการแทรกแซงคืออะไร? งาน 4-8 ชั่วโมงที่สำเร็จมากกว่าครึ่งระหว่างเดือนมกราคมถึงกรกฎาคมมีการแทรกแซงจากมนุษย์หนึ่งครั้งขึ้นไป รันยาว ๆ สำเร็จได้ก็เพราะมีคนเข้ามาช่วย ไม่ใช่เพราะไม่มีคนเลย

Sharkly แสดงคิวการตรวจทานอย่างไร? Waiting for human reply และ Waiting for human review เป็นสถานะการทำงานของ Agent บน Task ซึ่งถูกจัดเส้นทางไปยังส่วน Primary ของ Inbox ของผู้รับผิดชอบ งานที่ล้มเหลวและถูกบล็อกก็ปรากฏอยู่ที่นั่นด้วย

อะไรนับว่าเป็นการยอมรับ? การที่คนคนหนึ่งเปลี่ยนสถานะ Task หลังจากอ่านคำตอบของ Agent, execution log และ diff การ merge pull request ไม่ได้เปลี่ยนสถานะด้วยตัวเอง

ฉบับย่อ

สัดส่วนของ OpenAI บอกว่าเอเจนต์ผลิตผลงานได้สามวันต่อวันทำงานของมนุษย์หนึ่งวันแล้ว และตัวเลขการแทรกแซงก็บอกว่ามีคนอยู่ในลูปสำหรับงานยาวส่วนใหญ่ ทรัพยากรที่หายากคือวันทำงานของมนุษย์ และคิวที่เต็มขึ้นคือผลลัพธ์ที่รอคน ทำให้คิวนั้นมองเห็นได้ จัดเส้นทางไปยังเจ้าของ และบันทึกการตัดสินใจ เชื่อมต่อ Computer หนึ่งเครื่อง สร้าง Agent หนึ่งตัว แล้วมอบหมายงานน่าเบื่อให้มันสักอย่าง เอกสารของเราอธิบายแต่ละแนวคิดอย่างละเอียดกว่า: docs.sharkly.ai