โมเดล Claude ของ Anthropic พบปัญหาทางเทคนิคในการสร้างโค้ดและความน่าเชื่อถือของเอเจนต์

Anthropic กำลังเผชิญกับความท้าทายทางเทคนิคหลายประการกับโมเดล Claude การสร้างโค้ดมีความยืดหยุ่นลดลงเนื่องจากข้อจำกัดในการฝังน้ำหมึก; กลไกการคิดแบบปรับตัวของ Sonnet 5 ทำให้โมเดลเดียวกันสามารถปรับการใช้ทรัพยากรการคำนวณได้ ทำให้ขอบเขตความสามารถของผลิตภัณฑ์คลุมเครือ; บริบท 1 ล้านแม้ดูเหมือนเพียงพอ แต่ในเซสชัน Agent ระยะยาว โมเดลสามารถใช้งานได้อย่างมีประสิทธิภาพเพียงประมาณ 20%-30% เท่านั้น ก่อนจะเกิดความสับสนและหลุดหายของสถานะ; การบีบอัดบริบททำให้ยากต่อการแยกแยะว่าข้อมูลใดยังคงใช้งานได้ สมมติฐานชั่วคราวอาจถูกตีความผิดเป็นข้อเท็จจริง; เมื่อ Agent เปลี่ยนแปลงสภาพแวดล้อมด้วยตนเอง โมเดลเริ่มวิเคราะห์ข้อผิดพลาดใหม่ที่มันสร้างขึ้นแทนที่จะแก้ไขปัญหาต้นฉบับ บทความชี้ว่าความน่าเชื่อถือของ Agent ระยะยาวขึ้นอยู่กับความชัดเจนของสถานะ ความสามารถในการตรวจสอบการกระทำ และความสามารถในการย้อนกลับข้อผิดพลาด มากกว่าประสิทธิภาพแบบก้าวเดียวของโมเดลเพียงอย่างเดียว

ผู้เขียนบทความ แหล่งที่มา: Leiphone

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

Anthropic เมื่อไม่นานมานี้มีรสชาติแบบนี้เล็กน้อย

ในช่วงไม่กี่วันที่ผ่านมา มีโพสต์หนึ่งบน X ที่รวบรวมความไม่พอใจที่พบบ่อยหลายประการเกี่ยวกับ Claude: ข้อความและโค้ดเริ่มถูกเพิ่มเครื่องหมายที่อ่านได้โดยเครื่องจักร ประสบการณ์จริงของ Sonnet 5 ไม่ทันกับเสียงตอบรับที่ตามมาจากการอัปเกรดโมเดล Fable 5 ขายในราคาที่สูงขึ้น แต่ผู้ใช้ยากจะรู้สึกได้ว่ามันแข็งแรงกว่า Opus 5 อย่างไร; นอกจากนี้ยังมีข้อเสนอแนะที่ชัดเจนยิ่งขึ้นว่า Fable 5 ใช้บริบทเพียงประมาณ 20%–30% เท่านั้น ก่อนที่ความสามารถจะเริ่มลดลง

สิ่งเหล่านี้ดูเหมือนไม่มีความเกี่ยวข้องกันในแง่ผิวเผิน อย่างหนึ่งดูเหมือนปัญหาเกี่ยวกับกลไกการสร้าง อีกอย่างดูเหมือนปัญหาความสามารถของโมเดล อีกอย่างดูเหมือนปัญหาการกำหนดราคา และอีกอย่างหนึ่งดูเหมือนมีปัญหากับบริบทยาว

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

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

01

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

เอกสารวิจัย: https://arxiv.org/pdf/2301.10226

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

รหัสมีตำแหน่งความไม่แน่นอนต่ำจำนวนมาก หลังจากประกาศตัวแปร การอ้างอิงที่ตามมาแทบจะใช้ชื่อเดียวกันเท่านั้น; ฟิลด์ JSON คำพูดและวงเล็บมีข้อจำกัดโครงสร้างที่เข้มงวด; พารามิเตอร์ฟังก์ชันต้องสอดคล้องกับอินเทอร์เฟซ; ในพาธ รีเจ็กซ์ SQL และคำสั่ง Shell การเปลี่ยนแปลง token เดียวอาจเปลี่ยนพฤติกรรมโดยตรง

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

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

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

Anthropic ไม่ได้เปิดเผยรายละเอียดว่าการเปลี่ยนแปลงการติดแท็กข้อความของ Claude ส่งผลต่อการสุ่มตัวอย่างอย่างไร ดังนั้นจึงไม่สามารถสรุปว่าการเปลี่ยนแปลงคุณภาพของ Claude Code เกิดจากอัลกอริธึมการใส่เครื่องหมายน้ำใดๆ โดยตรง

