บทคัดย่อ : Anthropic พบว่าความแตกต่างในการกำหนดค่าสาธารณูปโภคพื้นฐานในการประเมิน Agent Programming สามารถทำให้คะแนนเปลี่ยนแปลงได้หลายเปอร์เซ็นต์ — บางครั้งมากกว่าช่องว่างระหว่างโมเดลชั้นนำในกระดานคะแนน บทความนี้วิเคราะห์โดยละเอียดว่าการกำหนดทรัพยากรส่งผลต่อผลการประเมินอย่างไร และให้คำแนะนำที่เป็นรูปธรรม

การค้นพบปัญหา

การทดสอบมาตรฐาน Agent Programming เช่น SWE-bench และ Terminal-Bench ถูกใช้กันอย่างแพร่หลายเพื่อเปรียบเทียบความสามารถด้านวิศวกรรมซอฟต์แวร์ของโมเดลล้ำสมัย — ตำแหน่งชั้นนำในกระดานคะแนนมักจะแตกต่างกันเพียงไม่กี่เปอร์เซ็นต์ คะแนนเหล่านี้มักถูกมองว่าเป็นการวัดความสามารถสัมพัทธ์ของโมเดลที่แม่นยำ และมีอิทธิพลต่อการตัดสินใจปรับใช้โมเดลมากขึ้นเรื่อยๆ

อย่างไรก็ตาม Anthropic พบในการทดลองภายในว่า แค่ความแตกต่างในการกำหนดค่าสาธารณูปโภคพื้นฐานก็สามารถทำให้คะแนนเปลี่ยนแปลงได้มากกว่าช่องว่างเหล่านี้แล้ว บน Terminal-Bench 2.0 ช่องว่างระหว่างการกำหนดค่าที่มีทรัพยากรเพียงพอที่สุดและจำกัดที่สุดสูงถึง 6 เปอร์เซ็นต์ (p < 0.01)

การทดสอบมาตรฐานแบบสถิตจะให้คะแนนผลลัพธ์ของโมเดลโดยตรง สภาพแวดล้อมขณะรันไทม์ไม่ส่งผลต่อผลลัพธ์ แต่การประเมิน Agent Programming นั้นต่างออกไป: โมเดลจะได้รับสภาพแวดล้อมที่สมบูรณ์เพื่อเขียนโปรแกรม รันการทดสอบ ติดตั้ง dependencies และทำซ้ำหลายรอบ สภาพแวดล้อมขณะรันไทม์ไม่ใช่แค่ภาชนะที่เฉยๆ อีกต่อไป แต่เป็นส่วนหนึ่งของกระบวนการแก้ปัญหา

Agent สองตัวที่มีงบประมาณทรัพยากรและข้อจำกัดด้านเวลาต่างกัน จริงๆ แล้วไม่ได้ทำการทดสอบชุดเดียวกัน นักพัฒนาการประเมินเริ่มตระหนักถึงปัญหานี้แล้ว ตัวอย่างเช่น Terminal-Bench 2.0 ในเวอร์ชันล่าสุดได้ระบุ CPU และ RAM ที่แนะนำตามแต่ละงาน แต่การระบุทรัพยากรไม่เท่ากับการปฏิบัติตามอย่างสม่ำเสมอ และ Anthropic พบว่าวิธีการปฏิบัติงานเองก็เปลี่ยนสิ่งที่การทดสอบมาตรฐานวัดได้จริง

ปัญหาถูกค้นพบอย่างไร

Anthropic รัน Terminal-Bench 2.0 บนคลัสเตอร์ Google Kubernetes Engine ขณะปรับการตั้งค่า พวกเขาสังเกตว่าคะแนนไม่ตรงกับกระดานคะแนนอย่างเป็นทางการของการทดสอบมาตรฐาน และอัตราความผิดพลาดของสาธารณูปโภคพื้นฐานสูงผิดปกติ: งานมากถึง 6% ล้มเหลวเนื่องจากข้อผิดพลาดของ pod ซึ่งส่วนใหญ่ไม่เกี่ยวข้องกับความสามารถของโมเดลในการแก้ไขงาน

