ข้อกำหนดการให้คะแนน

สรุปสำหรับผู้บริหาร เอกสารนี้คือแหล่งข้อมูลหลักแหล่งเดียวสำหรับเมตริกการประเมินทั้งหมด การให้คะแนนแบบผสม ระดับคุณภาพ และการวิเคราะห์ต้นทุนในระบบนิเวศการประเมิน MT ของ Champollion เมตริกการประเมินเฉพาะภาษา ได้แก่ ความถูกต้องทางสัณฐานวิทยาด้วย FST คลาสความเท่าเทียมของ linter และการตรวจสอบความหมายแบบ deterministic รวมเรียกว่า LYSS (Linguistically-informed Yield & Structural Scoring) เมตริกทุกตัวที่คำนวณโดย harness น้ำหนักทุกค่าในสูตรผสม และเกณฑ์ระดับทุกค่าถูกกำหนดไว้ที่นี่ — และที่นี่เท่านั้น โค้ด เอกสาร และ database schema ล้วนอ้างอิงจากเอกสารนี้ หากมีความขัดแย้ง เอกสารนี้มีอำนาจสูงสุด

ขอบเขต เอกสารนี้กำหนด สิ่งที่เราวัด และ วิธีการให้คะแนน ไม่ได้กำหนด schema ของ run card (ดู BENCHMARK_SPEC §3) โปรโตคอล benchmark (BENCHMARK_SPEC §6) หรือกฎของ leaderboard (ดูเอกสาร arena) เอกสารเหล่านั้นอ้างอิงเอกสารนี้สำหรับนิยามเมตริกและตรรกะการให้คะแนน

อัปเดตล่าสุด: 2026-06-07

1. ปรัชญาการให้คะแนน

1.1 ปรัชญา Microeval

"หากเรามุ่งเน้นเฉพาะสิ่งที่สามารถนำไปใช้ได้ทั่วไป เราจะลืมสิ่งที่ทำไม่ได้อย่างหลีกเลี่ยงไม่ได้ — และสูญเสียภาษาเหล่านั้นพร้อมกับความรู้และภูมิปัญญาทั้งหมด"

โครงการนี้ใช้แนวทาง microeval development: การสร้างเมตริกการประเมินที่ปรับแต่งสำหรับภาษาเฉพาะโดยใช้เครื่องมือทางภาษาศาสตร์ที่ดีที่สุดที่มีอยู่ ได้แก่ finite-state transducer พจนานุกรมสองภาษา ตัววิเคราะห์สัณฐานวิทยา และกฎความเท่าเทียมที่นักภาษาศาสตร์คัดสรร แนวทางนี้ตรงข้ามกับกระบวนทัศน์หลักในการประเมิน MT ซึ่งมุ่งหาเมตริกสากลที่ใช้ได้กับทุกภาษา เมตริกสากลมีคุณค่า แต่อ่อนแอที่สุดในจุดที่ต้องการมากที่สุด: สำหรับภาษาที่มีสัณฐานวิทยาซับซ้อน ข้อมูลการฝึกจำกัด และไม่มีตัวแทนในชุดข้อมูลฝึก neural metric

เราไม่ได้ขาดความก้าวหน้าในการแปลด้วยเครื่องสำหรับภาษาต่าง ๆ ของโลกเพียงเพราะขาด corpus เท่านั้น แต่เพราะ เราไม่รู้ด้วยซ้ำว่าความก้าวหน้าหน้าตาเป็นอย่างไร — เราขาดเครื่องมือประเมินอัตโนมัติเพื่อวัดว่าระบบแปลกำลังพัฒนาขึ้นหรือไม่ LYSS คือความพยายามของเราในการสร้างเครื่องมือเหล่านั้น ทีละภาษา โดยใช้ทรัพยากรทางภาษาศาสตร์ที่มีอยู่

1.2 เมตริกอัตโนมัติเป็นเพียงตัวแทน

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

1.3 การออกแบบแบบหลายสัญญาณ

ไม่มีเมตริกใดตัวเดียวที่สามารถวัดคุณภาพการแปลได้ครบถ้วน การแปลอาจมีค่า chrF++ overlap ที่สมบูรณ์แบบแต่ล้มเหลวการตรวจสอบสัณฐานวิทยา อาจผ่านการตรวจสอบ FST แต่มีความหมายผิด หรืออาจถูกต้องทางความหมายแต่แปลกแยกทางสไตล์สำหรับภาษาเป้าหมาย คะแนนผสมในหัวข้อ §4 รวบรวมสัญญาณอิสระหลายตัว แต่ละตัวจับมิติคุณภาพที่แตกต่างกัน

1.4 ความสามารถในการขยาย

รายการเมตริกนี้ไม่ได้ปิดตาย ภาษาใหม่นำมาซึ่งข้อกำหนดใหม่: ความถูกต้องของโทนเสียงสำหรับภาษาวรรณยุกต์ ความแม่นยำของเครื่องหมายกำกับเสียงสำหรับอักษร Semitic ความถูกต้องของ syllabary สำหรับ Cree สถาปัตยกรรม (โปรโตคอล MetricPlugin, composite แบบถ่วงน้ำหนักพร้อม re-normalization) ออกแบบมาให้เพิ่มเมตริกได้โดยไม่ทำลายคะแนนที่มีอยู่ เมตริกเฉพาะภาษา (เช่น linter และ semantic validator ของ CRK) ถูกประกาศบน language card ภายใต้ evalMetrics และโหลดจาก eval_standards/ — harness มาพร้อมกับเมตริกพฤติกรรมทั่วไปเท่านั้น (code-switching, hallucination, terminology)

1.5 สามมิติของการประเมิน

ทุก run card วัดสามมิติอิสระ:

Quality   — How good is the translation?   (composite score, §4)
Cost      — How much does it cost?          (cost metrics, §6)
Speed     — How fast does it run?           (speed metrics, §7)

มิติเหล่านี้เป็นแกนอิสระ วิธีการหนึ่งอาจมีคุณภาพสูงแต่มีต้นทุนสูง รวดเร็วแต่ไม่แม่นยำ หรือผสมผสานใด ๆ ก็ได้ leaderboard รองรับการเรียงลำดับตามมิติใดก็ได้ คะแนนที่ปรับตามต้นทุน (§6.3) เป็นเมตริกเดียวที่รวมมิติต่าง ๆ เข้าด้วยกัน

1.6 สถานะการตรวจสอบความถูกต้อง

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

ระดับการตรวจสอบ	ความหมาย	เมตริกปัจจุบัน
✅ ตรวจสอบจากภายนอกแล้ว	มีการศึกษาความสัมพันธ์กับมนุษย์ที่เผยแพร่แล้ว (WMT, บทความวิชาการ)	`chrf_plus_plus`, `bleu`, `comet_score`
⚡ ตรวจสอบแบบ proxy	ตรวจสอบแล้วสำหรับภาษาที่มีทรัพยากรสูง แต่ยังไม่ได้ตรวจสอบสำหรับ LRL เป้าหมาย	`comet_score` (ตรวจสอบแล้วสำหรับคู่ภาษา EU แต่ไม่ใช่สำหรับ CRK)
🔶 Heuristic ทางวิศวกรรม	ออกแบบจากหลักการทางภาษาศาสตร์หรือรูปแบบความล้มเหลวที่สังเกตได้ ไม่มีข้อมูลความสัมพันธ์กับมนุษย์	`fst_acceptance_rate`, `equivalent_match_rate`, `semantic_score`, `code_switching_rate`, `hallucination_rate`, `terminology_adherence`
🔲 ยังไม่ได้ตรวจสอบ	ยังไม่ได้ทดสอบกับข้อมูลใด ๆ	`morphological_accuracy`, `orthographic_accuracy`, `consistency_score`

ความหมายในทางปฏิบัติ คะแนนผสม (§4) รวบรวมเมตริกในทุกระดับการตรวจสอบ นี่เป็นการเลือกออกแบบอย่างชัดเจน: เราเชื่อว่า heuristic ทางวิศวกรรมที่มีพื้นฐานทางโครงสร้าง (การยอมรับ FST) ให้ข้อมูลมากกว่าสำหรับภาษา polysynthetic มากกว่า neural metric ที่ตรวจสอบแล้วเฉพาะกับคู่ภาษายุโรป (COMET) แต่เราไม่ได้พิสูจน์สิ่งนี้ คะแนนผสมควรถือเป็น การประมาณทางวิศวกรรม ไม่ใช่การวัดคุณภาพที่ผ่านการตรวจสอบ จนกว่าการศึกษาความสัมพันธ์กับมนุษย์จะเสร็จสมบูรณ์สำหรับแต่ละภาษาเป้าหมาย

การทดลองตรวจสอบที่จำเป็น (ดู mt-evaluation-landscape.md §6 และ speaker-validation.md):

