Hợp đồng tác vụ AI: chốt đầu vào, đầu ra và giới hạn giao việc

Đăng ngày 27/10/2026

Tóm tắt: mô tả việc trước khi tìm câu lệnh hay

Hợp đồng tác vụ AI là bản mô tả đầu vào, sản phẩm phải nhận, nguồn được dùng, điều cấm và điều kiện chuyển người. Bài dùng tên này cho một khung giao việc thực hành, không phải hợp đồng pháp lý hay tiêu chuẩn đã được chứng nhận. Mục tiêu là giúp người giao, người làm và người nhận có cùng cách hiểu về một việc được AI hỗ trợ.

• Câu lệnh là cách diễn đạt yêu cầu; hợp đồng tác vụ giữ yêu cầu ổn định khi đổi cách diễn đạt hoặc mô hình.
• Mỗi kết quả quan trọng cần có căn cứ và cách kiểm, bên cạnh hình thức trình bày.
• Dữ liệu thiếu phải dẫn tới trạng thái rõ, không bị thay bằng một suy đoán trông có vẻ đầy đủ.
• Đọc, tạo nháp, gửi và ghi vào hệ thống là những quyền cần mô tả riêng.
• Chỉ dùng bản mô tả để giao việc sau khi đã thử tình huống bình thường, thiếu dữ liệu và ngoại lệ.

Hợp đồng tác vụ AI khác một đoạn câu lệnh ở đâu?

Một câu lệnh có thể yêu cầu “đọc hồ sơ và lập báo cáo đầy đủ”. Người nhận việc vẫn chưa biết đầy đủ theo nghĩa nào, được dùng nguồn nào và kết luận nào phải chờ chuyên viên. Nếu sửa câu lệnh nhiều lần mà các câu hỏi đó chưa được trả lời, nhóm đang đổi cách nói trước khi thống nhất việc cần làm. Đó là khoảng trống mà bản mô tả tác vụ trong bài muốn xử lý.

Nghiên cứu LMQL đề xuất kết hợp chỉ dẫn ngôn ngữ, cấu trúc chương trình và ràng buộc đầu ra để làm việc với mô hình [1]. Đây là một hướng nghiên cứu về lập trình mô hình ngôn ngữ. Nó không chứng minh mọi yêu cầu doanh nghiệp có thể được biến thành ràng buộc tự động, nhưng cho thấy việc giao nhiệm vụ có thể được tổ chức rõ hơn một chuỗi văn bản viết theo cảm giác.

Giả định một công ty dịch vụ kỹ thuật tại Việt Nam cần rà hồ sơ mời thầu để chuẩn bị cuộc họp nội bộ. AI được giao lập danh sách tài liệu còn thiếu, trích điều kiện quan trọng và tạo câu hỏi cho người phụ trách. Đây là tình huống tự xây, không phải dự án đã triển khai. Bài không hướng dẫn kết luận pháp lý, quyết định tham dự thầu hoặc cam kết thay người có thẩm quyền.

Thay vì giao “đánh giá hồ sơ”, nhóm xác định sản phẩm là một bản nháp bàn giao có ba phần: điểm đã tìm thấy, điểm chưa xác nhận và câu hỏi cần xử lý. Người nhận biết phần nào có thể dùng để chuẩn bị họp, phần nào cần đọc nguồn lại. Nhờ vậy, một đầu ra chưa đủ căn cứ vẫn có thể hữu ích nếu nó giữ rõ giới hạn, thay vì cố tỏ ra đã hoàn tất toàn bộ phân tích.

Chốt người nhận kết quả và tiêu chí chấp nhận

Bản mô tả nên bắt đầu bằng người nhận và quyết định họ sẽ dùng kết quả để hỗ trợ. Trong ca giả định, người nhận là điều phối viên chuẩn bị hồ sơ cho cuộc họp, không phải hội đồng ra quyết định. Sản phẩm cần giúp tìm đúng chỗ cần xem và phân công người xác minh. Vì thế, tính truy vết và khả năng nhận diện thiếu sót quan trọng hơn văn phong thuyết phục hoặc độ dài báo cáo.

Nghiên cứu DSPy dùng khai báo nhiệm vụ với các trường đầu vào, đầu ra, đồng thời tách chương trình khỏi phần tối ưu theo chỉ số [2]. Từ góc nhìn giao việc, điều này gợi một cách làm rõ: nói sản phẩm phải có gì và đo nó thế nào trước khi tìm cách viết câu lệnh hiệu quả hơn. Khung thực hành của bài không đòi doanh nghiệp phải dùng DSPy để áp dụng nguyên tắc ấy.

