กลยุทธ์ความร่วมมือด้านคลังข้อมูล: การจัดตั้งคลังข้อมูลประเมินผลผ่านภาควิชาภาษาศาสตร์ในสถาบันการศึกษา

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

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

เอกสารประกอบ:

โปรโตคอลการตรวจสอบโดยผู้พูดภาษา — คำขอให้ผู้พูดสองภาษา ทำเครื่องหมาย การแปลที่มีอยู่ (การให้คะแนนคุณภาพ การตรวจสอบด้วย linter การตรวจสอบด้วย FST)

ข้อกำหนดเกณฑ์มาตรฐาน — ข้อกำหนดทางเทคนิคฉบับสมบูรณ์สำหรับคลังข้อมูล run card และโปรโตคอลการประเมินผล

อธิปไตยด้านข้อมูล — OCAP®, CARE และเหตุผลที่การโอนกรรมสิทธิ์มีความสำคัญ

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

1. สิ่งที่ความร่วมมือนี้จะผลิตขึ้น

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

ความร่วมมือนี้จะผลิตผลลัพธ์สามรายการ:

ผลลัพธ์	คืออะไร	ใครควบคุม
คลังข้อมูลพัฒนา	คู่ข้อความคู่ขนานสาธารณะ 100–200+ คู่สำหรับการพัฒนาวิธีการ	เผยแพร่แบบเปิด (CC BY-NC-SA 4.0 หรือเทียบเท่า)
ชุดทดสอบมาตรฐานทอง	คู่ข้อความคู่ขนานลับ 50–150 คู่สำหรับการประเมินผลอย่างเป็นทางการ	องค์กรกำกับดูแลชุมชน (ปิดผนึกด้วยการเข้ารหัสลับ)
ชุดทดสอบวินิจฉัย	คู่ข้อความเปรียบเทียบแบบกำหนดเป้าหมาย 10–50 คู่ที่ทดสอบปรากฏการณ์ทางภาษาศาสตร์เฉพาะ	เผยแพร่แบบเปิด

คลังข้อมูลพัฒนาช่วยให้ทุกคนสามารถสร้างวิธีการแปลได้ ชุดมาตรฐานทองรับประกันว่าวิธีการเหล่านั้นจะถูกทดสอบอย่างซื่อสัตย์ ชุดวินิจฉัยช่วยตรวจจับรูปแบบความล้มเหลวเฉพาะ (เช่น "ระบบนี้จัดการ obviation ได้หรือไม่")

2. สิ่งที่ภาควิชาต้องดำเนินการ

ระยะที่ 1: การออกแบบคลังข้อมูล (2–4 สัปดาห์ เวลาของนักวิจัย)

ผู้นำ: PI หรือนักวิจัยหลังปริญญาเอกที่มีความเชี่ยวชาญในภาษาเป้าหมาย

เลือกโดเมนของวัสดุต้นทาง เลือก 4–6 โดเมนในโลกจริงที่ชุมชนภาษาต้องการการแปลจริง ๆ อนุกรมวิธานของเรารองรับ 16 โดเมน (ดู Benchmark Spec §2.7):

ลำดับความสำคัญ	โดเมน	เหตุผล
🔴 สูง	`edu` — การศึกษา	ตำราเรียน หลักสูตร — ความต้องการของชุมชนโดยตรง
🔴 สูง	`gov` — ราชการ	เอกสารสภาชนเผ่า นโยบาย — ความต้องการในชีวิตประจำวัน
🔴 สูง	`medical` — สุขภาพ	แบบฟอร์มรับผู้ป่วยคลินิก ข้อมูลสุขภาพ — สำคัญต่อความปลอดภัย
🟡 ปานกลาง	`conv` — การสนทนา	การพูดในชีวิตประจำวัน — สร้างพื้นฐานความคล่องแคล่ว
🟡 ปานกลาง	`legal` — กฎหมาย	เอกสารสิทธิ์ สนธิสัญญา — ความสำคัญต่อชุมชน
🟢 ต่ำกว่า	`literary` — วรรณกรรม/วัฒนธรรม	เรื่องเล่า ประวัติศาสตร์บอกเล่า — การอนุรักษ์วัฒนธรรม

