#60 - Bạn có nên để AI làm problem discovery không?

Có một câu hỏi mình đã suy nghĩ khá lâu trong vài tháng gần đây, khi quan sát cách các product team xung quanh mình đang tích hợp AI vào quy trình làm sản phẩm. Câu hỏi đó là:

"Tại sao có những công đoạn AI làm rất tốt, nhanh hơn con người nhiều lần, mà chúng ta vẫn cảm thấy có gì đó lệch khi để AI làm thay, giống như problem discovery?"

Bài viết này mình sẽ cố gắng trả lời câu hỏi trên. Chìa khóa, mình nghĩ, không nằm ở giới hạn kỹ thuật của AI. Nó nằm ở chỗ chúng ta đang nhầm lẫn giữa hai loại công cụ rất khác nhau.

Hai loại interface

Trước khi nói về AI, hãy nói về interface. Không chỉ là những gì hiện ra trên màn hình, mà interface là bất kỳ cơ chế nào giúp con người tương tác với thế giới để đạt được một mục tiêu. Ngôn ngữ là interface để suy nghĩ và giao tiếp. Chữ viết là interface để lưu trữ và truyền đạt tri thức qua thời gian. Hệ thống số cũng là một interface, một cách để chúng ta thao tác với những khái niệm trừu tượng như lượng và phép toán.

Thử đặt mình vào bối cảnh thời La Mã. Nếu bạn là một người làm kế toán thời đó, việc tính toán với I, V, X… không chỉ bất tiện mà còn giới hạn khả năng xử lý những phép tính phức tạp. Những phép cộng nhiều chữ số như 12 + 53 + 63 trở nên cồng kềnh, khó kiểm soát, và dễ sai sót - không phải vì con người thời đó không thông minh bằng, mà vì interface mà họ đang sử dụng không phù hợp với loại vấn đề họ cần giải quyết.

Về chủ đề này, Linus Lee - Head of AI tại Thrive Capital và cựu Research Engineer tại Notion, có một bài viết về chủ đề này mang tên "Instrumental Interfaces, Engaged Interfaces." Trong đó, anh ta phân biệt rõ giữa hai loại interfaces - instrumental interface và engaged interface, dựa trên cách chúng ta sử dụng chúng:

• Instrumental interface phục vụ những người dùng khá là goal-oriented. Người dùng chỉ muốn có một giải pháp đủ tốt cho vấn đề của họ, và không quan tâm đến quá trình. Một bài kiểm tra Linus đề xuất khá hay: nếu bạn có một nút thần kỳ để hoàn thành tác vụ ngay lập tức, bạn có nhấn không? Nếu câu trả lời là có, thì bạn đang nhìn vào một instrumental interface. Grab, app giao đồ ăn, form điền đơn xin việc đều thuộc loại này.
• Engaged interface thì khác. Người dùng muốn được tham gia trực tiếp vào cơ chế của interface. Họ sử dụng nó không phải để check off một thứ phải làm, mà vì có giá trị nội tại trong việc tương tác với chính nó. Một nhạc cụ, một bàn cờ, một bộ flash card đều thuộc loại này. Người chơi nhạc không muốn nghe một bản thu sẵn, họ muốn cảm giác tự mình chơi. Người học bằng flash card không muốn được trao kết luận, họ muốn quá trình tự ghi nhớ.

Đến đây có thể bạn sẽ nghĩ: vậy engaged interface là dành cho những việc mình muốn tận hưởng, còn việc nào mình không thích làm thì cứ xài instrumental interface cũng được. Nếu mình không thích làm discovery, thì cứ để AI làm thôi!

Mình muốn mở rộng ý của Linus thêm một bước nữa, vì cách hiểu trên chưa đầy đủ. Engaged interface không chỉ dành cho những việc mình thấy vui. Nó còn dành cho loại công việc mà giá trị thực sự được tạo ra trong chính quá trình làm, chứ không phải ở output cuối cùng. Một tác vụ có thể không vui nhưng vẫn cần engaged interface, nếu bản chất của nó là việc nhận thức được hình thành dần qua quá trình, không thể nén lại thành kết luận.

Câu hỏi mình muốn đặt ra trong bài này là: problem discovery thuộc loại nào? Nó giống đặt xe (giá trị ở kết quả) hay giống luyện đàn (giá trị ở quá trình)?

Những gì nên để AI làm

Khi bạn cần di chuyển từ điểm A đến điểm B, điều duy nhất bạn quan tâm là đến được nơi cần đến. A và B đã rõ ràng trong đầu bạn, và bạn cũng chẳng mặn mà gì với chuyện một chiếc xe được cấu trúc ra sao ở bên trong. Đây chính là bối cảnh mà một instrumental interface như Grab phát huy giá trị: bạn book xe, tài xế đến điểm A, đưa bạn đến điểm B, và cuộc trao đổi kết thúc ở đó.

