Baseten Grid ชวนคิดว่างานเขียนโค้ดที่เสร็จจริงมีต้นทุนเท่าไร

เอเจนต์เขียนโค้ดส่งการแก้ไขที่ดูเรียบร้อยมาให้สำหรับเทสต์ที่ล้มเหลว แต่โค้ดไม่ผ่าน CI นักพัฒนาจึงให้เอเจนต์ลองอีกครั้ง รอบสองแก้ไฟล์มากขึ้น ผู้รีวิวเสียเวลาครึ่งชั่วโมงตรวจแพตช์ที่ควรใช้เวลาห้านาที แล้วโมเดลไหนถูกกว่ากัน?

Baseten เปิดตัว Grid ในสถานะพรีวิวสาธารณะเมื่อวันที่ 4 พฤศจิกายน โดยรวมเกตเวย์สำหรับโมเดลที่อนุมัติแล้ว ตัวเลือกเส้นทาง และการควบคุมการใช้งานกับข้อจำกัดจากส่วนกลาง บริการนี้คั่นระหว่างเครื่องมือเขียนโค้ดที่รองรับกับโมเดล เพื่อให้ทีมใช้กติกาเดียวกันกับคำขอต่าง ๆ หน้าขอสิทธิ์ใช้งานก่อนเปิดเต็มรูปแบบพาทีมไปลงชื่อรอ

เลือกตัวหารให้ตรงกับงาน

ต้นทุนต่องานที่ผ่านการตรวจ ภาพประกอบต้นฉบับโดย Telli.sh

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

สมมติสองเส้นทางได้รับงานลักษณะใกล้กันเส้นทางละ 100 งาน เส้นทางราคาต่ำจ่ายรวม $50 ทำงานผ่านเกณฑ์ 50 งาน อีกเส้นทางจ่าย $90 ทำผ่าน 90 งาน ในตัวอย่างนี้ทั้งคู่มีค่าโมเดล $1 ต่องานที่ผ่าน เมื่อรวมเวลารีวิว ค่าเครื่องมือ และเวลารอลองใหม่ ต้นทุนสองทางอาจต่างกันได้ทั้งสองทิศทาง

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

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

มองผลทดสอบตัวเลือกเส้นทางผ่านสิ่งที่ต้องแลก

การทดลองเลือกเส้นทาง ภาพประกอบต้นฉบับโดย Telli.sh

รายงานเทคนิคของ Baseten เปรียบเทียบการใช้ Opus 5.5 ตลอดกับการสลับงานระหว่างโมเดลนั้นกับ GLM 5.3 Flash บนชุดงานผสมจาก DeepSWE, SWE Atlas QnA และ Terminal-Bench บริษัทระบุว่าจุดหนึ่งลดต้นทุนได้ 72% โดยอัตราผ่านต่างจากการใช้ Opus ตลอดไม่เกิน 0.8 จุดเปอร์เซ็นต์ รายงานยังเทียบกับการสุ่มเส้นทางที่ต้นทุนใกล้กัน ประเด็นนี้สำคัญเพราะต่อให้โยนเหรียญ การส่งงานไปยังโมเดลที่ราคาถูกขึ้นก็ลดค่าโมเดลเฉลี่ยได้อยู่แล้ว

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

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

เกตเวย์ทำให้นโยบายเห็นได้จากจุดเดียว

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

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

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

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

ทดสอบการเลือกเส้นทางก่อนเปลี่ยนค่าเริ่มต้น

