คำถามต่อโมเดลสามข้อคั่นระหว่างผู้ช่วยเชื่อมต่อสมมติกับการแมปฟิลด์ ข้อแรกจัดประเภทคำขอ ข้อสองเลือกเครื่องมือ ข้อสามเขียนทางเลือกเดิมใหม่ให้ยาวขึ้น ลำดับนี้สร้างตอนโมเดลมักสับสนการดำเนินการสองอย่าง หลังอัปเกรดโมเดล เส้นทางเสริมอาจเพิ่มความช้าโดยไม่กันข้อผิดพลาด
วิธีรู้มีอย่างเดียวคือรันงานเดียวกันผ่านทั้งสองทาง ความคุ้นเคยไม่ใช่หลักฐานคุณค่า
บทพูดเรื่องผลิตภัณฑ์ที่เปลี่ยนตามความสามารถโมเดล เสนอว่าผลิตภัณฑ์ควรดีขึ้นเมื่อโมเดลดีขึ้น และเล่าความยากในการลบอินเทอร์เฟซคุ้นเคย บทเรียนไม่ใช่ให้ลบนั่งร้านทุกชิ้น แต่ให้ทดสอบว่ามันยังคุ้มที่อยู่ไหม
แยกตัวช่วยจากอำนาจ
ตัวช่วยเก่าอาจเป็นพรอมป์ต์ที่ทวนคำอธิบายเครื่องมือ ตัวจัดเส้นทางที่เลือกการดำเนินการเดิมเสมอ หรืออินเทอร์เฟซตายตัวสำหรับงานที่โมเดลอธิบายตามคำขอได้ชัดกว่าแล้ว หน้าที่มันคือช่วยโมเดลหรือผู้ใช้ทำงาน หากไม่ช่วยแล้ว ค่าดูแลเป็นภาระล้วน
การตรวจสิทธิ์ต่างออกไป มันตัดสินว่าการกระทำได้รับอนุญาตไหม โมเดลที่เลือกเครื่องมือเก่งมากก็ยังมอบสิทธิ์เข้าข้อมูลร้านอื่นให้ตัวเองไม่ได้ โมเดลที่เขียนอัปเดตรายชื่อสมบูรณ์แบบก็ยังต้องได้รับอนุมัติที่ถูกก่อนเขียนจริง
คำอธิบาย MCP กล่าวถึงทั้งการเข้าถึงเครื่องมือและต้นทุนความปลอดภัยของการเปิดให้ใช้ ความสามารถโมเดลอาจเปลี่ยนวิธีที่ผู้ช่วยหาเครื่องมือที่ถูก แต่ไม่ลบความจำเป็นในการจำกัดขอบเขตเครื่องมือและตรวจข้อมูลเข้า
ความต่างนี้กันความผิดพลาดทั่วไปในงานเก็บกวาด ทีมเห็นขั้นตอนเก่าเป็นชั้นเดียวแล้วเก็บทั้งหมดหรือลบทั้งหมด แยกเป็นคำถาม: ส่วนไหนช่วยโมเดลคิด ส่วนไหนช่วยผู้ใช้เข้าใจ และส่วนไหนบังคับกฎนอกโมเดล เฉพาะสองข้อแรกอาจถอดได้ตามความสามารถ
การเปรียบเทียบที่ยุติธรรมต้องใช้ข้อมูลงานเดียวกันและการกระทำที่อนุญาตเหมือนกัน หากทางสั้นได้สคีมาใหม่กว่าหรือสิทธิ์กว้างกว่า ผลดีบอกเรื่องชั้นที่ลบได้น้อย ใส่กรณีล้มเหลวที่ตัวช่วยเก่าถูกสร้างเพื่อจับ แล้วดูว่าทางใหม่จับได้ด้วยเหตุผลเดียวกันไหม มิฉะนั้นตัวอย่างปกติที่สำเร็จไม่กี่ครั้งอาจลบความทรงจำว่าทำไมตัวช่วยมีอยู่
เปรียบเทียบงานที่เสร็จทั้งงาน
เกณฑ์วัดโมเดลอย่างเดียวไม่พอ คำถามผลิตภัณฑ์คือผู้ใช้จบงานจริงโดยผิดน้อยลง ใช้เวลาน้อยลง หรือมีหลักฐานชัดขึ้นไหม
สร้างชุดสถานการณ์เล็ก: การแมปรายชื่อปกติ ฟิลด์ปลายทางไม่คุ้นเคย บัญชีที่ขาดสิทธิ์ และคำขอเปิดใช้ก่อนดูตัวอย่าง รันแต่ละกรณีทั้งมีและไม่มีชั้นช่วย ตรวจการเรียกเครื่องมือ คำอธิบาย และการตัดสินหยุด วัดเวลาและต้นทุนควบคู่ความถูกต้อง
หากทางสั้นเท่ากันในงานปกติแต่แย่กว่าในกรณีสิทธิ์ ให้คงการป้องกัน หากตัวช่วยไม่เปลี่ยนผลและเพิ่มสองวินาที ให้ลบ หากตัวช่วยสำคัญเฉพาะคำขอหายากชนิดหนึ่ง ให้จำกัดไปชนิดนั้น
ข้อโต้แย้งที่ยุติธรรมคือ “ผู้ใช้เรียนรู้อินเทอร์เฟซเก่าแล้ว การลบสร้างงานใหม่” ถูกต้อง การควบคุมที่คุ้นเคยอาจช่วยคนแม้โมเดลไม่ต้องใช้แล้ว สังเกตการเสร็จงานและความเข้าใจจริงของผู้ใช้เหล่านั้น อินเทอร์เฟซเก่าอาจอยู่ด้วยเหตุผลด้านคน แต่ควรระบุและทดสอบเหตุผล
แยกต้นทุนของวิธีแก้ขัดจากต้นทุนการเปลี่ยนมัน ตัวจัดเส้นทางอาจหน่วงเล็กน้อยแต่เก็บถูก ตัวแยกข้อความที่เขียนมือและเปราะอาจกินแรงดูแลทุกครั้งที่ผู้ให้บริการเพิ่มฟิลด์ ตารางคะแนนบันทึกเวลา อัตราผิด ภาระดูแล และความเข้าใจของผู้ใช้ ค่าเหล่านี้มาจากงานของผลิตภัณฑ์เอง ไม่ใช่ข้ออ้างทั่วไปว่าโมเดลใหม่ฉลาดกว่า
ตัวช่วยเก่ายังปกป้องอะไร?
-
บังคับสิทธิ์หรือขอบเขตข้อมูล
คงการควบคุม
ความสามารถโมเดลไม่ได้มอบอำนาจ
-
ช่วยเพียงข้อยกเว้นชนิดเดียว
จำกัดตัวช่วย
ใช้ตรงที่การทดสอบงานแสดงคุณค่า
-
ไม่เปลี่ยนผลที่ทดสอบ
เลิกใช้ตัวช่วย
ตัดความช้าและค่าดูแลที่ไม่คุ้มแล้ว
เลิกใช้โดยตั้งใจ
การเลิกใช้อย่างปลอดภัยมีค่าฐานและทางย้อน บันทึกผลของทางเก่าในสถานการณ์เดียวกัน สลับทางใหม่ให้กลุ่มจำกัดและเฝ้าความผิด เก็บพฤติกรรมเก่าไว้นานพอวิเคราะห์การถดถอย สิ่งเหล่านี้คือการตรวจผลิตภัณฑ์ธรรมดา ไม่ใช่คำสัญญาว่าความก้าวหน้าโมเดลทำให้ทุกฟีเจอร์ล้าสมัย
คู่มือ Reverse ETL ของ Tajo ให้ขอบเขตที่มีประโยชน์: การย้ายข้อมูลซ้ำควรอยู่ในไปป์ไลน์เสถียร โมเดลที่เก่งขึ้นอาจช่วยเสนอหรืออธิบายการแมป แต่ไม่ได้ทำให้เรียกโมเดลทุกระเบียนเป็นกลไกขนส่งที่ดีกว่า
ต้นทุนของวินัยนี้คือการทดสอบซ้ำเป็นช่วง ผลคือผลิตภัณฑ์ไม่แบกวิธีแก้ขัดของเมื่อวานตลอดไป
ความก้าวหน้าโมเดลควรลดงานน่าเบื่อ ไม่ใช่ลบกฎ
เก็บเหตุผลสั้น ๆ ข้างทุกชั้นที่ยังอยู่ “ขั้นนี้กันการเขียนที่ไม่มีสิทธิ์” คงทนแม้คุณภาพโมเดลดีขึ้น “ขั้นนี้ชดเชยที่โมเดลสับสนเครื่องมือสองตัว” ควรกระตุ้นให้ทดสอบใหม่เมื่อเปลี่ยนโมเดลครั้งถัดไป รายการเล็กนี้ทำให้เก็บกวาดในอนาคตเป็นการตัดสินซ้ำได้ แทนการเถียงว่ารูปแบบเก่ารู้สึกคุ้นหรือไม่
คำถามที่พบบ่อย
เมื่อใดควรถอดชั้นช่วย AI?
เมื่อการทดสอบงานปัจจุบันแสดงว่ามันไม่ช่วยผลลัพธ์มากพอจะคุ้มความช้า ต้นทุน และการดูแล เทียบงานเดียวกันทั้งแบบมีและไม่มี
การควบคุมใดควรอยู่?
การควบคุมที่บังคับสิทธิ์ ขอบเขตข้อมูล หรือการกระทำย้อนกลับยากต้องอยู่แม้โมเดลเก่งขึ้น ความสามารถไม่ได้มอบอำนาจ
การลบอินเทอร์เฟซคุ้นเคยอาจทำร้ายผู้ใช้ไหม?
ได้ ทดสอบความสำเร็จและความเข้าใจของผู้ใช้ที่พึ่งมัน โมเดลเร็วขึ้นไม่ใช่หลักฐานว่าทุกคนทำงานได้โดยไม่มีอินเทอร์เฟซเดิม