ร่างเอกสารออกแบบคลังข้อมูล โดยระบุ:
- ขนาดเป้าหมายต่อส่วน (development, gold_standard, diagnostic)
- การกระจายระดับความยาก (ดู §3.3 ด้านล่าง)
- การครอบคลุมรีจิสเตอร์และโดเมน
- เกณฑ์การเลือกประโยคต้นทาง (ไม่ใช้ข้อความสังเคราะห์ ไม่ใช้เฉพาะพระคัมภีร์)
- แผนการสรรหาผู้พูดภาษา
ส่งการออกแบบให้เราตรวจสอบ เราจะตรวจสอบกับสคีมาคลังข้อมูล (Benchmark Spec §2) และส่งข้อเสนอแนะกลับภายใน 1 สัปดาห์

ระยะที่ 2: การสร้างประโยคต้นทาง (4–8 สัปดาห์ เวลาของผู้พูดภาษา)

ผู้นำ: ผู้ประสานงานวิจัยที่ทำงานร่วมกับผู้พูดสองภาษา

สร้างหรือเลือกประโยคต้นทาง ครอบคลุมโดเมนและระดับความยากที่วางแผนไว้ แหล่งที่มาอาจเป็น:
- วัสดุสองภาษาที่ตีพิมพ์แล้ว (ตำราเรียน เอกสารราชการ)
- ประโยคที่สร้างขึ้นใหม่เพื่อครอบคลุมปรากฏการณ์ทางภาษาศาสตร์เฉพาะ
- ดัดแปลงจากเอกสารในโลกจริง (วาระการประชุมสภาชนเผ่า แบบฟอร์มคลินิก สื่อการศึกษา)
ประโยคต้นทางแต่ละประโยคต้องมี:
- แท็กโดเมน (จากอนุกรมวิธาน 16 รหัส)
- แท็กรีจิสเตอร์ (การสนทนา ทางการ เทคนิค พิธีกรรม การศึกษา)
- แท็กบริบท (การทักทาย การประกาศ คำถาม คำสั่ง การเล่าเรื่อง ป้ายกำกับ ข้อผิดพลาด)
- ระดับความยากโดยประมาณ (1–5 ดู §3.3)
- แท็กที่มา (ตำราเรียน elicited corpus gold_standard)
แปลประโยคต้นทางแต่ละประโยค เป็นภาษาเป้าหมาย โดยผู้พูดสองภาษาเป็นผู้ดำเนินการ การมีการแปลอ้างอิงหลายรายการต่อรายการมีคุณค่าแต่ไม่จำเป็น
เพิ่มการวิเคราะห์ทางสัณฐานวิทยาสำหรับการแปลอ้างอิงแต่ละรายการ (ไม่บังคับ):
- การอธิบายแบบ interlinear gloss (การแยกส่วนทีละหน่วยคำ)
- สตริงแท็ก FST (หากมี FST สำหรับภาษานั้น)
- หมายเหตุของผู้แปลเกี่ยวกับรูปแบบภาษาถิ่น ความกำกวม หรือบริบททางวัฒนธรรม

ระยะที่ 3: การประกันคุณภาพ (2–4 สัปดาห์)

ผู้นำ: นักภาษาศาสตร์ที่มีความเชี่ยวชาญในภาษาเป้าหมาย

การตรวจสอบข้ามกัน การแปลแต่ละรายการควรได้รับการตรวจสอบโดยผู้พูดสองภาษาอย่างน้อยหนึ่งคนที่ไม่ได้เป็นผู้แปลต้นฉบับ ผู้ตรวจสอบจะตรวจสอบ:
- การแปลถูกต้องหรือไม่?
- ฟังดูเป็นธรรมชาติหรือไม่?
- การให้คะแนนความยากถูกต้องหรือไม่?
- มีรูปแบบที่ยอมรับได้ที่ควรบันทึกไว้หรือไม่?
รันผ่านตัวตรวจสอบสคีมาของเรา เราจัดเตรียมสคริปต์ที่ตรวจสอบคลังข้อมูลกับสคีมารายการ (Benchmark Spec §2.2) โดยตรวจสอบ:
- ฟิลด์ที่จำเป็นครบถ้วน
- รหัสโดเมนถูกต้อง
- ระดับความยากเป็นจำนวนเต็ม 1–5
- ไม่มี ID ซ้ำกัน
- การเข้ารหัสอักขระ (การทำให้เป็นมาตรฐาน UTF-8 NFC)
หากมี FST สำหรับภาษานั้น ให้รันการแปลอ้างอิงผ่าน FST ทุกคำในการอ้างอิงควรผ่านการตรวจสอบ FST คำที่ไม่ผ่าน (คำยืม คำใหม่ ชื่อเฉพาะ) ควรบันทึกไว้ใน allowlist