การศึกษาความสัมพันธ์กับการตัดสินของมนุษย์: คู่ประโยค 200+ คู่ที่ประเมินโดยผู้พูดสองภาษา 3+ คน

การวัดอัตราการปฏิเสธผิดพลาดของ FST บน corpus ที่เป็นตัวแทน

การนำไปใช้กับภาษาที่สอง (North Sámi) เพื่อทดสอบการนำไปใช้ทั่วไป

การเปรียบเทียบโดยตรงกับ COMET บนข้อมูลเดียวกัน

2. รายการเมตริก

เมตริกจัดเป็นสี่หมวดหมู่ แต่ละเมตริกมีสถานะการนำไปใช้งาน มาตราส่วน และระดับ (ต่อรายการ ระดับ corpus หรือทั้งสองอย่าง)

2.1 เมตริกพื้นผิว

เมตริกพื้นผิวเปรียบเทียบการแปลที่ทำนายกับการแปลอ้างอิงในระดับสตริง ไม่ต้องการเครื่องมือทางภาษาศาสตร์ — เพียงแค่การเปรียบเทียบสตริง

ID	เมตริก	สถานะ	มาตราส่วน	ระดับ	การนำไปใช้งาน
`exact_match_rate`	Exact Match	✅ นำไปใช้งานแล้ว	0.0–1.0	ทั้งสอง	แบบ Binary: ผลลัพธ์ที่ทำนาย == อ้างอิงหรือไม่? อัตรา corpus = จำนวนที่ตรงกัน / ทั้งหมด
`equivalent_match_rate`	Equivalent Match	⚡ บางส่วน	0.0–1.0	ทั้งสอง	ผลลัพธ์ที่ทำนายตรงกับตัวแปรที่ยอมรับได้ใด ๆ หรือไม่? สำหรับ CRK: นำไปใช้งานผ่าน `CrkLinterMetric` ของมาตรฐาน eval ของ CRK (ใน `eval_standards/crk/`) โดยใช้กฎคลาสตัวแปรแบบ deterministic (ลำดับคำ การสะกด อนุภาคเสริม คำพ้องความหมาย ความกำกวมของ progressive) โหลดอัตโนมัติผ่านการประกาศ `evalMetrics` ของ language card ของ CRK การนำไปใช้งานข้ามภาษาทั่วไปต้องการ `variants[]` ต่อรายการใน corpus
`chrf_plus_plus`	chrF++	✅ นำไปใช้งานแล้ว	0–100	ทั้งสอง	Character n-gram F-score (sacrebleu) ทนทานต่อการเปลี่ยนแปลงทางสัณฐานวิทยา เมตริกพื้นผิวหลักสำหรับภาษา agglutinative/polysynthetic ต่อรายการใช้ `sentence_chrf`; corpus ใช้ `corpus_chrf`
`bleu`	BLEU	✅ นำไปใช้งานแล้ว	0–100	Corpus	ความแม่นยำ word-level n-gram (sacrebleu) ไม่รวมในผสม — การให้คะแนนระดับคำลงโทษการเปลี่ยนแปลงทางสัณฐานวิทยาอย่างไม่เป็นธรรม คำนวณและรายงานเพื่อความเข้ากันได้กับวรรณกรรม MT
`ter`	Translation Edit Rate	✅ นำไปใช้งานแล้ว	0–∞ (ยิ่งต่ำยิ่งดี)	ทั้งสอง	ระยะทางแก้ไขขั้นต่ำระหว่างผลลัพธ์ที่ทำนายและอ้างอิง ปรับตามความยาวอ้างอิง (sacrebleu `corpus_ter`) คำนวณควบคู่กับ chrF++ และ BLEU ไม่รวมในผสม — มีความสัมพันธ์กับ chrF++ ดังนั้นการรวมทั้งสองจะนับซ้ำความคล้ายคลึงพื้นผิว
`length_ratio`	Length Ratio	✅ นำไปใช้งานแล้ว	0–∞ (1.0 คือค่าอุดมคติ)	ทั้งสอง	`len(predicted) / len(reference)` ในหน่วยอักขระ ตรวจจับการตัดทอน (<0.5) และการขยาย/hallucination (>2.0) เฉลี่ยข้ามรายการในระดับ corpus

2.2 เมตริกโครงสร้าง

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

ID	เมตริก	สถานะ	มาตราส่วน	ระดับ	การนำไปใช้งาน
`fst_acceptance_rate`	FST Acceptance	✅ นำไปใช้งานแล้ว	0.0–1.0	ทั้งสอง	สัดส่วนของคำในผลลัพธ์ที่ได้รับการยอมรับโดย finite-state transducer (GiellaLT) คำหนึ่งถือว่า "ถูกต้อง" หาก FST ส่งคืนการวิเคราะห์สัณฐานวิทยาอย่างน้อยหนึ่งรายการ ใช้ได้กับภาษาใด ๆ ที่มีตัววิเคราะห์ `.hfstol` ของ GiellaLT
`morphological_accuracy`	Morphological Accuracy	🔲 วางแผนแล้ว	0.0–1.0	ทั้งสอง	คำหนึ่งอาจถูกต้องตาม FST แต่มีการผันคำผิด (รากถูกต้อง คำต่อท้ายผิด) เมตริกนี้เปรียบเทียบการวิเคราะห์ FST ของคำที่ทำนายกับคุณลักษณะสัณฐานวิทยาที่คาดหวัง ต้องการคำอธิบายสัณฐานวิทยาต่อรายการใน corpus
`orthographic_accuracy`	Orthographic Accuracy	🔲 วางแผนแล้ว	0.0–1.0	ทั้งสอง	ตรวจสอบความถูกต้องเฉพาะอักษร: การใช้ macron/circumflex ของ SRO สำหรับ Cree เครื่องหมายกำกับเสียงสำหรับ Inuktitut เครื่องหมายความยาวสระสำหรับ Ojibwe ชุดกฎต่อภาษา

เหตุใดเมตริกโครงสร้างจึงสำคัญ OMT-1600 ของ Meta — ระบบ MT ที่ใหญ่ที่สุดที่เคยเผยแพร่ (1,600 ภาษา) — ประเมินด้วย ChrF++, xCOMET, MetricX และ BLASER 3 ไม่มีตัวใดตรวจสอบความถูกต้องทางสัณฐานวิทยา ChrF++ วัดการทับซ้อนของ character n-gram: ให้รางวัลสตริงที่ ดูเหมือน ภาษาเป้าหมาย สำหรับภาษา polysynthetic หมายความว่าคำที่ไม่ถูกต้องทางสัณฐานวิทยาซึ่งมีอักขระร่วมกับอ้างอิงจำนวนมากจะได้คะแนนดี เมตริก FST acceptance ของเราเป็นการทดสอบโครงสร้างแบบ binary: คำนั้นเป็นรูปแบบที่ถูกต้องในภาษาหรือไม่ ไม่มีกรอบการประเมิน MT อื่นใดที่ให้สิ่งนี้ในระดับขนาดใหญ่

2.3 เมตริกความหมาย

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

ID	เมตริก	สถานะ	มาตราส่วน	ระดับ	การนำไปใช้งาน
`semantic_score`	Semantic Similarity	⚡ บางส่วน	0.0–1.0	ทั้งสอง	CRK: คะแนนถ่วงน้ำหนักตาม verdict จาก `CrkSemanticMetric` ของมาตรฐาน eval ของ CRK (ใน `eval_standards/crk/`, proxy) ทั่วไป: cosine similarity ของ sentence embedding (ต้นทาง + ทำนาย เทียบกับ ต้นทาง + อ้างอิง) โมเดล TBD — ต้องรองรับภาษาที่มีทรัพยากรต่ำ ซึ่งตัดโมเดล embedding ที่เน้นภาษาอังกฤษส่วนใหญ่ออก
`comet_score`	COMET	✅ นำไปใช้งานแล้ว	~0.0–1.0	ทั้งสอง	เมตริกการประเมิน MT แบบเรียนรู้ (Unbabel) ฝึกบนการตัดสินคุณภาพของมนุษย์ ไม่รวมในผสม — ข้อมูลการฝึกมีอคติต่อภาษายุโรปที่มีทรัพยากรสูง คะแนนสำหรับ LRL ไม่น่าเชื่อถือ คำนวณเมื่อติดตั้ง `unbabel-comet` รายงานพร้อมแฟล็กเตือนทรัพยากรต่ำ สำหรับ 35 ภาษาแอฟริกัน harness จะเลือก AfriCOMET (`masakhane/africomet-mtl`) อัตโนมัติผ่าน `resolve_comet_model()` ซึ่งมีความสัมพันธ์กับการตัดสินของมนุษย์ที่ดีกว่าสำหรับภาษาเหล่านั้น

