ข้อกำหนดเกณฑ์มาตรฐาน

สรุปสำหรับผู้บริหาร เอกสารนี้กำหนดโปรโตคอลการประเมินสำหรับระบบนิเวศการประเมิน MT ของ Champollion ได้แก่ รูปแบบคอร์ปัส (§2) สคีมา run card (§3) โปรโตคอลเกณฑ์มาตรฐาน (§6) ข้อกำหนดการตรวจสอบโดยมนุษย์ (§7) กลไกอธิปไตย (§8) โมเดลลีดเดอร์บอร์ดและการส่งผลงาน (§9) กรอบต้นทุน (§10) และการขยายไปยังภาษาใหม่ (§11) สำหรับนิยามเมตริก น้ำหนักคะแนนรวม เกณฑ์ระดับคุณภาพ และสูตรเมตริกด้านต้นทุน/ความเร็ว โปรดดู SCORING_SPEC.md ซึ่งเป็นแหล่งข้อมูลหลักสำหรับตรรกะการให้คะแนนทั้งหมด เอกสารนี้อ้างอิง SCORING_SPEC สำหรับรายละเอียดเหล่านั้นแทนการทำซ้ำ

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

1. หลักการ

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

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

ลำดับชั้นการประเมิน:

Automated metrics (run cards, benchmarks)
    ↓ proxy for
Human review (bilingual speakers validate output)
    ↓ proxy for
Actual utility (does this help a language community?)

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

1.2 วิธีการ ไม่ใช่โมเดล

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

1.3 การทำซ้ำได้

ผลลัพธ์เกณฑ์มาตรฐานทุกรายการต้องทำซ้ำได้ run card (§3) บันทึกการกำหนดค่าสมบูรณ์ของการทดลอง fingerprint (§3.5) ระบุการตั้งค่าการทดลอง run card hash (§3.6) ตรวจสอบความสมบูรณ์ของผลลัพธ์ ผู้ใดก็ตามที่มีวิธีการ คอร์ปัส และการกำหนดค่าเดียวกันควรได้คะแนนภายใน ±2% (คำนึงถึงความไม่แน่นอนของการสุ่มตัวอย่าง LLM ที่อุณหภูมิ > 0)

1.4 ไม่มีข้อมูลการประเมินสังเคราะห์

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

LLM อาจช่วยในด้าน:

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

LLM ต้องไม่ สร้างการแปลอ้างอิงหรือคู่การประเมิน

เราเป็นกลางในด้านการพัฒนาเกี่ยวกับข้อมูลการฝึก หากนักพัฒนาวิธีการใช้ข้อมูลการฝึกสังเคราะห์ การแปลกลับ หรือการเพิ่มข้อมูลในวิธีการของตน นั่นเป็นทางเลือกของพวกเขา — เราประเมินผลลัพธ์ ไม่ใช่กระบวนการฝึก OMT-1600 ของ Meta ใช้ประโยคคู่ขนานสังเคราะห์ประมาณ 270 ล้านประโยคที่สร้างผ่านการแปลกลับ เราไม่มีข้อโต้แย้งต่อวิธีการที่ฝึกด้วยวิธีนี้ เราทดสอบบนการดูแลโดยมนุษย์เท่านั้น

เหตุใดจึงไม่ใช้ข้อความพระคัมภีร์สำหรับการประเมิน? OMT-1600 ประเมิน 1,560 จาก 1,600 ภาษาบนข้อความโดเมนพระคัมภีร์ การแปลพระคัมภีร์มีรีจิสเตอร์โบราณ คำศัพท์พิธีกรรม และโครงสร้างประโยคแบบสูตร คอร์ปัสการประเมินของเราได้มาจากข้อความที่หลากหลายโดเมนซึ่งดูแลโดยชุมชน ได้แก่ โดเมนสุขภาพ กฎหมาย การศึกษา รัฐบาล การสนทนา และเทคนิค (ดู §2.7) นี่เป็นการเลือกออกแบบโดยเจตนา ชุมชนต้องการการแปลสำหรับโดเมนที่พวกเขาใช้ชีวิตและทำงานจริง ไม่ใช่รีจิสเตอร์ทางศาสนาเดียว วิธีการที่ได้คะแนนดีใน Genesis 1:1 แทบไม่บอกอะไรเกี่ยวกับประสิทธิภาพในวาระการประชุมสภาชนเผ่าหรือแบบฟอร์มรับผู้ป่วยของคลินิก

2. สคีมาคอร์ปัส

คอร์ปัสคือชุดคู่ข้อความคู่ขนานที่ดูแลแล้วพร้อมเมทาดาทาที่มีโครงสร้าง เป็นความจริงพื้นฐานที่ใช้วัดวิธีการทั้งหมด

2.1 ซองข้อมูลชุดข้อมูล

โครงสร้างระดับบนสุดของไฟล์คอร์ปัส:

{
  "dataset": {
    "id": "edtekla-dev-v1",
    "version": "1.0",
    "language_pair": "EN→CRK",
    "source_language": "en",
    "target_language": "crk",
    "created": "2026-05-01",
    "license": "CC-BY-NC-SA-4.0",
    "provenance": ["gold_standard", "textbook"]
  },
  "entries": [ ... ]
}

ฟิลด์	ประเภท	จำเป็น	คำอธิบาย
`id`	string	✅	ตัวระบุชุดข้อมูลที่ไม่ซ้ำกัน ใช้ใน run card และลีดเดอร์บอร์ด
`version`	string	✅	เวอร์ชันความหมาย การเพิ่มค่าจะทำให้การเปรียบเทียบ run card ก่อนหน้าไม่ถูกต้อง
`language_pair`	string	✅	ป้ายกำกับแสดงผล (เช่น `EN→CRK`)
`source_language`	string	✅	รหัสภาษาต้นฉบับ BCP 47
`target_language`	string	✅	รหัสภาษาเป้าหมาย BCP 47
`created`	string	✅	วันที่สร้าง ISO 8601
`license`	string	✅	ตัวระบุสิทธิ์การใช้งาน SPDX
`provenance`	string[]	✅	รายการแท็กที่มาที่ใช้ในรายการต่างๆ

2.2 สคีมารายการ

แต่ละรายการในคอร์ปัสแสดงถึงความท้าทายการแปลหนึ่งรายการ:

{
  "id": 42,
  "source": "I see the dog",
  "reference": "niwâpamâw atim",
  "segment": "gold_standard",
  "difficulty": 2,
  "provenance": "gold_standard",
  "register": "conversational",
  "context": "declaration",
  "morphological_analysis": "ni-wâpam-âw atim | 1sg-see.TA-3sg.DIR dog.AN",
  "notes": "Animate noun (atim); direct form because speaker is proximate",
  "variant_class": "simple-ta-direct"
}

ฟิลด์	ประเภท	จำเป็น	คำอธิบาย
`id`	integer	✅	ตัวระบุที่ไม่ซ้ำกันภายในคอร์ปัส
`source`	string	✅	ข้อความต้นฉบับในภาษาต้นทาง
`reference`	string	✅	การแปลอ้างอิงมาตรฐานทองในภาษาเป้าหมาย
`segment`	string	📎	พาร์ติชันคอร์ปัส: `gold_standard`, `held_out`, `development` หรือ `diagnostic`
`difficulty`	integer	📎	การให้คะแนนความยาก 1–5 (ดู §2.4)
`provenance`	string	📎	ที่มาของรายการนี้ (ดู §2.5)
`register`	string	📎	ระดับรีจิสเตอร์/ความเป็นทางการ (ดู §2.6)
`context`	string	📎	หน้าที่การสื่อสาร (ดู §2.6)
`domain`	string	📎	โดเมนกรณีการใช้งานจากอนุกรมวิธาน 16 รหัส (ดู §2.7) ต้องเป็นหนึ่งใน: `conv`, `ecommerce`, `edu`, `financial`, `gov`, `legal`, `literary`, `marketing`, `medical`, `news`, `religious`, `scientific`, `subtitles`, `support`, `tech`, `ui` ตรวจสอบความถูกต้องในขณะสร้าง