ระยะที่ 4: การแบ่งส่วนและการปิดผนึก (1 สัปดาห์ วิศวกรรมของเรา)

ผู้นำ: ทีม Champollion โดยมีภาควิชาตรวจสอบ

การแบ่งแบบ stratified เราแบ่งคลังข้อมูลออกเป็นส่วนต่าง ๆ โดยใช้การสุ่มตัวอย่างแบบกำหนดได้ (seed ที่บันทึกไว้ สามารถทำซ้ำได้):

ส่วน	ขนาดเป้าหมาย	การเข้าถึง
`development`	60% ของรายการ (ขั้นต่ำ 100)	สาธารณะ
`gold_standard`	30% ของรายการ (ขั้นต่ำ 50)	ลับ ปิดผนึก
`held_out`	10% ของรายการ (ขั้นต่ำ 10)	ลับ ปิดผนึก ไม่ใช้จนกว่าจะเปิดใช้งาน

การแบ่งจะรักษาการกระจายระดับความยาก (การสุ่มตัวอย่างแบบ stratified) เพื่อให้แต่ละส่วนมีการแทนค่าตามสัดส่วนในทุกระดับ

การปิดผนึกด้วยการเข้ารหัสลับ ของส่วน gold_standard และ held_out:

1. SHA-256 hash of each entry (source + reference + metadata)
2. SHA-256 hash of the complete segment file
3. Segment file encrypted with AES-256-GCM
4. Encryption key split using Shamir Secret Sharing (2-of-3 threshold)
5. Key shares distributed to:
     - Share 1: Community governance organization
     - Share 2: Academic department partner
     - Share 3: Champollion project (escrow)
6. Hash manifest published to a public commit (proves the corpus existed
   at a specific time without revealing its contents)

ส่วน development จะถูก commit ไปยัง repository สาธารณะและเผยแพร่พร้อมการอนุญาตสิทธิ์ครบถ้วน
ส่วน diagnostic ก็เป็นสาธารณะเช่นกัน — ทดสอบปรากฏการณ์ทางภาษาศาสตร์เฉพาะ (ดู §3.4)

ระยะที่ 5: การรวมระบบและการเปิดตัว (1–2 สัปดาห์ วิศวกรรมของเรา)

การกำหนดค่า harness เราเพิ่มภาษาเข้าสู่ evaluation harness:
- สร้างหรือตรวจสอบ language card
- ลงทะเบียนคลังข้อมูลใน dataset registry
- กำหนดค่าเมตริก LYSS (LYSS-fst หากมี FST, LYSS-eq หากมีกฎ linter)
- เลือก scoring profile เริ่มต้น (Profile A หากมี FST, Profile B ในกรณีอื่น)
เกณฑ์มาตรฐานพื้นฐาน เราทำการทดสอบ 12 โมเดลกับส่วน development เพื่อเติมข้อมูลเริ่มต้นใน leaderboard
การประกาศสาธารณะ ภาษาจะปรากฏบน Arena leaderboard พร้อมเกณฑ์มาตรฐาน development segment แบบสด โดยระบุภาควิชาเป็นพันธมิตรคลังข้อมูล

3. รูปแบบที่คลังข้อมูลต้องมี

3.1 รูปแบบ

ไฟล์คลังข้อมูลทุกไฟล์เป็นเอกสาร JSON ตามสคีมาใน Benchmark Spec §2.1–§2.2:

{
  "dataset": {
    "id": "crk-ualberta-v1",
    "version": "1.0",
    "language_pair": "EN→CRK",
    "source_language": "en",
    "target_language": "crk",
    "created": "2026-09-15",
    "license": "CC-BY-NC-SA-4.0",
    "provenance": ["textbook", "elicited", "gold_standard"]
  },
  "entries": [
    {
      "id": 1,
      "source": "I see the dog",
      "reference": "niwâpamâw atim",
      "segment": "development",
      "difficulty": 2,
      "provenance": "textbook",
      "register": "conversational",
      "context": "declaration",
      "domain": "edu",
      "morphological_analysis": "ni-wâpam-âw atim | 1sg-see.TA-3sg.DIR dog.AN",
      "notes": "Animate noun (atim); direct form because speaker is proximate"
    }
  ]
}

