Có nên cho user sửa câu trả lời của AI?
Bạn nhờ AI viết một email từ chối ứng viên sau vòng phỏng vấn.
AI viết khá nhanh, đầy đủ tiêu đề, lời chào và cả lời chúc ở cuối. Chỉ có một câu đọc vẫn chưa tự nhiên:
“Chúng tôi rất tiếc phải thông báo rằng bạn chưa đáp ứng được các tiêu chí của vị trí.”
Bạn xóa câu đó và viết lại:
“Sau khi trao đổi cùng team, bên mình chưa thể tiếp tục với bạn ở vòng này.”
Xong. Email dùng được rồi.
Nhưng nếu đây là một sản phẩm AI, chuyện gì vừa xảy ra?
Có thể bạn chỉ sửa một câu để gửi email lần này. Có thể bạn đang cho AI biết công ty mình không dùng giọng văn quá trang trọng. Cũng có thể bạn sửa vì ứng viên này đã đi đến vòng cuối, còn với ứng viên bị loại từ vòng CV thì câu ban đầu vẫn dùng được.
Trên màn hình, cả ba trường hợp đều chỉ là một thao tác: user sửa text.
Nếu sản phẩm không phân biệt được ba ý định đó, nó có thể làm đúng việc trước mắt nhưng lại học sai cho những lần sau. Tệ hơn nữa, user còn không biết AI đã “học” cái gì từ mình.
Vậy có nên cho user sửa câu trả lời của AI không?
Có. Nhưng cho sửa mới chỉ là nửa đầu của bài toán.
Sửa để dùng được trước đã
Với một công cụ viết, câu trả lời của AI thường không phải sản phẩm cuối cùng. Nó là một bản nháp.
User còn phải thay tên, kiểm tra số liệu, bỏ một câu dài dòng, thêm chi tiết mà AI không biết hoặc đơn giản là đổi chữ “trân trọng” thành “cảm ơn”. Nếu chỉ muốn thay đúng một câu mà user vẫn phải prompt lại toàn bộ, chờ AI generate rồi đọc lại từ đầu, thì tính năng này đang bắt họ làm lại cả flow chỉ để sửa vài chữ.
Chưa chắc lần generate thứ hai đã tốt hơn. AI có thể sửa được câu cũ nhưng tiện tay thay luôn ba đoạn đang ổn.
Lúc này, một text editor bình thường lại hữu ích hơn thêm một model xịn.
Microsoft Research từng tổng hợp và kiểm tra 18 hướng dẫn cho tương tác giữa người và AI. Trong nhóm hướng dẫn dành cho lúc AI làm sai, Microsoft đề xuất support efficient correction: giúp user dễ sửa, tinh chỉnh hoặc khôi phục khi hệ thống sai.
Nguồn: Guidelines for Human-AI Interaction — Microsoft Research
Quay lại chiếc email, user nên có thể đặt con trỏ vào đúng câu cần sửa, gõ lại rồi gửi đi. Không cần viết thêm một prompt giải thích rằng “hãy giữ nguyên mọi thứ, chỉ sửa câu thứ hai, bớt trang trọng một chút nhưng vẫn phải lịch sự”.
Nếu nội dung AI tạo ra là thứ user phải chịu trách nhiệm sau cùng — một email, bài viết, slide, báo cáo hay đoạn code — thì quyền sửa gần như là một phần của công việc chứ không phải tính năng phụ.
Một nghiên cứu về viết cùng AI của Stanford cũng thiết kế hẳn một editor để người tham gia có thể viết, nhận gợi ý từ GPT-3, chấp nhận, bỏ qua hoặc sửa các gợi ý đó. Bộ dữ liệu CoAuthor ghi lại 1.445 phiên viết của 63 người, đến cả thao tác gõ phím và di chuyển con trỏ cũng được lưu lại.
Nghiên cứu này không chứng minh rằng mọi sản phẩm AI đều phải có editor. Nhưng nó cho thấy nếu muốn hiểu cách con người thực sự viết cùng AI, việc họ sửa phần AI tạo ra là một hành vi cần được quan sát riêng, không thể gộp hết vào hai button thích và không thích.
Nguồn: CoAuthor — Stanford University
Một lần sửa có thể mang ba ý nghĩa
Email đã sửa xong. User bấm tiếp:
“Viết thêm một email từ chối cho ứng viên còn lại.”
AI nên dùng giọng văn nào?
Theo mình, sản phẩm có thể hiểu thao tác sửa ở ba phạm vi khác nhau.
Phạm vi nhỏ nhất là bản nháp hiện tại. User sửa để có một email dùng được, và hệ thống không mang thay đổi đó đi đâu cả.
Phạm vi thứ hai là công việc hiện tại. AI dùng bản đã sửa làm context cho yêu cầu tiếp theo trong cùng một cuộc trò chuyện hoặc cùng một document. Nếu user vừa xóa cách viết “chúng tôi rất tiếc phải thông báo”, email kế tiếp không nên bê nguyên câu đó trở lại.
Phạm vi lớn nhất là những lần dùng sau. Hệ thống ghi nhận rằng user thích xưng “bên mình”, thích câu ngắn và không thích giọng văn quá trang trọng. Preference này có thể được áp dụng cho một document, một dự án, một công ty hoặc toàn bộ tài khoản.
Ba phạm vi đều hợp lý. Cái nguy hiểm là sản phẩm tự chọn phạm vi lớn nhất trong khi user chỉ định sửa một email.
Google PAIR phân biệt feedback ngầm qua hành vi với feedback rõ ràng do user chủ động cung cấp. Họ cũng lưu ý rằng không phải hành động nào cũng có thể được diễn giải theo cùng một cách. Việc một người tương tác với nội dung chưa chắc có nghĩa là họ muốn xem thêm nội dung tương tự.
Nguồn: Feedback + Control — People + AI Guidebook
Sửa text cũng vậy.
User xóa một đoạn có thể vì đoạn đó sai. Nhưng cũng có thể vì email hôm nay cần ngắn hơn, người nhận đã biết sẵn bối cảnh hoặc đoạn đó chứa thông tin không được phép gửi ra ngoài. Hệ thống chỉ nhìn thấy phần text biến mất. Nó không nhìn thấy lý do nằm trong đầu user.
Nếu cứ xem mọi chỉnh sửa là preference, sau vài tuần AI có thể học được một bộ thói quen rất kỳ cục: lúc thì viết dài, lúc thì viết ngắn; lúc xưng “tôi”, lúc xưng “bên mình”; lúc thêm số liệu, lúc lại xóa hết số liệu.
AI không hẳn học sai. Nó được đưa cho những tín hiệu vốn mang ý nghĩa khác nhau nhưng bị team sản phẩm dán chung một nhãn là “user muốn thế này”.
Đừng bắt user sửa cùng một lỗi hai lần
Không tự động học từ mọi chỉnh sửa không có nghĩa là hệ thống nên quên sạch.
Nếu user vừa sửa tên ứng viên từ “Minh” thành “Minh Anh”, rồi câu tiếp theo AI lại viết “Chào Minh”, sản phẩm trông khá ngớ ngẩn. Tương tự, nếu user đã đổi toàn bộ cách xưng hô trong document nhưng mỗi đoạn generate mới lại quay về cách cũ, editor chỉ giúp user có thêm chỗ để làm việc tay chân.
Trong phạm vi document hoặc phiên làm việc hiện tại, bản user đã sửa nên trở thành phiên bản mới nhất mà AI đọc được. Khi được yêu cầu viết tiếp, rút gọn hay đổi thành bullet point, AI cần làm việc trên bản đó chứ không phải output ban đầu của model.
Chỗ này nghe hiển nhiên, cơ mà cách lưu dữ liệu phía sau có thể làm mọi thứ rối lên khá nhanh.
Sản phẩm cần biết đâu là output ban đầu, đâu là phần user sửa và đâu là phiên bản hiện tại. Nếu user bấm regenerate, hệ thống sẽ thay cả bản đã sửa hay tạo một version mới? Nếu AI viết tiếp dựa trên document, nó có đọc được những câu user vừa đổi không? Nếu user bấm undo, preference đã lưu trước đó có được hoàn tác cùng không?
Đây là lý do tính năng edit thường đi cùng version history, undo và một cách nhìn rõ bản nào đang được dùng. Không cần biến màn hình thành Git cho người viết email, nhưng ít nhất đừng để một lần bấm regenerate thổi bay mười phút sửa tay.
Muốn AI nhớ thì hỏi rõ
Sau khi user sửa email, sản phẩm có thể đặt một lựa chọn nhỏ:
“Dùng cách viết này cho các email tuyển dụng sau?”
Nếu user đồng ý, hệ thống mới lưu preference. Và preference cũng nên đủ cụ thể. “Dùng giọng thân thiện hơn cho email tuyển dụng” hữu ích hơn một thuộc tính mơ hồ như “user thích văn phong thân thiện”.
Một người có thể muốn viết thân thiện khi trao đổi với ứng viên nhưng vẫn cần giọng trang trọng trong hợp đồng. Nếu preference không có phạm vi, AI sẽ mang cách xưng “bên mình” đi khắp nơi. Đến lúc nó xuất hiện trong công văn gửi cơ quan nhà nước thì hơi khó giải thích.
User cũng cần biết lựa chọn vừa rồi có tác dụng ở đâu và trong bao lâu. Áp dụng cho email tiếp theo, cho project tuyển dụng hay cho cả tài khoản? Có thể xem, sửa hoặc xóa preference ở đâu?
Trong 18 hướng dẫn của Microsoft có hai nguyên tắc đứng sát chuyện này: khuyến khích feedback đủ chi tiết và nói rõ hành động của user sẽ ảnh hưởng đến hành vi tương lai của AI như thế nào. Google PAIR cũng khuyên sản phẩm phải cho user biết feedback được thu thập để làm gì, khi nào thay đổi sẽ xảy ra và cho phép họ điều chỉnh hoặc reset các preference trước đó.
Nói “Cảm ơn phản hồi của bạn” rồi âm thầm làm một việc gì đó phía sau là chưa đủ. Cảm ơn xong để làm gì mới là phần user cần biết.
Với những chỉnh sửa có dữ liệu nhạy cảm, việc dùng chúng để huấn luyện hoặc cải thiện model còn là một quyết định khác nữa. Quyền sửa nội dung không tự động trở thành sự đồng ý cho team đem nội dung đã sửa đi làm training data. Phần này liên quan đến consent, chính sách dữ liệu và cả cách triển khai kỹ thuật, nếu đào tiếp chắc thành một bài riêng mất.
Đo cái gì khi user được quyền sửa?
Giả sử team vừa ra mắt editor và thấy 70% câu trả lời đều bị user sửa.
Con số đó tốt hay xấu?
Nếu AI chỉ có nhiệm vụ đưa ra bản nháp, 70% có thể hoàn toàn bình thường. User lấy được khung nội dung rồi chỉnh lại cho đúng tình huống của mình. Nhưng nếu AI được bán với lời hứa tạo ra email hoàn chỉnh chỉ bằng một click, 70% lại là dấu hiệu cần xem kỹ.
Ngay cả số lượng ký tự bị sửa cũng khó trả lời. Đổi một chữ trong số tài khoản có thể quan trọng hơn xóa cả đoạn chào hỏi. User thêm hai câu vì AI thiếu dữ kiện khác với việc họ viết lại toàn bộ vì output không dùng được.
Mình sẽ tách ít nhất ba thứ khi đọc hành vi này:
- User có hoàn thành công việc sau khi sửa không: họ copy, gửi, lưu hay xuất bản nội dung?
- User sửa loại gì: dữ kiện sai, giọng văn, cấu trúc hay thông tin bị thiếu?
- Lần sau AI có giảm được đúng loại chỉnh sửa đó không, trong trường hợp user đã chủ động cho phép ghi nhớ?
Edit rate đứng một mình chỉ cho biết user đã chạm vào text. Nó chưa nói AI giúp được bao nhiêu và cũng chưa nói phần sửa có nên trở thành dữ liệu để cá nhân hóa.
Nếu team muốn hiểu sâu hơn, có thể hỏi feedback sau một số phiên thay vì hỏi sau mọi câu trả lời. User đang cố gửi email, không phải đi làm công việc gán nhãn miễn phí cho sản phẩm. Hỏi đúng lúc và đúng mức là đủ.
Lời nhắn
Kết luận lại, user nên được xóa “chúng tôi rất tiếc phải thông báo” và viết câu họ muốn. Đó là nội dung mà họ sẽ gửi đi, mang tên họ và có thể khiến một người khác vui hoặc buồn. Giữ quyền sửa trong trường hợp này là hoàn toàn hợp lý.
Nhưng sau khi user sửa, sản phẩm cần biết mình đang giữ một bản nháp mới, một context mới hay một preference mới. Nếu chưa biết, hãy giữ thay đổi trong công việc hiện tại và hỏi trước khi nhớ lâu hơn.
Cho user sửa giúp AI bớt làm phiền ở lần này. Nói rõ AI sẽ nhớ gì mới giúp user yên tâm sửa ở những lần sau.
Bài gốc trên Substack: https://henrypham.substack.com/p/co-nen-cho-user-sua-cau-tra-loi-cua
All rights reserved
