เลือกโมเดลด้วยหลักฐาน

กำหนดการตัดสินใจ

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

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

ใช้งานที่เป็นตัวแทนได้

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

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

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

ให้การเปรียบเทียบเป็นธรรม

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

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

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

ให้คะแนนคุณภาพก่อนความเร็ว

ตรวจเกณฑ์การยอมรับที่เป็นข้อบังคับก่อน การเปลี่ยนแปลงตรงตามข้อกำหนดหรือไม่ รักษามาตรการควบคุมการเข้าถึงหรือไม่ Test ที่เกี่ยวข้องผ่านหรือไม่ ผู้ตรวจทานเข้าใจ diff ได้หรือไม่

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

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

บันทึกการตัดสินใจและเงื่อนไขที่ต้องประเมินใหม่

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

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

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