3.2 ข้อกำหนดขนาดขั้นต่ำ

ส่วน	รายการขั้นต่ำ	แนะนำ
`development`	100	200–300
`gold_standard`	50	100–150
`diagnostic`	10	30–50
`held_out`	10	20–30
รวม	170	350–530

3.3 การกระจายระดับความยาก

คลังข้อมูลต้องมีรายการครอบคลุมทุกห้าระดับความยาก โดยเน้นที่ระดับ 2–4:

ระดับ	คำอธิบาย	การกระจายเป้าหมาย
1 — คำศัพท์พื้นฐาน	คำเดี่ยว การทักทายทั่วไป ตัวเลข	10–15%
2 — ประโยคง่าย	SVO กาลปัจจุบัน	25–30%
3 — ความซับซ้อนปานกลาง	กาลอดีต/อนาคต การแสดงความเป็นเจ้าของ animacy	30–35%
4 — สัณฐานวิทยาซับซ้อน	Obviation passive conjunct order อนุประโยคสัมพันธ์	15–20%
5 — ขั้นสูง	หลายอนุประโยค รีจิสเตอร์ทางการ พิธีกรรม สำนวน	5–10%

3.4 ชุดทดสอบวินิจฉัย

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

สำหรับภาษา polysynthetic ชุดทดสอบวินิจฉัยควรกำหนดเป้าหมายที่:

ปรากฏการณ์	ตัวอย่าง (Cree)	สิ่งที่ทดสอบ
การสอดคล้องของ animacy	atim (AN) vs. maskisin (IN) — รูปแบบกริยาต่างกัน	ระบบรู้หรือไม่ว่าคำนามใดมีชีวิต?
Obviation	บุรุษที่สามแบบ proximate vs. obviative	ระบบติดตามลำดับชั้นบุรุษที่สามได้หรือไม่?
Inverse marking	รูปแบบกริยา direct vs. inverse	ระบบจัดการกรณีที่ผู้รับกระทำมีลำดับสูงกว่าผู้กระทำได้หรือไม่?
Conjunct/Independent	ลำดับกริยาในประโยคหลัก vs. ประโยคย่อย	ระบบใช้ paradigm กริยาที่ถูกต้องหรือไม่?
Inclusive/Exclusive	"เรา (รวมคุณ)" vs. "เรา (ไม่รวมคุณ)"	ระบบแยกแยะรูปแบบพหูพจน์บุรุษที่หนึ่งได้หรือไม่?

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

3.5 สิ่งที่เราไม่ต้องการ

รูปแบบที่ไม่พึงประสงค์	เหตุผล
ข้อความจากพระคัมภีร์เท่านั้น	รีจิสเตอร์โบราณ คำศัพท์พิธีกรรม โครงสร้างสูตรสำเร็จ OMT-1600 ประเมิน 1,560 ภาษาด้วยวิธีนี้ — เราหลีกเลี่ยงโดยเจตนา
คู่ประเมินผลสังเคราะห์	การอ้างอิงที่สร้างโดย LLM ทำลายวัตถุประสงค์ของการประเมินผล การอ้างอิงต้องเป็นงานของมนุษย์
คลังข้อมูลรีจิสเตอร์เดียว	ทางการทั้งหมด หรือการสนทนาทั้งหมด การแปลในโลกจริงครอบคลุมหลายรีจิสเตอร์
เฉพาะระดับความยาก 1	คำเดี่ยวและการทักทายไม่ได้ทดสอบการแปล — แต่ทดสอบการค้นหาคำศัพท์
การอ้างอิงที่แปลด้วยเครื่อง	การใช้ผลลัพธ์ Google Translate เป็น "การอ้างอิง" เป็นการวนซ้ำแบบวงกลม
ประโยคที่ไม่มีแท็กบริบท	เราต้องการทราบฟังก์ชันการสื่อสารสำหรับการวิเคราะห์วินิจฉัย

4. การปิดผนึกด้วยการเข้ารหัสลับและการทดสอบในแซนด์บ็อกซ์

4.1 เหตุใดจึงต้องปิดผนึกชุดทดสอบ?

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

การปิดผนึกรับประกัน:

ความสมบูรณ์ของชุดทดสอบ: วิธีการต่าง ๆ ไม่สามารถ overfit กับข้อมูลที่ไม่เคยเห็น
อธิปไตยด้านข้อมูล: ชุมชนควบคุมว่าใครประเมินผลกับข้อมูลของตน
ความสดใหม่ตลอดกาล: ชุดทดสอบไม่มีวันถูกปนเปื้อน

4.2 การทำงานของการทดสอบในแซนด์บ็อกซ์

Developer workflow:
  1. Developer builds a translation method using the PUBLIC development corpus
  2. Developer tests locally against the development segment (unlimited, self-serve)
  3. When ready, developer submits their complete method (code + config + coaching data)
  4. Governance org installs the method in the evaluation sandbox
  5. Sandbox runs the method against the SEALED gold-standard test set
  6. Only scores are returned to the developer
  7. Developer never sees the source sentences or reference translations

The sandbox:
  - Runs on governance-controlled infrastructure
  - Has selective network access (LLM APIs only, no exfiltration)
  - Produces a tamper-proof run card (SHA-256 hash of all inputs and outputs)
  - Logs all execution for audit purposes
  - Can be inspected by the governance org at any time

4.3 การจัดการคีย์

คีย์เข้ารหัสสำหรับชุดทดสอบที่ปิดผนึกถูกแบ่งโดยใช้ Shamir Secret Sharing ด้วยเกณฑ์ 2-of-3:

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

ส่วนแบ่งใด ๆ 2 ใน 3 จะสร้างคีย์ขึ้นใหม่ได้ ซึ่งหมายความว่า:

ชุมชน + ภาควิชาสามารถเข้าถึงข้อมูลได้โดยไม่ต้องมี Champollion
ชุมชน + Champollion สามารถเข้าถึงข้อมูลได้โดยไม่ต้องมีภาควิชา
Champollion เพียงฝ่ายเดียวไม่สามารถเข้าถึงข้อมูลได้เลย

4.4 Hash Manifest

เมื่อปิดผนึกคลังข้อมูล hash manifest จะถูกเผยแพร่ไปยัง Git commit สาธารณะ:

{
  "corpus_id": "crk-ualberta-v1",
  "seal_date": "2026-09-15T00:00:00Z",
  "segments": {
    "development": {
      "entry_count": 200,
      "sha256": "a3f7c...",
      "access": "public"
    },
    "gold_standard": {
      "entry_count": 100,
      "sha256": "b8d2e...",
      "access": "sealed",
      "key_scheme": "shamir-2-of-3"
    },
    "held_out": {
      "entry_count": 20,
      "sha256": "c9e4f...",
      "access": "sealed",
      "key_scheme": "shamir-2-of-3"
    },
    "diagnostic": {
      "entry_count": 30,
      "sha256": "d1a3b...",
      "access": "public"
    }
  },
  "total_entries": 350,
  "manifest_sha256": "e2b5c..."
}

สิ่งนี้พิสูจน์ว่า:

คลังข้อมูลมีอยู่จริงในวันที่เฉพาะเจาะจง
มีขนาดและโครงสร้างที่ทราบแน่ชัด
การแก้ไขใด ๆ ต่อส่วนที่ปิดผนึกจะทำลาย hash chain
ชุมชนสามารถตรวจสอบได้ว่าข้อมูลของตนไม่ถูกดัดแปลง

5. สิ่งที่ภาควิชาจะได้รับ

5.1 โครงสร้างพื้นฐานการวิจัย

สินทรัพย์	คำอธิบาย
Evaluation harness	กรอบการประเมินผลที่ใช้งานได้และทดสอบแล้วสำหรับภาษาของตน — ประหยัดเวลาการสร้างเครื่องมือหลายเดือน
เมตริก LYSS	เมตริกการประเมินผลเฉพาะภาษา (LYSS-fst, LYSS-eq, LYSS-sem) ที่กำหนดค่าสำหรับภาษาของตน — หากมีทรัพยากร FST และพจนานุกรม
Leaderboard	leaderboard สาธารณะแบบสดที่แสดงสถานะของศิลปะสำหรับคู่ภาษาของตน
เกณฑ์มาตรฐานพื้นฐาน	การทดสอบ 12 โมเดลที่ให้เกณฑ์มาตรฐานเริ่มต้นที่สามารถตีพิมพ์ได้ทันที
ชุดทดสอบวินิจฉัย	การทดสอบแบบกำหนดเป้าหมายสำหรับปรากฏการณ์ทางภาษาศาสตร์เฉพาะ — นำกลับมาใช้ใหม่ได้สำหรับการประเมินผลอื่น ๆ

5.2 สิ่งตีพิมพ์

การสร้างคลังข้อมูลและผลการประเมินผลรองรับสิ่งตีพิมพ์หลายรายการ:

บทความ	สถานที่ตีพิมพ์	บทบาทของภาควิชา
วิธีการสร้างคลังข้อมูล	LREC, ComputEL	ผู้แต่งหลักหรือผู้แต่งร่วม
ผลการประเมินผลเกณฑ์มาตรฐาน	ACL, EMNLP	ผู้แต่งร่วม
การตรวจสอบเมตริก LYSS	WMT Metrics Shared Task	ผู้แต่งร่วม
การออกแบบชุดทดสอบวินิจฉัย	SIGMORPHON, NAACL	ผู้แต่งหลักหรือผู้แต่งร่วม
ทรัพยากร NLP เฉพาะภาษา	สถานที่ตีพิมพ์เฉพาะภาษา	ผู้แต่งหลัก

5.3 การวางตำแหน่งสำหรับทุนวิจัย

ความร่วมมือนี้ให้ผลลัพธ์ที่เป็นรูปธรรมสำหรับข้อเสนอทุนวิจัย:

"โครงสร้างพื้นฐานการประเมินผล open-source สำหรับ MT ภาษา [ภาษา]" — ผลส่งมอบที่พิสูจน์ได้
"อธิปไตยด้านข้อมูลด้วยการเข้ารหัสลับสำหรับข้อมูลภาษาศาสตร์พื้นเมือง" — ใหม่ สามารถตีพิมพ์ได้
"เกณฑ์มาตรฐานที่กำกับดูแลโดยชุมชนพร้อม leaderboard แบบสด" — เมตริกผลกระทบต่อเนื่อง
"การประเมินผลอิสระของ OMT-1600 / Google Translate สำหรับภาษา [ภาษา]" — ทันเวลา มีการมองเห็นสูง

5.4 ผลกระทบต่อชุมชน

ชุมชนภาษาได้รับ ความสามารถในการประเมินผลอิสระ — สามารถประเมินได้ว่าระบบ MT ใด ๆ (Google, Meta หรือแบบกำหนดเอง) ทำงานได้จริงสำหรับภาษาของตนหรือไม่
ชุมชน ควบคุมข้อมูลทดสอบ ผ่านการดูแลคีย์เข้ารหัสลับ
วิธีการใด ๆ ที่พิสูจน์ผ่านเกณฑ์มาตรฐาน โอนกรรมสิทธิ์ไปยังชุมชน (ดู Benchmark Spec §8.3)
รายได้จากวิธีการที่ใช้งานจริงไหลไปยังชุมชน (การแบ่ง 90/10)

5.5 ต้นทุนสำหรับภาควิชา

ส่วนประกอบ	ต้นทุนโดยประมาณ	ใครจ่าย
เวลา PI/นักวิจัยหลังปริญญาเอก (การออกแบบ การดูแล)	~40 ชั่วโมง	ภาควิชา (หรือได้รับทุนสนับสนุน)
ค่าตอบแทนผู้พูดภาษา (การแปล)	$2,500–6,000	ได้รับทุนสนับสนุนหรือ Champollion เป็นผู้จ่าย
ค่าตอบแทนผู้พูดภาษา (การตรวจสอบ)	$500–1,500	ได้รับทุนสนับสนุนหรือ Champollion เป็นผู้จ่าย
เวลาผู้ประสานงานวิจัย	~20 ชั่วโมง	ภาควิชา
วิศวกรรม โครงสร้างพื้นฐาน harness	$0	โครงการ Champollion

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

6. ไทม์ไลน์

ระยะ	ระยะเวลา	เหตุการณ์สำคัญ
1: การออกแบบคลังข้อมูล	2–4 สัปดาห์	เอกสารออกแบบได้รับการอนุมัติ
2: ประโยคต้นทาง + การแปล	4–8 สัปดาห์	คลังข้อมูลดิบเสร็จสมบูรณ์
3: การประกันคุณภาพ	2–4 สัปดาห์	ตรวจสอบข้ามกัน ตรวจสอบสคีมาแล้ว
4: การปิดผนึก	1 สัปดาห์	มาตรฐานทองปิดผนึก เผยแพร่ hash manifest แล้ว
5: การรวมระบบ	1–2 สัปดาห์	ภาษาแสดงบน leaderboard พร้อมเกณฑ์มาตรฐาน
รวม	10–19 สัปดาห์	leaderboard แบบสดพร้อมการประเมินผลที่ปิดผนึก

7. วิธีเริ่มต้น

ติดต่อเรา — [อีเมล/ช่องทางติดต่อโครงการ] เราจะนัดหมายการโทรประชุม 30 นาทีเพื่อหารือเกี่ยวกับภาษา ทรัพยากรที่มีอยู่ และรายละเอียดความร่วมมือ
เราจัดเตรียม:
- เอกสารนี้
- สคีมาคลังข้อมูลและเครื่องมือตรวจสอบ
- ตัวอย่างจากคลังข้อมูล Cree (CRK) ที่มีอยู่ของเรา
- เทมเพลตออกแบบคลังข้อมูลฉบับร่าง
คุณจัดเตรียม:
- PI หรือนักวิจัยหลังปริญญาเอกเพื่อนำงานทางภาษาศาสตร์
- การเข้าถึงผู้พูดสองภาษา (หรือแผนการสรรหา)
- ข้อมูลเกี่ยวกับทรัพยากรที่มีอยู่ (FST พจนานุกรม คลังข้อมูลที่มีอยู่)
- การอนุมัติจากสถาบันสำหรับการกำกับดูแลข้อมูล (การปฏิบัติตาม OCAP® หรือเทียบเท่า)
เราออกแบบคลังข้อมูลร่วมกัน — การเลือกโดเมน การกระจายระดับความยาก การทดสอบวินิจฉัย ไทม์ไลน์ และงบประมาณ
เริ่มงาน เราตรวจสอบทุกสัปดาห์ ภาควิชามีอำนาจตัดสินใจเต็มที่ในการตัดสินใจทางภาษาศาสตร์ เราดูแลวิศวกรรมทั้งหมด

8. คำถามที่พบบ่อย

"เรามีคลังข้อมูลคู่ขนานอยู่แล้ว สามารถใช้ได้หรือไม่?"

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

"เราไม่มี FST สำหรับภาษาของเรา"

ไม่เป็นไร LYSS-fst (ความถูกต้องทางสัณฐานวิทยา) ต้องการ FST แต่ harness ทำงานได้โดยไม่มีโดยใช้น้ำหนัก Profile B (chrF++, BLEU, COMET, เมตริกพฤติกรรม) หากมี GiellaLT FST สำหรับภาษาที่เกี่ยวข้อง เราอาจสามารถปรับใช้ได้ หากไม่มี คลังข้อมูลยังคงเปิดใช้งานการประเมินผลที่มีคุณค่า — เพียงแต่ไม่มีประตูตรวจสอบความถูกต้องทางสัณฐานวิทยา

"ผู้พูดภาษาของเราใช้อักษรที่ไม่ใช่ Latin"

รองรับอย่างสมบูรณ์ สคีมาคลังข้อมูลรองรับอักษร Unicode ใด ๆ เราออกแบบสำหรับ SRO (Standard Roman Orthography) และ syllabics สำหรับ Cree แต่โครงสร้างพื้นฐานเดียวกันทำงานได้กับ Devanagari อักษรอาหรับ CJK Ethiopic หรือระบบการเขียนอื่น ๆ

"แล้วความหลากหลายของภาษาถิ่นล่ะ?"

ติดแท็กไว้ สคีมารายการคลังข้อมูลมีฟิลด์ notes สำหรับข้อมูลภาษาถิ่น หากมีการแทนค่าหลายภาษาถิ่น ให้บันทึกไว้ คลาสความเท่าเทียมของ linter (LYSS-eq) สามารถกำหนดค่าให้ยอมรับรูปแบบภาษาถิ่นเป็นสิ่งที่เทียบเท่ากันได้ ชุดทดสอบวินิจฉัยสามารถรวมการเปรียบเทียบเฉพาะภาษาถิ่นได้

"ใครเป็นเจ้าของคลังข้อมูล?"

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

"ถ้าเราต้องการหยุดล่ะ?"

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

"ถ้าองค์กรกำกับดูแลยังไม่มีอยู่ล่ะ?"

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

