จากเกณฑ์มาตรฐานสู่การใช้งานจริง: เส้นทาง Post-Editing

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

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

กระบวนการทำงานตั้งแต่ต้นจนจบ

 English source document
        │
        ▼
 Machine draft  ←  a benchmarked, community-owned method
        │
        ▼
 Fluent-speaker post-edit  ←  the human gate; nothing skips it
        │
        ▼
 Published text  ←  carries human approval, not a machine score
        │
        ▼
 (Optional, community-controlled) corrections become
 data that improves the next version of the method

สามสิ่งที่ควรสังเกต:

เครื่องไม่เคยเผยแพร่โดยตรง หน่วยผลลัพธ์คือร่างแปล การตรวจแก้ไขของผู้พูดภาษาไม่ใช่การประกันคุณภาพที่ต่อเติมไว้ท้ายสุด แต่คือตัวกระบวนการทำงานเอง
เวลาของผู้พูดภาษาคือทรัพยากรที่ต้องการเพิ่มประสิทธิภาพ วิธีหนึ่งดีกว่าอีกวิธีหนึ่งก็ต่อเมื่อทำให้ผู้พูดภาษาต้องแก้ไขน้อยลง งานวิจัยด้าน post-editing สำหรับภาษาที่มีทรัพยากรเพียงพอพบอย่างสม่ำเสมอว่าเร็วกว่าการแปลใหม่ตั้งแต่ต้นเมื่อคุณภาพ MT อยู่ในระดับปานกลาง (Plitt & Masselot 2010; Green, Heer & Manning 2013 อ้างอิงพร้อมลิงก์ใน Translation Is Not Revitalization) ว่าสิ่งนี้จะเป็นจริงสำหรับภาษาแบบ polysynthetic หรือไม่นั้น คือสิ่งที่เกณฑ์มาตรฐานนี้มีอยู่เพื่อค้นหา เราถือว่าเป็นสมมติฐานที่ต้องตรวจสอบเป็นรายภาษา ไม่ใช่ข้อสมมติที่รับมาโดยไม่ตั้งคำถาม
วงจรป้อนกลับเป็นของชุมชน เอกสารที่ผ่านการแก้ไขทุกฉบับเป็นข้อมูลที่อาจนำไปใช้ฝึกและพัฒนาได้ และเป็นของชุมชน เพื่อนำกลับมาใช้ (หรือไม่ก็ได้) ตามเงื่อนไขของตนเองภายใต้กฎ data sovereignty กลไกป้อนกลับนี้เป็นเป้าหมายการออกแบบของแพลตฟอร์ม แต่ยังไม่ได้สร้างขึ้นจริง ดู Reporting Errors and Owning Corrections สำหรับวิธีที่การแก้ไขและที่มาของข้อมูลมีแผนจะทำงาน

ความหมายของระดับคุณภาพต่อการใช้งานจริง

Leaderboard ให้คะแนนวิธีการต่าง ๆ บนพื้นฐานของ composite ของ automated metrics (Scoring Specification) และคะแนนเหล่านั้นจะจัดอยู่ในระดับที่มีชื่อเรียก ต่อไปนี้คือการแปลความหมายที่ตรงไปตรงมาของระดับเหล่านั้นในแง่การใช้งานประจำวัน:

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

กฎความซื่อสัตย์เชิงโครงสร้างสองข้อวางอยู่บนตารางนี้ ดึงมาจาก Benchmark Specification §5 and §7 โดยตรง:

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

เพื่อการเปรียบเทียบ เกณฑ์ Founder's Prize (composite ≥ 0.80, ≥99% ของคำที่ถูกต้องทางสัณฐานวิทยา, ≥70% ที่ผู้พูดภาษาให้คะแนน acceptable หรือดีกว่า) อธิบายวิธีที่ข้อผิดพลาดที่เหลืออยู่เป็น ข้อผิดพลาดในภาษาจริง ได้แก่ การผันคำผิด ไม่ใช่คำที่ถูกสร้างขึ้นมา นั่นคือสิ่งที่ "ร่างแปลที่คุ้มค่าเวลาของผู้พูดภาษา" มีลักษณะอย่างไรในเชิงตัวเลข

จากวิธีที่ชนะสู่สำนักงานที่ทำงานได้จริง

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

ความเป็นเจ้าของถ่ายโอน โค้ดของวิธีนั้นกลายเป็นทรัพย์สินขององค์กรกำกับดูแลของชุมชน โดยผู้พัฒนายังคงสิทธิ์การระบุแหล่งที่มาและสิทธิ์การเผยแพร่ (Ownership Transfer)
วิธีนั้นกลายเป็นบริการ ถูกบรรจุเป็น plugin และให้บริการผ่านแพลตฟอร์ม deployment โดยชุมชนควบคุมการเข้าถึง ราคา และการใช้งานที่อนุญาต (Deploy to Production)
นักแปลนำไปใช้ในงานประจำวัน สำนักงานแปลเชื่อมต่อกระบวนการทำงานเอกสารที่มีอยู่กับ API ของวิธีนั้น: ส่งข้อความต้นฉบับเข้า รับร่างแปลออกมา ทำ post-edit แล้วเผยแพร่ ข้อความที่เผยแพร่ระบุชื่อและอำนาจของนักแปล เครื่องเป็นเพียงเครื่องมือบนโต๊ะทำงาน เหมือนพจนานุกรม
รายได้ตามการใช้งาน นักพัฒนาภายนอกที่ใช้วิธีนั้นจ่ายค่าบริการตามปริมาณการใช้งาน และ 90% ของรายได้นั้นไหลไปยังองค์กรกำกับดูแล (The Economic Model) ซึ่งสามารถนำไปสนับสนุนชั่วโมงทำงานของนักแปลเพิ่มเติม ปิดวงจรนี้

สถานะปัจจุบัน

พูดตรง ๆ: เส้นทางทั้งหมดได้รับการระบุไว้ครบถ้วนตั้งแต่ต้นจนจบ และสร้างขึ้นบางส่วนแล้ว ระบบประเมิน เมตริก run cards และ leaderboard สาธารณะมีอยู่แล้ว คลังข้อมูลพัฒนา Plains Cree และรางวัลที่ยังเปิดรับอยู่มีอยู่แล้ว แพลตฟอร์ม deployment มีอยู่แล้ว อินเทอร์เฟซการตรวจสอบของชุมชน sandbox สำหรับการประเมิน และวงจรป้อนกลับข้อความที่ผ่านการแก้ไขได้รับการระบุไว้แต่ยังไม่ได้เปิดใช้งาน ข้อกำหนดระบุว่าเป็นแผนงาน และเราก็ระบุเช่นเดียวกัน ยังไม่มีวิธีใดที่ผ่านเส้นทางทั้งหมดจากเกณฑ์มาตรฐานไปสู่การใช้งานจริงในชุมชน การเดินทางนั้นคือนิยามของความสำเร็จของโครงการ ซึ่งเป็นเหตุผลที่เราจะไม่อ้างสิทธิ์ก่อนเวลาอันควร

ความหมายสำหรับคุณ

:::info หากคุณเป็นสมาชิกชุมชน ป้าย "Deployable" บน leaderboard ไม่ได้หมายความว่าเครื่องจะเผยแพร่ในภาษาของคุณโดยไม่มีการดูแล แต่หมายความว่าตัวสร้างร่างแปลอาจพร้อมที่จะ ทดสอบ กับนักแปลของคุณ ตามเงื่อนไขของคุณ โดยมีผู้พูดภาษาของคุณเป็นผู้ตัดสิน (และได้รับค่าตอบแทน ดู How Speakers Get Paid) หากชุมชนของคุณมีสำนักงานแปล คำถามที่เกี่ยวข้องที่ควรนำมาหารือกับเราคือ: "การทดลองนำร่องจะมีลักษณะอย่างไร และใครเป็นผู้ตรวจสอบผลลัพธ์?" :::

:::info หากคุณเป็นนักวิจัย กรอบแนวคิด post-editing เปลี่ยนสิ่งที่ควรวัด: เวลาที่ใช้จนได้ข้อความที่ยอมรับได้โดยมีผู้พูดภาษาอยู่ในวงจร ไม่ใช่แค่ composite score เมตริกของ Arena เป็นตัวแทนสำหรับสิ่งนั้น (Scoring Specification §1) และการศึกษา post-editing รายภาษาสำหรับภาษาที่มีความซับซ้อนทางสัณฐานวิทยาเป็นช่องว่างการวิจัยที่เปิดอยู่ซึ่งโครงสร้างพื้นฐานนี้ออกแบบมาเพื่อรองรับ :::

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

ดูเพิ่มเติม

Translation Is Not Revitalization — เหตุใดประตูของมนุษย์จึงเป็นจุดสำคัญ ไม่ใช่ข้อจำกัด
Reporting Errors and Owning Corrections — สิ่งที่เกิดขึ้นเมื่อข้อความที่เผยแพร่ยังคงมีข้อผิดพลาด
Benchmark Specification §7 — ประตูการตรวจสอบโดยมนุษย์ในรูปแบบทางการ

กระบวนการทำงานตั้งแต่ต้นจนจบ​

ความหมายของระดับคุณภาพต่อการใช้งานจริง​

จากวิธีที่ชนะสู่สำนักงานที่ทำงานได้จริง​

สถานะปัจจุบัน​

ความหมายสำหรับคุณ​

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