วิธีประเมินตัวแทน AI: เวลาในการทำงาน, CI/CD และอื่นๆ

การประเมินตัวแทน AI ไปไกลกว่าการตรวจสอบว่าพวกเขาให้คำตอบที่ถูกต้องหรือไม่ มันเน้นว่าการวิเคราะห์เส้นทาง การตีความเจตนาของผู้ใช้ การวางแผนขั้นตอน การใช้เครื่องมือ การตอบคำถาม และการรักษาความปลอดภัยมีความสำคัญเท่ากับผลลัพธ์สุดท้าย การประเมินที่มีประสิทธิภาพใช้เกณฑ์การประเมินที่ละเอียด ไม่ใช่แค่การจับคู่คำตอบที่ถูกต้อง และมักใช้โมเดลภาษาขนาดใหญ่อื่นๆ (LLM-as-judge) เพื่อให้คะแนนที่ละเอียดตามพฤติกรรมและการติดตามของตัวแทน

บทนำ: ช่องว่างระหว่างการสาธิตและตัวแทนที่ใช้งานจริง 

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

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

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

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

ทำไมการทดสอบตัวแทน AI ไม่เหมือนการทดสอบซอฟต์แวร์แบบดั้งเดิม 

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

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

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

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

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

โหมดความล้มเหลวของตัวแทนที่พบบ่อยที่สุด 

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

• การเรียกเครื่องมือที่หลอน: ตัวแทนสร้าง API, พารามิเตอร์, หรือชื่อเครื่องมือที่ไม่มีอยู่จริง สิ่งเหล่านี้สามารถผ่านการตรวจสอบผิวเผินได้เพราะการเรียกเครื่องมือดูถูกต้องตามหลักไวยากรณ์ แต่การดำเนินการล้มเหลว 

• วงจรที่ไม่มีที่สิ้นสุด: ตัวแทนพยายามทำซ้ำการกระทำเดิมหลังจากได้รับข้อเสนอแนะที่ไม่ชัดเจน ใช้โทเค็นและการคำนวณโดยไม่ก้าวหน้า 

• การดึงข้อมูลล้มเหลว: ตัวแทนสอบถามข้อมูลที่ไม่สมบูรณ์หรือไม่เกี่ยวข้อง จากนั้นสร้างคำตอบที่มั่นใจโดยไม่มีพื้นฐาน 

• หน่วยความจำที่ล้าสมัย: ตัวแทนพึ่งพาสถานะระหว่างกลางที่ล้าสมัยแทนที่จะเป็นข้อมูลที่ดึงมาใหม่ 

• การให้เหตุผลที่ไม่มีทางออก: ตัวแทนยึดติดกับสมมติฐานที่ผิดตั้งแต่ต้นและไม่สามารถฟื้นตัวได้ 

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

การสร้างพื้นฐาน: เมตริก, ชุดทดสอบ, และการครอบคลุม 

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

เมตริกหลักที่สำคัญ 

การประเมินตัวแทน AI ที่มีประสิทธิภาพ วัดพฤติกรรมในหลายมิติ: 

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

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

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

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

สิ่งที่ควรอยู่ในชุดทดสอบของคุณ 

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

ชุดทดสอบตัวแทนที่มีโครงสร้างดี ควรรวมถึง: 

• กระบวนการทำงานมาตรฐาน ครอบคลุมกรณีการใช้งานที่พบบ่อยที่สุดที่ตัวแทนของคุณออกแบบมาเพื่อจัดการ 

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

• กรณีขอบและอินพุตที่ไม่ชัดเจน ที่ทดสอบตรรกะการกำหนดเส้นทางและการให้เหตุผล 

• กรณีความล้มเหลวที่รู้จัก ที่ดึงมาจากเหตุการณ์ก่อนหน้าหรือการทดสอบก่อนการใช้งาน 

• คำสั่งที่เป็นปฏิปักษ์ ที่ทดสอบความปลอดภัยและช่องโหว่ในการเจลเบรก 

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

LLM-as-Judge: การขยายการประเมินโดยไม่ต้องขยายทีมของคุณ 

หนึ่งในความก้าวหน้าที่ใช้งานได้จริงที่สุดในการทดสอบตัวแทน AI ในช่วงสองปีที่ผ่านมาคือการนำ LLM-as-judge มาใช้อย่างแพร่หลายเป็นวิธีการประเมิน แนวคิดหลักนั้นง่าย: หากผู้ประเมินมนุษย์สามารถประเมินได้ว่าการตอบสนองมีประโยชน์ มีพื้นฐาน หรือหลอนหรือไม่ LLM ที่ได้รับคำแนะนำที่ถูกต้องก็สามารถทำได้เช่นกัน 