Tiêu chí chấp nhận trong ca giả định có thể là mỗi điều kiện được ghi kèm vị trí nguồn, mỗi khoảng thiếu được nêu thành câu hỏi có người nhận và không có kết luận ngoài phạm vi. Một câu “hồ sơ đạt” sẽ không được chấp nhận chỉ vì câu chữ rõ ràng. Ngược lại, một bản nháp nói chưa xác minh được điều kiện vì thiếu phụ lục có thể đúng hợp đồng tác vụ và giúp nhóm xử lý tiếp.

Nên phân biệt tiêu chí bắt buộc với ưu tiên. Không bịa thông tin và không lộ hồ sơ ngoài quyền là điều kiện cần. Viết ngắn gọn hoặc sắp thứ tự theo độ quan trọng là ưu tiên có thể điều chỉnh. Nếu dồn tất cả vào một điểm trung bình, một bản nháp đẹp có thể bù điểm cho lỗi nghiêm trọng. Hãy cho người nhận thấy lỗi nào làm đầu ra phải dừng, thay vì chỉ nhìn một nhãn đạt chung.

Đầu vào phải có nghĩa, không chỉ có tên tệp

Một danh sách tệp chưa cho biết tài liệu nào là bản chính, phụ lục nào thay thế bản trước và hồ sơ nào người dùng được quyền mở. Cần ghi loại đầu vào, mã hồ sơ, thời điểm và những thông tin bắt buộc. Nếu một yêu cầu tới dưới dạng ảnh mờ, nó không nên được xử lý như bản văn đã đối chiếu. Hợp đồng tác vụ cần giữ khác biệt chất lượng này ngay từ lúc nhận việc.

Datasheets for Datasets đề xuất mô tả nguồn gốc, thành phần, mục đích và cách duy trì dữ liệu [3]. Áp dụng tinh thần mô tả này cho ca giả định, nhóm nên biết tài liệu do ai cung cấp, bản nào đã được xác nhận và có khoảng thiếu nào đã biết. Đây là cách tổ chức thông tin; điền danh mục không tự bảo đảm quyền sử dụng hoặc chất lượng của nội dung bên trong.

Có thể chia đầu vào thành dữ liệu bắt buộc, dữ liệu hỗ trợ và nội dung không được dùng. Hồ sơ chưa có mã hoặc không nhận diện được phiên bản phải chuyển người trước khi tổng hợp. Ghi chú của nhân viên được giữ như ý kiến, không biến thành điều kiện của hồ sơ mời thầu. Nguồn bên ngoài chỉ được thêm nếu nhiệm vụ cho phép và phải giữ riêng với tài liệu đã được công ty xác nhận.

Một lỗi thường gặp là yêu cầu AI suy ra thông tin chỉ để điền đủ trường. Nếu trang phụ lục chưa có, bản nháp nên ghi thiếu phụ lục cùng hệ quả cho việc kiểm. Nếu tên tài liệu gần giống nhau, cần dấu hiệu phân biệt thay vì tự chọn một bản. Cách xử lý đầu vào thiếu là một phần của việc được giao, không phải tình huống nằm ngoài kế hoạch mà mô hình phải tự xoay xở.

Đầu ra cần cấu trúc và nghĩa nghiệp vụ

Tài liệu JSON Schema cho thấy có thể mô tả thuộc tính bắt buộc, kiểu dữ liệu và cách xử lý thuộc tính bổ sung [4]. Các ràng buộc hình thức hữu ích khi kết quả phải được phần mềm khác đọc. Nhưng một chuỗi đúng kiểu hoặc một trường đã xuất hiện không xác nhận giá trị có thật. Cần giữ phép kiểm nghiệp vụ tách khỏi phép kiểm cấu trúc.

Trong ca hồ sơ giả định, một mục đầu ra có thể gồm điều kiện cần chú ý, đoạn chứng cứ, vị trí tài liệu và trạng thái xác minh. Nếu trường vị trí chứa “trang không rõ”, phần mềm vẫn có thể đọc chuỗi đó, nhưng người duyệt chưa đủ căn cứ. Hợp đồng tác vụ phải nói rõ khi nào trường hợp này được chấp nhận như bản nháp, khi nào cần dừng và hỏi người phụ trách.

