Eval-Driven Development (EDD) คืออะไร? กระบวนการพัฒนา AI ที่เน้นการประเมินผลเป็นหลัก

Eval-Driven Development (EDD) คือแนวทางการพัฒนาที่ให้ความสำคัญกับการออกแบบตัวชี้วัด (Evaluation Metrics) เป็นจุดเริ่มต้นของการพัฒนา AI โดยอาศัยวงจรการประเมินผลอย่างต่อเนื่องเพื่อรับประกันคุณภาพของโมเดลและผลิตภัณฑ์

ในการพัฒนาแอปพลิเคชันด้วย LLM (Large Language Model) มักเกิดสภาวะที่ "ดูเหมือนว่าทำงานได้ แต่ไม่สามารถวัดคุณภาพได้" เพื่อรับมือกับปัญหานี้ EDD จึงนำเสนอกลไกที่ช่วยให้วิศวกรและฝ่ายธุรกิจสามารถพัฒนาผลิตภัณฑ์โดยใช้เกณฑ์คุณภาพเดียวกัน ผ่านการกำหนดมาตรฐานการประเมินที่ครอบคลุมหลายมิติ เช่น การตรวจจับอาการประสาทหลอน (Hallucination), คุณภาพของคำตอบ และความปลอดภัย ก่อนที่จะเริ่มการพัฒนาจริง

บทความนี้จัดทำขึ้นสำหรับวิศวกรและผู้จัดการผลิตภัณฑ์ที่มีส่วนร่วมในการพัฒนาและดูแลแอปพลิเคชัน LLM

บทสรุป: EDD คือวิธีการที่นำแนวคิดของ Test-Driven Development (TDD) มาประยุกต์ใช้กับการพัฒนา LLM โดยการกำหนดตัวชี้วัดการประเมิน (Evaluation Metrics) ไว้เป็นจุดเริ่มต้นของการพัฒนา ซึ่งจะช่วยรับประกันคุณภาพได้อย่างต่อเนื่อง

เนื้อหาต่อไปนี้จะสรุปถึงจุดเหมือนและจุดต่างระหว่าง TDD และ EDD, ความยากลำบากในการทดสอบที่เป็นลักษณะเฉพาะของ LLM รวมถึงปัญหาที่เกิดจาก "การพัฒนาที่ปราศจากการประเมิน" (Evaluation-less development) ตามลำดับ

TDD (Test-Driven Development) และ EDD ต่างก็มีแนวคิดร่วมกันคือ "การกำหนดเกณฑ์คุณภาพก่อนการลงมือพัฒนา" เช่นเดียวกับที่ TDD ให้เขียน Unit Test ก่อนเขียนโค้ด EDD ก็ให้เตรียมเกณฑ์การประเมินและชุดข้อมูลสำหรับการประเมินก่อนที่จะสร้างแอปพลิเคชัน LLM

สรุปจุดร่วม:

• กำหนดเกณฑ์คุณภาพไว้ล่วงหน้า และทำซ้ำเพื่อปรับปรุงจนกว่าการพัฒนาจะเป็นไปตามเกณฑ์นั้น
• ใช้กรณีที่ล้มเหลว (Test Fail / คะแนนการประเมินลดลง) เป็นจุดเริ่มต้นของวงจรการพัฒนา
• สามารถตรวจพบการถดถอย (Regression) ได้ตั้งแต่เนิ่นๆ เมื่อนำไปใช้ร่วมกับ Continuous Integration

ในตอนแรก เรามักจะคิดว่า "การนำแนวคิดของ TDD มาปรับใช้กับการพัฒนา LLM โดยตรงก็น่าจะเพียงพอแล้ว" แต่ในความเป็นจริง การทดสอบโค้ดที่เป็นแบบกำหนดผลลัพธ์ได้ (Deterministic) กับผลลัพธ์ของ LLM ที่เป็นแบบความน่าจะเป็น (Probabilistic) จำเป็นต้องเปลี่ยนกลไกการตรวจสอบคุณภาพจากรากฐาน

หัวใจสำคัญของความแตกต่าง:

ใน TDD เราจะถามว่า "ทดสอบผ่านหรือไม่" แต่ใน EDD เราจะถามว่า "ความถูกต้องของคำตอบเกินเกณฑ์ที่กำหนดไว้หรือไม่" ในตัวอย่างการประเมินของ MLflow ค่า correctness/mean จะอยู่ที่ 0.

