Vì sao AI khó tiếp quản công việc dang dở

Mặc dù các tác nhân AI có thể giải quyết những nhiệm vụ phức tạp, một nghiên cứu mới cho thấy chúng gặp khó khăn khi tiếp tục công việc do bên khác bắt đầu. Điều này dẫn đến việc phải làm lại, tiến độ chậm hơn và chi phí cao hơn.

Một trong những việc mệt mỏi nhưng cần thiết khi làm việc với các tác nhân và giao diện AI là phải giúp AI nắm được tình hình ngay từ đầu gần như mọi cuộc trao đổi.

Mặc dù các mô hình ngôn ngữ phổ biến như ChatGPT cung cấp một mức độ truy cập nhất định vào bộ nhớ lâu dài được cá nhân hóa, khả năng này hoạt động chưa nhất quán. Cuối cùng, thường an toàn hơn nếu chịu khó giải thích bối cảnh nhiệm vụ cho AI*, dù chỉ để ngăn mô hình đoán sai ngữ cảnh dựa trên không gian tiềm ẩn được hình thành trong quá trình huấn luyện của nó.

Tiếp quản công việc dang dở trong thực tế

Thách thức này tất nhiên đã tồn tại trước AI. Nhiều công ty đã yêu cầu nhân viên ghi lại tài liệu về các quy trình họ xây dựng hoặc hoàn thiện, một phần để giúp nhân viên mới làm quen dễ dàng hơn, nhưng cũng có thể lập luận rằng mục đích là ngăn nhân viên có được vị thế thương lượng mạnh hơn.

Tuy nhiên, trên thực tế, thường chỉ những tổ chức lớn hơn và có nguồn tài chính tốt hơn mới thực sự tạo lập, cập nhật và duy trì tài liệu. Thay vào đó, nhân viên phải tiếp quản công việc của người khác rất thường được giao một nhiệm vụ như thám tử: họ phải tỉ mỉ dựng lại diễn biến theo thời gian dẫn đến phần công việc dang dở vừa được giao cho mình.

Tài liệu hoàn chỉnh rõ ràng có thể tiết kiệm nhiều ngày, nhiều tuần, thậm chí nhiều tháng làm việc, nếu việc tạo ra chúng hợp lý về mặt tài chính.

Tuy nhiên, khi tác nhân AI là bên thực hiện nhiệm vụ, có thể sẽ có nhiều cơ hội hơn để giải quyết vấn đề này.

Bàn giao

Một nghiên cứu mới từ Mỹ định lượng gánh nặng do thiếu tài liệu này và gọi vấn đề đó là nợ bàn giao.

Nếu nợ kỹ thuật mô tả tình trạng các giải pháp kỹ thuật nhanh, làm tạm và rẻ ở hiện tại tạo ra những hệ thống mong manh hoặc khó bảo trì trong tương lai, thì nợ bàn giao mô tả chi phí tìm hiểu lại – lần theo dấu vết để dựng lại các bước của một người lao động hoặc thực thể không thể cung cấp hướng dẫn, chẳng hạn do bị sa thải trong xung đột, quá bận hoặc đã qua đời. Thực thể đó cũng có thể không còn khả năng hướng dẫn, như một mô hình ngôn ngữ đã mất ngữ cảnh dẫn đến trạng thái công việc hiện tại.

Bài nghiên cứu mới^† – công trình hợp tác giữa các nhà nghiên cứu độc lập và các nhà nghiên cứu có liên hệ với Georgia State University – xem xét nợ bàn giao đối với các tác nhân lập trình được giao tiếp tục công việc trong một cơ sở mã tại nơi một phiên làm việc, người hoặc thực thể khác đã dừng lại.

Một mục tiêu của nghiên cứu là xác định lượng tài liệu cần thiết để giảm nợ bàn giao, cùng những quy trình và giao thức có thể được khuyến nghị làm thông lệ chuẩn trong tương lai nhằm hạn chế vấn đề.

Vấn đề ngân sách

Trong điều kiện lý tưởng, có thể đặt chế độ ghi nhật ký thành chế độ chi tiết, verbose rồi cung cấp ngay nhật ký của công việc chưa hoàn thành cho tác nhân mới tiếp quản nhiệm vụ.

Tuy nhiên, việc rút ra thông tin hữu ích từ lượng dữ liệu lớn như vậy vừa tốn thời gian, vừa tiêu hao ngân sách token, đồng thời có thể gặp giới hạn về dung lượng lưu trữ.

Đây là một vấn đề về ngân sách: xử lý dữ liệu thô xuất ra rất nặng nề, trong khi nhật ký đã được chọn lọc và biên tập dễ hiểu hơn nhưng đòi hỏi đầu tư nguồn lực từ trước.

Những ghi chú được chuẩn bị riêng sẽ giúp tác nhân tiếp quản nhanh chóng nắm tình hình. Tuy nhiên, chúng đòi hỏi nhiều công sức chuẩn bị hơn nữa, mà có thể không bao giờ cần đến nếu logic công việc cuối cùng đã rõ ràng, công việc bị bỏ dở hoặc không bao giờ được chỉnh sửa lại.