ทำไม LLM-as-Judge ถึงได้ผล 

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

เนื่องจากการประเมินต้องการการให้เหตุผลที่เปิดกว้างน้อยกว่าการสร้าง ผู้ตัดสิน LLM สามารถบรรลุความสอดคล้องและการจัดแนวกับผู้ประเมินมนุษย์ได้สูง การวิจัยที่เปรียบเทียบการตัดสินของ GPT-4 กับความชอบของมนุษย์ที่ได้รับการคราวด์ซอร์สพบว่าระดับข้อตกลงเกิน 80% ซึ่งเทียบได้กับอัตราข้อตกลงระหว่างผู้ประเมินมนุษย์เอง

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

วิธีสร้างผู้ตัดสิน LLM ที่เชื่อถือได้ 

คุณภาพของผู้ตัดสิน LLM ขึ้นอยู่เกือบทั้งหมดกับคุณภาพของคำสั่งการประเมิน นี่คือแนวทางปฏิบัติที่สร้างผลลัพธ์ที่ดีกว่าอย่างสม่ำเสมอ: 

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

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

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

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

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

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

LLM-as-Judge ในทางปฏิบัติ: สิ่งที่ควรประเมินจริงๆ 

สำหรับระบบตัวแทนโดยเฉพาะ LLM-as-judge มีค่ามากที่สุดสำหรับการประเมินสิ่งที่การตรวจสอบตามกฎไม่สามารถจับได้: 

• ความซื่อสัตย์: การตอบสนองของตัวแทนสะท้อนถึงแหล่งข้อมูลที่ดึงมาอย่างถูกต้องโดยไม่เพิ่มข้อเรียกร้องที่ไม่สนับสนุนหรือไม่? 

• การปฏิบัติตามคำแนะนำ: ตัวแทนปฏิบัติตามคำแนะนำระบบตลอดกระบวนการทำงานหรือไม่? 

• การปฏิบัติตามบริบท: การตอบสนองของตัวแทนมีพื้นฐานในบริบทที่ได้รับหรือไม่? 

• ความสอดคล้องของการให้เหตุผล: เส้นทางการให้เหตุผลของตัวแทนมีความสอดคล้องกันทางตรรกะหรือไม่? 

• คุณภาพการเลือกเครื่องมือ: ตัวแทนเลือกเครื่องมือที่ถูกต้องสำหรับแต่ละขั้นตอนหรือไม่? 

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

การประเมิน CI/CD: การจับการถดถอยก่อนที่พวกเขาจะจัดส่ง 

ท่อ CI/CD แบบดั้งเดิมถือว่าซอฟต์แวร์ที่กำหนดได้ อินพุตเดียวกันสร้างผลลัพธ์เดียวกัน การทดสอบผ่านหรือล้มเหลว การสร้างสีเขียวหมายถึงระบบที่ทำงานได้ 

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

ทำไม CI แบบดั้งเดิมจึงล้มเหลวสำหรับตัวแทน AI 

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

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

การสร้างท่อ CI ที่ขับเคลื่อนด้วยการประเมิน 

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

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

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

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

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

ทำงานอัตโนมัติด้วยเครื่องมือที่เหมาะสม API การทดลองของ Arize Phoenix ให้รูปแบบที่สะอาดสำหรับการจัดโครงสร้างการประเมิน CI: สร้างชุดข้อมูลของกรณีทดสอบ กำหนดงานที่แสดงถึงพฤติกรรมตัวแทนที่คุณกำลังทดสอบ สร้างผู้ประเมินหนึ่งคนหรือมากกว่า (รวมถึงผู้ประเมิน LLM-as-judge) รันการทดลอง และกำหนดค่าท่อให้ล้มเหลวหากคะแนนเฉลี่ยต่ำกว่าขอบเขตที่กำหนด สิ่งนี้สามารถเชื่อมต่อโดยตรงกับ GitHub Actions, GitLab CI, หรือ CI runner มาตรฐานใดๆ

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

เกตการประเมิน CI/CD ที่ดีมีลักษณะอย่างไร 