ความแตกต่างของคะแนนเกิดจากวิธีการปฏิบัติงานที่ต่างกัน การใช้งาน Kubernetes กำหนดข้อกำหนดทรัพยากรของแต่ละงานเป็นทั้งขีดจำกัดล่างและขีดจำกัดสูงสุดแบบแข็ง: แต่ละคอนเทนเนอร์จะได้รับทรัพยากรที่ระบุอย่างแน่นอน แต่หากเกินกว่าที่กำหนดก็จะถูกหยุดทำงาน ตัวรันไทม์คอนเทนเนอร์บังคับใช้ข้อจำกัดทรัพยากรผ่านพารามิเตอร์อิสระสองตัว: การจัดสรรที่รับประกัน (ทรัพยากรที่จองไว้ล่วงหน้า) และขีดจำกัดสูงสุดแบบแข็ง (เกณฑ์ที่คอนเทนเนอร์จะถูกหยุด) เมื่อตั้งค่าทั้งสองค่านี้ให้เท่ากัน ก็จะไม่มีพื้นที่ว่างสำหรับค่าสูงสุดชั่วขณะ: ความผันผวนของหน่วยความจำเพียงชั่วครู่ก็อาจทำให้คอนเทนเนอร์ที่อาจสำเร็จได้ถูก OOM-kill (หยุดทำงานเนื่องจากหน่วยความจำล้น)

เพื่อแก้ไขปัญหานี้ กระดานคะแนนของ Terminal-Bench ใช้ผู้ให้บริการแซนด์บ็อกซ์ที่ต่างกัน ซึ่งการใช้งานยืดหยุ่นกว่า อนุญาตให้มีการจัดสรรทรัพยากรเกินชั่วคราวโดยไม่หยุดคอนเทนเนอร์ เพื่อความมั่นคงของสาธารณูปโภคพื้นฐาน การค้นพบนี้ทำให้เกิดคำถามที่ใหญ่ขึ้น: การกำหนดค่าทรัพยากรส่งผลต่อคะแนนการประเมินมากแค่ไหนกันแน่?

การออกแบบการทดลองและผลลัพธ์

เพื่อวัดผลกระทบของเฟรมเวิร์กเชิงปริมาณ Anthropic ได้รัน Terminal-Bench 2.0 ภายใต้การกำหนดทรัพยากรหกแบบ ตั้งแต่การปฏิบัติตามข้อกำหนดของแต่ละงานอย่างเคร่งครัด (1x คือ Requests เท่ากับ Limits ทั้งเป็นขีดจำกัดล่างและบน) ไปจนถึงไม่กำหนดขีดจำกัดบนเลย เงื่อนไขอื่นๆ ทั้งหมดคงที่: โมเดล Claude เดียวกัน เฟรมเวิร์กเดียวกัน ชุดงานเดียวกัน

ผลการทดลองแสดงให้เห็นว่าอัตราความสำเร็จเพิ่มขึ้นตามพื้นที่ทรัพยากรที่เพิ่มขึ้น สาเหตุหลักมาจากอัตราความผิดพลาดของสาธารณูปโภคพื้นฐานลดลงอย่างต่อเนื่องในแต่ละขั้นตอน จาก 5.8% เมื่อปฏิบัติอย่างเคร่งครัดเหลือ 0.5% เมื่อไม่กำหนดขีดจำกัด การลดลงจากการปฏิบัติอย่างเคร่งครัดไปยังพื้นที่ 3 เท่า (5.8% ถึง 2.1%) มีนัยสำคัญที่ระดับ p < 0.001 พื้นที่มากขึ้นหมายถึงคอนเทนเนอร์น้อยลงที่ถูกหยุดเนื่องจากเกินการจัดสรร

