TRAIDA: chuẩn hoá định nghĩa trước, gọi AI sau

Câu hỏi tôi nhận nhiều nhất trong hai năm gần đây: “AI làm được gì cho doanh nghiệp em?” Câu trả lời thật thà của tôi thường làm người hỏi hơi thất vọng: chưa làm được gì nhiều, cho đến khi anh chị trả lời xong một câu hỏi rẻ hơn nhiều — hai phòng ban trong công ty có đang gọi cùng một thứ bằng cùng một cái tên không.

Điểm nghẽn hiếm khi nằm ở AI

Tôi từng ngồi trong một buổi review nơi phòng marketing báo 1.200 khách hàng tiềm năng trong tháng, phòng sale báo 400. Không ai gian dối. Marketing tính mọi người để lại số điện thoại; sale chỉ tính người đã bắt máy và xác nhận có nhu cầu. Hai định nghĩa khác nhau cho cùng một từ, và mọi con số phía sau — chi phí trên mỗi khách hàng tiềm năng, tỷ lệ chuyển đổi, hiệu quả từng kênh — đều lệch theo.

Nếu lúc đó tôi cắm thêm một lớp AI để tự động tổng hợp báo cáo, tôi chỉ làm một việc: khiến con số sai được tạo ra nhanh hơn và trông đáng tin hơn. Đây là cái bẫy tôi thấy nhiều nhất ở các dự án AI tại SME — dữ liệu rác đi vào thì kết quả rác đi ra, chỉ khác là bây giờ nó ra với tốc độ máy.

AI không sửa được một tổ chức chưa thống nhất được cách gọi tên sự vật. Nó chỉ khuếch đại sự lệch pha đó lên.

TRAIDA là gì, và của ai

Khung tôi dựa vào để làm phần này có tên TRAIDA — Transformative AI and Data Solutions. Cần nói rõ ngay: đây không phải khung do tôi tạo ra. Tác giả là Pierre Bonnet, người sáng lập Engage-Meta, với hơn 30 năm làm Enterprise Architecture và quản trị dữ liệu. Bộ tài liệu được phát hành dưới giấy phép Creative Commons Attribution 4.0 — được dùng, được diễn giải lại, với điều kiện ghi nguồn. Tôi ghi nguồn ở cuối bài này, và tôi cũng nói thẳng phần nào là của khung, phần nào là cách tôi rút gọn cho khách hàng của mình.

Bản gốc của TRAIDA đi theo một trình tự khá dài, dành cho doanh nghiệp lớn: từ điển nghiệp vụ (business glossary) → mô hình dữ liệu khái niệm → mô hình dữ liệu logic và kho dữ liệu vận hành → knowledge graph và ontology → semantic API → knowledge graph toàn doanh nghiệp. Kiến trúc của khung tách rõ hai khối: một khối lo phần ý nghĩa và quản trị tri thức doanh nghiệp, một khối lo phần điều phối suy luận của AI. Nói cách khác, tri thức được mô hình hoá và quản trị riêng, AI chỉ là lớp khai thác đứng trên nó.

Vì sao tôi chọn khung này: nó nói đúng thứ tự

Tôi bị thuyết phục vì bước đầu tiên của nó không phải chọn công cụ, không phải chọn mô hình ngôn ngữ, mà là chuẩn hoá định nghĩa. Đúng thứ tự tôi vẫn giữ trong mọi hợp đồng: hệ thống trước con người, con người trước chiến thuật, chiến thuật trước tiền quảng cáo. Ở lớp công nghệ, câu đó dịch thành: định nghĩa trước dữ liệu, dữ liệu trước AI.

Một điểm tôi cần nói cho công bằng: Engage-Meta công bố việc dùng AI để dựng lớp ngữ nghĩa có thể giảm chi phí và thời gian tới khoảng mười lần. Đó là con số của họ, ở quy mô doanh nghiệp lớn — không phải con số tôi đo được ở khách hàng SME của mình. Tôi dẫn lại để anh chị biết khung này tham vọng tới đâu, chứ không mượn nó làm cam kết của tôi.

Dịch cho SME Việt Nam: bản ba tầng

Một doanh nghiệp 40 người không cần ontology chuẩn RDF-OWL, cũng không cần knowledge graph toàn tập đoàn. Cấy nguyên bản gốc vào đó là cách chắc chắn nhất để dự án chết ở tháng thứ hai — đúng như tôi đã viết trong bài về việc dịch playbook thay vì cấy playbook. Nên tôi rút TRAIDA xuống ba tầng, giữ đúng trình tự, bỏ hết phần hạ tầng chưa tới lượt:

• —Tầng 1 — chuẩn hoá định nghĩa. Một từ điển nghiệp vụ đúng nghĩa: khách hàng tiềm năng là gì, tính từ thời điểm nào, ai được quyền đổi trạng thái. Thường chỉ là một trang tài liệu, nhưng phải được chủ doanh nghiệp và các trưởng phòng ký nhận cùng nhau.
• —Tầng 2 — chuẩn hoá dữ liệu. Trường dữ liệu bắt buộc, nguồn nào là nguồn gốc cho từng chỉ số, ai chịu trách nhiệm nhập, và luồng nào tự động thay cho nhập tay. Đây là tầng tốn công nhất và ít ai muốn làm, vì nó không sinh ra thứ gì để mang đi họp.
• —Tầng 3 — khai thác bằng AI và tự động hoá. Chỉ đến đây tôi mới đưa chatbot, trợ lý nội bộ, luồng tự động rẽ nhánh vào. Vì đến đây, thứ AI đọc đã là dữ liệu có nghĩa và có chủ.

Tại Onschool, phần việc nặng nhất không phải cài công cụ mà là chuẩn hoá lại cách Marketing, Tech và Sale bàn giao thông tin cho nhau — sau khi thống nhất được cách gọi và cách đo, tự động hoá mới có chỗ để bám, và năng suất thực thi của toàn đội tăng gấp đôi. Ở một danh mục hơn 6.000 SKU đa thương hiệu, cũng cùng một logic: chatbot chăm sóc khách hàng chỉ trả lời đúng khi cấu trúc dữ liệu sản phẩm được dọn trước, chứ không phải khi mô hình được chọn giỏi hơn.

Phép thử trước khi tiêu đồng nào cho AI

Bốn câu hỏi này rẻ, mất khoảng một buổi để trả lời, và tiết kiệm được nhiều tháng làm sai:

• —Hai phòng ban báo cùng một chỉ số cho ra hai con số khác nhau không? Nếu có, dừng lại ở tầng 1.
• —Mỗi chỉ số quan trọng có đúng một nguồn được coi là nguồn gốc, hay đang có ba bản Excel song song?
• —Nếu người đang giữ file báo cáo nghỉ một tháng, ai dựng lại được? Câu này đo mức độ phụ thuộc trí nhớ cá nhân.
• —Việc mình muốn AI làm, hiện có ai đang làm thủ công và làm đúng không? AI khuếch đại một quy trình đã chạy được, chứ không phát minh ra quy trình chưa từng có.

Nếu ba trong bốn câu trả lời khiến anh chị thấy khó chịu, thì tin tốt là anh chị chưa cần mua gì cả. Việc cần làm nằm ở tầng 1 và tầng 2, và nó rẻ hơn nhiều so với một dự án AI phải làm lại từ đầu.