Evals: จากการทดลอง AI สู่การใช้งานจริงอย่างมั่นใจ

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

• การประเมินที่ออกแบบมาอย่างดีช่วยให้ผู้จัดการผลิตภัณฑ์ ผู้นำด้านธรรมาภิบาล AI และ CTO นำเอเจนต์ AI ไปใช้งานในวงกว้างได้อย่างปลอดภัย เปลี่ยน AI จากของเล่นที่ใช้งานแยกส่วนให้เป็นข้อได้เปรียบทางการแข่งขัน

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

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

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

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

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

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

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

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

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

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

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

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

2. พฤติกรรมของโมเดล: วิธีเรียกใช้โมเดล เช่น การสร้างคำตอบโดยเสริมด้วยการค้นคืนข้อมูล การสรุป การค้นคืนข้อมูลแบบมีโครงสร้าง และการใช้เครื่องมือ

3. เมตริก: วิธีวัดและตีความประสิทธิภาพ

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

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

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

ตัวอย่างการเลือกเมตริกที่ดี:

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

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

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

ตัวอย่างการเลือกเมตริกที่ไม่ดี:

• ใช้เพียงความยาวของคำตอบเป็นตัวแทนคุณภาพ (ยาวกว่า ≠ ดีกว่า)

• วัดความเร็วโดยไม่พิจารณาว่าต้องแลกกับความแม่นยำเพียงใด

• ติดตามคะแนนความมั่นใจของโมเดลโดยไม่ตรวจสอบเทียบกับความถูกต้องจริง

• พึ่งพาค่า perplexity ภายในของโมเดลเพียงอย่างเดียว โดยไม่ตรวจสอบกับผู้ใช้

ข้อผิดพลาดด้านเมตริกที่พบบ่อยและควรหลีกเลี่ยง:

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

• ปรับให้เข้ากับเกณฑ์มาตรฐานมากเกินไป: ทำคะแนนชุดทดสอบได้ 95% แต่ล้มเหลวเมื่อใช้งานจริง เพราะผู้ใช้จริงมีพฤติกรรมต่างออกไป

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

เมื่อใดควรใช้ LLM-as-a-judge เพื่อประเมินคุณภาพที่มีความละเอียดอ่อน

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

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

• ใช้ผลลัพธ์แบบมีโครงสร้าง (Schema JSON) สำหรับคำตอบของผู้ตัดสิน

• บันทึกทั้งคะแนนผ่าน/ไม่ผ่านและข้อความวินิจฉัยเพื่อวิเคราะห์ความล้มเหลว

• ปรับเทียบผลลัพธ์ของผู้ตัดสินกับตัวอย่างที่มนุษย์ติดป้ายกำกับในทุกรอบการเผยแพร่

• ใช้ผู้ตัดสินสองรายหรือตรวจสอบฉันทามติเป็นระยะสำหรับโดเมนที่มีความเสี่ยงสูง

• ติดตามการเปลี่ยนแปลงของผู้ตัดสินและอัตราความเห็นต่างเมื่อเวลาผ่านไป

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

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

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

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

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

นักเรียนขอให้แอปพลิเคชันช่วยแก้โจทย์ปัญหา

ตัวอย่างเกณฑ์มาตรฐานสาธารณะที่ใช้ได้: GSM8K (การให้เหตุผลทางคณิตศาสตร์ระดับประถมศึกษา)

• ชุดที่ยากกว่าและเลือกใช้ได้: MATH

เหตุผลที่เกณฑ์มาตรฐานนี้มีประโยชน์:

• เปรียบเทียบได้อย่างรวดเร็วว่าโมเดลใดให้เหตุผลทางคณิตศาสตร์ทั่วไปได้ดีกว่า

• เป็นตัวกรองแรกที่ดีก่อนลงทุนกับ evals ของผลิตภัณฑ์เต็มรูปแบบ

เหตุผลที่ยังต้องมีชุดข้อมูลของคุณเอง:

แอปของคุณมีข้อกำหนดที่ GSM8K ไม่ได้ทดสอบ ได้แก่

• ถ้อยคำและลำดับหัวข้อในหลักสูตรของคุณ

• รูปแบบการอธิบายที่เหมาะกับกลุ่มอายุของคุณ

• วิธีจัดการคำถามของนักเรียนที่กำกวมหรือมีคำผิดจำนวนมาก

• กฎตามนโยบาย เช่น เมื่อใดควรให้คำใบ้หรือให้คำตอบทั้งหมด

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

ความเชื่อมโยงระหว่างเกณฑ์มาตรฐานเฉพาะแอปพลิเคชันกับการเลือกโมเดลมีความสำคัญอย่างยิ่ง เกณฑ์มาตรฐานไม่เพียงบอกว่าโซลูชันใช้ได้หรือไม่ แต่ยังเผยให้เห็นว่าขนาดโมเดลและเทคนิคหลังการฝึกชุดใดให้ประสิทธิภาพตามต้องการด้วยต้นทุนที่คุ้มค่าที่สุด การปรับปรุงโมเดลที่ผ่านการฝึกล่วงหน้า (ตัว ‘PT’ ใน ChatGPT) อย่างทรงประสิทธิภาพที่สุดไม่ได้มาจากการฝึกใหม่ แต่มาจากวิธีการ "หลังการฝึก"

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

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

