PoC AI: chốt tiêu chí trước khi xem bản demo

Một bản demo AI tạo báo cáo đúng mẫu khiến cuộc họp triển khai thuận lợi. Nhưng khi đổi bộ hồ sơ, kết quả thiếu một ngoại lệ quan trọng. Nếu mục tiêu ban đầu chỉ là xem AI có làm được báo cáo hay không, nhóm dự án khó thống nhất thử nghiệm đã thành công chưa. PoC AI cần một giả định và tiêu chí kiểm chứng rõ trước khi xem đầu ra.

PoC, viết đầy đủ là proof of concept, dùng để kiểm tra khả năng thực hiện một ý tưởng trong phạm vi giới hạn. Với AI dựa trên tài liệu, câu hỏi có thể là liệu hệ thống có tạo được bản nháp đủ căn cứ từ một nhóm hồ sơ đã xác nhận. Kết quả cần giúp tổ chức quyết định bước tiếp theo, kể cả quyết định dừng.

PoC AI phải trả lời một câu hỏi có thể kiểm tra

Một mục tiêu như tăng hiệu quả vận hành quá rộng để nghiệm thu. Nhóm nghiệp vụ cần chuyển nó thành đầu việc cụ thể, người sử dụng và điều kiện chấp nhận. Chẳng hạn, chuẩn bị bản nháp tổng hợp từ hồ sơ đã chốt, có chỉ ra phần thiếu nguồn và giữ người phụ trách xác nhận. Phạm vi này có thể được thử bằng các bộ tài liệu tương ứng.

Giả định cần chỉ rõ điều chưa biết. Có thể tổ chức chưa biết tài liệu scan có đủ chất lượng để khai thác, hoặc chưa biết hệ thống có xử lý đúng điều kiện áp dụng trong nhiều văn bản. Nếu thử nhiều việc cùng lúc, một đầu ra tốt sẽ khó cho biết giả định nào đã được kiểm chứng. Nên tách những câu hỏi quyết định.

Hướng dẫn AWS về thiết kế generative AI PoC yêu cầu chuyển mục tiêu kinh doanh thành tiêu chí thành công cụ thể, có thể đo. Bài viết này áp dụng nguyên tắc đó vào thử nghiệm công việc tài liệu. Đây là hướng dẫn thiết kế, không phải cam kết về hiệu quả hay thời gian triển khai.

Phân biệt trình diễn, thử nghiệm và vận hành

Bản trình diễn giúp người xem hiểu một cách làm. Nó có thể sử dụng tài liệu đã được chuẩn bị và câu hỏi đã biết trước. PoC cần thêm phép thử để xác nhận giả định. Người nghiệm thu phải biết hồ sơ nào đã dùng khi cấu hình và hồ sơ nào được giữ lại để đánh giá, tránh chỉ kiểm lại trường hợp quen thuộc.

Pilot đưa quy trình vào một phạm vi sử dụng có kiểm soát. Khi đó, ngoài chất lượng đầu ra còn có việc tiếp nhận yêu cầu, xử lý ngoại lệ và hỗ trợ người dùng. Vận hành chính thức cần thêm trách nhiệm theo dõi, thay đổi nguồn, quản lý quyền và xử lý sự cố. Tổ chức nên xác định đầu ra của từng giai đoạn trong phạm vi dự án.

Một PoC tốt chưa tự chứng minh hệ thống sẵn sàng phục vụ mọi phòng ban. Kết quả có thể cho thấy một loại hồ sơ phù hợp, trong khi loại khác chưa đủ dữ liệu. Quyết định mở rộng phải dựa trên điều kiện đã kiểm chứng. Những kết luận vượt phạm vi cần được ghi thành câu hỏi cho giai đoạn tiếp theo.

Chọn bộ hồ sơ có cả trường hợp khó

Bộ thử cần đại diện cho công việc dự định hỗ trợ. Với tài liệu, có thể gồm hồ sơ đủ căn cứ, hồ sơ thiếu phần quan trọng, hồ sơ có hai phiên bản và hồ sơ có ngoại lệ. Chủ quy trình xác định kết quả mong đợi từ từng trường hợp. Không nên chọn toàn hồ sơ sạch nếu thực tế đầu vào thường cần kiểm tra.

Các nguồn dùng cho nghiệm thu cần có trạng thái rõ. Một file chưa xác nhận nội dung không phù hợp làm đáp án chuẩn. Nếu chuyên viên không thống nhất được kết luận, phải giải quyết phần nghiệp vụ trước. AI không thể thay tổ chức quyết định nguồn nào được phép dùng làm căn cứ chính thức.

Khi sử dụng hồ sơ thật, cần hạn chế dữ liệu cá nhân và thông tin không cần thiết cho câu hỏi thử nghiệm. Nếu dùng dữ liệu giả định, phải ghi rõ và giải thích nó đại diện cho điều kiện nào. Dữ liệu giả định phù hợp kiểm logic nhưng chưa đủ để kết luận hệ thống hoạt động tốt với mọi định dạng thực tế.

Tiêu chí cần có điều kiện đạt và điều kiện dừng

Tiêu chí đầu ra nên gắn với yêu cầu công việc. Một bản nháp cần đủ các mục bắt buộc, dẫn đúng nguồn và nhận diện chỗ chưa có căn cứ. Người nghiệm thu cần biết lỗi nào có thể sửa trong bước biên tập, lỗi nào khiến kết quả không được sử dụng. Phân loại trước sẽ giảm tranh luận sau khi xem demo.

