Khi thí điểm AI không như kỳ vọng, nguyên nhân thường rơi vào một trong sáu loại: chọn sai việc, đầu vào kém, câu lệnh chưa đủ, bước duyệt gây nghẽn, người dùng chưa được hướng dẫn đủ hoặc không có thời gian, và kỳ vọng ban đầu quá cao. Mỗi loại có dấu hiệu riêng trong nhật ký thí điểm và cách gỡ riêng. Chỉ khi đã gỡ mà vẫn không cải thiện mới nên đổi việc hoặc dừng.
Bài này giúp người phụ trách AI đọc nhật ký để tìm đúng nguyên nhân thay vì đổ cho công cụ, và đưa ra cách xử lý cho từng loại. Một thí điểm vấp ở tuần thứ ba là chuyện bình thường; điều đáng lo là vấp mà không ai biết vì sao, rồi dự án lặng lẽ bị bỏ.
Dấu hiệu sớm: đừng đợi đến buổi tổng kết
Ba dấu hiệu nên khiến người phụ trách AI dừng lại xem ngay, không đợi họp chốt chặng. Thứ nhất, nhật ký thưa dần: tuần đầu mỗi người ghi mười lượt, tuần ba chỉ còn hai ba lượt. Thứ hai, cột mức sửa toàn "bỏ và tự viết lại" hoặc "sửa nặng" mà không giảm qua các tuần. Thứ ba, người tham gia bắt đầu nói những câu như "làm tay còn nhanh hơn" hay "để em làm cách cũ cho kịp".
Những dấu hiệu này không có nghĩa là thí điểm thất bại. Chúng có nghĩa là có điều gì đó chưa đúng và cần chẩn đoán. Càng phát hiện sớm, càng có thời gian sửa trong khuôn khổ chín mươi ngày. Phát hiện ở ngày thứ tám mươi thì chỉ còn đủ thời gian để kết luận "không hiệu quả" mà không biết vì sao.
Cách làm đơn giản: mỗi thứ Sáu, người phụ trách AI dành ba mươi phút đọc nhật ký tuần, đếm số lượt theo từng người và tỷ lệ theo từng mức sửa. Nếu một trong ba dấu hiệu xuất hiện, hẹn từng người tham gia nói chuyện mười phút trong tuần sau.
Sáu loại vướng mắc: dấu hiệu và cách gỡ
Bảng dưới giúp đi từ triệu chứng trong nhật ký đến nguyên nhân có khả năng nhất. Thường có hai loại cùng lúc; gỡ loại dễ trước để thấy loại còn lại rõ hơn.
| Loại vướng mắc | Dấu hiệu trong nhật ký và lời người dùng | Cách gỡ |
|---|---|---|
| Chọn sai việc | Mỗi lượt khác nhau quá nhiều, AI không có khuôn để theo; "việc này mỗi lần một kiểu" | Thu hẹp phạm vi về loại lượt có khuôn, hoặc đổi sang việc khác trong danh sách ứng viên |
| Đầu vào kém | Lỗi tập trung ở thông tin sai, thiếu; AI bịa vì tài liệu không có | Dọn tài liệu nguồn, chuẩn hoá mẫu đầu vào, thêm hướng dẫn "không có thì để trống" |
| Câu lệnh chưa đủ | Lỗi lặp lại cùng kiểu: sai giọng, thiếu ý, sai định dạng | Sửa câu lệnh theo từng lỗi, thêm ví dụ đầu ra đạt chuẩn, đánh số phiên bản |
| Bước duyệt gây nghẽn | Thời gian soạn giảm nhưng tổng thời gian không giảm; đầu ra chờ duyệt | Phân loại đầu ra theo rủi ro, uỷ quyền duyệt, danh sách kiểm ngắn |
| Người dùng chưa đủ hướng dẫn hoặc thiếu thời gian | Một hai người dùng tốt, số còn lại bỏ; "chưa biết làm", "không có thời gian thử" | Kèm cặp một một, giờ hỏi đáp, xin trưởng phòng bớt việc khác trong thời gian thí điểm |
| Kỳ vọng quá cao | Số đo có cải thiện nhưng lãnh đạo thấy "chưa đủ"; so với lời hứa của người bán | Trình bày lại số đo trước và sau, điều chỉnh mục tiêu theo dữ liệu thực |
Chọn sai việc: nhận ra và xử lý
Một việc trông lặp lại trên giấy có thể rất đa dạng trong thực tế. Ví dụ giả định: một công ty dịch vụ vệ sinh công nghiệp chọn thí điểm "soạn báo giá dịch vụ". Khi chạy, nhóm nhận ra mỗi báo giá phụ thuộc vào khảo sát hiện trường, loại bề mặt, tần suất, yêu cầu riêng của từng toà nhà, nên AI soạn bản nào cũng phải sửa gần hết.
Cách gỡ ở đây là thu hẹp, không phải bỏ. Nhóm tách báo giá thành hai phần: phần giới thiệu công ty, quy trình làm việc, cam kết chung, điều khoản thanh toán thì AI soạn tốt vì có khuôn; phần hạng mục và đơn giá thì nhân viên tự làm từ biên bản khảo sát. Sau khi tách, tỷ lệ sửa nặng giảm rõ, và thời gian soạn phần văn bản chung giảm theo nhật ký.
Nếu thu hẹp rồi mà phần còn lại quá nhỏ để đáng làm, đó là lúc đổi sang việc thứ hai trong danh sách ứng viên. Ghi lại vì sao việc đầu không hợp, để lần chọn sau tránh loại việc tương tự.
Đầu vào kém và câu lệnh chưa đủ: hai lỗi hay bị nhầm với nhau
Khi AI trả lời sai, phản xạ đầu tiên của nhiều người là sửa câu lệnh. Nhưng nếu lỗi nằm ở đầu vào, sửa câu lệnh bao nhiêu cũng không hết. Cách phân biệt: đọc kỹ năm đầu ra sai, với mỗi cái hỏi "thông tin đúng có nằm trong đầu vào không". Nếu không có, đó là lỗi đầu vào: tài liệu thiếu, người dùng dán thiếu, dữ liệu cũ. Nếu có mà AI vẫn bỏ qua hoặc diễn đạt sai, đó là lỗi câu lệnh.
Lỗi đầu vào gỡ bằng cách chuẩn hoá cái được đưa vào: một mẫu điền sẵn các trường cần có trước khi gọi AI, một tài liệu nguồn đã dọn, một hướng dẫn rõ trong câu lệnh rằng thiếu thông tin thì để trống và đánh dấu chứ không được tự điền. Hướng dẫn cuối này giảm đáng kể kiểu lỗi AI bịa số liệu.
Lỗi câu lệnh gỡ theo từng lỗi cụ thể: AI quá dài dòng thì ghi giới hạn độ dài; giọng quá suồng sã thì mô tả người đọc và giọng mong muốn, kèm một ví dụ; hay bỏ ý thì liệt kê các ý bắt buộc. Mỗi lần sửa, chạy lại trên cùng năm lượt mẫu đã sai để xem có sửa được không, có làm hỏng chỗ khác không.
Khi vấn đề nằm ở con người và thời gian
Có những thí điểm mà công cụ và câu lệnh đều ổn, nhưng người dùng không dùng. Lý do hay gặp nhất không phải là phản đối AI, mà là không có thời gian: họ vẫn phải làm đủ việc cũ, cộng thêm thí điểm. Trong tuần bận, cách cũ quen tay luôn thắng cách mới chưa quen. Gỡ việc này là trách nhiệm của lãnh đạo bảo trợ và trưởng phòng, không phải của người phụ trách AI.
Lý do thứ hai là chưa được hướng dẫn đủ, nhưng ngại hỏi. Người lớn tuổi hơn, người không quen công nghệ thường không muốn lộ ra là mình chưa biết. Kèm cặp một một trong mười lăm phút, ngồi cạnh làm thử một lượt việc thật, hiệu quả hơn nhiều so với gửi thêm tài liệu hướng dẫn.
Lý do thứ ba là lo ngại không được nói ra: sợ làm nhanh hơn thì bị giao thêm việc, sợ sau thí điểm sẽ bị cắt người. Nếu công ty chưa nói rõ mục tiêu của dự án, hãy nói lại, bằng lời của lãnh đạo, và giữ lời. Những cuộc trò chuyện riêng với từng người lo lắng là kỹ năng của trưởng nhóm, có bài kỹ hơn ở AI Lãnh Đạo.
Bước duyệt gây nghẽn và kỳ vọng quá cao: hai lỗi nằm ngoài công cụ
Bước duyệt gây nghẽn là lỗi khó thấy nhất vì mọi số đo của khâu soạn đều đẹp. Người làm soạn nháp nhanh hơn hẳn, nhưng đầu ra nằm chờ trưởng phòng duyệt cả buổi, nên tổng thời gian từ lúc nhận việc đến lúc gửi cho khách gần như không đổi. Nhật ký sẽ cho thấy điều này nếu có hai cột thời gian riêng: thời gian soạn và thời gian chờ duyệt. Thiếu cột thứ hai thì nhóm dễ kết luận sai rằng AI không giúp gì.
Cách gỡ là phân loại đầu ra theo mức rủi ro. Ví dụ giả định ở một công ty phân phối thiết bị văn phòng: thư xác nhận đơn hàng, thư nhắc lịch giao theo khuôn có sẵn thì nhân viên tự kiểm theo danh sách năm dòng rồi gửi; thư trả lời khiếu nại, thư có nhắc đến tiền hoặc cam kết thì vẫn qua trưởng nhóm. Chốt duyệt không bị bỏ, chỉ được đặt đúng chỗ cần nó. Ghi rõ phân loại này vào quy trình, đừng để mỗi người tự hiểu.
Kỳ vọng quá cao thì gỡ bằng con số chứ không bằng tranh luận. Khi lãnh đạo nói "chưa thấy khác gì", đặt cạnh nhau số đo của tuần ghi ban đầu theo cách làm cũ và bốn tuần gần nhất. Nếu cải thiện có thật nhưng nhỏ hơn mức người bán công cụ từng giới thiệu, hãy nói thẳng: mức đó đo ở điều kiện khác, còn đây là số của chính công ty. Mục tiêu cho chặng sau nên đặt lại theo dữ liệu này.
Quy trình gỡ trong hai tuần
Khi nhật ký có dấu hiệu xấu, đừng sửa nhiều thứ cùng lúc vì sẽ không biết thứ nào có tác dụng. Quy trình hai tuần dưới đây giúp gỡ có kiểm soát:
- Ngày 1–2: đọc nhật ký, chọn năm đến mười lượt điển hình có vấn đề, nói chuyện ngắn với từng người tham gia.
- Ngày 3: họp nhóm ba mươi phút, thống nhất nguyên nhân chính theo bảng sáu loại. Chọn một nguyên nhân để gỡ trước.
- Ngày 4–8: áp dụng cách gỡ cho nguyên nhân đó. Chỉ đổi một thứ, ví dụ chỉ sửa câu lệnh hoặc chỉ đổi người duyệt. Tiếp tục ghi nhật ký như cũ.
- Ngày 9–10: so nhật ký năm ngày sau với năm ngày trước. Nếu cải thiện rõ, giữ thay đổi và chuyển sang nguyên nhân thứ hai nếu còn.
- Ngày 11–14: nếu không cải thiện, thử cách gỡ thứ hai hoặc chuẩn bị đề xuất thu hẹp phạm vi hay đổi việc ở buổi họp chốt chặng.
Ghi toàn bộ quá trình vào báo cáo thí điểm, kể cả những cách gỡ không có tác dụng. Đây là phần quý nhất của báo cáo cho đợt nhân rộng sau, vì nó cho phòng mới biết trước những chỗ hay vấp.
Khi nào nên dừng hẳn
Có những trường hợp dừng là đúng. Đã gỡ hai vòng mà số đo không cải thiện. Phát hiện rủi ro dữ liệu hoặc pháp lý mà công cụ hiện tại không xử lý được. Việc thí điểm thay đổi bản chất, ví dụ công ty bỏ dòng sản phẩm liên quan. Hoặc chi phí thời gian để duy trì vượt xa lợi ích quan sát được.
Dừng không có nghĩa là thất bại của người tham gia. Hãy nói rõ điều đó trong buổi tổng kết và trong thông báo cho công ty. Ghi lại ba thứ: việc gì, vì sao dừng, học được gì cho lần sau. Một thí điểm dừng có ghi chép rõ ràng thường giúp đợt sau chọn việc đúng hơn và tránh được đúng những vấp ngã đó.
Điều nên tránh là để dự án lửng lơ: không ai nói dừng, nhưng cũng không ai dùng. Trạng thái này tệ hơn dừng hẳn, vì nó làm cả công ty tin rằng "AI ở công ty mình không chạy", và lần sau khó kêu gọi người tham gia hơn.
Câu hỏi thường gặp
Thí điểm được ba tuần mà chưa thấy nhanh hơn có bình thường không?
Khá bình thường. Ba tuần đầu người dùng còn đang học cách giao việc và câu lệnh còn đang được chỉnh, nên thời gian có thể bằng hoặc chậm hơn cách cũ. Điều cần xem là xu hướng: tỷ lệ phải sửa nặng có giảm dần qua từng tuần không.
Làm sao biết lỗi do công cụ hay do cách dùng?
Thử cùng năm lượt việc có vấn đề với câu lệnh đã sửa kỹ và đầu vào đầy đủ. Nếu kết quả tốt lên rõ, lỗi do cách dùng. Nếu vẫn sai cùng kiểu, có thể công cụ không hợp với việc đó, đặc biệt ở chất lượng tiếng Việt hoặc đọc loại tệp nhất định.
Có nên đổi công cụ ngay khi thí điểm không tốt không?
Thường là không nên làm đầu tiên. Đổi công cụ tốn thời gian đào tạo lại và làm mất số đo đã có. Kiểm năm loại vướng mắc còn lại trước. Chỉ đổi khi đã chắc lỗi nằm ở năng lực của công cụ trên đúng việc đó.
Lãnh đạo muốn dừng sớm vì thấy không hiệu quả thì làm gì?
Trình bày số đo trong nhật ký, nguyên nhân đã chẩn đoán và kế hoạch gỡ hai tuần. Đề nghị một mốc rõ ràng: nếu sau hai tuần không cải thiện thì dừng. Đa số lãnh đạo đồng ý khi thấy có dữ liệu và có điểm dừng cụ thể.
Một người dùng tốt, số còn lại không dùng thì có tính là thành công?
Chưa. Điều đó cho thấy việc và công cụ có thể hợp, nhưng cách làm chưa chuyển được sang người khác. Hãy nhờ người dùng tốt chia sẻ câu lệnh và cách làm, kèm cặp đồng nghiệp, rồi đo lại. Thành công là khi đa số người tham gia dùng được.
Có nên công bố thí điểm không thành công cho toàn công ty không?
Nên, ngắn gọn và tích cực: việc gì đã thử, vì sao chưa hợp, công ty học được gì, bước tiếp theo là gì. Giấu đi sẽ sinh tin đồn. Công bố minh bạch cho thấy công ty nghiêm túc và an toàn để thử điều mới.