Cũng cần thống nhất nghĩa của trạng thái. “Không tìm thấy” là kết quả của quá trình tìm trong phạm vi đã đọc, không luôn có nghĩa tài liệu không tồn tại. “Chưa xác minh” khác “không đáp ứng”. Một ứng dụng nên bảo toàn các khác biệt này qua bước lưu trữ và bàn giao. Nếu giao diện tự đổi mọi trạng thái thiếu thành ô trống, người nhận khó biết phải làm gì tiếp theo.

Bản nháp tốt nên hiển thị điều kiện và căn cứ trước câu nhận định. Người đọc có thể kiểm một phát biểu quan trọng mà không phải dò toàn bộ báo cáo. Đừng yêu cầu mô hình giải thích dài để thay cho vị trí nguồn. Đường kiểm cần dẫn tới tài liệu hoặc bản ghi cụ thể. Sau khi người sửa nội dung, phải biết phần nào đã được xác nhận để lần bàn giao sau không bị trộn với phần AI đề xuất.

Việc ngoài phạm vi và điều cấm cần đủ cụ thể

Đề xuất Model Cards khuyến khích nêu nhiệm vụ dự kiến, việc không được dự kiến cùng bối cảnh đo chất lượng mô hình [5]. Với hợp đồng tác vụ AI, doanh nghiệp có thể mô tả ranh giới tương tự ở cấp công việc. Đây là một bước làm rõ phạm vi, không phải cách chuyển trách nhiệm sang nhà cung cấp hay thay thế việc kiểm ứng dụng trong môi trường của mình.

Trong ví dụ, AI được trích thông tin và tạo câu hỏi, nhưng không được xác nhận tư cách pháp lý, tự tính một kết luận chuyên môn còn thiếu căn cứ hoặc gửi tài liệu ra bên ngoài. Những điều cấm này cần được ánh xạ tới giao diện và quyền công cụ. Nếu chỉ viết “không gửi” trong câu lệnh nhưng ứng dụng vẫn cấp công cụ gửi không giới hạn, nhóm chưa giải quyết đầy đủ ranh giới hành động.

Một câu cấm cũng cần đường đi thay thế. Khi gặp nội dung ngoài chuyên môn, trợ lý đánh dấu vấn đề và chuyển đúng người, kèm phạm vi đã đọc. Khi không có quyền mở tài liệu, nó thông báo thiếu quyền mà không tìm bản sao khác để lách. Khi công cụ không phản hồi, trạng thái là chưa xác nhận thao tác. Tránh tạo áp lực hoàn tất bằng mọi cách khiến hệ thống che điều kiện thiếu.

Người giao nên thử các yêu cầu gần ranh giới: đề nghị thêm người nhận thư, suy ra điều kiện chưa có hoặc dùng tài liệu của hồ sơ khác. Đây là các tình huống giả định để kiểm phạm vi, không phải hướng dẫn khai thác lỗ hổng. Kết quả cần được đánh giá theo hành vi thực tế, gồm công cụ đã chạy và dữ liệu đã truy cập, thay vì chỉ xem câu cuối nói rằng trợ lý tuân thủ.

Thiết kế đường hỏi lại và chuyển người

Nhóm nghiên cứu Microsoft cùng cộng sự bàn về thiết kế tương tác để người biết hệ thống làm được gì và thuận tiện sửa kết quả không phù hợp [6]. Trong ca giả định, điều đó có thể được thể hiện bằng câu hỏi bổ sung cụ thể và trạng thái dễ hiểu. Bài không coi hướng dẫn thiết kế này là bằng chứng một giao diện nhất định sẽ tăng năng suất trong mọi doanh nghiệp.

Câu hỏi lại nên làm giảm một khoảng không chắc có ảnh hưởng đến việc nhận kết quả. Hỏi “bạn có thể cung cấp thêm thông tin không” thường để người dùng tự đoán. Hỏi cần xác nhận bản phụ lục nào đang áp dụng sẽ hướng cuộc trao đổi vào đúng nguồn. Hợp đồng tác vụ nên liệt kê loại khoảng thiếu quan trọng, đồng thời tránh bắt người dùng trả lời những câu không cần cho phạm vi đã giao.

Chuyển người cần đủ thông tin để không bắt đầu lại. Hồ sơ bàn giao nên ghi yêu cầu ban đầu, nguồn đã mở, điểm đang thiếu và công việc chưa làm. Không nên gửi toàn bộ lịch sử theo thói quen nếu người nhận chỉ cần một phần. Người nhận ngoại lệ phải là một vai được phân công, có đường nhận việc khi vắng mặt, thay vì một nhãn chung như “chuyên gia xem thêm”.