📎 = แนะนำ เครื่องมือจัดการฟิลด์ตัวเลือกที่ขาดหายไปอย่างสง่างามผ่านค่าเริ่มต้น คอร์ปัสของบุคคลที่สามต้องระบุเพียง id, source และ reference ต่อรายการ | morphological_analysis | string | ❌ | การแยกส่วนทางสัณฐานวิทยามาตรฐานทอง | | notes | string | ❌ | หมายเหตุผู้แปล ตัวแปรภาษาถิ่น แฟล็กความกำกวม | | variant_class | string | ❌ | ป้ายกำกับคลาสที่จัดกลุ่มตัวแปรการแปลที่ยอมรับได้ |

2.3 เซกเมนต์คอร์ปัส

คอร์ปัสแบ่งออกเป็นเซกเมนต์ที่มีระดับการเข้าถึงต่างกัน:

เซกเมนต์	วัตถุประสงค์	การเข้าถึง	ขนาดขั้นต่ำ
`development`	การพัฒนาและวนซ้ำวิธีการ นักพัฒนาใช้ได้อย่างอิสระ	สาธารณะ	30 รายการ
`diagnostic`	การทดสอบเป้าหมายสำหรับปรากฏการณ์ทางภาษาเฉพาะ	สาธารณะ	10 รายการ
`gold_standard`	การประเมินเกณฑ์มาตรฐานอย่างเป็นทางการ คะแนนลีดเดอร์บอร์ดมาจากที่นี่	ลับ — ถือครองโดยองค์กรกำกับดูแล	50 รายการ
`held_out`	สำรองไว้สำหรับการประเมินในอนาคต ไม่ใช้จนกว่าจะเปิดใช้งาน	ลับ — ถือครองโดยองค์กรกำกับดูแล	10 รายการ

สถานะปัจจุบัน: มีเพียงเซกเมนต์ development เท่านั้นที่มีอยู่ในชุดข้อมูลที่จัดส่ง เซกเมนต์ diagnostic, gold_standard และ held_out ถูกกำหนดไว้สำหรับการใช้งานในอนาคตเมื่อคอร์ปัสเติบโตขึ้น

เซกเมนต์ gold_standard และ held_out เป็นความลับอย่างสมบูรณ์ ทั้งประโยคต้นฉบับและการแปลอ้างอิงถูกเก็บไว้บนโครงสร้างพื้นฐานที่ควบคุมโดยการกำกับดูแล นักพัฒนาวิธีการไม่เคยเห็นคำถามหรือคำตอบ ดู §8 สำหรับกลไกอธิปไตย

2.4 ระดับความยาก

ระดับ	คำอธิบาย	ตัวอย่าง
1 — คำศัพท์พื้นฐาน	คำเดี่ยว คำทักทายทั่วไป ตัวเลข	"hello" → "tânisi", "dog" → "atim"
2 — ประโยคง่าย	ประธาน-กริยา หรือ SVO กาลปัจจุบัน	"I see the dog" → "niwâpamâw atim"
3 — ความซับซ้อนปานกลาง	กาลอดีต/อนาคต การแสดงความเป็นเจ้าของ ความมีชีวิต	"I saw his dog yesterday"
4 — สัณฐานวิทยาซับซ้อน	การแสดงความชัดเจน เสียงกรรม ลำดับร่วม อนุประโยคสัมพัทธ์	"the woman whose son went to the store"
5 — ขั้นสูง	หลายอนุประโยค รีจิสเตอร์ทางการ พิธีกรรม สำนวน	ย่อหน้าเต็มพร้อมน้ำเสียงที่เหมาะสมกับรีจิสเตอร์

คอร์ปัสที่สร้างขึ้นอย่างดีควรมีรายการครอบคลุมระดับความยากทั้งห้าระดับ โดยเน้นที่ระดับ 2–4 ซึ่งเป็นที่ที่ความท้าทายการแปลในโลกจริงส่วนใหญ่อยู่

2.5 แท็กที่มา

ทุกรายการต้องระบุที่มา:

แท็ก	ความหมาย
`gold_standard`	ตรวจสอบโดยผู้พูดที่คล่องแคล่ว
`textbook`	จากสื่อการศึกษาที่ตีพิมพ์
`elicited`	ผลิตผ่านเซสชันการดึงข้อมูลที่มีโครงสร้าง
`corpus`	ดึงมาจากคอร์ปัสคู่ขนาน

หมายเหตุ: ในทางปฏิบัติ ค่าที่มาเป็นสตริงอิสระ แท็กข้างต้นเป็นแบบแผน ไม่ใช่ enum ที่ตรวจสอบแล้ว — ชุดข้อมูลอาจใช้สตริงที่มาเชิงพรรณนาอื่นๆ

2.6 รีจิสเตอร์และบริบท

รีจิสเตอร์ อธิบายความเป็นทางการและบริบททางสังคม:

รีจิสเตอร์	คำอธิบาย
`conversational`	การพูดในชีวิตประจำวันระหว่างผู้เท่าเทียมกัน
`formal`	ภาษาทางการหรือสถาบัน
`technical`	คำศัพท์เฉพาะโดเมน
`ceremonial`	การใช้ภาษาแบบดั้งเดิมหรือศักดิ์สิทธิ์
`educational`	สื่อการสอนภาษา

บริบท อธิบายหน้าที่การสื่อสาร:

🔲 วางแผนไว้ ฟิลด์ context ถูกกำหนดในสคีมาแต่ยังไม่ได้ใส่ข้อมูลในชุดข้อมูลปัจจุบัน สำรองไว้สำหรับการเพิ่มคอร์ปัสในอนาคต

บริบท	คำอธิบาย
`greeting`	การทักทายหรือการลาทางสังคม
`declaration`	การแถลงข้อเท็จจริง
`question`	ประโยคคำถาม
`instruction`	คำสั่งหรือคำชี้นำ
`narrative`	การเล่าเรื่องหรือการบรรยาย
`label`	ป้ายกำกับ UI ข้อความปุ่ม หรือหัวข้อ
`error`	ข้อความแสดงข้อผิดพลาดหรือคำเตือน

2.7 โดเมน

โดเมน อธิบายกรณีการใช้งานในโลกจริง — ประเภทเนื้อหาที่กำลังแปล ซึ่งตั้งฉากกับรีจิสเตอร์และบริบท:

รีจิสเตอร์ ตอบคำถาม: ความเป็นทางการมากแค่ไหน?
บริบท ตอบคำถาม: ประโยคนี้ทำอะไร?
โดเมน ตอบคำถาม: อุตสาหกรรม/กรณีการใช้งานนี้คืออะไร?

สัญญาทางกฎหมาย (โดเมน: legal) อาจเป็นทางการ (รีจิสเตอร์: formal) และมีการประกาศ (บริบท: declaration) บันทึกการสนทนาของ chatbot ทางกฎหมาย (โดเมน: legal) อาจเป็นการสนทนา (รีจิสเตอร์: conversational) และมีคำถาม (บริบท: question) โดเมนเดียวกัน รีจิสเตอร์และบริบทต่างกัน