Các tác giả của công trình mới, có tiêu đề Handoff Debt: The Rediscovery Cost When Coding Agents Take Over Interrupted Tasks, đã xem xét tất cả các kịch bản này và điều chỉnh những mô hình nhiệm vụ hiện có để đo lường và xử lý nợ bàn giao theo cách mới. Mặc dù tập trung vào các tác nhân lập trình, nghiên cứu vẫn có thể chỉ ra hướng hữu ích cho những ứng dụng AI rộng hơn và việc tổ chức chính sách tài liệu.

Các tác giả cho biết:

“Nợ bàn giao phát sinh khi một tác nhân đạt tiến triển rõ rệt nhưng để lại trạng thái khiến bên kế nhiệm khó tiếp tục, chẳng hạn các chỉnh sửa không được giải thích, tệp làm việc tạm, giả định ngầm hoặc thiếu bằng chứng kiểm tra xác nhận.

“Một chỉ số chỉ dựa vào việc cuối cùng có giải quyết được nhiệm vụ hay không sẽ không phân biệt được việc tìm hiểu lại tốn kém với khả năng tiếp tục hiệu quả.

“Hai tác nhân tiền nhiệm có thể để lại cùng một điểm kiểm tra của kho mã, nhưng bên kế nhiệm có thể đối mặt với chi phí tiếp tục rất khác nhau: một bên có thể tiếp tục ngay, trong khi bên kia phải thực hiện nhiều lần tương tác với công cụ để dựng lại ý định từ các tệp tạm và lịch sử lệnh không đầy đủ.”

Phương pháp

Các tác giả định nghĩa tác nhân tiền nhiệm là tác nhân trước đó, bên khởi tạo hoặc thực hiện công việc gần nhất, và tác nhân kế nhiệm là tác nhân hiện tại, được giao tiếp quản công việc.

Để xây dựng một bộ chuẩn đo chi phí chuyển giao nhiệm vụ kỹ thuật phần mềm chưa hoàn thành giữa các tác nhân, 75 nhiệm vụ từ SWE-bench Verified đã được chuyển đổi thành 181 kịch bản bàn giao, mỗi kịch bản tương ứng với một thời điểm công việc bị ngắt và được giao cho tác nhân kế nhiệm. Sau đó, ba mô hình kế nhiệm khác nhau được thử nghiệm qua 2.172 lượt tiếp quản.

Các họ mô hình được sử dụng với nhiều cách ghép cặp trong những thử nghiệm bàn giao này là Qwen, Gemma, và Devstral.

Thử nghiệm xem xét bốn mức thông tin được kế thừa. Ở điều kiện hạn chế nhất, tác nhân kế nhiệm chỉ nhận trạng thái kho mã, gần như bước vào một vùng thảm họa không có tài liệu. Các điều kiện khác cung cấp bối cảnh ngày càng chi tiết, từ dấu vết hoạt động và lịch sử lệnh đến những bản tóm tắt ngắn gọn về điều đã được thử và tìm hiểu:

Thay vì chỉ tập trung vào việc cuối cùng có giải quyết được nhiệm vụ hay không, nghiên cứu được thiết kế để đo chi phí của chính việc tiếp tục công việc, xét đến việc sử dụng công cụ, mức tiêu thụ token và công sức cần thiết để dựng lại lập luận đằng sau công việc trước đó.

Trong thử nghiệm, ba mốc kích hoạt bàn giao và ba trạng thái bàn giao được xác định như sau:

Dữ liệu và thử nghiệm

Để tạo ra các kịch bản bàn giao thực tế, tác giả xây dựng bộ chuẩn từ 75 nhiệm vụ kỹ thuật phần mềm trong SWE-bench Verified, tập trung vào những vấn đề thường cần từ 15 phút đến 4 giờ để giải quyết.

Thay vì chỉ đánh giá nhiệm vụ đã hoàn thành, các nhà nghiên cứu ghi lại nhiều điểm kiểm tra trung gian trong lúc làm việc, tạo ra những tình huống một tác nhân AI phải tiếp quản công việc của tác nhân khác:

Cấu trúc bộ chuẩn tiếp nhận công việc: 75 tác vụ SWE-bench Verified được mở rộng thành 181 thời điểm bàn giao thuộc ba giai đoạn và được gắn nhãn theo trạng thái kho mã tại thời điểm tiếp quản. Bốn điều kiện chia sẻ thông tin tạo ra tổng cộng 2.172 lượt tác nhân kế nhiệm tiếp tục tác vụ. Nguồn

Vì mỗi nhiệm vụ có thể tạo ra nhiều điểm bàn giao và mỗi điểm được thử nghiệm với bốn dạng thông tin chuyển giao khác nhau, bộ chuẩn nhanh chóng mở rộng. Tập dữ liệu cuối cùng gồm 181 nhiệm vụ bàn giao riêng biệt và 724 lượt đánh giá tiếp quản cho mỗi mô hình kế nhiệm, tạo ra 2.172 lượt chạy trên ba hệ thống AI được thử nghiệm.

Thử nghiệm lập trình sử dụng môi trường theo kiểu OpenHands, với thao tác trên thiết bị đầu cuối, đóng băng kho mã tại điểm bàn giao, chỉnh sửa tệp và kiểm tra xác nhận chính thức SWE-bench.

Trong nghiên cứu chính, tất cả điểm bàn giao đều xuất phát từ lượt chạy có Qwen làm tác nhân tiền nhiệm, nhằm tạo cùng một điểm xuất phát để đánh giá khác biệt giữa các cách ghép cặp tác nhân và kịch bản.

Các cặp thử nghiệm là Qwen → Qwen, Qwen → Gemma và Qwen → Devstral.

Dấu vết thô giúp giảm nhiều nhất công sức của tác nhân kế nhiệm, với số sự kiện của tác nhân giảm 57–59%, trong khi ghi chú tóm tắt và ghi chú có cấu trúc giảm số sự kiện 20–46%. Mức sử dụng token đầu vào cũng giảm ở cả ba phương pháp, từ 42–63%:

Trong điều kiện bàn giao chỉ kho mã, tác nhân kế nhiệm phải thực hiện thêm nhiều lượt tương tác để dựng lại ý định của tác nhân tiền nhiệm, bằng chứng trước đó và những cách làm đã thất bại. Dấu vết thô, ghi chú tóm tắt và ghi chú có cấu trúc truyền trực tiếp một phần thông tin này, giảm nhu cầu tìm hiểu lại nhưng phải dùng lời nhắc ban đầu dài hơn.

Để kiểm tra xem lợi ích có thực sự tồn tại hay không, mỗi lượt bàn giao giàu bối cảnh được ghép với một lượt bàn giao chỉ kho mã bắt đầu từ cùng một điểm. Trong mọi cặp mô hình, bối cảnh bàn giao phong phú hơn đều giúp giảm công việc mà tác nhân kế nhiệm phải thực hiện.

Dấu vết sự kiện đầy đủ giúp giảm nhiều nhất, nhưng ghi chú tóm tắt và ghi chú có cấu trúc cũng mang lại mức tiết kiệm đáng kể. Hiệu ứng xuất hiện trên toàn bộ bộ chuẩn, chứ không phải do một vài trường hợp khác thường:

Để xác nhận hiệu ứng không phải do một vài trường hợp khác thường, các nhà nghiên cứu so sánh mỗi lượt bàn giao với một lượt bàn giao chỉ kho mã bắt đầu từ cùng một điểm. Mức giảm nhất quán trên mọi cặp mô hình cho thấy lợi ích phản ánh một xu hướng có ý nghĩa, chứ không chỉ vài ví dụ ngoại lệ.

Điểm chính rút ra…

Tóm lại^†, các tác giả nhận thấy rằng khi một tác nhân AI bàn giao nhiệm vụ cho tác nhân khác, ngay cả ghi chú đơn giản cũng giúp tác nhân thứ hai tiếp tục hiệu quả hơn.

Bản ghi đầy đủ các sự kiện cho kết quả tốt nhất, nhưng bất kỳ thông tin bàn giao nào cũng tốt hơn việc buộc tác nhân kế nhiệm dựng lại mọi thứ chỉ từ mã. Kết quả nêu trên cũng minh họa rằng cách dùng toàn bộ nhật ký thô tất yếu có chi phí token cao hơn.

Kết luận

Mặc dù bài báo hướng riêng đến giới nghiên cứu và ít hấp dẫn với độc giả phổ thông, công trình mới vẫn đề cập một trong những vấn đề thú vị và cấp thiết nhất của các giao diện và giao thức con người–AI hiện nay.

Có thể hy vọng rằng những phương pháp được phát triển và hiểu biết thu được từ kiểu nghiên cứu này cuối cùng sẽ được mở rộng sang các ứng dụng AI khác ngoài lập trình bằng tác nhân.

Một hướng nghiên cứu tiếp theo là đánh giá lượng tài liệu tối thiểu cần thiết cho từng dự án dựa trên đặc điểm và trường hợp sử dụng. Tuy nhiên, ngay cả chức năng giúp sử dụng thời gian và tiền bạc hợp lý hơn này cũng cần thời gian và tiền bạc. Vì thế, bài toán ngân sách trong việc lập tài liệu vẫn khó tránh.

* Cá nhân tôi gần đây đã bắt đầu xuất một bản PDF sạch của cuộc trò chuyện, dù gặp đôi chút khó khăn, đối với những phiên ChatGPT chậm do độ trễ và quá nhiều ngữ cảnh. Tôi dùng bản PDF ấy làm điểm khởi đầu cho phiên mới, trở thành “phần 2”.

^† Đây không phải bài báo dễ đọc nhất tôi đã đọc trong năm nay. Vì thế, tôi không thể khuyên độc giả tìm đến công trình gốc, mặc dù các kết quả được trình bày lại dễ hiểu hơn vẫn đáng quan tâm.

Được xuất bản lần đầu vào thứ Tư, ngày 3 tháng 6 năm 2026