จาก 1x ถึง 3x คะแนนความสำเร็จผันผวนภายในช่วงสัญญาณรบกวน (p=0.40) งานส่วนใหญ่ที่ล้มเหลวที่ 1x จะล้มเหลวไม่ว่าอย่างไรก็ตาม — นี่คือสิ่งที่พวกเขาสังเกตเห็นในข้อมูล Agent สำรวจ พบกำแพงทรัพยากร ถูกขัดจังหวะ แต่เดิมทีมันก็ไม่ได้อยู่บนเส้นทางสู่การแก้ปัญหาที่ถูกต้อง

อย่างไรก็ตาม ประมาณตั้งแต่ 3x เป็นต้นไป แนวโน้มนี้เปลี่ยนไป: อัตราความสำเร็จเพิ่มขึ้นเร็วกว่าอัตราความผิดพลาดของสาธารณูปโภคพื้นฐานลดลง จาก 3x ไปจนถึงไม่กำหนดขีดจำกัด อัตราความผิดพลาดของสาธารณูปโภคพื้นฐานลดลงอีก 1.6 เปอร์เซ็นต์ ในขณะที่อัตราความสำเร็จเพิ่มขึ้นเกือบ 4 เปอร์เซ็นต์ ทรัพยากรเพิ่มเติมทำให้ Agent สามารถลองใช้วิธีการที่ทำงานได้เฉพาะเมื่อมีทรัพยากรเพียงพอ เช่น ดึง dependencies ขนาดใหญ่ สร้างซับโพรเซสที่ใช้ทรัพยากรมาก รันชุดทดสอบที่ใช้หน่วยความจำเข้มข้น ที่ไม่กำหนดขีดจำกัดทรัพยากร การเพิ่มขึ้นทั้งหมดเมื่อเทียบกับ 1x อยู่ที่ +6 เปอร์เซ็นต์ (p < 0.01)

นี่หมายความว่าอย่างไรต่อการวัดผล

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

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

Agent ที่เขียนโค้ดที่กระชับมีประสิทธิภาพและเร็วจะทำงานได้ดีภายใต้ข้อจำกัดที่คับแคบ Agent ที่ใช้เครื่องมือหนักๆ แก้ปัญหาด้วยวิธี brute force จะทำงานได้ดีภายใต้เงื่อนไขที่ยืดหยุ่น ทั้งสองอย่างเป็นเนื้อหาที่สมเหตุสมผลในการทดสอบ แต่หากยุบรวมเป็นคะแนนเดียวโดยไม่ระบุการกำหนดทรัพยากร ความแตกต่างและความสามารถในการนำไปใช้ในโลกแห่งความเป็นจริงก็จะตีความได้ยาก

ตัวอย่างที่เป็นรูปธรรม

ในงาน Terminal-Bench ชื่อ bn-fit-modify ซึ่งต้องทำการ fitting Bayesian network ขั้นตอนแรกของโมเดลบางตัวคือการติดตั้งสแต็กวิทยาศาสตร์ข้อมูล Python มาตรฐาน: pandas, networkx, scikit-learn และ toolchain ทั้งหมดของมัน ภายใต้ข้อจำกัดที่ยืดหยุ่น วิธีนี้ใช้ได้ ภายใต้ข้อจำกัดที่คับแคบ pod ใช้หน่วยความจำหมดระหว่างขั้นตอนการติดตั้ง โดยที่ Agent ยังไม่ได้เขียนโค้ดแก้ปัญหาแม้แต่บรรทัดเดียว

มีกลยุทธ์ที่กระชับกว่า (ใช้ไลบรารีมาตรฐานเพียงอย่างเดียวและคำนวณทางคณิตศาสตร์ตั้งแต่เริ่มต้น) ซึ่งโมเดลบางตัวใช้วิธีนี้โดยค่าเริ่มต้น ในขณะที่บางตัวไม่ใช้ โมเดลที่ต่างกันมีวิธีการเริ่มต้นที่ต่างกัน การกำหนดทรัพยากรเป็นตัวกำหนดว่าวิธีใดจะประสบความสำเร็จโดยบังเอิญ