สิ่งที่สามารถระบุได้แน่นอนคือการเปลี่ยนแปลงอีกประการหนึ่ง: การสร้างรหัสกำลังรับผิดชอบต่อข้อจำกัดเพิ่มเติม越来越多 นอกเหนือจากความถูกต้องทางความหมายและการดำเนินการแล้ว มันอาจต้องปฏิบัติตามโปรโตคอลเครื่องมือ รูปแบบที่มีโครงสร้าง กฎความปลอดภัย และป้ายกำกับแหล่งที่มา ขณะที่รหัสเองมีอิสระในการรับข้อจำกัดเพิ่มเติมเหล่านี้น้อยกว่าภาษาธรรมชาติมาก

02

การเปลี่ยนแปลงที่เกิดจาก adaptive thinking ของ Sonnet 5 ไม่ได้หมายถึงแค่การให้โมเดลคิดนานขึ้น

ก่อนหน้านี้ เมื่อพูดถึง Sonnet, Opus, Fable เราอาจเข้าใจว่าเป็นจุดความสามารถที่คงที่ แต่ตอนนี้เมื่อมีการเพิ่ม effort โมเดลเดียวกันสามารถอยู่ในช่วงการคำนวณช่วงเวลาทดสอบที่ต่างกันได้ ดังนั้นรุ่นของโมเดลเองจึงไม่สามารถแสดงถึงปริมาณความสามารถที่ใช้จริงในการร้องขอได้ครบถ้วนอีกต่อไป

ลิงก์อ้างอิง: https://platform.claude.com/docs/en/build-with-claude/effort

การเปลี่ยนแปลงนี้เห็นได้ชัดเจนเป็นพิเศษใน Coding Agent เมื่อ Claude เผชิญกับบั๊ก ไม่เพียงแต่ต้องสร้างแนวทางการแก้ไข แต่ยังต้องตัดสินใจว่าจะอ่านไฟล์ใด ติดตามสายการเรียกใช้งานใด รักษาสมมติฐานทางเลือกไว้กี่ข้อ ควรรันการทดสอบหรือไม่ ควรตรวจสอบการพึ่งพาต่อหรือไม่ และเมื่อใดจึงถือว่าหลักฐานเพียงพอ

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

ลิงก์อ้างอิง: https://platform.claude.com/docs/en/build-with-claude/effort

ดังนั้น effort ไม่ได้ควบคุมแค่ความยาวของการคิด แต่ควบคุมขอบเขตการค้นหาที่อนุญาตให้กับงานของ Agent ซึ่งจะเปลี่ยนแปลงโครงสร้างแบบจำลองของ Anthropic โดยตรง

หากงานการเขียนโค้ดทั่วไปไม่ยากสำหรับ Opus แล้ว การเพิ่ม effort ต่อไป Opus มีแนวโน้มจะเข้าสู่พื้นที่ประสิทธิภาพอย่างรวดเร็ว Fable แม้จะมีโมเดลพื้นฐานที่แข็งแกร่งกว่า ก็ยังเหลือความยากที่จะแปลงเป็นความแตกต่างของประสบการณ์ไม่มากนัก

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

ลิงก์อ้างอิง: https://www.anthropic.com/news/claude-opus-5

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

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

03

การเห็นบริบท 1M ทำให้หลายคนเข้าใจว่ามันเป็นหน่วยความจำการทำงานขนาดใหญ่มาก ดังนั้นเมื่อ Claude เริ่มหลงลืม ซ้ำซ้อน หรือสับสนในสถานะเพียงเพราะใช้เพียง 200K หรือ 300K token ก็ดูเหมือนขัดกับความเข้าใจทั่วไป

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

ลิงก์อ้างอิง: https://platform.claude.com/docs/en/build-with-claude/context-windows

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

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

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

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

ลิงก์อ้างอิง: https://platform.claude.com/docs/en/build-with-claude/context-windows

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

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

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

04

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

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

ลิงก์อ้างอิง: https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

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

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

ดังนั้น ตัวชี้วัดหลักของ compaction ไม่ใช่อัตราการบีบอัด แต่คือความถูกต้องของสถานะ นี่คือเหตุผลที่ Git การทดสอบ ไฟล์งาน หน่วยความจำ และการส่งต่อแบบมีโครงสร้างมีความสำคัญมากขึ้นใน Agent ระยะยาว

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

บริบทสามารถเก็บประวัติที่หลากหลายไว้ได้ แต่ไม่สามารถรับผิดชอบการจัดการสถานะทั้งหมดในระยะยาว

ลิงก์อ้างอิง: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

05

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

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

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

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

ลิงก์อ้างอิง: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

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

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

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

บทบาทของส่วนประกอบเหล่านี้โดยพื้นฐานแล้วคือการเพิ่มความสามารถในการแก้ไขข้อผิดพลาดแบบปิดวงจรให้กับ Agent

ลิงก์อ้างอิง: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

06

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

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

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

ตัวชี้วัดเหล่านี้ไม่ได้วัดว่าการตอบสนองหนึ่งครั้งฉลาดแค่ไหน แต่วัดว่าเส้นทางหนึ่งสามารถคงความควบคุมได้หรือไม่

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

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

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