2 điểm bởi GN⁺ 2024-12-08 | 1 bình luận | Chia sẻ qua WhatsApp
  • Vào đầu năm 2024, nhóm bắt đầu nghiên cứu một hệ thống chỉnh sửa cộng tác để dùng cho trình soạn thảo văn bản cốt lõi của Moment. Hiện có nhiều thuật toán tuyên bố giải quyết được bài toán chỉnh sửa trực tuyến và ngoại tuyến. Tuy nhiên, trên thực tế họ phát hiện trải nghiệm chỉnh sửa ngoại tuyến không tốt.
  • Vấn đề của chỉnh sửa ngoại tuyến
    • Các thuật toán phổ biến như CRDTs và OT xử lý các xung đột chỉnh sửa trực tiếp theo cách thiếu trực quan, khiến người dùng cảm nhận như dữ liệu đã bị hỏng.
    • Chỉnh sửa ngoại tuyến làm tăng khả năng xảy ra xung đột trực tiếp, và các thuật toán này không phù hợp với chỉnh sửa ngoại tuyến.
  • Ví dụ: xung đột chỉnh sửa nhỏ
    • Alice và Bob chỉnh sửa một tài liệu khi đang ngoại tuyến. Bob đổi 'Color' thành 'Colour', còn Alice xóa toàn bộ văn bản. Sau đó khi trở lại trực tuyến, xung đột này phải được giải quyết.
    • Những xung đột như vậy xảy ra thường xuyên, và kết quả là người dùng cảm thấy dữ liệu đã bị hỏng.
  • Giới hạn của thuật toán
    • Các dự án như Yjs, ShareJS và Peritext tuyên bố hỗ trợ chỉnh sửa ngoại tuyến, nhưng trên thực tế lỗi xảy ra thường xuyên.
    • Thuật toán không thể biết được ý định của người dùng và hoạt động ở cấp ký tự, nên thiếu sự đảm bảo về kết quả.
  • Chuyển hướng sang bài toán UI/UX
    • Chỉ riêng thuật toán không thể giải quyết trọn vẹn vấn đề; cần tiếp cận đây như một bài toán UI/UX.
    • Các UI hợp nhất tài liệu như git đã tồn tại, và cần nghiên cứu cách làm chúng dễ tiếp cận hơn và có thể tự động hóa hơn.
    • Một số nhà nghiên cứu đang tập trung vào vấn đề này như một bài toán UI/UX, ví dụ như nghiên cứu về lịch sử cộng tác của Ink & Switch.

1 bình luận

 
GN⁺ 2024-12-08
Ý kiến trên Hacker News
  • Tác giả của Eg-walker và ShareJS cho biết các công cụ cộng tác thời gian thực hữu ích khi cùng làm việc trực tuyến, nhưng với chỉnh sửa ngoại tuyến hoặc các nhánh kéo dài thì cần có tùy chọn thêm dấu xung đột và rà soát thủ công

    • Thuật toán Eg-walker gợi mở khả năng xây dựng một CRDT có thể lưu vết chỉnh sửa theo từng ký tự từ mọi người dùng, đồng thời lưu thời điểm mọi thay đổi xảy ra để phát hiện và đánh dấu phạm vi xung đột
    • Họ nhấn mạnh đây là một vấn đề thú vị và vẫn chưa được giải quyết, nên cần được quan tâm nhiều hơn
  • Một vấn đề khác của các triển khai dùng CRDT là gánh nặng hạ tầng

    • Khi dùng CRDT, nên dùng thứ như Redis hoặc MyRocks, và khuyến nghị không sao lưu bằng RDBMS, đặc biệt là Postgres
  • Gửi lời cảm ơn tới một người dùng đang làm việc tích hợp CRDT vào phần mềm ghi chú

  • Thuật toán hợp nhất cơ học có thể cho hiệu năng khác nhau trước nhiều loại xung đột, và CRDT không thể quyết định liệu văn bản sau khi hợp nhất có đúng với ý định của người dùng hay không

    • Bài báo Upwelling giải thích chi tiết sự khác biệt giữa xung đột ngữ nghĩa và xung đột cú pháp
    • Cộng tác nghiêm túc là một bài toán rà soát tài liệu, đặc biệt quan trọng trong báo chí và xuất bản khoa học
  • Các thuật toán dùng cho chỉnh sửa văn bản cộng tác (CRDTs và OT) có những yêu cầu đại số nghiêm ngặt đối với việc thực thi và tương tác của các thao tác chỉnh sửa

    • Máy chủ có thể xử lý thao tác theo logic UX, còn phía client có thể dùng chiến lược rebase/dự đoán để cho phép chỉnh sửa lạc quan
  • Có ý kiến cho rằng các khái niệm xung đột toán học, nhân quả và entropy đã bị nhầm lẫn với xung đột ngữ nghĩa

    • Trong số các CRDTs, lớp bảo toàn xung đột là hứa hẹn nhất, và cần cho phép người dùng nhìn thấy xung đột một cách trực quan
  • Có ý kiến nêu ra khả năng dùng AI để dự đoán việc hợp nhất

    • Họ cho rằng một LLM có thể xem tập thay đổi của tác giả, được hỏi liệu các chỉnh sửa có chồng lấn hay không, rồi quyết định thứ tự thay đổi để đạt 90% kết quả tốt
  • CRDTs là một mô hình hình thức rất tốt cho cấu trúc dữ liệu phân tán, nhưng có vấn đề với quan niệm rằng mọi xung đột đều phải được tự động giải quyết

    • Cần một mô hình có thể biểu diễn xung đột theo cấu trúc và giải quyết chúng theo cách chia sẻ, cộng tác
    • Họ đã phát triển một mô hình biểu diễn xung đột có cấu trúc gọi là "Lazy Merging", đưa ra một mô hình khái niệm đơn giản thông qua cách tiếp cận toán học
  • Có ý kiến cho rằng việc nhiều thực thể đồng thời có quyền đối với cùng một dữ liệu là một vấn đề không thể giải quyết triệt để

    • Đây là bài học rút ra từ hệ thống phân tán, và được thể hiện rõ trong chỉnh sửa tài liệu phân tán
  • Có ý kiến nhắc lại rằng vào năm 2009 đã có nhiều thảo luận về các thuật toán để Git tự động hợp nhất thay đổi, và Torvalds từng hoài nghi về giới hạn của hợp nhất tự động

    • Chỉnh sửa ngoại tuyến là một vấn đề UI/UX, đồng thời liên quan đến việc ngành máy tính cứ lặp lại các giải pháp cũ
    • Trong chỉnh sửa văn bản, việc hợp nhất cộng tác ngoại tuyến phải là trung tâm của quy trình, và rất khó thoát khỏi cực trị cục bộ như MacWrite