Cũng cần chốt khi nào nhiệm vụ dừng hẳn. Nếu hồ sơ không thể nhận diện hoặc người giao không có quyền yêu cầu, ứng dụng không nên tiếp tục tạo báo cáo với nhiều lời cảnh báo để bù. Dừng có lý do là một kết quả hợp lệ nếu hợp đồng đã mô tả. Điều cần kiểm là người dùng hiểu phải bổ sung gì hoặc chuyển vấn đề cho ai, không chỉ nhận một thông báo lỗi kỹ thuật.

Biến tiêu chí thành bộ tình huống có thể thử

HELM tổ chức đánh giá theo tình huống và nhiều nhóm thước đo, thay vì chỉ một chỉ số đúng [7]. Khi xây bộ thử nội bộ, doanh nghiệp có thể học cách nêu điều muốn đo cùng điều chưa được bao phủ. Bộ thử của công ty vẫn phải được chọn cho nghiệp vụ riêng; không lấy điểm benchmark công khai để thay bằng chứng về hồ sơ mời thầu trong ví dụ.

Có thể bắt đầu bằng các nhóm tình huống: hồ sơ đủ, thiếu bản bắt buộc, hai bản mâu thuẫn, nguồn không đọc được và yêu cầu vượt quyền. Mỗi nhóm cần đầu ra mong đợi cùng lý do. Không phải mọi câu đều có một văn bản đáp án duy nhất. Có thể chấp nhận nhiều cách diễn đạt, nhưng bắt buộc giữ đúng sự kiện, trạng thái thiếu và điểm phải chuyển người.

Nên giữ riêng tình huống dùng để sửa yêu cầu và tình huống kiểm sau khi sửa. Nếu người xây cứ xem đáp án rồi điều chỉnh cho tới khi đúng hết, kết quả chủ yếu cho biết ứng dụng phù hợp các ví dụ đã biết. Chuyên viên nghiệp vụ có thể tạo thêm tình huống từ ngoại lệ có quyền sử dụng, kiểm chúng trước rồi mới đưa vào đánh giá. Ghi rõ dữ liệu giả lập và dữ liệu quan sát để tránh kể thử nghiệm thành triển khai.

Chỉ số cũng cần chống hiểu sai. Số trường được điền không đo tính đúng; tỷ lệ người bấm chấp nhận không luôn đo chất lượng; thời gian trả lời không bao gồm thời gian sửa nếu chưa được ghi. Một biên bản thử nên cho thấy những lỗi làm dừng, những lỗi có thể sửa và phần việc còn chuyển sang người. Khi đó hợp đồng tác vụ mới hỗ trợ quyết định mở rộng hay giữ phạm vi.

Quản lý phiên bản để không đổi yêu cầu một cách âm thầm

Nghiên cứu Structured Prompts Improve Evaluation of Language Models, bản cập nhật được mở trong đợt biên soạn này, xem ảnh hưởng của lựa chọn câu lệnh tới kết quả benchmark [8]. Phạm vi chủ yếu là các nhiệm vụ kiểm có đáp án xác định, không đại diện mọi báo cáo dài. Điều phù hợp cho quản lý tác vụ là ghi cấu hình thử, tránh gán mọi thay đổi điểm số cho riêng mô hình.

Trong ca giả định, nếu đổi từ “liệt kê điều kiện” sang “đánh giá mức phù hợp”, phạm vi đã thay đổi dù chỉ thêm ít chữ. Nếu bổ sung quyền mở kho khác, nguồn cũng đã thay đổi. Mỗi bản hợp đồng tác vụ nên có người sở hữu, lý do sửa và tập tình huống cần chạy lại. Không nhất thiết dùng hệ thống phức tạp; một sổ phiên bản có thể xem khác biệt đã giúp việc thảo luận rõ hơn.

Giữ nguyên bản mô tả nghiệp vụ khi so nhiều cách thực hiện. Câu lệnh, công cụ và mô hình có thể khác, nhưng người nhận cùng tiêu chí chấp nhận phải rõ. Nếu một phương án chỉ tạo tóm tắt còn phương án khác phải truy nguồn và lập câu hỏi, không nên so thời gian rồi kết luận phương án nhanh hơn tốt hơn. Chúng đang làm hai việc khác nhau.

Áp dụng theo quy mô doanh nghiệp Việt Nam

