คู่มือการทำ RAG Evaluation อัตโนมัติด้วย LLM-as-a-Judge
LLM-as-a-Judge คือวิธีการใช้โมเดลภาษาขนาดใหญ่ (LLM) เป็นผู้ประเมินเพื่อตรวจสอบและให้คะแนนคุณภาพของ RAG pipeline โดยอัตโนมัติ บทความนี้จะอธิบายขั้นตอนการนำไปใช้งานอย่างเป็นระบบ ตั้งแต่การออกแบบ pipeline การวัดผลด้วย RAGAS ไปจนถึงการทำระบบอัตโนมัติ เพื่อช่วยให้นักพัฒนาและวิศวกร ML สามารถสร้างฐานการประเมินที่มีความแม่นยำสูงได้อย่างรวดเร็ว
LLM-as-a-Judge คืออะไร? ความแตกต่างจากการประเมิน RAG แบบเดิม
คุณภาพของระบบ RAG ขึ้นอยู่กับ 2 ปัจจัยหลัก ได้แก่ การที่ระบบสามารถดึงเอกสารที่เหมาะสมออกมาได้หรือไม่ และคำตอบที่สร้างขึ้นมีความถูกต้องตรงตามบริบทเพียงใด LLM-as-a-Judge คือวิธีการที่มอบหมายให้โมเดลภาษาขนาดใหญ่ (Large Language Model) เป็นผู้ประเมินคุณภาพดังกล่าวโดยตรง ในเบื้องต้น เราจะมาสรุปถึงข้อจำกัดของวิธีการประเมินแบบดั้งเดิม และเหตุผลที่แนวคิดการนำ LLM มาใช้เป็นผู้ประเมินถือกำเนิดขึ้น
ข้อจำกัดของการประเมินโดยมนุษย์และแบบใช้กฎ (Rule-based)
วิธีการดั้งเดิมในการวัดคุณภาพคำตอบของ RAG แบ่งออกเป็น 2 ประเภทหลัก ได้แก่ การประเมินโดยมนุษย์ (Human Evaluation) และการประเมินแบบใช้กฎเกณฑ์ (Rule-based Evaluation) ซึ่งทั้งสองวิธีนี้มักจะประสบปัญหาเมื่อ RAG ขยายตัวไปสู่ระดับการใช้งานจริง (Production scale)
การประเมินโดยมนุษย์ คือวิธีการที่ให้คนอ่านคำตอบแล้วให้คะแนนความถูกต้องและความเป็นประโยชน์ แม้จะได้คุณภาพการตัดสินที่ดี แต่เมื่อจำนวนที่ต้องประเมินเพิ่มขึ้นเป็นหลักร้อยหรือหลักพัน จะทำให้เวลาและต้นทุนพุ่งสูงขึ้น อีกทั้งมาตรฐานยังขึ้นอยู่กับผู้ประเมินแต่ละคน การจะให้คะแนนใหม่ทั้งหมดทุกครั้งที่มีการปล่อยอัปเดตจึงไม่ใช่เรื่องที่ทำได้จริง
การประเมินแบบใช้กฎเกณฑ์ คือวิธีการที่ใช้เครื่องมือวัดความสอดคล้องของคำตอบกับประโยคเฉลยในเชิงรูปแบบ เช่น BLEU หรือ ROUGE แม้จะรวดเร็วและทำซ้ำได้ แต่ก็มักจะให้คะแนนต่ำกับคำตอบที่ถูกต้องในเชิงความหมายแต่ใช้คำต่างออกไป หรือให้คะแนนสูงกับคำตอบที่ผิดแต่มีตัวอักษรคล้ายคลึงกัน จึงไม่เหมาะกับการประเมิน RAG ที่เน้นความถูกต้องของความหมาย
กล่าวคือ การประเมินโดยมนุษย์ไม่สามารถขยายสเกลได้ และการประเมินแบบใช้กฎเกณฑ์ก็ไม่สามารถจับใจความสำคัญได้ สิ่งที่จะเข้ามาเติมเต็มช่องว่างนี้คือ LLM-as-a-Judge
ปัญหาด้านต้นทุนและสเกลที่ LLM-as-a-Judge ช่วยแก้ไข
LLM-as-a-Judge คือวิธีการที่ใช้ Large Language Model ซึ่งสามารถเข้าใจความหมายของคำตอบมาทำหน้าที่เป็นผู้ประเมิน (Judge) เพื่อทำการตัดสินโดยอัตโนมัติในปริมาณมาก ซึ่งให้ผลลัพธ์ใกล้เคียงกับการประเมินโดยมนุษย์
โดยจะส่ง "คำถาม, บริบทที่ดึงมา, และคำตอบที่สร้างขึ้น" ให้กับ LLM ที่ทำหน้าที่เป็น Judge เพื่อให้ประเมินคะแนนหรือตัดสินผ่าน/ไม่ผ่าน ตามเกณฑ์ที่กำหนดไว้ล่วงหน้า (เช่น ความถูกต้องตามบริบท, การตอบตรงคำถาม) วิธีนี้ช่วยให้สามารถประเมินข้อมูลจำนวนมากที่มนุษย์ไม่สามารถทำได้ทันในเวลาอันสั้น อีกทั้งยังช่วยลดความคลาดเคลื่อนระหว่างผู้ประเมินแต่ละคนได้ เนื่องจากเกณฑ์การประเมินถูกกำหนดไว้คงที่ผ่าน Prompt
จุดเด่นที่สำคัญคือ ต่างจากการประเมินแบบ Rule-based ตรงที่สามารถให้คะแนนได้อย่างถูกต้องแม้ว่าสำนวนภาษาจะแตกต่างกัน แต่หากความหมายถูกต้องก็ถือว่าผ่าน ในขณะเดียวกัน เนื่องจากตัว Judge เองก็เป็น LLM จึงมีจุดอ่อนเฉพาะตัว เช่น อคติ (Bias) และความไม่สม่ำเสมอในการตัดสิน ซึ่งจะกล่าวถึงในภายหลัง ด้วยเหตุนี้ การออกแบบและตรวจสอบเกณฑ์การประเมินจึงเป็นปัจจัยสำคัญที่กำหนดคุณภาพของผลลัพธ์
บทบาทของเฟรมเวิร์กหลักอย่าง RAGAS
แม้ว่าจะสามารถสร้าง LLM-as-a-Judge ขึ้นมาเองตั้งแต่ต้นได้ แต่ในทางปฏิบัติแล้วการใช้เฟรมเวิร์กสำหรับการประเมินผลเป็นสิ่งที่นิยมมากกว่า ตัวอย่างที่โดดเด่นคือ RAGAS ซึ่งรวบรวมตัวชี้วัดสำหรับการประเมินผล RAG โดยเฉพาะ พร้อมด้วยกลไกในการวัดผลผ่าน LLM-as-a-Judge มาให้ในตัว
RAGAS มาพร้อมกับตัวชี้วัดที่เหมาะสมสำหรับ RAG เช่น "ความซื่อตรง" (Faithfulness), "ความเกี่ยวข้องของคำตอบ" (Answer Relevance) และ "ความแม่นยำของบริบท" (Context Precision) เป็นมาตรฐาน โดยจะเรียกใช้ LLM สำหรับการตัดสิน (Judge LLM) ภายในเพื่อคำนวณคะแนน ซึ่งช่วยให้เริ่มต้นใช้งานได้รวดเร็วกว่าการเขียน Prompt และตรรกะการให้คะแนนด้วยตนเอง อีกทั้งยังช่วยให้คำจำกัดความของตัวชี้วัดเป็นมาตรฐานเดียวกันอีกด้วย
นอกจากนี้ยังมีไลบรารีสำหรับการประเมินผลทั่วไปอีกหลายตัว แต่ในบทความนี้จะอธิบายขั้นตอนการใช้งาน LLM-as-a-Judge โดยเน้นไปที่ RAGAS ซึ่งเป็นที่นิยมอย่างแพร่หลายในการประเมินผล RAG ทั้งนี้ ความหมายของตัวชี้วัดแต่ละตัวและวิธีการนำไปใช้เพื่อปรับปรุงความแม่นยำของ RAG ได้มีการอธิบายไว้อย่างละเอียดใน วิธีเพิ่มความแม่นยำของ RAG แล้ว ดังนั้นบทความนี้จึงจะมุ่งเน้นไปที่การทำให้การประเมินผลเป็นแบบอัตโนมัติเป็นหลัก
ข้อกำหนดเบื้องต้นที่ควรตรวจสอบก่อนสร้าง Pipeline การประเมิน
การเตรียมรากฐานให้พร้อมก่อนเริ่มรันตัวชี้วัด (Metrics) เป็นสิ่งที่กำหนดความแม่นยำและความสามารถในการทำซ้ำ (Reproducibility) ของ Evaluation Pipeline ในส่วนนี้ เราจะมาตรวจสอบ 3 ข้อกำหนดเบื้องต้น ได้แก่ การจัดระเบียบสิ่งที่ต้องการประเมิน, การเลือก Judge LLM และการเตรียม Test Set
การจัดระเบียบสถาปัตยกรรม RAG และรูปแบบเอาต์พุตที่ต้องการประเมิน
สิ่งแรกที่ต้องทำคือการกำหนดให้ชัดเจนว่าจะประเมินอะไร RAG pipeline แบ่งออกเป็น 2 ขั้นตอน คือ "การสืบค้น (Retrieval)" และ "การสร้าง (Generation)" ซึ่งตัวชี้วัดการประเมินก็จะสอดคล้องกับแต่ละขั้นตอน หากไม่ตัดสินใจให้แน่ชัดว่าจะวัดผลลัพธ์ส่วนไหน ก็จะไม่สามารถเลือกและนำตัวชี้วัดไปปรับใช้ได้
โดยเฉพาะอย่างยิ่ง เพื่อการประเมินผล คุณต้องเตรียมความพร้อมให้สามารถบันทึกข้อมูลอย่างน้อย 3 ส่วนนี้ได้ ได้แก่ คำถามของผู้ใช้, บริบท (Chunks) ที่ได้จากการสืบค้น และคำตอบที่ถูกสร้างขึ้นในท้ายที่สุด ทั้งนี้ ขึ้นอยู่กับตัวชี้วัดว่าอาจจำเป็นต้องมีคำตอบที่ถูกต้อง (Reference) เพิ่มเติมด้วย
หาก RAG ที่มีอยู่เดิมบันทึกไว้เพียงแค่คำตอบ คุณจำเป็นต้องปรับปรุงระบบให้บันทึกบริบทที่สืบค้นได้ลงในบันทึก (Log) ด้วย เพราะหากไม่มีข้อมูลบริบท ก็จะไม่สามารถคำนวณตัวชี้วัดเพื่อวัดคุณภาพการสืบค้นได้ การออกแบบการประเมินจึงเริ่มต้นจากการจัดระเบียบรูปแบบผลลัพธ์เหล่านี้
เกณฑ์การเลือก LLM สำหรับการตัดสินและข้อกำหนดในการเข้าถึง
โดยพื้นฐานแล้ว การเลือก LLM ที่จะนำมาใช้เป็น Judge ควรเลือกโมเดลที่มีความสามารถในการตัดสินใจเทียบเท่าหรือเหนือกว่าโมเดลที่สร้างคำตอบที่ต้องการประเมิน หากใช้โมเดลที่มีความสามารถในการตัดสินใจต่ำมาเป็น Judge จะทำให้ผลการประเมินนั้นไม่น่าเชื่อถือ โดยมีโมเดลระดับแนวหน้า (Frontier Models) อย่าง GPT, Claude และ Gemini เป็นตัวเลือกที่เหมาะสม
ในการคัดเลือก ให้ตรวจสอบ 3 ประเด็นดังนี้: ประการแรก คือมี Context Length ที่เพียงพอต่อการจัดการกับบริบทที่ยาว (เช่น การส่งคำถาม บริบทที่ดึงมา และคำตอบรวมกัน) หรือไม่ ประการที่สอง คือสามารถส่งออกผลลัพธ์ในรูปแบบโครงสร้างอย่างคะแนนหรือ JSON เพื่อให้การประเมินมีความเสถียรหรือไม่ และประการที่สาม คือสามารถรองรับอัตรา API Rate และต้นทุนที่สอดคล้องกับจำนวนการประเมินได้หรือไม่
หากมีการนำข้อมูลภายในบริษัทมาใช้ในการประเมิน จำเป็นต้องระมัดระวังเรื่องการจัดการข้อมูลด้วย หากเป็นข้อมูลที่มีความลับสูง ควรพิจารณาทางเลือกในการใช้ Local LLM ที่ทำงานบน On-premise หรือสภาพแวดล้อมส่วนตัวแทนการใช้ API ภายนอก
วิธีการเตรียมชุดทดสอบ (Golden Dataset)
ความน่าเชื่อถือของการประเมินผลขึ้นอยู่กับคุณภาพของชุดทดสอบ (Golden Dataset) เป็นสำคัญ ซึ่งก็คือข้อมูลสำหรับการประเมินที่รวบรวม "คำถามที่คาดว่าจะได้รับ" รวมถึง "คำตอบที่คาดหวังหรือบริบทที่เป็นหลักฐานอ้างอิง" (หากจำเป็น) ไว้ด้วยกัน
เงื่อนไขของชุดทดสอบที่ดีมี 3 ประการ ได้แก่ ต้องสะท้อนการกระจายตัวของคำถามที่ผู้ใช้จริงส่งเข้ามา, ต้องไม่เพียงแค่มีคำถามง่ายๆ แต่ต้องรวมถึงคำถามที่กำกวม คำถามเชิงซ้อน และคำถามที่ท้าทาย และต้องมีการอัปเดตอย่างต่อเนื่องจากข้อมูลจริง หากสร้างขึ้นจากเพียงคำถามที่นักพัฒนาคิดขึ้นมาเอง จะไม่สามารถตรวจจับความผิดพลาดที่เกิดขึ้นจริงในการใช้งานได้
แม้จำนวนข้อมูลที่มากจะช่วยให้ผลลัพธ์มีความเสถียรมากขึ้น แต่ในทางปฏิบัติควรเริ่มจากหลักสิบถึงหลักร้อยรายการที่ครอบคลุมกรณีการใช้งาน (Use Case) ที่เป็นตัวแทนได้ แล้วจึงค่อยๆ เพิ่มตัวอย่างความผิดพลาดที่พบจากการใช้งานจริงเข้าไปอย่างต่อเนื่อง ทั้งนี้ หากวิธีการสร้างชุดทดสอบผิดพลาด ผลลัพธ์การประเมินจะขาดความน่าเชื่อถือ ซึ่งความผิดพลาดทั่วไปเหล่านั้นจะถูกกล่าวถึงโดยละเอียดในส่วนถัดไป
ควรใช้ตัวชี้วัดใด? วิธีเลือกตัวชี้วัดที่เหมาะสมสำหรับ RAG
มีตัวชี้วัดมากมายสำหรับการประเมิน RAG แต่การวัดผลทั้งหมดโดยไม่มีเป้าหมายจะทำให้ยากต่อการตีความ ในที่นี้ เราจะมาดูตัวชี้วัดหลักที่ใช้การตัดสินโดย Judge (ผู้ประเมิน), ความสัมพันธ์กับ RAGAS และวิธีการกำหนดลำดับความสำคัญตามกรณีการใช้งาน (Use Case) ตามลำดับ
ตัวชี้วัดหลักที่ LLM Judge ใช้ให้คะแนนและมุมมองในการตัดสิน
ในการประเมิน RAG ด้วย LLM-as-a-Judge มีตัวชี้วัดหลัก 3 ประการ ซึ่งแต่ละตัวมีมุมมองในการตัดสินที่แตกต่างกันว่า "จดจ้องดูอะไรในการให้คะแนน"
ความซื่อตรง (Faithfulness): คำตอบที่สร้างขึ้นได้รับการสนับสนุนจากบริบทที่ดึงมาหรือไม่ จอจจะตรวจสอบว่าแต่ละข้อความในคำตอบสามารถอนุมานได้จากบริบทหรือไม่ หากคำตอบมีการกล่าวถึงข้อมูลที่ไม่มีอยู่ในบริบท (= ฮัลซิเนชัน) จอจจะให้คะแนนต่ำ
ความเกี่ยวข้องของคำตอบ (Answer Relevancy): คำตอบตอบตรงตามเจตนาของคำถามหรือไม่ จอจจะหักคะแนนคำตอบที่แม้จะถูกต้องแต่ไม่ตรงประเด็น หรือคำตอบที่เยิ่นเย้อจนใจความสำคัญไม่ชัดเจน
ความแม่นยำของบริบท (Context Precision): ในบรรดาบริบทที่ดึงมาจากการค้นหา มีข้อมูลที่จำเป็นต่อการตอบคำถามอยู่มากน้อยเพียงใด นี่เป็นตัวชี้วัดคุณภาพในขั้นตอนการค้นหา ไม่ใช่ขั้นตอนการสร้างคำตอบ
ความซื่อตรงและความเกี่ยวข้องของคำตอบใช้ดูคุณภาพของการสร้างคำตอบ ส่วนความแม่นยำของบริบทใช้ดูคุณภาพของการค้นหา การแยกวัดตัวชี้วัดเหล่านี้มีคุณค่าตรงที่ทำให้สามารถระบุได้ว่าปัญหาเกิดขึ้นในขั้นตอนใด
การจับคู่เมตริกของ RAGAS เข้ากับการให้คะแนนโดย LLM Judge
ตัวชี้วัดในหัวข้อก่อนหน้านี้ถูกนำมาใช้เป็นเมทริกซ์มาตรฐานใน RAGAS ซึ่งจะถูกคำนวณโดยอัตโนมัติผ่านการเรียกใช้ LLM-as-a-Judge ภายใน โดยค่าความซื่อตรง (Faithfulness) จะสอดคล้องกับ faithfulness, ความเกี่ยวข้องของคำตอบ (Answer Relevancy) สอดคล้องกับ answer relevancy และคุณภาพของการสืบค้น (Retrieval Quality) สอดคล้องกับ context precision / context recall
หากคุณต้องการพัฒนา LLM-as-a-Judge ด้วยตนเอง การทำความเข้าใจความสัมพันธ์เหล่านี้จะเป็นแนวทางในการออกแบบตัวชี้วัด หากใช้ RAGAS ให้ตรวจสอบว่าแต่ละเมทริกซ์ต้องการข้อมูลใดบ้าง (คำถาม, บริบท, คำตอบ, หรือคำตอบที่ถูกต้อง) และเตรียมชุดทดสอบ (Test Set) ให้มีข้อมูลครบถ้วนตามที่ต้องการ
สำหรับความหมายของตัวเลขในแต่ละเมทริกซ์ และวิธีการนำคะแนนที่ต่ำไปปรับปรุง RAG (เช่น การทำ Reranking หรือ Hybrid Search) ได้มีการอธิบายไว้อย่างเป็นระบบใน วิธีเพิ่มความแม่นยำของ RAG: การลดอาการหลอน (Hallucination) และ Hybrid Search โดยในบทความนี้ เราจะมุ่งเน้นไปที่ "วิธีการให้คะแนนอัตโนมัติด้วย Judge และการนำไปใช้งานจริง"
วิธีการจัดลำดับความสำคัญของตัวชี้วัดตามกรณีการใช้งาน
ไม่จำเป็นต้องให้ความสำคัญกับทุกตัวชี้วัดเท่ากันหมด ตัวชี้วัดที่ควรให้ความสำคัญเป็นอันดับแรกจะเปลี่ยนไปตามวัตถุประสงค์การใช้งานของ RAG
ในกรณีที่ความถูกต้องแม่นยำมีความสำคัญอย่างยิ่งยวด เช่น กฎระเบียบภายในบริษัท, ข้อกฎหมาย, การแพทย์ หรือการเงิน ให้ความสำคัญกับความซื่อตรง (Faithfulness) เป็นอันดับแรก เพราะการตอบข้อมูลที่ไม่อยู่ในบริบท (Hallucination) ถือเป็นความเสี่ยงสูงสุด ในทางกลับกัน สำหรับการใช้งานที่ความเข้าใจง่ายของคำตอบส่งผลดี เช่น ฝ่ายบริการลูกค้าหรือแผนกช่วยเหลือภายในองค์กร ให้เพิ่มน้ำหนักของความเกี่ยวข้องของคำตอบ (Answer Relevance) แทน
สำหรับฐานความรู้ที่มีเอกสารที่ใช้ค้นหาจำนวนมากและมีโอกาสเกิดสัญญาณรบกวน (Noise) ได้ง่าย ให้ตรวจสอบอัตราความเหมาะสมของบริบท (Context Precision) เพื่อติดตามคุณภาพในขั้นตอนการค้นหาอย่างต่อเนื่อง
เมื่อกำหนดลำดับความสำคัญได้แล้ว ให้นำไปสะท้อนในเกณฑ์การผ่าน/ไม่ผ่าน (Threshold) ตัวอย่างเช่น การกำหนดว่า "หากความซื่อตรงต่ำกว่าเกณฑ์มาตรฐานให้ถือว่าไม่ผ่าน" ซึ่งการปรับเกณฑ์ตามตัวชี้วัดให้เหมาะสมกับความเสี่ยงของการใช้งานแต่ละประเภทเป็นวิธีที่ใช้ได้จริงในทางปฏิบัติ หากต้องการให้ทุกอย่างอยู่ในระดับสูงทั้งหมด จะทำให้จุดเน้นในการปรับปรุงไม่ชัดเจน
ขั้นตอนที่ 1-4: ขั้นตอนการติดตั้งใช้งาน Pipeline การประเมินแบบ LLM-as-a-Judge
ต่อไปนี้คือขั้นตอน 4 ขั้นตอนในการนำ RAGAS มาใช้เพื่อสร้างไปป์ไลน์การประเมินผลแบบ LLM-as-a-Judge โดยจะเริ่มตั้งแต่การตั้งค่าสภาพแวดล้อม การออกแบบ Judge Prompt ไปจนถึงการรวมผลคะแนนและการแสดงผลตามลำดับ
ขั้นตอนที่ 1-2: การตั้งค่า RAGAS และการกำหนดรูปแบบข้อมูลนำเข้าสำหรับการประเมิน
ขั้นแรก ให้เตรียมสภาพแวดล้อมสำหรับการประเมิน โดยเตรียม RAGAS และไคลเอนต์ของ LLM ที่ใช้สำหรับตัดสิน (SDK ของโมเดลที่ใช้งาน) ไว้ในสภาพแวดล้อม Python
จากนั้น ให้เตรียมข้อมูลสำหรับการประเมินให้อยู่ในรูปแบบที่ RAGAS สามารถรับได้ โดยองค์ประกอบพื้นฐานจะมี 4 ส่วน ได้แก่ คำถาม, บริบทที่ดึงข้อมูลมาได้, คำตอบที่สร้างขึ้น และ (ถ้าจำเป็น) คำตอบที่ถูกต้อง ใน RAGAS ข้อมูลเหล่านี้จะถูกส่งผ่านในรูปแบบของชุดข้อมูล (Dataset) ที่มีคอลัมน์ดังกล่าว
python
1from datasets import Dataset
2
3data = {
4 "question": ["จำนวนวันลาพักร้อนที่ได้รับตามระเบียบข้อบังคับในการทำงานคือเท่าไร?"],
5 "contexts": [["ได้รับ 10 วันหลังจากทำงานครบ 6 เดือน..."]],
6 "answer": ["ได้รับ 10 วันหลังจากทำงานครบ 6 เดือน"],
7 "ground_truth": ["ได้รับ 10 วันเมื่อทำงานต่อเนื่องครบ 6 เดือน"],
8}
9dataset = Dataset.from_dict(data)สิ่งที่สำคัญในขั้นตอนนี้คือ การใส่ "บริบทที่ดึงมาได้จากการค้นหาจริง" ลงใน contexts หากไม่ส่งผลลัพธ์การค้นหาที่เหมือนกับที่ใช้ในระบบจริงแทนที่จะเป็นบริบทในอุดมคติ ก็จะไม่สามารถประเมินรวมถึงคุณภาพของการค้นหาได้ เมื่อกำหนดรูปแบบข้อมูลนำเข้าเรียบร้อยแล้ว ขั้นตอนถัดไปคือการออกแบบเนื้อหาสำหรับการตัดสิน (Judge)
ขั้นตอนที่ 3: การออกแบบ Prompt สำหรับ Judge และการติดตั้งตรรกะการให้คะแนน
คุณภาพของ LLM-as-a-Judge ขึ้นอยู่กับการออกแบบ Prompt ที่ส่งให้ Judge เป็นหลัก หากใช้เมตริกมาตรฐานของ RAGAS คุณสามารถใช้ Prompt ภายในที่ระบบเตรียมไว้ให้ได้ แต่หากต้องการให้คะแนนตามเกณฑ์เฉพาะของตนเอง คุณจำเป็นต้องออกแบบ Judge Prompt ขึ้นมาเอง
หัวใจสำคัญของการออกแบบมี 3 ประการ ประการแรก คือการเขียนเกณฑ์การให้คะแนนด้วยมุมมองที่เฉพาะเจาะจงแทนการใช้คำคุณศัพท์ที่คลุมเครือ เช่น แทนที่จะถามว่า "เป็นคำตอบที่ดีหรือไม่" ให้ถามว่า "ข้อกล่าวอ้างแต่ละข้อในคำตอบได้รับการสนับสนุนจากบริบทหรือไม่" ประการที่สอง คือการกำหนดรูปแบบผลลัพธ์ให้เป็นรูปแบบที่มีโครงสร้าง เช่น คะแนน หรือ JSON เพื่อให้สามารถนำไปประมวลผลต่อด้วยเครื่องมือได้โดยอัตโนมัติ ประการที่สาม คือการให้ LLM แสดงเหตุผลประกอบการตัดสินใจมาด้วย เพื่อให้สามารถตรวจสอบสาเหตุของคะแนนที่ต่ำได้ในภายหลัง
text
1คุณคือผู้ประเมินที่เข้มงวด โปรดตัดสินว่าคำตอบต่อไปนี้อ้างอิงจากบริบทที่กำหนดให้เพียงอย่างเดียวหรือไม่
2หากมีข้อมูลที่ไม่ได้อยู่ในบริบท ให้ถือว่า faithful=false
3ผลลัพธ์ต้องอยู่ในรูปแบบ JSON เท่านั้น เช่น {"faithful": true/false, "reason": "..."}การเลือกว่าจะให้คะแนนเป็นระดับ 1-5 หรือเป็นแบบผ่าน/ไม่ผ่าน (Binary) ขึ้นอยู่กับวัตถุประสงค์การใช้งาน การให้คะแนนเป็นระดับช่วยให้ติดตามแนวโน้มได้ง่ายขึ้น ในขณะที่แบบผ่าน/ไม่ผ่านช่วยให้การตัดสินผลลัพธ์เป็นไปโดยอัตโนมัติได้ง่ายกว่า
ขั้นตอนที่ 4: การทำระบบสรุปคะแนนและรายงานผลอัตโนมัติ
เมื่อได้คะแนนรายบุคคลแล้ว ให้รวบรวมผลลัพธ์จากชุดทดสอบ (test set) ทั้งหมดเพื่อจัดทำเป็นรายงานที่มนุษย์สามารถอ่านและตัดสินใจได้ ใน RAGAS เมื่อเรียกใช้ฟังก์ชัน evaluate คุณจะสามารถคำนวณคะแนนของแต่ละเมทริกซ์สำหรับชุดข้อมูลทั้งหมดได้พร้อมกัน
python
1from ragas import evaluate
2from ragas.metrics import faithfulness, answer_relevancy, context_precision
3
4result = evaluate(
5 dataset,
6 metrics=[faithfulness, answer_relevancy, context_precision],
7)
8print(result)ผลลัพธ์ที่รวบรวมได้ไม่ควรมีเพียงแค่คะแนนเฉลี่ยของแต่ละดัชนีชี้วัดเท่านั้น แต่ควรจัดเตรียมให้สามารถดึงข้อมูลรายกรณีที่ได้คะแนนต่ำออกมาได้ด้วย เพราะการดูเพียงค่าเฉลี่ยอย่างเดียวจะไม่ทำให้ทราบว่าล้มเหลวที่คำถามใดหรือเพราะเหตุใด
รายงานที่ประกอบด้วยค่าเฉลี่ยของแต่ละดัชนี การเปรียบเทียบกับเกณฑ์ที่กำหนด (threshold) และรายการกรณีที่ไม่ผ่านเกณฑ์ จะช่วยให้สามารถนำไปสู่การดำเนินการปรับปรุงได้ง่ายขึ้น การนำผลลัพธ์นี้ไปรวมเข้ากับ CI/CD ที่จะกล่าวถึงในภายหลัง จะช่วยให้การประเมินผลไม่ใช่แค่กิจกรรมที่ทำเพียงครั้งเดียว แต่เป็นกระบวนการที่ทำได้อย่างต่อเนื่อง
ข้อผิดพลาดที่พบบ่อยใน Pipeline การประเมินและวิธีแก้ไข
LLM-as-a-Judge มีประสิทธิภาพสูง แต่ก็มีข้อควรระวังเฉพาะตัวเนื่องจากตัวตัดสินเองก็เป็น LLM เช่นกัน ในที่นี้จะกล่าวถึงความผิดพลาดทั่วไป 3 ประการที่ทำให้ผลการประเมินไม่น่าเชื่อถือ พร้อมทั้งแนวทางแก้ไข ซึ่งปัญหาเหล่านี้เป็นลักษณะเฉพาะของวิธีนี้ หากมองข้ามไปอาจนำไปสู่สถานการณ์ที่ "ประเมินผลแล้วแต่คุณภาพกลับไม่ดีขึ้น" ได้
การรับมือกับปัญหาอคติ (Bias) และการประเมินตนเองของ Judge LLM
มีการรายงานว่า LLM ที่ใช้เป็นตัวตัดสิน (Judge) มีอคติที่ทราบกันอยู่หลายประการ ตัวอย่างที่เด่นชัด ได้แก่ แนวโน้มที่จะให้คะแนนคำตอบที่ยาวสูงกว่าปกติ, แนวโน้มที่จะชอบตัวเลือกที่ถูกนำเสนอเป็นอันดับแรก และอคติจากการประเมินตนเอง (Self-preference bias) ซึ่งมักจะให้คะแนนคำตอบที่ตนเอง (โมเดลเดียวกัน) สร้างขึ้นมาอย่างผ่อนปรน
สิ่งที่ควรระมัดระวังเป็นพิเศษคือปัญหาการประเมินตนเอง หากใช้โมเดลเดียวกันทั้งในการสร้างคำตอบและเป็นตัวตัดสิน อาจมีความเสี่ยงที่การประเมินจะมีความลำเอียง วิธีแก้ไขที่มีประสิทธิภาพคือการใช้โมเดลคนละตระกูลกับที่ใช้สร้างคำตอบมาเป็นตัวตัดสิน หรือใช้โมเดลหลายตัวในการให้คะแนนแล้วนำผลลัพธ์มาเปรียบเทียบกัน
แม้จะไม่สามารถขจัดอคติให้หมดไปได้อย่างสมบูรณ์ แต่สามารถลดผลกระทบลงได้ โดยการกำหนดเกณฑ์การให้คะแนนให้ชัดเจนเพื่อจำกัดดุลยพินิจของตัวตัดสิน, การตรวจสอบเป็นระยะว่าความยาวหรือลำดับของคำตอบส่งผลต่อผลลัพธ์หรือไม่ และการตรวจสอบความถูกต้องของตัวตัดสินด้วยการเทียบกับการประเมินโดยมนุษย์ในจุดสำคัญ สิ่งสำคัญคือการไม่เชื่อมั่นในตัวตัดสินอย่างหลับหูหลับตา แต่ต้องมีทัศนคติที่รวมเอาตัวตัดสินเข้ามาเป็นส่วนหนึ่งของสิ่งที่ต้องประเมินด้วย
ความผันผวนของคะแนนที่เกิดจากข้อบกพร่องในการออกแบบ Prompt
หากคุณพบว่าคะแนนไม่เสถียรแม้จะประเมินคำตอบเดิม สาเหตุส่วนใหญ่มักมาจากความคลุมเครือของ Judge Prompt
คำสั่งอย่างเช่น "จงให้คะแนนคุณภาพของคำตอบเต็ม 10 คะแนน" จะทำให้การตัดสินขึ้นอยู่กับดุลยพินิจของ Judge ซึ่งส่งผลให้ผลลัพธ์คลาดเคลื่อนทุกครั้งที่ประมวลผล การแบ่งเกณฑ์การให้คะแนนออกเป็นหัวข้อที่ชัดเจนและให้ตัดสินแยกกันในแต่ละหัวข้อจะช่วยลดความแปรปรวนลงได้อย่างมาก
แนวทางปฏิบัติเพื่อลดความแปรปรวน ได้แก่ การตั้งค่า Temperature ให้ต่ำเพื่อสร้างผลลัพธ์ที่เสถียร, การระบุเกณฑ์การตัดสินและรูปแบบผลลัพธ์ผ่านตัวอย่าง (Few-shot) ให้กับ Judge, และการประเมินเคสเดิมซ้ำหลายครั้งเพื่อตรวจสอบความสอดคล้องของคะแนน
ก่อนเริ่มการประเมิน ควรตรวจสอบกับเคสจำนวนน้อยๆ ให้แน่ใจก่อนว่า "ผลลัพธ์มีความเสถียรแม้จะประเมินอินพุตเดิมซ้ำหรือไม่" หากดำเนินการประเมินจำนวนมากทั้งที่ส่วนนี้ยังไม่เสถียร คุณจะไม่สามารถแยกแยะได้ว่าความแตกต่างของคะแนนที่ได้นั้นมาจากคุณภาพที่ต่างกันจริง หรือมาจากความไม่แน่นอนของ Judge กันแน่
การปนเปื้อนของชุดทดสอบ (Data Contamination) และความน่าเชื่อถือของผลการประเมินที่ลดลง
การปนเปื้อนของชุดทดสอบ (Data Contamination) หมายถึงสภาวะที่ข้อมูลที่ใช้ในการประเมินทำให้ผลลัพธ์การประเมินดูดีเกินความเป็นจริง ในบริบทของ LLM-as-a-Judge ปัญหานี้มักเกิดขึ้นใน 2 รูปแบบหลัก
รูปแบบแรกคือ กรณีที่คำถามหรือคำตอบที่ถูกต้องของชุดทดสอบหลุดเข้าไปอยู่ในเอกสารเป้าหมายของ RAG หรือเป็นตัวอย่างใน Prompt ซึ่งจะกลายเป็นการให้โมเดลแก้โจทย์ที่ "รู้อยู่แล้วว่าคำตอบคืออะไร" ทำให้ไม่สามารถวัดความสามารถที่แท้จริงในการใช้งานจริงได้ ดังนั้น จึงต้องแยกข้อมูลที่ใช้ประเมินออกจากความรู้หรือตัวอย่างที่ให้แก่ RAG อย่างชัดเจน
รูปแบบที่สองคือ กรณีที่ชุดทดสอบล้าสมัยและไม่สอดคล้องกับข้อมูลหน้างานจริง หากคำถามที่เกิดขึ้นจริงมีการเปลี่ยนแปลงไปแล้ว แต่เรายังคงประเมินด้วยคำถามเก่าๆ ต่อไป แม้จะได้คะแนนที่ดี แต่เมื่อนำไปใช้งานจริงก็อาจล้มเหลวได้
แนวทางแก้ไขคือ การแยกจัดการข้อมูลประเมินออกจากฐานความรู้ของ RAG อย่างเด็ดขาด และการนำตัวอย่างความล้มเหลวที่พบจากการใช้งานจริงมาอัปเดตลงในชุดทดสอบอย่างสม่ำเสมอเพื่อรักษาความสดใหม่ของการประเมิน ทั้งนี้ การประเมินที่เกิดการปนเปื้อนอาจเป็นอันตรายยิ่งกว่าการไม่มีการประเมินเลย เพราะตัวเลขที่ดีจะทำให้เราประมาทได้
การรวมเข้ากับ CI/CD และวิธีการดำเนินการประเมินอย่างต่อเนื่อง
การประเมินผลเพียงครั้งเดียวแทบไม่มีความหมาย เนื่องจากคุณภาพของ RAG จะเปลี่ยนแปลงไปตามการอัปเดตข้อมูลหรือโมเดล จึงจำเป็นต้องมีกลไกที่ประเมินผลโดยอัตโนมัติทุกครั้งที่มีการเปลี่ยนแปลง การออกแบบภาพรวมเพื่อรวม Pipeline การประเมินผลเข้ากับ CI/CD เพื่อให้เกิดการประเมินอย่างต่อเนื่องนั้น ได้มีการกล่าวถึงไว้ใน คู่มือการใช้งาน Enterprise RAG ในระดับ Production แล้ว ในที่นี้จะขอนำเสนอประเด็นสำคัญในการนำ LLM-as-a-Judge มาใช้สำหรับการประเมินผลอัตโนมัติ
การตั้งค่า Trigger สำหรับการประเมินอัตโนมัติโดยใช้ GitHub Actions
รูปแบบทั่วไปของการประเมินผลแบบต่อเนื่อง (Continuous Evaluation) คือการตั้งค่าให้ระบบรันการประเมินโดยอัตโนมัติเมื่อมีการเปลี่ยนแปลงโค้ด, Prompt หรือข้อมูล หากใช้ GitHub ให้ใช้ Pull Request หรือการ Merge เข้าสู่ Branch ที่กำหนดเป็นตัวกระตุ้น (Trigger) ให้สคริปต์การประเมินทำงาน
yaml
1name: rag-eval
2on:
3 pull_request:
4 branches: [main]
5jobs:
6 evaluate:
7 runs-on: ubuntu-latest
8 steps:
9 - uses: actions/checkout@v4
10 - run: pip install ragas datasets
11 - run: python eval/run_ragas.py
12 env:
13 LLM_API_KEY: ${{ secrets.LLM_API_KEY }}API Key ของ LLM ที่ใช้สำหรับตัดสิน (Judge LLM) ควรถูกส่งผ่านอย่างปลอดภัยในรูปแบบของ Repository Secrets เนื่องจากกระบวนการประเมินมีค่าใช้จ่ายด้าน API จึงควรควบคุมความถี่ในการรันให้เหมาะสม เช่น รันเฉพาะตอนทำ Pull Request แทนที่จะรันทุกครั้งที่มีการ Commit หากชุดทดสอบ (Test Set) มีขนาดใหญ่ การแยกการประเมินแบบเบา (Lightweight Evaluation) ที่รันเฉพาะส่วนที่เกี่ยวข้องกับการเปลี่ยนแปลง กับการประเมินแบบเต็มรูปแบบ (Full Evaluation) ที่รันเป็นระยะ จะช่วยให้สามารถรักษาสมดุลระหว่างต้นทุนและความครอบคลุมได้ดีขึ้น
แนวทางปฏิบัติที่ดีที่สุดในการจัดการเกณฑ์คะแนน (Threshold) และการออกแบบระบบแจ้งเตือน
กุญแจสำคัญประการสุดท้ายที่จะทำให้การประเมินอัตโนมัติมีคุณค่า คือการจัดการเกณฑ์มาตรฐาน (Threshold) และการแจ้งเตือน หากเพียงแค่บันทึกคะแนนไว้เฉยๆ เราจะไม่สามารถรับรู้ได้เลยเมื่อคุณภาพลดลง
ขั้นแรก ให้กำหนดเกณฑ์มาตรฐานสำหรับผ่านหรือไม่ผ่านในแต่ละตัวชี้วัด และหากคะแนนต่ำกว่าเกณฑ์ดังกล่าว ให้สั่งให้ CI ล้มเหลว ตัวอย่างเช่น การบล็อกการ Merge สำหรับ Pull Request ที่มีค่าความถูกต้อง (Faithfulness) ต่ำกว่าเกณฑ์ที่กำหนด วิธีการนี้จะช่วยหยุดการเปลี่ยนแปลงที่ทำให้คุณภาพลดลงก่อนที่จะถูกนำไปใช้จริง
สำหรับการตั้งค่าเกณฑ์มาตรฐาน ให้เริ่มจากการใช้ค่าคงที่ก่อน แล้วจึงปรับเปลี่ยนตามสถานการณ์จริงหน้างาน หากตั้งเกณฑ์ไว้เข้มงวดเกินไปก็จะขัดขวางแม้กระทั่งการเปลี่ยนแปลงที่ถูกต้อง แต่หากตั้งไว้หลวมเกินไปก็จะทำให้มองข้ามความเสื่อมถอยของระบบไปได้ ดังนั้นควรดูแนวโน้มของคะแนนในอดีตประกอบ เพื่อปรับระดับให้เหมาะสมกับความเสี่ยงของการใช้งาน
ในส่วนของการแจ้งเตือน นอกจากจะมีการแจ้งเตือนเมื่อ CI ล้มเหลวแล้ว ควรมีกลไกในการสุ่มตรวจคะแนนระหว่างการใช้งานจริงอย่างสม่ำเสมอเพื่อตรวจจับความเสื่อมถอยของระบบด้วย การใช้การประเมินผลแบบ "เกตก่อนการปล่อยซอฟต์แวร์" (Release Gate) ควบคู่ไปกับ "การเฝ้าระวังระหว่างการใช้งาน" (Operational Monitoring) จะช่วยรักษาคุณภาพของ RAG ให้คงที่ได้อย่างต่อเนื่อง โดยมี LLM-as-a-Judge เป็นวิธีการหลักที่ช่วยสนับสนุนการทำงานอัตโนมัตินี้
ผู้เขียน・ผู้ตรวจสอบ
Chi
ศึกษาเอกวิทยาการสารสนเทศที่มหาวิทยาลัยแห่งชาติลาว และระหว่างศึกษาได้มีส่วนร่วมในการพัฒนาซอฟต์แวร์ทางสถิติ สั่งสมพื้นฐานด้านการวิเคราะห์ข้อมูลและการเขียนโปรแกรมอย่างเป็นรูปธรรม ตั้งแต่ปี 2021 ได้ก้าวเข้าสู่เส้นทางการพัฒนา Web และแอปพลิเคชัน และตั้งแต่ปี 2023 เริ่มสั่งสมประสบการณ์การพัฒนาอย่างจริงจังทั้งในด้าน Frontend และ Backend ในบริษัทปัจจุบันรับผิดชอบการออกแบบและพัฒนาบริการ Web ที่ใช้ AI โดยมีส่วนร่วมในโครงการที่นำการประมวลผลภาษาธรรมชาติ (NLP) การเรียนรู้ของเครื่อง (Machine Learning) และ Generative AI รวมถึงโมเดลภาษาขนาดใหญ่ (LLM) มาผสานรวมกับระบบงานจริง มีความกระตือรือร้นในการติดตามเทคโนโลยีล่าสุดอยู่เสมอ และให้ความสำคัญกับความรวดเร็วในการดำเนินงานตั้งแต่การพิสูจน์แนวคิดทางเทคนิคไปจนถึงการนำไปใช้งานจริง
