การรายงานข้อผิดพลาดและการเป็นเจ้าของการแก้ไข
จุดยืน. การผิดพลาดเป็นสิ่งที่หลีกเลี่ยงไม่ได้สำหรับแพลตฟอร์มที่เผยแพร่ข้อเท็จจริงและการประเมินผลเกี่ยวกับภาษาหลายพันภาษา สิ่งที่ ไม่จำเป็น ต้องเป็นเช่นนั้นคือ ใครจะได้รับความเชื่อถือเมื่อมีการรายงานข้อผิดพลาด และใครเป็นเจ้าของการแก้ไข คำตอบของเราคือ รายงานจากผู้พูดภาษาที่คล่องแคล่วมีน้ำหนักเหนือกว่าระบบอัตโนมัติของเรา การแก้ไขทุกครั้งมีข้อมูลที่มาระบุว่าใครเปลี่ยนแปลงอะไรและเพราะเหตุใด และชุมชนสามารถถอนหรือยับยั้งการใช้ข้อมูลภาษาของตนได้ — ไม่ใช่เพียงความอนุเคราะห์ แต่เป็นคุณสมบัติที่บังคับใช้ได้ในระดับสถาปัตยกรรม
แพลตฟอร์มข้อมูลส่วนใหญ่ปฏิบัติต่อรายงานข้อผิดพลาดเหมือนตั๋วสนับสนุน: ผู้ใช้ร้องเรียน ผู้ดูแลตัดสินใจ บันทึกเปลี่ยนแปลงโดยไม่มีการแจ้ง สำหรับข้อมูลภาษาพื้นเมือง โมเดลนั้นกลับหัวกลับหาง ผู้รายงานข้อผิดพลาดมักมีอำนาจมากกว่าแพลตฟอร์ม — ผู้พูดที่บอกว่าคำหนึ่งผิดไม่ใช่ "ผู้ใช้" แต่คือแหล่งความจริงที่กำลังแก้ไขตัวแทน การออกแบบด้านล่างนี้เกิดจากการนำหลักการนั้นมาปฏิบัติอย่างจริงจัง
ข้อผิดพลาดสองประเภท หลักการเดียว
แพลตฟอร์มเผยแพร่การอ้างสิทธิ์สองประเภทที่อาจผิดพลาดได้:
- ข้อเท็จจริงเกี่ยวกับภาษา — การ์ดภาษาที่ขับเคลื่อนการประเมินผล: ข้อมูลการจำแนก ระบบการเขียน คุณลักษณะทางภาษาศาสตร์ และเมตริกที่ใช้ การ์ดอาจระบุจำนวนผู้พูดผิด ความสัมพันธ์ของสำเนียงผิด หรือสถานะระบบการเขียนผิด
- การตัดสินเกี่ยวกับการแปล — การแปลอ้างอิงในคลังข้อมูลที่ผู้พูดเห็นว่าผิดหรือไม่เป็นธรรมชาติ เมตริกอัตโนมัติที่ปฏิเสธคำที่ถูกต้องหรือยอมรับคำที่ไม่ถูกต้อง หรือป้าย "Deployable" บนผลลัพธ์ที่ผู้พูดไม่ยอมรับ
หลักการที่ครอบคลุมทั้งสองประเภท ซึ่งมีผลผูกพันแล้วใน Scoring Specification และ Benchmark Specification §7: ผลลัพธ์อัตโนมัติเป็นเพียงตัวแทน ผู้พูดคือแหล่งความจริง พันธกิจที่เผยแพร่ใน Speaker Validation Protocol §6 ระบุอย่างตรงไปตรงมา: หากผู้พูดบอกว่า linter ผิดในเรื่องใด เราจะแก้ไข linter
เส้นทางของรายงาน
นี่คือเส้นทางที่รายงานดำเนินไป พร้อมสถานะที่ตรงไปตรงมา — บางส่วนทำงานอยู่แล้วในปัจจุบัน บางส่วนระบุไว้แล้วแต่ยังไม่ได้สร้าง
การรายงานการแปลที่ผิดหรือการตัดสินของเมตริก (ทำงานอยู่แล้วในปัจจุบัน ผ่านช่องทางตรง) ผู้พูดที่พบการแปลอ้างอิงที่ผิด คำที่ถูกปฏิเสธโดยไม่มีเหตุผล หรือ "คำเทียบเท่า" ที่ยอมรับไม่ได้ สามารถรายงานผ่าน issue tracker ของ repository สาธารณะของโครงการ หรือติดต่อโครงการโดยตรง เวอร์ชันที่มีโครงสร้าง — หน้าจอการให้คะแนนพร้อมตัวเลือก reject / gist / acceptable / excellent และหมายเหตุข้อความอิสระ — คือส่วนติดต่อการตรวจสอบของชุมชน ซึ่งระบุไว้ใน Benchmark Specification §7.3 แต่ยังไม่เปิดใช้งาน จนกว่าจะพร้อม รายงานจะได้รับการจัดการแบบตัวต่อตัว และงานตรวจสอบ (การตรวจสอบโดยผู้พูดที่มีโครงสร้างและได้รับค่าตอบแทน — ดู How Speakers Get Paid) คือช่องทางการแก้ไขหลัก
การรายงานข้อเท็จจริงที่ผิดบนการ์ดภาษา (ทำงานอยู่แล้วในปัจจุบัน ช่องทางเดียวกัน) การแก้ไขการ์ดดำเนินตามเส้นทางเดียวกัน: รายงาน ตรวจสอบ เปลี่ยนแปลงพร้อมเวอร์ชัน เนื่องจากการ์ดขับเคลื่อนพฤติกรรมการประเมินผล — เมตริกใดที่โหลด โมเดลใดที่แนะนำ — การแก้ไขการ์ดอาจเปลี่ยนคะแนน ดังนั้นการแก้ไขจึงถูกนำไปใช้เป็นการเปลี่ยนแปลงข้อมูลที่บันทึกไว้ ไม่ใช่การแก้ไขแบบเงียบ
สิ่งที่เกิดขึ้นต่อไป — ใครเป็นผู้ตัดสินใจ:
- การตัดสินทางภาษาศาสตร์เป็นของผู้พูดภาษานั้น ไม่ว่าจะเป็นรูปแบบที่ถูกต้อง ความเทียบเท่าของสองวลี หรือความเหมาะสมของระดับภาษา — แพลตฟอร์มนำคำตอบไปปฏิบัติ ไม่ใช่ผู้ให้คำตอบ ในกรณีที่ผู้พูดไม่เห็นด้วย (สำเนียง ข้อตกลงการเขียน) คำตอบจะถูกบันทึกเป็นความหลากหลาย ไม่ใช่ตัดสินโดยเรา — สคีมาของคลังข้อมูลและ linter รองรับการแท็กตัวแปรตามสำเนียงเป็นทางเลือกที่ยอมรับได้ แทนที่จะบังคับให้มีผู้ชนะเพียงหนึ่งเดียว
- การตัดสินใจเกี่ยวกับข้อมูลของชุมชนเป็นของหน่วยงานกำกับดูแลของชุมชนนั้น สำหรับภาษาที่มีหน่วยงานกำกับดูแล การเปลี่ยนแปลงคลังข้อมูลการประเมิน การยอมรับการแก้ไขเข้าสู่ชุดทดสอบที่ปิดผนึก และผลที่ตามมาจากการนำไปใช้งาน ล้วนดำเนินผ่านหน่วยงานนั้น — นั่นคือหลักการ Control ของ OCAP® ที่นำไปปฏิบัติเป็นกระบวนการ ไม่ใช่โปสเตอร์
- ข้อผิดพลาดเชิงกลไกแก้ไขได้เลย การพิมพ์ผิด ลิงก์เสีย ฟิลด์ที่แยกวิเคราะห์ผิด — รายงาน แก้ไข บันทึก ไม่ใช่ทุกเรื่องที่ต้องการสภา
การแก้ไขมีข้อมูลที่มา
การแก้ไขที่ไม่สามารถตรวจสอบย้อนกลับได้คือเพียงความเห็นที่ใหม่กว่า กฎข้อมูลที่มาสามข้อใช้กับทุกข้อเท็จจริงและทุกการแก้ไข:
- ทุกข้อเท็จจริงระบุแหล่งที่มา การ์ดภาษาและรายการในคลังข้อมูลบันทึกว่าแต่ละค่ามาจากไหน — ชุดข้อมูลที่เผยแพร่ การมีส่วนร่วมของชุมชน หรือการตรวจสอบของผู้พูด
- ค่าที่ได้จากการคำนวณถูกระบุว่าเป็นของเรา ไม่ใช่ของต้นทาง เมื่อแพลตฟอร์มคำนวณบางอย่าง — การรวม การเข้ารหัสใหม่ คะแนนรวม — จะถูกบันทึกเป็นการอนุมานของแพลตฟอร์ม จาก แหล่งต้นทาง ไม่ใช่เขียนภายใต้ชื่อของต้นทาง ชุดข้อมูลต้นทางไม่ควรถูกตำหนิหรือให้เครดิตกับตัวเลขที่ไม่ได้เผยแพร่
- การแก้ไขกลายเป็นส่วนหนึ่งของบันทึก การแก้ไขของผู้พูดถูกบันทึกเป็นการยืนยันใหม่ที่มีการระบุที่มา (ระบุชื่อหรือไม่ระบุชื่อ ตามที่ผู้พูดเลือก — เงื่อนไขเดียวกับงานตรวจสอบ) ที่แทนที่ค่าเดิม ประวัติของสิ่งที่เปลี่ยนแปลงยังคงตรวจสอบได้ เวอร์ชันของคลังข้อมูลมี hash manifest (Corpus Partnership §4.4) ดังนั้นคลังข้อมูลที่แก้ไขแล้วจึงเป็นเวอร์ชันใหม่ที่มองเห็นได้ชัดเจน และทุก run card บันทึกเวอร์ชันที่แน่นอนที่ใช้ในการให้คะแนน — คะแนนเก่ายังคงตีความได้ คะแนนใหม่สะท้อนการแก้ไข
สิทธิ์ยับยั้ง อย่างเป็นรูปธรรม
"การควบคุมของชุมชน" เป็นสิ่งที่อ้างได้ง่าย นี่คือสิ่งที่มันหมายถึงในสถาปัตยกรรมที่เผยแพร่:
- ผู้พูดสามารถถอนการมีส่วนร่วมของตนได้ ผู้พูดสามารถดึงการให้คะแนนของตนออกได้ตลอดเวลา และการถอนจะลบออกจากการวิเคราะห์ทั้งหมด (Speaker Validation §5) ผู้พูดยังมีสิทธิ์ยับยั้งการเผยแพร่ผลลัพธ์ที่พวกเขาเห็นว่ามีปัญหา
- ชุมชนสามารถหยุดการประเมินได้ทั้งหมด ชุดทดสอบที่ปิดผนึกถูกเข้ารหัส โดยมีการถือครองคีย์ในลักษณะที่แพลตฟอร์มเพียงอย่างเดียวไม่สามารถสร้างขึ้นใหม่ได้ ชุมชนสามารถเพิกถอนการเข้าถึงการประเมินโดยปฏิเสธการมีส่วนร่วมในการสร้างคีย์ใหม่ (Corpus Partnership §4.3) "จะเกิดอะไรขึ้นถ้าเราต้องการหยุด?" มีคำตอบที่ระบุไว้: ข้อมูลที่ปิดผนึกจะไม่ถูกเปิดเผย และการประเมินจะสิ้นสุดลง
- ไม่มีคะแนนใดที่แทนที่การตัดสินใจของชุมชน วิธีการที่ขึ้นอันดับต้นของ leaderboard ยังคงนำไปใช้งานได้ก็ต่อเมื่อหน่วยงานกำกับดูแลอนุมัติเท่านั้น (Ownership Transfer) — และชุมชนที่ตัดสินใจว่าไม่ควรนำ MT ไปใช้กับภาษาของตนเลยกำลังใช้ระบบตามที่ออกแบบไว้ ไม่ใช่ทำลายมัน (ดู Translation Is Not Revitalization)
สิ่งที่เรายังไม่ได้สร้าง
ในจิตวิญญาณเดียวกับส่วนอื่นๆ ของเอกสารนี้: ส่วนติดต่อการตรวจสอบของชุมชนอยู่ในแผน ยังไม่เปิดใช้งาน หน่วยงานกำกับดูแลยังไม่ได้จัดตั้งสำหรับภาษาปัจจุบันใดๆ — การดูแลของชุมชนสำหรับ benchmark Plains Cree อยู่ระหว่างการยืนยัน และเราไม่ระบุชื่อผู้ดูแลต่อสาธารณะก่อนที่พวกเขาจะให้ความยินยอม จนกว่าส่วนเหล่านั้นจะมีอยู่ การแก้ไขจะดำเนินผ่านช่องทางตรงที่ระบุที่มาได้ และข้อกำหนดที่เผยแพร่ — ไม่ใช่หน้านี้ — ยังคงเป็นคำอธิบายที่มีผลผูกพันของกระบวนการ หากหน้านี้และข้อกำหนดขัดแย้งกัน ข้อกำหนดมีผลเหนือกว่า และเราจะถือว่าความขัดแย้งนั้นเป็นข้อบกพร่องที่ควรรายงานเช่นกัน
สิ่งนี้หมายความว่าอะไรสำหรับคุณ
:::info หากคุณเป็นสมาชิกชุมชน หากมีสิ่งใดเกี่ยวกับภาษาของคุณบนแพลตฟอร์มนี้ที่ผิดพลาด — ข้อเท็จจริง การแปล หรือป้ายกำกับ — รายงานของคุณคือคำให้การจากแหล่งความจริง ไม่ใช่การร้องเรียนที่ต้องจัดลำดับความสำคัญ คุณตัดสินใจว่าการแก้ไขของคุณจะระบุชื่อหรือไม่ การมีส่วนร่วมของคุณสามารถถอนได้ในภายหลัง และชุมชนของคุณสามารถหยุดการใช้ข้อมูลของตนได้โดยสิ้นเชิง เริ่มต้นที่ For Language Communities หรือเปิด issue บน repository สาธารณะได้เลย :::
:::info หากคุณเป็นนักวิจัย การแก้ไขที่นี่คือข้อมูลที่มีที่มา ไม่ใช่การแก้ไขแบบเงียบ: เวอร์ชันของคลังข้อมูลมี hash run card ระบุเวอร์ชันที่แน่นอนที่ใช้ในการให้คะแนน และค่าที่ได้จากการคำนวณถูกระบุว่าเป็นการอนุมาน หากคุณสร้างบน Arena scores หรือคลังข้อมูล ให้อ้างอิงเวอร์ชัน — และปฏิบัติต่อคลื่นการแก้ไขที่ขับเคลื่อนโดยผู้พูดเป็นผลการค้นพบเกี่ยวกับความถูกต้องของเมตริก เพราะนั่นคือสิ่งที่มันเป็น :::
:::info หากคุณเป็นผู้พัฒนา คะแนนของวิธีการของคุณอาจเปลี่ยนแปลงได้อย่างถูกต้องโดยที่โค้ดของคุณไม่เปลี่ยน — คำที่ถูกปฏิเสธโดยไม่มีเหตุผลได้รับการ allowlist การแปลอ้างอิงได้รับการแก้ไข คลาสตัวแปรได้รับการแก้ไข ออกแบบให้รองรับสิ่งนั้น: ระบุเวอร์ชันของคลังข้อมูลใน run card ของคุณ (Run Card spec) ติดตาม changelog ของชุดข้อมูล และปฏิบัติต่อการแก้ไขของผู้พูดเป็นสัญญาณข้อผิดพลาดที่เชื่อถือได้มากที่สุดที่คุณจะได้รับฟรี :::
ดูเพิ่มเติม
- How Speakers Get Paid — อำนาจของผู้พูดในระดับเดียวกัน ในขั้นตอน benchmark
- From Benchmark to Daily Use — จุดที่การแก้ไขพบกับขั้นตอนการเผยแพร่
- Data Sovereignty — OCAP®, CARE และ Te Mana Raraunga หลักการเบื้องหลังการออกแบบนี้