เครื่องมือการประเมิน AI ที่ดีที่สุดสำหรับท่อ CI/CD มีลักษณะหลายประการ: พวกเขาโพสต์ผลลัพธ์การประเมินโดยตรงไปยังคำขอดึงเพื่อให้นักพัฒนาเห็นการเปลี่ยนแปลงคุณภาพในบริบท พวกเขาติดตามคะแนนการประเมินข้ามการสร้างเพื่อให้การถดถอยมองเห็นได้เมื่อเวลาผ่านไป และพวกเขาแยกแยะระหว่างการเปลี่ยนแปลงที่ "แย่ลงจริง" และการเปลี่ยนแปลงที่ "แค่แตกต่าง"

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

การตรวจสอบการทำงาน: การประเมินที่ไม่เคยหลับ 

เกตการประเมิน CI/CD จับการถดถอยก่อนการใช้งาน การตรวจสอบการทำงานจับทุกอย่างที่การทดสอบก่อนการใช้งานไม่สามารถคาดการณ์ได้ 

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

ส่วนประกอบหลักของการตรวจสอบการทำงาน 

การตรวจสอบการทำงานที่มีประสิทธิภาพสำหรับตัวแทน AI ปฏิบัติตามกระบวนการที่มีโครงสร้าง: 

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

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

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

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

เมตริกที่สำคัญที่สุดในการผลิต 

การตรวจสอบการผลิต ควรติดตามชุดเมตริกที่แตกต่างจากการประเมินการพัฒนา เมตริกที่สำคัญที่สุดคือ: 

• ความซื่อสัตย์: การตอบสนองของตัวแทนมีพื้นฐานในแหล่งข้อมูลที่ดึงมาอย่างถูกต้องหรือไม่ หรือมันเพิ่มข้อเรียกร้องที่ไม่สนับสนุน? 

• ความสมบูรณ์: ตัวแทนจัดการกับทุกองค์ประกอบของงานหรือไม่? 

• ความเพียงพอ: การตอบสนองมีขอบเขตที่เหมาะสม ไม่เกินการสร้างหรือไม่ละเว้นข้อมูลสำคัญหรือไม่? 

• การลอย: การกระจายคุณภาพการตอบสนองเปลี่ยนแปลงเมื่อเวลาผ่านไปเมื่อโมเดล ข้อมูล หรือรูปแบบผู้ใช้เปลี่ยนแปลงหรือไม่? 

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

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

การเปลี่ยนข้อมูลเชิงลึกจากการทำงานเป็นการปรับปรุง 

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

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

การตรวจจับการหลอนในระดับใหญ่ 

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

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

สถาปัตยกรรมการตรวจจับแบบแบ่งระดับ 

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

ระดับ 1 (การจราจรทั้งหมด): การตรวจสอบการมีพื้นฐานและความซื่อสัตย์ สำหรับตัวแทนที่เสริมด้วยการดึงข้อมูลใดๆ ให้แบ่งการตอบสนองออกเป็นข้อเรียกร้องและตรวจสอบแต่ละข้อกับบริบทที่ดึงมา สิ่งนี้จับรูปแบบการหลอนขององค์กรที่พบบ่อยที่สุด (ตัวแทนเติมคำตอบเกินแหล่งที่มาของพวกเขา) ที่ต้นทุนต่ำ เพราะคุณมีบริบทอยู่แล้ว 

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

ระดับ 3 (เฉพาะชุดย่อยที่ถูกตั้งค่าสถานะ): LLM-as-judge ใช้ผู้ตัดสิน LLM เต็มรูปแบบเฉพาะกับการติดตามที่ถูกตั้งค่าสถานะในระดับก่อนหน้านี้ หรือกับการไหลที่มีความเสี่ยงสูงเช่นคำแนะนำทางการเงิน คำแนะนำทางกฎหมาย หรือข้อมูลทางการแพทย์ นี่คือที่ที่คุณจับการสร้างที่ละเอียดอ่อน การอ้างอิงปลอม และการเลือกเครื่องมือที่ผิดที่การตรวจสอบที่ง่ายกว่าพลาด 

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

ให้คะแนนวิถี ไม่ใช่แค่คำตอบสุดท้าย 

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

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

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

จากการทดสอบด้วยมือสู่การเพิ่มประสิทธิภาพอย่างต่อเนื่อง: โมเดลความเป็นผู้ใหญ่ในการประเมิน 

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

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

ระดับ 2: กรณีทดสอบที่มีสคริปต์ ทีมแนะนำระบบอัตโนมัติพื้นฐานผ่านสคริปต์ที่สร้างอินพุต บันทึกผลลัพธ์ และประเมินประสิทธิภาพโดยใช้กฎง่ายๆ หรือการตรวจสอบจุด 

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

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

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

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