Đội rất nhỏ có thể dùng một trang gồm mục tiêu, đầu vào, mẫu đầu ra và người duyệt. Chọn việc dễ kiểm như chuẩn bị danh sách câu hỏi từ tài liệu được phép dùng. Chưa cần tích hợp tự động hoặc bộ mô tả máy đọc được. Mục tiêu ban đầu là hai người đọc cùng bản mô tả có hiểu giống nhau và xử lý được đầu vào thiếu mà không hỏi lại từ đầu hay không.

Doanh nghiệp vừa có thể chuẩn hóa các trường dùng chung, nhưng giữ tiêu chí riêng của từng bộ phận. Hồ sơ chuẩn bị họp của đội kinh doanh khác hồ sơ giao kỹ thuật dù cùng định dạng tệp. Cần một nơi nhận đề nghị sửa bản mô tả, tránh mỗi nhân viên lưu một mẫu câu lệnh rồi tự thay điều kiện. Ghi ai được đổi quyền hoặc nguồn, bên cạnh ai được sửa câu chữ cho dễ hiểu.

Doanh nghiệp lớn cần nối hợp đồng tác vụ với danh mục ứng dụng và quản lý thay đổi. NIST AI RMF nhấn mạnh phân vai và quản lý rủi ro theo bối cảnh, vòng đời hệ thống [9]. Trong phân tích của bài, điều này gợi ý mỗi nhóm nghiệp vụ giữ tiêu chí nhận việc, còn nhóm nền tảng duy trì thành phần chung. Khung tham khảo không quyết định cơ cấu hay nghĩa vụ pháp lý thay doanh nghiệp.

Hỏi đáp về cách giao việc cho AI

Hợp đồng tác vụ có phải một prompt dài không? Không nhất thiết. Nó giữ yêu cầu nghiệp vụ ổn định, còn câu lệnh là một cách chuyển yêu cầu sang mô hình. Bản mô tả có thể ngắn nếu đầu vào và tiêu chí rõ. Viết dài nhưng không chốt người nhận, nguồn hoặc trạng thái thiếu vẫn để lại khoảng trống. Hãy thử bàn giao cùng bản mô tả cho người khác để xem họ hiểu việc ra sao.

Có cần lập trình viên mới viết được bản mô tả này không? Không. Người phụ trách nghiệp vụ cần mô tả kết quả và ngoại lệ trước; nhóm kỹ thuật giúp chuyển phần có thể kiểm thành giao diện, ràng buộc và quyền. Nếu chưa có kỹ thuật, vẫn có thể thử bằng tài liệu giả lập cùng người duyệt. Đừng để việc chưa chọn được công cụ ngăn nhóm thống nhất ý nghĩa của một kết quả đúng.

Đầu ra đúng cấu trúc thì có thể bỏ người duyệt không? Chưa có cơ sở để kết luận chỉ từ cấu trúc. Cần kiểm căn cứ, điều kiện áp dụng và hậu quả của việc dùng kết quả. Với hồ sơ giả định trong bài, đầu ra luôn là bản nháp chuẩn bị họp. Việc tăng quyền cần được đánh giá riêng, có bộ thử và người chịu trách nhiệm, thay vì tự mở sau một lần trả đúng định dạng.

Khi nào cần sửa hợp đồng tác vụ thay vì sửa câu lệnh? Khi mục tiêu, nguồn, người nhận, tiêu chí hoặc quyền đã đổi. Nếu yêu cầu vẫn giữ nguyên nhưng cách diễn đạt khiến mô hình hiểu nhầm, có thể sửa câu lệnh rồi thử lại. Ghi hai loại thay đổi riêng giúp tránh vô tình đổi việc để làm kết quả trông tốt hơn. Nếu chưa phân biệt được, nên kiểm lại yêu cầu với người nhận đầu ra.

Nguồn và phương pháp

Đây là phân tích có hỗ trợ AI, biên soạn bằng lời và khung tình huống riêng, không phải bản dịch. Đã mở các công trình gốc và tài liệu chính thức trong ngày 27/10/2026, dùng đúng phạm vi ghi ở hồ sơ nguồn; công trình có xuất xứ hãng được nêu trong bài. Hợp đồng tác vụ là khung thực hành đề xuất, không phải hợp đồng pháp lý. Ca hồ sơ và phép thử đều giả định; chưa có thử nghiệm doanh nghiệp Việt Nam hoặc thẩm định chuyên gia.