ภาคผนวก: การติดแท็กเทียบกับการสร้างคลังข้อมูล

เอกสารนี้ครอบคลุม การสร้างคลังข้อมูล — การสร้างคู่ข้อความคู่ขนานที่เป็นมาตรฐานอ้างอิงสำหรับการประเมินผล การติดแท็ก (การอธิบายทางสัณฐานวิทยา การอธิบายแบบ interlinear gloss สตริงแท็ก FST) เป็นกิจกรรมแยกต่างหากที่เพิ่มคุณค่าให้คลังข้อมูลแต่ไม่จำเป็นสำหรับการประเมินผลพื้นฐาน

กิจกรรม	จำเป็นหรือไม่?	สิ่งที่เปิดใช้งาน
การสร้างคลังข้อมูล (เอกสารนี้)	✅ จำเป็น	การประเมินผลพื้นฐาน: chrF++, exact match, COMET, เมตริกพฤติกรรม
การตรวจสอบความครอบคลุม FST	🟡 ไม่บังคับ	เมตริกความถูกต้องทางสัณฐานวิทยา LYSS-fst
การอธิบายทางสัณฐานวิทยา	🟡 ไม่บังคับ	เมตริก `morphological_accuracy` (Scoring Spec §2.2)
กฎความเท่าเทียมของ linter	🟡 ไม่บังคับ	เมตริก equivalent match ของ LYSS-eq
กฎตัวตรวจสอบความหมาย	🟡 ไม่บังคับ	เมตริกการตรวจสอบความหมาย LYSS-sem
การให้คะแนนคุณภาพโดยผู้พูดภาษา	กิจกรรมแยกต่างหาก	การตรวจสอบเมตริก (ดู โปรโตคอลการตรวจสอบโดยผู้พูดภาษา)

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

1. สิ่งที่ความร่วมมือนี้จะผลิตขึ้น​

2. สิ่งที่ภาควิชาต้องดำเนินการ​

ระยะที่ 1: การออกแบบคลังข้อมูล (2–4 สัปดาห์ เวลาของนักวิจัย)​

ระยะที่ 2: การสร้างประโยคต้นทาง (4–8 สัปดาห์ เวลาของผู้พูดภาษา)​

ระยะที่ 3: การประกันคุณภาพ (2–4 สัปดาห์)​

ระยะที่ 4: การแบ่งส่วนและการปิดผนึก (1 สัปดาห์ วิศวกรรมของเรา)​

ระยะที่ 5: การรวมระบบและการเปิดตัว (1–2 สัปดาห์ วิศวกรรมของเรา)​

3. รูปแบบที่คลังข้อมูลต้องมี​

3.1 รูปแบบ​

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

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

3.4 ชุดทดสอบวินิจฉัย​

3.5 สิ่งที่เราไม่ต้องการ​

4. การปิดผนึกด้วยการเข้ารหัสลับและการทดสอบในแซนด์บ็อกซ์​

4.1 เหตุใดจึงต้องปิดผนึกชุดทดสอบ?​

4.2 การทำงานของการทดสอบในแซนด์บ็อกซ์​

4.3 การจัดการคีย์​

4.4 Hash Manifest​

5. สิ่งที่ภาควิชาจะได้รับ​

5.1 โครงสร้างพื้นฐานการวิจัย​

5.2 สิ่งตีพิมพ์​

5.3 การวางตำแหน่งสำหรับทุนวิจัย​

5.4 ผลกระทบต่อชุมชน​

5.5 ต้นทุนสำหรับภาควิชา​

6. ไทม์ไลน์​

7. วิธีเริ่มต้น​

8. คำถามที่พบบ่อย​

"เรามีคลังข้อมูลคู่ขนานอยู่แล้ว สามารถใช้ได้หรือไม่?"​

"เราไม่มี FST สำหรับภาษาของเรา"​

"ผู้พูดภาษาของเราใช้อักษรที่ไม่ใช่ Latin"​

"แล้วความหลากหลายของภาษาถิ่นล่ะ?"​

"ใครเป็นเจ้าของคลังข้อมูล?"​

"ถ้าเราต้องการหยุดล่ะ?"​

"ถ้าองค์กรกำกับดูแลยังไม่มีอยู่ล่ะ?"​

ภาคผนวก: การติดแท็กเทียบกับการสร้างคลังข้อมูล​