ตัวชี้วัดและวิธีการประเมินคุณภาพผลลัพธ์ของ Generative AI แบบอัตโนมัติ

เมื่อใช้งาน Generative AI ในสภาพแวดล้อมการผลิต (Production) บางครั้งอาจมีเสียงสะท้อนจากหน้างานว่า "คุณภาพของผลลัพธ์ลดลง" อย่างกะทันหัน อย่างไรก็ตาม การระบุว่าคุณภาพเริ่มลดลงตั้งแต่เมื่อใดและส่งผลกระทบในขอบเขตใดบ้างนั้นไม่ใช่เรื่องง่ายหากอาศัยเพียงการประเมินโดยมนุษย์เท่านั้น บทความนี้จะอธิบายวิธีการตรวจจับความเสื่อมถอยของผลลัพธ์อย่างต่อเนื่องโดยไม่ต้องพึ่งพาการประเมินโดยมนุษย์ ด้วยการผสมผสานตัวชี้วัดการประเมินอัตโนมัติ เช่น BLEU, ROUGE, BERTScore เข้ากับเครื่องมือตรวจสอบคุณภาพ (Quality Monitoring Tools) กลุ่มเป้าหมายของบทความนี้คือ ML Engineer, ผู้รับผิดชอบด้าน QA และ Data Scientist ที่กำลังใช้งาน Generative AI ในระดับการผลิต เราจะแนะนำตั้งแต่การเลือกตัวชี้วัดการประเมินอัตโนมัติ ขั้นตอนการติดตั้งเครื่องมือตรวจสอบ ไปจนถึงการตั้งค่าเกณฑ์การแจ้งเตือน (Alert Threshold) พร้อมตัวอย่างการใช้งานจริง เพื่อแสดงให้เห็นถึงวิธีการสร้างระบบประเมินอัตโนมัติที่ช่วยลดเวลาในการตรวจจับความเสื่อมถอยของคุณภาพลงได้อย่างมากเมื่อเทียบกับการประเมินโดยมนุษย์ หวังว่าบทความนี้จะเป็นแนวทางในการนำกลไกการประกันคุณภาพอย่างต่อเนื่องไปปรับใช้ในกระบวนการดำเนินงานขององค์กรท่าน

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

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

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

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

การประเมินด้วยระบบอัตโนมัติ (Automatic Evaluation Metrics) และการประเมินโดยมนุษย์ (Human Evaluation) ไม่ใช่สิ่งที่ใช้แทนกันได้ แต่เป็นความสัมพันธ์ที่แบ่งบทบาทหน้าที่ตามลักษณะของสิ่งที่ต้องการตรวจสอบ คะแนนอย่าง BLEU หรือ BERTScore สามารถประมวลผลข้อมูลจำนวนมหาศาลได้ภายในเวลาไม่กี่วินาที จึงเหมาะสำหรับการตรวจสอบอย่างต่อเนื่องสำหรับทุกคำขอ (Request) ในระหว่างการใช้งานจริง อย่างไรก็ตาม มีรายงานว่าการตัดสินในด้านความถูกต้องของข้อเท็จจริง ความเหมาะสมของบริบท หรือการตรวจหาเนื้อหาที่เป็นอันตรายนั้น มีหลายกรณีที่ตัวชี้วัดเชิงตัวเลขเพียงอย่างเดียวไม่สามารถตรวจพบได้ทั้งหมด

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

ในทางปฏิบัติ การดำเนินงานแบบสองขั้นตอนถือว่าสมเหตุสมผลที่สุด โดยใช้การประเมินอัตโนมัติเป็นตัวกรองขั้นแรกสำหรับทุกรายการ แล้วส่งเฉพาะผลลัพธ์ที่คะแนนต่ำกว่าเกณฑ์หรือผลลัพธ์ที่สุ่มเลือกมาบางส่วนไปให้มนุษย์ตรวจสอบ ผู้รับผิดชอบด้าน QA ควรนิยามสัดส่วนและความถี่ของการประเมินไว้ล่วงหน้า และผนวกจุดที่มนุษย์ต้องเข้ามามีส่วนร่วมตามที่ระบุไว้ใน Human-in-the-Loop (HITL) คืออะไร? พื้นฐานการออกแบบ "Human-in-the-Loop" เพื่อสร้างระบบอัตโนมัติด้วย AI ให้ยั่งยืน เข้าไปในกฎการดำเนินงาน ซึ่งประสิทธิภาพของระบบการตรวจสอบจะขึ้นอยู่กับการออกแบบนี้เป็นสำคัญ

ตัวชี้วัดคุณภาพผลลัพธ์ของ Generative AI สามารถแบ่งออกเป็น 3 กลุ่มหลัก ได้แก่ กลุ่มการวัดความสอดคล้องเชิงรูปแบบ (Surface-level matching) เช่น BLEU และ ROUGE ซึ่งเป็นการวัดความซ้ำซ้อนของคำและสำนวนด้วยวิธีทางกลไก, กลุ่มการวัดความสอดคล้องเชิงความหมาย (Semantic matching) เช่น BERTScore ซึ่งเป็นการจับความใกล้เคียงทางความหมายของประโยคในปริภูมิเวกเตอร์ (Vector space) และกลุ่มตัวชี้วัดเฉพาะทางที่ออกแบบมาสำหรับงานแต่ละประเภท เช่น การสรุปความ การแปลภาษา และการตอบคำถาม

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

BLEU, ROUGE, BERTScore มีบทบาทที่แตกต่างกันโดยขึ้นอยู่กับว่าเป็นการดูความสอดคล้องของรูปแบบภายนอกหรือความสอดคล้องทางความหมาย การเข้าใจความแตกต่างนี้จะช่วยให้เลือกตัวชี้วัดที่เหมาะสมกับงานได้อย่างถูกต้อง

BLEU เป็นตัวชี้วัดที่เสนอโดย Papineni และคณะ ในปี 2002 ซึ่งใช้วัดอัตราการตรงกันของ N-gram ระหว่างข้อความที่สร้างขึ้นกับข้อความอ้างอิง โดยเป็นมาตรฐานที่ใช้ในการประเมินการแปล และมักใช้ sacreBLEU ในการนำไปใช้งานจริงเนื่องจากให้ความสำคัญกับความสามารถในการทำซ้ำ อย่างไรก็ตาม เนื่องจากไม่ได้นับรวมการใช้คำพ้องความหมายว่าเป็นการตรงกัน จึงมีแนวโน้มที่จะให้คะแนนต่ำหากข้อความมีความหมายเหมือนกันแต่ใช้การเรียบเรียงที่ต่างกัน

ROUGE เป็นตัวชี้วัดสำหรับการประเมินการสรุปความที่ Lin นำเสนอในปี 2004 โดยวัดว่าข้อความที่สร้างขึ้นสามารถครอบคลุม N-gram ที่อยู่ในข้อความอ้างอิงได้มากน้อยเพียงใด มีรูปแบบย่อยหลายแบบ เช่น ROUGE-1, ROUGE-2 และ ROUGE-L ซึ่งถูกนำมาใช้อย่างแพร่หลายในการตรวจสอบคุณภาพของงานสรุปความ

BERTScore เป็นตัวชี้วัดที่คำนวณความคล้ายคลึงทางความหมายในระดับโทเค็นโดยใช้การฝัง (Embedding) ของ BERT ซึ่งถูกเสนอในงานวิจัยของ Zhang และคณะ จุดที่แตกต่างอย่างชัดเจนจาก BLEU และ ROUGE คือการไม่พึ่งพาความสอดคล้องของรูปแบบภายนอก ทำให้สามารถรองรับการใช้คำพ้องความหมายและการเรียบเรียงใหม่ได้

ในการตรวจสอบการทำงานจริงของ Generative AI การใช้งานที่เหมาะสมคือการใช้ ROUGE และ BLEU สำหรับงานสรุปความหรือการแปลที่มีข้อความอ้างอิงเตรียมไว้ และใช้ BERTScore ร่วมด้วยสำหรับการประเมินการโต้ตอบหรือการตอบกลับของ RAG (Retrieval-Augmented Generation) ที่ต้องการตรวจสอบความถูกต้องทางความหมายมากกว่า การไม่พึ่งพาตัวชี้วัดเพียงตัวเดียว แต่ใช้วิธีบันทึกข้อมูลหลายตัวชี้วัดเพื่อติดตามแนวโน้ม จะช่วยให้ตรวจพบการเสื่อมถอยของคุณภาพได้รวดเร็วยิ่งขึ้น

หากต้องการตรวจหาการใช้คำแทน (paraphrasing) การวัดความสอดคล้องทางความหมายด้วย Cosine Similarity จะมีประสิทธิภาพ แต่หากต้องการประเมินลำดับของคำโดยตรง ตัวชี้วัดความสอดคล้องเชิงรูปแบบ (surface-level metrics) เช่น BLEU หรือ ROUGE จะเหมาะสมกว่า ในการวัดความสอดคล้องทางความหมายนั้น จะใช้วิธีแปลงประโยคผลลัพธ์และประโยคอ้างอิงให้เป็นเวกเตอร์ด้วย Embedding จากนั้นจึงคำนวณหาค่าความใกล้เคียงของทิศทางเวกเตอร์ทั้งสองด้วย Cosine Similarity ซึ่งวิธีนี้ไม่ใช่การให้คะแนนแบบ "คำต่อคำที่ต้องตรงกันทุกประการ" แต่เป็นการประเมินว่า "แม้ถ้อยคำจะต่างกัน แต่ทิศทางของความหมายเหมือนกันหรือไม่"

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

สำหรับการนำไปใช้งานจริง การใช้โมเดล Embedding ที่รองรับหลายภาษาอย่าง Gemini Embedding 2 จะช่วยให้สามารถวัดความสอดคล้องทางความหมายของผลลัพธ์ รวมถึงงานด้านการแปลและงาน NLP หลายภาษาได้ด้วยเกณฑ์มาตรฐานเดียวกัน ทั้งนี้ การออกแบบค่าเกณฑ์ (threshold) ไม่ควรพึ่งพาตัวชี้วัดเพียงตัวเดียว แต่การใช้งานโดยผสมผสานกับตัวชี้วัดความสอดคล้องเชิงรูปแบบจะช่วยให้เกิดความสมดุลในการปฏิบัติงานจริงได้ดีกว่า

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

ในงานด้านการสรุปความ (Summarization) หัวใจสำคัญของการประเมินคือการบีบอัดเนื้อหาโดยที่ประเด็นสำคัญจากต้นฉบับยังคงอยู่ครบถ้วน แม้ ROUGE จะถูกใช้เป็นมาตรฐานในการประเมินการสรุปความเนื่องจากวัดอัตราการซ้ำกันของ N-gram แต่ก็มีจุดอ่อนคือยากที่จะตรวจจับความสอดคล้องทางความหมายที่เกิดจากการใช้คำอื่นแทน (Paraphrasing) ในทางปฏิบัติ การสรุปความที่คงประเด็นสำคัญไว้แต่เปลี่ยนรูปแบบการนำเสนอใหม่ทั้งหมดมักได้คะแนน ROUGE ต่ำ ดังนั้นการใช้ BERTScore ควบคู่กันไปเพื่อตรวจสอบว่าความหมายยังคงอยู่แม้คำศัพท์จะต่างกัน จึงเป็นแนวทางที่มีประสิทธิภาพในการทำงานจริง

ในงานด้านการแปล (Translation) ตัวชี้วัดอย่าง COMET และ BLEURT ซึ่งถูกพัฒนาขึ้นเพื่อประเมินคุณภาพของเครื่องแปลภาษา ได้รับการยอมรับในเรื่องความสัมพันธ์ที่สูงกับค่าอ้างอิง โดย COMET ซึ่งเป็นเฟรมเวิร์กการประเมินด้วยโครงข่ายประสาทเทียม (Neural Network) มีรายงานว่ามีความสัมพันธ์กับการตัดสินของมนุษย์สูงกว่า BLEU จึงเหมาะสำหรับการติดตามคุณภาพการแปลอย่างต่อเนื่อง นอกจากนี้ METEOR ยังสามารถนำมาใช้เป็นตัวชี้วัดเสริมสำหรับ BLEU ได้ เนื่องจากสามารถพิจารณาคำพ้องความหมายและการเปลี่ยนรูปของคำได้

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

การนำตัวชี้วัด (Evaluation Metrics) ไปใช้งานจริงนั้น สร้างขึ้นจากการผสมผสาน 3 องค์ประกอบ ได้แก่ ตรรกะการคำนวณ (Calculation Logic), ปลายทางการบันทึกข้อมูล (Logging Destination) และวิธีการแสดงผล (Visualization Method) โดยจะขออธิบายขั้นตอนการนำไปใช้งานตามลำดับ โดยเน้นไปที่กลไกการบันทึก Log และการเลือกใช้เครื่องมือตรวจสอบ (Monitoring Tools) เป็นหลัก

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

ในทางปฏิบัติ เราจะบันทึกผลลัพธ์การอนุมาน (Inference) คู่กับข้อความอ้างอิง (ข้อมูลเฉลยหรือสรุปอ้างอิง) แล้วคำนวณค่า BLEU, ROUGE, BERTScore ฯลฯ ด้วยการประมวลผลแบบแบตช์ (Batch Processing) เหตุผลที่เลือกใช้การประมวลผลแบบแบตช์คือ หากคำนวณแบบเรียลไทม์ ต้นทุนในการประเมินจะไปเพิ่มความหน่วง (Latency) ของการอนุมาน ทำให้การตอบสนองในการใช้งานจริงล่าช้า ในหลายสถานประกอบการจึงเลือกใช้โครงสร้างที่เก็บ Log การอนุมานไว้ในคิวหรือพื้นที่จัดเก็บข้อมูลก่อน แล้วค่อยรันงานประเมินแบบอะซิงโครนัส (Asynchronous) ทุกๆ สองสามนาทีหรือทุกชั่วโมง

ข้อมูลใน Log ควรประกอบด้วยข้อมูลพื้นฐาน ได้แก่ Prompt ที่ป้อนเข้า, ข้อความที่ได้จากโมเดล, ข้อมูลอ้างอิง, คะแนนของดัชนีชี้วัดแต่ละตัว, เวอร์ชันของโมเดล และเวลาที่บันทึก หากไม่บันทึกเวอร์ชันของโมเดลไว้ เมื่อเกิดปัญหาคุณภาพลดลงในภายหลัง จะไม่สามารถแยกแยะได้ว่าสาเหตุมาจากตัวโมเดลที่อัปเดตหรือการเปลี่ยนแปลงของข้อมูล และเนื่องจาก BERTScore ขึ้นอยู่กับโมเดลการฝังคำ (Embedding Model) จึงต้องมีการระบุเวอร์ชันของโมเดลที่ใช้ประเมินให้คงที่และบันทึกไว้ด้วยเช่นกัน

Log เหล่านี้จะถูกส่งไปยังฐานข้อมูลอนุกรมเวลา (Time-series Database) หรือแพลตฟอร์มรวบรวมเมทริกซ์ (เช่น Prometheus) เพื่อนำไปใช้ในการแสดงผลข้อมูล (Visualization) และการตรวจจับความผิดปกติผ่านเครื่องมือตรวจสอบที่จะกล่าวถึงต่อไป

หากเป้าหมายการตรวจสอบคือการตรวจจับ Drift ของคุณภาพการสร้างข้อความ (Text Generation) การใช้ OSS อย่าง Evidently หรือ NannyML จะมีความเหมาะสม แต่หากต้องการรวมเมทริกซ์เข้ากับโครงสร้างพื้นฐานของอนุกรมเวลา (Time Series) ที่มีอยู่เดิม การสร้างระบบเองด้วย Prometheus จะเหมาะสมกว่า Evidently เป็นเฟรมเวิร์กการตรวจสอบแบบโอเพนซอร์สสำหรับ ML/LLM ซึ่งสามารถสร้างระบบตรวจจับ Data Drift หรือการเปลี่ยนแปลงของการกระจายตัวของผลลัพธ์ได้ในระยะเวลาอันสั้นตามเอกสารประกอบอย่างเป็นทางการ ส่วน NannyML มีจุดแข็งในการประเมินประสิทธิภาพโดยไม่ต้องใช้ Label ซึ่งเหมาะสำหรับการตรวจจับสัญญาณเตือนล่วงหน้าของความเสื่อมถอยของคุณภาพในสภาพแวดล้อมการใช้งานจริง (Production) ที่การได้มาซึ่งข้อมูลเฉลย (Ground Truth) อาจล่าช้า

หากเน้นการดำเนินงานบนระบบคลาวด์ อาจมีตัวเลือกอย่าง Amazon SageMaker Model Monitor แต่เนื่องจากในเอกสารประกอบอย่างเป็นทางการมีหมายเหตุระบุว่าการเข้าถึงสำหรับลูกค้าใหม่จะสิ้นสุดลงในวันที่ 30 กรกฎาคม 2026 ดังนั้นเมื่อพิจารณาการนำมาใช้งานใหม่ จำเป็นต้องตรวจสอบข้อมูลล่าสุดจากเอกสารประกอบอย่างเป็นทางการก่อนตัดสินใจ

เกณฑ์ในการเลือกคือต้นทุนในการบูรณาการเข้ากับโครงสร้างพื้นฐาน MLOps ที่มีอยู่เดิม และการเชื่อมต่อกับไปป์ไลน์ที่คำนวณตัวชี้วัดที่จำเป็น (เช่น BLEU, ROUGE, BERTScore) สำหรับองค์กรที่รวบรวม System Metrics ด้วย Prometheus อยู่แล้ว การกำหนดค่าโดยการส่งออก (Export) ตัวชี้วัดการประเมินและใช้ PromQL เพื่อเฝ้าระวังค่า Threshold จะเหมาะสมกับการรวมศูนย์การดำเนินงานมากกว่า ในทางกลับกัน หากต้องการจัดการตั้งแต่การคำนวณตัวชี้วัดไปจนถึงการตรวจจับ Drift แบบเบ็ดเสร็จ การเลือกใช้เครื่องมือเฉพาะทางด้าน ML อย่าง Evidently หรือ NannyML จะช่วยลดภาระในการนำมาใช้งานได้มากกว่า

เนื่องจากค่าของดัชนีชี้วัดมีการเปลี่ยนแปลงอยู่ทุกวัน การเฝ้าระวังด้วยค่าเกณฑ์ (Threshold) แบบธรรมดาจึงมักทำให้เกิดการแจ้งเตือนที่ผิดพลาด การใช้การตรวจจับความผิดปกติทางสถิติ (Statistical Anomaly Detection) เพื่อแยกแยะระหว่างสัญญาณรบกวน (Noise) กับการเสื่อมสภาพที่เกิดขึ้นจริง รวมถึงการกำหนดหลักเกณฑ์ในการตั้งค่าเกณฑ์และกฎการดำเนินงาน จะช่วยให้สามารถรักษาทั้งความแม่นยำของการแจ้งเตือนและความรวดเร็วในการตอบสนองได้พร้อมกัน

เมื่อคะแนน BLEU หรือ BERTScore ค่อยๆ ลดลงเล็กน้อยในแต่ละสัปดาห์ เราจะแยกแยะได้อย่างไรว่าเป็นเพียงสัญญาณรบกวนชั่วคราว (temporary noise) หรือเป็นการเสื่อมถอยของโมเดลอย่างแท้จริง? ในการทำงานจริง มักพบกรณีที่เกิดความลังเลในการตัดสินใจ จนปล่อยทิ้งไว้โดยไม่สามารถสรุปได้ว่าควรแจ้งเตือนหรือควรเฝ้าดูสถานการณ์ต่อไป

การตรวจจับความผิดปกติทางสถิติ (Statistical anomaly detection) เป็นวิธีการที่เปลี่ยนการตัดสินใจจากความรู้สึกของคนมาเป็นเกณฑ์เชิงตัวเลข โดยมีวิธีที่เป็นตัวแทนหลัก 3 วิธี ดังนี้:

• แผนภูมิควบคุม (Control Chart) ที่ใช้ค่าเฉลี่ยเคลื่อนที่และส่วนเบี่ยงเบนมาตรฐาน: (พิจารณาว่าค่าที่เบี่ยงเบนไปจากค่าเฉลี่ยของ N วันที่ผ่านมาเกินกว่าจำนวนเท่าที่กำหนดของส่วนเบี่ยงเบนมาตรฐานเป็นความผิดปกติ)
• การทดสอบการเลื่อนไหล (Drift Detection): (ทดสอบว่าการกระจายตัวของข้อมูลนำเข้าหรือคะแนนผลลัพธ์แตกต่างจากข้อมูลอ้างอิงในอดีตอย่างมีนัยสำคัญทางสถิติหรือไม่)
• การเฝ้าระวังส่วนเหลือ (Residual Monitoring) ด้วยโมเดลพยากรณ์อนุกรมเวลา: (กำหนดให้จุดที่ผลต่างระหว่างค่าพยากรณ์และค่าจริงเกินเกณฑ์ที่ตั้งไว้เป็นเป้าหมายในการแจ้งเตือน)

เครื่องมืออย่าง Evidently และ NannyML มีฟังก์ชันการตรวจจับ Drift เหล่านี้เป็นมาตรฐาน ซึ่งข้อได้เปรียบในการนำไปใช้งานคือสามารถแยกการแสดงผลระหว่างการเปลี่ยนแปลงของการกระจายตัวของ Input Prompt และการเสื่อมถอยของคะแนนผลลัพธ์ได้ ตัวอย่างเช่น หากหัวข้อของฝั่ง Input เปลี่ยนไปอย่างกะทันหัน มีความเป็นไปได้สูงว่าเกิดจากการเปลี่ยนแปลงของสถานการณ์การใช้งาน ไม่ใช่การเสื่อมถอยของตัวโมเดลเอง ทำให้ความสำคัญในการแก้ไขลดลง ในทางกลับกัน หากการกระจายตัวของ Input ยังคงที่แต่ BERTScore กลับลดลงอย่างต่อเนื่อง นั่นจะเป็นหลักฐานที่บ่งชี้ว่าควรสงสัยถึงการเสื่อมถอยของโมเดลหรือ Prompt Template ดังนั้น ประเด็นสำคัญในการปฏิบัติงานเพื่อลดการแจ้งเตือนที่ผิดพลาด (false alarm) คือการไม่ตัดสินจากผลการตรวจจับเพียงอย่างเดียว แต่ต้องนำการเปลี่ยนแปลงของฝั่ง Input และ Output มาวิเคราะห์ร่วมกัน

เกณฑ์การตัดสิน: ค่าเกณฑ์ (Threshold) จะไม่ใช่ค่าคงที่ แต่จะกำหนดจากค่าเบี่ยงเบนจากเส้นฐาน (Baseline) ที่ได้จากการตรวจจับความผิดปกติทางสถิติ

การตรวจจับจุดเปลี่ยน (Change point detection) หรือคะแนนค่าผิดปกติ (Outlier score) ที่กล่าวถึงในส่วนก่อนหน้านี้ หากนำมาใช้แจ้งเตือนโดยตรงจะทำให้เกิดการแจ้งเตือนผิดพลาด (False positive) เพิ่มขึ้น การใช้โครงสร้างสองระดับถือเป็นวิธีปฏิบัติที่เหมาะสม โดยจะแจ้งเตือนเมื่อค่าเฉลี่ยของ BERTScore หรือ ROUGE ลดลงเกินค่าเบี่ยงเบนมาตรฐานจากค่าเฉลี่ยเคลื่อนที่ (Moving average) ในอดีต และจะส่งการแจ้งเตือนฉุกเฉินหากค่าลดลงเกินกว่านั้นมาก หากกำหนดเกณฑ์เพียงระดับเดียว การเปลี่ยนแปลงเพียงเล็กน้อยอาจทำให้เกิดการตอบสนองฉุกเฉิน ซึ่งนำไปสู่ภาวะล้าจากการแจ้งเตือน (Alert fatigue)

กฎการดำเนินงานควรจัดทำเป็นเอกสารโดยคำนึงถึงประเด็นต่อไปนี้:

• การแยกช่องทางการแจ้งเตือน: ระดับคำเตือน (Warning) จะส่งไปยังแชทของทีมพัฒนา ส่วนระดับฉุกเฉิน (Critical) จะแจ้งเตือนไปยังผู้รับผิดชอบด้าน QA โดยตรง
• ขั้นตอนการตรวจสอบ: เมื่อเกิดการแจ้งเตือน ให้ตรวจสอบผลลัพธ์ตัวอย่างด้วยตนเอง เพื่อแยกแยะว่าดัชนีที่ลดลงเกิดจากคุณภาพที่แย่ลงจริง หรือเป็นผลบวกลวง (False positive) จากความเอนเอียงของชุดข้อมูลที่ใช้ประเมิน
• การเรียนรู้ค่าเกณฑ์ใหม่: เมื่อมีการอัปเดตโมเดลหรือเปลี่ยน Prompt ให้คำนวณเส้นฐานใหม่และอัปเดตค่าเกณฑ์ หากลืมอัปเดต ผลลัพธ์ที่ได้รับการปรับปรุงแล้วอาจถูกตัดสินว่าแย่ลงอย่างผิดพลาด

การกำหนดกฎการแจ้งเตือนสองระดับนี้ด้วย PromQL ของ Prometheus จะช่วยให้การเปลี่ยนช่องทางการแจ้งเตือนหรือค่าเกณฑ์ทำได้เพียงแค่แก้ไขไฟล์ตั้งค่า ซึ่งช่วยลดภาระของผู้ดูแลระบบ ทั้งนี้ ค่าเกณฑ์ไม่ใช่สิ่งที่กำหนดครั้งเดียวแล้วจบ แต่ควรมีการทบทวนอย่างสม่ำเสมอเพื่อให้สอดคล้องกับสถานการณ์จริง

ทางเลือกจะขึ้นอยู่กับว่าคุณมีโครงสร้างพื้นฐาน MLOps อยู่แล้วหรือไม่ หากต้องการเพียงการตรวจจับค่าเบี่ยงเบนทางสถิติ (Statistical Drift) แบบน้ำหนักเบา ให้เลือกใช้ OSS หากต้องการความสามารถในการตรวจสอบย้อนกลับ (Traceability) ของผลลัพธ์จาก LLM และการทำงานร่วมกันภายในทีม ให้เลือกใช้แพลตฟอร์มแบบบูรณาการ (Integrated Platform) และหากต้องการให้จบครบภายในสภาพแวดล้อม AWS ให้เลือกใช้แบบ Cloud-native

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

เราได้รวบรวมคำถามที่พบบ่อยเกี่ยวกับการใช้งานตัวชี้วัดการประเมินอัตโนมัติ (Automated Evaluation Metrics) โดยแบ่งออกเป็น 3 ด้าน ได้แก่ การเลือกตัวชี้วัด การออกแบบการแจ้งเตือน (Alert Design) และการวิเคราะห์สาเหตุ โปรดใช้ข้อมูลนี้เป็นแนวทางในการตัดสินใจระหว่างการนำไปใช้งานจริง

การใช้เพียงตัวชี้วัดการประเมินอัตโนมัติ (Automatic Evaluation Metrics) เพียงอย่างเดียว จะสามารถรักษาคุณภาพของผลลัพธ์ได้จริงหรือ?

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

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

ในทางกลับกัน สำหรับสาขาที่ความผิดพลาดส่งผลกระทบสูง เช่น การแพทย์ การเงิน และกฎหมาย ขอแนะนำให้มีการสุ่มตรวจโดยมนุษย์เป็นประจำในสัดส่วนที่กำหนดโดยไม่คำนึงถึงผลจากตัวชี้วัดการประเมินอัตโนมัติ หากปัญหาเรื่องความสอดคล้องกับเอกสารอ้างอิงเกิดขึ้นในโครงสร้าง RAG (Retrieval-Augmented Generation) การพิจารณาทบทวนความแม่นยำในการสืบค้นตามที่แนะนำไว้ใน Adaptive RAG คืออะไร? วิธีสร้างสมดุลระหว่างต้นทุนและความแม่นยำด้วยการสืบค้นแบบไดนามิกที่ขับเคลื่อนด้วยคำถาม ก็เป็นสิ่งที่ควรค่าแก่การพิจารณา สิ่งสำคัญคือต้องเข้าใจว่าตัวชี้วัดการประเมินอัตโนมัติเป็นเพียงจุดเริ่มต้นของการเฝ้าระวัง และไม่สามารถทดแทนการตัดสินใจขั้นสุดท้ายของมนุษย์ได้อย่างสมบูรณ์

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

สำหรับงานที่มีประโยคอ้างอิงที่ใกล้เคียงกับคำตอบที่ถูกต้อง เช่น การสรุปความหรือการแปลภาษา ควรเริ่มจากการติดตามตัวชี้วัดที่อิงตามความสอดคล้องของคำศัพท์ (Lexical overlap) เช่น ROUGE หรือ BLEU เนื่องจากมีต้นทุนการคำนวณต่ำและสามารถบันทึกข้อมูล (Log) ได้แบบเรียลไทม์ในระดับการตอบกลับ จึงเหมาะสำหรับการใช้งานในสภาพแวดล้อมการผลิตที่มีทราฟฟิกจำนวนมาก

ในทางกลับกัน สำหรับงานที่มีความอิสระในการแสดงออกสูง เช่น แชทบอทหรือการสร้างข้อความ การใช้เพียงความสอดคล้องของคำศัพท์จะทำให้การเรียบเรียงใหม่ (Paraphrasing) ถูกประเมินค่าต่ำเกินไปอย่างไม่เป็นธรรม ในกรณีนี้ การใช้ตัวชี้วัดที่วัดความสอดคล้องเชิงความหมาย (Semantic similarity) เช่น BERTScore เป็นตัวชี้วัดหลัก และใช้ ROUGE เป็นค่าอ้างอิงเสริมถือเป็นแนวทางที่เหมาะสม

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

แนวทางในการกำหนดลำดับความสำคัญมีดังนี้:

• การสรุปความ/การแปลที่มีประโยคอ้างอิง: เริ่มจาก ROUGE/BLEU และเพิ่ม BERTScore ตามความจำเป็น
• การสร้างบทสนทนาที่มีความอิสระสูง: ใช้ BERTScore เป็นตัวชี้วัดหลัก และใช้ตัวชี้วัดความสอดคล้องของคำศัพท์เป็นตัวเสริม
• การตอบคำถามที่เน้นข้อเท็จจริง: ใช้ความสอดคล้องเชิงความหมายควบคู่ไปกับการตรวจสอบความถูกต้องของข้อมูล (Grounding check)

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

หากแนวโน้มของข้อมูลนำเข้า (Input data) เปลี่ยนแปลงไป มีความเป็นไปได้สูงว่าสาเหตุมาจาก Data Drift แต่หากตัวโมเดลเองหรือ API ที่ใช้งานอยู่มีการอัปเดต สาเหตุอาจมาจาก Model Drift ซึ่งการแยกแยะสาเหตุถือเป็นก้าวแรกของการแก้ไขปัญหา Data Drift เปรียบเสมือนปรากฏการณ์ที่ว่า "แม้จะใช้สูตรเดิมทำอาหาร แต่ถ้าแหล่งที่มาของวัตถุดิบเปลี่ยนไป รสชาติก็ย่อมเปลี่ยนตาม" ซึ่งเกิดจากการที่แนวโน้มคำถามของผู้ใช้หรือเนื้อหาของเอกสารอ้างอิงค่อยๆ เปลี่ยนไป จนทำให้ค่า BLEU หรือ BERTScore เบี่ยงเบนไปจากเกณฑ์มาตรฐาน

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

ลำดับความสำคัญในการรับมือคือการตรวจสอบความสามารถในการทำซ้ำ (Reproducibility) หากรันข้อมูลนำเข้าเดิมซ้ำแล้วคะแนนยังคงต่ำอยู่ ให้สงสัยว่ามีการเปลี่ยนแปลงที่ตัวโมเดลหรือ Prompt Template แต่หากผลลัพธ์กลับมาเสถียรเมื่อเปลี่ยนข้อมูลนำเข้า ให้สงสัยว่ามีการเปลี่ยนแปลงที่ฝั่งข้อมูล หากเป็นโครงสร้างแบบ RAG อาจมีความเป็นไปได้ที่ผลลัพธ์การค้นหาของ Vector Database เสื่อมประสิทธิภาพลง ดังนั้นการตรวจสอบความแม่นยำในการค้นหาแยกต่างหากด้วย Grounding Check จึงเป็นวิธีที่มีประสิทธิภาพ เมื่อระบุสาเหตุได้แล้ว การเริ่มแก้ไขโดยจำกัดขอบเขตผลกระทบ เช่น การ Rollback Prompt หรือการสร้างดัชนีการค้นหา (Search Index) ใหม่ จะช่วยลดเวลาในการกู้คืนระบบได้

การสร้างระบบตรวจวัดคุณภาพแบบอัตโนมัติ หากดำเนินการอย่างเป็นขั้นตอนตั้งแต่การเลือกตัวชี้วัดไปจนถึงการใช้งานระบบแจ้งเตือน จะช่วยลดความผิดพลาดได้มาก ขั้นแรกให้สำรวจประเภทงานที่มีอยู่ในปัจจุบัน (เช่น การสรุปความ การแปลภาษา การตอบคำถาม เป็นต้น) แล้วเลือกตัวชี้วัดที่เหมาะสมกับงานนั้น ๆ จำนวน 1-2 ตัวจากกลุ่ม BLEU, ROUGE, BERTScore จากนั้นให้นำสคริปต์การประเมินผลไปฝังเข้ากับ pipeline การอนุมาน (inference) และจัดเตรียมระบบที่บันทึกล็อกผลลัพธ์และคะแนนโดยอัตโนมัติ

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

ขั้นตอนสุดท้าย ให้จัดทำเอกสารกำหนดขั้นตอนการดำเนินงาน (operational rules) สำหรับรับมือเมื่อเกิดการแจ้งเตือน เช่น การฝึกโมเดลใหม่ (retraining) การปรับแก้ prompt หรือการเปลี่ยนไปใช้การตรวจสอบโดยมนุษย์ (human review) หากท่านกำลังพิจารณาการออกแบบระบบ HITL สามารถอ่านเพิ่มเติมได้จาก Human-in-the-Loop (HITL) คืออะไร? พื้นฐานการออกแบบ "แบบมีมนุษย์ร่วมในระบบ" เพื่อทำให้การใช้ AI ในการปรับปรุงกระบวนการทำงานอัตโนมัติเกิดผลอย่างยั่งยืน

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