การพิจารณาด้านการกำกับดูแล ความปลอดภัย และการปฏิบัติตามข้อกำหนด 

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

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

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

ข้อบังคับเช่น GDPR, HIPAA, และ SOX กำหนดข้อกำหนดเฉพาะในระบบ AI ที่โต้ตอบกับข้อมูลส่วนบุคคล สุขภาพ หรือการเงิน ท่อการประเมินต้องแยกข้อมูลที่ละเอียดอ่อน บังคับใช้การตรวจสอบนโยบาย และรักษาหลักฐานสำหรับการตรวจสอบ สิ่งเหล่านี้ไม่ใช่กล่องตรวจสอบการปฏิบัติตามข้อกำหนดที่เป็นทางเลือก พวกมันเป็นข้อกำหนดทางวิศวกรรมที่ควรถูกสร้างเข้ากับสถาปัตยกรรมการประเมินของคุณตั้งแต่เริ่มต้น

การรวมทุกอย่างเข้าด้วยกัน: รายการตรวจสอบการประเมินที่ใช้งานได้จริง 

ก่อนที่จะใช้งานตัวแทนการผลิตใดๆ ให้ทำงานผ่านรายการตรวจสอบนี้: 

พื้นฐานการประเมิน: 

• กำหนดเกณฑ์ความสำเร็จพร้อมเกณฑ์ที่วัดได้สำหรับความแม่นยำ ความปลอดภัย และประสิทธิภาพ 

• สร้างชุดทดสอบที่เป็นตัวแทนด้วยกระบวนการทำงานมาตรฐาน กรณีขอบ และโหมดความล้มเหลวที่รู้จัก 

• เลือกเมตริกการประเมินที่สอดคล้องกับบริบททางธุรกิจของคุณ (ไม่ใช่แค่เกณฑ์มาตรฐานทั่วไป) 

การประเมิน CI/CD: 

• เกตการประเมินที่กำหนดค่าในท่อ CI ของคุณที่ทำงานในทุกคำขอดึง 

• คำสั่ง ชุดข้อมูล และการกำหนดค่าตัวแทนภายใต้การควบคุมเวอร์ชัน 

• การตรวจสอบทางสถิติแทนการยืนยันการจับคู่ที่แน่นอน 

• กลยุทธ์การประเมินแบบแบ่งระดับที่สมดุลการครอบคลุมกับความเร็วในการสร้าง 

LLM-as-judge: 

• คำสั่งการประเมินที่เขียนและปรับเทียบกับตัวอย่างที่มีป้ายกำกับของมนุษย์ 

• ผู้ประเมินแยกต่างหากสำหรับเกณฑ์แยกต่างหาก (ความซื่อสัตย์ การปฏิบัติตามคำแนะนำ การเลือกเครื่องมือ) 

• การให้เหตุผลโซ่ของความคิดที่เปิดใช้งานในคำสั่งผู้ตัดสินสำหรับการมองเห็นการดีบัก 

• ตั้งค่าอุณหภูมิต่ำในทุกการเรียกผู้ตัดสิน 

การตรวจสอบการทำงาน: 

• การติดตามที่ติดตั้งเพื่อจับอินพุตทั้งหมด การเรียกเครื่องมือ และผลลัพธ์ 

• การประเมินตามกำหนดเวลาที่ทำงานบนการจราจรการผลิตที่สุ่มตัวอย่าง 

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

• การแจ้งเตือนที่กำหนดค่าสำหรับเมตริกที่ข้ามเกณฑ์ที่ยอมรับได้ 

การตรวจจับการหลอน: 

• การตรวจสอบการมีพื้นฐานที่ทำงานบน 100% ของการตอบสนองที่เสริมด้วยการดึงข้อมูล 

• LLM-as-judge ที่สงวนไว้สำหรับการติดตามที่ถูกตั้งค่าสถานะและการไหลที่มีความเสี่ยงสูง 

• การประเมินวิถีที่ตรวจสอบการเลือกเครื่องมือ การโต้แย้ง และการจัดการผลลัพธ์ 

• อัตราการหลอนที่ติดตามเป็นแนวโน้ม ไม่ใช่แค่การวัดจุดในเวลา 

บทสรุป: การประเมินที่เข้มงวดคือวิธีที่คุณสร้างความไว้วางใจ 

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

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

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

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

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

สร้างตัวแทน AI ที่คุ้มค่ากับความไว้วางใจ เริ่มต้นด้วยการประเมิน 

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