1. เลือกงานที่พบบ่อยสองหรือสามกลุ่ม ทั้งงานตรงไปตรงมาอย่างอัปเดตเทสต์ตามปกติ และงานยากกว่าอย่างการย้ายระบบที่ต้องรองรับข้อมูลหรือสัญญาเดิม
2. กำหนดหลักฐานการผ่านเกณฑ์ล่วงหน้า งานเขียนโค้ดอาจต้องมีเทสต์รีเกรสชันที่ผ่าน ชุดการแก้ไขที่อ่านได้ การอนุมัติจากผู้รีวิว และการตรวจไฟล์ที่เปลี่ยนโดยไม่คาดคิด
3. เก็บค่าฐานจากโมเดลเริ่มต้นปัจจุบัน รวมความพยายามที่ล้มเหลว การลองใหม่ และงานที่นักพัฒนาต้องทำต่อเอง คงข้อจำกัดด้านข้อมูลและความปลอดภัยที่ใช้จริง
4. เทียบการเลือกเส้นทางกับงานที่เทียบเคียงกันได้ หากได้รับสิทธิ์ ให้ตรวจเครื่องมือและสิทธิ์ที่เกตเวย์รองรับจากเอกสารทางการก่อนผูกบัญชี
5. กำหนดว่าจะยกระดับเมื่อไร รอบแรกที่ไม่ผ่านอาจเรียกโมเดลตัวที่สอง แต่การลองซ้ำแบบไร้ขอบเขตอาจแพงกว่าการใช้โมเดลที่เก่งกว่าตั้งแต่แรก กำหนดจำนวนรอบและจดเหตุผลที่ยกระดับ
6. เปิดทางให้เลือกเองในงานที่มีผลเสียสูงหากผิดพลาด หลังทดสอบให้ทบทวนกรณียกเว้นพร้อมต้นทุนรวมและอัตราผ่าน

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

อ่านบันทึกงานที่จับคู่เปรียบเทียบกันได้

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

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

เก็บเวลาที่คนใช้ตัดสินใจว่ารับผลหรือไม่ สมมติค่าฐานได้ผลผ่าน 19 จาก 20 งานด้วยต้นทุน $19 ส่วนตัวเลือกเส้นทางได้ 18 งานด้วยต้นทุน $9 ในตัวอย่างนี้ค่าโมเดลต่องานที่ผ่านอยู่ที่ $1.00 และ $0.50 ตามลำดับ หากผู้รีวิวใช้เวลาเพิ่ม 20 นาทีแก้ผลที่ไม่ผ่านหนึ่งชิ้น การเทียบต้นทุนก็เปลี่ยนไป องค์กรสามารถรวมงานแก้ซ้ำในหน่วยวัดที่เลือกโดยไม่ต้องถือว่าเงินกับนาทีเป็นหน่วยเดียวกัน

ดูว่าตัวเลือกเส้นทางเรียนรู้จากงานแบบไหน

บทความเทคนิคของ Baseten ระบุ DeepSWE 1.1, SWE Atlas QnA และ Terminal-Bench 2.1 การศึกษาเปรียบเทียบ Claude Opus 5.5 กับ GLM 5.3 Flash ในหลายงาน และประเมินตัวเลือกเส้นทางบนข้อมูลที่กันไว้สำหรับทดสอบ รายละเอียดเหล่านี้กำหนดว่าจะนำผลไปอ้างได้กว้างเพียงใด คำถามเรื่องการหาไฟล์ในคลังมีรูปแบบต้นทุนต่างจากงานที่รันเชลล์ ใช้เครื่องมือภายนอก หรือแก้หลายไฟล์ การประเมินของลูกค้าควรแทนงานที่ตั้งใจส่งจริง

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

จับตางานกลุ่มที่รอนานและมีต้นทุนสูง

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

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

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

รักษาค่าฐานให้ใช้ได้แม้โมเดลเปลี่ยน

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

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

นโยบายควรพัฒนาไปพร้อมงาน

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

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

แหล่งข้อมูล

• ประกาศพรีวิว Grid ของ Baseten วันที่ 4 พฤศจิกายน
• รายงานเทคนิค Router ของ Baseten วันที่ 4 พฤศจิกายน

---

หากต้องการเก็บบันทึกการสนทนาและการตัดสินใจเบื้องหลังงานให้ค้นหาได้ สร้างบัญชี Telli.sh.