ในการพัฒนาซอฟต์แวร์แบบดั้งเดิม การทดสอบแบบกำหนดผลลัพธ์ที่แน่นอน (Deterministic testing) ที่ว่า "หากป้อน Input A เข้าไป จะต้องได้ Output B ออกมา" นั้นสามารถทำได้จริง แต่สำหรับแอปพลิเคชันที่ใช้ LLM สมมติฐานนี้กลับพังทลายลงตั้งแต่ต้น เนื่องจากแม้จะใช้ Prompt เดิม แต่ด้วยค่า Temperature หรือการสุ่มภายใน (Internal sampling) ทำให้ข้อความที่สร้างขึ้นแตกต่างกันออกไปในทุกครั้ง การตัดสินผลผ่าน/ไม่ผ่านด้วยการเทียบค่าที่ตรงกันทุกประการ (Exact match) จึงใช้งานไม่ได้ หากพยายามนำกรอบการทำงานของ Unit test หรือ E2E test มาใช้โดยตรง ก็จะพบกับทางตันในทันที

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

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

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

เบื้องหลังความจำเป็นของ Evaluation-Driven Development (EDD) คือความเสี่ยงจากการนำระบบขึ้นใช้งานจริง (Production release) ในขณะที่ยังอยู่ในสถานะที่ "ไม่สามารถทดสอบได้" เช่นนี้

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

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

EDD เข้ามาจัดการกับปัญหาเหล่านี้โดยการวางตัวชี้วัดการประเมินไว้ที่จุดเริ่มต้นของวงจรการพัฒนา กล่าวคือ ก่อนเริ่มพัฒนาจะมีการกำหนดเกณฑ์ว่า "อะไรคือความสำเร็จ" และรวมขั้นตอนการวัดผลการเปลี่ยนแปลงทุกครั้งเข้ากับเกณฑ์ดังกล่าว ในเวิร์กโฟลว์การประเมินของ MLflow คุณสามารถตรวจสอบผลลัพธ์ของการเปลี่ยนแปลงเชิงปริมาณได้โดยการเปรียบเทียบค่าการวัดผลพื้นฐาน (เช่น correctness/mean = 0.2) กับค่าการวัดผลหลังการปรับปรุง (เช่น correctness/mean = 1.0)

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

แม้จะกล่าวว่าควรให้ความสำคัญกับการออกแบบการประเมิน (Evaluation Design) เป็นอันดับแรก แต่หากปราศจากรากฐานที่มั่นคง วงจรการประเมินก็ไม่สามารถขับเคลื่อนไปได้ หากเราเตรียมเพียงตัวชี้วัดโดยที่ยังมีความคลุมเครือว่า "จะประเมินอะไร" ผลลัพธ์ที่ได้จากการวัดมักจะไม่สามารถนำไปใช้เป็นเบาะแสในการปรับปรุงได้ ดังนั้น การตรวจสอบองค์ประกอบ 3 ประการ ได้แก่ ประเภทของแอปพลิเคชัน, Golden Dataset และโครงสร้างพื้นฐาน MLOps จึงเป็นเงื่อนไขเบื้องต้นเพื่อให้ EDD สามารถใช้งานได้จริง

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

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

ประเภทของแอปพลิเคชัน LLM หลักๆ และคุณลักษณะในการประเมินของแต่ละประเภท มีดังนี้:

• Q&A / แชทบอท: ตัวชี้วัดหลักคือความถูกต้องของคำตอบ อัตราการเกิดฮัลซิเนชัน (Hallucination) และความเร็วในการตอบสนอง สามารถประเมินเชิงปริมาณโดยเทียบกับชุดข้อมูลมาตรฐาน (Golden Dataset) ได้ง่าย
• RAG (Retrieval-Augmented Generation) Pipeline: จำเป็นต้องแยกประเมินระหว่างคุณภาพการค้นหา (Retrieval) และคุณภาพการสร้างคำตอบ (Generation)

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

Golden Dataset คือชุดข้อมูลที่รวบรวมคู่ Input-Output ที่มี Label เฉลยกำกับไว้ ซึ่งจะทำหน้าที่เป็นจุดอ้างอิงสำหรับตัวชี้วัดการประเมินผล โดยแนวทางการจัดเตรียมสามารถแบ่งออกเป็นสองขั้นตอนหลัก

หลักการตัดสินใจพื้นฐานคือ หากมีข้อมูลจริงเพียงพอให้ใช้ข้อมูลจริงเป็นลำดับแรก แต่หากไม่มีให้ใช้ข้อมูลสังเคราะห์ (Synthetic Data) เข้ามาเสริม ในทางปฏิบัติ หากสามารถรวบรวม Log การใช้งานจริงหรือประวัติ QA ได้มากกว่า 100 รายการ ให้สร้างชุดข้อมูลโดยเน้นข้อมูลจริงและให้ผู้เชี่ยวชาญเฉพาะด้านเป็นผู้กำหนด Label ในทางกลับกัน หากอยู่ในขั้นตอน PoC ก่อนการเปิดตัวจริง หรือกรณีที่ข้อมูลเฉพาะทางมีไม่เพียงพอ การใช้ข้อมูลสังเคราะห์ที่สร้างโดย LLM เพื่อเติมเต็มส่วนที่ขาดหายไปถือเป็นวิธีที่มีประสิทธิภาพ

ข้อควรระวังในการสร้างข้อมูลสังเคราะห์มีดังนี้:

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

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

"เขียน evaluation script เสร็จแล้ว แต่ไม่รู้จะเก็บผลลัพธ์ไว้ที่ไหน" — นี่คือคำถามที่มักได้ยินบ่อยในทีมที่เพิ่งเริ่มต้นทำ EDD การหมุนวงจรการประเมินให้ต่อเนื่องได้นั้น จำเป็นต้องอาศัยทั้งโครงสร้างพื้นฐาน MLOps ที่สามารถบันทึกและเปรียบเทียบผลการประเมินได้ และ AI Observability ที่ช่วยให้มองเห็นพฤติกรรมของระบบในขณะ inference ทั้งสองส่วนนี้ขาดกันไม่ได้

องค์ประกอบที่ต้องจัดเตรียมแบ่งออกเป็นสามส่วนหลัก ดังนี้

① Experiment Tracking นำเครื่องมือจัดการ experiment อย่าง MLflow มาใช้ เพื่อบริหารจัดการ version ของ prompt, parameter และ evaluation score ไว้ในที่เดียวกัน ฟีเจอร์ Evaluation Datasets ของ MLflow ต้องการ SQL backend อย่างใดอย่างหนึ่งจาก PostgreSQL, MySQL, SQLite หรือ MSSQL ดังนั้นควรตรวจสอบสภาพแวดล้อมของฐานข้อมูลให้พร้อมก่อนใช้งาน

② Version Control ของ Pipeline จัดการ prompt, chunk size ของ RAG (Retrieval-Augmented Generation) และการตั้งค่า model ด้วย Git เช่นเดียวกับการจัดการ code เป้าหมายคือการรักษาสถานะที่สามารถ trace ได้ว่า "การเปลี่ยนแปลงใดส่งผลต่อ evaluation score"

③ การฝัง Observability เข้าในระบบ ในสภาพแวดล้อม production ให้เก็บข้อมูล latency, ปริมาณ token ที่ใช้ และอัตราการเกิด Hallucination แบบ real-time การมีกลไกที่ป้อน log ที่เก็บได้กลับเข้าสู่ evaluation dataset จะทำให้การประเมินและการดำเนินงานจริงเชื่อมต่อกันอย่างไม่ขาดตอน

สรุป: EDD ดำเนินการผ่าน 6 ขั้นตอน ได้แก่ "การกำหนดตัวชี้วัดการประเมิน → การสร้างเคสทดสอบ → การติดตั้ง Harness → การวัดค่า Baseline → การปรับปรุง → วงจรต่อเนื่อง"

การทำความเข้าใจบทบาทและลำดับของแต่ละขั้นตอน ตั้งแต่การออกแบบการประเมินไปจนถึงวงจรการปรับปรุงอย่างต่อเนื่อง คือกุญแจสำคัญในการนำ EDD ไปปฏิบัติจริง ในหัวข้อ H3 ถัดไปจะอธิบายรายละเอียดของแต่ละเฟสตามลำดับ

หลุมพรางแรกของ EDD คือการใช้วิธี "สร้างสิ่งที่ใช้งานได้ไปก่อน แล้วค่อยคิดเรื่องการประเมินผลทีหลัง" ในความเป็นจริงแล้ว การพยายามกำหนดตัวชี้วัดการประเมินผลในภายหลังมักทำให้ไม่สามารถระบุได้ว่าควรวัดค่าใด และทำให้ทิศทางการปรับปรุงไม่ชัดเจน การกำหนดตัวชี้วัดการประเมินผลและกรณีทดสอบ (Test Case) ไว้ล่วงหน้าจะเป็นเข็มทิศให้กับการพัฒนาโดยรวม

Step 1: การกำหนดตัวชี้วัดการประเมินผล

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

• ความถูกต้อง (Correctness): คำตอบสอดคล้องกับข้อเท็จจริงหรือไม่ ซึ่งมีความสำคัญอย่างยิ่งในระบบ RAG (Retrieval-Augmented Generation)
• การอ้างอิงแหล่งที่มา (Grounding): คำตอบมีที่มาหรือหลักฐานจากแหล่งข้อมูลอ้างอิงหรือไม่
• ความปลอดภัย (Safety): มีเนื้อหาที่เป็นอันตรายหรือไม่เหมาะสมรวมอยู่ด้วยหรือไม่
• ความหน่วง (Latency): เวลาในการตอบสนองอยู่ในขอบเขตที่ประสบการณ์ผู้ใช้ยอมรับได้หรือไม่

แนะนำให้จำกัดตัวชี้วัดไว้ที่ 3-5 รายการ หากมีมากเกินไปจะทำให้ลำดับความสำคัญกระจัดกระจายและตัดสินใจปรับปรุงได้ช้าลง ในตัวอย่างการประเมินผลของ MLflow ได้แสดงแนวทางในการจัดการแบบรวมศูนย์โดยใช้ correctness/mean เป็นตัวชี้วัดหลัก ดังนั้นการกำหนดตัวชี้วัดหลักเพียง 1 รายการจึงเป็นจุดเริ่มต้นที่มีประสิทธิภาพ

Step 2: การสร้างกรณีทดสอบ (Test Case)

เมื่อกำหนดตัวชี้วัดได้แล้ว ให้เตรียมกรณีทดสอบเพื่อตรวจสอบตัวชี้วัดเหล่านั้น

• ชุดข้อมูลทองคำ (Golden Dataset): สร้างคู่ของอินพุตที่คาดหวังและเอาต์พุตที่ถูกต้องด้วยตนเอง (Manual)

Evaluation Harness คือโครงสร้างพื้นฐานสำหรับการรันการทดสอบ โดยทำหน้าที่ป้อนชุดทดสอบ (Test Case) เข้าสู่โมเดลพร้อมกัน และรวบรวมผลลัพธ์เพื่อสรุปผลโดยอัตโนมัติ ในมุมมองของ Harness Engineering หัวใจสำคัญของการออกแบบคือ "ความสามารถในการทำซ้ำ" (Reproducibility) และ "ความเป็นอัตโนมัติ" (Automation)

องค์ประกอบพื้นฐานของการทำ Harness Implementation

• Input Loader: โหลด Golden Dataset และนำไปรวมกับ Prompt Template
• Execution Layer: เรียกใช้ LLM API และบันทึกการตอบกลับเป็น Log
• Evaluation Layer: คำนวณคะแนนตามตัวชี้วัดที่กำหนดไว้ (เช่น ความถูกต้อง, ความปลอดภัย)
• Aggregation & Visualization: แสดงค่าเฉลี่ยหรือ Pass Rate ของแต่ละตัวชี้วัดผ่านแดชบอร์ด

หากยกตัวอย่าง MLflow เราสามารถรันกระบวนการทั้งหมดนี้ได้เพียงแค่เรียกใช้ mlflow.evaluate() จากข้อมูลการวัดจริงที่ระบุไว้ใน Research Note มีรายงานกรณีที่ค่า correctness/mean ณ จุดเริ่มต้น (Baseline) ต่ำเพียง 0.2 ซึ่งแสดงให้เห็นว่าการทำความเข้าใจสถานะปัจจุบันด้วยตัวเลขก่อนเริ่มการปรับปรุงนั้นมีความสำคัญเพียงใด

เกณฑ์การตัดสินใจสำหรับการวัด Baseline

หากโครงการยังอยู่ในขั้นตอน PoC การวัดเพียงตัวชี้วัดเดียว (เช่น คะแนนความถูกต้อง) เพื่อกำหนดค่า Baseline ถือเป็นแนวทางที่สมเหตุสมผล แต่ในทางกลับกัน หากอยู่ในขั้นตอนการปรับปรุงอย่างต่อเนื่องหลังจากการเปิดใช้งานจริง (Production) จำเป็นต้องมีการวัดหลายตัวชี้วัดควบคู่กันไป ทั้งความปลอดภัย, Latency และต้นทุน เพื่อให้เห็นภาพรวมของ Trade-off ที่เกิดขึ้น

「คะแนนไม่เพิ่มขึ้น เป็นเพราะ Prompt ไม่ดี หรือเป็นเพราะปัญหาที่ตัวข้อมูลกันแน่」—— EDD ให้คำตอบสำหรับคำถามที่มักพบเจอในหน้างานจริงนี้ผ่านกระบวนการประเมินผล (Evaluation Loop)

ใน Step 5 เราจะดำเนินการ Prompt Engineering โดยอ้างอิงจากผลการวัดค่า Baseline โดยทั่วไปแล้ว ลำดับความสำคัญในการปรับปรุงจะพิจารณาดังนี้:

• การจัดโครงสร้าง System Prompt: ระบุบทบาท ข้อจำกัด และรูปแบบผลลัพธ์ให้ชัดเจน เพื่อลดอัตราการเกิด Hallucination
• การเปลี่ยนตัวอย่าง Few-shot: เลือกตัวอย่างที่เป็นตัวแทนจาก Golden Dataset และนำเสนอในรูปแบบ CoT (Chain-of-Thought)
• การแบ่ง Chain: แยกงานที่ซับซ้อนออกเป็นหลายขั้นตอน และวัดคะแนนการประเมินในแต่ละขั้นตอน

ทุกครั้งที่มีการเปลี่ยนแปลง Prompt ให้รัน Evaluation Harness และบันทึกการเปลี่ยนแปลงของคะแนนลงในเครื่องมือติดตามผลอย่าง MLflow เป็นต้น ในตัวอย่างการประเมินของ MLflow ได้แสดงให้เห็นกรณีที่ค่า correctness/mean ของ Baseline ซึ่งอยู่ที่ 0.2 ได้ปรับปรุงขึ้นเป็น 1.0 หลังจากทำการปรับปรุง Prompt

เมื่อการปรับปรุง Prompt ถึงจุดอิ่มตัวแล้ว จึงค่อยพิจารณาการทำ Fine-tuning ใน Step 6 การใช้ PEFT (Parameter-Efficient Fine-Tuning) ด้วย LoRA หรือ QLoRA จะช่วยให้สามารถปรับจูนโมเดลให้เข้ากับงานได้โดยยังคงควบคุมต้นทุนการคำนวณไว้ได้ (รายละเอียดเพิ่มเติมคือ...

สรุป: การเลือกใช้ตัวชี้วัด (Metrics) ของ LLM ทั้งเชิงปริมาณและเชิงคุณภาพให้เหมาะสมกับ "สิ่งที่คุณต้องการปรับปรุง" คือกุญแจสำคัญในการยกระดับคุณภาพ

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

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

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

ตัวชี้วัดด้านความปลอดภัยที่สำคัญมีดังนี้:

• การตรวจจับอาการประสาทหลอน (Hallucination Detection): ตรวจสอบว่าผลลัพธ์ของโมเดลขัดแย้งกับบริบทที่กำหนดหรือข้อเท็จจริงที่ทราบหรือไม่ ในโครงสร้าง RAG (Retrieval-Augmented Generation) จะเป็นการตรวจสอบว่ามีการกล่าวอ้างข้อมูลที่ไม่ได้รวมอยู่ในผลการค้นหาอย่างมั่นใจหรือไม่
• การตรวจสอบความสมเหตุสมผล (Grounding Check): ให้คะแนนว่าแต่ละข้อความที่กล่าวอ้างในผลลัพธ์นั้นมีหลักฐานสนับสนุนในเอกสารต้นฉบับหรือไม่

BLEU และ ROUGE เป็นตัวชี้วัดเชิงปริมาณแบบอ้างอิง (reference-based metrics) ที่ใช้กันมาอย่างยาวนานในงานด้านการแปลภาษาด้วยเครื่องและการสรุปความ เนื่องจากเป็นการคำนวณอัตราการตรงกันของ n-gram กับข้อความเฉลย (reference text) จึงมีข้อดีคือสามารถคำนวณคะแนนได้รวดเร็ว มีความสามารถในการทำซ้ำ (reproducibility) และง่ายต่อการรวมเข้ากับไปป์ไลน์ CI/CD

คุณลักษณะของตัวชี้วัดหลักมีดังนี้:

• BLEU (Bilingual Evaluation Understudy): วัดว่าข้อความที่สร้างขึ้นมี n-gram ของข้อความเฉลยอยู่มากน้อยเพียงใดโดยเน้นที่ความแม่นยำ (precision) เหมาะสำหรับการประเมินคุณภาพการแปล
• ROUGE-N: วัดสัดส่วนของ n-gram ในข้อความเฉลยที่ปรากฏอยู่ในข้อความที่สร้างขึ้น (recall) เหมาะสำหรับการประเมินความครอบคลุมของการสรุปความ
• ROUGE-L: ใช้ Longest Common Subsequence (LCS) เป็นพื้นฐาน จึงสามารถรองรับความคลาดเคลื่อนของลำดับคำได้

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

สิ่งที่สำคัญในการตัดสินใจคือลักษณะของงาน ในงานอย่างการแปลหรือการสรุปความที่ "ข้อความเฉลยมีความชัดเจนเพียงหนึ่งเดียว" BLEU/ROUGE จะเป็นเกณฑ์ที่มีประสิทธิภาพ ในทางกลับกัน สำหรับงานอย่างการสร้างคำตอบของแชทบอทหรือการสังเคราะห์คำตอบของ RAG ที่ "รูปแบบของคำตอบมีความหลากหลาย" ขอแนะนำให้ใช้ร่วมกับการประเมินเชิงคุณภาพ เช่น LLM-as-a-Judge ซึ่งจะอธิบายในส่วนถัดไป

「จะให้คะแนนความเหมาะสมของโทนและบริบทของคำตอบอย่างไรดี」——คำถามนี้เป็นสิ่งที่ได้ยินซ้ำแล้วซ้ำเล่าในหน้างานการพัฒนาแอปพลิเคชัน LLM วิธีการที่กำลังได้รับความสนใจในฐานะเครื่องมือประเมินคุณภาพเชิงคุณภาพที่ไม่สามารถวัดได้ด้วยดัชนีความสอดคล้องของคำศัพท์อย่าง BLEU หรือ ROUGE โดยไม่ต้องอาศัยการตรวจสอบจากมนุษย์ คือแนวทาง LLM-as-a-Judge

LLM-as-a-Judge คือวิธีการที่ LLM อีกตัวหนึ่ง (โมเดลประเมินผล) ทำหน้าที่ให้คะแนนผลลัพธ์ที่สร้างขึ้น โดยการส่งรูบริค (เกณฑ์การให้คะแนน) และข้อความที่ต้องการประเมินให้แก่โมเดลประเมินผล เพื่อให้ส่งกลับมาเป็นคะแนนและเหตุผลประกอบ โดยแกนหลักในการประเมินมีดังนี้:

• ความถูกต้อง (Correctness): ตรงกับข้อเท็จจริงหรือไม่
• ความเกี่ยวข้อง (Relevance): สอดคล้องกับเจตนาของผู้ใช้หรือไม่
• ความลื่นไหล (Fluency): เขียนด้วยสำนวนที่เป็นธรรมชาติหรือไม่
• ความปลอดภัย (Safety): ไม่มีเนื้อหาที่เป็นอันตรายหรือไม่เหมาะสมหรือไม่

ในเฟรมเวิร์กการประเมินของ MLflow สามารถใช้กลไกนี้เป็นเมทริกซ์การประเมินแบบ Built-in และสามารถเชื่อมโยงค่าสรุปผลอย่าง correctness/mean เข้ากับการติดตามการทดลอง (Experiment Tracking) ได้

ข้อควรระวังในการนำไปปฏิบัติจริงมี 2 ประการ ดังนี้:

บทสรุป: ความล้มเหลวที่มักเกิดขึ้นในการนำ EDD มาใช้จะกระจุกตัวอยู่ที่ 3 ประเด็นหลัก ได้แก่ การออกแบบตัวชี้วัด (Metrics Design), การจัดการข้อมูล (Data Management) และการประสานงานเพื่อรับผลตอบรับ (Feedback Integration) การทำความเข้าใจรูปแบบปัญหาเหล่านี้ล่วงหน้าและเตรียมมาตรการป้องกันไว้ คือกุญแจสำคัญสู่การปรับปรุงคุณภาพอย่างต่อเนื่อง

หลายทีมมักพยายามครอบคลุมตัวชี้วัด (Evaluation Metrics) ให้ครบถ้วนจนนำตัวชี้วัดมากกว่า 10 ชนิดมาวางเรียงกัน และนิยามว่า "ไม่ว่าตัวไหนลดลงก็ถือเป็นปัญหา" ในช่วงแรกเรามักคิดว่า "ยิ่งประเมินหลายมุมมองยิ่งปลอดภัย" แต่ในความเป็นจริง การจำกัดให้เหลือเพียง 3-5 ตัวชี้วัดหลักจะช่วยให้วงจรการปรับปรุงทำงานได้รวดเร็วกว่า

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

แนวทางแก้ไขที่มีประสิทธิภาพคือการแบ่งตัวชี้วัดออกเป็น 2 ชั้น ได้แก่ "North Star Metric" และ "Diagnostic Metrics" โดย North Star Metric ควรจำกัดไว้เพียง 1-2 ตัวที่เป็นเกณฑ์ตัดสินใจขั้นสุดท้ายในการพัฒนา เช่น correctness score หรือ task completion rate ส่วน Diagnostic Metrics เป็นเพียงตัวช่วยในการระบุสาเหตุของปัญหาเท่านั้น ซึ่งควรจำกัดไว้ที่ประมาณ 3-5 ตัว เช่น hallucination rate, latency และ grounding check pass rate

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

การปล่อยให้ Golden Dataset ที่สร้างขึ้นแล้วกลายเป็น "ผลิตภัณฑ์สำเร็จรูป" ที่ถูกทิ้งไว้เฉยๆ เป็นรูปแบบความล้มเหลวที่เกิดขึ้นซ้ำแล้วซ้ำเล่าในหน้างานของ EDD

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

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

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

มาตรการเชิงปฏิบัติที่มีประสิทธิภาพคือการจัดเตรียมไปป์ไลน์เพื่อสุ่มตัวอย่างจากบันทึกการใช้งานจริง (Production Log) มาติดป้ายกำกับ (Labeling) ด้วยคนและเพิ่มเข้าไปในชุดข้อมูลเป็นระยะ พร้อมกันนี้ การทำ Version Control ให้กับชุดข้อมูลก็เป็นสิ่งที่ขาดไม่ได้ เพื่อให้สามารถแยกแยะได้ว่าการเปลี่ยนแปลงของคะแนนการประเมินนั้นเกิดจากการปรับปรุงโมเดลหรือเกิดจากการอัปเดตข้อมูล นอกจากนี้ สัญญาณเตือนของความล้าสมัยที่มักถูกมองข้ามคือช่องว่างที่ว่า "คะแนนการประเมินสูง แต่กลับมีข้อร้องเรียนเกี่ยวกับคุณภาพในการใช้งานจริงเพิ่มขึ้น" หากตั้งค่าความคลาดเคลื่อนนี้เป็นดัชนีชี้วัดการตรวจสอบไว้ชัดเจน จะช่วยให้สังเกตเห็นความเสื่อมสภาพของชุดข้อมูลได้เร็วขึ้น

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

「คะแนนการประเมินมีอยู่ในรายงานทุกสัปดาห์ แต่ผลิตภัณฑ์กลับไม่มีการปรับปรุงเลย」——คุณเคยประสบกับสถานการณ์เช่นนี้บ้างหรือไม่

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

สาเหตุของการเกิดไซโลมักจะสรุปได้จากประเด็นเดิมๆ คือ การที่ผลการประเมินถูกจำกัดอยู่แค่ภายในทีมเทคนิคและไม่ถึงมือเจ้าของผลิตภัณฑ์ (Product Owner) หรือผู้รับผิดชอบฝ่ายธุรกิจ, การที่เกณฑ์การตีความคะแนนไม่เป็นมาตรฐานเดียวกันและไม่มีการกำหนด "เกณฑ์ขั้นต่ำที่ต้องปรับปรุง" (Threshold), และการที่รายงานการประเมินกับรอบการพัฒนา (Development Sprint) ไม่ได้เชื่อมโยงกันตั้งแต่แรก เมื่อปัจจัยทั้งสามนี้มารวมกัน จึงเกิดสถานการณ์ที่รายงานถูกสร้างขึ้นทุกสัปดาห์แต่ไม่มีใครลงมือทำอะไรเลย

การแก้ไขปัญหานี้จำเป็นต้องมีกลไกที่ผนวกผลการประเมินเข้ากับรอบการพัฒนา หากมีการกำหนดเกณฑ์ขั้นต่ำของคะแนนไว้ล่วงหน้า และตั้งค่าให้มีการสร้าง Ticket โดยอัตโนมัติเมื่อคะแนนต่ำกว่าเกณฑ์ ก็จะช่วยลดขั้นตอนที่ต้องพึ่งพาบุคคล (Subjective) อย่างการที่ "ต้องมีใครสักคนสังเกตเห็นแล้วรายงาน" ออกไปได้ นอกจากนี้ หากมีการนำสรุปผลการประเมินเข้าเป็นวาระการประชุมใน Sprint Review ประจำสัปดาห์ และกำหนดแนวทางการปรับปรุงในที่ประชุมที่มีฝ่ายธุรกิจเข้าร่วมด้วย ก็จะช่วยทำลายโครงสร้างที่ทีมเทคนิคต้องแบกรับปัญหาไว้เพียงลำพังได้ง่ายขึ้น

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

บทสรุป: เนื่องจาก RAG และระบบ Multi-agent มีการประเมินผลที่ซับซ้อนหลายระดับ จึงจำเป็นต้องออกแบบวิธีการประยุกต์ใช้ EDD ใหม่ให้สอดคล้องกับโครงสร้างดังกล่าว

ต่างจากการเรียกใช้งาน LLM แบบเดี่ยว สถาปัตยกรรมเหล่านี้ต้องการเกณฑ์การประเมินที่แยกจากกันสำหรับทั้งการสืบค้น (Retrieval), การสร้าง (Generation) และการประสานงานระหว่างเอเจนต์ (Agent interaction) ต่อไปนี้คือคำอธิบายเกี่ยวกับการออกแบบการประเมินผลในแต่ละเลเยอร์และวิธีการบูรณาการเข้าด้วยกัน

ในการประเมินไปป์ไลน์ RAG (Retrieval-Augmented Generation) หลายคนมักคิดว่า "การดูเพียงคุณภาพของคำตอบสุดท้ายก็เพียงพอแล้ว" แต่ในความเป็นจริง การแยกประเมินระหว่างขั้นตอนการค้นหา (Retrieval) และขั้นตอนการสร้างคำตอบ (Generation) จะช่วยให้ระบุสาเหตุที่แท้จริงของปัญหาได้รวดเร็วกว่า

ตัวชี้วัดคุณภาพการค้นหา (Retrieval Quality)

ในขั้นตอนการค้นหา เราจะวัดว่าสามารถดึงข้อมูล (Chunk) ที่เหมาะสมกับคำถาม (Query) ได้หรือไม่ โดยมีตัวชี้วัดหลักดังนี้:

• Recall@K: สัดส่วนที่ Chunk ที่ถูกต้องถูกรวมอยู่ในผลลัพธ์ K อันดับแรก
• MRR (Mean Reciprocal Rank): ค่าเฉลี่ยของส่วนกลับของอันดับที่ Chunk ที่ถูกต้องปรากฏขึ้นเป็นครั้งแรก
• Context Precision: สัดส่วนของ Chunk ที่ดึงมาได้ ซึ่งถูกนำไปใช้ในการสร้างคำตอบจริง

การวัดค่าเหล่านี้จะช่วยให้ตัดสินใจได้ว่าจำเป็นต้องปรับปรุงการตั้งค่า Vector Database หรือขนาดของ Chunk (Chunk size) หรือไม่

ตัวชี้วัดคุณภาพการสร้างคำตอบ (Generation Quality)

ในขั้นตอนการสร้างคำตอบ เราจะประเมินว่ามีการสร้างคำตอบที่ถูกต้องโดยอ้างอิงจากบริบท (Context) ที่ดึงมาได้หรือไม่

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

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

• ชั้นเอเจนต์เดี่ยว (Agent-level): เอเจนต์แต่ละตัวส่งผลลัพธ์ที่ถูกต้องสำหรับงานที่ได้รับมอบหมายหรือไม่
• ชั้นการสื่อสารระหว่างเอเจนต์ (Agent-to-Agent Communication layer): ข้อความในโปรโตคอล A2A (Agent-to-Agent Protocol) ได้รับการตีความและส่งต่อตามเจตนาหรือไม่
• ชั้นเอนด์ทูเอนด์ (End-to-End layer): ระบบโดยรวมให้ผลลัพธ์ที่คาดหวังต่อเป้าหมายสุดท้ายของผู้ใช้หรือไม่

ในกรณีที่สิ่งที่ต้องประเมินมีความซับซ้อน การประเมินแบบ "จากล่างขึ้นบน" (Bottom-up evaluation) ซึ่งเป็นการทำให้การทดสอบเอเจนต์เดี่ยวมีความเสถียรก่อนแล้วจึงขยับไปประเมินชั้นที่สูงขึ้นนั้นถือว่ามีประสิทธิภาพ ในทางกลับกัน หากจำเป็นต้องตรวจสอบความต้องการทางธุรกิจอย่างเร่งด่วน การประเมินแบบ "จากบนลงล่าง" (Top-down evaluation) ซึ่งเป็นการประเมินแบบเอนด์ทูเอนด์ก่อนเพื่อจำกัดขอบเขตของชั้นที่มีปัญหาจะมีความเหมาะสมมากกว่า