• ความสอดคล้องในตัวเอง ซึ่งสร้างผลลัพธ์หลายรายการแล้วเลือกรายการที่ดีที่สุด

• การสร้างและประสานบริบท เช่น การสร้างคำตอบโดยเสริมด้วยการค้นคืนข้อมูล (RAG) ตัวอย่างแบบ few-shot และเวิร์กโฟลว์แบบเอเจนต์

• การใช้เครื่องมือและการเข้าถึงความรู้ภายนอก ซึ่งช่วยให้โมเดลดำเนินการได้เกินขอบเขตพารามิเตอร์ภายใน

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

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

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

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

การติดตามส่วนสำคัญของระบบประกอบด้วย

• ติดตั้งเครื่องมือวัดในไปป์ไลน์เพื่อให้ได้ผลลัพธ์ที่วัดได้

• บันทึกการทดลองเพื่อให้เห็นผลของการปรับแต่งทุกครั้ง

• ใช้การเปรียบเทียบ A/B แบบง่ายก่อนเผยแพร่การเปลี่ยนแปลงครั้งใหญ่ เพื่อทดสอบว่าประสิทธิภาพอาจถดถอยหรือไม่

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

• ขั้นตอนที่ 1: คำขอของผู้ใช้เข้าสู่ระบบพร้อม request_id, user_segment, intent

• ขั้นตอนที่ 2: Trace บันทึกเวอร์ชันโมเดล เวอร์ชันพรอมต์ เอกสารที่ค้นคืน และการเรียกใช้เครื่องมือ

• ขั้นตอนที่ 3: ผู้ตัดสิน LLM ให้คะแนนคำตอบ (correctness, groundedness, policy_risk)

• ขั้นตอนที่ 4: กลไกกฎประเมินค่าเกณฑ์

• ขั้นตอนที่ 5: หากละเมิดค่าเกณฑ์ ให้ส่งการแจ้งเตือน + เปลี่ยนเส้นทางไปยังระบบสำรอง/การตรวจสอบโดยมนุษย์

• ขั้นตอนที่ 6: เพิ่มกรณีล้มเหลวลงในคิวคัดแยกปัญหา แล้วจึงเพิ่มลงในรายการงานค้างของเกณฑ์มาตรฐาน

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

เราแนะนำให้ผสานกลไกป้องกันและการติดตามตั้งแต่วันแรก

• ติดตามเมตริกและการถดถอยของโมเดลอย่างสม่ำเสมอ โดยใช้เกณฑ์มาตรฐานเฉพาะแอปพลิเคชัน

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

• ตรวจสอบว่าเมตริกการประเมินเหล่านี้สอดคล้องกับ KPI หลัก

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

• ตั้งค่าการแจ้งเตือนอัตโนมัติเมื่อเมตริกลดลง เช่น หากความแม่นยำต่ำกว่า 85% ให้เริ่มการตรวจสอบ

• คงกระบวนการตรวจสอบโดยมนุษย์ไว้สำหรับการตัดสินใจที่มีความเสี่ยงสูง เช่น คำแนะนำทางกฎหมาย คำแนะนำทางการแพทย์ และธุรกรรมทางการเงิน

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

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

• ใช้โมเดลขนาดเล็กเมื่อทำได้ โดยทดลองเบื้องต้นกับโมเดลที่มีต้นทุนต่ำกว่า และขยายขนาดเมื่อยืนยันแนวทางแล้วเท่านั้น

• แคชพรอมต์และการเรียก API

• จัดตารางงานโดยคำนึงถึงพลังงาน เช่น การประมวลผลแบบกลุ่ม spot instance และ flex priority

• ติดตามการใช้ทรัพยากรประมวลผลควบคู่กับประสิทธิภาพ

ขณะเดียวกันต้องเฝ้าติดตามกฎระเบียบ AI ที่กำลังเกิดขึ้น แม้ยังไม่มีกฎหมายเฉพาะ กรอบกฎหมายและขั้นตอนที่จำเป็นเดิมก็ยังมีผลบังคับใช้ เช่น

การคุ้มครองข้อมูล:

• ตรวจสอบว่าชุดข้อมูลเกณฑ์มาตรฐานไม่มีข้อมูลส่วนบุคคลที่ระบุตัวตนได้ (PII) หากไม่ได้รับความยินยอมอย่างเหมาะสม

• ใช้นโยบายเก็บรักษาข้อมูลกับคำถามที่บันทึกไว้

• จัดเตรียมช่องทางสำหรับคำขอลบข้อมูล

ความเท่าเทียมและอคติ:

• ทดสอบประสิทธิภาพในกลุ่มประชากรต่าง ๆ

• ให้กลุ่มที่หลากหลายมีส่วนร่วมในการสร้างเกณฑ์มาตรฐาน

สิทธิมนุษยชนและความโปร่งใส:

• จัดทำเอกสารข้อจำกัดของโมเดลให้ผู้ใช้เข้าใจอย่างชัดเจน

• อธิบายเหตุผลของการตัดสินใจที่มีความเสี่ยงสูง

• เปิดให้มนุษย์กำกับดูแลแอปพลิเคชันที่สำคัญ

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

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