Anthropic ทำซ้ำการค้นพบหลักบนโมเดล Anthropic ที่ต่างกัน ผลกระทบมีทิศทางเดียวกัน แต่ขนาดแตกต่างกัน แนวโน้มเดียวกันดูเหมือนจะใช้ได้กับโมเดลอื่นนอกจาก Claude ด้วย แต่พวกเขาไม่ได้ทดสอบอย่างเข้มงวด

พวกเขายังทดสอบรูปแบบนี้กับการประเมินอื่นนอกเหนือจาก Terminal-Bench โดยทำการทดลองข้ามบน SWE-bench เพิ่ม RAM ที่ใช้ได้ทั้งหมดเป็น 5 เท่าของมาตรฐานใน 227 ปัญหา ตัวอย่างละ 10 ตัวอย่าง ผลกระทบเดียวกันยังคงอยู่ แม้ว่าขนาดจะเล็กกว่า: คะแนนเพิ่มขึ้นอย่างต่อเนื่องตาม RAM ที่เพิ่มขึ้นอีกครั้ง แต่ที่ 5x สูงกว่า 1x เพียง 1.54 เปอร์เซ็นต์ งาน SWE-bench ใช้ทรัพยากรน้อยกว่า ดังนั้นผลกระทบที่เล็กกว่าจึงเป็นไปตามคาด แต่ก็บ่งชี้ว่าการจัดสรรทรัพยากรที่นั่นก็ไม่เป็นกลางเช่นกัน

แหล่งที่มาของความแปรปรวนอื่นๆ

การจัดสรรทรัพยากรไม่ใช่ตัวแปรแฝงเดียว ในบางการกำหนดค่า ข้อจำกัดด้านเวลาเริ่มมีบทบาทด้วย โดยหลักการแล้ว ทุกองค์ประกอบของการตั้งค่าการประเมินอาจส่งผลต่อคะแนนสุดท้าย ตั้งแต่สุขภาพของคลัสเตอร์ไปจนถึงสเปกฮาร์ดแวร์ ตั้งแต่ระดับคอนเคอร์เรนซีไปจนถึงแบนด์วิธเอาต์พุต การประเมิน Agent โดยพื้นฐานคือการทดสอบระบบแบบ end-to-end องค์ประกอบใดๆ ของระบบนี้อาจกลายเป็นปัจจัยที่ทำให้สับสนได้

Anthropic สังเกตว่าอัตราการผ่านผันผวนตามเวลาของวัน อาจเป็นเพราะความล่าช้าของ API เปลี่ยนแปลงตามรูปแบบการจราจรและเหตุการณ์ พวกเขาไม่ได้วัดผลกระทบนี้อย่างเป็นทางการ แต่มันแสดงให้เห็นประเด็นที่ใหญ่กว่า: เส้นแบ่งระหว่าง “ความสามารถของโมเดล” และ “พฤติกรรมของสาธารณูปโภคพื้นฐาน” นั้นเบลอมากกว่าที่คะแนนการทดสอบมาตรฐานเดียวจะบอก

ผู้ให้บริการโมเดลสามารถปกป้องโครงสร้างพื้นฐานการประเมินของพวกเขาจากผลกระทบดังกล่าวด้วยฮาร์ดแวร์เฉพาะทาง แต่ผู้ประเมินภายนอกไม่สามารถทำเช่นเดียวกันได้ง่ายๆ การทดสอบมาตรฐานสาธารณะมักมีจุดมุ่งหมายเพื่อวัดความสามารถของโมเดลล้วนๆ แต่ในความเป็นจริงพวกมันเสี่ยงที่จะรวมความสามารถเข้ากับความแปลกประหลาดของสาธารณูปโภคพื้นฐาน บางครั้งอาจเป็นที่พึงประสงค์ เพราะมันทดสอบสแต็กเทคโนโลยีทั้งหมดแบบ end-to-end แต่บ่อยครั้งก็ไม่ใช่ สำหรับการประเมินการเขียนโปรแกรมที่ตั้งใจจะแบ่งปันต่อสาธารณะ การรันหลายครั้งและหลายวันช่วยให้ค่าเฉลี่ยของสัญญาณรบกวน