รหัสโดเมน	คำอธิบาย	ผู้บริโภคทั่วไป
`ui`	สตริงอินเทอร์เฟซซอฟต์แวร์	นักพัฒนาแอป ทีมโลคัลไลเซชัน
`legal`	สัญญา กฎหมาย เอกสารศาล เอกสารการย้ายถิ่น	สำนักงานกฎหมาย ศาล ทีมปฏิบัติตามกฎระเบียบ ทนายความทรัพย์สินทางปัญญา
`medical`	บันทึกทางคลินิก ฉลากยา การสื่อสารกับผู้ป่วย โปรโตคอลการทดลอง	โรงพยาบาล บริษัทยา การทดลองทางคลินิก พอร์ทัลผู้ป่วย
`financial`	การธนาคาร ประกันภัย การยื่นเอกสารกำกับดูแล รายงานการตรวจสอบ	ธนาคาร บริษัทประกัน หน่วยงานกำกับดูแล ผู้ตรวจสอบ
`edu`	ตำราเรียน หลักสูตร แผนการสอน สื่อวิชาการ	โรงเรียน มหาวิทยาลัย สำนักพิมพ์ตำราเรียน
`ecommerce`	คำอธิบายสินค้า รีวิว รายการตลาด	ผู้ค้าปลีกออนไลน์ ผู้ขายในตลาด
`marketing`	ข้อความโฆษณา ข้อความแบรนด์ แคมเปญ สโลแกน	เอเจนซีโฆษณา ทีมแบรนด์
`gov`	เอกสารนโยบาย กฎระเบียบ ประกาศสาธารณะ กฎหมาย	หน่วยงานรัฐบาล ทีมปฏิบัติตามกฎระเบียบ
`scientific`	บทความวิจัย บทคัดย่อ วิธีการ ข้อเสนอทุน	นักวิจัย วารสาร หน่วยงานทุน
`religious`	พระคัมภีร์ ข้อความพิธีกรรม คำอธิบายเทววิทยา	ชุมชนศรัทธา สำนักพิมพ์พิธีกรรม
`support`	คำถามที่พบบ่อย ข้อความแสดงข้อผิดพลาด คู่มือการแก้ปัญหา สคริปต์ chatbot	บริษัท SaaS ฝ่ายช่วยเหลือ
`subtitles`	บทสนทนาภาพยนตร์ ทีวี สตรีมมิ่ง และเกม	แพลตฟอร์มสตรีมมิ่ง สตูดิโอ บริษัทเกม
`news`	วารสารศาสตร์ รายงานข่าว บทบรรณาธิการ ข่าวประชาสัมพันธ์	องค์กรสื่อ บริการข่าว
`literary`	นิยาย บทกวี เรื่องเล่า ข้อความวัฒนธรรม	สำนักพิมพ์ องค์กรอนุรักษ์วัฒนธรรม
`conv`	การสนทนาไม่เป็นทางการ โซเชียลมีเดีย การส่งข้อความ	แอปผู้บริโภค แพลตฟอร์มโซเชียล
`tech`	เอกสาร API คู่มือ ข้อกำหนดวิศวกรรม คู่มือเทคนิค	ทีมเอกสาร องค์กรวิศวกรรม

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

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

อนาคต: Arena Chatbot เว็บไซต์ Arena จะมีผู้ช่วยสนทนาที่ช่วยให้ผู้ใช้อธิบายกรณีการใช้งาน MT ของตน (โดเมน คู่ภาษา ข้อกำหนดคุณภาพ) และแนะนำวิธีการที่ดีที่สุดที่ผ่านการตรวจสอบโดยชุมชนจากลีดเดอร์บอร์ด ตัวอย่างเช่น: "ฉันต้องการแปลโปรโตคอลการทดลองทางคลินิกจากภาษาอังกฤษเป็นภาษาญี่ปุ่น — วิธีการใดได้คะแนนสูงสุดในเกณฑ์มาตรฐาน EN→JA โดเมนการแพทย์?" ซึ่งขึ้นอยู่กับการมีข้อมูลการประเมินที่ติดแท็กตามโดเมนเพียงพอและความหลากหลายของวิธีการ

3. สคีมา Run Card

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

run card ทุกใบบันทึกสามมิติ:

คุณภาพ — การแปลดีแค่ไหน?
ต้นทุน — ใช้ต้นทุนเท่าไรในการผลิต?
ความเร็ว — ใช้เวลานานแค่ไหน?

3.1 ฟิลด์ระดับบนสุด

ฟิลด์	ประเภท	คำอธิบาย
`run_id`	string	UUID v4 ที่สร้างขึ้นเมื่อเริ่มการรัน
`harness_version`	string	เวอร์ชันความหมายของ harness (เช่น `2.0`)
`timestamp`	string	เวลาประทับ UTC ISO 8601 เมื่อการรันเริ่มต้น
`elapsed_seconds`	number	ระยะเวลาตามนาฬิกาจริงของการรันทั้งหมด

3.2 การกำหนดค่าวิธีการ

ฟิลด์เหล่านี้กำหนดการตั้งค่าการทดลอง — สิ่งที่ทดสอบและวิธีการ

ฟิลด์	ประเภท	จำเป็น	คำอธิบาย
`model_slug`	string	✅	ตัวระบุโมเดล (เช่น `google/gemini-2.5-flash`)
`model_id`	string	❌	ตัวระบุโมเดลที่แก้ไขแล้วซึ่งส่งคืนโดย API
`condition`	string	✅	ป้ายกำกับการทดลอง (เช่น `baseline`, `coached-v3`, `few-shot`)
`temperature`	number	✅	อุณหภูมิการสุ่มตัวอย่าง
`system_prompt_sha256`	string	✅	แฮช SHA-256 ของ system prompt เต็มรูปแบบ
`system_prompt_used`	string	✅	ข้อความ system prompt เต็มรูปแบบ
`coaching_data_sha256`	string	❌	แฮช SHA-256 ของไฟล์ข้อมูลการฝึกสอน หากใช้
`fst_version`	string	❌	เวอร์ชันของตัววิเคราะห์ FST หากใช้
`tools_enabled`	string[]	❌	รายการเครื่องมือที่วิธีการสามารถใช้ได้
`batch_size`	number	❌	รายการต่อแบตช์ API พร้อมกัน
`max_retries`	number	❌	จำนวนการลองใหม่สูงสุดสำหรับการปฏิเสธ FST หากมี

:::info Run Card ที่เผยแพร่รวม method_config เมื่อ run card ถูกเผยแพร่ไปยังลีดเดอร์บอร์ด (ผ่าน mt-eval publish) จะมีบล็อก method_config ที่มี MethodConfig 8 ฟิลด์แบบ canonical (model, temperature, batchSize, register, coachingFile, coachingPrompt, promptContext, qualityTier — ทั้งหมด camelCase) ซึ่งช่วยให้นำเข้าแบบ zero-reconstruction ได้: champollion leaderboard --install อ่าน method_config โดยตรงและเขียนเป็น plugin manifest ฟิลด์ telemetry ข้างต้น (§3.2) บันทึกสิ่งที่ harness สังเกตเห็น; method_config บันทึกสิ่งที่นักพัฒนาตั้งใจ :::

3.3 การอ้างอิงชุดข้อมูล

ฟิลด์	ประเภท	คำอธิบาย
`dataset.id`	string	ตัวระบุชุดข้อมูล
`dataset.version`	string	เวอร์ชันชุดข้อมูล
`dataset.language_pair`	string	ป้ายกำกับแสดงผล
`dataset.sha256`	string	แฮช SHA-256 ของเนื้อหาไฟล์ชุดข้อมูล
`dataset.entry_count`	number	จำนวนรายการที่ประเมิน

แฮช SHA-256 ของชุดข้อมูลยึด run card กับเวอร์ชันเฉพาะของข้อมูล หากชุดข้อมูลเปลี่ยนแปลง run card เก่าจะไม่สามารถเปรียบเทียบได้

3.4 คะแนน (คุณภาพ)

เมตริกรวมสำหรับการรันทั้งหมด เมตริกคุณภาพทั้งหมดเป็นอัตโนมัติ — ดู §1.1

ฟิลด์	ประเภท	คำอธิบาย
`scores.total`	number	รายการทั้งหมดที่ประเมิน
`scores.exact_matches`	number	รายการที่ผลลัพธ์ตรงกับอ้างอิงทุกประการ
`scores.exact_match_rate`	number	0.0–1.0
`scores.equivalent_matches`	number	รายการที่ตรงกับตัวแปรที่ยอมรับได้
`scores.equivalent_match_rate`	number	0.0–1.0
`scores.fst_accepted`	number	รายการที่ตัววิเคราะห์ FST ยอมรับ
`scores.fst_acceptance_rate`	number	0.0–1.0, `null` หากไม่ได้กำหนดค่า FST
`scores.morphological_accuracy`	number	0.0–1.0, `null` หากไม่มีการวิเคราะห์มาตรฐานทอง
`scores.chrf_plus_plus`	number	คะแนน chrF++ ระดับคอร์ปัส (0–100)
`scores.semantic_score`	number	ความคล้ายคลึงทางความหมายแบบ embedding (0.0–1.0)
`scores.ter`	number	Translation Edit Rate (0–∞ ยิ่งต่ำยิ่งดี)
`scores.length_ratio`	number	avg(len(predicted)/len(reference)) ค่าอุดมคติ = 1.0
`scores.code_switching_rate`	number	0.0–1.0 สัดส่วนรายการที่มีการรั่วไหลของภาษาต้นทาง
`scores.hallucination_rate`	number	0.0–1.0 สัดส่วนรายการที่มีเนื้อหาที่สร้างขึ้นเอง
`scores.terminology_adherence`	number	0.0–1.0 การปฏิบัติตามคำศัพท์อภิธาน (`null` หากไม่มีอภิธาน)
`scores.tokens_per_second`	number	total_tokens / elapsed_seconds
`scores.entries_per_minute`	number	รายการที่แปลต่อนาที
`scores.composite`	number	คะแนนรวมถ่วงน้ำหนัก (0.0–1.0) ดู SCORING_SPEC §4
`scores.errors`	number	รายการที่ล้มเหลว (ข้อผิดพลาด API หมดเวลา ฯลฯ)
`scores.by_difficulty`	object	คะแนนแยกตามระดับความยาก
`scores.by_provenance`	object	คะแนนแยกตามแท็กที่มา
`scores.by_domain`	object	✅ ดำเนินการแล้ว — คะแนนแยกตามโดเมน (§2.7) ช่วยให้จัดอันดับลีดเดอร์บอร์ดที่กรองตามโดเมนได้ คำนวณโดย tester.py และส่งผ่าน publish.py

3.5 ยอดรวม (ต้นทุน)

ฟิลด์	ประเภท	คำอธิบาย
`totals.prompt_tokens`	number	โทเค็นอินพุตทั้งหมดในการเรียก API ทั้งหมด
`totals.completion_tokens`	number	โทเค็นเอาต์พุตทั้งหมด
`totals.reasoning_tokens`	number	โทเค็นที่ใช้สำหรับ chain-of-thought (0 สำหรับโมเดลส่วนใหญ่)
`totals.cached_tokens`	number	โทเค็นที่ให้บริการจาก prompt cache ของผู้ให้บริการ
`totals.total_cost_usd`	number	ต้นทุนรวมเป็น USD
`totals.cost_per_entry_usd`	number	`total_cost_usd / entry_count`
`totals.cost_per_source_char`	number	USD ต่ออักขระต้นทาง — เปรียบเทียบได้ข้ามภาษา

3.6 เวลา (ความเร็ว)

ฟิลด์	ประเภท	คำอธิบาย
`elapsed_seconds`	number	ระยะเวลาตามนาฬิกาจริงของการรันทั้งหมด (ระดับบนสุด)
`scores.avg_latency_seconds`	number	เวลาตอบสนองเฉลี่ยต่อรายการ
`scores.median_latency_seconds`	number	เวลาตอบสนองมัธยฐานต่อรายการ
`scores.p95_latency_seconds`	number	เวลาตอบสนองเปอร์เซ็นไทล์ที่ 95 ต่อรายการ

3.7 ผลลัพธ์ต่อรายการ

แต่ละรายการในอาร์เรย์ results[] บันทึกการแปลหนึ่งรายการ ข้อมูลต่อรายการถูกเก็บไว้ในตาราง run_card_entries (migration 005) พร้อมคำตัดสิน LYSS ที่ denormalized (migration 006)

ฟิลด์	ประเภท	คำอธิบาย
`entry_id`	string	ตรงกับ `entries[].id` ในคอร์ปัส
`source`	string	ข้อความต้นฉบับที่แปล
`expected`	string	การแปลอ้างอิงมาตรฐานทอง
`raw_predicted`	string \| null	ผลลัพธ์โมเดลดิบก่อนการประมวลผลหลัง
`predicted`	string	ผลลัพธ์จริงของวิธีการ (หลังการประมวลผล)
`segment`	string	ตัวระบุเซกเมนต์ (เช่น ดัชนีประโยค)
`difficulty`	string \| null	ระดับความยากจากคอร์ปัส
`domain`	string	แท็กโดเมนจากคอร์ปัส (§2.7)
`exact_match`	boolean	ผลลัพธ์ตรงกับอ้างอิงทุกประการหรือไม่
`chrf_score`	number \| null	chrF++ ระดับประโยค (0–100)
`bleu_score`	number \| null	BLEU ระดับประโยค (0–100)
`latency_s`	number \| null	เวลาตอบสนองเป็นวินาที
`cost_usd`	number \| null	ต้นทุนเป็น USD สำหรับรายการนี้
`tool_call_count`	integer	จำนวนการเรียกใช้เครื่องมือ (0 หากไม่มี)
`error`	string \| null	ข้อความแสดงข้อผิดพลาดหากรายการนี้ล้มเหลว
`plugin_metrics`	object	ผลลัพธ์ plugin ต่อรายการเต็มรูปแบบ (JSONB)
`fst_valid`	boolean \| null	GiellaLT FST ยอมรับการทำนาย (LYSS-fst ที่ denormalized)
`equivalent_match`	boolean \| null	CRK linter ยืนยันความเท่าเทียมเชิงโครงสร้าง (LYSS-eq ที่ denormalized)
`semantic_verdict`	string \| null	คำตัดสิน LYSS-sem: `VALID`, `MISMATCH`, `UNKNOWN`, `ERROR`
`code_switching_detected`	boolean \| null	ตรวจพบโทเค็นภาษาต้นทางในผลลัพธ์
`hallucination_detected`	boolean \| null	ตรวจพบเนื้อหาที่สร้างขึ้นเองในผลลัพธ์

3.8 Fingerprint

ตัวระบุการทำซ้ำได้ การรันสองครั้งที่มี fingerprint เหมือนกันใช้การตั้งค่าการทดลองเดียวกัน

fingerprint คือแฮช SHA-256 ของการเรียงต่อกันแบบเรียงลำดับของ:

dataset.sha256
model_slug
condition
system_prompt_sha256
temperature
harness_version
batch_size
tools_enabled

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

การรันสองครั้งที่มี fingerprint เหมือนกันควรให้ผลลัพธ์ที่เปรียบเทียบได้ ความแตกต่างเกิดจากความไม่แน่นอนของ API (อุณหภูมิ > 0) หรือการอัปเดตโมเดลฝั่งผู้ให้บริการ

3.9 Run Card Hash

แฮช SHA-256 ของ run card JSON ทั้งหมด (โดยตั้งค่าฟิลด์ run_card_hash เป็น "" ระหว่างการแฮช) นี่คือตราประทับตรวจจับการแก้ไข หากฟิลด์ใดเปลี่ยนแปลง แฮชจะเสีย

4. เมตริกอัตโนมัติ

เมตริกทั้งหมดในส่วนนี้คำนวณโดยเครื่อง ดู §1.1

4.1 นิยามเมตริก

เมตริก	สถานะ	สิ่งที่วัด	ช่วง
chrF++	✅ ดำเนินการแล้ว	F-score ของ character n-gram ทำงานในระดับอักขระ ทำให้มีความทนทานมากกว่าเมตริกระดับคำ (BLEU) สำหรับภาษาที่มีสัณฐานวิทยาสมบูรณ์ซึ่งคำมีความยาวและผันแปรสูง คำนวณโดย sacrebleu	0–100 (สเกลดั้งเดิม) หารด้วย 100 เมื่อใช้ในคะแนนรวม
FST acceptance rate	✅ ดำเนินการแล้ว	สัดส่วนคำที่ทำนายซึ่งตัววิเคราะห์สัณฐานวิทยา (GiellaLT HFST) ยอมรับว่าเป็นรูปแบบที่ถูกต้องในภาษาเป้าหมาย คำที่ FST ยอมรับเป็นคำจริงที่มีโครงสร้างถูกต้อง ไม่ใช่การสร้างขึ้นเอง	0.0–1.0
Exact match	✅ ดำเนินการแล้ว	สัดส่วนการทำนายที่ตรงกับอ้างอิงทุกประการหลัง Unicode normalization เข้มงวดแต่ชัดเจน — มีประโยชน์เป็นการตรวจสอบเพดาน	0.0–1.0
Morphological accuracy	🔲 วางแผนไว้	สำหรับรายการที่มีการวิเคราะห์สัณฐานวิทยามาตรฐานทอง: สัดส่วน morpheme ที่สร้างได้ถูกต้อง ละเอียดกว่าการยอมรับ FST — คำสามารถถูกต้องตาม FST แต่มีโครงสร้าง morpheme ผิด (รากถูกต้อง กาลผิด)	0.0–1.0
Equivalent match	⚡ บางส่วน	สัดส่วนที่ตรงกับตัวแปรที่ยอมรับได้ของอ้างอิง — คำนึงถึงลำดับคำ ความแตกต่างของภาษาถิ่น และแบบแผนการสะกด ปัจจุบันดำเนินการสำหรับ CRK ผ่านมาตรฐาน CRK eval `CrkLinterMetric` (ใน `eval_standards/crk/`); โหลดอัตโนมัติผ่านการประกาศ `evalMetrics` ของ CRK language card การดำเนินการทั่วไปต้องการ `variants[]` ต่อรายการในคอร์ปัส	0.0–1.0
Semantic score	⚡ บางส่วน	การรักษาความหมายโดยไม่คำนึงถึงรูปแบบพื้นผิว ปัจจุบันดำเนินการสำหรับ CRK ผ่านมาตรฐาน CRK eval `CrkSemanticMetric` (ใน `eval_standards/crk/`, ตัวแทนถ่วงน้ำหนักคำตัดสิน) ความคล้ายคลึง cosine แบบ universal embedding วางแผนไว้ — ดู SCORING_SPEC §2.3	0.0–1.0

4.2 คะแนนรวม

คะแนนรวมคือค่าเฉลี่ยถ่วงน้ำหนักของเมตริกทั้งหมดที่มีอยู่:

composite = Σ (weight_i × metric_i)   for all available metrics
             ─────────────────────
             Σ weight_i              (renormalized to sum to 1.0)

เมื่อเมตริกไม่พร้อมใช้งาน (ไม่ได้กำหนดค่า FST ไม่มีคลาสตัวแปรที่กำหนด ไม่มีโมเดล embedding) น้ำหนักของมันจะถูกกระจายตามสัดส่วนไปยังเมตริกที่เหลือ ซึ่งหมายความว่าคะแนนรวมสามารถเปรียบเทียบได้เสมอภายในภาษา — ใช้เมตริกที่มีอยู่สำหรับภาษานั้นและทำ normalization ตามนั้น

ตารางน้ำหนัก กฎ normalization อินพุต และรายการเมตริกเต็มรูปแบบถูกกำหนดใน SCORING_SPEC.md §4 เอกสารนั้นเป็น SSOT สำหรับ:

น้ำหนัก Profile A (ภาษาที่มีการครอบคลุม FST — 9 เมตริก เมตริกโครงสร้างมีน้ำหนัก 40%)
น้ำหนัก Profile B (ภาษาที่ไม่มีการครอบคลุม FST — 8 เมตริก)
กฎ normalization (chrF++ ÷ 100 การผกผันอัตราการสลับรหัสและการสร้างขึ้นเอง)
เมตริกที่ไม่รวมในคะแนนรวม (BLEU, COMET, TER, อัตราส่วนความยาว ความสอดคล้อง) และเหตุผล

โค้ด harness สะท้อนตารางเหล่านี้ใน mt_eval_harness/scoring.py เมื่อ SCORING_SPEC เปลี่ยนแปลง scoring.py จะถูกอัปเดตให้ตรงกันและ test_scoring_ssot.py ตรวจสอบการจัดแนว

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

4.3 คะแนนปรับตามต้นทุน

สำหรับวิธีการที่ใช้ API แบบชำระเงิน เรายังรายงานการจัดอันดับรอง สูตรปรับตามต้นทุนถูกกำหนดใน SCORING_SPEC.md §6.3

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

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

เกณฑ์ระดับและคำอธิบายถูกกำหนดใน SCORING_SPEC.md §5 ระดับต่างๆ ได้แก่: Baseline (0.00–0.30), Emerging (0.30–0.50), Functional (0.50–0.70), Deployable (0.70–0.85) และ Fluent (0.85–1.00)

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

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

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

6. โปรโตคอลเกณฑ์มาตรฐาน

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

6.1 สิ่งที่เกณฑ์มาตรฐานผลิต

เกณฑ์มาตรฐานผลิตเมทริกซ์ของ run card — หนึ่งใบสำหรับแต่ละชุดค่าพารามิเตอร์ เมทริกซ์ช่วยให้เปรียบเทียบหลายมิติได้:

คุณภาพ — คะแนนรวม การแยกย่อยเมตริกแต่ละตัว
ต้นทุน — ต้นทุนรวมและต่อรายการสำหรับแต่ละการกำหนดค่า
ความเร็ว — เวลาตามนาฬิกาจริงและเวลาแฝงต่อรายการ

ไม่มี "คะแนนเกณฑ์มาตรฐาน" เดียว เกณฑ์มาตรฐานคือเมทริกซ์ทั้งหมด ผู้มีส่วนได้ส่วนเสียต่างๆ จะสนใจมิติต่างกัน: นักวิจัยเพิ่มประสิทธิภาพคะแนนรวม วิศวกรการปรับใช้เพิ่มประสิทธิภาพต้นทุนต่อรายการ ชุมชนตรวจสอบคุณภาพ

6.2 พื้นที่พารามิเตอร์

เกณฑ์มาตรฐานประกาศว่าพารามิเตอร์ใดถูกสลับ:

แกน	ค่าทั่วไป	วัตถุประสงค์
`model`	4–12 โมเดล (frontier + mid-tier + budget)	ความสามารถของโมเดลสำคัญแค่ไหน?
`temperature`	0.0, 0.3, 0.7	ความสุ่มในการสุ่มตัวอย่างช่วยหรือทำให้แย่ลง?
`prompt_version`	2–3 กลยุทธ์ prompt	วิธีการไวต่อการออกแบบ prompt แค่ไหน?
`coaching_config`	มี/ไม่มีข้อมูลการฝึกสอน	การฉีดความรู้ทางภาษาช่วยปรับปรุงผลลัพธ์หรือไม่?
`tool_config`	มี/ไม่มี FST มี/ไม่มีพจนานุกรม	เครื่องมือทางภาษาช่วยปรับปรุงผลลัพธ์หรือไม่?

พื้นที่การสลับทั้งหมด:

runs = |models| × |temperatures| × |prompts| × |coaching| × |tools|

เกณฑ์มาตรฐานเริ่มต้นทั่วไป: 12 โมเดล × 3 อุณหภูมิ × 2 prompt × 2 การฝึกสอน = 144 การรัน

6.3 การกำหนดเส้นฐานเทียบกับการประเมินวิธีการ

เกณฑ์มาตรฐานมีวัตถุประสงค์สองประการที่แตกต่างกัน:

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

การประเมินวิธีการ — การทดสอบวิธีการที่ออกแบบมาเฉพาะ "pipeline ที่ฝึกสอนด้วย FST-gated ของฉันเอาชนะเส้นฐานได้หรือไม่?" run card ของวิธีการถูกเปรียบเทียบกับเมทริกซ์เส้นฐาน วิธีการน่าสนใจเมื่อมันทำได้ดีกว่าเส้นฐานที่ดีที่สุด — เมื่อวิศวกรรมเพิ่มคุณค่าเหนือการเรียก API แบบไม่ซับซ้อน

กิจกรรมทั้งสองผลิต run card ด้วยสคีมาเดียวกัน ความแตกต่างอยู่ที่เจตนาและพื้นที่พารามิเตอร์: เส้นฐานสลับข้ามโมเดลและการกำหนดค่า; การประเมินวิธีการทดสอบวิธีการหนึ่งกับการกำหนดค่าที่ดีที่สุด

6.4 การประเมินแบบ Dev เทียบกับมาตรฐานทอง

นักพัฒนาวิธีการวนซ้ำได้อย่างอิสระกับเซกเมนต์คอร์ปัส development และ diagnostic ซึ่งเป็นแบบไม่เป็นทางการ — ไม่มีข้อจำกัด ไม่มีการส่งผลงาน ไม่มีการมีส่วนร่วมของการกำกับดูแล นักพัฒนากำลังเรียนรู้ว่าอะไรได้ผล

คะแนนลีดเดอร์บอร์ดอย่างเป็นทางการมาจากการประเมิน gold_standard เท่านั้น ซึ่งเป็นทางการ:

นักพัฒนาส่งวิธีการที่รันได้สมบูรณ์ (โค้ด + การกำหนดค่า + ข้อมูลการฝึกสอน)
องค์กรกำกับดูแลรันในแซนด์บ็อกซ์ harness กับชุดทดสอบลับ
มีเพียงคะแนนที่ส่งกลับมา

ดู §8 สำหรับกลไกอธิปไตยเต็มรูปแบบ

7. การตรวจสอบโดยมนุษย์

เมตริกอัตโนมัติเป็นตัวแทน การตรวจสอบโดยมนุษย์คือความจริงพื้นฐาน

7.1 สิ่งที่การตรวจสอบโดยมนุษย์ตรวจพบที่เมตริกพลาด

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

7.2 ประตูการตรวจสอบ

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

7.3 โปรโตคอลการตรวจสอบโดยชุมชน

🔲 วางแผนไว้: อินเทอร์เฟซการตรวจสอบโดยชุมชนยังไม่เปิดใช้งาน ส่วนนี้อธิบายกระบวนการที่ตั้งใจไว้

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

8. อธิปไตย

ชุดข้อมูลการประเมินมีความรู้ทางภาษาที่ดูแลแล้วซึ่งเป็นของชุมชนภาษา ส่วนนี้กำหนดกรอบทางเทคนิคและกฎหมายสำหรับการปกป้องข้อมูลนั้น

8.1 ปัญหา

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

8.2 การดำเนินการในแซนด์บ็อกซ์

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

ขั้นตอน:

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

8.3 การโอนความเป็นเจ้าของ

วิธีการที่ได้คะแนนรวมเท่ากับหรือสูงกว่าเกณฑ์ Deployable (0.70) กับการประเมินมาตรฐานทอง และ ผ่านการตรวจสอบโดยมนุษย์ (§7) จะต้องโอนความเป็นเจ้าของ

นักพัฒนาคงไว้ซึ่ง:

การระบุแหล่งที่มาและเครดิต (ชื่อยังคงอยู่บนลีดเดอร์บอร์ด)
สิทธิ์ในการเผยแพร่เกี่ยวกับวิธีการ
สิทธิ์ในการใช้วิธีการสำหรับคู่ภาษาอื่น

องค์กรกำกับดูแลได้รับ:

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

8.4 ข้อกำหนดองค์กรกำกับดูแล

เพื่อทำหน้าที่เป็นผู้ดูแลหลักสำหรับเกณฑ์มาตรฐานภาษา:

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

8.5 การจัดแนว OCAP® และ CARE

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

8.6 คลาสการพึ่งพาและนโยบายเครือข่ายแซนด์บ็อกซ์

การดำเนินการในแซนด์บ็อกซ์ (§8.2) และการโอนความเป็นเจ้าของ (§8.3) ทั้งสองขึ้นอยู่กับการรู้ว่าวิธีการต้องการอะไรในขณะรันไทม์ ข้อกำหนด Method Interface กำหนดห้าคลาสการพึ่งพา — S (self-contained), O (open external), A1 (substitutable LLM inference), A2 (non-substitutable external API), X (closed) — และ dependency manifest ที่ทุกวิธีการต้องประกาศ ส่วนนี้บันทึกวิธีที่นโยบายเครือข่ายแซนด์บ็อกซ์บังคับใช้

Default-deny egress ข้อกำหนดแซนด์บ็อกซ์กำหนดให้คอนเทนเนอร์วิธีการไม่มีการเข้าถึงเครือข่ายโดยค่าเริ่มต้น นี่ไม่ใช่กฎไฟร์วอลล์ — ข้อกำหนดลบเครือข่ายออกจากสภาพแวดล้อมการดำเนินการ ดังนั้นการพึ่งพาเครือข่ายที่ไม่ได้ประกาศจะล้มเหลวในชั้นสถาปัตยกรรม ไม่ใช่ชั้นนโยบาย วิธีการคลาส S และ O รันทั้งหมดจากอาร์ติแฟกต์ที่รวมอยู่ในการส่งผลงาน (อาร์ติแฟกต์คลาส O ถูกปักหมุดและมิเรอร์เข้ามาในขณะส่งผลงาน)

LLM gateway (🔲 วางแผนไว้) วิธีการส่วนใหญ่เรียก LLM ดังนั้นข้อกำหนดแซนด์บ็อกซ์กำหนดข้อยกเว้น egress หนึ่งรายการ: LLM gateway ที่ดำเนินการโดยโครงสร้างพื้นฐานการประเมิน gateway:

พร็อกซีคำขอ inference ไปยังรายการที่อนุญาตอย่างชัดเจนของโมเดลที่ปักหมุด — ตัวระบุโมเดลที่บันทึกใน manifest และ run card ของวิธีการ;
บันทึกทุกคำขอและการตอบสนอง ในบันทึกการตรวจสอบที่ปิดผนึก เพื่อให้สามารถตรวจสอบการรับส่งข้อมูล gateway เพื่อหาความพยายามในการขโมยข้อมูลก่อนที่คะแนนจะถูกปล่อย;
เป็นเส้นทางเครือข่ายเดียว — ไม่มี egress ทั่วไป ไม่มี DNS ไม่มี endpoint อื่น

นี่คือสิ่งที่ทำให้วิธีการคลาส A1 ประเมินได้โดยไม่ละทิ้งการรับประกันความสามารถในการตรวจสอบของ §8.2 — แต่เป็นการแลกเปลี่ยนที่แท้จริง และข้อกำหนดระบุอย่างชัดเจน: การแปลประโยคต้นฉบับที่เป็นความลับผ่านโมเดลภายนอกเปิดเผยประโยคต้นฉบับนั้นต่อผู้ให้บริการโมเดล การแปลอ้างอิงไม่เคยออกไป (ถือครองโดย harness นอกคอนเทนเนอร์; ดู §8.2) และวิธีการเองยังคงไม่สามารถขโมยข้อมูลอะไรได้นอกเหนือจากสิ่งที่การเรียก inference ที่บันทึกและอนุญาตแล้วมี ว่าการเปิดเผยที่จำกัดนั้นยอมรับได้สำหรับคอร์ปัสที่กำหนดหรือไม่เป็นการตัดสินใจของผู้ดูแล: การอนุญาตการประเมินคลาส A1 หมายถึงการอนุญาตอย่างรู้เท่าทัน ต่อการรัน เหมือนกับการใช้ข้อมูลอื่นๆ ทุกครั้ง

สถานะ แซนด์บ็อกซ์และ gateway ถูกระบุแต่ยังไม่ได้สร้าง จนกว่า gateway จะพร้อมใช้งาน เฉพาะวิธีการคลาส S และ O เท่านั้นที่สามารถผลิตคะแนนมาตรฐานทองได้; วิธีการคลาส A1 ยังคงมีสิทธิ์ได้รับรางวัลในหลักการ (ดู Prize Specification §1.6) แต่ยังไม่สามารถประเมินกับเซกเมนต์ลับได้ การพึ่งพาคลาส A2 ไม่สามารถเข้าสู่แซนด์บ็อกซ์ได้เลยจนกว่าผู้ถือสิทธิ์จะให้อนุญาต — อาร์ติแฟกต์ต้องได้รับอนุญาตให้มีอยู่ในแซนด์บ็อกซ์ก่อนที่คำถามเกี่ยวกับเครือข่ายใดๆ จะเกิดขึ้น

9. ลีดเดอร์บอร์ดและการส่งผลงาน

9.1 ข้อกำหนดการส่งผลงาน

การส่งผลงานลีดเดอร์บอร์ดที่ถูกต้องต้องมี:

run card ที่สมบูรณ์ (§3) พร้อมฟิลด์ที่จำเป็นทั้งหมด
โค้ดวิธีการ — รันได้อย่างสมบูรณ์ พร้อมคำแนะนำการติดตั้ง
การพึ่งพาทั้งหมด — ข้อมูลการฝึกสอน พจนานุกรม ไบนารี FST prompt
รายงานต้นทุน
README ที่อธิบายแนวทางและข้อจำกัดของวิธีการ

9.2 เกณฑ์ความถูกต้อง

ไม่มีการฝึกบนข้อมูลการประเมิน วิธีการต้องไม่ถูกเปิดเผยต่อรายการ gold_standard หรือ held_out (บังคับใช้ทางสถาปัตยกรรม — คุณไม่สามารถฝึกบนข้อมูลที่คุณไม่เคยเห็น)
ประกาศการใช้ข้อมูลการพัฒนา การใช้รายการ development สำหรับ few-shot prompting ได้รับอนุญาตแต่ต้องประกาศ
การทำซ้ำได้ องค์กรกำกับดูแลต้องสามารถรันซ้ำและได้คะแนนภายใน ±2%
การทำให้เป็นนัยทั่วไป วิธีการต้องทำงานกับรายการที่ไม่เคยเห็น ไม่ใช่แค่ตัวอย่างที่จำได้

9.3 การป้องกันการโกง

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

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

ระดับการตรวจสอบอธิบายว่าใครตรวจสอบผลลัพธ์ — ตั้งฉากกับระดับคุณภาพ (§5) ซึ่งอธิบายความหมายของคะแนนอัตโนมัติ

ระดับ	ความหมาย	วิธีการบรรลุ
Self-benchmarked	นักพัฒนารัน harness และส่ง run card	PR หรือแฟล็ก `--submit` กับเซกเมนต์ `development`
GDS Verified	ผู้ดูแลทำซ้ำผลลัพธ์อย่างอิสระ	ส่งวิธีการเป็น plugin ที่ติดตั้งได้; ผู้ดูแลรันซ้ำ
Community Validated	องค์กรกำกับดูแลรันกับ `gold_standard` + การตรวจสอบโดยชุมชน	ส่งโค้ดวิธีการไปยังองค์กรกำกับดูแล (§8.2); ผ่านการตรวจสอบโดยมนุษย์ (§7)

วิธีการสามารถเป็น Self-benchmarked ในระดับคุณภาพ Functional ระดับคุณภาพและระดับการตรวจสอบเป็นแกนอิสระบนลีดเดอร์บอร์ด

9.5 โมเดลการส่งผลงานแบบชั้น

กลไกการส่งผลงานขึ้นอยู่กับเซกเมนต์คอร์ปัสที่คุณประเมิน:

เซกเมนต์	เส้นทางการส่งผลงาน	การตรวจสอบ	ต้องการโค้ดวิธีการ?
`development`	บริการตนเอง: รัน harness ส่ง run card ผ่าน PR หรือ API	Self-benchmarked	ไม่ — คุณเก็บโค้ดของคุณ
`development`	ผู้ดูแลรันซ้ำ: ส่งวิธีการเป็น plugin	GDS Verified	ใช่ — วิธีการต้องติดตั้งได้
`gold_standard`	ส่งวิธีการไปยังองค์กรกำกับดูแล; พวกเขารันในแซนด์บ็อกซ์	Community Validated	ใช่ — วิธีการถูกส่งและถือครอง

เส้นทางบริการตนเอง (เซกเมนต์การพัฒนา) ไม่มีข้อจำกัด เส้นทางอธิปไตย (เซกเมนต์มาตรฐานทอง) ต้องการการส่งวิธีการเต็มรูปแบบเพราะ (a) นักพัฒนาไม่เคยเห็นชุดทดสอบ และ (b) วิธีการที่ถึงระดับ Deployable จะต้องโอนความเป็นเจ้าของ (§8.3)

9.6 คลาสวิธีการ

วิธีการถูกจัดประเภทตามประเภท enum แบบ canonical ถูกกำหนดในโค้ดเบส harness (VALID_METHOD_CLASSES ใน config.py):

คลาส	คำอธิบาย
`raw-llm`	การเรียก LLM โดยตรงโดยไม่มีวิศวกรรมเฉพาะภาษา
`coached-llm`	LLM พร้อมข้อมูลการฝึกสอน (ตัวอย่าง หมายเหตุไวยากรณ์ รายการพจนานุกรม)
`pipeline`	pipeline หลายขั้นตอน (เช่น แปล → ตรวจสอบ FST → ลองใหม่)
`custom-plugin`	plugin `TranslationMethod` แบบกำหนดเอง
`api`	API การแปลภายนอก (Google Translate, DeepL ฯลฯ)
`human`	เส้นฐานนักแปลมนุษย์

9.7 ฟิลด์ลีดเดอร์บอร์ด

