เอเจนต์ AI แทบไม่ล่ม แต่ล้มเหลวอย่างเงียบเชียบ และงานวิจัยเผยให้เห็นสาเหตุ

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

ความล้มเหลวที่ดูเหมือนความสำเร็จ

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

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

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

นี่ไม่ใช่ปัญหารูปแบบใหม่ แต่เป็นปัญหาเก่าที่ทวีความชัดเจนขึ้น ในปี 2015 วิศวกรของ Google ซึ่งนำโดย D. Sculley อธิบายถึง “หนี้ทางเทคนิคที่ซ่อนอยู่” ในระบบแมชชีนเลิร์นนิง พวกเขาโต้แย้งว่า ความเสี่ยงส่วนใหญ่ในระบบ ML ที่ใช้งานจริงไม่ได้อยู่ในโค้ดของโมเดล แต่อยู่ภายนอกนั้น ทั้งในส่วนการพึ่งพาข้อมูล การกำหนดค่า และโค้ดเชื่อมต่อ เอเจนต์เพิ่มอีกหนึ่งชั้นเข้าไปในรายการนี้ พรอมป์ตและคำอธิบายเครื่องมือถือเป็นการกำหนดค่าที่เปลี่ยนพฤติกรรมของระบบได้โดยไม่ต้องแก้ไขโค้ด

การแก้ไขเล็กน้อย ผลกระทบใหญ่หลวง

การเปลี่ยนพรอมป์ตเพียงเล็กน้อยส่งผลได้มากแค่ไหน? ในงานวิจัยที่นำเสนอในการประชุม ICLR 2024 Melanie Sclar จาก University of Washington และคณะ เปลี่ยนเพียงรูปแบบการจัดวางพรอมป์ตแบบ few-shot ได้แก่ ตัวคั่น ระยะห่าง และการใช้ตัวพิมพ์ใหญ่-เล็ก โดยความหมายยังคงเดิม ถึงกระนั้น ผลการทำงานในงานเดียวกันของ LLaMA-2-13B ก็ยังแตกต่างกันได้ถึง 76 จุดความแม่นยำ ความอ่อนไหวนี้ไม่ได้หายไปเมื่อใช้โมเดลขนาดใหญ่ขึ้น เพิ่มตัวอย่าง หรือปรับแต่งตามคำสั่ง

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

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

ความสำเร็จเพียงครั้งเดียวบอกอะไรได้น้อยมาก

งานวิจัยอีกแนวทางหนึ่งศึกษาความสม่ำเสมอ เกณฑ์มาตรฐาน τ-bench ซึ่ง Shunyu Yao และคณะจาก Sierra เผยแพร่และนำเสนอในการประชุม ICLR 2025 จำลองบทสนทนาการบริการลูกค้าที่เอเจนต์ต้องใช้เครื่องมือและปฏิบัติตามกฎทางธุรกิจ ผู้เขียนนำเสนอตัวชี้วัดที่เรียกว่า pass^k ซึ่งหมายถึงความน่าจะเป็นที่เอเจนต์จะแก้โจทย์เดียวกันได้อย่างถูกต้องในการลองทั้ง k ครั้ง

ผลการทดลองชวนให้กังวล เอเจนต์ GPT-4o แก้โจทย์ค้าปลีกได้ประมาณ 61% ในการลองครั้งเดียว แต่เมื่อต้องทำโจทย์เดิมให้สำเร็จติดต่อกันแปดครั้ง อัตราความสำเร็จลดลงเหลือประมาณ 25% การสาธิตที่ใช้งานได้เพียงครั้งเดียวบอกอะไรได้น้อยมากเกี่ยวกับพฤติกรรมของระบบเมื่อทำงานเป็นครั้งที่หนึ่งพัน

จุดที่ระบบหลายเอเจนต์เริ่มล้มเหลว

ปัจจุบันหลายทีมเชื่อมเอเจนต์หลายตัวเข้าด้วยกัน โดยให้ตัวหนึ่งวางแผน อีกตัวลงมือทำ และตัวที่สามตรวจสอบงาน งานศึกษาในปี 2025 จาก UC Berkeley เรื่อง “เหตุใดระบบโมเดลภาษาขนาดใหญ่แบบหลายเอเจนต์จึงล้มเหลว?” วิเคราะห์บันทึกลำดับการทำงานที่มีคำอธิบายประกอบมากกว่า 1,600 รายการ จากกรอบการทำงานหลายเอเจนต์ยอดนิยม 7 แบบ ผู้เขียนซึ่งมี Mert Cemri เป็นหัวหน้าทีม สร้างหมวดหมู่ข้อผิดพลาดชื่อ MAST ซึ่งประกอบด้วยรูปแบบความล้มเหลว 14 รูปแบบ แบ่งเป็น 3 กลุ่ม ได้แก่ ปัญหาด้านการออกแบบระบบ ความไม่สอดคล้องระหว่างเอเจนต์ และการตรวจสอบงาน

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

ทำให้สิ่งที่มองไม่เห็นปรากฏชัด

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

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

ผลสำรวจในอุตสาหกรรมชี้ว่า ปัจจุบันการทำเทรซเป็นเรื่องปกติแล้ว แต่การทดสอบยังตามหลังอยู่ รายงานสถานะวิศวกรรมเอเจนต์ของ LangChain สำรวจผู้ปฏิบัติงาน 1,340 คนในช่วงปลายปี 2025 คุณภาพเป็นอุปสรรคที่ผู้ตอบแบบสำรวจกล่าวถึงมากที่สุดในการนำเอเจนต์ไปใช้งานจริง โดยมีผู้ระบุประเด็นนี้ 32% องค์กร 89% รายงานว่ามีการสังเกตการณ์เอเจนต์ของตนในรูปแบบใดรูปแบบหนึ่ง และ 62% มีการทำเทรซอย่างละเอียดในแต่ละขั้นตอนและการเรียกใช้เครื่องมือ มีเพียง 52.4% ที่ประเมินผลแบบออฟไลน์ด้วยชุดข้อมูลทดสอบ และ 37.3% ที่ประเมินข้อมูลการใช้งานจริง ทีมส่วนใหญ่เห็นได้ว่าเอเจนต์ทำอะไรไปบ้าง แต่มีทีมจำนวนน้อยกว่าที่ตรวจสอบว่าการกระทำนั้นถูกต้องหรือไม่

ประเมินคำตอบในวงกว้าง

ร่องรอยแสดงให้เห็นว่าเกิดอะไรขึ้น แต่ไม่ได้บอกว่าคำตอบนั้นดีหรือไม่ การอ่านทุกบทสนทนาด้วยตนเองไม่สามารถทำได้ในวงกว้าง ทีมต่าง ๆ จึงหันมาใช้โมเดลอีกตัวเป็นผู้ประเมินมากขึ้น ซึ่งเป็นแนวทางที่เรียกว่า LLM-as-a-judge งานวิจัยที่นำเสนอในการประชุม NeurIPS ปี 2023 โดย Lianmin Zheng และคณะพบว่า โมเดลประสิทธิภาพสูงอย่าง GPT-4 ให้ผลสอดคล้องกับความพึงพอใจของมนุษย์มากกว่า 80% ของกรณี ซึ่งใกล้เคียงกับอัตราที่มนุษย์เห็นพ้องกันเอง

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

จากแนวปฏิบัติสู่นโยบาย

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

สิ่งที่ทีมทำได้ในตอนนี้

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

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

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

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