เหตุใด COMET จึงไม่รวมในผสม COMET ฝึกบนข้อมูลการประเมินมนุษย์ของ WMT ซึ่งส่วนใหญ่เป็นคู่ภาษายุโรปที่มีทรัพยากรสูง เมื่อนำไปใช้กับ Plains Cree หรือ LRL อื่น ๆ การแสดงภายในของโมเดลไม่มีการสัมผัสกับภาษาเหล่านั้น — มันกำลังประมาณจากภาษาที่มีระบบสัณฐานวิทยาแตกต่างกันโดยพื้นฐาน คะแนนยังคงมีประโยชน์ในทิศทาง (COMET สูงกว่า ≈ ผลลัพธ์ที่ฟังดูคล่องแคล่วกว่าโดยทั่วไป) แต่ค่าสัมบูรณ์ไม่ได้ถูกปรับเทียบ เรารายงาน COMET เพื่อความโปร่งใสแต่ไม่ให้มันมีอิทธิพลต่อคะแนนผสมจนกว่าเราจะสามารถตรวจสอบกับการตัดสินของมนุษย์สำหรับแต่ละภาษาเป้าหมาย

AfriCOMET สำหรับภาษาแอฟริกัน language card แต่ละใบมีฟิลด์ metricModelSupport (ดูข้อกำหนด language card §9) ที่ประกาศว่าโมเดล COMET เฉพาะทางใดได้รับการฝึกสำหรับภาษานั้น สำหรับ 35 ภาษาแอฟริกัน (yor, hau, ibo, amh, swa ฯลฯ) card ประกาศ AfriCOMET (masakhane/africomet-mtl) — โมเดล COMET ที่ fine-tune บนการตัดสินของมนุษย์สำหรับ MT ภาษาแอฟริกันโดยชุมชน Masakhane harness เลือกโมเดลที่แนะนำอัตโนมัติผ่าน resolve_comet_model() ที่อ่านจาก language card แต่สามารถแทนที่ได้ด้วย --comet-model การเพิ่มการแมปภาษา→โมเดลใหม่ทำได้โดยการเพิ่มข้อมูลใน language card (ไม่ใช่การแก้ไขโค้ด Python)

2.4 เมตริกพฤติกรรม

เมตริกพฤติกรรมตรวจจับรูปแบบความล้มเหลวเฉพาะในผลลัพธ์การแปล ไม่ได้วัดคุณภาพโดยตรง — แต่ตรวจจับปัญหา

ID	เมตริก	สถานะ	มาตราส่วน	ระดับ	การนำไปใช้งาน
`code_switching_rate`	Code-Switching Rate	✅ นำไปใช้งานแล้ว	0.0–1.0 (ยิ่งต่ำยิ่งดี)	ทั้งสอง	สัดส่วนของคำในผลลัพธ์ที่อยู่ในภาษาต้นทาง (โดยทั่วไปคือภาษาอังกฤษ) ตรวจจับผ่านการวิเคราะห์ Unicode script และ/หรือรายการคำภาษาต้นทาง รูปแบบความล้มเหลวของ LLM ที่พบบ่อยมาก: โมเดลแทรกคำภาษาอังกฤษเมื่อไม่รู้คำเทียบเท่าในภาษาเป้าหมาย
`hallucination_rate`	Hallucination Rate	✅ นำไปใช้งานแล้ว	0.0–1.0 (ยิ่งต่ำยิ่งดี)	ทั้งสอง	สัดส่วนของเนื้อหาในผลลัพธ์ที่ไม่มีเนื้อหาต้นทางที่สอดคล้องกัน ตรวจจับผ่านการจัดตำแหน่งคำหรือการทับซ้อนของ cross-lingual embedding ตรวจจับโมเดลที่สร้างการแปลที่ฟังดูสมเหตุสมผลแต่เป็นการแต่งขึ้น
`terminology_adherence`	Terminology Adherence	✅ นำไปใช้งานแล้ว	0.0–1.0	ทั้งสอง	สำหรับวิธีการที่มีการ coaching: สัดส่วนของคำศัพท์ที่กำหนดไว้ที่ปรากฏในผลลัพธ์ ต้องการข้อมูลพจนานุกรม coaching วัดว่าโมเดลเคารพคำศัพท์ที่ผู้เชี่ยวชาญกำหนดหรือไม่
`consistency_score`	Cross-Entry Consistency	🔲 วางแผนแล้ว	0.0–1.0	Corpus เท่านั้น	โมเดลแปลคำต้นทางเดียวกันในลักษณะเดียวกันข้ามรายการหรือไม่? ความสม่ำเสมอต่ำบ่งชี้ว่าโมเดลกำลังเดาแทนที่จะใช้รูปแบบที่เรียนรู้ ต้องการคำที่ซ้ำกันข้ามรายการ corpus

2.5 เมตริกการปฏิบัติตาม

เมตริกการปฏิบัติตามตรวจสอบว่าการแปลรักษาความสมบูรณ์ของโครงสร้าง — placeholder การจัดรูปแบบ และข้อตกลงการพิมพ์ เป็นการตรวจสอบ quality gate ไม่ใช่คะแนนคุณภาพ

ID	เมตริก	สถานะ	มาตราส่วน	ระดับ	การนำไปใช้งาน
`compliance_index`	Double-Pass Compliance	✅ นำไปใช้งานแล้ว	0.0–1.0	ทั้งสอง	ผสมถ่วงน้ำหนัก: 60% ความสมบูรณ์ของตัวแปร (ตัวแปร `{placeholder}` ถูกรักษาไว้หรือไม่?) + 20% การปฏิบัติตามเครื่องหมายคำพูด (อักขระเครื่องหมายคำพูดที่ถูกต้องตาม language card) + 20% การปฏิบัติตามตัวพิมพ์ (ไม่มีการรั่วไหลของตัวอักษร Latin สำหรับภาษาที่ไม่มีตัวพิมพ์ใหญ่-เล็ก) คำนวณทั้งบนผลลัพธ์ดิบและหลังการประมวลผล ผ่าน `DoublePassCompliancePlugin`
`repair_effectiveness`	Repair Effectiveness	✅ นำไปใช้งานแล้ว	0.0–1.0	Corpus	สัดส่วนของการละเมิดการปฏิบัติตามที่ได้รับการซ่อมแซมอัตโนมัติโดย hook หลังการแปล วัดว่า quality gate ปรับปรุงผลลัพธ์ดิบมากเพียงใด

เหตุใดการปฏิบัติตามจึงไม่อยู่ในผสม เมตริกการปฏิบัติตามวัดการรักษาโครงสร้าง (placeholder, เครื่องหมายคำพูด) ไม่ใช่คุณภาพการแปล การแปลอาจสมบูรณ์แบบทางภาษาศาสตร์แต่ล้มเหลวการปฏิบัติตามเพราะทิ้งตัวแปร {name} สิ่งเหล่านี้คือ quality gate — บล็อกผลลัพธ์ที่ไม่ดีไม่ให้ส่งออก แต่ไม่ได้จัดอันดับคุณภาพการแปล

3. ระดับสถานะเมตริก

เมตริกทุกตัวในหัวข้อ §2 อยู่ในหนึ่งในสี่ระดับการนำไปใช้งาน:

ระดับ	ความหมาย	พฤติกรรมใน Run Card
✅ นำไปใช้งานแล้ว	มีโค้ด ทดสอบแล้ว กำลังสร้างค่าใน run card ในปัจจุบัน	ค่าตัวเลขใน run card
⚡ บางส่วน	มี proxy เฉพาะภาษา (เช่น CRK) แต่การนำไปใช้งานทั่วไปยังรอดำเนินการ	ค่าตัวเลขเมื่อ proxy ใช้ได้ `null` ในกรณีอื่น
🔲 วางแผนแล้ว	ระบุแล้วแต่ยังไม่ได้นำไปใช้งาน	`null` ใน run card (ฟิลด์มีอยู่ ค่าไม่มี)
💡 เสนอแล้ว	อยู่ระหว่างการพิจารณา ยังไม่ได้ระบุ	ไม่อยู่ใน run card

เมตริกเลื่อนจาก วางแผนแล้ว → บางส่วน เมื่อ:

การนำไปใช้งานเฉพาะภาษาถูก merge และทดสอบแล้ว
สร้างค่าสำหรับคู่ภาษาอย่างน้อยหนึ่งคู่
การนำไปใช้งานทั่วไปยังรอดำเนินการ (บันทึกไว้ในข้อกำหนดนี้)

เมตริกเลื่อนจาก บางส่วน → นำไปใช้งานแล้ว เมื่อ:

การนำไปใช้งานที่ไม่ขึ้นกับภาษาถูก merge และทดสอบแล้ว
สร้างค่าสำหรับคู่ภาษาใด ๆ โดยไม่ต้องใช้ plugin เฉพาะภาษา
เอกสารนี้ได้รับการอัปเดตเพื่อสะท้อนสถานะ ✅

เมตริกเลื่อนจาก วางแผนแล้ว → นำไปใช้งานแล้ว เมื่อ:

การนำไปใช้งานถูก merge และทดสอบแล้ว
ได้รับการตรวจสอบบนการรัน evaluation จริงอย่างน้อยหนึ่งครั้ง
เอกสารนี้ได้รับการอัปเดตพร้อมรายละเอียดการนำไปใช้งาน

เมตริกเลื่อนจาก เสนอแล้ว → วางแผนแล้ว เมื่อ:

นิยาม มาตราส่วน และวิธีการคำนวณได้รับการตกลง
ถูกเพิ่มในเอกสารนี้พร้อมสถานะ 🔲 Planned
เพิ่ม null placeholder ใน schema ของ run card

4. คะแนนผสม

4.1 สูตร

คะแนนผสมคือค่าเฉลี่ยถ่วงน้ำหนักของเมตริกที่ มีอยู่ ทั้งหมด โดย re-normalize ให้น้ำหนักของเมตริกที่มีอยู่รวมกันเป็น 1.0:

composite = Σ (weight_i × value_i)    for all available metrics
             ─────────────────────
             Σ weight_i               (re-normalization denominator)

เมตริกถือว่า "มีอยู่" หากค่าใน run card เป็นตัวเลข (ไม่ใช่ null) เมื่อเมตริกไม่มีอยู่ — เพราะภาษาไม่มี FST หรือเพราะเมตริกยังไม่ได้นำไปใช้งาน — น้ำหนักของมันจะถูกกระจายตามสัดส่วนข้ามเมตริกที่เหลือ

ซึ่งหมายความว่าคะแนนผสมสามารถเปรียบเทียบได้เสมอภายใน run เดียว: ใช้เมตริกที่มีอยู่และ normalize ตามนั้น การเปรียบเทียบข้าม run ถูกต้องเมื่อ run ใช้ชุดเมตริกที่มีอยู่เหมือนกัน

[!WARNING] ความสามารถในการเปรียบเทียบข้าม run เมื่อเปรียบเทียบ run ที่มีความพร้อมใช้งานของเมตริกต่างกัน (เช่น run หนึ่งมีคะแนน FST อีก run ไม่มี) คะแนนผสม ไม่สามารถเปรียบเทียบโดยตรงได้ คะแนนผสม 0.72 ที่คำนวณจาก 5 เมตริกมีข้อมูลมากกว่าคะแนนผสม 0.72 ที่คำนวณจาก 2 เมตริก leaderboard แสดงคำเตือนเมื่อความครอบคลุมของเมตริกแตกต่างกันระหว่าง run ที่เปรียบเทียบ สำหรับการเปรียบเทียบที่เข้มงวด ให้ใช้การทดสอบนัยสำคัญแบบ paired bootstrap (§8.2) บนเมตริกที่ใช้ร่วมกันเท่านั้น

4.2 การ Normalize ข้อมูลนำเข้า

ก่อนเข้าสูตรผสม เมตริกทั้งหมดต้องอยู่บนมาตราส่วน 0.0–1.0 โดย 1.0 = สมบูรณ์แบบ:

เมตริก	มาตราส่วนดั้งเดิม	การ Normalize
`exact_match_rate`	0.0–1.0	ไม่มี (normalize แล้ว)
`equivalent_match_rate`	0.0–1.0	ไม่มี
`fst_acceptance_rate`	0.0–1.0	ไม่มี
`morphological_accuracy`	0.0–1.0	ไม่มี
`chrf_plus_plus`	0–100	หารด้วย 100
`semantic_score`	0.0–1.0	ไม่มี
`code_switching_rate`	0.0–1.0 (ยิ่งต่ำยิ่งดี)	`1.0 - value` (กลับค่า: 0% code-switching = 1.0)
`hallucination_rate`	0.0–1.0 (ยิ่งต่ำยิ่งดี)	`1.0 - value` (กลับค่า)
`terminology_adherence`	0.0–1.0	ไม่มี

เมตริกที่ไม่รวมในผสม (bleu, comet_score, ter, length_ratio, consistency_score) ไม่ได้รับการ normalize เพื่อจุดประสงค์นี้

4.3 ตารางน้ำหนัก

โปรไฟล์ A: ภาษาที่มีความครอบคลุม FST

สำหรับภาษาที่มี finite-state transducer ของ GiellaLT เมตริกโครงสร้างมีน้ำหนัก 40% ของผสม (FST 0.25 + morphological accuracy 0.15) สะท้อนถึงความสำคัญหลักของความถูกต้องทางสัณฐานวิทยาสำหรับภาษา polysynthetic/agglutinative

เมตริก	น้ำหนักเป้าหมาย	เหตุผล
`fst_acceptance_rate`	0.25	น้ำหนักสูงสุด หาก FST ปฏิเสธคำ แสดงว่าไม่ใช่รูปแบบที่ถูกต้องในภาษา — ไม่ว่าเมตริกอื่นจะบอกว่าอะไร แบบ Binary มีพื้นฐานทางโครงสร้าง
`morphological_accuracy`	0.15	คำอาจถูกต้องตาม FST แต่ผิดทางสัณฐานวิทยา (รากถูกต้อง การผันคำผิด) ร่วมกับ FST เมตริกโครงสร้างมีน้ำหนัก 40%
`chrf_plus_plus`	0.15	การทับซ้อนของ character n-gram: proxy ระดับพื้นผิวที่ดีที่สุดสำหรับภาษา polysynthetic จัดการสัณฐานวิทยา agglutinative ได้ดีกว่าเมตริกระดับคำ
`semantic_score`	0.15	การรักษาความหมายเมื่อรูปแบบพื้นผิวแตกต่างกัน ตรวจจับการแปลที่ผิดทางความหมายซึ่งผ่านการตรวจสอบโครงสร้าง
`equivalent_match_rate`	0.10	ให้รางวัลตัวแปรที่ยอมรับได้ ไม่ใช่แค่การแปลอ้างอิงเดียว สำคัญสำหรับภาษาที่มีลำดับคำยืดหยุ่น
`code_switching_rate`	0.05	ลงโทษการรั่วไหลของภาษาต้นทาง กลับค่า: 0% code-switching = 1.0
`terminology_adherence`	0.05	ให้รางวัลวิธีการที่มีการ coaching ซึ่งเคารพคำศัพท์ที่กำหนด ใช้งานได้เฉพาะเมื่อมีข้อมูล coaching
`hallucination_rate`	0.05	ลงโทษเนื้อหาที่แต่งขึ้น กลับค่า: 0% hallucination = 1.0
`exact_match_rate`	0.05	น้ำหนักต่ำสุด เข้มงวดเกินไปสำหรับภาษา polysynthetic — มีการแปลที่ถูกต้องหลายแบบ เก็บไว้เป็นการตรวจสอบเพดาน

รวม: 1.00 เมื่อเมตริกไม่มีอยู่ น้ำหนักของมันจะถูกกระจายตามสัดส่วนข้ามเมตริกที่มีอยู่ ปัจจุบัน morphological_accuracy (น้ำหนัก 0.15) เป็นเมตริกโปรไฟล์ A เดียวที่ยังไม่ได้คำนวณ — ต้องการคำอธิบายสัณฐานวิทยา gold-standard ต่อรายการ เมื่อเมตริกนี้ไม่มีอยู่ เมตริกที่เหลือ 8 ตัว (น้ำหนักรวม 0.85) จะถูกปรับขนาดแต่ละตัวด้วย 1/0.85 ≈ 1.176 ตัวอย่างเช่น:

FST: 0.25/0.85 = 0.294

chrF++: 0.15/0.85 = 0.176

semantic: 0.15/0.85 = 0.176

โปรไฟล์ B: ภาษาที่ไม่มีความครอบคลุม FST

สำหรับภาษาที่ไม่มีเครื่องมือตรวจสอบสัณฐานวิทยา เมตริกความหมายและพื้นผิวมีน้ำหนักเท่ากัน

เมตริก	น้ำหนักเป้าหมาย	เหตุผล
`semantic_score`	0.25	หากไม่มีการตรวจสอบโครงสร้าง การรักษาความหมายเป็นสัญญาณที่แข็งแกร่งที่สุดที่มีอยู่
`chrf_plus_plus`	0.25	หากไม่มี FST การทับซ้อนระดับอักขระกลายเป็นการตรวจสอบพื้นผิวหลัก
`equivalent_match_rate`	0.15	การจับคู่ตัวแปรให้การประเมินคุณภาพที่มีโครงสร้างโดยไม่ต้องใช้เครื่องมือสัณฐานวิทยา
`exact_match_rate`	0.10	หากไม่มี FST exact match มีน้ำหนักมากขึ้นในฐานะ proxy การตรวจสอบโครงสร้างเดียว
`code_switching_rate`	0.10	การรั่วไหลของภาษาต้นทางสำคัญมากขึ้นเมื่อไม่มี FST เพื่อตรวจจับผลลัพธ์ที่ไม่ดี
`terminology_adherence`	0.05	การปฏิบัติตามคำศัพท์ที่มีการ coaching
`hallucination_rate`	0.05	การตรวจจับเนื้อหาที่แต่งขึ้น
`orthographic_accuracy`	0.05	ความถูกต้องเฉพาะอักษรเติมส่วนหนึ่งของช่องว่างที่เกิดจากการไม่มี FST

รวม: 1.00 orthographic_accuracy (น้ำหนัก 0.05) วางแผนแล้วแต่ยังไม่ได้คำนวณ เมื่อไม่มีอยู่ เมตริกที่เหลือ 7 ตัว (น้ำหนักรวม 0.95) จะถูกปรับขนาดด้วย 1/0.95 ≈ 1.053 — ผลกระทบต่อผสมน้อยมาก

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

4.4 การเพิ่มเมตริกใหม่ในผสม

เพื่อเพิ่มเมตริกใหม่ในผสม:

กำหนดมัน ในหัวข้อ §2 พร้อมสถานะ 🔲 Planned รวมถึงมาตราส่วน ระดับ และวิธีการคำนวณ
นำไปใช้งาน เป็น MetricPlugin (หรือใน tester.py สำหรับเมตริกหลัก)
เพิ่ม null placeholder ในบล็อก scores ของ run card
กำหนดน้ำหนักเป้าหมาย ในหัวข้อ §4.3 โดยปรับน้ำหนักที่มีอยู่ลดลง น้ำหนักต้องรวมกันเป็น 1.00
อัปเดต BENCHMARK_SPEC.md §3 หาก schema ของ run card เปลี่ยนแปลง
อัปเดต scoring.py ตารางน้ำหนัก (โค้ดต้องสะท้อนเอกสารนี้)
รัน validation benchmark เพื่อยืนยันว่าเมตริกสร้างค่าที่สมเหตุสมผลบนข้อมูลจริง
อัปเดตเอกสารนี้ เพื่อเปลี่ยนสถานะจาก 🔲 เป็น ✅

5. ระดับคุณภาพ

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

[!IMPORTANT] ระดับอัตโนมัติเป็นการชั่วคราว ป้ายกำกับเหล่านี้เป็นการเสนอชื่อเพื่อการตรวจสอบ ไม่ใช่การประกาศคุณภาพ วิธีการที่ถึงระดับ "Deployable" บนเมตริกอัตโนมัติเป็นผู้สมัครสำหรับการประเมินชุมชน — ไม่ใช่ผลิตภัณฑ์ที่พร้อมส่งมอบ เฉพาะการตรวจสอบโดยมนุษย์จากผู้พูดสองภาษาเท่านั้นที่ยืนยันความสามารถใช้งานได้จริง (ดู BENCHMARK_SPEC §7) ไม่มีวิธีการใดที่อ้างสิทธิ์ระดับ Deployable หรือสูงกว่าได้โดยไม่มีการตรวจสอบชุมชนยืนยันว่าผู้พูดเห็นด้วยว่าผลลัพธ์สามารถใช้งานได้ เกณฑ์ระดับอาจแตกต่างกันข้ามภาษาเมื่อข้อมูลการตรวจสอบของมนุษย์สะสมมากขึ้น

ระดับ	ช่วงผสม	สิ่งที่ผู้พูดมักเห็น
Baseline	0.00–0.30	ผลลัพธ์ LLM ดิบโดยไม่มีการสนับสนุนเฉพาะภาษา สัณฐานวิทยาส่วนใหญ่เป็น hallucination
Emerging	0.30–0.50	รูปแบบที่ถูกต้องบางส่วนเริ่มปรากฏ การ coaching ช่วยได้ แต่ผลลัพธ์ยังไม่น่าเชื่อถือ
Functional	0.50–0.70	ผลลัพธ์สามารถจดจำได้สำหรับผู้พูด หมวดหมู่ไวยากรณ์หลักมักถูกต้อง ข้อผิดพลาดทางสัณฐานวิทยาบ่อยครั้ง
Deployable	0.70–0.85	เหมาะสำหรับการแปลร่างพร้อมการตรวจสอบของมนุษย์ สัณฐานวิทยาส่วนใหญ่ถูกต้อง
Fluent	0.85–1.00	ใกล้เคียงกับการแปลของมนุษย์ที่มีความสามารถ ข้อผิดพลาดหายากและเล็กน้อย

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

5.1 เกณฑ์ระดับ (อ่านได้ด้วยเครื่อง)

สำหรับการนำไปใช้งานในโค้ด เกณฑ์คือ (ประเมินจากบนลงล่าง ตรงกันครั้งแรกชนะ):

composite >= 0.85  →  "fluent"
composite >= 0.70  →  "deployable"
composite >= 0.50  →  "functional"
composite >= 0.30  →  "emerging"
composite >= 0.00  →  "baseline"
composite is null  →  "unscored"

6. เมตริกต้นทุน

เมตริกต้นทุนวัดประสิทธิภาพทางการเงินของวิธีการแปล รายงานแยกจากคุณภาพ — ต้นทุนไม่มีอิทธิพลต่อคะแนนผสม (ยกเว้นในการจัดอันดับรองที่ปรับตามต้นทุน)

6.1 เมตริก Token

ID	เมตริก	การคำนวณ
`prompt_tokens`	Token นำเข้าทั้งหมด	ผลรวมของ `usage.prompt_tokens` ข้ามการเรียก API ทั้งหมด
`completion_tokens`	Token ส่งออกทั้งหมด	ผลรวมของ `usage.completion_tokens`
`reasoning_tokens`	Token chain-of-thought	ผลรวมของ `usage.completion_tokens_details.reasoning_tokens` (0 สำหรับโมเดลส่วนใหญ่)
`cached_tokens`	Token ที่ provider cache	ผลรวมของ `usage.prompt_tokens_details.cached_tokens`
`total_tokens`	Token ทั้งหมดที่ใช้	`prompt_tokens + completion_tokens`
`tokens_per_entry`	Token เฉลี่ยต่อการแปล	✅ `total_tokens / entry_count`

6.2 เมตริกต้นทุน

ID	เมตริก	การคำนวณ	กรณีการใช้งาน
`total_cost_usd`	ต้นทุนรันทั้งหมด	ราคาที่ provider รายงาน × จำนวน token	"benchmark นี้มีต้นทุนเท่าไร?"
`cost_per_entry_usd`	ต้นทุนต่อรายการ corpus	`total_cost_usd / entry_count`	การเปรียบเทียบวิธีการบน corpus เดียวกัน
`cost_per_1k_tokens`	ต้นทุนต่อ 1,000 token	✅ `total_cost_usd / total_tokens × 1000`	ประสิทธิภาพ LLM สากล — เปรียบเทียบได้ข้าม corpus
`cost_per_source_char`	ต้นทุนต่ออักขระต้นทาง	`total_cost_usd / total_source_chars`	เปรียบเทียบได้ข้ามภาษาที่มี tokenization ต่างกัน

เหตุใดจึงมีเมตริกต้นทุนหลายตัว? "รายการ" มีความยาวต่างกัน — วลี 3 คำมีต้นทุนน้อยกว่าย่อหน้า cost_per_entry_usd มีประโยชน์สำหรับการเปรียบเทียบวิธีการบน corpus เดียวกัน (รายการเดียวกัน = ความยาวเดียวกัน = การเปรียบเทียบที่ยุติธรรม) cost_per_1k_tokens เป็นเมตริกประสิทธิภาพ LLM มาตรฐาน เปรียบเทียบได้ ข้าม corpus cost_per_source_char normalize สำหรับความแตกต่างของ tokenization — ประโยคเดียวกันอาจ tokenize เป็นจำนวน token ต่างกันขึ้นอยู่กับ vocabulary ของโมเดล

6.3 คะแนนที่ปรับตามต้นทุน

สำหรับวิธีการที่ใช้ API แบบชำระเงิน เราคำนวณการจัดอันดับรอง:

cost_adjusted = composite / log2(1 + cost_per_entry_usd × 1000)

สิ่งนี้ให้รางวัลวิธีการที่บรรลุคะแนนดีอย่างมีประสิทธิภาพ ใช้ cost_per_entry_usd (ไม่ใช่ต่อ token) เพราะคะแนนที่ปรับตามต้นทุนคำนวณภายใน benchmark เดียวเสมอ (corpus เดียวกัน) ทำให้การเปรียบเทียบต่อรายการยุติธรรม

คะแนนที่ปรับตามต้นทุนเป็น การจัดอันดับรอง — leaderboard หลักจัดอันดับตามคะแนนผสม ตอบคำถามที่แตกต่างกัน: "ด้วยงบประมาณที่กำหนด วิธีการใดให้ผลลัพธ์ที่ดีที่สุด?"

7. เมตริกความเร็ว

เมตริกความเร็ววัด latency และ throughput ของวิธีการแปล เช่นเดียวกับต้นทุน ความเร็วไม่มีอิทธิพลต่อคะแนนผสม

ID	เมตริก	การคำนวณ	ระดับ
`elapsed_seconds`	ระยะเวลารันตามนาฬิกาจริง	`time_end - time_start`	Run
`avg_latency_seconds`	Latency เฉลี่ยต่อรายการ	`Σ latency_s / n_entries`	Corpus
`median_latency_seconds`	Latency มัธยฐานต่อรายการ	เปอร์เซ็นไทล์ที่ 50 ของ `latency_s`	Corpus
`p95_latency_seconds`	Latency เปอร์เซ็นไทล์ที่ 95	เปอร์เซ็นไทล์ที่ 95 ของ `latency_s`	Corpus
`tokens_per_second`	Throughput	`total_tokens / elapsed_seconds`	Run
`entries_per_minute`	อัตราการแปล	`entry_count / (elapsed_seconds / 60)`	Run

8. ความเชื่อมั่นและนัยสำคัญ

8.1 ช่วงความเชื่อมั่นแบบ Bootstrap

เมตริกหลักทั้งหมดรองรับช่วงความเชื่อมั่นแบบ bootstrap (วิธี percentile, n=1000 resamples, α=0.05):

เมตริก	CI ที่รายงาน
`chrf_plus_plus`	✅ `chrf_ci_lower`, `chrf_ci_upper`
`exact_match_rate`	✅ `exact_match_ci_lower`, `exact_match_ci_upper`
`fst_acceptance_rate`	✅ `fst_ci_lower`, `fst_ci_upper` (คำนวณเฉพาะเมื่อมีข้อมูล FST)
`comet_score`	✅ `comet_ci_lower`, `comet_ci_upper` (bootstrap จากคะแนนต่อรายการที่ cache ไว้ — ไม่มีการอนุมาน neural ซ้ำซ้อน)
`composite`	✅ `composite_ci_lower`, `composite_ci_upper` (คำนวณเมื่อ chrF++ และ exact_match มีอยู่)
CI ต่อระดับ	✅ `confidence_intervals_by_tier` — chrF++ และ exact_match CI ต่อระดับความยาก (Tier 1-5)

8.2 การทดสอบนัยสำคัญแบบ Paired Bootstrap

สำหรับการเปรียบเทียบสองวิธีการ harness คำนวณการทดสอบ resampling แบบ paired bootstrap:

H₀: The two methods perform equally on this corpus.
H₁: One method is significantly better.

หาก p-value < 0.05 และช่วงความเชื่อมั่นของความแตกต่างไม่รวมศูนย์ ความแตกต่างนั้นมีนัยสำคัญทางสถิติที่ระดับ 95%

9. Schema ของ Scores ใน Run Card

หัวข้อนี้กำหนดโครงสร้างลำดับชั้นของบล็อก scores ใน run card Schema นี้ได้มาจากเมตริกที่กำหนดในหัวข้อ §2–§7 และต้องรักษาให้สอดคล้องกัน

{
  "scores": {
    // §2.1 Surface metrics
    "exact_match_rate":       0.6613,       // 0.0–1.0
    "exact_matches":          41,           // count
    "equivalent_match_rate":  0.7258,       // ⚡ partial (CRK: eval_standards/crk CrkLinterMetric)
    "equivalent_matches":     45,           // ⚡ partial (CRK: eval_standards/crk CrkLinterMetric)
    "chrf_plus_plus":         80.65,        // 0–100 (sacrebleu native scale)
    "bleu":                   54.78,        // 0–100, NOT in composite
    "ter":                    42.3,         // ✅ implemented, 0–∞ (lower=better)
    "length_ratio":           1.03,         // ✅ implemented, ideal=1.0

    // §2.2 Structural metrics
    "fst_acceptance_rate":    1.0,          // 0.0–1.0
    "fst_accepted":           74,           // count
    "morphological_accuracy": null,         // 🔲 planned
    "orthographic_accuracy":  null,         // 🔲 planned

    // §2.3 Semantic metrics
    "semantic_score":         0.6842,       // ⚡ partial (CRK: eval_standards/crk CrkSemanticMetric)
    "comet_score":            null,         // nullable, NOT in composite
    "comet_model":            "",           // model ID used for COMET

    // §2.4 Behavioral metrics
    "code_switching_rate":    0.03,         // ✅ implemented (lower=better)
    "hallucination_rate":     0.01,         // ✅ implemented (lower=better)
    "terminology_adherence":  null,         // ✅ implemented (null when no glossary)
    "consistency_score":      null,         // 🔲 planned

    // §4 Composite
    "composite":              0.8988,       // 0.0–1.0
    "quality_tier":           "fluent",     // §5 tier label
    "cost_adjusted":          null,         // §6.3 secondary ranking

    // §7 Speed metrics (merged into scores block)
    "tokens_per_second":      4462.5,       // ✅ total_tokens / elapsed
    "entries_per_minute":     82.30,        // ✅ entry_count / (elapsed/60)
    "avg_latency_seconds":    0.234,
    "median_latency_seconds": 0.190,
    "p95_latency_seconds":    0.415,

    // §8.1 Confidence intervals
    "confidence_intervals": {
      "chrf_plus_plus":     { "ci_lower": 78.2, "ci_upper": 83.1 },
      "exact_match_rate":   { "ci_lower": 0.54, "ci_upper": 0.78 },
      "corpus_comet":       { "ci_lower": 0.71, "ci_upper": 0.76 }
    },
    "confidence_intervals_by_tier": {
      "1": { "corpus_chrf": { "ci_lower": 68.1, "ci_upper": 76.5 } },
      "3": { "corpus_chrf": { "ci_lower": 36.2, "ci_upper": 47.0 } }
    },

    // Breakdowns
    "by_difficulty":          {},           // scores grouped by difficulty tier
    "by_provenance":          {},           // scores grouped by entry provenance

    // Counts
    "total":                  62,
    "evaluated":              62,
    "errors":                 0
  },

  "totals": {
    // §6.1 Token metrics
    "prompt_tokens":          13985,
    "completion_tokens":      187822,
    "reasoning_tokens":       175726,
    "cached_tokens":          0,
    // §6.2 Cost metrics
    "total_cost_usd":         1.7114,
    "cost_per_entry_usd":     0.027603,
    "cost_per_source_char":   null          // 🔲 needs source char counting
  }
}

ประวัติ Schema ร่างข้อกำหนดก่อนหน้าเสนอบล็อก cost, speed และ tokens แยกกัน สิ่งเหล่านี้ถูก merge เข้าใน scores และ totals ตามลำดับเพื่อความเรียบง่าย เมตริกความเร็ว (tokens_per_second, entries_per_minute, latency) อยู่ใน scores; จำนวน token และตัวเลขต้นทุนอยู่ใน totals

9.1 การแมป Schema–Database

JSON ของ run card ถูกเก็บทั้งหมดเป็นคอลัมน์ jsonb ใน Supabase เมตริกหลักยังถูก denormalize เป็นคอลัมน์ระดับบนสุดเพื่อประสิทธิภาพการเรียงลำดับ/กรอง:

ฟิลด์ใน Run Card	คอลัมน์ Supabase	ประเภท	Index
`scores.composite`	`composite_score`	`real`	`idx_composite`
`scores.quality_tier`	`quality_tier`	`text`	—
`scores.chrf_plus_plus`	`chrf_plus_plus`	`real`	`idx_leaderboard`
`scores.exact_match_rate`	`exact_match_rate`	`real`	—
`scores.fst_acceptance_rate`	`fst_acceptance_rate`	`real`	—
`scores.bleu`	`corpus_bleu`	`real`	—
`scores.comet_score`	`comet_score`	`real`	—
`totals.total_cost_usd`	`total_cost_usd`	`real`	—
`totals.cost_per_entry_usd`	`cost_per_entry_usd`	`real`	—
`totals.cost_per_source_char`	`cost_per_source_char`	`real`	—
`scores.avg_latency_seconds`	`avg_latency_seconds`	`real`	—
`model_slug`	`model_slug`	`text`	`idx_model`
`condition`	`condition`	`text`	—
`dataset.id`	`dataset_id`	`text`	`idx_leaderboard`
`dataset.language_pair`	`language_pair`	`text`	—
`fingerprint.hash`	`fingerprint_hash`	`text`	`idx_fingerprint`
`scores.equivalent_match_rate`	`equivalent_match_rate`	`real`	—
`scores.semantic_score`	`semantic_score`	`real`	—
`scores.ter`	`ter`	`real`	—
`scores.length_ratio`	`length_ratio`	`real`	—
`scores.code_switching_rate`	`code_switching_rate`	`real`	—
`scores.hallucination_rate`	`hallucination_rate`	`real`	—
`scores.terminology_adherence`	`terminology_adherence`	`real`	—
`scores.tokens_per_second`	`tokens_per_second`	`real`	—
`scores.entries_per_minute`	`entries_per_minute`	`real`	—
`elapsed_seconds`	`elapsed_seconds`	`real`	—
(การ์ดทั้งหมด)	`run_card`	`jsonb`	—

เมื่อมีการนำเมตริกใหม่ไปใช้งาน ควรเพิ่มคอลัมน์ที่สอดคล้องกันผ่าน migration ที่มีหมายเลขใน arena/migrations/

10. การซิงโครไนซ์โค้ด–ข้อกำหนด

10.1 แหล่งข้อมูลหลัก

เอกสารนี้ (arena/website/docs/specifications/scoring.md) เป็นแหล่งข้อมูลหลักสำหรับ:

นิยามเมตริก (§2)
ตารางน้ำหนักผสม (§4.3)
เกณฑ์ระดับคุณภาพ (§5.1)
สูตรเมตริกต้นทุน (§6.2)
Schema ของ scores ใน run card (§9)

10.2 โค้ด Mirror

ไฟล์ arena/mt_eval_harness/scoring.py สะท้อนตารางน้ำหนักและเกณฑ์ระดับจากเอกสารนี้ เป็น การนำไปใช้งานในโค้ด ของหัวข้อ §4.3 และ §5.1 เมื่ออัปเดตเอกสารนี้:

อัปเดต scoring.py ให้ตรงกัน
รัน pytest tests/test_scoring_ssot.py เพื่อตรวจสอบความสอดคล้อง
อัปเดต FAQ และเอกสารเว็บไซต์ที่สรุปน้ำหนัก

10.3 เอกสารที่อ้างอิงข้อกำหนดนี้

เอกสาร	สิ่งที่อ้างอิง	วิธีรักษาความสอดคล้อง
`arena/website/docs/specifications/benchmark-spec.md` §4–§5	สูตรผสม ตารางน้ำหนัก เกณฑ์ระดับ	อ้างอิงเอกสารนี้ อย่าทำซ้ำตาราง
`website/docs/getting-started/faq.md`	สรุปน้ำหนักแบบย่อ	ต้องตรงกับ §4.3; ลิงก์กลับมาที่เอกสารนี้
`arena/website/docs/how-it-works.md`	เกณฑ์ Deployable	ต้องตรงกับ §5
`publish.py` ผ่าน `scoring.py`	dict น้ำหนัก + ฟังก์ชันระดับ	การทดสอบอัตโนมัติตรวจสอบความตรงกัน

ภาคผนวก A: เมตริกที่ไม่อยู่ในผสม (และเหตุผล)

เมตริก	เหตุผลที่ไม่รวม
BLEU	การให้คะแนนระดับคำลงโทษการเปลี่ยนแปลงทางสัณฐานวิทยาในภาษา polysynthetic ความแตกต่างของการผันคำเล็กน้อย (ความหมายถูกต้อง คำต่อท้ายต่างกันเล็กน้อย) นับเป็นการพลาดทั้งหมด chrF++ จัดการสิ่งนี้ได้ดีกว่าในระดับอักขระ
COMET	ฝึกบนข้อมูล WMT (คู่ภาษายุโรปที่มีทรัพยากรสูง) คะแนนสำหรับ LRL ไม่น่าเชื่อถือ — โมเดลกำลังประมาณจากภาษาที่มีระบบสัณฐานวิทยาต่างกัน รายงานเพื่อความโปร่งใส ไม่ใช่เพื่อการให้คะแนน
TER	ระยะทางแก้ไขมีความสัมพันธ์กับ chrF++ สำหรับกรณีการใช้งานส่วนใหญ่ การรวมทั้งสองจะนับซ้ำความคล้ายคลึงพื้นผิว TER รายงานเพื่อการอ้างอิง
Length Ratio	เป็นการวินิจฉัย ไม่ใช่สัญญาณคุณภาพ อัตราส่วน 1.02 และ 0.98 ต่างก็ดี เฉพาะค่าสุดขีดเท่านั้นที่บ่งชี้ปัญหา
Consistency Score	ระดับ corpus เท่านั้น — ไม่มีค่าต่อรายการเพื่อรวบรวม นอกจากนี้ ความไม่สม่ำเสมอบางอย่างถูกต้องตามกฎหมาย (คำภาษาอังกฤษเดียวกัน → การแปลภาษาเป้าหมายต่างกันขึ้นอยู่กับบริบท)
Compliance Index	Quality gate ไม่ใช่สัญญาณคุณภาพ วัดการรักษาโครงสร้าง (placeholder, เครื่องหมายคำพูด) ไม่ใช่ความถูกต้องของการแปล

ภาคผนวก B: LYSS — การนำไปใช้งานเมตริกเฉพาะภาษา

กรอบงาน LYSS (Linguistically-informed Yield & Structural Scoring) ให้เมตริกเฉพาะภาษาที่เกินกว่าการเปรียบเทียบสตริงระดับพื้นผิว LYSS มีสามองค์ประกอบหลัก:

LYSS-fst — ความถูกต้องทางสัณฐานวิทยา (fst_acceptance_rate): แต่ละคำเป็นรูปแบบที่ถูกต้องในภาษาเป้าหมายหรือไม่?
LYSS-eq — ความเท่าเทียมทางภาษาศาสตร์ (equivalent_match_rate): ผลลัพธ์เป็นตัวแปรที่ยอมรับได้ของอ้างอิงหรือไม่?
LYSS-sem — การตรวจสอบความหมาย (semantic_score): ผลลัพธ์รักษาความหมายต้นทางหรือไม่?

สถานะการตรวจสอบ: 🔶 Heuristic ทางวิศวกรรม เมตริก LYSS ยังไม่ได้รับการตรวจสอบกับการตัดสินคุณภาพของมนุษย์ ออกแบบจากหลักการทางภาษาศาสตร์ (FST พจนานุกรม กฎไวยากรณ์ที่สร้างโดยนักภาษาศาสตร์ที่ UAlberta ALTLab) แต่ความสัมพันธ์ระหว่างคะแนน LYSS และคุณภาพการแปลจริงยังไม่ได้วัด ดู โปรโตคอลการตรวจสอบโดยผู้พูด สำหรับการทดลองตรวจสอบที่จำเป็น

ภาษา	Plugin	ตำแหน่ง	องค์ประกอบ LYSS	คีย์เมตริก	หมายเหตุ
CRK (Plains Cree)	`CrkLinterMetric`	`eval_standards/crk/metrics.py`	LYSS-eq	`equivalent_match_rate`	กฎคลาสตัวแปรแบบ deterministic: ลำดับคำ การสะกด อนุภาคเสริม คำพ้องความหมาย ความกำกวมของ progressive, inclusive/exclusive สร้าง `lint_verdict` ต่อรายการ (EXACT/EQUIVALENT/MISS/NO_OUTPUT)
CRK	`CrkSemanticMetric`	`eval_standards/crk/metrics.py`	LYSS-sem	`semantic_score`	แบบ Deterministic: การดึง lemma ด้วย FST + คำอธิบายพจนานุกรม + การทับซ้อนของคำเนื้อหาด้วย spaCy สร้าง verdict (EXACT_MATCH/VALID/GRAMMAR_ISSUES/PARTIAL/INCOMPLETE/WRONG/NO_OUTPUT)
ภาษา GiellaLT	`GiellaLTFSTMetric`	`plugins/giellalt_fst.py`	LYSS-fst	`fst_acceptance_rate`	ทั่วไป: ใช้ได้กับ CRK, SME, SMA, SMJ, SMN, SMS, FIN, NOB, IKU — ภาษาใด ๆ ที่มีตัววิเคราะห์ `.hfstol`

หมายเหตุสถาปัตยกรรม (มิถุนายน 2026) เมตริก LYSS เฉพาะภาษาถูกประกาศบน language card ภายใต้ evalMetrics และโหลดจาก eval_standards/<lang>/ โดย plugin_discovery.py เป็น มาตรฐานการประเมิน (กรรมการ) ไม่ใช่เมตริก plugin ของวิธีการ (ผู้แข่งขัน) ซึ่งหมายความว่าวิธีการแปลใด ๆ ที่กำหนดเป้าหมาย CRK จะได้รับการให้คะแนนโดย LYSS อัตโนมัติ — ไม่ต้องการการกำหนดค่าเฉพาะวิธีการ CrkFSTMetric ถูกลบออก; ฟังก์ชันของมันครอบคลุมทั้งหมดโดย GiellaLTFSTMetric ทั่วไป

ภาคผนวก C: เมตริกที่อยู่ระหว่างการพิจารณา

สิ่งเหล่านี้เป็นแนวคิดที่กำลังประเมินแต่ยังไม่ได้ระบุเพียงพอสำหรับหัวข้อ §2:

แนวคิด	สิ่งที่จะวัด	อุปสรรค
Fluency (LM perplexity)	ผลลัพธ์เป็นร้อยแก้วที่ถูกต้องในภาษาเป้าหมายหรือไม่?	ต้องการ LM ภาษาเป้าหมาย ไม่มีโมเดลที่ดีสำหรับ LRL ส่วนใหญ่
Register match	การแปลตรงกับระดับความเป็นทางการที่คาดหวังหรือไม่?	ต้องการตัวจำแนก sociolinguistic เป็นปัญหาการวิจัย
Cultural appropriateness	การอ้างอิงทางวัฒนธรรมได้รับการจัดการอย่างถูกต้องหรือไม่?	ไม่สามารถทำอัตโนมัติได้ — ต้องการการตรวจสอบของมนุษย์โดยเนื้อแท้
Discourse coherence	การแปลต่อเนื่องกันสร้างข้อความที่สอดคล้องกันหรือไม่?	ต้องการการประเมินระดับเอกสาร ไม่ใช่ระดับประโยค

อ้างอิง

บทความวิชาการ เครื่องมือ และทรัพยากรภาษาที่อ้างถึงตลอดข้อกำหนดนี้

เมตริกพื้นผิว

Popović, M. (2017). "chrF++: words helping character n-grams." Proceedings of the Second Conference on Machine Translation (WMT 2017), pp. 612–618. Copenhagen, Denmark.
Papineni, K., Roukos, S., Ward, T., & Zhu, W.-J. (2002). "BLEU: a method for automatic evaluation of machine translation." Proceedings of the 40th Annual Meeting of the Association for Computational Linguistics (ACL 2002), pp. 311–318. Philadelphia, PA.
Post, M. (2018). "A Call for Clarity in Reporting BLEU Scores." Proceedings of the Third Conference on Machine Translation (WMT 2018), pp. 186–191. Belgium, Brussels. การนำไปใช้งานอ้างอิง: sacrebleu.
Snover, M., Dorr, B., Schwartz, R., Micciulla, L., & Makhoul, J. (2006). "A Study of Translation Edit Rate with Targeted Human Annotation." Proceedings of the 7th Conference of the Association for Machine Translation in the Americas (AMTA 2006), pp. 223–231. Cambridge, MA.

เมตริก Neural

Rei, R., Stewart, C., Farinha, A. C., & Lavie, A. (2020). "COMET: A Neural Framework for MT Evaluation." Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP 2020), pp. 2685–2702. Online.
Juraska, J., Finkelstein, M., Deutsch, D., Siddhant, A., Miber, D., & Markl, A. (2023). "MetricX-23: The Google Submission to the WMT 2023 Metrics Shared Task." Proceedings of the Eighth Conference on Machine Translation (WMT 2023). Singapore.
Zhang, T., Kishore, V., Wu, F., Weinberger, K. Q., & Artzi, Y. (2020). "BERTScore: Evaluating Text Generation with BERT." Proceedings of the Eighth International Conference on Learning Representations (ICLR 2020). Addis Ababa, Ethiopia.
Sellam, T., Das, D., & Parikh, A. (2020). "BLEURT: Learning Robust Metrics for Text Generation." Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics (ACL 2020), pp. 7881–7892. Online.

เครื่องมือสัณฐานวิทยาและภาษาศาสตร์

Lindén, K., Silfverberg, M., Axelson, E., Hardwick, S., & Pirinen, T. (2011). "HFST—Framework for Compiling and Applying Morphologies." Systems and Frameworks for Computational Morphology (SFCM 2011), Communications in Computer and Information Science, vol. 100, pp. 67–85. Springer, Berlin, Heidelberg.
Sánchez-Cartagena, V. M., & Toral, A. (2024). "MorphEval: Automatic Evaluation of Morphological Capabilities of Machine Translation Systems." Machine Translation, vol. 38, pp. 1–28.

การจำแนกข้อผิดพลาดและการประเมินเชิงวินิจฉัย

Popović, M. (2011). "Hjerson: An Open Source Tool for Automatic Error Classification of Machine Translation Output." The Prague Bulletin of Mathematical Linguistics, no. 96, pp. 59–68.
Dreyer, M. & Marcu, D. (2012). "HyTER: Meaning-Equivalent Semantics for Translation Evaluation." Proceedings of the 2012 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (NAACL 2012), pp. 162–171. Montréal, Canada.
Reiter, E. & Belz, A. (2009). "An Investigation into the Validity of Some Metrics for Automatically Evaluating Natural Language Generation Systems." Computational Linguistics, vol. 35, no. 4, pp. 529–558. (งานที่เกี่ยวข้องเกี่ยวกับเมตริกการประเมินแบบ feature-based รวมถึง FUSE)

การตรวจจับ Hallucination

Raunak, V., Menezes, A., & Junczys-Dowmunt, M. (2021). "The Curious Case of Hallucinations in Neural Machine Translation." Proceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (NAACL 2021), pp. 1172–1183. Online.
Guerreiro, N. M., Voita, E., & Martins, A. F. T. (2023). "Looking for a Needle in a Haystack: A Comprehensive Study of Hallucinations in Neural Machine Translation." Proceedings of the 17th Conference of the European Chapter of the Association for Computational Linguistics (EACL 2023), pp. 1059–1075. Dubrovnik, Croatia.

ทรัพยากรภาษา Cree

Wolfart, H. C. (1973). "Plains Cree: A Grammatical Study." Transactions of the American Philosophical Society, vol. 63, no. 5, pp. 1–90.
Wolvengrey, A. (2001). nêhiyawêwin: itwêwina / Cree: Words. Canadian Plains Research Center, University of Regina.

การกำกับดูแลข้อมูล

First Nations Information Governance Centre. "The First Nations Principles of OCAP®." https://fnigc.ca/ocap-training/. (OCAP® เป็นเครื่องหมายการค้าจดทะเบียนของ First Nations Information Governance Centre)
Carroll, S. R., Garba, I., Figueroa-Rodríguez, O. L., Holbrook, J., Lovett, R., Materechera, S., Parsons, M., Raseroka, K., Rodriguez-Lonebear, D., Rowe, R., Sara, R., Walker, J. D., Anderson, J., & Hudson, M. (2020). "The CARE Principles for Indigenous Data Governance." Data Science Journal, vol. 19, no. 1, p. 43.

1. ปรัชญาการให้คะแนน​

1.1 ปรัชญา Microeval​

1.2 เมตริกอัตโนมัติเป็นเพียงตัวแทน​

1.3 การออกแบบแบบหลายสัญญาณ​

1.4 ความสามารถในการขยาย​

1.5 สามมิติของการประเมิน​

1.6 สถานะการตรวจสอบความถูกต้อง​

2. รายการเมตริก​

2.1 เมตริกพื้นผิว​

2.2 เมตริกโครงสร้าง​

2.3 เมตริกความหมาย​

2.4 เมตริกพฤติกรรม​

2.5 เมตริกการปฏิบัติตาม​

3. ระดับสถานะเมตริก​

4. คะแนนผสม​

4.1 สูตร​

4.2 การ Normalize ข้อมูลนำเข้า​

4.3 ตารางน้ำหนัก​

โปรไฟล์ A: ภาษาที่มีความครอบคลุม FST​

โปรไฟล์ B: ภาษาที่ไม่มีความครอบคลุม FST​

4.4 การเพิ่มเมตริกใหม่ในผสม​

5. ระดับคุณภาพ​

5.1 เกณฑ์ระดับ (อ่านได้ด้วยเครื่อง)​

6. เมตริกต้นทุน​

6.1 เมตริก Token​

6.2 เมตริกต้นทุน​

6.3 คะแนนที่ปรับตามต้นทุน​

7. เมตริกความเร็ว​

8. ความเชื่อมั่นและนัยสำคัญ​

8.1 ช่วงความเชื่อมั่นแบบ Bootstrap​

8.2 การทดสอบนัยสำคัญแบบ Paired Bootstrap​

9. Schema ของ Scores ใน Run Card​

9.1 การแมป Schema–Database​

10. การซิงโครไนซ์โค้ด–ข้อกำหนด​

10.1 แหล่งข้อมูลหลัก​

10.2 โค้ด Mirror​

10.3 เอกสารที่อ้างอิงข้อกำหนดนี้​

ภาคผนวก A: เมตริกที่ไม่อยู่ในผสม (และเหตุผล)​

ภาคผนวก B: LYSS — การนำไปใช้งานเมตริกเฉพาะภาษา​

ภาคผนวก C: เมตริกที่อยู่ระหว่างการพิจารณา​

อ้างอิง​

เมตริกพื้นผิว​

เมตริก Neural​

เครื่องมือสัณฐานวิทยาและภาษาศาสตร์​

การจำแนกข้อผิดพลาดและการประเมินเชิงวินิจฉัย​

การตรวจจับ Hallucination​

ทรัพยากรภาษา Cree​

การกำกับดูแลข้อมูล​