ข้ามไปยังเนื้อหาหลัก

การประเมินผล MT

สรุปสำหรับผู้บริหาร หน้านี้กำหนดเกณฑ์การส่งผลงานเข้าสู่ leaderboard เมตริกการให้คะแนน (chrF++, FST acceptance, exact match, equivalent match, semantic score) นโยบายป้องกันการโกง ระดับการตรวจสอบ และขั้นตอนการส่งผลงาน วิธีการที่ถูกเปิดเผยต่อข้อมูลการประเมินจะถูกตัดสิทธิ์

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

Leaderboard​

จุดศูนย์กลางคือ Method Leaderboard — กระดานคะแนนแบบสดที่ขับเคลื่อนด้วย Supabase ซึ่งนักวิจัยและสมาชิกชุมชนสามารถส่งและเปรียบเทียบวิธีการแปลด้วยการประเมินที่มีลายนิ้วมือและทำซ้ำได้

การส่งผลงานทุกครั้งประกอบด้วย:

  • Pipeline ที่มีลายนิ้วมือ — ผูกกับ Git commit และ config hash ที่เฉพาะเจาะจง เพื่อให้ผลลัพธ์สามารถย้อนกลับไปยังโค้ดที่แน่นอนที่สร้างผลลัพธ์นั้น
  • ชุดข้อมูลที่มีเวอร์ชัน — มีการแฮชเนื้อหาและกำหนดเวอร์ชัน คะแนนสามารถเปรียบเทียบได้เฉพาะภายในเวอร์ชันชุดข้อมูลเดียวกันเท่านั้น
  • เมตริกมาตรฐาน — การให้คะแนนทั้งหมดคำนวณโดย evaluation harness ที่ใช้ร่วมกัน เพื่อขจัดความแตกต่างในการนำไปใช้งาน
  • ระดับความน่าเชื่อถือ — self-benchmarked, GDS Verified หรือ Community Validated
  • การติดตามต้นทุน — ต้นทุน API ต่อการส่งผลงาน เพื่อให้การแลกเปลี่ยนระหว่างต้นทุนและคุณภาพโปร่งใส

ปัจจุบัน leaderboard ติดตามเมตริกห้าตัว โดยสามตัวใช้ได้กับทุกภาษา และสองตัวพร้อมใช้งานสำหรับ Plains Cree และจะถูกขยายออกไปในอนาคต:

เมตริกประเภทสิ่งที่วัด
chrF++Character n-gram F-scoreเมตริกคุณภาพหลัก — มีความสัมพันธ์ที่ดีกับการตัดสินของมนุษย์ โดยเฉพาะสำหรับภาษาที่มีความซับซ้อนทางสัณฐานวิทยา
Exact Matchสัดส่วนของการจับคู่ที่สมบูรณ์แบบความแม่นยำเข้มงวด — บ่อยแค่ไหนที่การแปลตรงกับมาตรฐานทองคำพอดี
FST Acceptanceอัตราการผ่านด่านสัณฐานวิทยาสำหรับวิธีการที่มีการตรวจสอบด้วย finite-state transducer — ผลลัพธ์กี่สัดส่วนที่ถูกต้องทางสัณฐานวิทยา
Equivalent Matchอัตราตัวแปรที่ยอมรับได้เศษส่วนที่ตรงกับข้อมูลอ้างอิงหรือตัวแปรที่ยอมรับได้ (ลำดับคำ, แบบแผนการสะกด) ปัจจุบันใช้กับ CRK กำลังขยาย
Semantic Scoreความซื่อสัตย์ทางความหมายการรักษาความหมาย — การแปลถ่ายทอดความหมายที่ตั้งใจไว้โดยไม่คำนึงถึงรูปแบบพื้นผิวหรือไม่ ปัจจุบันใช้กับ CRK กำลังขยาย

:::info ชุดเมตริกครบถ้วน ข้อกำหนดการให้คะแนน กำหนดรายการเมตริกครบถ้วน 19 ตัวใน 5 หมวดหมู่ สูตรคะแนนรวม ตารางน้ำหนัก และเกณฑ์ระดับคุณภาพ :::

→ ดู leaderboard

ชุดข้อมูลที่มีให้ใช้งาน​

EDTeKLA Development Set v1​

ชุดข้อมูลการประเมินชุดแรก สร้างขึ้นสำหรับการแปล English→Plains Cree (SRO) สร้างโดย กลุ่มวิจัย EdTeKLA ที่ University of Alberta