ฟิลด์	คำอธิบาย
อันดับ	ตำแหน่งตามคะแนนรวม
ชื่อวิธีการ	ตัวระบุที่นักพัฒนาเลือก
คะแนนรวม	ค่าเฉลี่ยถ่วงน้ำหนักของเมตริกที่มีอยู่ (§4.2)
chrF++	คะแนน character n-gram (0–100)
FST acceptance	อัตราความถูกต้องทางสัณฐานวิทยา (0.0–1.0)
Exact match	อัตราการจับคู่เข้มงวด (0.0–1.0)
Semantic score	การรักษาความหมาย (0.0–1.0) — 🔲 เมื่อพร้อมใช้งาน
ต้นทุนต่อรายการ	USD ต่อรายการคอร์ปัส
ความเร็ว	เวลาแฝงเฉลี่ยต่อรายการ (วินาที)
คะแนนปรับตามต้นทุน	การจัดอันดับรอง (§4.3)
คลาสวิธีการ	จาก enum §9.6
โมเดล	LLM/engine ที่ใช้
ระดับคุณภาพ	ช่วงคะแนนรวมอัตโนมัติ (§5)
ระดับการตรวจสอบ	ผู้ตรวจสอบ (§9.4)
วันที่	เมื่อประเมิน

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

10. กรอบต้นทุน

10.1 ต้นทุนต่อการรัน

run_cost = entries × api_calls_per_entry × cost_per_api_call

ต้นทุนต่อการรันทั่วไปสำหรับคอร์ปัส 150 รายการ:

วิธีการ	โมเดล	ต้นทุนโดยประมาณ
Naive LLM	Gemini 2.5 Flash	$0.15–0.30
Coached LLM	Gemini 2.5 Flash	$0.30–0.60
FST-gated (3 retries)	Gemini 2.5 Flash	$0.45–1.20
Naive LLM	Claude Sonnet 4	$0.45–0.90
Coached LLM	GPT-4.1	$0.60–1.50

10.2 ต้นทุนเกณฑ์มาตรฐาน (Sweep)

sweep_cost = Σ run_cost(i)   for each parameter combination i

Sweep ทั่วไป: 12 โมเดล × 3 อุณหภูมิ × 2 prompt × 2 การฝึกสอน = 144 การรัน ที่ $0.50 เฉลี่ย = **$72 ต่อ sweep**

10.3 การจัดตั้งต่อภาษา

องค์ประกอบ	ช่วงต้นทุน	หมายเหตุ
ค่าตอบแทนผู้พูด (คอร์ปัส)	$2,500–6,000	50–150 รายการที่ $50–65/ชั่วโมง
ค่าตอบแทนผู้พูด (การตรวจสอบ)	$500–1,500	การตรวจสอบผลลัพธ์วิธีการ
การคำนวณ (benchmark sweeps)	$100–500	หลาย sweep ระหว่างการพัฒนา
การคำนวณ (ลีดเดอร์บอร์ดต่อเนื่อง)	$50–200/ปี	การรันวิธีการที่ส่งมา
โครงสร้างพื้นฐาน (แซนด์บ็อกซ์)	$200–500/ปี	โครงสร้างพื้นฐานการประเมินขององค์กรกำกับดูแล
การจัดตั้งรวม	$3,350–8,500

10.4 ขนาดโปรแกรม

ขนาด	ต้นทุนประจำปี	หมายเหตุ
1 ภาษา (การบำรุงรักษา)	$1,000–3,000	หลังการจัดตั้ง
5 ภาษา (การจัดตั้ง + การบำรุงรักษา)	$25,000–65,000	ปีแรก
10 ภาษา (สถานะคงที่)	$15,000–40,000	ต่อปีหลังการจัดตั้ง

11. การขยายไปยังภาษาใหม่

11.1 ข้อกำหนดขั้นต่ำ

50+ รายการ ในเซกเมนต์ gold_standard
30+ รายการ ในเซกเมนต์ development
10+ รายการ ในเซกเมนต์ diagnostic ที่กำหนดเป้าหมายปรากฏการณ์ทางภาษาเฉพาะ
ที่มา สำหรับทุกรายการ
การกระจายความยาก — อย่างน้อย 3 จาก 5 ระดับ
การกระจายรีจิสเตอร์ — อย่างน้อย 2 รีจิสเตอร์
ความยินยอมของชุมชน — ข้อตกลงที่บันทึกไว้จากชุมชนภาษา

11.2 ตัวเลือกแต่มีคุณค่า

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

11.3 เส้นทางที่ช่วยด้วย Agent

🔲 วางแผนไว้: การสร้างคอร์ปัสที่ช่วยด้วย agent เป็นความสามารถในอนาคต

สำหรับภาษาที่ไม่มีทรัพยากรที่มีอยู่มากมาย:

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

ซึ่งลดเวลาผู้พูดจาก ~80 ชั่วโมงเป็น ~30–40 ชั่วโมงต่อภาษา

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

1. หลักการ​

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

1.2 วิธีการ ไม่ใช่โมเดล​

1.3 การทำซ้ำได้​

1.4 ไม่มีข้อมูลการประเมินสังเคราะห์​

2. สคีมาคอร์ปัส​

2.1 ซองข้อมูลชุดข้อมูล​

2.2 สคีมารายการ​

2.3 เซกเมนต์คอร์ปัส​

2.4 ระดับความยาก​

2.5 แท็กที่มา​

2.6 รีจิสเตอร์และบริบท​

2.7 โดเมน​

3. สคีมา Run Card​

3.1 ฟิลด์ระดับบนสุด​

3.2 การกำหนดค่าวิธีการ​

3.3 การอ้างอิงชุดข้อมูล​

3.4 คะแนน (คุณภาพ)​

3.5 ยอดรวม (ต้นทุน)​

3.6 เวลา (ความเร็ว)​

3.7 ผลลัพธ์ต่อรายการ​

3.8 Fingerprint​

3.9 Run Card Hash​

4. เมตริกอัตโนมัติ​

4.1 นิยามเมตริก​

4.2 คะแนนรวม​

4.3 คะแนนปรับตามต้นทุน​

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

6. โปรโตคอลเกณฑ์มาตรฐาน​

6.1 สิ่งที่เกณฑ์มาตรฐานผลิต​

6.2 พื้นที่พารามิเตอร์​

6.3 การกำหนดเส้นฐานเทียบกับการประเมินวิธีการ​

6.4 การประเมินแบบ Dev เทียบกับมาตรฐานทอง​

7. การตรวจสอบโดยมนุษย์​

7.1 สิ่งที่การตรวจสอบโดยมนุษย์ตรวจพบที่เมตริกพลาด​

7.2 ประตูการตรวจสอบ​

7.3 โปรโตคอลการตรวจสอบโดยชุมชน​

8. อธิปไตย​

8.1 ปัญหา​

8.2 การดำเนินการในแซนด์บ็อกซ์​

8.3 การโอนความเป็นเจ้าของ​

8.4 ข้อกำหนดองค์กรกำกับดูแล​

8.5 การจัดแนว OCAP® และ CARE​

8.6 คลาสการพึ่งพาและนโยบายเครือข่ายแซนด์บ็อกซ์​

9. ลีดเดอร์บอร์ดและการส่งผลงาน​

9.1 ข้อกำหนดการส่งผลงาน​

9.2 เกณฑ์ความถูกต้อง​

9.3 การป้องกันการโกง​

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

9.5 โมเดลการส่งผลงานแบบชั้น​

9.6 คลาสวิธีการ​

9.7 ฟิลด์ลีดเดอร์บอร์ด​

10. กรอบต้นทุน​

10.1 ต้นทุนต่อการรัน​

10.2 ต้นทุนเกณฑ์มาตรฐาน (Sweep)​

10.3 การจัดตั้งต่อภาษา​

10.4 ขนาดโปรแกรม​

11. การขยายไปยังภาษาใหม่​

11.1 ข้อกำหนดขั้นต่ำ​

11.2 ตัวเลือกแต่มีคุณค่า​

11.3 เส้นทางที่ช่วยด้วย Agent​