AI Agents có thể được xem như một instrumental interface tương đối lý tưởng, bởi vì nó giúp cho bạn đi từ A đến B một cách hiệu quả hơn, với điều kiện bạn miêu tả đủ rõ hai trạng thái và không cần quá chấp niệm về các chi tiết cụ thể trong quá trình di chuyển đó. Nên nếu bạn có một tác vụ mà bạn không quan tâm làm như thế nào, miễn ra được output đúng như bạn định nghĩa, thì đó là use case nên dùng AI.

Ví dụ điển hình là chuyện viết report hàng tuần. Bạn có input rõ ràng là các nguồn thông tin, có output rõ ràng là một văn bản đi theo cấu trúc và tông giọng đã định sẵn, và bạn cũng không mấy bận tâm đến quá trình chuyển từ input sang output diễn ra như thế nào.

Đây là use case mà AI Agents gần như được sinh ra để giải quyết, bởi không mấy ai enjoy chuyện viết report, và bản thân công việc này cũng không phải là thứ giúp bạn làm dày được kỹ năng nội tại qua thời gian. Nếu bạn như mình, bạn sẽ muốn cái report được xong càng nhanh càng tốt, để dành thời gian cho những việc mà quá trình mới là nơi tạo ra giá trị. Sử dụng AI Agents trong để viết report là hoàn toàn hợp lý.

Nhưng product discovery thì nó không vận hành theo logic đó.

Bản chất của vấn đề

Problem discovery không phải đi từ điểm A đến điểm B, nó là quá trình xác định được điểm A và điểm B là gì, cũng như nhìn ra được kết cấu chằng chịt nằm giao thoa giữa hai điểm đó với nhau.

Nếu chúng ta định nghĩa được "vấn đề" là gì, thì câu trả lời tại sao problem discovery lại khó giao cho AI Agent sẽ trở nên rõ ràng hơn. Bản chất của thứ chúng ta gọi là vấn đề có thể được phân rã thành ba cấu thành, mình sẽ miêu tả thông qua ví dụ sau (cũng là một vấn đề mình thường gặp):

• Trạng thái hiện tại (current state). Khi tôi có ba mẹ hoặc người thân lớn tuổi ở xa đang cần di chuyển từ nhà họ đến một địa điểm nào đó, và họ lại nhờ tôi đặt xe công nghệ cho họ, nhưng giờ di chuyển của họ lại vào 3-4 giờ sáng lúc tôi vẫn còn đang ngủ.
• Trạng thái mong muốn (desired state). Đảm bảo rằng người thân của tôi có xe công nghệ đến đón đúng giờ, ở đúng địa chỉ và di chuyển đúng nơi cần đến, mà không cần tôi phải thức dậy lúc 3-4 giờ sáng.
• Khoảng cách giữa hai trạng thái (gap). Hiện tại tôi đang phải lựa chọn giữa việc thức dậy lúc 3-4 giờ sáng để đặt xe, hoặc để lỡ và rủi ro ba mẹ không có xe. Mong muốn là một cơ chế cho phép tôi không cần thức dậy mà vẫn đảm bảo được việc đưa đón.

Không gian vấn đề (problem space) là không gian chứa đựng mọi trạng thái khả dĩ mà bài toán có thể ở trong đó, với current state và desired state chỉ là hai điểm đặc biệt trên không gian này. AI không thể thay thế bạn khai phá được không gian vấn đề với những chi tiết dày đặc thú vị, bởi thứ được model lưu lại chỉ là những pattern phổ thông, trung bình, lightweight của thực tại. Nó không có sự tò mò nguyên bản của con người - thứ cần thiết để nhìn thấy được sự phức tạp của không gian này.

Để trân quý hơn sự phức tạp đó, bạn có thể hình dung rằng mỗi biến số mà giải pháp phải thỏa mãn như là một chiều của không gian vấn đề. Trong ví dụ trên, có thể kể ra các chiều như: độ tin cậy của tài xế, khả năng có backup khi tài xế hủy, độ chính xác của địa chỉ đón và trả, mức độ yên tâm của người đặt xe, chi phí, và còn nhiều chiều khác chưa được phát hiện ra.

Các chiều này không trực quan dễ thấy như thế giới vật lý ba chiều, mà chúng có sự phụ thuộc với nhau theo những cách khóa đoán trước: tăng độ tin cậy có thể đẩy chi phí lên, cải thiện luồng có tài xế backup có thể làm phức tạp hóa UX. Mỗi quyết định ở một chiều đều tạo nên gợn sóng ở các chiều khác.

Chúng ta hình dung về chuyện khai phá không gian vấn đề bằng cách nhắm mắt và dùng hai bàn tay chạm vào một vật thể: bạn cảm nhận đường nét ở chỗ này, chất liệu ở chỗ kia, và dần dần một hình dạng tổng thể hiện ra trong đầu. Khác biệt với vật thể vật lý là không gian vấn đề không có sẵn hình dạng cố định để khám phá. Chính cách bạn chạm, chạm ở đâu, theo thứ tự nào, sẽ tham gia vào việc định hình nó. Cùng một chủ đề có thể được khái niệm hóa thành nhiều không gian vấn đề khác nhau tùy vào framing của người làm sản phẩm.