คำแนะนำของ Anthropic

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

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

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

ตัวอย่างเช่น ใน Terminal-Bench 2.0 การตั้งค่าขีดจำกัดบน 3 เท่าเมื่อเทียบกับข้อกำหนดของแต่ละงาน ลดอัตราความผิดพลาดของสาธารณูปโภคพื้นฐานลงประมาณสองในสาม (5.8% ถึง 2.1%, p < 0.001) ในขณะที่รักษาการเพิ่มคะแนนให้อยู่ในระดับปานกลางและอยู่ในช่วงสัญญาณรบกวน (p = 0.40) นี่เป็นการแลกเปลี่ยนที่สมเหตุสมผล: ปัจจัยที่ทำให้สับสนจากสาธารณูปโภคพื้นฐานถูกทำให้เป็นกลางเป็นส่วนใหญ่ โดยไม่กำจัดแรงกดดันด้านทรัพยากรที่มีความหมาย ตัวคูณที่แน่นอนจะแตกต่างกันไปตามการทดสอบมาตรฐานและการกระจายของงาน ดังนั้นจึงควรรายงาน แต่หลักการปรับเทียบเชิงประจักษ์เป็นสากล

ทำไมสิ่งนี้จึงสำคัญ

คะแนนการทดสอบมาตรฐานกำลังกลายเป็นพื้นฐานที่สำคัญมากขึ้นเรื่อยๆ สำหรับการตัดสินใจ แต่การให้ความสำคัญและการพึ่งพาที่เพิ่มขึ้นนี้ไม่ได้มาพร้อมกับการตรวจสอบอย่างเข้มงวดเกี่ยวกับวิธีการรันและรายงานการประเมิน ในปัจจุบัน ความได้เปรียบ 2 คะแนนในกระดานคะแนนอาจมาจากช่องว่างความสามารถที่แท้จริงของโมเดล หรืออาจเป็นเพียงเพราะการประเมินรันบนฮาร์ดแวร์ที่ทรงพลังกว่า หรือรันในช่วงเวลาที่ “โชคดี” หรือทั้งสองอย่างรวมกัน

หากขาดการตั้งค่าคอนฟิกที่เปิดเผยหรือเป็นมาตรฐาน บุคคลภายนอกจะแยกแยะแหล่งที่มาของความแตกต่างได้ยาก เว้นแต่ผู้เกี่ยวข้องจะทุ่มเทความพยายามเพิ่มเติมเพื่อทำซ้ำผลลัพธ์ภายใต้เงื่อนไขที่เหมือนกันทุกประการ ดังนั้น สำหรับสถาบันวิจัยเช่น Anthropic ควรพิจารณาการกำหนดทรัพยากรสำหรับการประเมิน Agent เป็นตัวแปรการทดลองระดับหนึ่งที่สำคัญเทียบเท่ากับรูปแบบคำสั่ง (prompt format) และอุณหภูมิการสุ่มตัวอย่าง (sampling temperature) และควรบันทึกและควบคุมอย่างเคร่งครัด

สำหรับผู้ดูแลการทดสอบมาตรฐาน การเผยแพร่ข้อกำหนดทรัพยากรที่แนะนำ (เช่นที่ Terminal-Bench 2.0 ทำ) จะช่วยได้อย่างมาก และการชี้แจงวิธีการปฏิบัติงานเพิ่มเติมจะช่วยปิดช่องว่างที่มีอยู่ สำหรับผู้ใช้ทั้งหมดที่อ้างอิงผลการทดสอบมาตรฐาน ข้อความสำคัญคือ: ความไม่แน่นอนที่อยู่เบื้องหลังความแตกต่างเล็กน้อยของคะแนนในการประเมิน Agent นั้นใหญ่กว่าที่ความแม่นยำของตัวเลขที่รายงานเองจะบอก — ปัจจัยที่ทำให้สับสนบางส่วนควบคุมได้ยากมากในตัวมันเอง

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง