การประเมินความแม่นยำของ AI Agent ภาษาลาว คือความพยายามในการตัดสินเชิงปริมาณว่า AI Agent แบบอัตโนมัติที่ปฏิบัติงานด้วยภาษาลาวนั้น พร้อมสำหรับการใช้งานจริงหรือไม่ โดยพิจารณาจากอัตราความสำเร็จของงาน (Task Completion Rate) ความแม่นยำในหลายภาษา (Multilingual Accuracy) และอัตราการแทรกแซงของมนุษย์ (Human Intervention Rate) บทความนี้มุ่งเน้นไปที่วิศวกรและผู้รับผิดชอบด้านเทคนิคที่ต้องการนำ AI Agent ไปใช้งานจริงในภาษาที่มีทรัพยากรจำกัด (Low-resource language) อย่างภาษาลาว โดยจะอธิบายถึงการออกแบบการประเมินเพื่อเปลี่ยนผ่านจากขั้นตอนที่ "ดูเหมือนจะทำงานได้" ไปสู่การตัดสินใจที่ว่า "พร้อมนำไปใช้งานจริงได้" เมื่ออ่านจบ คุณจะเข้าใจความหมายของเกณฑ์การประเมินทั้ง 3 ด้าน วิธีการวัดผลในแต่ละด้าน รวมถึงการออกแบบเกณฑ์ตัดสิน (Threshold) เพื่อชี้ขาดความพร้อมในการนำไปใช้งานจริง และวิธีการสร้างวงจรการดำเนินงาน โดยจะเน้นไปที่มุมมองการประเมินในระดับงานธุรกิจ (Business Task) มากกว่าการใช้เกณฑ์มาตรฐาน (Benchmark) ของตัวโมเดลเพียงอย่างเดียว

การประเมิน AI Agent ภาษาลาวนั้นทำได้ยาก เนื่องจากความผันผวนของความแม่นยำของโมเดลซึ่งเป็นภาษาที่มีทรัพยากรน้อย (low-resource language) ประกอบกับความไม่แน่นอน (non-determinism) ที่เป็นลักษณะเฉพาะของ Autonomous Agent ยิ่งไปกว่านั้น หากนำไปใช้งานจริงโดยที่การประเมินยังมีความคลุมเครือ ก็จะยังคงมีความเสี่ยงที่ระบบจะล้มเหลวในสถานการณ์สำคัญ แม้ว่าในเบื้องต้นจะดูเหมือนทำงานได้ตามปกติก็ตาม ต่อไปนี้คือการสรุปอุปสรรคทั้ง 3 ประการตามลำดับ

ภาษาลาวถูกจัดอยู่ในกลุ่มภาษาทรัพยากรต่ำ (low-resource language) ซึ่งมีปริมาณข้อมูลสำหรับการเรียนรู้โดยรวมน้อยกว่าภาษาอังกฤษหรือภาษาญี่ปุ่น โมเดลภาษาขนาดใหญ่ (Large Language Models) มักจะให้ความแม่นยำสูงในภาษาที่มีปริมาณข้อความบนเว็บจำนวนมาก ในทางกลับกัน ภาษาที่มีข้อมูลน้อยมักจะมีแนวโน้มที่ความแม่นยำทั้งในด้านความเข้าใจและการสร้างข้อความไม่คงที่

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

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

ต่างจากระบบถาม-ตอบแบบครั้งเดียวจบ (single-shot) ตรงที่ Autonomous AI Agent จะวางแผนและดำเนินงานหลายขั้นตอนด้วยตัวเอง กระบวนการที่เชื่อมโยงกันภายใน เช่น การค้นหาข้อมูล การเรียกใช้เครื่องมือ การตีความผลลัพธ์เพื่อตัดสินใจในขั้นตอนถัดไป ทำให้แม้จะเป็นอินพุตเดิม แต่เส้นทางการทำงานอาจเปลี่ยนแปลงไปในทุกครั้งที่รัน ความไม่แน่นอน (non-determinism) นี้เองที่ทำให้การประเมินผลไม่ใช่เรื่องง่าย

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

