Trả lời nhanh: Human-in-the-loop (HITL) là cách thiết kế hệ thống AI hoặc tự động hoá để con người tham gia vào một khâu của vòng lặp: gán nhãn dữ liệu, duyệt kết quả nghi ngờ, phê duyệt hành động hoặc sửa lỗi. Phản hồi của người thường được đưa ngược lại để mô hình tốt hơn.
Điểm chính
- HITL là một mẫu thiết kế, không phải một phần mềm. Người có thể xuất hiện trước, trong hoặc sau khi mô hình chạy.
- Cơ chế phổ biến nhất là chuyển các ca có độ tin cậy thấp hoặc hậu quả lớn sang người duyệt.
- Human-in-the-loop, human-on-the-loop và human-in-command khác nhau ở thời điểm và quyền của người.
- Rủi ro lớn nhất là người duyệt bấm đồng ý theo thói quen (automation bias), khi đó vòng lặp chỉ còn trên giấy.
Mục lục
- Human-in-the-loop là gì?
- HITL hoạt động như thế nào?
- Human-in-the-loop, on-the-loop và in-command khác nhau ra sao?
- Ví dụ HITL trong doanh nghiệp Việt Nam
- Làm sao chọn ca nào cần người duyệt?
- Làm sao để người duyệt không chỉ bấm cho xong?
- Ưu điểm và nhược điểm của HITL
- HITL khác gì với các khái niệm gần?
- Khi nào nên và không nên dùng HITL?
- Triển khai HITL cần chuẩn bị những gì?
- Câu hỏi thường gặp
Human-in-the-loop là gì?
Human-in-the-loop (HITL), tiếng Việt thường dịch là “con người trong vòng lặp”, là cách xây dựng hệ thống AI mà ở đó con người chủ động tham gia vận hành, giám sát hoặc ra quyết định cùng máy. Theo cách IBM và Databricks mô tả, “vòng lặp” là chu trình: mô hình tạo kết quả, người xem xét hoặc sửa, rồi phản hồi đó quay lại hệ thống.
Mục tiêu là lấy tốc độ của tự động hoá nhưng không đánh mất khả năng xử lý tình huống mơ hồ của con người. Các mô hình học máy dù mạnh vẫn dễ sai ở ca hiếm, ca mơ hồ hoặc ca khác xa dữ liệu đã học.
Điểm cần nhớ ngay từ đầu: HITL không có nghĩa là “người kiểm tra lại mọi thứ”. Nếu người xem lại 100% kết quả thì đó chỉ là làm tay có thêm công cụ gợi ý. HITL đúng nghĩa là xác định được ca nào cần người, người đó được quyền làm gì và sửa xong thì dữ liệu đi đâu.
HITL hoạt động như thế nào?
Về cơ chế, một vòng HITL gồm bốn thao tác lặp đi lặp lại. Mô hình đưa dự đoán, hệ thống chấm độ tin cậy, người xử lý những ca không đủ tin cậy, và các bản sửa được lưu lại thành dữ liệu huấn luyện hoặc quy tắc mới.
Ba điểm có thể chèn con người
- Trước khi mô hình chạy: người gán nhãn tạo dữ liệu mẫu đúng. Phần này có hẳn quy trình riêng, bạn xem thêm ở bài quy trình gán nhãn dữ liệu.
- Trong lúc huấn luyện và tinh chỉnh: người chọn mẫu khó để dạy tiếp (active learning), hoặc xếp hạng các câu trả lời của mô hình ngôn ngữ để tinh chỉnh theo phản hồi (RLHF, reinforcement learning from human feedback). Tài liệu nghiên cứu về mô hình ngôn ngữ lớn xem RLHF là ví dụ tiêu biểu của HITL.
- Sau khi triển khai: người duyệt đầu ra, xử lý ca chuyển tiếp (escalation), hoặc phê duyệt hành động của tác tử AI trước khi nó ghi vào hệ thống thật.
Active learning là kỹ thuật đáng chú ý vì nó giải bài toán chi phí. Thay vì nhờ người gán nhãn toàn bộ 100.000 ảnh, mô hình tự chỉ ra những ảnh nó phân vân nhất để người gán nhãn trước. Một nhãn của người ở ca khó thường có giá trị học cao hơn nhiều nhãn ở ca dễ.
Human-in-the-loop, on-the-loop và in-command khác nhau ra sao?
Ba thuật ngữ này hay bị dùng lẫn. Khác biệt nằm ở việc người đứng ở đâu so với quyết định của máy.
| Tiêu chí | Human-in-the-loop | Human-on-the-loop | Human-in-command |
|---|---|---|---|
| Thời điểm | Đồng bộ: máy chờ người | Bất đồng bộ: máy chạy, người theo dõi | Ở tầng chiến lược, trước và sau |
| Người làm gì | Duyệt, sửa, chọn từng ca | Xem cảnh báo, can thiệp khi lệch | Quyết định có dùng hệ thống không, khi nào dừng |
| Tốc độ | Chậm hơn, phụ thuộc hàng đợi | Gần với tự động hoàn toàn | Không ảnh hưởng tốc độ từng ca |
| Ví dụ minh hoạ | Nhân viên xác nhận hóa đơn mà OCR đọc không chắc | Giám sát viên xem bảng cảnh báo giao dịch bất thường | Ban lãnh đạo quyết định tắt mô hình khi tỷ lệ sai vượt ngưỡng |
Cách phân biệt này được Databricks dùng cho hai khái niệm đầu, còn bên tuân thủ của EU hay gọi đủ ba mô hình. Trong thực tế một hệ thống thường kết hợp cả ba: ca nhỏ chạy tự động, ca nghi ngờ qua người duyệt, và ban quản lý giữ quyền dừng.
Ví dụ HITL trong doanh nghiệp Việt Nam
Các ví dụ dưới đây là tình huống minh hoạ, không phải số liệu của một doanh nghiệp cụ thể.
Đọc hoá đơn và chứng từ bằng OCR
Ví dụ minh hoạ: một phòng kế toán dùng OCR để đọc hoá đơn đầu vào. Mô hình trả về từng trường (mã số thuế, số hoá đơn, tổng tiền) kèm điểm tin cậy. Trường nào dưới ngưỡng sẽ hiện lên màn hình cho kế toán đối chiếu với ảnh gốc. Chỉ những trường bị sửa mới được lưu làm mẫu huấn luyện, nên khối lượng người xem nhỏ hơn nhiều so với đọc lại toàn bộ.
Chatbot chăm sóc khách hàng chuyển cho tổng đài viên
Chatbot trả lời câu hỏi thường gặp, nhưng khi khách nhắc đến khiếu nại, hoàn tiền hoặc khi mô hình nhận ra câu hỏi nằm ngoài kịch bản thì chuyển sang người. Điểm đáng thiết kế là chuyển kèm toàn bộ lịch sử hội thoại, để khách không phải nhắc lại. Cách chuyển ca này còn cho bạn một tập dữ liệu về những câu chatbot chưa biết trả lời.
Kiểm duyệt nội dung và đánh giá hồ sơ
Với nội dung người dùng đăng, AI gắn cờ, người kiểm duyệt xác nhận hoặc bác. Với hồ sơ vay hay hồ sơ tuyển dụng, mô hình chỉ xếp hạng hoặc gợi ý, quyết định cuối do người ký. Đây là chỗ HITL gắn với dữ liệu cá nhân: người duyệt thường nhìn thấy họ tên, số định danh, thu nhập, nên cần phân quyền theo trường dữ liệu và ghi log ai đã xem hồ sơ nào. Nếu mô hình chỉ cần một vài trường, hãy cân nhắc che giấu dữ liệu nhạy cảm ở màn hình duyệt.
Gán nhãn dữ liệu huấn luyện
Đây là dạng HITL lâu đời nhất. Người gán nhãn đánh dấu ảnh, văn bản, âm thanh làm “đáp án” cho mô hình học có giám sát. Nếu bạn cần hiểu nghề này, hãy đọc bài về gán nhãn dữ liệu và annotator.
Làm sao chọn ca nào cần người duyệt?
Đây là câu hỏi thiết kế quan trọng nhất và bài top thường bỏ qua. Có hai trục để quyết định: mô hình tự tin đến mức nào, và nếu sai thì hậu quả nặng đến đâu.
Ngưỡng tin cậy và các bẫy kỹ thuật
- Điểm tin cậy chưa chắc là xác suất đúng. Nhiều mô hình tự tin quá mức. Hãy hiệu chỉnh (calibration) bằng một tập kiểm chứng: lấy các ca mô hình báo 90% rồi đếm xem thực tế đúng bao nhiêu.
- Ngưỡng theo từng trường, không theo cả hồ sơ. Trên hoá đơn, sai một chữ trong tên người bán ít nghiêm trọng hơn sai một chữ số trong tổng tiền. Mỗi trường nên có ngưỡng riêng.
- Lấy mẫu cả ca tin cậy cao. Nếu người chỉ thấy ca nghi ngờ, bạn không biết mô hình có đang sai âm thầm ở ca nó tự tin hay không. Rút ngẫu nhiên một tỷ lệ nhỏ ca tự động để kiểm tra.
- Thiên lệch chọn mẫu. Nếu mô hình chỉ học từ ca khó mà người đã sửa, tập huấn luyện sẽ lệch khỏi phân bố thực. Cần trộn thêm mẫu ngẫu nhiên.
Làm sao để người duyệt không chỉ bấm cho xong?
Đây là rủi ro lớn nhất của HITL. Khi mô hình đúng 95% thời gian, người duyệt dần tin theo và ngừng đọc kỹ. Hiện tượng này gọi là thiên lệch tự động hoá (automation bias). Nghiên cứu về Đạo luật AI của EU cũng ghi nhận rằng đưa người vào vòng lặp không tự động hoá giải rủi ro của AI.
Một số biện pháp đo được:
- Chèn ca kiểm chứng. Trộn vào hàng đợi một số ca đã biết đáp án (có mô hình sai cố ý). Nếu người duyệt bỏ sót nhiều, họ đang duyệt hình thức.
- Theo dõi thời gian xử lý mỗi ca. Thời gian xuống quá thấp so với độ phức tạp là dấu hiệu duyệt vội.
- Ẩn gợi ý của mô hình ở một số ca để người tự đánh giá trước, rồi so sánh với gợi ý.
- Đo độ đồng thuận giữa các người gán nhãn (inter-annotator agreement), ví dụ bằng hệ số Cohen’s kappa. Nếu hai người giỏi gán khác nhau nhiều, vấn đề nằm ở hướng dẫn gán nhãn chứ chưa phải ở mô hình.
- Giữ giao diện đủ thông tin. Người duyệt cần thấy dữ liệu gốc cạnh dự đoán, lý do mô hình nghi ngờ và nút từ chối rõ ràng.
Người duyệt cũng cần hiểu dữ liệu họ đang xử lý. Vai trò quản lý chất lượng nghiệp vụ này gần với người quản lý dữ liệu nghiệp vụ trong tổ chức, đặc biệt khi bản sửa của người sẽ trở thành dữ liệu huấn luyện.
Về pháp lý, Điều 14 của Đạo luật AI của EU yêu cầu hệ thống AI rủi ro cao phải được thiết kế để con người giám sát hiệu quả, và người giám sát phải nhận biết được xu hướng tin theo kết quả máy. Đây là tham chiếu quốc tế đáng đọc nếu bạn thiết kế quy trình duyệt cho hệ thống ảnh hưởng đến quyền lợi của người dùng. Nó không phải văn bản có hiệu lực tại Việt Nam.
Ưu điểm và nhược điểm của HITL
| Ưu điểm | Nhược điểm |
|---|---|
| Bắt được ca hiếm, ca mơ hồ mà mô hình chưa gặp | Chi phí nhân sự và hàng đợi tăng khi khối lượng lớn |
| Tạo dữ liệu huấn luyện sát thực tế sau mỗi lần sửa | Bản sửa kém chất lượng làm hỏng dữ liệu học |
| Có người chịu trách nhiệm ở quyết định hệ trọng | Dễ rơi vào duyệt hình thức do thiên lệch tự động hoá |
| Giảm dần số ca cần duyệt khi mô hình cải thiện | Độ trễ: máy phải chờ người ở chế độ đồng bộ |
Chất lượng bản sửa quyết định chất lượng vòng lặp. Nguyên lý rác vào thì rác ra áp dụng cả cho phản hồi của người, bạn có thể đọc thêm ở bài về garbage in, garbage out.
HITL khác gì với các khái niệm gần?
- Active learning: là một kỹ thuật bên trong HITL, trong đó mô hình chọn mẫu để hỏi người. HITL rộng hơn, bao cả duyệt kết quả khi vận hành.
- RLHF: dùng xếp hạng của người để tinh chỉnh mô hình ngôn ngữ. Người tham gia lúc huấn luyện, không nhất thiết ở từng yêu cầu khi chạy.
- Tự động hoá hoàn toàn: không có điểm chặn nào cho người ở từng ca. Phù hợp khi sai ít tốn kém.
- Tăng cường dữ liệu và dữ liệu tổng hợp: là cách giảm nhu cầu gán nhãn tay, không thay thế việc kiểm tra bằng người. Bạn có thể xem bài về tăng cường dữ liệu để thấy ranh giới này.
Khi nào nên và không nên dùng HITL?
Nên dùng
- Sai một ca gây thiệt hại tiền bạc, sức khoẻ, danh tiếng hoặc quyền lợi khách hàng (duyệt khoản vay, đọc ảnh y khoa, khoá tài khoản).
- Mô hình mới, dữ liệu huấn luyện còn ít, hoặc đang chạy ở lĩnh vực nhiều ca ngoại lệ.
- Bạn cần chính hoạt động duyệt để tạo dữ liệu huấn luyện mà hiện chưa có.
- Tác tử AI sắp thực hiện hành động khó hoàn tác như xoá dữ liệu, chuyển tiền, gửi email hàng loạt.
Không nên hoặc chưa cần
- Tác vụ khối lượng rất lớn, chi phí sai thấp và dễ hoàn tác, như gợi ý sản phẩm hay gắn thẻ ảnh nội bộ. Giám sát định kỳ bằng lấy mẫu là đủ.
- Khi chưa có tiêu chuẩn đúng/sai viết ra được. Người duyệt sẽ quyết định mỗi người một kiểu và dữ liệu huấn luyện nhiễu.
- Khi người duyệt không được trao quyền bác kết quả của máy. Lúc đó vai trò của họ chỉ mang tính hình thức.
Triển khai HITL cần chuẩn bị những gì?
- Viết tiêu chí đúng/sai cho từng loại ca, kèm ví dụ ca biên. Đây chính là hướng dẫn gán nhãn.
- Chọn ngưỡng và kênh chuyển ca: ca nào vào hàng đợi, ưu tiên theo hậu quả, thời hạn xử lý.
- Thiết kế giao diện duyệt: hiển thị dữ liệu gốc, dự đoán, điểm tin cậy; cho phép sửa, từ chối, ghi lý do.
- Lưu bản sửa có cấu trúc: ai sửa, lúc nào, trước và sau. Không có bước này vòng lặp chỉ có “người” chứ không có “học”.
- Theo dõi chỉ số: tỷ lệ ca chuyển sang người, tỷ lệ người sửa mô hình, độ đồng thuận giữa người duyệt, độ trôi dữ liệu. Các cảnh báo trôi dữ liệu thường đến từ công cụ quan sát dữ liệu.
Lưu ý riêng cho chất lượng nguồn: nếu bản sửa của người đi vào kho dữ liệu dùng chung, hãy kiểm tra chúng bằng cùng bộ quy tắc như mọi dữ liệu khác, ví dụ theo khung chất lượng dữ liệu.
Câu hỏi thường gặp
Human-in-the-loop viết tắt là gì?
Viết tắt là HITL. Có người đọc là “hit-l”. Nhiều tài liệu tiếng Việt dịch là “con người trong vòng lặp” hoặc “có sự tham gia của con người”.
HITL có làm AI chậm đi không?
Có, nếu máy phải chờ người ở từng ca. Cách giảm độ trễ là chỉ chuyển ca nghi ngờ hoặc hệ trọng sang người, và để các ca còn lại chạy tự động kèm lấy mẫu kiểm tra. Ở chế độ on-the-loop, máy không phải chờ.
Human-in-the-loop và human-on-the-loop khác nhau chỗ nào?
Ở in-the-loop, quyết định chỉ thực hiện sau khi người duyệt. Ở on-the-loop, hệ thống tự chạy, người giám sát và can thiệp khi thấy bất thường. Cái đầu hợp với quyết định có hậu quả lớn, cái sau hợp với khối lượng lớn cần phản ứng nhanh.
Gán nhãn dữ liệu có phải là HITL không?
Có. Gán nhãn là dạng HITL ở giai đoạn chuẩn bị dữ liệu, khi người tạo đáp án mẫu cho mô hình học có giám sát. HITL bao rộng hơn: cũng gồm duyệt kết quả và phê duyệt hành động sau khi triển khai.
Có thể bỏ người khỏi vòng lặp khi mô hình đủ tốt không?
Có thể giảm dần, nhưng thường không bỏ hẳn ở quyết định hệ trọng. Bạn nên chuyển từ duyệt từng ca sang giám sát bằng lấy mẫu và cảnh báo trôi dữ liệu, đồng thời giữ quyền dừng hệ thống cho một người cụ thể.
Quy định nào yêu cầu có con người giám sát AI?
Đạo luật AI của EU yêu cầu hệ thống rủi ro cao phải cho phép con người giám sát hiệu quả theo Điều 14. Nếu hệ thống của bạn xử lý dữ liệu cá nhân hoặc ảnh hưởng đến quyền lợi người dùng ở Việt Nam, hãy đối chiếu với quy định nội địa hiện hành. Bài này không phải tư vấn pháp lý.
Bài viết thuộc chuyên mục Dữ liệu & phân tích trên trang tin công nghệ VBPO, trang tin tức và kiến thức công nghệ cho doanh nghiệp Việt Nam về AI, dữ liệu, blockchain, chuyển đổi số và tự động hoá.