Điều kiện dừng có thể là dùng tài liệu ngoài quyền, trích dẫn không tồn tại hoặc tự kết luận khi thiếu nguồn quyết định. Ngưỡng và cách xử lý do tổ chức thống nhất theo hậu quả. Không nên lấy một điểm tổng hợp cao để bỏ qua lỗi nghiêm trọng ở một hồ sơ, nhất là khi đầu ra sẽ được dùng cho quyết định nghiệp vụ.

Cần ghi cả công sức kiểm tra. Một bản nháp đủ nội dung nhưng người duyệt phải dựng lại toàn bộ hồ sơ chưa đạt mục tiêu hỗ trợ đã đặt ra. Tổ chức có thể theo dõi những bước người dùng phải làm trước và sau khi dùng AI. Khi chưa có dữ liệu đo, chỉ nêu mục tiêu thử, không công bố tỷ lệ tiết kiệm.

Thống nhất trách nhiệm giữa nghiệp vụ và kỹ thuật

Người bảo trợ dự án chốt câu hỏi cần kiểm chứng và quyết định bước tiếp theo. Chủ quy trình xác nhận tài liệu, tiêu chí và kết luận mong đợi. Nhóm kỹ thuật mô tả cấu hình, phạm vi xử lý và giới hạn. Người sử dụng thực hiện đầu việc theo tình huống thử đã thống nhất.

Nếu nhóm kỹ thuật tự chọn hồ sơ và tự chấm kết quả, đơn vị mua khó biết đầu ra có phù hợp nghiệp vụ. Nếu nhóm nghiệp vụ chỉ xem câu trả lời cuối mà không cung cấp tiêu chí, việc đánh giá dễ phụ thuộc cảm nhận. Sự phối hợp cần được thể hiện bằng tài liệu thử nghiệm ngắn, có thể đọc và kiểm lại.

Tài liệu này nên ghi mục tiêu, nguồn, vai trò, các trường hợp thử và cách ghi lỗi. Thay đổi trong quá trình thử phải được lưu để người nghiệm thu hiểu kết quả thuộc cấu hình nào. Không mặc định nền tảng tự có mọi chức năng lưu dấu cần thiết; có thể dùng phương pháp quản lý phiên bản hiện hành của đơn vị.

Đọc kết quả để chọn bước tiếp theo

Kết quả phù hợp có thể dẫn đến một pilot có phạm vi rõ. Tuy vậy, cần nêu điều kiện đi kèm: nhóm tài liệu được chuẩn hóa, người duyệt có chuyên môn hoặc một kết nối chưa được mở. Những điều kiện này phải xuất hiện trong đề xuất giai đoạn sau. Nếu bỏ chúng, tổ chức có thể mở rộng sang công việc chưa được kiểm chứng.

Kết quả chưa đạt cần được phân loại nguyên nhân. Nguồn thiếu khác với hệ thống đọc sai; người dùng đặt yêu cầu chưa đủ khác với lỗi quyền. Với từng loại, xác định ai có thể xử lý và liệu có đáng thử lại. Không nên tăng phạm vi chỉ để tìm một trường hợp dễ đạt hơn rồi kết luận thử nghiệm thành công.

Dừng cũng là một quyết định có giá trị nếu giả định không phù hợp hoặc công sức chuẩn bị lớn hơn khả năng đáp ứng hiện tại. Tổ chức vẫn cần nhận được những gì đã kiểm chứng, lỗi còn tồn tại và điều kiện để xem xét lại. Giữ quy trình đang vận hành giúp công việc tiếp tục trong thời gian hoàn thiện nguồn hoặc thiết kế.

Lạc Hồng Tech tham gia từ khâu xác định bài toán

Lạc Hồng Tech tư vấn ứng dụng AI theo công việc của doanh nghiệp, gắn với năng lực nền tảng AI native và kho tri thức tổ chức. Bước trao đổi ban đầu nên làm rõ nguồn tài liệu, người sử dụng, đầu ra và trách nhiệm duyệt. Phạm vi PoC cần được hai bên xác nhận theo yêu cầu, không mặc định có một gói cố định phù hợp mọi đơn vị.

Những năng lực có căn cứ như truy vấn tài liệu, phản hồi có trích nguồn và báo cáo theo sườn có thể dùng làm nền cho một phép thử. Các yêu cầu tích hợp, thực hiện hành động hoặc xử lý tài liệu đặc thù cần khảo sát riêng. Đặt tiêu chí trước giúp phân biệt khả năng đang có với phần cần phát triển hay kiểm chứng thêm.

Doanh nghiệp có thể chuẩn bị một đầu việc, một nhóm hồ sơ và tiêu chuẩn kết quả đang dùng để trao đổi với Lạc Hồng Tech. Từ đó, các bên xác định giả định cần thử và điều kiện để mở rộng. Một kết luận rõ về phạm vi sẽ hữu ích hơn một buổi trình diễn không có tiêu chí đánh giá.

Đọc thêm: AI native là gì và quản lý chi phí AI.

Câu hỏi thường gặp

PoC AI đạt có đồng nghĩa triển khai ngay?

Chưa đủ. Cần xem điều kiện thử có đại diện cho phạm vi sử dụng và các yêu cầu vận hành đã được đáp ứng hay chưa.

Có phải mọi PoC đều cần cùng bộ chỉ số?

Không. Chỉ số và lỗi cần dừng phải gắn với đầu việc, dữ liệu và hậu quả của từng ứng dụng.

Hồ sơ thiếu nguồn có nên loại khỏi bộ thử?

Nên giữ các trường hợp thiếu nguồn có chủ đích để kiểm tra khả năng nhận diện giới hạn. Chúng cần có kết quả mong đợi rõ và không được dùng để ép hệ thống suy đoán.