การหมดเวลาของ API เปลี่ยนตัวแทนที่ใช้เครื่องมือให้เป็นหนี้การลองใหม่ เว้นแต่ว่างบประมาณในการลองใหม่จะชัดเจน
แบบสดๆ เธรด r/AgentixLabs ทำให้เวอร์ชันที่ใช้งานจริงของความล้มเหลวของเอเจนต์ยากที่จะเพิกเฉย การหมดเวลาของ API ไม่ใช่สัญญาณรบกวนที่หายาก เป็นสภาวะการทำงานปกติ ข้อผิดพลาดที่แท้จริงคือการปฏิบัติต่อทุกการหมดเวลาเหมือนเป็นความไม่สะดวกชั่วคราวที่โมเดลควรแก้ไข นั่นคือวิธีที่การพึ่งพาที่ไม่สม่ำเสมอครั้งหนึ่งกลายเป็นการเรียกโมเดลเพิ่มเติม การพยายามใช้เครื่องมือซ้ำๆ และเวลาที่เกิดเหตุการณ์ซึ่งไม่มีใครสามารถอธิบายได้ในภายหลัง
การหมดเวลาเป็นข้อเท็จจริงในการผลิต ไม่ใช่ข้อบกพร่องที่เกิดขึ้นทันที
เมื่อการพึ่งพาภายนอกหยุดชะงัก ทีมมักตำหนิโมเดลก่อน เนื่องจากโมเดลเป็นส่วนที่มองเห็นได้ของสแต็ก นั่นทำให้พลาดปัญหาในการทำงาน การหมดเวลาอาจมาจาก API ดาวน์สตรีม การเลื่อนการตรวจสอบสิทธิ์ ความกดดันของคิว ขีดจำกัดอัตราเฉพาะผู้เช่า หรือรูปแบบคำขอที่ไม่ถูกต้องซึ่งใช้เวลานานเกินไปก่อนที่จะล้มเหลว หากสายรัดไม่สามารถแยกกรณีเหล่านั้นออกจากกันได้ เจ้าหน้าที่จะถือว่าความล้มเหลวทุกครั้งเป็นโอกาสให้เหตุผลอีกทางหนึ่ง
นั่นคือสาเหตุที่เวิร์กโฟลว์ที่เน้นการหมดเวลามากเกินไปรู้สึกว่ามีราคาแพงกว่าที่เห็นบนกระดาษ การลองซ้ำแต่ละครั้งสามารถกระตุ้นให้เกิดการวางแผนมากขึ้น การใช้บริบทซ้ำมากขึ้น การบรรยายของเครื่องมือมากขึ้น และการตรวจสอบโดยเจ้าหน้าที่มากขึ้นก่อนที่งานจะสำเร็จหรือล้มเหลว ความล้มเหลวเริ่มต้นในเลเยอร์การขึ้นต่อกัน แต่การเรียกเก็บเงินจะเกิดขึ้นตลอดการดำเนินการทั้งหมด
การลองตรรกะอีกครั้งโดยไม่มีงบประมาณจะกลายเป็นโรงละครที่มีราคาแพง
การวนซ้ำแบบธรรมดาดูมีความรับผิดชอบในการแยกออกจากกัน ปัญหาปรากฏขึ้นเมื่อไม่มีการเปลี่ยนแปลงที่สำคัญระหว่างความพยายาม เครื่องมือเดียวกัน กลุ่มเพย์โหลดเดียวกัน การพึ่งพาเดียวกัน สถานะที่ถูกบล็อกเหมือนกัน จากมุมมองของรันไทม์ การลองอีกครั้งดูเป็นไปได้ จากมุมมองของผู้ปฏิบัติงาน ระบบจะค่อยๆ ซ้อมความล้มเหลวเดิมในขณะที่ลูกค้ารอ
การแก้ไขไม่ใช่การลองใหม่เป็นศูนย์ การแก้ไขนี้เป็นนโยบายการลองใหม่อย่างชัดเจน กำหนดว่าเมื่อใดที่การหมดเวลาสมควรได้รับความพยายามอีกครั้ง เมื่อใดที่เจ้าหน้าที่ควรลดระดับลงอย่างสวยงาม เมื่อใดที่การรันควรหยุดชั่วคราวและดำเนินการต่อในภายหลัง และเมื่อใดที่มนุษย์ควรเข้าควบคุม หากไม่มีขอบเขตดังกล่าว การหมดเวลาของเครื่องมือจะกลายเป็นหนี้การลองใหม่อย่างเงียบๆ
สิ่งที่ต้องวัดก่อนที่คุณจะเรียกเวิร์กโฟลว์ที่เชื่อถือได้
วัดอัตราการหมดเวลาตามเครื่องมือ จำนวนการลองซ้ำต่อผลลัพธ์ที่สำเร็จ เวลาแฝงทั้งหมดที่เพิ่มจากการลองใหม่ และเส้นทางที่การรันแต่ละครั้งใช้หลังจากความล้มเหลว: ลดระดับ ขยายระดับ หรือหยุด นอกจากนี้ ยังบันทึกได้เพียงพอที่จะจัดประเภทเหตุการณ์ในภายหลัง เช่น เครื่องมือใดหมดเวลา จำนวนความพยายามที่เกิดขึ้น เพย์โหลดมีการเปลี่ยนแปลงหรือไม่ และมีการใช้ตัวป้องกันค่าเดิมหรือไม่ หากคุณรู้เพียงว่าตัวแทน "ทำงาน" คุณจะไม่รู้ว่าเวิร์กโฟลว์ใช้งานได้หรือไม่
Token Robin Hood เข้ากับชั้นนั้นได้ ผลิตภัณฑ์ไม่ควรรับประกันการประหยัด ควรช่วยให้ทีมวิเคราะห์ ระบุ และเพิ่มประสิทธิภาพการใช้งานโทเค็นที่ขยายตัวก่อนที่งานจะได้รับการใช้จ่าย
การเคลื่อนไหวเชิงปฏิบัติครั้งต่อไป
เลือกเวิร์กโฟลว์การผลิตหนึ่งรายการที่มีการพึ่งพาภายนอกจริง กำหนดคลาสการหมดเวลา งบประมาณการลองใหม่ให้กับเครื่องมือแต่ละรายการ และการดำเนินการทางเลือกที่ชัดเจน จากนั้นเปรียบเทียบราคาต่องานที่สำเร็จก่อนและหลังการเปลี่ยนแปลงนโยบาย ซึ่งจะบอกคุณเกี่ยวกับความน่าเชื่อถือของตัวแทนมากกว่าการถกเถียงทั่วไปอื่นๆ ว่าแบบจำลองนั้น "ดีเพียงพอหรือไม่"