ทุกคนพูดถึง Continual Learning ราวกับว่ามันหมายถึงสิ่งเดียวเท่านั้น นั่นคือการอัปเดตน้ำหนักของโมเดล แต่มีความจริงที่ไม่สะดวกนักเกี่ยวกับระบบนิเวศของเอเจนต์ นั่นคือ เอเจนต์ส่วนใหญ่ที่ใช้งานจริงในปัจจุบันใช้ประโยชน์จากโมเดลชั้นนำแบบปิด (closed frontier models) เมื่อคุณไม่ได้เป็นเจ้าของน้ำหนักโมเดล คุณก็ไม่สามารถปรับแต่งมันได้อย่างแน่นอน สำหรับผู้สร้างเอเจนต์ส่วนใหญ่ การเรียนรู้ต่อเนื่องในระดับน้ำหนักโมเดลนั้นเป็นไปไม่ได้ โดยเฉพาะอย่างยิ่งเมื่อทำงานกับขีดความสามารถที่ล้ำสมัยที่สุด (ลองนึกถึง Fable 5 หรือ GPT 5.6)
นั่นไม่ได้หมายความว่าเอเจนต์จะเรียนรู้ไม่ได้ ระบบเอเจนต์สามารถพัฒนาได้ในสามชั้น ได้แก่ โมเดล (model) สายรัด (harness) และบริบท (context) [0] และสองชั้นหลังนั้นอยู่ภายใต้การควบคุมของคุณอย่างสมบูรณ์ นี่คือจุดที่โอกาสอันยิ่งใหญ่ (แต่มักถูกมองข้าม) ตั้งอยู่: การเรียนรู้ระดับสายรัดช่วยให้คุณสามารถขุดค้นร่องรอยการทำงานจริง (production traces) เพื่อปรับปรุงโค้ด เครื่องมือ และคำแนะนำที่ขับเคลื่อนทุกอินสแตนซ์ของเอเจนต์ของคุณอย่างเป็นระบบ ในขณะที่การเรียนรู้ระดับบริบทช่วยให้คุณปรับแต่งในระดับเอเจนต์ ผู้ใช้ และองค์กรได้ ดังนั้นผลิตภัณฑ์ของคุณจะดีขึ้นเรื่อยๆ ตามทุกการโต้ตอบ หากทำทั้งหมดข้างต้นได้ คุณจะสามารถส่งมอบการปรับปรุงที่ทวีคูณได้ทุกวัน
ในส่วนที่เหลือของบทความนี้ ผมจะอธิบายว่าเราได้นำการเรียนรู้ต่อเนื่องไปใช้กับ Replit Agent อย่างไรในช่วงปีที่ผ่านมา และแบ่งปันบทเรียนทั้งหมดที่เราได้เรียนรู้ตลอดเส้นทาง
การประเมินและปรับปรุง Replit Agent ในวงกว้าง
ผู้ใช้ Replit Agent ส่วนใหญ่เริ่มต้นจากแนวคิดหนึ่ง พวกเขาอธิบายเป้าหมายด้วยภาษาธรรมชาติ โดยไม่มี repository, ชุดทดสอบ หรือเฟรมเวิร์กที่เลือกไว้ล่วงหน้า และคาดหวังให้เอเจนต์เปลี่ยนแนวคิดนั้นให้เป็นแอปพลิเคชันที่ใช้งานได้ ผลลัพธ์ที่ได้อาจเป็นเว็บไซต์ สไลด์เด็ค แอปมือถือ อาร์ติแฟกต์ที่เชื่อมต่อกันหลายชิ้น หรือสิ่งอื่นใดก็ตาม
นักเขียนโค้ดแบบ Vibe (Vibe coders) มักจะไม่ตรวจสอบ diffs หรือผลลัพธ์การทดสอบ ความสำเร็จของ Replit Agent นั้นเรียบง่ายอย่างหลอกลวง: แอปควรทำงานได้เมื่อผู้ใช้คลิกไปรอบๆ
นั่นเปลี่ยนหน้าที่ของการประเมินผล คะแนนเดียวอาจช่วยในการตัดสินใจส่งมอบเฉพาะอย่างได้ แต่มันไม่สามารถบอกเราได้ สัปดาห์แล้วสัปดาห์เล่า ว่า Replit Agent ดีขึ้นสำหรับผู้ใช้หรือไม่ เพื่อตอบคำถามนั้น การประเมินผลจะต้องกลายเป็นส่วนหนึ่งของวงจรการปรับปรุง
NASA Lewis Research Center, ห้องควบคุมกลางในอาคารวิจัยเครื่องยนต์, 1968 — การวัดผลมีความสำคัญเมื่อมันเปลี่ยนแปลงสิ่งที่ถูกส่งมอบ
การประเมินผลต้องทำมากกว่านี้แล้วในตอนนี้
การประเมินเอเจนต์ในอดีตมักเป็นกระบวนการทางเดียว: รันการประเมิน, สร้างคะแนน, และตัดสินใจส่งมอบ วิธีนี้ใช้ได้เมื่อการปล่อยเวอร์ชันเป็นไปอย่างช้าๆ และสิ่งที่ถูกวัดนั้นแทบจะไม่เปลี่ยนแปลง แต่มันจะพังทลายเมื่อโมเดล, พรอมพ์, เครื่องมือ, และพื้นผิวผลิตภัณฑ์ทั้งหมดเปลี่ยนแปลงอย่างรวดเร็ว
วงจรแบบเก่าทำให้การประเมินผลดูมีขอบเขตจำกัด แต่ Replit Agent เปลี่ยนแปลงเร็วเกินกว่าที่คะแนนเดียวจะแบกรับการตัดสินใจทั้งหมดได้ คะแนนสามารถเปรียบเทียบผู้สมัครสองคนในงานชุดหนึ่งได้ แต่มันไม่สามารถอธิบายได้ว่าผู้ใช้สนใจอะไร, ระบบการทำงานจริงล้มเหลวตรงไหน, หรือควรปรับปรุงอะไรต่อไป
การประเมินผลต้องเปลี่ยนจากการตรวจสอบก่อนเปิดตัวเป็นวงจรการปรับปรุง
หน้าที่ของการประเมินผลแบบเก่าสิ้นสุดที่การตัดสินใจส่งมอบของมนุษย์; หน้าที่แบบใหม่จะป้อนเข้าสู่ระบบต่อเนื่องที่เรียนรู้จากการทำงานจริงและส่งมอบเอเจนต์ที่ได้รับการปรับปรุง
ระบบนี้มีเสาหลักของการวัดสองประการและวงจรการปรับให้เหมาะสมหนึ่งวงจร การวัดประสิทธิภาพแบบออฟไลน์ (Offline benchmarks) บอกเราว่าการเปลี่ยนแปลงที่เสนอสามารถทำงานจำลองการสร้างแอปพลิเคชันได้สำเร็จหรือไม่ ก่อนที่เราจะส่งมอบมัน การทดสอบ A/B แบบออนไลน์และร่องรอยการทำงานจริง (production traces) แสดงให้เห็นว่าผู้ใช้จริงได้รับผลกระทบอย่างไรหลังจากที่การเปลี่ยนแปลงถูกส่งมอบไปแล้ว สัญญาณเหล่านั้นจะไหลกลับไปสู่การประเมินผลและการตัดสินใจส่งมอบ
ไม่มีชั้นใดเพียงพอด้วยตัวมันเอง การวัดประสิทธิภาพ (Benchmarks) จับข้อบกพร่องก่อนการปล่อยเวอร์ชัน การทดสอบ A/B แสดงให้เห็นว่าพฤติกรรมการทำงานจริงเปลี่ยนแปลงไปหรือไม่ การจัดกลุ่มร่องรอย (Trace clusters) อธิบายความล้มเหลวภายใต้เมตริกรวม การตัดสินใจของมนุษย์ทำให้วงจรการปรับปรุงชี้ไปยังผลลัพธ์ทางผลิตภัณฑ์และวิศวกรรมที่ถูกต้อง รูปแบบนี้คล้ายคลึงกับโมเดล Swiss cheese ในวิศวกรรมความปลอดภัย: แต่ละชั้นมีรูพรุน แต่เมื่อรวมกันแล้วจะจับข้อบกพร่องได้มากกว่าที่ชั้นใดชั้นหนึ่งจะทำได้
การวัดประสิทธิภาพที่มีอยู่ยังไม่ถึงมือผู้ใช้
การวัดประสิทธิภาพการเขียนโค้ดแบบเอเจนต์ เช่น SWE-bench [1] และ Terminal-Bench [2] จะให้คะแนนโค้ดในสภาพแวดล้อมที่ถูกจำกัดและทำซ้ำได้ การวัดประสิทธิภาพเหล่านี้มีค่าและถูกนำไปใช้อย่างกว้างขวาง แต่พวกมันพลาดสัญญาณที่นักเขียนโค้ดแบบ Vibe ให้ความสำคัญ
Replit Agent มักจะสร้างฐานโค้ดขึ้นมาใหม่ตั้งแต่ต้น ผู้ใช้ไม่ได้นำเส้นทางที่ตายตัว, ลายเซ็นฟังก์ชัน, ตัวเลือก, หรือการทดสอบมา พวกเขานำคำขอผลิตภัณฑ์มา เอเจนต์จะเป็นผู้เลือกสแตก, สคีมา, เส้นทาง, คอมโพเนนต์, และขั้นตอนการโต้ตอบ
สิ่งนี้สร้างช่องว่างของความถูกต้องเชิงฟังก์ชัน (functional correctness gap) เอเจนต์สามารถตอบสนองข้อจำกัดเฉพาะที่ของการวัดประสิทธิภาพการเขียนโค้ดได้ แต่ก็ยังล้มเหลวในสิ่งที่ผู้ใช้เห็น: แอปที่เสร็จสมบูรณ์นั้นทำตามที่ขอหรือไม่ สำหรับการเขียนโค้ดแบบ Vibe เป้าหมายการประเมินคืออาร์ติแฟกต์นั้นเอง: มันโหลดได้หรือไม่, เวิร์กโฟลว์หลักทำงานได้หรือไม่, และผลลัพธ์ตรงกับคำขอหรือไม่
แนะนำ ViBench
ความจำเป็นสำหรับการประเมินผลแบบ end-to-end นี้คือเหตุผลที่เราสร้าง ViBench [3] ซึ่งเป็นการวัดประสิทธิภาพสาธารณะของเราสำหรับการเขียนโค้ดแบบ Vibe โดยวัดสัญญาณที่เรียบง่ายแต่สำคัญ: แอปพลิเคชันที่สร้างโดยเอเจนต์ตรงตามข้อกำหนดหรือไม่
ViBench เริ่มต้นด้วยเอกสารข้อกำหนดผลิตภัณฑ์ (PRD) ภาษาอังกฤษธรรมดาที่ดึงมาจากร่องรอยการทำงานจริงของ Replit ที่ไม่ระบุตัวตน จากนั้น เอเจนต์จะได้รับ PRD และสร้างแอปที่ทำงานได้ตั้งแต่ต้น โดยไม่ถูกจำกัดด้วยโครงสร้างพื้นฐาน, เส้นทาง, หรือการอ้างอิงที่การวัดประสิทธิภาพการเขียนโค้ดแบบดั้งเดิมต้องการ
อย่างไรก็ตาม ความยืดหยุ่นแบบเดียวกับที่ทำให้ ViBench สมจริงนั้นต้องการเอเจนต์ประเมินผลที่ยืดหยุ่นไม่แพ้กัน ซึ่งยังคงยึดมั่นใน PRD ในการวัดประสิทธิภาพแบบ SWE-bench โปรเจกต์มีอยู่แล้ว ดังนั้นพื้นผิวการประเมินจึงถูกกำหนดไว้แล้ว ในการเขียนโค้ดแบบ Vibe เอเจนต์จะเป็นผู้เลือกสแตก, เส้นทาง, คอมโพเนนต์, และโฟลว์ การประเมินผลต้องสำรวจสิ่งที่มันประดิษฐ์ขึ้นมา
เพื่อจุดประสงค์นั้น แต่ละงานของ ViBench จะจับคู่ PRD กับชุดแผนการทดสอบ ภาษาธรรมชาติ ที่อธิบายการโต้ตอบระดับฟีเจอร์และการยืนยันที่แอปที่เสร็จสมบูรณ์ต้องทำให้สำเร็จ เอเจนต์ประเมินผลใช้ Playwright เป็นแกนหลักที่ยืดหยุ่น ซึ่งช่วยให้มันสามารถใช้ฟีเจอร์ที่ซับซ้อน เช่น การจำลองแบบออฟไลน์, การจัดการไฟล์, และการเช่าหลายราย (multi-tenancy) เนื่องจากมันไม่รู้จักตัวระบุตำแหน่ง (locators) หรือโครงสร้างของแอป มาก่อน มันจึงทำงานในสภาพแวดล้อมโน้ตบุ๊ก โดยค่อยๆ ค้นพบว่าแอปถูกสร้างขึ้นมาอย่างไรและโต้ตอบกับมันทีละขั้นตอน ซึ่งเป็นแนวทางที่ได้มาจากงานวิจัยก่อนหน้าของ Replit เกี่ยวกับการทดสอบตัวเองอัตโนมัติ [4]
การรัน ViBench และการประเมินผลของเราโดยทั่วไปในระดับของ Replit ยังต้องการการสนับสนุนโครงสร้างพื้นฐานที่แข็งแกร่ง [5] ภายในองค์กร เราพึ่งพาโครงสร้างพื้นฐานการทำงานจริงแบบเดียวกับที่ช่วยให้เราสร้างแซนด์บ็อกซ์ที่แยกออกมาและมีทรัพยากรเพียงพอสำหรับการสร้างแอปและรันเอเจนต์ของเรา เนื่องจากเราสามารถ fork แซนด์บ็อกซ์เหล่านั้นได้อย่างรวดเร็ว [6] เราจึงรันการประเมินผลส่วนใหญ่แบบขนาน โดยไม่เสี่ยงต่อการปนเปื้อนข้ามการประเมิน
นอกเหนือจากการสร้างแอปตั้งแต่ต้นแล้ว รากฐาน ViBench เดียวกันนี้ ซึ่งก็คือ PRD ภาษาธรรมชาติที่ถูกให้คะแนนโดยแผนการทดสอบภาษาธรรมชาติ สามารถปรับให้เข้ากับสถานการณ์การเขียนโค้ดแบบ Vibe ที่หลากหลายได้ เพื่อประเมินว่าเอเจนต์ทำงาน ภายใน แอปที่มีอยู่แล้วอย่างไร ซึ่งใกล้เคียงกับปริมาณงานในช่วงกลางของวิถี (mid-trajectory workloads) ของ Replit เราจะเริ่มต้นมันบนฐานโค้ดที่มีอยู่และวัดว่ามันสามารถส่งมอบส่วนขยายฟีเจอร์จาก PRD ฟีเจอร์ได้ดีเพียงใด ฐานโค้ดนั้นอาจมาจากการอ้างอิงการใช้งานของเราเองหรือจากแอปที่เอเจนต์เขียนโค้ดแบบ Vibe ขึ้นมาเอง ซึ่งเราเรียกว่า Vibe-to-ref และ Vibe-on-Vibe ในสิ่งพิมพ์ของเรา เมื่อเราส่งมอบพื้นผิวผลิตภัณฑ์ใหม่ แกนหลักเดียวกันนี้ช่วยให้เราสามารถสร้างปัญหาใหม่ๆ เพื่อประเมินรูปแบบการโต้ตอบที่แปลกใหม่ได้อย่างรวดเร็ว เช่นเดียวกับที่เราทำสำหรับการแยกย่อยแบบ parallel-and-merge และ subagent ของ Agent 4
ViBench จะคงตัวประเมินพฤติกรรมไว้คงที่ในขณะที่เปลี่ยนแปลงกลยุทธ์อินพุตและการสร้าง
ผลลัพธ์ ViBench ในช่วงแรกให้บทเรียนที่มีประโยชน์สองข้อแก่เรา ประการแรก คะแนนการวัดประสิทธิภาพการเขียนโค้ดชั้นนำนั้นไม่ได้ถ่ายทอดไปสู่การสร้างแอปพลิเคชันเต็มรูปแบบเสมอไป โดยเฉพาะอย่างยิ่งสำหรับโมเดลน้ำหนักเปิด (open-weight models) ประการที่สอง โมเดลส่วนใหญ่จะแย่ลงเมื่อต้องขยายโค้ดของตัวเอง เนื่องจากข้อผิดพลาดมักจะทวีคูณ เมื่อรวมกันแล้ว บทเรียนเหล่านั้นทำให้เรามีเนินเขาที่ดีกว่าให้ปีน: ไม่ใช่แค่การเขียนโค้ดที่ผ่านการทดสอบ แต่เป็นการสร้างแอปที่สามารถอยู่รอดจากคำขอของผู้ใช้ครั้งต่อไป
A/B คือวิธีที่เราทำให้ตัวเองซื่อสัตย์
เราเชื่อถือการประเมินแบบออฟไลน์อย่างลึกซึ้ง แต่มันไม่ใช่ผู้ตัดสินเพียงคนเดียว เราเห็นการอัปเดตเอเจนต์มากมายที่ดูดีในสภาพแวดล้อมที่มีการควบคุม แต่กลับทำให้พฤติกรรมผู้ใช้จริงถดถอย เราจึงรู้ว่าการทำงานจริงต้องการชั้นการวัดของตัวเอง
ผู้ใช้ไม่ได้ถูกกำหนดสคริปต์, ทำงานตลอดเวลา, และดำเนินการในระดับที่การวัดประสิทธิภาพแบบออฟไลน์ไม่สามารถจำลองได้อย่างสมบูรณ์ พวกเขาละทิ้งโปรเจกต์, เปลี่ยนใจ, รวมฟีเจอร์ในรูปแบบที่น่าประหลาดใจ, และค้นพบโหมดความล้มเหลวที่เราไม่รู้ว่าจะทดสอบ
ดังนั้นเราจึงทำ A/B การอัปเดตที่ส่งผลกระทบต่อเอเจนต์ส่วนใหญ่: พรอมพ์, เครื่องมือ, การแก้ไขสายรัด, การสลับโมเดล, และการเปลี่ยนแปลงพฤติกรรมที่ใหญ่ขึ้น การทดลองหลายๆ ครั้งมักจะทำงานพร้อมกัน โดยมีการระบุแหล่งที่มาอย่างชัดเจนเพื่อหลีกเลี่ยงการซ่อนผลกระทบจากการโต้ตอบ การทดสอบ A/B เผยให้เห็นพฤติกรรมผู้ใช้, ความรู้สึก, และความสำเร็จ: ผู้ใช้ยังคงใช้ต่อไปหรือไม่, ต้นทุนมีพฤติกรรมที่ไม่คาดคิดหรือไม่, ความรู้สึกเปลี่ยนไปหรือไม่, และผู้ใช้ส่งมอบบางสิ่งหรือไม่
การทดสอบ A/B ให้ข้อมูลเชิงลึกที่มีการควบคุมเกี่ยวกับพฤติกรรมการทำงานจริงแก่เรา แต่เมตริกรวมไม่ได้อธิบายตัวเอง นี่คือชัยชนะหรือไม่? การเปลี่ยนแปลงพฤติกรรมที่แท้จริงคืออะไร?
ความท้าทายของการทดสอบ A/B คือผลลัพธ์นั้นตีความได้ยาก หากระยะเวลาการรันเพิ่มขึ้น เอเจนต์ทำงานที่มีประโยชน์มากขึ้นหรือติดขัด? หากต้นทุนลดลง เราปรับปรุงประสิทธิภาพหรือเอเจนต์หยุดทำสิ่งที่มีค่าอย่างเงียบๆ? หากความรู้สึกลดลง กรณีการใช้งานใดที่ถดถอย, โหมดความล้มเหลวใดที่ใหม่, และผู้ใช้รายใดที่ยอมแพ้?
Telescope: สิ่งที่กำลังพัง
การทดสอบ A/B บอกเราว่าเมื่อใดที่พฤติกรรมการทำงานจริงเปลี่ยนไป Telescope — ระบบของเราสำหรับการวิเคราะห์และจัดกลุ่มร่องรอย — ช่วยอธิบายว่าทำไม
ในระดับการทำงานจริง ไม่มีวิศวกรคนใดสามารถอ่านทุกร่องรอยได้ Telescope จัดรูปแบบที่เกิดซ้ำเป็นกลุ่มปัญหาที่วิศวกรและเอเจนต์สามารถดำเนินการได้ มันสรุปวิถีความล้มเหลว, ฝังมัน, จัดกลุ่มกรณีที่คล้ายกัน, และจำแนกเซสชันใหม่เมื่อการกระจายตัวเปลี่ยนไป เป้าหมายไม่ใช่แค่นับความล้มเหลว แต่เพื่อค้นหาสิ่งที่ซ่อนอยู่ในที่แจ้ง
GIF
การจัดกลุ่มสิ่งที่เราไม่รู้ว่าจะมองหา
Telescope ใช้แง่มุมสั้นๆ ที่มีหลักฐานสนับสนุน ซึ่งได้รับแรงบันดาลใจจากแนวทางจากล่างขึ้นบนแบบเดียวกับ Clio [7] สำหรับร่องรอย มันจะสร้างเซสชันขึ้นมาใหม่จากข้อความผู้ใช้, การตอบกลับของเอเจนต์ที่มองเห็นได้, การเรียกใช้เครื่องมือ, ข้อผิดพลาด, เมตาดาต้า, และบริบทอื่นๆ จากนั้น Telescope จะสรุปสิ่งที่ผิดพลาด, ฝังสรุปเหล่านั้น, และใช้การจัดกลุ่มตามความหนาแน่น [8] เพื่อสร้างกลุ่มปัญหาที่เกิดขึ้นใหม่
แง่มุมต่างๆ ทำให้การตรวจสอบเร็วขึ้น โดยเฉพาะอย่างยิ่งเมื่อการจัดกลุ่มเพียงอย่างเดียวไม่เพียงพอ เมื่อรายงานการสนับสนุนชี้ไปยังปัญหาที่กว้าง เช่น ความล้มเหลวของพอร์ต วิศวกรและเอเจนต์สามารถค้นหาชั้นที่กะทัดรัดก่อน สำรวจแง่มุมที่เกี่ยวข้อง จากนั้นเจาะลึกเข้าไปในเซสชันที่เป็นตัวแทนพร้อมกับบริบทของบันทึกและการสังเกตการณ์ที่จำเป็นในการอธิบายมัน
โดยรวมแล้ว โครงสร้างเดียวกันนี้เปลี่ยนความล้มเหลวที่กระจัดกระจายให้เป็นคำถามเกี่ยวกับผลิตภัณฑ์: เวิร์กโฟลว์ใดที่โดดเด่น, เวิร์กโฟลว์ใดที่ถูกทอดทิ้ง, อะไรที่พังซ้ำแล้วซ้ำเล่า, และการบรรเทาผลกระทบกำลังทำให้กลุ่มเป้าหมายหดตัวลงหรือไม่
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับสถาปัตยกรรมพื้นฐานนี้ โปรดดูโพสต์เชิงลึกเกี่ยวกับ Topics จากผู้ทำงานร่วมกันของเราที่ Braintrust [9]
วงจร: จากหลักฐานสู่การปรับปรุงเอเจนต์
เมื่อมีการวัดผลแล้ว คอขวดก็จะเคลื่อนที่ ViBench, การทดสอบ A/B, และ Telescope สามารถบอกเราได้ว่าอะไรล้มเหลว, ล้มเหลวที่ไหน, และเกิดขึ้นบ่อยแค่ไหน เรายังคงต้องเปลี่ยนหลักฐานนั้นให้เป็นการแก้ไขที่เป็นไปได้
เราหันไปใช้วงจรการปรับปรุงตนเองเพื่อจัดการกับสิ่งนี้ หลักการทำงานนั้นเรียบง่าย: หากเอเจนต์มีประโยชน์สำหรับการสร้างซอฟต์แวร์ พวกมันก็ควรมีประโยชน์สำหรับการปรับปรุงเอเจนต์ด้วย แต่ละรอบเริ่มต้นด้วยการอ่านบันทึกการทำงานจริง, กลุ่มร่องรอย, และความล้มเหลวล่าสุดเพื่อค้นหาสมมติฐานที่ควรค่าแก่การไล่ตาม จากนั้นมันจะสร้างผู้สมัคร, เปิด PR แบบร่างพร้อมเหตุผลที่แนบมา, วัดผลลัพธ์เทียบกับ ViBench, ผลลัพธ์ A/B, ข้อมูลวิถี, และเกณฑ์มาตรฐานล่าสุด, และแนะนำว่าจะส่งมอบ, ทำซ้ำ, หรือทิ้งมัน
วงจรการปรับให้เหมาะสมจะค้นพบปัญหา, เสนอการเปลี่ยนแปลงเอเจนต์, ประเมินผล, และตัดสินใจว่าจะส่งมอบ, ทำซ้ำ, หรือทิ้ง
การส่งมอบไม่ได้กลายเป็นอัตโนมัติ วงจรสามารถเตรียมหลักฐานและการนำไปใช้ในรอบแรกได้ วิศวกรยังคงตรวจสอบผลลัพธ์และเป็นเจ้าของการตัดสินใจเปิดตัว
แต่ละรันจะบันทึกสิ่งที่พยายามและสิ่งที่เกิดขึ้น รวมถึงความล้มเหลว บันทึกนั้นจะปรับปรุงวงจรเมื่อเวลาผ่านไป: การรันในอนาคตสามารถนำสิ่งที่ใช้ได้ผลกลับมาใช้ใหม่, หลีกเลี่ยงทางตันที่รู้จัก, และเสนอการเปลี่ยนแปลงที่สามารถสรุปเป็นทั่วไปได้
การทำซ้ำเอเจนต์เร็วขึ้นโดยไม่ต้องละทิ้งการควบคุมทางวิศวกรรม เมื่อได้รับโมเดลใหม่, พื้นผิวผลิตภัณฑ์, หรือเป้าหมายความน่าเชื่อถือ วงจรสามารถค้นหาการแก้ไขพรอมพ์, ข้อเสนอทักษะ, การแก้ไขเครื่องมือ, และการเปลี่ยนแปลงสายรัดในเชิงรุก ในขณะที่วิศวกรยังคงให้ระบบชี้ไปยังจุดที่เหมาะสมที่สุดของผลิตภัณฑ์โดยรวม
ตัวอย่างที่เป็นรูปธรรม
การรันครั้งล่าสุดครั้งหนึ่งเริ่มต้นด้วยกลุ่ม Telescope ขนาดเล็กแต่กำลังเติบโต การตั้งค่าสภาพแวดล้อมกำลังลดประสิทธิภาพลงอย่างเงียบๆ ในหางยาวของสถานการณ์ cold-start เซสชันเหล่านี้ไม่ชัดเจนจากเมตริกรวม แต่กลุ่มแสดงรูปแบบที่ควรค่าแก่การตรวจสอบ
หลังจากแสดงรูปแบบ วงจรได้อ่านวิถีที่ได้รับผลกระทบ, เสนอแพตช์, เพิ่มการทดสอบการถดถอย, และรันผู้สมัครเทียบกับ ViBench เพื่อยืนยันว่าเส้นทางหลัก (happy path) ไม่ได้ถดถอย วิศวกรตรวจสอบหลักฐาน, อนุมัติการเปลี่ยนแปลง, และผลักดันไปยังการทำงานจริงในวันเดียวกัน
หลังจากที่แพตช์ถูกส่งมอบ ความรู้สึกฟื้นตัวและผู้ใช้ที่ได้รับผลกระทบก็ถูกปลดบล็อก นี่คือรูปแบบที่เราต้องการ — วงจรที่ค้นหารูปแบบความล้มเหลวจริง, เชื่อมต่อกับผู้ใช้ที่ได้รับผลกระทบ, เสนอระดับการแก้ไขที่ถูกต้อง, และนำหลักฐานกลับมาเพียงพอสำหรับมนุษย์ในการตัดสินใจว่าจะส่งมอบหรือไม่
จุดที่รสนิยมของมนุษย์ยังคงสำคัญที่สุด
ส่วนใหญ่ของสิ่งนี้สามารถทำงานได้โดยอัตโนมัติ: การจัดกลุ่มความล้มเหลว, การเสนอสมมติฐาน, การสร้างผู้สมัคร, การรันการประเมิน, และการรวบรวมหลักฐาน มนุษย์ยังคงกำหนดทิศทางและควบคุมการออกส่วนใหญ่ รวมถึง:
- การเลือกสมมติฐาน. ระบบสามารถแสดงความล้มเหลวนับพันรายการ แต่มนุษย์เป็นผู้ตัดสินว่าคำถามใดสมควรได้รับงบประมาณข้ามคืนของวงจร ไม่ใช่ทุกกลุ่มที่มีความสำคัญเท่ากัน และไม่ใช่ทุกการถดถอยที่ชี้ไปยังปัญหาผลิตภัณฑ์ที่ถูกต้อง
- สถาปัตยกรรมการนำไปใช้. ร่องรอยอาจแสดงให้เห็นว่าผู้ใช้กำลังละทิ้งเวิร์กโฟลว์ แต่การตัดสินใจว่าจะทำให้เส้นทางนั้นราบรื่นขึ้น, เปลี่ยนพฤติกรรมของเอเจนต์, หรือออกแบบพื้นผิวใหม่นั้นเป็นการตัดสินใจทางวิศวกรรมและผลิตภัณฑ์
- การดูแลจัดการการประเมินผล. นี่ไม่ใช่งานธุรการ มันกำหนดเนินเขาที่เอเจนต์จะปีน หากการประเมินผลให้รางวัลกับพฤติกรรมที่ผิด วงจรการปรับให้เหมาะสมจะปรับให้เหมาะสมไปสู่สิ่งที่ผิดอย่างซื่อสัตย์
- การอนุมัติการเปิดตัว. การส่งมอบการเปลี่ยนแปลงเอเจนต์ไม่ใช่แค่การอ่านตัวเลข การอนุมัติการเปิดตัวหมายถึงการอ่านหลักฐาน, การทำความเข้าใจรัศมีการระเบิด, การตัดสินใจว่าความเสี่ยงนั้นยอมรับได้หรือไม่, และการเป็นเจ้าของการเปิดตัว
ความสมดุลนั้นสำคัญ: วงจรสามารถทำการค้นหา, การวัด, และการสังเคราะห์ได้มากขึ้น วิศวกรยังคงเลือกทิศทาง, ตัดสินใจเกี่ยวกับผลิตภัณฑ์, และตัดสินใจว่าอะไรจะถูกส่งมอบ
ปิดวงจร
การประเมินผลไม่ใช่แค่ประตูก่อนการเปิดตัวอีกต่อไป มันช่วยตัดสินใจว่าจะแก้ไขอะไร, จะทดสอบอะไร, และจะปล่อยอะไร
งานไม่ใช่การสร้างตัวเลขที่ดีขึ้น แต่มันคือการเปลี่ยนความล้มเหลวของผู้ใช้ให้เป็นการปล่อยเวอร์ชันที่ดีขึ้น เพื่อให้แนวคิดต่างๆ กลายเป็นแอปที่ผู้คนภูมิใจที่จะเผยแพร่
เรารู้สึกตื่นเต้นที่จะผลักดันขอบเขตของเอเจนต์อัตโนมัติต่อไป โดยมุ่งเน้นที่ความน่าเชื่อถือสำหรับงานเขียนโค้ดที่ซับซ้อนที่สุด หากคุณสนใจที่จะทำงานกับเอเจนต์เขียนโค้ดอัตโนมัติ ผมกำลังรับสมัครทีม Replit AI อยู่เสมอ — ติดต่อได้ที่ [email protected]
ผู้เขียน: Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
เอกสารอ้างอิง
[0] การเรียนรู้ต่อเนื่องสำหรับเอเจนต์ AI
[1] SWE-bench: โมเดลภาษาสามารถแก้ไขปัญหา GitHub ในโลกแห่งความจริงได้หรือไม่?
[2] Terminal-Bench: การวัดประสิทธิภาพเอเจนต์ในงานที่ยากและสมจริงในอินเทอร์เฟซบรรทัดคำสั่ง
[3] ViBench: การวัดประสิทธิภาพสำหรับการเขียนโค้ดแบบ Vibe
[4] การทำให้ Agent 3 สามารถทดสอบตัวเองในวงกว้างด้วยการตรวจสอบตาม REPL
[5] การวัดปริมาณสัญญาณรบกวนโครงสร้างพื้นฐานในการประเมินการเขียนโค้ดแบบเอเจนต์
[6] ภายใน Snapshot Engine ของ Replit: เทคโนโลยีที่ทำให้เอเจนต์ AI ปลอดภัย
[7] Clio: ข้อมูลเชิงลึกที่รักษาความเป็นส่วนตัวเกี่ยวกับการใช้ AI ในโลกแห่งความจริง
[8] การประมาณความหนาแน่นแบบลำดับชั้นสำหรับการจัดกลุ่มข้อมูล, การแสดงภาพ, และการตรวจจับค่าผิดปกติ
[9] เราทำให้การวิเคราะห์ร่องรอยอย่างต่อเนื่องเป็นไปได้ในวงกว้างได้อย่างไร