นอกจากนี้ ขอบเขตของการประเมินยังกว้างขวางมาก ไม่ว่าจะเป็นความถูกต้องของคำตอบ การเลือกใช้เครื่องมือ ผลกระทบข้างเคียงต่อระบบภายนอก พฤติกรรมเมื่อเกิดข้อผิดพลาด หรือความทนทานต่ออินพุตที่ไม่คาดคิด ด้วยเหตุนี้ การผ่านเพียงหนึ่งกรณีทดสอบ (test case) จึงไม่สามารถรับประกันคุณภาพโดยรวมได้ และหากเกี่ยวข้องกับภาษาที่มีทรัพยากรน้อย (low-resource languages) ความคลาดเคลื่อนทางภาษาที่สะสมในแต่ละขั้นตอนเมื่อรวมกับความไม่แน่นอน จะยิ่งทำให้การคาดการณ์คุณภาพทำได้ยากขึ้นไปอีก ด้วยเหตุนี้เอง จึงจำเป็นต้องมีการออกแบบการประเมินที่วัดผลอย่างรอบด้านผ่าน 3 แกนหลักที่จะกล่าวถึงต่อไปนี้

หากนำเอเจนต์ (Agent) ไปใช้งานจริงโดยที่ยังไม่มีการประเมินผลที่ชัดเจน เอเจนต์ที่ดูเหมือนจะทำงานได้ดีในการสาธิตหรือการทดสอบในวงจำกัด มักจะเผยให้เห็นปัญหาทันทีเมื่อต้องเผชิญกับอินพุตที่หลากหลายในการใช้งานจริง ซึ่งสำหรับภาษาที่มีทรัพยากรน้อย (Low-resource languages) แล้ว เงื่อนไขต่างๆ ยิ่งทำให้ช่องว่างนี้กว้างขึ้นเป็นพิเศษ

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

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

การประเมินเอเจนต์สามารถทำความเข้าใจได้ง่ายขึ้นหากพิจารณาผ่าน 3 แกนหลัก ได้แก่ อัตราความสำเร็จของงาน (Task Completion Rate), ความแม่นยำในหลายภาษา (Multilingual Accuracy) และอัตราการแทรกแซงโดยมนุษย์ (HITL Intervention Rate) การรวมทั้ง 3 ปัจจัยนี้เข้าด้วยกัน ไม่ว่าจะเป็นความสามารถในการทำงานให้สำเร็จ, ความถูกต้องในการจัดการภาษาลาว และระดับที่มนุษย์ต้องเข้าไปมีส่วนร่วม จะช่วยให้เห็นภาพรวมของคุณภาพที่ตัวชี้วัดเพียงตัวเดียวไม่สามารถแสดงให้เห็นได้ ต่อไปนี้คือรายละเอียดความหมายของแต่ละแกน

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

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

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

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

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

สำหรับภาษาที่มีทรัพยากรน้อย (Low-resource languages) ความยากในการประเมินจะเพิ่มขึ้นเป็นสองเท่า เนื่องจากความแม่นยำของโมเดลมีความเสถียรต่ำ อีกทั้งการสร้างเกณฑ์มาตรฐานสำหรับผู้ประเมินยังต้องใช้ความพยายามสูง ตัวอย่างเช่น หากเป็นภาษาอังกฤษจะมีข้อมูลสำหรับการประเมินและแนวปฏิบัติในการตัดสินที่หลากหลาย แต่สำหรับภาษาลาว ทรัพยากรเหล่านี้ยังมีจำกัดและมักจำเป็นต้องจัดเตรียมขึ้นเอง ด้วยเหตุนี้ การเตรียมชุดข้อมูลสำหรับการประเมินแยกตามภาษา (ซึ่งจะกล่าวถึงในภายหลัง) และการวัดผลด้วยเกณฑ์ที่เฉพาะเจาะจงสำหรับภาษาลาวจึงเป็นกุญแจสำคัญที่จะทำให้เกณฑ์การวัดนี้ใช้งานได้จริง

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

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

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

การวัดอัตราความสำเร็จของงานเชิงปริมาณนั้น ในทางปฏิบัติควรใช้วิธีแบ่งเป้าหมายออกเป็นงานย่อย (Subtasks) แล้วกำหนดน้ำหนัก จากนั้นให้คะแนนตามระดับความสำเร็จ โดยผสมผสานการตัดสินอัตโนมัติด้วยโปรแกรมเข้ากับการประเมินโดยมนุษย์ การออกแบบที่สามารถรองรับความสำเร็จบางส่วนซึ่งไม่สามารถตัดสินได้ด้วยตัวเลือกเพียง "ทำได้/ทำไม่ได้" นั้น จะมีประสิทธิภาพอย่างยิ่งสำหรับภาษาที่มีทรัพยากรต่ำ (Low-resource languages)

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

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

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

ระดับความสำเร็จของงานนั้น หากมองเป็น 3 ระดับ ได้แก่ "สำเร็จสมบูรณ์ (Complete Achievement)", "สำเร็จบางส่วน (Partial Achievement)" และ "เบี่ยงเบน (Deviation)" แทนที่จะเป็นค่าไบนารีแบบ "สำเร็จ-ไม่สำเร็จ" จะช่วยให้สะท้อนความเป็นจริงได้แม่นยำกว่า โดย "สำเร็จสมบูรณ์" หมายถึงสถานะที่บรรลุเป้าหมายทั้งหมด, "สำเร็จบางส่วน" หมายถึงสถานะที่ทำซับทาสก์ (sub-task) ได้บางส่วนแต่โดยรวมยังไม่เสร็จสิ้น และ "เบี่ยงเบน" หมายถึงสถานะที่ดำเนินงานไปในทิศทางที่ผิดหรือก่อให้เกิดผลลัพธ์ที่เป็นอันตราย

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

การจัดการกับ "การเบี่ยงเบน" ให้เป็นหมวดหมู่แยกต่างหากก็มีความสำคัญเช่นกัน ในภาษาที่มีทรัพยากรต่ำ (low-resource languages) อาจเกิดกรณีที่เอเจนต์เข้าใจภาษาผิดพลาดจนตั้งสมมติฐานที่ผิด แล้วดำเนินการไปในทางที่ผิดอย่างมั่นใจ "ความผิดพลาดเชิงรุก" เช่นนี้อาจมีความเสี่ยงสูงกว่าการแค่ทำไม่เสร็จ การทำให้การเบี่ยงเบนเป็นสิ่งที่มองเห็นได้จะช่วยให้การตัดสินใจนำไปใช้งานจริงทำได้ง่ายขึ้น โดยสามารถกำหนดเกณฑ์ตามลักษณะของความเสี่ยง เช่น "ยอมรับได้หากงานไม่เสร็จ แต่ยอมรับไม่ได้หากมีการเบี่ยงเบน" การให้คะแนน 3 ระดับจึงเป็นกลวิธีในการจับทั้งความเข้มข้นของความสำเร็จและคุณภาพของความล้มเหลวด้วยกรอบการทำงานที่เรียบง่าย

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

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

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

การวัดความแม่นยำของภาษาลาวในระบบหลายภาษา (Multilingual) โดยพื้นฐานแล้วจำเป็นต้องจัดเตรียมชุดข้อมูลประเมินผล (Evaluation Dataset) ที่เฉพาะเจาะจงสำหรับภาษาลาวด้วยตนเอง โดยต้องระมัดระวังข้อผิดพลาดในระดับต่ำ (Low-level pitfalls) เช่น ประสิทธิภาพของโทเค็น (Token efficiency) และปัญหาตัวอักษรเพี้ยน (Mojibake) จุดเริ่มต้นของแนวทางนี้คือการตระหนักว่าทรัพยากรภาษาอังกฤษที่มีอยู่เดิมไม่สามารถนำมาปรับใช้ได้โดยตรง

ในการประเมินความแม่นยำของภาษาลาว จำเป็นต้องระมัดระวังข้อผิดพลาดที่อาจเกิดขึ้นในขั้นตอนก่อนที่ข้อความจะถูกส่งไปยังโมเดล นั่นคือระดับของการทำ Tokenization โดยโมเดลส่วนใหญ่มักใช้วิธีการแบบ BPE (Byte Pair Encoding) ในการแบ่งข้อความเป็นหน่วยย่อยเพื่อประมวลผล ซึ่งการแบ่งนี้มักถูกปรับให้เหมาะสมกับภาษาที่มีข้อมูลการเรียนรู้จำนวนมาก ส่งผลให้ภาษาที่มีทรัพยากรน้อย (Low-resource language) อย่างภาษาลาวมักจะมีจำนวน Token ต่อประโยคสูงกว่าปกติ

การที่จำนวน Token เพิ่มขึ้นส่งผลกระทบในทางปฏิบัติหลายประการ เช่น แม้จะเป็นเนื้อหาเดียวกัน แต่ภาษาลาวจะใช้จำนวน Token มากกว่า ทำให้ถึงขีดจำกัดของ Context length ได้เร็วกว่า และมีต้นทุนในการประมวลผลที่สูงกว่าโดยเปรียบเทียบ สำหรับ Agent ที่ต้องจัดการกับบริบทที่ยาว ความแตกต่างนี้อาจกลายเป็นประเด็นที่ไม่สามารถมองข้ามได้ นอกจากนี้ หากมีการเข้ารหัสตัวอักษรหรือการจัดการฟอนต์ที่ผิดพลาด อาจทำให้เกิดปัญหาตัวอักษรเพี้ยน (Mojibake) บนหน้าจอแสดงผลหรือใน Log จนทำให้ไม่สามารถอ่านสิ่งที่โมเดลส่งออกมาได้อย่างถูกต้องก่อนที่จะเริ่มประเมินคุณภาพของผลลัพธ์เสียอีก

ปัญหาในระดับต่ำเหล่านี้บิดเบือนผลการประเมินในมิติที่แยกจากความฉลาดของโมเดล แม้จะดูเหมือนว่าความแม่นยำต่ำ แต่หากสาเหตุมาจากความบกพร่องในการทำ Tokenization หรือการเข้ารหัส การเปลี่ยนโมเดลก็อาจไม่ช่วยให้ดีขึ้น ก่อนเริ่มการประเมินจึงควรตรวจสอบให้แน่ใจว่าข้อความภาษาลาวไม่ได้เสียหายในขั้นตอนการทำ Pre-processing, Tokenization และการแสดงผล แม้รายละเอียดเชิงลึกเกี่ยวกับการทำงานภายในของ BPE และ Tokenizer จะอยู่นอกเหนือขอบเขตของบทความนี้และจะกล่าวถึงในบทความอื่น แต่ในมุมมองของการออกแบบการประเมิน การตั้งสมมติฐานไว้ก่อนว่า "การใช้ Token และความเสถียรของ Pre-processing นั้นแตกต่างกันไปตามแต่ละภาษา" จะช่วยให้หลีกเลี่ยงข้อสรุปที่คลาดเคลื่อนได้

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

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

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

การตัดสินใจว่าจะนำขึ้นใช้งานจริง (Production) หรือไม่นั้น จะพิจารณาโดยอ้างอิงจากวงจรการดำเนินงานที่กำหนดเกณฑ์ (Threshold) สำหรับผลการประเมินทั้ง 3 แกน ตรวจสอบผ่านการประเมินนำร่อง (Pilot evaluation) ขนาดเล็ก และทำการประเมินซ้ำอย่างต่อเนื่องหลังจากนำขึ้นใช้งานแล้ว กุญแจสำคัญคือการออกแบบให้เป็นกลไกที่ดำเนินการได้อย่างต่อเนื่อง ไม่ใช่จบลงเพียงแค่การตัดสินว่าผ่านเกณฑ์ในครั้งเดียว

ในการตัดสินใจว่าจะนำระบบไปใช้งานจริงหรือไม่ จำเป็นต้องกำหนดเกณฑ์มาตรฐานหรือ "เส้นผ่านเกณฑ์" สำหรับแกนการประเมินทั้ง 3 ด้าน โดยต้องกำหนดเงื่อนไขความสำเร็จเชิงปริมาณไว้ล่วงหน้า เช่น "จะพิจารณานำไปใช้งานหากอัตราความสำเร็จของงานถึงระดับนี้ ความแม่นยำของภาษาลาว (Laos language) เกินเกณฑ์นี้ และอัตราการแทรกแซงโดยมนุษย์ (HITL intervention rate) อยู่ในขอบเขตนี้" หากเกณฑ์มาตรฐานมีความคลุมเครือ การตัดสินใจจะขึ้นอยู่กับความรู้สึกของผู้รับผิดชอบและทำให้ขาดความสามารถในการอธิบาย (explainability)

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

เกณฑ์มาตรฐานที่กำหนดไว้ควรได้รับการตรวจสอบผ่านการประเมินนำร่อง (pilot evaluation) ในระดับเล็กก่อน แทนที่จะนำไปใช้เต็มรูปแบบในทันที ควรจำกัดขอบเขตหรือกลุ่มผู้ใช้งานเพื่อทดสอบว่าเอเจนต์สามารถบรรลุเกณฑ์ทั้ง 3 ด้านในการใช้งานจริงหรือไม่ ในขั้นตอนนำร่อง การตั้งอัตราการแทรกแซงโดยมนุษย์ (HITL intervention rate) ให้สูงไว้และให้มนุษย์คอยตรวจสอบผลลัพธ์จะช่วยจำกัดความเสียหายหากเกิดข้อผิดพลาดที่คาดไม่ถึง การทบทวนเกณฑ์มาตรฐานและการออกแบบโดยใช้ข้อมูลจริงที่ได้จากช่วงนำร่อง แล้วค่อยๆ ขยายขอบเขตของระบบอัตโนมัติออกไปทีละน้อย ถือเป็นแนวทางที่สมเหตุสมผลอย่างยิ่งสำหรับภาษาที่มีทรัพยากรต่ำ (low-resource languages)

การประเมินเอเจนต์ (Agent) ไม่ได้สิ้นสุดลงเพียงแค่ตอนนำไปใช้งานจริง แต่จำเป็นต้องสร้างเป็นวงจรการดำเนินงานที่มีการประเมินซ้ำอย่างต่อเนื่อง เนื่องจากแม้จะตัดสินว่าผ่านเกณฑ์ในครั้งแรกแล้ว แต่แนวโน้มของข้อมูลนำเข้า (Input) จะเปลี่ยนไปตามกาลเวลา อีกทั้งพฤติกรรมของโมเดลและระบบโดยรอบอาจเปลี่ยนแปลงได้จากการอัปเดต จึงควรออกแบบโดยตั้งอยู่บนสมมติฐานที่ว่า "เมื่อนำไปใช้งานแล้ว ต้องวัดผลอย่างต่อเนื่อง"

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

สำหรับภาษาที่มีทรัพยากรต่ำ (Low-resource language) วงจรนี้จะมีคุณค่าเป็นพิเศษ เนื่องจากในเมื่อไม่มีข้อมูลสำหรับการประเมินที่เพียงพอตั้งแต่ต้น จึงไม่มีทางเลือกอื่นนอกจากต้องพัฒนาการประเมินไปพร้อมกับการใช้งานจริงโดยอาศัยผลตอบรับจากหน้างาน หากติดตามการเปลี่ยนแปลงของอัตราการแทรกแซง (Intervention rate) ก็จะเห็นได้ว่าสามารถลดการพึ่งพามนุษย์ลงได้มากน้อยเพียงใดตามการปรับปรุงที่เกิดขึ้น ซึ่งจะช่วยให้สามารถอธิบายความคืบหน้าของระบบอัตโนมัติได้อย่างเป็นรูปธรรม การวางตำแหน่งให้การประเมินเป็นภารกิจต่อเนื่องเพื่อรักษาคุณภาพ แทนที่จะเป็นเพียงด่านตรวจสอบชั่วคราว คือรากฐานสำคัญที่จะทำให้การดำเนินงานจริงมีความเสถียร

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

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

ความคลาดเคลื่อนนี้มักจะรุนแรงยิ่งขึ้นในภาษาที่มีทรัพยากรต่ำ (Low-resource language) สำหรับภาษาลาว ภาระในการจัดเตรียมข้อมูลสำหรับการประเมินด้วยตนเองนั้นมีสูง จึงมักโน้มเอียงไปทางกรณีทั่วไปที่สร้างได้ง่าย และละเลยกรณีที่ยากลำบาก ส่งผลให้ชุดข้อมูลสำหรับการประเมินเป็นตัวแทนของ "ด้านที่ง่าย" ของการกระจายตัวในการใช้งานจริงเท่านั้น

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

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

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

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

Q: การประเมิน AI Agent ภาษาลาว สามารถใช้วิธีการประเมินสำหรับภาษาอังกฤษได้เลยหรือไม่? A: แนวคิดของกรอบการทำงานสามารถนำมาใช้ร่วมกันได้ แต่ต้องระมัดระวังในการนำมาปรับใช้โดยตรง ภาษาอังกฤษมีข้อมูลการประเมินและแนวปฏิบัติในการตัดสินที่หลากหลายซึ่งสามารถใช้เป็นพื้นฐานได้ แต่สำหรับภาษาลาวนั้นทรัพยากรที่เทียบเท่ากันยังมีจำกัด จึงมักจำเป็นต้องจัดเตรียมชุดข้อมูลการประเมินและเกณฑ์มาตรฐานขึ้นมาเอง นอกจากนี้ การใช้โทเค็น (Token) และความเสถียรของการประมวลผลล่วงหน้า (Preprocessing) ยังแตกต่างกันไปตามแต่ละภาษา ดังนั้น การใช้โครงสร้างวิธีการประเมินเดิมแต่สร้างข้อมูลและเกณฑ์มาตรฐานใหม่ให้เหมาะกับภาษาลาวจึงเป็นแนวทางที่สมเหตุสมผลกว่า

Q: ระหว่างอัตราความสำเร็จของงาน (Task Completion Rate), ความแม่นยำหลายภาษา (Multilingual Accuracy) และอัตราการแทรกแซงโดยมนุษย์ (HITL Intervention Rate) ควรให้ความสำคัญกับสิ่งใดก่อน? A: ไม่ควรเลือกเพียงอย่างใดอย่างหนึ่ง แต่ควรพิจารณาโดยใช้ทั้ง 3 แกนร่วมกัน หากจำเป็นต้องเลือกจุดเริ่มต้น อัตราความสำเร็จของงานซึ่งแสดงถึงความสามารถในการดำเนินงานให้เสร็จสิ้นจะเป็นแกนหลัก แต่ต้องตรวจสอบด้วยอัตราการแทรกแซงโดยมนุษย์ (HITL) ว่างานนั้นสำเร็จได้โดยไม่ต้องพึ่งพาการแทรกแซงจากมนุษย์มากเกินไปหรือไม่ และใช้ความแม่นยำหลายภาษาเพื่อดูว่ามีความผิดพลาดที่เกิดจากตัวภาษาลาวเองหรือไม่ ทั้งสามส่วนนี้มีความสัมพันธ์ในการเติมเต็มซึ่งกันและกัน การจะให้ความสำคัญกับแกนใดมากกว่ากันนั้น ควรปรับเปลี่ยนตามระดับความเสี่ยงที่ยอมรับได้ของธุรกิจ

Q: ควรตั้งเกณฑ์มาตรฐาน (Threshold) สำหรับการนำไปใช้งานจริงไว้ที่เท่าใด? A: ไม่มีค่ามาตรฐานที่ตายตัว เกณฑ์ดังกล่าวควรคำนวณย้อนกลับจากลักษณะของงานและระดับความเสี่ยงที่ยอมรับได้ ในงานที่ความผิดพลาดส่งผลเสียโดยตรงต่อผู้ใช้ จำเป็นต้องกำหนดเกณฑ์อัตราความสำเร็จที่เข้มงวดและแทบไม่ยอมให้เกิดความคลาดเคลื่อน ในขณะที่หากเป็นระบบที่มีการตรวจสอบโดยมนุษย์ในขั้นตอนถัดไปเสมอ ก็สามารถออกแบบโดยผ่อนปรนเกณฑ์ของตัว Agent ลงแล้วใช้การแทรกแซงจากมนุษย์เข้ามาเสริมได้ แนวทางที่เหมาะสมคือการเริ่มจากการประเมินนำร่อง (Pilot Evaluation) เพื่อเก็บข้อมูลจริง แล้วจึงปรับระดับให้เหมาะสมกับองค์กรของตนเอง

Q: ในขั้นตอนที่มีข้อมูลการประเมินน้อย สามารถตัดสินใจนำไปใช้งานจริงได้หรือไม่? A: สามารถเริ่มจากข้อมูลจำนวนน้อยได้ แต่เพื่อให้เกิดความปลอดภัยควรเพิ่มความเข้มข้นในการประเมินนำร่องและการแทรกแซงโดยมนุษย์ (HITL) เนื่องจากเป็นการยากที่จะเตรียมข้อมูลการประเมินที่สมบูรณ์แบบตั้งแต่ต้น จึงควรเริ่มจากการประเมินด้วยข้อมูลคุณภาพสูงจำนวนน้อย และในระหว่างที่เริ่มใช้งานในขอบเขตจำกัด ให้รวบรวมกรณีความผิดพลาดที่เกิดขึ้นจริงเพื่อนำไปเพิ่มในชุดข้อมูลการประเมินอย่างต่อเนื่อง หากตั้งอยู่บนพื้นฐานของการค่อยๆ ขยายขอบเขตการทำงานอัตโนมัติไปพร้อมกับการพัฒนาการประเมิน ก็สามารถตัดสินใจนำไปใช้งานจริงอย่างระมัดระวังได้แม้ข้อมูลจะยังไม่ครบถ้วนสมบูรณ์