ทีม AI และโครงสร้างพื้นฐานของ Google ได้เผยแพร่สิ่งที่น่าสนใจอย่างเงียบๆ ในบล็อกโพสต์ที่คนในวงการส่วนใหญ่ผ่านเลยไป นั่นคือการเพิ่มความเร็วถึงหกเท่าในการย้ายโมเดล Machine Learning ระดับโปรดักชันจาก TensorFlow ไปยัง JAX ในระดับที่เกี่ยวข้องกับโค้ดหลายพันบรรทัด เลเยอร์หลายร้อยชั้น และการพึ่งพาที่ลึกล้ำข้ามไฟล์หลายไฟล์ Sundar Pichai กล่าวถึงเรื่องนี้บนเวทีในงาน Google Cloud Next ตัวเลขดังกล่าวกลายเป็นพาดหัวข่าว แต่สถาปัตยกรรมที่อยู่เบื้องหลังคือเรื่องราวที่แท้จริง และเป็นสถาปัตยกรรมเดียวกันที่อยู่เบื้องหลังการย้ายระบบเอเจนต์ขนาดใหญ่ที่น่าเชื่อถือทุกตัวที่กำลังเกิดขึ้นในตอนนี้ ไม่ว่าฝูงเอเจนต์นั้นจะมี 8 ตัวหรือ 800 ตัวก็ตาม
นี่คือรายละเอียดที่สำคัญที่สุด: พวกเขาลองใช้เอเจนต์ AI ตัวเดียวจัดการกับโค้ดเบสก่อน มันล้มเหลว ไม่ใช่ล้มเหลวบางส่วน มันสูญเสียบริบท สร้าง API ที่ไม่มีอยู่จริงขึ้นมาเอง และสร้างโค้ดที่คอมไพล์ไม่ได้ วิธีแก้ไขไม่ใช่การใช้โมเดลที่ฉลาดกว่า แต่เป็นสถาปัตยกรรมที่แตกต่างไปโดยสิ้นเชิง ซึ่งปัจจุบันมีชื่อเรียกว่า รูปแบบ "dark factory" (โรงงานมืด) ซึ่งเป็นโค้ดเบสที่เอเจนต์วางแผน ดำเนินการ ทดสอบ และจัดส่งโค้ดโดยที่ไม่มีการตรวจสอบจากมนุษย์เลยในวงจร เหมือนกับโรงงานอัตโนมัติเต็มรูปแบบที่เดินเครื่องจักรในความมืด เพราะไม่มีใครเหลือให้เปิดไฟอีกแล้ว
บทความนี้คือการแจกแจงรูปแบบนั้นอย่างสมบูรณ์ ไม่ใช่เวอร์ชันทางการตลาด แต่เป็นกลไกที่แท้จริงว่าเอเจนต์หลายร้อยตัวย้ายโค้ดเบสจริงโดยที่มนุษย์ไม่ต้องตรวจสอบการเปลี่ยนแปลงแต่ละรายการได้อย่างไร และเหตุใดสิ่งที่ทำให้มันปลอดภัยไม่ใช่ความไว้วางใจในโมเดล แต่เป็นสถาปัตยกรรมที่ออกแบบมาโดยเฉพาะเพื่อไม่ต้องพึ่งพาความไว้วางใจนั้นตั้งแต่แรก
เหตุใดเอเจนต์ตัวเดียวถึงล้มเหลวในระดับใหญ่
ก่อนจะพูดถึงสถาปัตยกรรม ให้เข้าใจก่อนว่าเหตุใดแนวทางแบบง่ายถึงพังทลาย เพราะการตัดสินใจออกแบบทุกอย่างในรูปแบบที่ใช้งานได้จริงนั้นมีไว้เพื่อแก้ไขความล้มเหลวเหล่านี้โดยเฉพาะ
เอเจนต์ตัวเดียวที่ชี้ไปยังโค้ดเบสขนาดใหญ่จะเจอปัญหาด้านบริบทก่อน แม้จะมีหน้าต่างบริบทที่กว้างขวาง โค้ดเบสที่มีไฟล์ที่พึ่งพากันหลายร้อยไฟล์ สายการเรียกที่ลึก และสมมติฐานที่สืบทอดข้ามโมดูลก็เกินกว่าที่เซสชันเดียวจะเก็บไว้อย่างสอดคล้องกันได้ เอเจนต์เริ่มต้นได้ดีกับสองสามไฟล์แรก แต่ประสิทธิภาพจะลดลงเมื่อบริบทการทำงานเต็มไปด้วยประวัติศาสตร์ที่สะสมและเกี่ยวข้องเพียงครึ่งเดียว
จากนั้นมันก็เจอปัญหาการจัดลำดับ การย้ายโค้ดไม่ใช่งานที่ทำแบบขนานได้โดยค่าเริ่มต้น ไฟล์ B มักจะขึ้นอยู่กับว่าไฟล์ A ถูกย้ายไปแล้วหรือไม่ เพราะลายเซ็นฟังก์ชันเปลี่ยนไป การนำเข้า (import) ถูกย้าย หรือโครงสร้างข้อมูลเปลี่ยนรูปร่าง เอเจนต์ที่ไม่มีแผนที่การพึ่งพาที่ชัดเจนจะเดาลำดับ ซึ่งทำให้เกิดสถานะกลางที่พัง หรือไม่ก็ประมวลผลไฟล์ตามลำดับที่มันถูกแสดงไว้ ซึ่งก็เหมือนกับการเดานั่นเอง
จากนั้นมันก็เจอปัญหาการตรวจสอบ และนี่คือปัญหาที่สำคัญที่สุดจริงๆ เอเจนต์ที่ย้ายโค้ดแล้วประเมินการย้ายของตัวเอง ก็คือการตรวจการบ้านของตัวเองด้วยจุดบอดเดียวกับที่ทำให้เกิดข้อผิดพลาดตั้งแต่แรก ถ้าเอเจนต์ไม่เข้าใจว่า API ตัวหนึ่งทำงานแตกต่างไปภายใต้เวอร์ชันใหม่ มันก็จะไม่จับข้อผิดพลาดนั้นเมื่อตรวจสอบผลลัพธ์ของตัวเอง เพราะช่องว่างความเข้าใจเดียวกันนั้นมีอยู่ทั้งในรอบแรกและรอบที่สอง
ทีมของ Google ค้นพบสิ่งนี้โดยตรง การตั้งค่าเอเจนต์ตัวเดียวไม่สามารถสร้างสมดุลระหว่างกฎโครงสร้างของการย้ายกับรายละเอียดการดำเนินการทีละบรรทัดได้พร้อมกัน การแยกข้อกังวลทั้งสองนี้ออกเป็นบทบาทที่แตกต่างกันคือวิธีแก้ไขที่แท้จริง และเป็นวิธีแก้ไขเดียวกันที่ปรากฏในคู่มือการย้ายที่เผยแพร่โดย OpenAI ในงานวิจัยทางวิชาการเกี่ยวกับลูปการย้ายแบบหลายเอเจนต์ และในทุกระบบการผลิตที่ใช้งานจริงในระดับนี้
สถาปัตยกรรม: สามบทบาท ไม่ใช่ผู้เชี่ยวชาญทั่วไปคนเดียว
รูปแบบที่ใช้งานได้จริงจะแบ่งงานออกเป็นบทบาทที่มีหน้าที่แตกต่างกันอย่างแท้จริง ไม่ใช่แค่พรอมต์ที่แตกต่างกันที่ชี้ไปยังเอเจนต์ทั่วไปตัวเดียวกัน
นักวางแผน (Planner) ที่ใช้เครื่องมือเชิงกำหนด (deterministic tooling) ไม่ใช่การเดาของ LLM เพื่อจัดลำดับงาน นี่คือรายละเอียดที่แยกระบบที่ปรับขนาดได้จริงออกจากระบบที่ดูน่าประทับใจในการสาธิตแต่พังทลายในโปรดักชัน นักวางแผนของ Google ไม่ได้ขอให้ LLM คิดหาลำดับการย้ายผ่านการใช้เหตุผล มันใช้การวิเคราะห์แบบสแตติกบนคอมไพเลอร์ (compiler-based static analysis) ซึ่งเป็นเครื่องมือเชิงกำหนดประเภทเดียวกับที่รองรับซอฟต์แวร์องค์กรมาหลายทศวรรษ เพื่อสร้างแผนผังการพึ่งพาที่แท้จริงและกำหนดแผนการดำเนินการที่เริ่มต้นจากโหนดใบ (ไฟล์ที่ไม่มีอะไรอื่นพึ่งพา) และทำงานขึ้นไปยังไฟล์ที่ทุกอย่างอื่นพึ่งพา
สิ่งนี้สำคัญเพราะการจัดลำดับการพึ่งพาไม่ใช่ปัญหาที่ต้องใช้ความคิดสร้างสรรค์ มันเป็นปัญหาเชิงกลไกที่มีคำตอบที่ถูกต้อง และการใช้ LLM เพื่อแก้ปัญหาที่มีวิธีแก้ไขเชิงกำหนดอยู่แล้ว ก็แค่เพิ่มแหล่งที่มาของข้อผิดพลาดใหม่ที่ไม่จำเป็นต้องมี กฎเบื้องหลังนี้คือ: ทุกที่ที่ปัญหามีคำตอบแบบอัลกอริทึม ให้ใช้อัลกอริทึม สำรองโมเดลภาษาไว้สำหรับส่วนของงานที่ต้องใช้ดุลยพินิจอย่างแท้จริง ซึ่งก็คือการแปลงโค้ดจริง ไม่ใช่การจัดลำดับว่าไฟล์ไหนมาก่อน
เอเจนต์การย้าย (Migration Agent) (หรือในระบบขนาดใหญ่ อาจมีหลายร้อยตัวทำงานแบบขนาน โดยเป็นอินสแตนซ์ที่แยกออกจากกันและมีขอบเขตแคบของบทบาทเดียวกัน) ที่ทำการแปลงโค้ดจริง แต่ละอินสแตนซ์ได้รับงานที่มีขอบเขตเดียว โดย ideally หนึ่งไฟล์หรือหนึ่งโมดูลที่มีขอบเขตจำกัด การเช็คเอาท์ครั้งเดียว และสรุปการย้ายที่ชัดเจนซึ่งอธิบายว่าต้องเปลี่ยนแปลงอะไรและเพราะเหตุใด มันตรวจสอบโค้ดที่เกี่ยวข้อง ทำการแก้ไข และสร้างแพตช์ มันไม่ได้ตัดสินว่าแพตช์ของตัวเองถูกต้องหรือไม่ นั่นไม่ใช่งานของมัน และสถาปัตยกรรมถูกออกแบบมาโดยเฉพาะเพื่อไม่ให้มันรับงานนั้นโดยไม่ได้ตั้งใจ
เลเยอร์สภาพแวดล้อมและการตรวจสอบ (Environment and Verification layer) ที่สร้าง รัน และทดสอบโค้ดที่ย้ายแล้วในสภาพแวดล้อมที่แยกออกมา ก่อนที่จะยอมรับสิ่งใด นี่คือจุดที่ "เสร็จแล้วคือเสร็จ" กลายเป็นข้อเท็จจริงเชิงกลไก ไม่ใช่ความคิดเห็น กรอบความคิดของ Google ในเรื่องนี้แม่นยำ: อุตสาหกรรมมีตัวเลือกที่ไม่ดีสองทางในอดีตสำหรับการตัดสินว่างานของ AI เสร็จสมบูรณ์จริงหรือไม่ นั่นคือการตรวจสอบโดยมนุษย์ซึ่งไม่สามารถปรับขนาดเป็นหลายร้อยไฟล์ได้ หรือการประเมินตนเองของ AI ซึ่งไม่สามารถตรวจสอบได้เพราะไม่มีบันทึกว่าตรวจสอบอะไรจริงๆ คำตอบของพวกเขาคือการตรวจสอบทางคณิตศาสตร์ (mathematical verification) โค้ดเชิงกำหนดที่ยืนยันว่าการคอมไพล์สำเร็จ การทดสอบผ่าน และพฤติกรรมตรงกับสเปกที่กำหนด ซึ่งแทนที่ตัวเลือกที่ไม่ดีทั้งสองด้วยตัวเลือกที่สามที่สามารถตรวจสอบได้จริง
สังเกตสิ่งที่หายไปจากรายการนี้: มนุษย์ที่อ่าน diff แต่ละรายการก่อนที่จะรวม (merge) นั่นคือประเด็นทั้งหมดของรูปแบบ dark factory และมันก็เป็นจุดที่สัญชาตญาณของคนส่วนใหญ่เกี่ยวกับความปลอดภัยผิดพลาด เพราะมันฟังดูเหมือนว่าระบบกำลังไว้วางใจเอเจนต์มากขึ้น มันตรงกันข้าม มันกำลังไว้วางใจเอเจนต์น้อยลง ในเชิงโครงสร้าง โดยการแทนที่จุดตัดสินใจจุดเดียว "เอเจนต์บอกว่าสิ่งนี้ใช้ได้" ด้วยเลเยอร์การตรวจสอบที่เอเจนต์ไม่สามารถมีอิทธิพลหรือเลี่ยงได้
เลเยอร์การแยก: ทำไมเอเจนต์แต่ละตัวถึงได้รับ Sandbox ของตัวเอง
การรันเอเจนต์หลายร้อยตัวกับโค้ดเบสเดียวกันพร้อมกันทำให้เกิดความเสี่ยงที่ชัดเจน: จะเกิดอะไรขึ้นเมื่อเอเจนต์ 47 กำลังแก้ไขไฟล์ที่การเปลี่ยนแปลงของเอเจนต์ 12 พึ่งพาอยู่ และการแก้ไขของเอเจนต์ 12 เพิ่งทำให้การคอมไพล์พัง
คำตอบ ซึ่งสอดคล้องกันในสถาปัตยกรรมการย้ายที่เผยแพร่ของ OpenAI และระบบการผลิตของ Google คือการแยกเป็นค่าเริ่มต้น งานย้ายแต่ละงานรันในสภาพแวดล้อมแบบแซนด์บ็อกซ์ของตัวเอง ซึ่งมักจะเป็น git worktree ของตัวเอง ซึ่งเป็นการเช็คเอาท์พื้นที่เก็บข้อมูลที่เกี่ยวข้องอย่างสมบูรณ์และเป็นอิสระ โดยจำกัดขอบเขตไว้ที่งานนั้นๆ หากเอเจนต์ในแซนด์บ็อกซ์นั้นทำอะไรพัง มันจะพังเฉพาะสำเนาที่แยกออกมา ไม่ใช่โค้ดเบสที่ใช้ร่วมกัน และแน่นอนว่าไม่ใช่งานที่กำลังดำเนินการของเอเจนต์อื่น
การแยกนี้ทำมากกว่าแค่ป้องกันการชนกัน มันทำให้ทั้งระบบสามารถขนานได้อย่างง่ายดาย เพราะไม่มีสถานะที่เปลี่ยนแปลงได้ซึ่งใช้ร่วมกันให้เอเจนต์หลายร้อยตัวเข้ามาเหยียบ เอเจนต์ 1 ถึงเอเจนต์ 800 สามารถทำงานพร้อมกันได้จริงๆ แต่ละตัวอยู่ในสภาพแวดล้อมที่สะอาดซึ่งมีเฉพาะไฟล์และบริบทที่เกี่ยวข้องกับงานเฉพาะของมัน โดยมีความเสี่ยงเป็นศูนย์ที่ภาพหลอนของเอเจนต์หนึ่งจะปนเปื้อนงานที่ถูกต้องของอีกเอเจนต์หนึ่ง
โครงสร้างควบคุม (harness) ซึ่งเป็นเลเยอร์การประสานงานที่ตัดสินว่างานไหนไปที่แซนด์บ็อกซ์ไหนและจะเกิดอะไรขึ้นกับแพตช์ที่ได้ จะอยู่ภายนอกทุกแซนด์บ็อกซ์แต่ละตัว นี่คือตัวเลือกทางสถาปัตยกรรมที่เฉพาะเจาะจงและสำคัญ: กระบวนการที่เชื่อถือได้ซึ่งสามารถเข้าถึงความลับ เครื่องมือภายนอก และพื้นที่เก็บข้อมูลจริง จะแยกอยู่ต่างหากจากสภาพแวดล้อมการดำเนินการที่ไม่น่าเชื่อถือซึ่งโค้ดที่สร้างโดย AI ทำงานจริง แซนด์บ็อกซ์ได้รับสิ่งที่ต้องการสำหรับงานเดียวเท่านั้น ไม่มีอะไรเพิ่มเติม กระบวนการโฮสต์ไม่เคยรันโค้ดที่สร้างขึ้นโดยตรงด้วยสิทธิ์ที่สูงขึ้นของตัวเอง การแยกนี้คือสิ่งที่ทำให้ปลอดภัยที่จะปล่อยให้โค้ดของเอเจนต์ทำงานเลย เนื่องจากข้อผิดพลาดหรือแม้แต่การฉีดพรอมต์ที่เป็นปฏิปักษ์ภายในแซนด์บ็อกซ์ไม่มีทางไปถึงสิ่งใดภายนอกมันได้
ลูปที่แท้จริง: วางแผน ดำเนินการ ตรวจสอบ ปรับปรุง
ลอกเลเยอร์ของขนาดและเครื่องมือเฉพาะออกไป ลูปที่แท้จริงที่ทำงานอยู่เบื้องหลังทั้งหมดนี้มีสี่ขั้นตอน ทำซ้ำต่องานนั้นจนกว่างานจะผ่านหรือใช้สิทธิ์ลองใหม่หมด
ขั้นตอนที่หนึ่ง: การวางแผนการย้าย เอเจนต์การย้ายได้รับงานที่มีขอบเขต หนึ่งไฟล์หรือหนึ่งโมดูล สเปกเป้าหมายเฉพาะ (เวอร์ชันภาษา การเปลี่ยนแปลงเฟรมเวิร์ก ข้อกำหนดความเข้ากันได้ของ API) และสร้างการแปลงที่เป็นตัวเลือก นี่เป็นขั้นตอนเดียวที่การใช้เหตุผลเชิงสร้างสรรค์และใช้ดุลยพินิจของโมเดลภาษาทำงานหลัก เพราะการตัดสินใจว่าจะแปลรูปแบบเฉพาะรูปแบบหนึ่งให้เทียบเท่าในเฟรมเวิร์กใหม่อย่างถูกต้องนั้นต้องใช้ความเข้าใจ ไม่ใช่แค่การค้นหาเชิงกลไก
ขั้นตอนที่สอง: การตั้งค่าสภาพแวดล้อมอัตโนมัติ คอมโพเนนต์ที่แยกต่างหาก ซึ่งบางครั้งเรียกว่า Environment Agent ในเอกสารวิชาการเกี่ยวกับรูปแบบนี้ จะสร้างสภาพแวดล้อม build และ runtime สำหรับโค้ดที่ย้ายแล้วโดยอัตโนมัติ จัดการการแก้ไขการพึ่งพาและการกำหนดค่า เพื่อให้แพตช์ตัวเลือกสามารถคอมไพล์และรันภายใต้เงื่อนไขที่สมจริง แทนที่จะประเมินในเชิงนามธรรม
ขั้นตอนที่สาม: การตรวจสอบการทดสอบ โค้ดที่ย้ายแล้วจะรันกับชุดทดสอบจริง หรือกับชุดทดสอบที่เทียบเท่าที่สร้างขึ้นหากไม่มีชุดทดสอบสำหรับโมดูลนั้นๆ นี่คือขั้นตอนการตรวจสอบเชิงกลไก ซึ่งสร้างผลลัพธ์ผ่านหรือไม่ผ่านที่เป็นรูปธรรม แทนที่จะเป็นความประทับใจ การทดสอบจะผ่านหรือไม่ผ่าน และไม่มีความคลุมเครือให้เอเจนต์เลี่ยงได้
ขั้นตอนที่สี่: การปรับปรุงตามข้อเสนอแนะ เมื่อล้มเหลว ข้อผิดพลาดในการทดสอบเฉพาะและบันทึกการวินิจฉัยจะถูกส่งกลับไปยังเอเจนต์การย้ายเป็นข้อมูลป้อนกลับสำหรับการแก้ไขที่ตรงจุด ไม่ใช่แค่ "สิ่งนี้ใช้ไม่ได้ ลองใหม่" เอเจนต์ที่เป็นเจ้าของแพตช์จะปรับปรุงตรรกะเฉพาะและการทำแผนที่การพึ่งพาตามหลักฐานที่เป็นรูปธรรมของสิ่งที่พัง ไม่ใช่การลองใหม่จากศูนย์แบบทั่วไป
วงจรสี่ขั้นตอนนี้ทำซ้ำต่องาน โดยมีขีดจำกัดที่กำหนดไว้ เวอร์ชันที่ใช้งานได้จริงและมีการบันทึกไว้ของรูปแบบลูปที่แน่นอนนี้ระบุเงื่อนไขการหยุด เช่น "ไม่มีไฟล์ที่ตรงกับรูปแบบเก่าอีกแล้ว" พร้อมกับจำนวนการวนซ้ำสูงสุดที่กำหนด ในตัวอย่างที่เผยแพร่ครั้งหนึ่งคือ 200 ครั้ง หลังจากนั้นระบบจะหยุดโดยอัตโนมัติ แทนที่จะทำงานต่อไปอย่างไม่มีกำหนดในงานที่ไม่ลู่เข้า
ขีดจำกัดนั้นสำคัญอย่างมากในระดับขนาดใหญ่ หากไม่มีขีดจำกัด งานที่ไม่สามารถทำให้เสร็จได้ในเชิงโครงสร้าง เนื่องจากสเปกไม่ชัดเจนหรือรูปแบบเป้าหมายไม่มีสิ่งที่เทียบเท่าที่สะอาด จะใช้ทรัพยากรไปตลอดกาล แทนที่จะปรากฏเป็นความล้มเหลวที่เฉพาะเจาะจงและมีขอบเขต ซึ่งมนุษย์สามารถดูและแก้ไขได้จริง
เหตุใดการตรวจสอบโดยมนุษย์จึงไม่สามารถปรับขนาดได้ และอะไรเข้ามาแทนที่
มันคุ้มค่าที่จะแม่นยำว่าทำไม "ไม่มีมนุษย์ตรวจสอบแต่ละรายการ" จึงเป็นการออกแบบที่ปลอดภัยกว่าที่นี่ ไม่ใช่การตัดมุม
งานวิจัยที่เปรียบเทียบการตรวจสอบโค้ดโดยเอเจนต์ AI กับการตรวจสอบโค้ดโดยมนุษย์พบสิ่งที่เฉพาะเจาะจงและมีประโยชน์: ความคิดเห็นในการตรวจสอบที่สร้างโดย AI ยาวกว่าเกือบเจ็ดเท่าต่อบรรทัดของโค้ดเมื่อเทียบกับการตรวจสอบโดยมนุษย์ และเน้นไปที่การปรับปรุงโค้ดและการตรวจจับข้อบกพร่องเกือบทั้งหมด ในขณะที่การตรวจสอบโดยมนุษย์ตามธรรมชาติจะกระจายไปยังสิ่งอื่นๆ โดยสิ้นเชิง เช่น การสร้างความเข้าใจร่วมกัน การถ่ายทอดความรู้ การสื่อสารทางสังคมระหว่างเพื่อนร่วมทีม การโต้ตอบการตรวจสอบระหว่างมนุษย์นั้นแตกต่างกันอย่างมาก ขึ้นอยู่กับประเภทของข้อเสนอแนะ การโต้ตอบการตรวจสอบระหว่าง AI กับ AI นั้นสม่ำเสมอและเป็นกลไกมากกว่า ไม่ว่าจะมีการแจ้งอะไรก็ตาม
อ่านให้ถูกต้องแล้วมันบอกอะไรบางอย่างที่สำคัญ: การตรวจสอบโดยมนุษย์และการตรวจสอบโดย AI นั้นเก่งในสิ่งที่แตกต่างกันในเชิงโครงสร้าง การขอให้มนุษย์ตรวจสอบ diff 800 รายการด้วยความเร็วและปริมาณที่ฝูงเอเจนต์ผลิตได้นั้นไม่ใช่การอัปเกรดความปลอดภัย แต่เป็นคอขวดที่สร้างการอนุมัติแบบยางประทับ เพราะไม่มีมนุษย์คนไหนที่สามารถรักษาความเข้มงวดอย่างแท้จริงในปริมาณนั้นได้ ความปลอดภัยที่แท้จริงในรูปแบบ dark factory ไม่ได้มาจากการลบการตรวจสอบ แต่มันมาจากการแทนที่การตรวจสอบประเภทหนึ่ง ซึ่งเป็นการใส่ใจของมนุษย์ที่ช้า เหนื่อยล้า และไม่สม่ำเสมอซึ่งกระจายไปทั่ว diff ซ้ำๆ หลายร้อยรายการ ด้วยการตรวจสอบอีกประเภทหนึ่งที่ปรับขนาดได้: การตรวจสอบ build และ test เชิงกำหนดที่ให้ความเข้มงวดที่แน่นอนใน diff ที่ 1 และ diff ที่ 800 โดยไม่มีความเหนื่อยล้าจากการใส่ใจ
นี่คือสาเหตุที่แน่นอนว่าทำไมขั้นตอนนักวางแผนจึงใช้การวิเคราะห์แบบสแตติกบนคอมไพเลอร์แทนการใช้ดุลยพินิจของ LLM สำหรับการจัดลำดับ ทุกที่ในระบบที่การตรวจสอบเชิงกำหนดสามารถแทนที่การตัดสินได้ ก็ควรทำ เพราะการตรวจสอบเชิงกำหนดเป็นส่วนเดียวของสถาปัตยกรรมนี้ที่สามารถตรวจสอบได้อย่างแท้จริงในภายหลัง คุณสามารถเล่นซ้ำสิ่งที่ตัววิเคราะห์แบบสแตติกพบได้อย่างแน่นอน คุณไม่สามารถเล่นซ้ำได้อย่างสมบูรณ์ว่าเหตุใดโมเดลภาษาจึง "รู้สึก" ว่าลำดับการย้ายแบบใดแบบหนึ่งถูกต้อง
สิ่งที่ยังต้องการมนุษย์ และเส้นแบ่งอยู่ที่ไหนจริงๆ
รูปแบบนี้ไม่ใช่ "กำจัดมนุษย์ทั้งหมดแล้วหวัง" ทุกเวอร์ชันที่เผยแพร่และน่าเชื่อถือของมัน ไม่ว่าจะเป็นระบบการผลิตของ Google งานวิจัย Environment-in-the-Loop ทางวิชาการ หรือคู่มือของ OpenAI ต่างก็วาดเส้นแบ่งที่ชัดเจนว่าดุลยพินิจของมนุษย์ยังคงจำเป็นอยู่ที่ไหน
ข้อค้นพบที่สอดคล้องกันจากการศึกษาเชิงปริมาณเกี่ยวกับการย้ายไลบรารีที่ขับเคลื่อนโดยเอเจนต์: เอเจนต์สามารถครอบคลุมการย้ายได้สูงอย่างน่าเชื่อถือ โดยระบุได้อย่างถูกต้องว่าต้องเปลี่ยนแปลง API ใด แต่โดยเฉพาะอย่างยิ่งมีปัญหาในการรักษาพฤติกรรมโดยรวมของแอปพลิเคชันในกรณีที่ซับซ้อนกว่า ซึ่งการย้ายที่ประสบความสำเร็จต้องอาศัยความเข้าใจในเจตนา ไม่ใช่แค่การจับคู่รูปแบบไวยากรณ์ คำแนะนำที่ตามมาโดยตรงจากข้อค้นพบนั้นคือจุดตรวจสอบแบบมนุษย์ในวงจร (human-in-the-loop checkpoint) สำหรับชุดย่อยของไฟล์ที่การตรวจสอบเชิงกำหนดระบุว่ามีความเสี่ยงสูงหรือมีความเชื่อมั่นต่ำเท่านั้น ไม่ใช่สำหรับทั้งชุด
ในทางปฏิบัติ สิ่งนี้สร้างระบบแบบแบ่งชั้น ไฟล์ที่การวิเคราะห์การพึ่งพาแบบสแตติกจัดประเภทว่ามีขนาดเล็ก แยกออกมาดี และมีโครงสร้างที่เรียบง่าย ซึ่งเป็นส่วนใหญ่ของการย้ายจริงใดๆ จะไหลผ่านลูปอัตโนมัติเต็มรูปแบบโดยไม่ต้องสัมผัสโดยมนุษย์เลย นอกเหนือจากประตู build และ test เชิงกำหนด ไฟล์ที่ถูกระบุว่าซับซ้อน เชื่อมโยงกันอย่างลึกซึ้ง หรือแตะต้องตรรกะที่สำคัญต่อธุรกิจ จะถูกส่งไปยังคิวสำหรับการตรวจสอบโดยมนุษย์จริงก่อนที่จะรวม (merge) แม้จะอยู่ในระบบอัตโนมัติเต็มรูปแบบก็ตาม
แนวทางแบบแบ่งชั้นนี้เป็นเวอร์ชันที่สมจริงของ "เอเจนต์ 800 ตัว ไม่มีมนุษย์ตรวจสอบแต่ละตัว" มันไม่ใช่ว่าไม่มีมนุษย์มองอะไรเลย มันคือระบบที่ถูกออกแบบมาโดยเฉพาะเพื่อส่งงานเชิงกลไกที่มีความเสี่ยงต่ำ 95% ผ่านระบบอัตโนมัติเต็มรูปแบบ ในขณะที่รวมทรัพยากรที่ scarce ซึ่งก็คือดุลยพินิจของมนุษย์ที่แท้จริง ไว้เฉพาะกับเศษเสี้ยวเล็กๆ ของกรณีที่มันเพิ่มมูลค่าที่การตรวจสอบเชิงกำหนดไม่สามารถทำซ้ำได้
การสร้างสิ่งนี้สำหรับโค้ดเบสของคุณเอง
รูปแบบนี้ปรับขนาดลงได้อย่างสะอาดพอๆ กับที่ปรับขนาดขึ้น บทบาททั้งสี่แบบเดียวกันนี้ใช้ได้ ไม่ว่าคุณจะรันเอเจนต์แบบขนาน 800 ตัวกับโค้ดเบสการผลิตขนาดใหญ่ หรืองานย้ายตามลำดับสองสามงานกับพื้นที่เก็บข้อมูลเดียว
เริ่มต้นด้วยนักวางแผน และต่อต้านแรงกระตุ้นที่จะทำให้มันเป็น LLM หากการย้ายของคุณมีโครงสร้างการพึ่งพาใดๆ เลย ไม่ว่าจะเป็นการนำเข้าไฟล์ อินเทอร์เฟซที่ใช้ร่วมกัน ลำดับ build ให้ใช้เครื่องมือวิเคราะห์แบบสแตติกที่เหมาะสมกับภาษาของคุณเพื่อสร้างกราฟการพึ่งพานั้นในเชิงกลไก การตัดสินใจเพียงครั้งเดียวนี้เป็นการตัดสินใจที่มีเลเวอเรจสูงที่สุดในทั้งระบบ เพราะทุกขั้นตอน downstream จะสืบทอดข้อผิดพลาดในการจัดลำดับใดๆ ที่นักวางแผนทำ
กำหนดขอบเขตงานแต่ละงานให้แคบที่สุดเท่าที่กราฟการพึ่งพาจะอนุญาต หนึ่งไฟล์ หนึ่งโมดูล หนึ่งหน่วยการเปลี่ยนแปลงที่มีขอบเขตชัดเจน พร้อมสรุปที่ชัดเจนซึ่งอธิบายว่าต้องเกิดอะไรขึ้นและเพราะเหตุใด ต่อต้านการรวมการเปลี่ยนแปลงที่ไม่เกี่ยวข้องหลายอย่างเป็นงานเดียวเพื่อประสิทธิภาพเพียงอย่างเดียว เพราะขอบเขตที่แคบคือสิ่งที่ทำให้การตัดสินผ่านหรือไม่ผ่านของขั้นตอนการตรวจสอบไม่คลุมเครือ
แยกการดำเนินการของทุกงาน อย่างน้อยที่สุดคือ git worktree ใหม่ต่องาน หรือสภาพแวดล้อมแบบแซนด์บ็อกซ์เต็มรูปแบบหากคุณรันสิ่งนี้ในระดับจริงใดๆ นี่ไม่ใช่โครงสร้างพื้นฐานเสริมที่เป็นทางเลือก มันคือสิ่งที่ทำให้การขนานปลอดภัยและทำให้ข้อผิดพลาดของเอเจนต์ตัวเดียวถูกจำกัดแทนที่จะแพร่กระจาย
สร้างการตรวจสอบเชิงกำหนดก่อนที่จะสร้างสิ่งอื่นใด ความสำเร็จในการคอมไพล์ อัตราการผ่านชุดทดสอบ การตรวจสอบความเท่าเทียมของพฤติกรรมในกรณีที่คุณสามารถสร้างมันขึ้นมาได้ นี่คือคอมโพเนนต์ที่แทนที่ "เอเจนต์บอกว่ามันใช้ได้" ด้วย "มันใช้ได้จริงหรือไม่" และมันเป็นคอมโพเนนต์เดียวที่ความพยายามย้ายที่สร้างเองในบ้านส่วนใหญ่ข้ามไปโดยสิ้นเชิง ซึ่งเป็นสาเหตุที่แท้จริงที่ความพยายามเหล่านั้นล้มเหลวในระดับที่มีความหมายใดๆ
กำหนดขีดจำกัดของลูปการลองใหม่อย่างชัดเจน ด้วยตัวเลข ไม่ใช่ความรู้สึก กำหนดว่า "งานนี้ติดขัด" มีลักษณะอย่างไรก่อนที่จะรันอะไร และส่งงานที่ติดขัดไปยังคิวของมนุษย์โดยอัตโนมัติ แทนที่จะปล่อยให้มันใช้ทรัพยากรอย่างไม่มีกำหนด หรือแย่กว่านั้นคือรายงานความสำเร็จเท็จอย่างเงียบๆ
บทเรียนที่แท้จริงเบื้องหลังตัวเลขพาดหัว
ไม่ว่าตัวเลขจริงที่รันในการย้ายขนาดใหญ่เฉพาะใดๆ จะเป็นเท่าใด ไม่ว่าจะเป็นเอเจนต์ 800 ตัว หรือ 80 ตัว หรือ 8,000 ตัว ตัวเลขพาดหัวเป็นส่วนที่น่าสนใจน้อยที่สุดของเรื่องราว ส่วนที่น่าสนใจคือไม่มีเอเจนต์เหล่านั้นสักตัวเดียวที่ได้รับความไว้วางใจเป็นรายบุคคลให้ตัดสินว่างานของตัวเองถูกต้องหรือไม่ และทั้งระบบถูกออกแบบมาโดยอาศัยความไม่ไว้วางใจนั้น ไม่ใช่ถึงแม้จะมีมัน
โรงงานมืดไม่ได้ทำงานในความมืดเพราะไม่มีใครดู มันทำงานในความมืดเพราะการดูถูกย้ายเข้าไปอยู่ในตัวเครื่องจักรทั้งหมดแล้ว ในการตรวจสอบของคอมไพเลอร์ ชุดทดสอบ และกราฟการพึ่งพาที่ให้คำตอบที่เข้มงวดเหมือนกันทุกครั้ง ในไฟล์ที่หนึ่งและไฟล์ที่แปดร้อย โดยไม่มีความเหนื่อยล้าและไม่มีความไม่สอดคล้องกันที่มาจากการขอให้มนุษย์ทำการตัดสินซ้ำๆ แบบเดิมหลายพันครั้งติดต่อกัน
นั่นคือรูปแบบที่แท้จริงเบื้องหลังทุกเวอร์ชันของสิ่งนี้ที่ทำงานในโปรดักชันอยู่ในขณะนี้ ไม่ใช่ความไว้วางใจที่กล้าหาญกว่าในโมเดลที่ใหญ่กว่า แต่เป็นการปฏิเสธที่มีวินัยมากขึ้นที่จะปล่อยให้คอมโพเนนต์ใดคอมโพเนนต์หนึ่ง ไม่ว่าจะเป็นมนุษย์หรือ AI เป็นผู้ตัดสินงานของตัวเองแต่เพียงผู้เดียว
ติดตาม @cyrilxbt สำหรับเนื้อหา AI เพิ่มเติม
