คำโกหกเกี่ยวกับการแก้ไขแบบทำงานร่วมกัน ตอนที่ 1: อัลกอริทึมสำหรับการแก้ไขแบบออฟไลน์

 (moment.dev)
2 คะแนน โดย GN⁺ 2024-12-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ช่วงต้นปี 2024 ได้เริ่มสำรวจระบบการแก้ไขแบบทำงานร่วมกันที่จะใช้กับตัวแก้ไขข้อความหลักของ Moment ขณะนี้มีหลายอัลกอริทึมที่อ้างว่าสามารถแก้ปัญหาการแก้ไขทั้งแบบออนไลน์และออฟไลน์ได้ แต่ในทางปฏิบัติกลับพบว่าประสบการณ์การแก้ไขแบบออฟไลน์นั้นไม่ดี
  • ปัญหาของการแก้ไขแบบออฟไลน์
    • อัลกอริทึมยอดนิยมอย่าง CRDTs และ OT จัดการความขัดแย้งจากการแก้ไขโดยตรงในแบบที่ไม่เป็นธรรมชาติ ทำให้ผู้ใช้รับรู้ว่าเป็นข้อมูลเสียหาย
    • การแก้ไขแบบออฟไลน์เพิ่มโอกาสของความขัดแย้งโดยตรง และอัลกอริทึมเหล่านี้ไม่เหมาะกับการแก้ไขแบบออฟไลน์
  • ตัวอย่าง: ความขัดแย้งจากการแก้ไขเล็กน้อย
    • Alice และ Bob แก้ไขเอกสารขณะออฟไลน์ Bob เปลี่ยน 'Color' เป็น 'Colour' ส่วน Alice ลบข้อความทั้งหมด จากนั้นเมื่อกลับมาออนไลน์ ก็ต้องหาทางแก้ความขัดแย้งนี้
    • ความขัดแย้งลักษณะนี้เกิดขึ้นได้บ่อย และสุดท้ายผู้ใช้ก็มองว่าข้อมูลเสียหาย
  • ข้อจำกัดของอัลกอริทึม
    • โปรเจ็กต์อย่าง Yjs, ShareJS และ Peritext อ้างว่ารองรับการแก้ไขแบบออฟไลน์ แต่ในความเป็นจริงกลับเกิดข้อผิดพลาดบ่อยครั้ง
    • อัลกอริทึมไม่สามารถรู้เจตนาของผู้ใช้ได้ และทำงานในระดับตัวอักษร จึงไม่มีหลักประกันมากพอสำหรับผลลัพธ์
  • การเปลี่ยนมุมมองไปเป็นปัญหา UI/UX
    • ปัญหานี้ไม่สามารถแก้ได้อย่างสมบูรณ์ด้วยอัลกอริทึมเพียงอย่างเดียว และควรเข้าหาในฐานะปัญหา UI/UX
    • มี UI สำหรับรวมเอกสารอย่าง git อยู่แล้ว และควรศึกษาว่าจะทำให้สิ่งนี้เข้าถึงได้ง่ายขึ้นและทำงานอัตโนมัติได้อย่างไร
    • นักวิจัยบางส่วนกำลังมุ่งเน้นปัญหานี้ในฐานะปัญหา UI/UX และงานศึกษาประวัติการทำงานร่วมกันของ Ink & Switch ก็เป็นตัวอย่างหนึ่ง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-12-08
ความเห็นจาก Hacker News

  • ผู้เขียน Eg-walker และ ShareJS กล่าวถึงว่าเครื่องมือทำงานร่วมกันแบบเรียลไทม์มีประโยชน์เมื่อทำงานร่วมกันขณะออนไลน์ แต่สำหรับการแก้ไขแบบออฟไลน์หรือการแยกสาขาระยะยาว ควรมีตัวเลือกในการเพิ่ม conflict marker และตรวจทานด้วยตนเอง

    • อัลกอริทึม Eg-walker เสนอความเป็นไปได้ในการสร้าง CRDT ที่เก็บการติดตามการแก้ไขรายตัวอักษรจากผู้ใช้ทุกคน และบันทึกช่วงเวลาที่การเปลี่ยนแปลงทั้งหมดเกิดขึ้น เพื่อให้ตรวจจับและแสดงขอบเขตของความขัดแย้งได้
    • เขาเน้นว่านี่เป็นปัญหาที่น่าสนใจและยังไม่ได้รับการแก้ไข จึงควรได้รับความสนใจมากกว่านี้

  • อีกปัญหาหนึ่งของการนำ CRDT ไปใช้งานคือภาระด้านโครงสร้างพื้นฐาน

    • หากใช้ CRDT ก็ควรใช้สิ่งอย่าง Redis หรือ MyRocks และแนะนำว่าอย่าสำรองข้อมูลไว้ใน RDBMS โดยเฉพาะ Postgres

  • กล่าวขอบคุณผู้ใช้ที่กำลังทำงานผสาน CRDT เข้ากับซอฟต์แวร์จดบันทึก

  • มีการกล่าวว่าอัลกอริทึม merge เชิงกลอาจให้ประสิทธิภาพต่างกันไปตามชนิดของความขัดแย้ง และ CRDT ไม่สามารถตัดสินได้ว่าข้อความที่ merge แล้วตรงกับเจตนาของผู้ใช้หรือไม่

    • งานวิจัย Upwelling อธิบายความแตกต่างระหว่าง semantic conflict และ syntactic conflict ไว้อย่างละเอียด
    • การทำงานร่วมกันอย่างจริงจังคือปัญหาของการตรวจทานเอกสาร และสำคัญอย่างยิ่งในงานวารสารศาสตร์และการตีพิมพ์ทางวิทยาศาสตร์

  • อัลกอริทึมที่ใช้ในการแก้ไขข้อความร่วมกัน (CRDTs และ OT) มีข้อกำหนดเชิงพีชคณิตที่เข้มงวดเกี่ยวกับการดำเนินการแก้ไขและปฏิสัมพันธ์ระหว่างกัน

    • เซิร์ฟเวอร์สามารถประมวลผลงานตามตรรกะ UX ได้ และไคลเอนต์สามารถใช้กลยุทธ์ rebase/prediction ที่อนุญาตให้แก้ไขแบบ optimistic ได้

  • มีการกล่าวว่าแนวคิดเรื่องความขัดแย้งทางคณิตศาสตร์ เชิงสาเหตุ และเชิงเอนโทรปี ถูกนำไปปะปนกับ semantic conflict

    • ในบรรดา CRDTs นั้น คลาสที่คงรักษาความขัดแย้งไว้น่าจะมีอนาคตมากที่สุด และควรทำให้ผู้ใช้มองเห็นความขัดแย้งได้ด้วยสายตา

  • มีการเสนอความเป็นไปได้ในการใช้ AI เพื่อคาดการณ์การ merge

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

  • มีการกล่าวว่า CRDTs เป็นแบบจำลองเชิงรูปแบบที่ยอดเยี่ยมสำหรับโครงสร้างข้อมูลแบบกระจาย แต่แนวคิดที่ว่าต้องแก้ไขความขัดแย้งทั้งหมดโดยอัตโนมัตินั้นมีปัญหา

    • จำเป็นต้องมีแบบจำลองที่สามารถแสดงความขัดแย้งอย่างเป็นโครงสร้าง และแก้ไขร่วมกันแบบแบ่งปันและร่วมมือกันได้
    • ได้พัฒนาแบบจำลองการแสดงความขัดแย้งเชิงโครงสร้างชื่อ "Lazy Merging" ซึ่งนำเสนอแบบจำลองเชิงแนวคิดที่เรียบง่ายผ่านแนวทางทางคณิตศาสตร์

  • มีการกล่าวว่าการที่หลายฝ่ายมีสิทธิ์เหนือข้อมูลเดียวกันพร้อมกันเป็นปัญหาที่แก้ไม่ได้

    • นี่เป็นบทเรียนที่ได้จากระบบกระจาย และปรากฏให้เห็นชัดเจนในการแก้ไขเอกสารแบบกระจาย

  • ในปี 2009 มีการถกเถียงกันมากเกี่ยวกับอัลกอริทึมที่ Git ใช้ในการ merge การเปลี่ยนแปลงโดยอัตโนมัติ และมีการกล่าวว่า Torvalds เคยตั้งข้อสงสัยต่อข้อจำกัดของการ merge อัตโนมัติ

    • การแก้ไขแบบออฟไลน์เป็นปัญหา UI/UX และเกี่ยวข้องกับปัญหาที่วงการคอมพิวเตอร์มักทำตามวิธีแก้เก่า ๆ
    • มีการกล่าวว่าการ merge สำหรับการทำงานร่วมกันแบบออฟไลน์ในงานแก้ไขข้อความควรเป็นศูนย์กลางของกระบวนการ และยากที่จะก้าวพ้นจุดอิ่มตัวเฉพาะที่แบบ MacWrite ได้