คุณสมบัติค่า
IDedtekla-dev-v1
คู่ภาษาEN → CRK (Plains Cree, SRO orthography)
จำนวนรายการ404 (master_corpus.json: 62 gold + 342 textbook); รวม 548 รายการที่มีให้ใช้งาน
สัญญาอนุญาตCC BY-NC-SA 4.0
แหล่งที่มาgold_standard (ตรวจสอบโดยผู้พูดภาษา), textbook (สื่อการศึกษาที่ตีพิมพ์แล้ว)

FLORES+ Devtest — สำหรับการพัฒนาเท่านั้น​

[!WARNING] FLORES+ มีให้ใช้งานสำหรับการพัฒนาและการดีบักเท่านั้น และไม่ได้ใช้สำหรับการประเมิน leaderboard อย่างเป็นทางการ FLORES+ (เดิมคือ Meta FLORES-200) เป็นชุดข้อมูลเกณฑ์มาตรฐานที่เปิดเผยต่อสาธารณะอย่างกว้างขวาง ซึ่ง LLM ชั้นนำเกือบแน่นอนว่าได้รับการฝึกอบรมบนชุดข้อมูลนี้ คะแนนที่ได้จาก FLORES+ ไม่ได้สะท้อนคุณภาพการแปลในโลกจริงสำหรับวิธีการที่ใช้ LLM อย่างน่าเชื่อถือ วิธีการที่ไม่ใช่ LLM (FST, rule-based, fine-tuned NMT) ได้รับผลกระทบน้อยกว่า แต่คะแนน FLORES+ ก็ยังไม่ถูกเผยแพร่ไปยัง leaderboard

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

ดู ชุดข้อมูลการประเมิน สำหรับ schema ชุดข้อมูลครบถ้วน ระดับความยาก และวิธีสร้างชุดข้อมูลของคุณเอง

:::danger ห้ามฝึกอบรมบนข้อมูลการประเมิน

ชุดข้อมูลเหล่านี้มีไว้สำหรับการประเมินเท่านั้น วิธีการที่ได้รับการฝึกอบรม fine-tuned, few-shot-prompted หรือถูกเปิดเผยต่อข้อมูลการประเมินในรูปแบบใดก็ตาม จะให้คะแนนที่สูงเกินจริงและจะ ถูกตัดสิทธิ์จาก leaderboard

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

หากคุณใช้ข้อมูล coaching หรือตัวอย่าง few-shot ข้อมูลเหล่านั้นต้องมาจาก แหล่งที่แยกต่างหากโดยสิ้นเชิง หากไม่แน่ใจ อย่านำมาใช้ :::

:::warning ความไม่แน่นอนของ LLM

ผลลัพธ์ของ LLM มีความไม่แน่นอน คะแนนแสดงถึงการวัดในช่วงเวลาหนึ่งภายใต้เวอร์ชันโมเดลและการกำหนดค่า API ที่เฉพาะเจาะจง ผู้ให้บริการโมเดลอาจอัปเดตน้ำหนัก กลยุทธ์การถอดรหัส หรือตัวกรองความปลอดภัยได้ตลอดเวลา ซึ่งอาจทำให้คะแนนเปลี่ยนแปลงระหว่างการรัน leaderboard บันทึก model slug และ timestamp ที่แน่นอนสำหรับการส่งผลงานทุกครั้ง :::

สิ่งที่ทำให้วิธีการดี​

วิธีการไม่ได้ถูกสร้างมาเท่าเทียมกัน นี่คือสิ่งที่แยกแยะงานที่เข้มงวดออกจากคะแนนที่สูงเกินจริง

ลักษณะของวิธีการที่แข็งแกร่ง​

  • การแยกข้อมูลฝึกอบรมและข้อมูลประเมินอย่างชัดเจน — วิธีการของคุณไม่เคยเห็นชุดข้อมูลการประเมินในระหว่างการพัฒนา การปรับแต่ง การออกแบบ prompt หรือการเลือกตัวอย่าง few-shot
  • ทำซ้ำได้ — ผู้อื่นสามารถ clone repository ของคุณ รัน harness และได้คะแนนเดียวกัน (ภายในขอบเขตความไม่แน่นอนของ LLM)
  • มีเอกสารประกอบ — method card ของคุณอธิบายสิ่งที่วิธีการทำ เครื่องมือที่ใช้ และข้อจำกัดของมัน
  • ซื่อสัตย์เกี่ยวกับขอบเขต — หากวิธีการของคุณใช้ได้กับคู่ภาษาเดียว ให้ระบุ หากมีประสิทธิภาพลดลงในรูปแบบสัณฐานวิทยาบางอย่าง ให้บันทึกไว้
  • ตระหนักถึงชุมชน — สำหรับภาษาพื้นเมือง วิธีการของคุณเคารพอธิปไตยของข้อมูล คุณได้ปรึกษากับชุมชนภาษาหรือใช้เฉพาะข้อมูลที่มีสัญญาอนุญาตแบบเปิด

สัญญาณเตือน (สิ่งที่ทำให้ถูกตัดสิทธิ์)​

สัญญาณเตือนเหตุใดจึงเป็นปัญหา
การฝึกอบรมบนข้อมูลการประเมินทำลายจุดประสงค์ของการประเมินโดยสิ้นเชิง คะแนนที่สูงเกินจริงทำให้ทุกคนเข้าใจผิด
การเลือกผลลัพธ์ที่ดีที่สุดการรัน 10 ครั้งและส่งผลลัพธ์ที่ดีที่สุดโดยไม่เปิดเผยผลลัพธ์อื่น
การประมวลผลภายหลังที่ไม่เปิดเผยการแก้ไขผลลัพธ์ด้วยตนเองก่อนการให้คะแนน
ข้อมูล coaching ที่ปนเปื้อนการใช้ตัวอย่างจากชุดข้อมูลการประเมินเป็น few-shot prompts หรือรายการพจนานุกรม
การอ้างความพร้อมเชิงพาณิชย์โดยไม่มีแหล่งที่มาหากวิธีการของคุณใช้ข้อมูล CC BY-NC-SA แสดงว่าไม่พร้อมสำหรับการใช้งานเชิงพาณิชย์

ระดับการตรวจสอบ​

ระดับการตรวจสอบอธิบาย ว่าใครเป็นผู้ตรวจสอบผลลัพธ์ — แยกจากระดับคุณภาพ (Baseline → Fluent) ที่กำหนดไว้ใน ข้อกำหนดการให้คะแนน §5 ซึ่งอธิบายความหมายของคะแนนรวมอัตโนมัติ

ระดับความหมายวิธีรับ
Self-benchmarkedคุณรัน harness เองและส่งผลลัพธ์เปิด PR พร้อม run card ของคุณ
GDS Verifiedผู้ดูแล champollion ทำซ้ำผลลัพธ์ของคุณส่งวิธีการของคุณในรูปแบบ installable plugin
Community Validatedองค์กรกำกับดูแลรันกับ gold-standard และผ่านการตรวจสอบจากชุมชนส่งโค้ดวิธีการไปยังองค์กรกำกับดูแล

วิธีการส่งผลงาน​

  1. สร้างวิธีการของคุณ — ดู การสร้างวิธีการ สำหรับ interface ของวิธีการ
  2. รัน harness — ดู Eval Harness สำหรับการตั้งค่าและการใช้งาน
  3. สร้าง run card — harness จะสร้าง JSON run card พร้อมคะแนน ลายนิ้วมือ และ metadata ของคุณ
  4. เปิด PR — ส่ง run card ของคุณไปยัง eval harness repository
  5. ปรากฏบน leaderboard — เมื่อ merge แล้ว ผลลัพธ์ของคุณจะปรากฏบน Method Leaderboard

ทิศทางในอนาคต​

  • การรันเปรียบเทียบโมเดลอย่างครอบคลุม — การประเมินอย่างเป็นระบบของโมเดลชั้นนำ (GPT-4o, Claude, Gemini ฯลฯ) ในภาษาต่างๆ ของ champollion โดยใช้คลังข้อมูลการประเมินที่กำหนดเอง (ไม่ใช่เกณฑ์มาตรฐานสาธารณะ)
  • คู่ภาษาเพิ่มเติม — Quechua, Inuktitut และภาษาที่มีทรัพยากรน้อยอื่นๆ เมื่อชุดข้อมูลที่ตรวจสอบโดยชุมชนพร้อมใช้งาน
  • การนำเข้าชุดข้อมูล — เครื่องมือสำหรับแปลงชุดข้อมูลการประเมินภายนอก (WMT, Tatoeba ฯลฯ) ให้เป็นรูปแบบการประเมินของ champollion
  • การรันซ้ำอัตโนมัติ — การตรวจจับการเปลี่ยนแปลงเวอร์ชันโมเดลและการรัน benchmark ซ้ำเพื่อติดตามการเปลี่ยนแปลงของคะแนน

ดูเพิ่มเติม​