- Barron Webster, người có hơn 8 năm kinh nghiệm thiết kế sản phẩm AI, hiện đảm nhiệm vai trò “model designer” đầu tiên trên thế giới tại Figma, cho thấy sự xuất hiện của một vị trí lai mới nơi nhà thiết kế cộng tác trực tiếp với LLM
- Nhiệm vụ cốt lõi của model designer là bù đắp những giới hạn của foundation model và đưa các công cụ cũng như tư duy mới vào tổ chức thiết kế để xây dựng tính năng AI
- Khác với thiết kế UI truyền thống, thiết kế sản phẩm AI cần prototype hành vi của mô hình trước, rồi mới thiết kế UI; nếu không sẽ có nguy cơ tạo ra UI không khớp với cách hệ thống thực sự vận hành
- Xây dựng hệ thống đánh giá (Evals) là trọng tâm của kiểm soát chất lượng sản phẩm AI, và cần có công cụ để nhà thiết kế có thể thao tác và chạy các case đánh giá trong vòng lặp phản hồi nhanh
- Trong kỷ nguyên AI, nhà thiết kế phải hiểu sâu cấu trúc đầu vào/đầu ra của mô hình và có năng lực nắm bắt toàn bộ hệ thống, thay vì chỉ là người làm UI, họ cần trở thành người tham gia vào quá trình ra quyết định
Giới thiệu về Barron Webster
- Là một nhà thiết kế đã tham gia sâu vào sản phẩm AI hơn 8 năm, có góc nhìn sắc bén xuyên qua các chu kỳ cường điệu
- Từng tham gia thiết kế Teachable Machine ra mắt năm 2017 tại Google Creative Lab, một trong những công cụ đầu tiên cho phép người dùng phổ thông huấn luyện mô hình AI
- Sau đó làm việc với các tính năng AI tại Replit, góp phần vào quá trình startup này phát triển thành kỳ lân
- Gần đây gia nhập Figma với vai trò model designer đầu tiên trên thế giới
Vai trò của model designer
- Thuộc nhóm nghiên cứu AI của Figma và thực hiện hai nhiệm vụ chính
- Giải quyết những trường hợp mà ngay cả khi đã khai thác tối đa hiệu năng từ foundation model thì vẫn chưa đủ
- Vì dữ liệu của Figma ở định dạng độc quyền nên foundation model xử lý chưa tốt, và công việc là lấp khoảng trống đó
- Đưa công cụ mới và tư duy AI-first vào tổ chức thiết kế
- Figma là công ty lớn nên nhiều nhà thiết kế chưa có kinh nghiệm thiết kế trải nghiệm AI
- Thiết kế tính năng AI khác với thiết kế sản phẩm truyền thống
- Mục tiêu là xây dựng công cụ để nhà thiết kế có thể prototype phần cốt lõi của tính năng AI từ sớm trong quy trình mà không cần trở thành kỹ sư
- Nếu thiết kế UI cho một tính năng chưa từng tự mình trải nghiệm, sẽ có nguy cơ tạo ra giao diện chỉ phù hợp với trường hợp lý tưởng mà không phản ánh cách hệ thống thực sự hoạt động
Tương lai của công cụ thiết kế AI
- Công cụ được kỳ vọng nhất là thứ cho phép nhà thiết kế thao tác và chạy các case đánh giá trong vòng lặp phản hồi nhanh
- Nếu tính năng AI không hoạt động trên một file Figma, cần có khả năng thêm ngay trường hợp đó vào test case
- Phải có thể điều chỉnh system prompt hoặc thử mô hình khác ngay lập tức
- Vấn đề hiện tại là vòng lặp phản hồi quá chậm
- Cốt lõi của mọi công cụ thiết kế tốt là loại bỏ hoặc rút ngắn vòng lặp phản hồi
- Phần lớn công việc xây dựng tập đánh giá hiện vẫn là dọn dẹp dữ liệu thủ công
- Figma cũng đang suy nghĩ về cách tạo khác biệt cho tính năng AI của mình
- Vì là nền tảng thiết kế nên đầu ra được kỳ vọng sẽ được thiết kế tốt hơn so với Claude Code hay Cursor
- Mấu chốt là chiến lược đánh giá có mục tiêu và tìm ra proxy cho thiết kế tốt
- Đây cũng là một câu hỏi mang tính triết học ở cấp độ trường mỹ thuật
Trải nghiệm bước vào AI của Barron
- Lớp RISD Computer Utopias giai đoạn 2014-2015: thời kỳ trước LLM, khi nghiên cứu machine learning chủ yếu xoay quanh bộ phân loại
- Các mô hình phân loại hình ảnh là thứ thú vị nhất, được dùng cho filter khuôn mặt của Snapchat hay tìm kiếm hình ảnh của Google
- Content moderation và hệ thống gợi ý là các chủ đề lớn
- Đây là thời kỳ đỉnh cao của Facebook, Twitter, Cambridge Analytica, khi sự ra đời của feed thuật toán tạo ra chất liệu thiết kế mới
- Google Creative Lab giai đoạn 2016-2018: làm việc với Google Lens, Google Assistant, Teachable Machine
- Gần như mọi dự án đều áp dụng đổi mới về mô hình
- Mô hình được dùng để sắp xếp hoặc gắn chú thích cho nội dung có sẵn chứ chưa phải tạo văn bản
- Từng thực hiện chiến dịch quảng bá câu chuyện một nông dân trồng dưa chuột ở Nhật phân loại dưa chuột bằng TensorFlow
Kinh nghiệm tại Replit
- Làm việc hơn 3 năm, bắt đầu từ lúc gần như chưa có tính năng AI nào và đảm nhiệm vai trò đánh giá cách ứng dụng AI
- Khi mô hình liên tục cải thiện, ông tìm cách bổ sung các tính năng AI vừa tận dụng năng lực mới vừa đủ đáng tin cậy
- Bắt đầu với các tính năng kích hoạt thủ công cơ bản như chọn đoạn code để AI giải thích, hoặc tạo code trong file hiện có
- Sau mỗi lần ra mắt tính năng, kỳ vọng của người dùng lại tăng lên theo chu kỳ
- Cho phép tạo code snippet → người dùng muốn cả file hoặc cả project
- Tạo được toàn bộ → người dùng muốn chỉnh sửa cụ thể
- Chỉnh sửa cụ thể được → người dùng muốn bắt đầu lại từ đầu
- Có một mô thức lặp lại: thử làm tính năng với mô hình hiện có → không được thì chờ → foundation model mới ra thì thử lại
- Các ràng buộc của sản phẩm trong môi trường lập trình
- Dù mô hình giỏi viết code, vẫn cần biết cách chỉnh sửa đúng vị trí
- Trước Sonnet 3.5, mô hình xử lý số dòng còn yếu
- Cần phát triển các giải pháp tạm thời cho độ chính xác chỉnh sửa, tránh trùng lặp nội dung và thay thế hàm
- Phần lớn những việc này trở nên vô dụng sau 6 tháng đến 1 năm khi có mô hình mới
Trường hợp chuyển sang xác minh bởi người dùng
- Khi Replit Agent tự động tạo file và viết code, việc kiểm tra ứng dụng do agent tạo ra có hoạt động hay không là một vấn đề kỹ thuật lớn
- Ví dụ: xác minh trang đăng nhập có hoạt động đúng không
- Cách tiếp cận từ phía kỹ thuật: chạy sandbox, xây tính năng chụp màn hình, đưa ảnh chụp cho mô hình multimodal để quyết định vị trí click/nhập
- Về bản chất là triển khai một dạng mô phỏng việc dùng máy tính của mô hình
- Đề xuất của Barron và một kỹ sư khác: cho người dùng xem website và yêu cầu họ tự kiểm tra
- Bằng cách chuyển phần xác minh và kiểm thử cho người dùng, họ đã né được cả một bài toán kỹ thuật phức tạp
- Khi có người tập trung vào vấn đề của người dùng thay vì chỉ nhìn như một bài toán kỹ thuật, rất nhiều thứ có thể được bỏ qua hoặc đơn giản hóa
Tìm kiếm product-market fit
- Trong chiến lược sản phẩm truyền thống thời kỳ trước AI: lập kế hoạch, dựa trên tệp người dùng hiện có, rồi xây chiến lược mở rộng thị trường hoặc danh mục
- Nhưng vì AI thay đổi quá nhanh nên chiến lược của Replit mang tính phản ứng nhiều hơn
- Công ty có product-market fit mạnh trong thị trường giáo dục, đặc biệt sau giai đoạn học từ xa thời COVID
- Việc cải thiện tính năng AI tạo ra một thế lưỡng nan
- Nhà phát triển độc lập và hacker rất thích AI
- Giáo viên thì phản đối vì học sinh có thể bỏ qua quá trình học nền tảng
- Khi ra mắt Replit Agent, chưa rõ người dùng mục tiêu là ai
- So với cách tiếp cận top-down, ra tính năng rồi quan sát phản ứng lại hiệu quả hơn
- Qua các cuộc trò chuyện sau khi ra mắt, họ phát hiện người dùng là những người phụ trách vận hành tại các công ty công nghệ, cần thu thập dữ liệu bán hàng hoặc xây dashboard, tương tự nhóm dùng Zapier hay Retool
Hệ thống đánh giá (Evals)
- Trong 2 năm đầu ở Replit, nhóm không làm nhiều về đánh giá vì khi đó đây chưa phải thực hành phổ biến
- Với Agent, đánh giá được dùng tích cực hơn, chủ yếu như chỉ số phát triển sản phẩm
- Khi mô hình mới ra mắt, họ nhìn vào hiệu năng trên các bài đánh giá lập trình để quyết định có nên thử kiểm thử ứng dụng hay không
- Ở Sandbar, ông dành nhiều thời gian để viết các bài đánh giá về cá tính của mô hình
- Ngoài benchmark diện rộng của ngành, việc xây bộ đánh giá đặc thù cho sản phẩm là một công việc thiết kế mới
- Quy trình làm việc: viết prompt → chỉnh prompt → tạo đánh giá → kiểm tra hiệu năng → kết hợp với test thủ công và phản hồi chủ quan
- Nếu không có đánh giá thì khối lượng kiểm thử thủ công để xác minh AI hoạt động đúng sẽ tăng mạnh
- Ví dụ đánh giá ở Sandbar
- Khi không biết câu trả lời, mô hình nên đặt một câu hỏi làm rõ duy nhất và cụ thể thay vì hallucinate
- Không được hỏi quá hai câu cùng lúc
- Câu trả lời phải giữ ngắn gọn, trừ các ngoại lệ
Khó khăn của đánh giá
- Sự nịnh nọt (Sycophancy) là một trong những chủ đề khó nhất khi viết đánh giá
- Tức là mô hình cần phải phản biện người dùng trong những trường hợp thích hợp
- Việc quyết định tỷ lệ thất bại chấp nhận được trở thành một quyết định về sản phẩm và thiết kế, đồng thời là một phần trong triết lý thiết kế của sản phẩm
- Kết quả đánh giá thấp nhiều khi không đến từ suy giảm hiệu năng, mà do bài đánh giá được viết sai
- Ví dụ: trong một bài đánh giá yêu cầu “phải rất ngắn gọn”, nếu người dùng nói “mẹ tôi qua đời rồi” thì câu “thật đáng tiếc” có thể được điểm cao nhưng đó không phải phản hồi thực sự mong muốn
- Đánh giá chủ yếu được dùng để ngăn hồi quy, tức kiểm tra xem tính chất mong muốn còn được giữ không
- Tương tự test coverage trong lập trình
- Một thứ như test-driven development (TDD) trong lập trình truyền thống vẫn còn hiếm trong AI engineering
- Tức là viết đánh giá trước, rồi viết code để vượt qua đánh giá
- Có thể sẽ xuất hiện nghề evaluation designer trong tương lai
- Vai trò này giống như hệ thống thiết kế cho dashboard giúp cả team hiểu hiệu năng AI
Hình dung tính năng AI tại Figma
- Đang cân nhắc ý tưởng “phê bình thiết kế như một dịch vụ”
- Yêu cầu AI đưa ra nhận xét phê bình thiết kế
- Điều này đặt ra những câu hỏi thú vị về tính cách của hệ thống
- Có nên cho người dùng chọn thái độ, ví dụ phong cách “Dieter Rams”, hay đặt mặc định
- Có nên tập trung vào vấn đề accessibility hoặc độ tương phản, tức các phản hồi mang tính khách quan hơn, hay nhắm đến phạm vi rộng hơn
- Hiện chưa rõ ý tưởng này sẽ được phản ánh đến đâu trong trải nghiệm sản phẩm thực tế
Hướng phát triển của công cụ đánh giá
- Mong muốn có công cụ giúp giảm thời gian lặp để tạo đánh giá
- Hiện tại, mọi người làm công việc đánh giá đều gần như phải tự làm các phần cơ bản
- Kết nối mapping, format, pipeline và giao diện để xem đầu ra ở một nơi
- Công cụ cho văn bản đã khá tốt nhưng với các định dạng khác thì còn thiếu
- Có những nền tảng đánh giá tương tự như Design Arena
- Cho người dùng bỏ phiếu cho đầu ra tốt nhất trong các bài test mù đặt cạnh nhau
- Ông muốn có thể làm việc tương tự trực tiếp trên file Figma
- Bao gồm việc để lại comment và chỉ ra vấn đề
- Cần có khả năng nhanh chóng tạo bộ test, chạy một lượt, nhận 100 phản hồi và lặp lại trong 30 giây
- Hiện mọi mảnh ghép đều đã tồn tại nhưng mất quá nhiều thời gian để vận hành
Vai trò của nhà thiết kế trong quá trình tạo mô hình
- Đã trải nghiệm cả hai cách: huấn luyện từ đầu và fine-tuning
- Khi huấn luyện từ đầu: đóng góp lớn nhất của nhà thiết kế là chỉ ra cho tổ chức nơi nhu cầu người dùng lớn nhất và nỗi đau rõ nhất
- Ở Replit, nhóm từng huấn luyện một mô hình tùy biến cho các lỗi code Python đơn giản và phổ biến
- Ông tham gia vào việc xác định bài toán và tìm cách đưa mô hình đã huấn luyện vào sản phẩm nhiều hơn là vào quá trình huấn luyện thực tế
- Khi fine-tuning: đã có mô hình, sản phẩm và hệ thống đánh giá, mục tiêu là cải thiện hiệu năng
- Người viết prompt, viết đánh giá và nói chuyện với người dùng thường hiểu rõ nhất liệu kỳ vọng có được đáp ứng hay không
- Khi prompt engineering chạm giới hạn thì fine-tuning là bước tiếp theo
- Vai trò “phiên dịch” cốt lõi của nhà thiết kế là ghi nhớ các giả định của người dùng
- Kỹ sư hoặc nhà thiết kế làm việc sát với mô hình có thể quên rằng người dùng không biết các chi tiết đó
- Cần dùng “gã ngốc nội tâm” của mình để truyền đạt người dùng ngây thơ không biết đặc tính của mô hình sẽ thử gì và sẽ mắc kẹt ở đâu
Lời khuyên cho nhà thiết kế sản phẩm AI
- Điều bền vững và có tác động nhất là đầu tư đáng kể thời gian từ sớm để thực sự hiểu đầu vào và đầu ra của mô hình
- Prompt là gì, thông tin người dùng nào được đưa vào, công cụ nào có thể được gọi, có những đánh giá nào
- Cần hình thành trực giác về điều gì xảy ra khi điều chỉnh các núm điều khiển này
- Không nên trở thành người chỉ làm UI cho một đầu ra mà mình không hiểu sâu
- Nếu chỉ nhận đầu ra mô hình rồi “hãy thiết kế giao diện cho cái này”, bạn vẫn làm được nhưng sẽ không thể đề xuất cải tiến dựa trên insight người dùng
- Bạn cũng sẽ luôn làm việc trong trạng thái phản ứng với các thay đổi tiếp theo của mô hình
- Nhà thiết kế cần là một phần của quá trình ra quyết định về việc tính năng mới có thực sự đáng mong muốn hay không, chứ không chỉ là người tiếp nhận
- Điều này có thể khó với nhà thiết kế không quen code
- Cần có giao diện như Langsmith hoặc học cách tự chạy môi trường phát triển
Những trường hợp tạo ảnh hưởng lớn nhất
- Replit Agent: ông đã thuyết phục team yêu cầu người dùng trực tiếp xác minh ứng dụng được tạo ra có hoạt động không
- Bằng cách tập trung vào con đường đơn giản nhất của xác minh bởi người dùng, nhóm đã tiết kiệm được rất nhiều công sức
- LaMDA ra mắt (LLM đời đầu của Google): ông đã dành nhiều thời gian thử các biến thể khác nhau của mô hình để xem cái gì hoạt động tốt nhất
- Khi đó chưa gọi là “prompting”, nhưng vẫn là thử khiến mô hình đóng vai thứ gì đó và làm việc đó một cách đáng tin cậy
- Demo cho phép trò chuyện với Sao Diêm Vương hoặc các mặt trăng của nó là kết quả của vô số lần thử để tìm ra phương án hoạt động tốt nhất
- Nếu không có thử nghiệm trên diện rộng thì không thể lựa chọn chiến lược một cách có cơ sở
Prompting của nhà thiết kế
- Câu hỏi “nhà thiết kế có nên prompt không” khác bản chất với “nhà thiết kế có nên code không”
- Với coding, câu trả lời khá dễ phản chứng: có thể xây XYZ bằng kỹ thuật ABC hay không? Hỏi kỹ sư gần như tương đương với việc tự biết trực tiếp
- Nhưng hành vi của mô hình AI về bản chất mang tính chủ quan và tinh tế hơn nhiều
- Không có gì thay thế được việc tự hiểu sâu trực tiếp chất liệu đó
Đây vẫn là thiết kế chứ?
- Đây là thiết kế hành vi, và nó có thể không bao giờ hoàn hảo — điều đó không sao cả
- Nó đòi hỏi tư duy khác với thiết kế UI, nơi từng pixel đều được kiểm soát chặt và sự hoàn hảo được tưởng thưởng
- Công việc vẫn bao gồm làm mockup và dùng công cụ thiết kế
- Vẫn tạo case đánh giá trong Figma, xem lại đầu ra và chỉnh những phần gượng gạo
- Nó gần như mang tính trị liệu, giống một fidget spinner
- Chỉ cần đưa một mockup website và 30 phút là có thể vui vẻ chỉnh typography
- Đây là kiểu công việc không bao giờ thực sự kết thúc trừ khi tính năng bị loại bỏ, vì lúc nào cũng có thể tiếp tục cải thiện
Chưa có bình luận nào.