Why most AI products fail: Lessons from 50+ AI deployments at OpenAI, Google & Amazon

• Phát triển sản phẩm AI khác biệt đáng kể so với phần mềm truyền thống do tính không xác định của tương tác người dùng và phản hồi của LLM, cùng với sự đánh đổi giữa quyền tự chủ của AI và kiểm soát của con người.
• Chiến lược phát triển hiệu quả là bắt đầu nhỏ, tập trung vào vấn đề cần giải quyết, và tăng dần quyền tự chủ của AI sau khi đã xây dựng được sự tin cậy thông qua các vòng lặp phản hồi.
• Quá trình này đòi hỏi sự cộng tác chặt chẽ giữa các vai trò truyền thống và một tư duy lãnh đạo cởi mở, sẵn sàng học hỏi liên tục trong một lĩnh vực đang phát triển nhanh chóng.

• Thiết kế cho tính không xác định: Chấp nhận và thiết kế các sản phẩm AI với nhận thức rằng cả đầu vào của người dùng (qua ngôn ngữ tự nhiên) và đầu ra của LLM đều là xác suất và không thể dự đoán chính xác như phần mềm truyền thống.
• Quản lý sự đánh đổi quyền tự chủ - kiểm soát: Bắt đầu phát triển với quyền tự chủ của AI ở mức thấp và kiểm soát của con người ở mức cao, dần dần tăng quyền tự chủ khi hệ thống AI chứng minh được độ tin cậy và "giành được lòng tin."
• Tiếp cận phát triển tăng cường: Xây dựng sản phẩm AI từng bước, bắt đầu với các giải pháp có tác động tối thiểu và dần dần thêm ngữ cảnh hoặc công cụ để cải thiện trải nghiệm, thay vì cố gắng tạo ra các tác nhân hoàn chỉnh ngay từ đầu.
• Tái cấu trúc quy trình và trải nghiệm người dùng: Các công ty thành công đang "giải cấu trúc" và "tái cấu trúc" quy trình làm việc và trải nghiệm người dùng cốt lõi để tích hợp AI một cách hiệu quả, thay vì chỉ thêm AI vào các quy trình hiện có.
• Cộng tác liên chức năng chặt chẽ: Các chu trình sống của AI yêu cầu sự hợp tác sâu rộng hơn giữa các vai trò như Quản lý Sản phẩm, Kỹ sư và Nhân sự dữ liệu, cùng sở hữu vòng lặp phản hồi và thường xuyên xem xét "agent traces" cùng nhau.
• Xây dựng vòng lặp phản hồi của con người: Trong giai đoạn đầu, sử dụng con người để đánh giá các gợi ý của AI (ví dụ: trong hỗ trợ khách hàng) để thu thập phản hồi, hiểu rõ khả năng và hạn chế của AI, từ đó cải thiện hệ thống.
• Tư duy lãnh đạo thích nghi: Các lãnh đạo cần thoải mái với sự không chắc chắn, sẵn sàng học hỏi từ mọi người và chấp nhận rằng những trực giác ban đầu của họ có thể không đúng.

• sản phẩm AI — AI product
• tính không xác định — Non-determinism / Uncertainty
• mô hình ngôn ngữ lớn (LLM) — Large Language Model (LLM)
• quyền tự chủ và kiểm soát — Agency and control (trade-off)
• hệ thống tác nhân / Tác nhân AI — Agent system / AI Agent
• trí tuệ nhân tạo (AI) — Artificial Intelligence (AI)
• học máy (ML) — Machine Learning (ML)
• giao diện lập trình ứng dụng (API) — Application Programming Interface (API)
• vòng lặp phản hồi — Feedback loop
• quy trình làm việc — Workflow

Sự Khác Biệt Giữa Phát Triển Sản phẩm AI và Phần mềm Truyền thống

Chúng tôi đã cùng nhau thực hiện một bài đăng khách và có một nhận định quan trọng rằng việc xây dựng các sản phẩm AI rất khác so với việc xây dựng các sản phẩm không phải AI. Hầu hết mọi người có xu hướng bỏ qua tính không xác định. Bạn không biết người dùng có thể tương tác với sản phẩm của bạn như thế nào và bạn cũng không biết mô hình ngôn ngữ lớn (LLM) có thể phản hồi ra sao. Khác biệt thứ hai là sự đánh đổi giữa quyền tự chủ và kiểm soát (agency control trade-off). Mỗi khi bạn trao quyền ra quyết định cho các hệ thống tác nhân, bạn đang từ bỏ một mức độ kiểm soát nhất định từ phía mình.

Điều này làm thay đổi đáng kể cách bạn nên xây dựng sản phẩm. Vì vậy, chúng tôi khuyên bạn nên xây dựng từng bước. Khi bạn bắt đầu nhỏ, nó buộc bạn phải suy nghĩ về vấn đề mà bạn sẽ giải quyết là gì. Trong tất cả những tiến bộ của trí tuệ nhân tạo (AI) này, một điều dễ sa vào là cứ mãi suy nghĩ về sự phức tạp của giải pháp mà quên đi vấn đề bạn đang cố gắng giải quyết. Không phải là việc trở thành công ty đầu tiên có một tác nhân trong số các đối thủ cạnh tranh của bạn. Vấn đề là bạn đã xây dựng đúng các flywheel để có thể cải thiện theo thời gian hay chưa.

Tư duy và Phương pháp Tiếp cận

Bạn thấy những phương thức làm việc nào trong các công ty xây dựng sản phẩm AI thành công? Tôi từng làm việc với Giám đốc điều hành (CEO) của Rackspace hiện nay. Ông ấy có một khoảng thời gian cố định mỗi sáng, ghi "theo dõi trí tuệ nhân tạo (AI) từ 4 đến 6 giờ sáng". Các Lãnh đạo phải quay trở lại làm việc trực tiếp. Bạn phải thoải mái với việc những trực giác của mình có thể không đúng và bạn có thể là người "ngu ngốc nhất" trong phòng, và bạn muốn học hỏi từ mọi người.

Triển vọng và Thách thức của AI trong Năm Tới

Bạn nghĩ năm tới của trí tuệ nhân tạo (AI) sẽ trông như thế nào? Sự kiên trì là cực kỳ có giá trị. Các công ty thành công hiện nay đang xây dựng trong bất kỳ lĩnh vực mới nào, họ đang trải qua nỗi đau của việc học hỏi điều này, triển khai điều này và hiểu điều gì hiệu quả và điều gì không. Nỗi đau là phương thức mới (mode) hiện nay.

Giới Thiệu Khách Mời

Hôm nay, các khách mời của tôi là Aishwaria Raanti và Kiti Bottom. Kiti làm việc với Codex tại OpenAI và đã dành một thập kỷ qua để xây dựng cơ sở hạ tầng trí tuệ nhân tạo (AI) và học máy (ML) tại Google và Kumo. Ash là một nhà nghiên cứu trí tuệ nhân tạo (AI) sớm tại Alexa và Microsoft và đã xuất bản hơn 35 bài báo nghiên cứu. Cùng nhau, họ đã dẫn dắt và hỗ trợ hơn 50 lần triển khai sản phẩm AI tại các công ty như Amazon, Data Bricks, OpenAI, Google, và cả các startup và doanh nghiệp lớn. Cùng nhau, họ cũng giảng dạy khóa học trí tuệ nhân tạo (AI) được đánh giá số một trên Maven, nơi họ dạy các Lãnh đạo sản phẩm tất cả những bài học quan trọng mà họ đã học được về việc xây dựng sản phẩm AI thành công. Mục tiêu của tập này là giúp bạn và nhóm của bạn tránh được nhiều nỗi đau, sự vất vả và thời gian lãng phí khi cố gắng xây dựng sản phẩm AI của mình. Cho dù bạn đang gặp khó khăn trong việc làm cho sản phẩm của mình hoạt động hay muốn tránh khó khăn đó, tập này là dành cho bạn. Nếu bạn thích podcast này, đừng quên đăng ký và theo dõi nó trên ứng dụng podcast yêu thích của bạn hoặc YouTube. Điều đó giúp ích rất nhiều.

Và nếu bạn trở thành người đăng ký thường niên bản tin của tôi, bạn sẽ nhận được một năm miễn phí rất nhiều sản phẩm tuyệt vời, bao gồm một năm miễn phí lovable, replet, bold, gamma, nad linear, Devon, Postto, Superhum, Dcript, Whisper Flow, Perplexity, Warp, Granola, Magic Pattern, Dracast, Chapter D, Mobit, và Stripe Atlas. Hãy truy cập lenny'snewsletter.com và nhấp vào "product pass". Với những lời đó, tôi xin giới thiệu Awaria Oranti và Kiti Bottom sau một vài lời ngắn gọn từ các nhà tài trợ của chúng ta.

Thông Điệp Từ Nhà Tài Trợ

Tập này được tài trợ bởi Merge. Các Lãnh đạo sản phẩm ghét việc xây dựng các tích hợp. Chúng lộn xộn. Chúng chậm để xây dựng. Chúng làm tiêu tốn rất nhiều tài nguyên trên lộ trình sản phẩm của bạn, và chắc chắn đó không phải là lý do bạn tham gia vào sản phẩm ngay từ đầu. May mắn thay cho bạn, Merge bị ám ảnh bởi các tích hợp. Với một giao diện lập trình ứng dụng (API) duy nhất, các công ty SaaS B2B nhúng Merge vào sản phẩm của họ và triển khai hơn 220 tích hợp hướng tới khách hàng trong vài tuần, không phải vài quý. Hãy nghĩ về Merge giống như Plaid, nhưng cho mọi thứ SaaS B2B. Các công ty như Merall AI, Ramp, sử dụng Merge để kết nối các hệ thống kế toán, nhân sự, ticketing, CRM và lưu trữ tệp của khách hàng để hỗ trợ mọi thứ từ quá trình giới thiệu/hòa nhập tự động đến đường ống dữ liệu sẵn sàng cho AI. Tuyệt vời hơn nữa, Merge hiện hỗ trợ triển khai an toàn các connector cho Tác nhân AI với một sản phẩm mới để bạn có thể an toàn cung cấp quy trình làm việc AI với dữ liệu khách hàng thực. Nếu sản phẩm của bạn cần dữ liệu khách hàng từ hàng tá hệ thống, Merge là cách nhanh nhất, an toàn nhất để có được nó. Hãy đặt và tham dự một cuộc họp tại merge.dev/lenny và họ sẽ gửi cho bạn một thẻ quà tặng Amazon trị giá 50 đô la. Đó là merge.dev/lenny.

Tập này được tài trợ bởi Strella, nền tảng nghiên cứu khách hàng được xây dựng cho kỷ nguyên trí tuệ nhân tạo (AI). Đây là sự thật về nghiên cứu người dùng. Nó chưa bao giờ quan trọng hơn hoặc đau đớn hơn. Các nhóm muốn hiểu tại sao khách hàng làm những gì họ làm. Nhưng việc tuyển dụng người dùng, thực hiện phỏng vấn và phân tích thông tin chi tiết mất nhiều tuần. Đến khi có kết quả, thời điểm để hành động đã qua. Strella thay đổi điều đó. Đây là nền tảng đầu tiên sử dụng trí tuệ nhân tạo (AI) để tự động thực hiện và phân tích phỏng vấn chuyên sâu, mang đến nghiên cứu người dùng nhanh chóng và liên tục cho mọi nhóm. Người điều hành AI của Strella đặt câu hỏi theo dõi thực tế, đào sâu hơn khi câu trả lời mơ hồ và tìm ra mô hình trên hàng trăm cuộc trò chuyện, tất cả chỉ trong vài giờ, không phải vài tuần. Các nhóm thiết kế sản phẩm và nghiên cứu tại các công ty như Amazon và Duolingo đã sử dụng Strella để kiểm thử nguyên mẫu Figma, xác thực khái niệm và nghiên cứu hành trình khách hàng, nhận được thông tin chi tiết chỉ sau một đêm thay vì chờ đợi sprint tiếp theo. Nếu nhóm của bạn muốn hiểu khách hàng với tốc độ bạn ra mắt sản phẩm, hãy thử Strella. Thực hiện nghiên cứu tiếp theo của bạn tại strella.io/lenny. Đó là s-t-r-e-l-l-a.io/lenny.

Ash và Kiti, cảm ơn rất nhiều vì đã có mặt ở đây và chào mừng đến với podcast. Cảm ơn. Cảm ơn vì đã mời chúng tôi. Rất hào hứng với điều này.

Hiện Trạng Phát Triển Sản phẩm AI

Hãy để tôi đặt nền tảng cho cuộc trò chuyện mà chúng ta sẽ có hôm nay. Vậy, hai bạn đã tự mình xây dựng rất nhiều sản phẩm AI. Các bạn đã làm việc sâu sắc với rất nhiều công ty đã xây dựng sản phẩm AI, đã vật lộn để xây dựng sản phẩm AI, xây dựng Tác nhân AI. Các bạn cũng dạy một khóa học về xây dựng sản phẩm AI thành công và các bạn đang thực hiện một sứ mệnh nhằm giảm bớt nỗi đau, sự vất vả và thất bại mà các bạn liên tục thấy mọi người phải trải qua khi họ xây dựng sản phẩm AI. Vì vậy, để đặt một nền tảng nhỏ cho cuộc trò chuyện mà chúng ta sẽ có, các bạn đang thấy điều gì đang diễn ra trong các công ty đang cố gắng xây dựng sản phẩm AI? Điều gì đang diễn ra tốt? Điều gì không diễn ra tốt?

Tôi nghĩ năm 2025 đã khác biệt đáng kể so với năm 2024. Thứ nhất, sự hoài nghi đã giảm đáng kể. Có rất nhiều Lãnh đạo vào năm ngoái có lẽ nghĩ rằng đây sẽ lại là một làn sóng tiền mã hóa khác và khá hoài nghi khi bắt đầu, và rất nhiều trường hợp sử dụng mà tôi thấy năm ngoái giống như Snapchat trên dữ liệu của bạn, đúng không? Và điều đó, bạn biết đấy, tự gọi mình là một sản phẩm AI. Và năm nay, rất nhiều công ty đang thực sự suy nghĩ lại về trải nghiệm người dùng và quy trình làm việc của họ và tất cả những điều đó, và thực sự hiểu rằng bạn cần giải cấu trúc và tái cấu trúc các quy trình của mình để xây dựng sản phẩm AI thành công, đúng không? Và đó là những điều tốt đẹp.

Những điều tồi tệ là việc thực thi vẫn còn rất lộn xộn. Hãy nghĩ mà xem, đúng không? Đây là một lĩnh vực mới ba năm tuổi. Không có quy trình chuẩn. Không có sách giáo khoa. Vì vậy, bạn thực sự cần phải tìm hiểu khi bạn tiến hành, và chu trình sống của AI cả trước khi triển khai (pre-deployment) và sau khi triển khai (post-deployment) rất khác so với chu trình sống phần mềm truyền thống. Và vì vậy, rất nhiều hợp đồng và bàn giao cũ giữa các vai trò truyền thống như Quản lý Sản phẩm (PM) và kỹ sư và nhân sự dữ liệu hiện đã bị phá vỡ. Mọi người thực sự đang thích nghi với cách làm việc mới này cùng nhau và kiểu sở hữu cùng một vòng lặp phản hồi theo một cách nào đó, bởi vì trước đây, tôi cảm thấy rằng Quản lý Sản phẩm (PM) và kỹ sư và tất cả những người này đều có vòng lặp phản hồi riêng để tối ưu hóa, và bây giờ bạn có thể cần phải ngồi cùng phòng. Bạn có thể đang xem xét agent traces cùng nhau và quyết định sản phẩm của bạn nên hoạt động như thế nào. Vì vậy, đây là một hình thức cộng tác chặt chẽ hơn. Vì vậy, các công ty vẫn đang tìm hiểu điều đó. Đó là những gì tôi thấy trong hoạt động tư vấn của mình trong năm nay.

Giải Thích Sâu Hơn về Tính Không Xác Định và Quyền Tự Chủ của Tác Nhân

Vậy, hãy để tôi tiếp nối chủ đề đó. Chúng tôi đã cùng nhau viết một bài đăng khách đã được xuất bản vài tháng trước. Và điều khiến tôi ấn tượng nhất, điều đọng lại nhất sau khi làm việc về bài đăng đó là bạn đã có một nhận định thực sự quan trọng rằng việc xây dựng sản phẩm AI rất khác so với việc xây dựng các sản phẩm không phải AI. Và điều bạn muốn nhấn mạnh là có hai khác biệt rất lớn. Hãy nói về hai khác biệt đó.

Vâng. Và một lần nữa, tôi muốn đảm bảo rằng chúng ta đưa ra đúng điểm. Có rất nhiều điểm tương đồng khi xây dựng hệ thống AI và hệ thống phần mềm nữa. Nhưng sau đó có một số điều thay đổi cơ bản cách bạn xây dựng hệ thống phần mềm so với hệ thống AI, đúng không? Và một trong số đó mà hầu hết mọi người có xu hướng bỏ qua là tính không xác định. Bạn gần như đang làm việc với một giao diện lập trình ứng dụng (API) không xác định (non-deterministic API) so với phần mềm truyền thống. Điều đó có nghĩa là gì và tại sao điều đó lại ảnh hưởng đến chúng ta?

Trong phần mềm truyền thống, bạn gần như có một công cụ ra quyết định hoặc quy trình làm việc được ánh xạ rất tốt. Hãy nghĩ về một cái gì đó như Booking.com, đúng không? Bạn có một ý định rằng bạn muốn đặt phòng ở San Francisco trong hai đêm, v.v. Sản phẩm đã được xây dựng để ý định của bạn có thể được chuyển đổi thành một hành động cụ thể, và bạn đang nhấp qua một loạt nút, tùy chọn, biểu mẫu và tất cả những điều đó, và cuối cùng bạn đạt được ý định của mình. Nhưng bây giờ lớp đó trong sản phẩm AI đã hoàn toàn được thay thế bằng một giao diện rất linh hoạt chủ yếu là ngôn ngữ tự nhiên, có nghĩa là bạn, người dùng, thực sự có thể đưa ra rất nhiều cách để nói hoặc truyền đạt ý định của họ, đúng không? Và điều đó làm thay đổi rất nhiều thứ bởi vì bây giờ bạn không biết người dùng của bạn sẽ hành xử như thế nào. Đó là về phía đầu vào. Và đầu ra cũng là bạn đang làm việc với một giao diện lập trình ứng dụng (API) xác suất không xác định (non-deterministic probabilistic API) đó là mô hình ngôn ngữ lớn (LLM) của bạn. Và các mô hình ngôn ngữ lớn (LLM) khá nhạy cảm với cách diễn đạt prompt và chúng gần như là hộp đen. Vì vậy, bạn thậm chí không biết bề mặt đầu ra sẽ trông như thế nào, đúng không?

Vì vậy, điều này - bạn không biết người dùng có thể hành xử với sản phẩm của bạn như thế nào, và bạn cũng không biết mô hình ngôn ngữ lớn (LLM) có thể phản hồi như thế nào. Vì vậy, bây giờ bạn đang làm việc với một đầu vào, đầu ra và một quy trình. Và bạn không hiểu rõ cả ba điều đó. Bạn đang cố gắng dự đoán hành vi và xây dựng cho nó. Và với hệ thống tác nhân, điều này thậm chí còn khó hơn. Và đó là lúc chúng ta nói về sự khác biệt thứ hai, đó là sự đánh đổi giữa quyền tự chủ và kiểm soát (agency control trade-off). Đúng không? Điều chúng tôi muốn nói với điều đó, và tôi khá sốc, rất nhiều người không nói về điều này. Họ cực kỳ bị ám ảnh bởi việc xây dựng các hệ thống tự động, các tác nhân có thể làm việc cho bạn. Nhưng mỗi khi bạn trao quyền ra quyết định hoặc quyền tự chủ cho các hệ thống tác nhân, bạn đang từ bỏ một mức độ kiểm soát nhất định từ phía mình, đúng không? Và khi bạn làm điều đó, bạn muốn đảm bảo rằng tác nhân của bạn có thể giành được lòng tin của bạn hoặc nó đủ đáng tin cậy để bạn có thể cho phép nó đưa ra quyết định. Và đó là lúc chúng ta nói về sự đánh đổi giữa quyền tự chủ và kiểm soát (agency control trade-off) này, đó là, nếu bạn cung cấp cho Tác nhân AI hoặc hệ thống AI của bạn – dù là gì đi nữa – nhiều quyền tự chủ hơn, đó là khả năng đưa ra quyết định, bạn cũng đang mất đi một số kiểm soát, và bạn muốn đảm bảo rằng tác nhân hoặc hệ thống AI đã giành được khả năng đó hoặc đã xây dựng được lòng tin theo thời gian.

Vì vậy, tóm lại những gì bạn đang chia sẻ ở đây, về cơ bản mọi người đã xây dựng sản phẩm phần mềm trong một thời gian dài.

Sản phẩm AI: Tính Không Xác định và Cân bằng Quyền tự chủ - Kiểm soát

Chúng ta hiện đang sống trong một thế giới mà phần mềm bạn đang xây dựng là một phần mềm không xác định (non-deterministic), có thể làm những điều khác nhau. Chẳng hạn, như bạn đã nói, bạn vào booking.com để tìm một khách sạn, đó sẽ là cùng một trải nghiệm mỗi lần. Bạn sẽ thấy các khách sạn khác nhau, nhưng đó là một trải nghiệm có thể dự đoán được. Với trí tuệ nhân tạo (AI), bạn không thể dự đoán rằng nó sẽ là chính xác cùng một thứ, thứ mà bạn đã lên kế hoạch cho mỗi lần. Và điểm còn lại là có sự đánh đổi giữa quyền tự chủ (agency) và kiểm soát: trí tuệ nhân tạo (AI) sẽ làm bao nhiêu cho bạn so với việc con người vẫn nên chịu trách nhiệm bao nhiêu? Điều tôi đang nghe thấy là điểm mấu chốt ở đây là nó thay đổi đáng kể cách bạn nên xây dựng sản phẩm. Và chúng ta sẽ nói về tác động đến cách chu trình phát triển sản phẩm nên thay đổi như thế nào. Bạn có muốn bổ sung thêm điều gì trước khi chúng ta đi sâu vào điều đó không?

Tư duy Phát triển Sản phẩm AI: Từ Kiểm soát Cao đến Quyền tự chủ Cao

Vâng, đây chắc chắn là một trong những điểm mấu chốt mà sự phân biệt này cần phải tồn tại trong suy nghĩ của bạn khi bắt đầu xây dựng. Ví dụ, hãy nghĩ về việc mục tiêu của bạn là đi bộ đường dài đến Half Dome ở Yosemite, đúng không? Bạn không bắt đầu đi bộ đường dài mỗi ngày, mà bạn bắt đầu rèn luyện bản thân từ những phần nhỏ, sau đó dần dần cải thiện và rồi đạt được mục tiêu cuối cùng, đúng không? Tôi cảm thấy điều đó cực kỳ giống với cách bạn muốn xây dựng các sản phẩm AI. Theo nghĩa là bạn không nên bắt đầu với các tác nhân (agents) có tất cả các công cụ (tools) và ngữ cảnh (context) bạn có trong công ty ngay từ ngày đầu tiên và mong đợi nó hoạt động, hoặc thậm chí là mày mò ở cấp độ đó. Bạn cần phải cố ý bắt đầu ở những nơi có tác động tối thiểu và kiểm soát của con người cao hơn, để bạn nắm rõ được các khả năng hiện tại là gì và bạn có thể làm gì với chúng, sau đó dần dần nghiêng về phía có nhiều quyền tự chủ (agency) hơn và ít kiểm soát hơn. Điều này mang lại cho bạn sự tự tin rằng, "được rồi, tôi biết đây là vấn đề cụ thể tôi đang gặp phải, và trí tuệ nhân tạo (AI) có thể giải quyết được mức độ này của vấn đề." Sau đó, "hãy để tôi tiếp theo suy nghĩ về ngữ cảnh nào tôi cần đưa vào, loại công cụ nào tôi cần thêm vào để cải thiện trải nghiệm." Đúng không? Vì vậy, tôi cảm thấy điều này cũng là một điều tốt và xấu. Điều tốt là bạn không phải đối mặt với sự phức tạp của thế giới bên ngoài, như tất cả các Tác nhân AI cao cấp này, và cảm thấy như bạn không thể làm được điều đó. Mọi người luôn bắt đầu từ những cấu trúc rất tối giản và sau đó phát triển. Và phần thứ hai, điều tệ là khi bạn đang cố gắng xây dựng các Tác nhân một-lần-nhấp (one-click agents) vào công ty của mình, bạn không cần phải bị choáng ngợp bởi sự phức tạp này; bạn có thể từ từ nâng cấp. Vì vậy, điều đó cực kỳ quan trọng và chúng ta thấy đây là một mô hình lặp đi lặp lại.

Tiến trình Phát triển Trí tuệ Nhân tạo (AI)

Được rồi. Vậy thì, hãy đi sâu vào điều đó, đúng không? Bởi vì đó là một thành phần thực sự quan trọng trong cách bạn khuyên mọi người xây dựng các sản phẩm trí tuệ nhân tạo (AI). Các sản phẩm AI, Tác nhân AI, tất cả những thứ liên quan đến trí tuệ nhân tạo (AI). Vậy hãy cho chúng tôi một ví dụ về điều bạn đang nói ở đây: ý tưởng bắt đầu chậm với quyền tự chủ (agency) và kiểm soát, sau đó dần dần tăng cấp.

Ví dụ Điển hình: Tác nhân Hỗ trợ Khách hàng

Vâng. Ví dụ, một trường hợp sử dụng rất quan trọng hoặc rất phổ biến của các Tác nhân AI là hỗ trợ khách hàng, đúng không? Hãy tưởng tượng bạn là một công ty có rất nhiều phiếu hỗ trợ khách hàng. Hoặc thậm chí không cần tưởng tượng, OpenAI đã đối mặt với chính xác điều tương tự khi chúng tôi ra mắt sản phẩm, và có một sự gia tăng lớn về số lượng yêu cầu hỗ trợ khi chúng tôi ra mắt các sản phẩm thành công như DALL-E (tạo ảnh) hoặc GPT-5 và những thứ tương tự. Loại câu hỏi bạn nhận được là khác nhau; loại vấn đề mà khách hàng mang đến cho bạn là khác nhau. Vì vậy, không phải chỉ là việc đổ tất cả danh sách các bài viết trung tâm trợ giúp của bạn vào Tác nhân AI. Bạn cần hiểu những gì mình có thể xây dựng. Vì vậy, ban đầu, bước đầu tiên sẽ là bạn có các tác nhân hỗ trợ là con người, nhưng bạn sẽ gợi ý theo kiểu: "Đây là điều trí tuệ nhân tạo (AI) nghĩ là đúng nên làm." Và sau đó bạn nhận được vòng lặp phản hồi (feedback loop) từ con người rằng: "Được rồi, đây thực sự là một gợi ý tốt cho tôi trong trường hợp cụ thể này," hoặc "đây là một gợi ý tồi." Và sau đó bạn có thể quay lại và hiểu: "Được rồi, đây là những hạn chế," hoặc "đây là những điểm mù," và "làm thế nào để tôi khắc phục điều đó?" Và một khi bạn đã nắm được điều đó, bạn có thể tăng quyền tự chủ (autonomy) để nói rằng: "Được rồi, tôi không cần phải gợi ý cho con người; tôi sẽ thực sự hiển thị câu trả lời trực tiếp cho khách hàng." Và sau đó chúng ta thực sự có thể thêm nhiều sự phức tạp hơn theo kiểu: "Được rồi, tôi chỉ trả lời các câu hỏi dựa trên các bài viết trung tâm trợ giúp, nhưng bây giờ hãy để tôi thêm chức năng mới như tôi thực sự có thể hoàn tiền cho khách hàng, tôi thực sự có thể gửi yêu cầu tính năng (feature requests) cho nhóm kỹ sư (engineering team) và tất cả những điều này." Vì vậy, nếu bạn bắt đầu tất cả những điều này ngay từ ngày đầu tiên, sẽ cực kỳ khó để kiểm soát sự phức tạp. Vì vậy, chúng tôi khuyến nghị xây dựng từng bước và sau đó tăng dần.

Tóm tắt Nguyên tắc: Kiểm soát Cao đến Quyền tự chủ Cao

Tuyệt vời. Và thực tế bạn có một hình ảnh minh họa về điều này mà chúng tôi sẽ chia sẻ. Nhưng chỉ để nhắc lại những gì bạn đang mô tả: ý tưởng bắt đầu với kiểm soát cao, quyền tự chủ (agency) thấp. Trong ví dụ bạn đưa ra, tác nhân hỗ trợ chỉ đưa ra các gợi ý, không thể làm bất cứ điều gì; người dùng là người chịu trách nhiệm. Và sau đó, khi nó trở nên hữu ích và bạn tin tưởng rằng nó đang thực hiện đúng công việc, bạn cấp cho nó thêm một chút quyền tự chủ (agency) và giảm bớt sự kiểm soát của người dùng. Và nếu điều đó bắt đầu diễn ra tốt đẹp, bạn lại cấp cho nó nhiều quyền tự chủ (agency) hơn, và người dùng cần ít kiểm soát hơn để điều khiển nó. Tuyệt vời.

Hiệu chỉnh Hành vi Hệ thống AI và Vòng Quay Cải tiến (Flywheel)

Tôi nghĩ ý tưởng cấp cao hơn ở đây là với các hệ thống trí tuệ nhân tạo (AI), tất cả là về việc hiệu chỉnh hành vi. Thực sự không thể dự đoán trước hệ thống của bạn sẽ hành xử như thế nào. Vậy bạn làm gì để giải quyết điều đó? Bạn đảm bảo rằng bạn không làm hỏng trải nghiệm khách hàng hoặc trải nghiệm người dùng cuối của mình. Bạn giữ nguyên trải nghiệm đó nhưng sau đó giảm bớt mức độ kiểm soát mà con người có. Và không có một cách đúng đắn duy nhất để làm điều đó. Bạn có thể quyết định cách hạn chế quyền tự chủ (autonomy) đó, đúng không? Một ví dụ khác về cách bạn có thể hạn chế quyền tự chủ (autonomy) là các trường hợp sử dụng ủy quyền trước. Ủy quyền trước bảo hiểm là một trường hợp sử dụng rất phù hợp cho trí tuệ nhân tạo (AI) vì các bác sĩ lâm sàng dành nhiều thời gian để ủy quyền trước các xét nghiệm máu, MRI và những thứ tương tự, đúng không? Và có một số trường hợp dễ thực hiện hơn (low-hanging fruits), chẳng hạn như MRI và xét nghiệm máu, bởi vì ngay khi bạn có thông tin bệnh nhân, việc phê duyệt sẽ dễ dàng hơn và trí tuệ nhân tạo (AI) có thể làm điều đó, trong khi một thứ như phẫu thuật xâm lấn, v.v., có rủi ro cao hơn. Bạn không muốn làm điều đó một cách tự động. Vì vậy, bạn có thể xác định trường hợp sử dụng nào nên thông qua lớp người-trong-vòng-lặp (human-in-the-loop) so với trường hợp sử dụng nào mà trí tuệ nhân tạo (AI) có thể xử lý thuận tiện. Và sau đó, trong suốt quá trình này, bạn cũng ghi lại những gì con người đang làm, đúng không? Bởi vì bạn muốn xây dựng một flywheel mà bạn có thể sử dụng để cải thiện hệ thống của mình. Vì vậy, về cơ bản, bạn không làm hỏng trải nghiệm người dùng, không làm xói mòn niềm tin, đồng thời ghi lại những gì con người sẽ làm nếu không có trí tuệ nhân tạo (AI) để bạn có thể liên tục cải thiện hệ thống của mình.

Thêm Ví dụ về Tiến trình Tự chủ: Trợ lý Lập trình và Tiếp thị

Vậy hãy để tôi đưa ra thêm một vài ví dụ về loại tiến trình mà bạn đề xuất này. Lý do tôi dành nhiều thời gian ở đây là vì đây là một phần thực sự quan trọng trong khuyến nghị của bạn để giúp mọi người xây dựng các sản phẩm AI thành công hơn: ý tưởng bắt đầu chậm với kiểm soát cao và quyền tự chủ (agency) thấp, sau đó xây dựng dần theo thời gian khi bạn đã có được sự tự tin rằng nó đang thực hiện đúng công việc. Dưới đây là một vài ví dụ nữa mà bạn đã chia sẻ trong bài đăng của mình mà tôi sẽ đọc. Giả sử bạn đang xây dựng một trợ lý lập trình (coding assistant). V1 sẽ chỉ gợi ý hoàn thành nội tuyến (inline completion) và các đoạn mã mẫu (boilerplate snippets). V2 sẽ tạo ra các khối lớn hơn như các bài kiểm tra (tests) hoặc tái cấu trúc mã (refactors) để con người xem xét. Và sau đó V3 chỉ đơn giản là áp dụng các thay đổi và mở Pull Request (Yêu cầu hợp nhất mã) một cách tự động. Và một ví dụ khác là trợ lý tiếp thị (marketing assistant). V1 sẽ soạn thảo email hoặc nội dung mạng xã hội, chỉ như là "đây là những gì tôi sẽ làm". V2 là xây dựng một chiến dịch đa bước (multi-step campaign), chạy chiến dịch và sau đó triển khai. Và V3 chỉ đơn giản là triển khai nó, chạy A/B test, tự động tối ưu hóa các chiến dịch trên các kênh. Tuyệt vời.

Tóm tắt Sự khác biệt của Sản phẩm AI

Vâng. Và một lần nữa, để tóm tắt những gì chúng ta đã thảo luận, để cung cấp cho mọi người lời khuyên mà chúng ta đã chia sẻ cho đến nay: Điều quan trọng là phải hiểu rằng sản phẩm AI rất khác biệt. Chúng không xác định (non-deterministic). Và ông ấy đã chỉ ra, và tôi quên nhắc lại điểm này, rằng cả về đầu vào và đầu ra, trải nghiệm người dùng đều không xác định. Ví dụ, mọi người sẽ thấy những điều khác nhau, đầu ra khác nhau, các cuộc trò chuyện chat khác nhau, có thể là UI khác nhau nếu trí tuệ nhân tạo (AI) đang thiết kế UI cho bạn, và rõ ràng đầu ra cũng sẽ không xác định. Vì vậy, đó là một vấn đề và một thách thức. Và sau đó, ừm...

Lợi ích và Thách thức của Tính Không Xác định

Ý tôi là, nếu bạn nghĩ về nó, đó cũng là phần đẹp nhất của trí tuệ nhân tạo (AI). Chúng ta đều thoải mái nói chuyện hơn là phải bấm một loạt nút, đúng không? Vì vậy, rào cản để sử dụng sản phẩm AI thấp hơn nhiều vì bạn có thể tương tác tự nhiên như với con người. Nhưng đó cũng là vấn đề, đó là có vô số cách chúng ta giao tiếp. Và bạn muốn đảm bảo rằng ý định đó được truyền đạt đúng cách và các hành động đúng đắn được thực hiện, bởi vì hầu hết các hệ thống của bạn là xác định (deterministic), và bạn muốn đạt được một kết quả xác định, nhưng lại với công nghệ không xác định (non-deterministic), và đó là lúc mọi thứ trở nên hơi lộn xộn.

Tránh Sai lầm: Không vội vàng đến V3

Tuyệt vời. Được rồi. Tôi thích, tôi thích phiên bản lạc quan về lý do tại sao điều này lại tốt. Được rồi. Và sau đó, phần còn lại là ý tưởng về sự đánh đổi giữa quyền tự chủ (autonomy) và kiểm soát khi bạn thiết kế một thứ gì đó. Và điều tôi hình dung bạn đang thấy là mọi người cố gắng nhảy ngay đến phiên bản lý tưởng, giống như V3, và đó là lúc họ gặp rắc rối. Việc xây dựng đó có lẽ khó hơn rất nhiều và nó đơn giản là không hoạt động, và sau đó họ chỉ nghĩ, "được rồi, đây là một thất bại. Chúng ta đang làm gì vậy?"

Lợi ích của Cách tiếp cận Từng bước và "Ưu tiên Vấn đề"

Chính xác. Tôi cảm thấy có rất nhiều điều bạn thực sự phải tự tin trước khi đạt đến V3. Và rất dễ bị choáng ngợp khi nghĩ rằng, "Ôi, Tác nhân AI của tôi đang làm sai những điều này theo 100 cách khác nhau," và bạn sẽ không thể thực sự lập bảng tất cả và sửa chúng, ngay cả khi bạn đã học cách xử lý các thực tiễn đánh giá (evaluation practices) và những thứ tương tự. Nếu bạn bắt đầu sai chỗ, bạn sẽ thực sự gặp khó khăn trong việc sửa chữa mọi thứ từ đó. Và khi bạn bắt đầu nhỏ, khi bạn bắt đầu với việc xây dựng một phiên bản rất tối giản với kiểm soát của con người cao và quyền tự chủ (agency) thấp, nó cũng buộc bạn phải suy nghĩ về vấn đề bạn sẽ giải quyết là gì. Chúng tôi sử dụng thuật ngữ "ưu tiên vấn đề" (problem first), và đối với tôi, điều đó là rõ ràng theo nghĩa là vâng, tôi cần phải suy nghĩ về vấn đề. Nhưng thật đáng kinh ngạc khi nó gây được tiếng vang mạnh mẽ với mọi người rằng trong tất cả những tiến bộ về trí tuệ nhân tạo (AI) mà chúng ta đang thấy, một lối đi dễ dàng trượt dốc là chỉ mãi suy nghĩ về sự phức tạp của giải pháp mà quên đi vấn đề bạn đang cố gắng giải quyết. Vì vậy, khi bạn cố gắng bắt đầu ở quy mô quyền tự chủ (autonomy) nhỏ hơn, bạn bắt đầu thực sự suy nghĩ về vấn đề bạn đang cố gắng giải quyết và làm thế nào để chia nhỏ nó thành các cấp độ quyền tự chủ (autonomy) mà bạn có thể xây dựng sau này. Vì vậy, điều đó cực kỳ hữu ích, và chúng tôi cứ lặp đi lặp lại mô hình này với tất cả mọi người mà chúng tôi nói chuyện. Và có rất nhiều lợi ích khác cho việc hạn chế quyền tự chủ (autonomy), bởi vì cũng có nguy hiểm khi mọi thứ làm quá nhiều cho bạn và làm hỏng, tôi không biết, cơ sở dữ liệu của bạn, gửi tất cả những email bạn không bao giờ mong đợi. Có rất nhiều lý do tại sao đây là một ý tưởng hay.

Nguồn Tham khảo

Vâng. Tôi gần đây đã đọc một bài báo từ một nhóm người tại Đại học California, Berkeley.

Thách Thức Về Độ Tin Cậy Của Sản Phẩm AI

Về cơ bản, Zahara Stoker và đội ngũ tại Databricks đã cho biết khoảng 74% hoặc 75% các doanh nghiệp mà họ đã trao đổi, vấn đề lớn nhất của họ là độ tin cậy. Đó cũng là lý do tại sao họ không cảm thấy thoải mái khi triển khai các sản phẩm cho người dùng cuối hoặc xây dựng các sản phẩm hướng tới khách hàng, bởi vì họ không chắc chắn hoặc không muốn người dùng của mình phải đối mặt với nhiều rủi ro như vậy. Đây cũng là lý do tại sao nhiều sản phẩm AI ngày nay tập trung vào năng suất, vì chúng yêu cầu mức độ tự chủ thấp hơn so với các tác nhân AI toàn diện có thể thay thế toàn bộ quy trình làm việc. Tôi rất thích công việc của họ nói chung, và tôi nghĩ rằng điều này rất phù hợp với những gì chúng tôi đang thấy tại startup của mình.

Rủi Ro Bảo Mật AI: Prompt Injection và Jailbreaking

Đây là một điểm rất thú vị. Có một tập podcast sẽ ra mắt trước cuộc trò chuyện này, nơi chúng tôi đi sâu vào một vấn đề khác mà cách tiếp cận này tránh được, đó là về prompt injection và jailbreaking – mức độ rủi ro lớn của chúng đối với các sản phẩm AI, nơi mà về cơ bản đó là một vấn đề chưa được giải quyết và có khả năng là không thể giải quyết được. Tôi sẽ không đi sâu vào vấn đề đó, nhưng đó là một cuộc trò chuyện khá đáng sợ mà chúng tôi đã có, và nó sẽ ra mắt trước cuộc trò chuyện này.

Tôi nghĩ rằng đây sẽ là một vấn đề lớn khi các hệ thống trở nên phổ biến. Chúng ta vẫn đang quá bận rộn xây dựng sản phẩm AI mà chưa lo lắng về bảo mật, nhưng nó sẽ là một vấn đề lớn, đặc biệt với giao diện lập trình ứng dụng (API) phi xác định này, đúng không? Bạn sẽ bị mắc kẹt vì có rất nhiều lệnh bạn có thể tiêm vào prompt của mình, và sau đó, mọi thứ sẽ trở nên tồi tệ. Tôi nghĩ chúng ta hãy dành một chút thời gian ở đây vì nó thực sự thú vị đối với tôi và không ai nói về những điều này. Cuộc trò chuyện mà chúng tôi đã có là rất dễ để khiến trí tuệ nhân tạo (AI) làm những điều nó không nên làm, và có rất nhiều hệ thống bảo vệ mà mọi người đặt ra, nhưng hóa ra những rào cản này không thực sự hiệu quả và bạn luôn có thể vượt qua chúng. Và như bạn đã nói, khi các tác nhân AI trở nên tự chủ hơn, mọi thứ trở nên khá đáng sợ khi bạn có thể khiến AI làm những điều bạn không nên làm. Tôi nghĩ đây chắc chắn là một vấn đề.

Quan Điểm Lạc Quan Về Việc Triển Khai AI

Nhưng tôi cảm thấy trong bối cảnh hiện tại về việc khách hàng áp dụng trí tuệ nhân tạo (AI), mức độ mà các công ty có thể thực sự tận dụng AI hoặc cải thiện quy trình của họ hoặc hợp lý hóa các quy trình hiện có vẫn còn ở giai đoạn rất sớm. Năm 2025 đã là một năm cực kỳ bận rộn đối với các tác nhân AI và khách hàng cố gắng áp dụng AI. Nhưng tôi cảm thấy mức độ thâm nhập vẫn chưa đủ để bạn thực sự nhận được lợi ích. Vì vậy, với những điểm human in the loop phù hợp, tôi tin rằng chúng ta thực sự có thể tránh được nhiều điều này và tập trung hơn vào việc hợp lý hóa các quy trình. Tôi có xu hướng lạc quan hơn, theo nghĩa là bạn cần phải cố gắng áp dụng AI trước khi chỉ tập trung vào việc nêu bật những khía cạnh tiêu cực về những gì có thể sai. Vì vậy, tôi thực sự tin rằng các công ty phải áp dụng điều này. Chắc chắn, không có công ty nào chúng tôi đã nói chuyện tại OpenAI từng nói rằng AI không thể giúp họ trong trường hợp này. Luôn luôn là: "Ồ, có một tập hợp những điều mà nó có thể tối ưu hóa cho tôi, và sau đó hãy để tôi xem làm thế nào tôi có thể áp dụng nó." Tôi luôn thích quan điểm lạc quan. Tôi rất mong bạn sẽ nghe điều này và cho biết suy nghĩ của mình vì nó thực sự thú vị, và như bạn đã nói, có rất nhiều điều để tập trung vào. Đó là một trong rất nhiều điều cần lo lắng và suy nghĩ.

Các Yếu Tố Thành Công Khi Xây Dựng Sản Phẩm AI

Được rồi, hãy quay lại chủ đề chính. Chúng tôi đã chia sẻ rất nhiều mẹo chuyên nghiệp và lời khuyên quan trọng. Hãy để tôi hỏi, bạn còn thấy những mô hình và cách làm việc nào khác ở các công ty thực hiện tốt điều này và các nhóm xây dựng sản phẩm AI thành công? Và sau đó, những cạm bẫy phổ biến nhất mà mọi người mắc phải là gì? Vậy thì, chúng ta có thể bắt đầu với những cách khác mà các công ty làm tốt điều này, xây dựng sản phẩm AI thành công? Tôi gần như coi đó là một tam giác thành công với ba chiều. Nó không bao giờ chỉ là kỹ thuật. Mọi vấn đề công nghệ trước tiên là vấn đề con người. Và với các công ty mà chúng tôi đã làm việc cùng, đó là ba chiều này: lãnh đạo giỏi, văn hóa tốt và tiến bộ kỹ thuật.

Vai Trò Của Lãnh Đạo

Với bản thân các lãnh đạo, chúng tôi làm việc với rất nhiều công ty để chuyển đổi AI, đào tạo, chiến lược và những thứ tương tự. Và tôi cảm thấy rằng rất nhiều lãnh đạo của các công ty đã xây dựng trực giác trong hơn 10 hoặc 15 năm và họ được đánh giá cao vì những trực giác đó. Nhưng giờ đây, với trí tuệ nhân tạo (AI), những trực giác đó sẽ phải được học lại, và các lãnh đạo phải dễ bị tổn thương để làm điều đó.

Tôi từng làm việc với Giám đốc điều hành (CEO) của Rackspace (hiện tại), Gajen. Anh ấy có một khoảng thời gian mỗi sáng từ 4 đến 6 giờ sáng dành cho "cập nhật AI", và anh ấy sẽ không có bất kỳ cuộc họp hay việc gì khác. Đó là thời gian của anh ấy để cập nhật những podcast hoặc thông tin AI mới nhất. Anh ấy cũng có những buổi lập trình theo cảm hứng/trực giác vào cuối tuần và những thứ tương tự. Vì vậy, tôi nghĩ các lãnh đạo phải quay trở lại với việc thực hành, và đó không phải vì họ phải triển khai những điều này, mà là để xây dựng lại trực giác của họ. Bởi vì bạn phải chấp nhận sự thật rằng trực giác của bạn có thể không đúng. Và bạn có thể là người "ngu ngốc nhất" trong phòng và muốn học hỏi từ mọi người.

Tôi đã thấy đó là một yếu tố rất khác biệt của các công ty xây dựng sản phẩm AI thành công, bởi vì bạn đang mang lại phương pháp tiếp cận từ trên xuống (top-down approach). Hầu như không thể để nó là từ dưới lên. Bạn không thể có một nhóm kỹ sư đi lấy sự đồng thuận từ lãnh đạo nếu họ không tin tưởng vào công nghệ hoặc nếu họ có những kỳ vọng không phù hợp về công nghệ. Tôi đã nghe từ rất nhiều người đang xây dựng rằng lãnh đạo của chúng tôi không hiểu mức độ mà trí tuệ nhân tạo (AI) có thể giải quyết một vấn đề cụ thể, hoặc họ chỉ lập trình sơ sài và cho rằng việc đưa nó vào sản xuất là dễ dàng. Bạn thực sự cần hiểu phạm vi những gì AI có thể giải quyết ngày nay để bạn có thể định hướng các quyết định trong công ty.

Xây Dựng Văn Hóa Doanh Nghiệp

Thứ hai là bản thân văn hóa, đúng không? Và một lần nữa, tôi làm việc với các doanh nghiệp nơi trí tuệ nhân tạo (AI) không phải là trọng tâm chính của họ. Họ cần đưa AI vào quy trình của mình chỉ vì một đối thủ cạnh tranh đang làm điều đó và bởi vì nó thực sự có ý nghĩa do có những trường hợp sử dụng (use case) rất tiềm năng. Sau đó, trên đường đi, tôi cảm thấy rất nhiều công ty có văn hóa hội chứng FOMO và lo sợ "bạn sẽ bị thay thế" và những điều tương tự, khiến mọi người thực sự sợ hãi. Chuyên gia lĩnh vực (SME) là một phần rất lớn trong việc xây dựng sản phẩm AI hiệu quả, vì bạn thực sự cần tham khảo ý kiến của họ để hiểu AI của bạn đang hoạt động như thế nào hoặc hành vi lý tưởng nên ra sao. Nhưng tôi đã nói chuyện với nhiều công ty mà Chuyên gia lĩnh vực (SME) không muốn nói chuyện với bạn vì họ nghĩ công việc của mình đang bị thay thế.

Vì vậy, một lần nữa, điều này xuất phát từ bản thân lãnh đạo. Bạn muốn xây dựng một văn hóa trao quyền, tăng cường AI vào quy trình làm việc của chính bạn để bạn có thể tăng hiệu suất công việc lên 10 lần, thay vì nói rằng bạn sẽ bị thay thế nếu không áp dụng AI và những điều tương tự. Một văn hóa trao quyền như vậy luôn hữu ích. Bạn muốn toàn bộ tổ chức của mình cùng nhau làm việc và biến AI phục vụ bạn, thay vì cố gắng bảo vệ công việc của riêng họ, v.v. Và với trí tuệ nhân tạo (AI), cũng đúng là nó mở ra nhiều cơ hội hơn trước đây. Vì vậy, bạn có thể khiến nhân viên của mình làm được nhiều việc hơn trước đây và tăng năng suất của họ lên 10 lần.

Tiến Bộ Kỹ Thuật và Quy Trình Phát Triển

Thứ ba là phần kỹ thuật mà chúng ta nói đến, đúng không? Tôi nghĩ những người thành công cực kỳ say mê trong việc hiểu rõ quy trình làm việc của họ và tăng cường những phần có thể phù hợp với trí tuệ nhân tạo (AI) so với những phần có thể cần con người trong vòng lặp (human in the loop) ở đâu đó, v.v. Bất cứ khi nào bạn cố gắng tự động hóa một phần của quy trình làm việc, không bao giờ có chuyện bạn có thể sử dụng một tác nhân AI và nó sẽ giải quyết mọi vấn đề của bạn, đúng không? Luôn có khả năng bạn sẽ có một mô hình học máy (machine learning model) thực hiện một phần công việc. Bạn có mã xác định (deterministic code) thực hiện một phần công việc. Vì vậy, bạn thực sự cần phải bị ám ảnh bởi việc hiểu quy trình làm việc đó để bạn có thể chọn đúng công cụ cho vấn đề thay vì bị ám ảnh bởi bản thân công nghệ.

Và một mô hình khác mà tôi thấy là mọi người thực sự hiểu ý tưởng làm việc với giao diện lập trình ứng dụng (API) phi xác định, đó là mô hình ngôn ngữ lớn (LLM) của bạn. Và điều đó có nghĩa là họ cũng hiểu rằng vòng đời phát triển (development life cycle) trông rất khác và họ lặp lại khá nhanh chóng, đó là: Liệu tôi có thể xây dựng một cái gì đó, lặp lại nhanh chóng theo cách mà nó không làm hỏng trải nghiệm khách hàng (customer experience) của tôi, đồng thời cung cấp đủ dữ liệu để tôi có thể ước tính hành vi? Vì vậy, họ xây dựng bánh đà đó rất nhanh chóng. Hiện tại, vấn đề không phải là trở thành công ty đầu tiên có tác nhân AI so với các đối thủ cạnh tranh, mà là bạn đã xây dựng đúng bánh đà để có thể cải thiện theo thời gian hay chưa.

Khi ai đó đến gặp tôi và nói: "Chúng tôi có tác nhân AI một cú nhấp chuột này. Nó sẽ được triển khai trong hệ thống của bạn và sau hai hoặc ba ngày nó sẽ bắt đầu cho bạn thấy những lợi ích đáng kể," tôi gần như sẽ hoài nghi, vì điều đó đơn giản là không thể. Và đó không phải vì các mô hình không đủ tốt, mà vì dữ liệu doanh nghiệp và cơ sở hạ tầng rất lộn xộn, và ngay cả tác nhân AI cũng cần một thời gian để hiểu cách các hệ thống này hoạt động. Có rất nhiều phân loại lộn xộn ở khắp mọi nơi. Mọi người có xu hướng làm những việc như lấy dữ liệu khách hàng w1, lấy dữ liệu khách hàng w2 và những thứ tương tự, và tất cả các chức năng đó đều tồn tại và đang được gọi. Về cơ bản, có rất nhiều nợ kỹ thuật mà bạn cần phải giải quyết. Vì vậy, hầu hết thời gian, nếu bạn bị ám ảnh bởi bản thân vấn đề và bạn hiểu rõ quy trình làm việc của mình, bạn sẽ biết cách cải thiện tác nhân AI của mình theo thời gian thay vì chỉ "đắp" một tác nhân AI vào và giả định rằng nó sẽ hoạt động ngay từ ngày đầu tiên. Tôi có lẽ sẽ đi xa hơn khi nói rằng nếu ai đó đang bán cho bạn tác nhân AI một cú nhấp chuột, đó hoàn toàn là tiếp thị. Bạn không muốn tin vào điều đó. Tôi thà đi với một công ty nói rằng chúng tôi sẽ xây dựng quy trình này cho bạn và nó sẽ học hỏi theo thời gian và xây dựng một bánh đà để cải thiện, hơn là thứ gì đó sẽ hoạt động ngay lập tức để thay thế bất kỳ quy trình làm việc quan trọng nào hoặc để xây dựng một cái gì đó có thể mang lại Lợi tức đầu tư (ROI) đáng kể một cách dễ dàng. Việc đó mất từ bốn đến sáu tháng làm việc. Ngay cả khi bạn có lớp dữ liệu và lớp cơ sở hạ tầng tốt nhất.

Sự Tham Gia Sâu Sắc Của CEO

Tuyệt vời. Có rất nhiều điều ở đó rất cộng hưởng sâu sắc với những cuộc trò chuyện khác mà tôi đã có trên podcast này. Một điều là để một công ty thành công trong việc tạo ra nhiều tác động từ trí tuệ nhân tạo (AI), Giám đốc điều hành (CEO) phải thực sự tham gia sâu vào đó. Tôi đã có Dan Shipper trên podcast và họ làm việc với nhiều công ty giúp họ áp dụng AI, và anh ấy nói rằng đó là yếu tố dự đoán thành công số một: Giám đốc điều hành (CEO) trò chuyện với ChatGPT, Claude, hoặc bất kỳ chatbot nào nhiều lần một ngày. Tôi thích ví dụ bạn đưa ra về Rackspace với việc cập nhật tin tức AI vào buổi sáng mỗi ngày. Tôi đã hình dung anh ấy sẽ trò chuyện với chatbot thay vì đọc tin tức.

Với loại thông tin bạn có ngày nay, bạn có thể chỉ cần... Tôi muốn nói là bạn cũng muốn chọn đúng kênh, bởi vì mọi người đều có ý kiến. Vậy bạn muốn dựa vào ý kiến của ai? Tôi cảm thấy việc có một nhóm người chất lượng mà bạn lắng nghe thực sự rất có ý nghĩa. Vì vậy, anh ấy chỉ có một danh sách hai hoặc ba nguồn mà anh ấy luôn xem xét, và sau đó anh ấy quay lại với một loạt câu hỏi và thảo luận với một nhóm chuyên gia AI để xem họ nghĩ gì về điều đó.

Đánh Giá (Evals) và Giám Sát Sản Xuất (Production Monitoring): Phân Tích Cân Bằng

Tôi đã từng là thành viên của nhóm đó, nên tôi biết rõ về những câu hỏi mà anh ấy thường đưa ra. Tuyệt vời! Anh ấy đã làm rất nhiều, và điều đó đã tạo ra vô vàn quyết định mà chúng tôi đưa ra.

Được rồi, hãy nói về một chủ đề khác rất nóng hổi trên podcast này và từng là chủ đề sôi nổi trên Twitter một thời gian: evals. Rất nhiều người bị ám ảnh bởi evals, cho rằng chúng là giải pháp cho nhiều vấn đề trong trí tuệ nhân tạo (AI). Nhiều người khác lại nghĩ chúng bị đánh giá quá cao, rằng bạn không cần evals, chỉ cần "cảm nhận vibe" là ổn. Quan điểm của bạn về evals là gì? Chúng giúp mọi người giải quyết các vấn đề trong cộng đồng đến mức nào?

Tôi cảm thấy có một sự phân đôi sai lầm rằng evals sẽ giải quyết mọi thứ hoặc online monitoring hay production monitoring sẽ giải quyết mọi thứ. Tôi không thấy lý do gì để tin vào một trong hai thái cực này theo kiểu "tôi sẽ đặt cược toàn bộ ứng dụng của mình vào cái này hoặc cái kia để giải quyết vấn đề."

Nếu bạn lùi lại một bước, hãy nghĩ xem evals thực chất là gì. Về cơ bản, evals là tư duy sản phẩm đáng tin cậy của bạn, hay kiến thức của bạn về sản phẩm, được đưa vào một tập hợp các data sets mà bạn sẽ xây dựng. Theo đó, đây là những gì quan trọng đối với tôi: đây là loại vấn đề mà tác nhân của tôi không nên mắc phải, và tôi sẽ xây dựng một danh sách các data sets để đảm bảo nó hoạt động tốt trên các vấn đề đó.

Về production monitoring, điều bạn đang làm là triển khai ứng dụng của mình và sau đó bạn có một số chỉ số quan trọng thực sự cho bạn biết khách hàng đang sử dụng sản phẩm của bạn như thế nào. Chẳng hạn, bạn có thể triển khai bất kỳ tác nhân nào, và nếu khách hàng đưa ra đánh giá tích cực cho tương tác của bạn, bạn chắc chắn sẽ muốn biết điều đó. Đó là những gì production monitoring sẽ làm, phải không?

Production monitoring đã tồn tại cho các sản phẩm trong một thời gian dài, chỉ là giờ đây với tác nhân AI, bạn cần giám sát với mức độ chi tiết (granularity) cao hơn nhiều. Không chỉ là khách hàng luôn đưa ra phản hồi rõ ràng (explicit feedback), mà còn có nhiều phản hồi ngầm (implicit feedback) mà bạn có thể nhận được. Ví dụ, trong Chat GPT, nếu bạn thích câu trả lời, bạn có thể bấm thumbs up (thích) hoặc nếu bạn không thích câu trả lời, đôi khi khách hàng không bấm thumbs down (không thích) mà thực sự tái tạo lại câu trả lời. Đó là một dấu hiệu rõ ràng rằng câu trả lời ban đầu mà bạn tạo ra không đáp ứng mong đợi của khách hàng.

Đây là loại tín hiệu ngầm mà bạn luôn cần suy nghĩ, và phổ đó đã tăng lên về mặt production monitoring. Bây giờ, hãy quay lại chủ đề ban đầu: liệu có phải là eval hay production monitoring? Điều gì quan trọng?

Tôi lại cảm thấy chúng ta quay lại cách tiếp cận lấy vấn đề làm trọng tâm (problem-first approach) về những gì bạn đang cố gắng xây dựng. Bạn đang cố gắng xây dựng một ứng dụng đáng tin cậy cho khách hàng của mình, một ứng dụng sẽ không làm điều xấu, mà sẽ luôn làm điều đúng đắn. Hoặc nếu nó đang làm điều sai, bạn sẽ được cảnh báo rất nhanh chóng.

Tôi chia vấn đề này thành hai phần. Một là, không ai triển khai một ứng dụng mà không thực sự kiểm thử nó. Việc kiểm thử này có thể là "cảm nhận vibe" hoặc có thể là "tôi có 10 câu hỏi mà nó không được sai, bất kể tôi thực hiện thay đổi nào." Hãy xây dựng điều này và gọi nó là một evaluation data set.

Bây giờ, giả sử bạn đã xây dựng và triển khai nó, và sau đó bạn nhận ra rằng "được rồi, bây giờ tôi cần hiểu liệu nó có đang làm điều đúng đắn hay không." Nếu bạn là một khách hàng có thông lượng cao hoặc giao dịch cao, bạn không thể thực tế ngồi và đánh giá tất cả các dấu vết (traces). Bạn cần một dấu hiệu nào đó để hiểu những điều bạn nên xem xét, và đây là lúc production monitoring xuất hiện. Bạn không thể dự đoán được các trường hợp tác nhân của bạn có thể làm sai, nhưng tất cả các tín hiệu ngầm và tín hiệu rõ ràng khác sẽ thông báo lại cho bạn biết những dấu vết nào bạn cần xem xét, và đó là nơi production monitoring hữu ích.

Sau khi bạn nhận được những dấu vết này, bạn cần kiểm tra các mẫu lỗi (failure patterns) mà bạn đang thấy trong các loại tương tác khác nhau này. Có điều gì mà tôi thực sự quan tâm không nên xảy ra không? Và nếu loại chế độ lỗi (failure modes) đó đang xảy ra, thì tôi cần suy nghĩ về việc xây dựng một evaluation data set cho nó.

Ví dụ, tôi đã xây dựng một evaluation data set cho tác nhân của mình cố gắng hoàn tiền, trong đó tôi đã cấu hình rõ ràng để nó không làm điều đó. Sau khi xây dựng evaluation data set này, tôi đã thực hiện các thay đổi trong công cụ hoặc prompts hoặc bất cứ điều gì, và sau đó tôi đã triển khai phiên bản thứ hai của sản phẩm. Tuy nhiên, không có gì đảm bảo rằng đây là vấn đề duy nhất bạn sẽ thấy. Bạn vẫn cần production monitoring để thực sự nắm bắt các loại vấn đề khác nhau mà bạn có thể gặp phải.

Vì vậy, tôi cảm thấy evals rất quan trọng, production monitoring cũng rất quan trọng, nhưng cái ý niệm rằng chỉ một trong số chúng sẽ giải quyết mọi thứ cho bạn thì hoàn toàn có thể bác bỏ theo ý kiến của tôi.

Đúng vậy, một câu trả lời rất hợp lý, và điểm mấu chốt ở đây không chỉ đơn giản là "làm cả hai". Vấn đề là có những điều khác nhau cần phải nắm bắt, và một cách tiếp cận sẽ không nắm bắt được tất cả những điều bạn cần chú ý.

Chính xác. Tuyệt vời!

Sự Khuếch Tán Ngữ Nghĩa (Semantic Diffusion) của Thuật Ngữ "Evals"

Tôi muốn lùi lại hai bước và nói về việc thuật ngữ evals đã phải mang quá nhiều ý nghĩa như thế nào. Bạn gặp một công ty gán nhãn dữ liệu (data labeling company) và họ nói với bạn rằng các chuyên gia của chúng tôi đang viết evals. Và sau đó, bạn có tất cả những người nói rằng các Quản lý Sản phẩm (PM) nên viết evals. Chúng là những Tài liệu Yêu cầu Sản phẩm (PRD) mới. Và sau đó bạn có những người nói rằng eval gần như là mọi thứ, đó là vòng lặp phản hồi (feedback loop) mà bạn phải xây dựng để cải thiện sản phẩm của mình.

Bây giờ, hãy lùi lại với tư cách là người mới bắt đầu và suy nghĩ: evals là gì? Tại sao mọi người đều nói eval? Và đây thực sự là những phần khác nhau của quá trình, và không ai sai cả, theo nghĩa là "vâng, đây là evals". Nhưng khi một công ty gán nhãn dữ liệu nói với bạn rằng các chuyên gia của họ đang viết evals, họ thực sự đang đề cập đến phân tích lỗi (error analysis) hoặc, bạn biết đấy, các chuyên gia chỉ ghi lại ghi chú (notes) về những gì nên đúng. Các luật sư và bác sĩ viết evals không có nghĩa là họ đang xây dựng giám định viên LLM (LLM judges) hoặc họ đang xây dựng toàn bộ vòng lặp phản hồi này. Và khi bạn nói rằng một Quản lý Sản phẩm (PM) nên viết evals, không có nghĩa là họ phải viết một giám định viên LLM đủ tốt cho sản xuất (production).

Tôi nghĩ cũng có những cách làm rất chỉ dẫn (prescriptive ways) để làm điều này, và tôi hoàn toàn đồng ý với KD rằng bạn không thể dự đoán trước liệu bạn cần xây dựng một giám định viên LLM hay bạn cần sử dụng tín hiệu ngầm từ giám sát sản xuất (production monitoring), v.v. Tôi nghĩ Martin Fowler vào một thời điểm nào đó đã có thuật ngữ semantic diffusion (khuếch tán ngữ nghĩa) vào những năm 2000. Điều đó có nghĩa là ai đó đưa ra một thuật ngữ, mọi người bắt đầu bóp méo nó với các định nghĩa của riêng họ, và sau đó bạn mất đi định nghĩa thực sự của nó. Đó là những gì đang xảy ra với eval ngày nay. Mọi người đều nhìn thấy một khía cạnh khác của nó, tôi đoán vậy.

Nhưng nếu bạn tập hợp một nhóm người thực hành (practitioners) lại với nhau và hỏi họ liệu có quan trọng không khi xây dựng một vòng lặp phản hồi có thể hành động (actionable feedback loop) cho các sản phẩm AI? Tôi nghĩ tất cả họ sẽ đồng ý. Bây giờ, cách bạn thực hiện điều đó thực sự phụ thuộc vào ứng dụng của bạn. Khi bạn đi đến các trường hợp sử dụng (use cases) phức tạp, việc xây dựng giám định viên LLM vô cùng khó khăn vì bạn thấy rất nhiều mẫu hình mới nổi (emerging patterns). Nếu bạn xây dựng một giám định viên để kiểm tra tính dài dòng (verbosity) hoặc một cái gì đó tương tự, hóa ra bạn lại thấy những mẫu hình mới hơn mà giám định viên LLM của bạn không thể bắt được, và sau đó bạn chỉ xây dựng quá nhiều evals. Lúc đó, chỉ có ý nghĩa khi bạn xem xét các tín hiệu người dùng (user signals), khắc phục chúng, kiểm tra xem bạn có bị hồi quy (regressed) hay không và tiếp tục thay vì thực sự xây dựng các giám định viên này.

Vì vậy, tất cả phụ thuộc. Tôi nghĩ một tuyên bố mà mọi người thực hành ML sẽ nói với bạn là: nó thực sự phụ thuộc vào ngữ cảnh (context). Đừng bị ám ảnh bởi các chỉ dẫn (prescriptions). Chúng sẽ thay đổi.

Đó là một điểm rất quan trọng. Ý tưởng rằng eval hiện nay có nghĩa là nhiều thứ đối với nhiều người khác nhau. Nó giống như một thuật ngữ cho rất nhiều thứ. Và thật phức tạp khi chỉ nói về evals khi bạn nghĩ về nó như những thứ mà các công ty gán nhãn dữ liệu cung cấp cho bạn và mọi thứ đều đúng. Và cũng có các tiêu chuẩn (benchmarks). Mọi người cũng gọi benchmarks là eval một chút.

Tôi gần đây đã nói chuyện với một khách hàng, họ nói với tôi rằng "chúng tôi thực hiện evals." Và tôi đã hỏi "Được rồi, bạn có thể cho tôi xem data set của bạn không?" Và họ nói, "Không, chúng tôi chỉ kiểm tra LLM arena và phân tích nhân tạo (artificial analysis). Đây là những tiêu chuẩn độc lập (independent benchmarks) và chúng tôi biết rằng mô hình này là đúng cho trường hợp sử dụng của chúng tôi." Và tôi nói, "Bạn không làm eval. Đó không phải là eval. Đó là mô hình."

Điều đó có lý. Từ ngữ, bạn biết đấy, có thể được sử dụng trong ngữ cảnh đó. Tôi hiểu tại sao mọi người lại nghĩ như vậy, nhưng vâng, bây giờ nó càng làm mọi thứ thêm khó hiểu.

Đúng vậy.

Cách Tiếp Cận Evals Của Codex

Chỉ một câu hỏi nữa mà tôi đang nghĩ đến là lý do tại sao điều này trở thành một cuộc tranh luận lớn là Boris, người đứng đầu Claude Code, đã nói: "Không, chúng tôi không làm evals trên Claude Code. Tất cả chỉ là lập trình theo cảm hứng/trực giác (vibe coding)." Bạn có thể chia sẻ gì, Kiti, về Codex và nhóm Codex về cách các bạn tiếp cận evals?

Tại Codex, chúng tôi có cách tiếp cận cân bằng (balanced approach), tức là bạn cần có evals và bạn cần lắng nghe khách hàng của mình. Tôi nghĩ Alex gần đây đã tham gia podcast của bạn và anh ấy đã nói về việc chúng tôi cực kỳ tập trung vào việc xây dựng sản phẩm phù hợp. Và một phần lớn của điều đó về cơ bản là lắng nghe khách hàng của bạn.

Các tác nhân viết mã (coding agents) cực kỳ độc đáo so với các tác nhân cho các lĩnh vực (domains) khác theo nghĩa là chúng thực sự được xây dựng cho khả năng tùy chỉnh (customizability) và chúng được xây dựng cho các kỹ sư. Vì vậy, tác nhân viết mã không phải là một sản phẩm sẽ giải quyết năm quy trình làm việc (workflows) hàng đầu hoặc sáu quy trình làm việc hàng đầu hoặc bất cứ điều gì. Nó được thiết kế để tùy chỉnh theo nhiều cách khác nhau, và hàm ý của điều đó là sản phẩm của bạn sẽ được sử dụng trong các tích hợp (integrations) khác nhau, các loại công cụ khác nhau và các loại thứ khác nhau. Vì vậy, việc xây dựng một evaluation data set cho tất cả các loại tương tác mà khách hàng của bạn sẽ sử dụng sản phẩm là thực sự khó.

Nhưng điều đó có nghĩa là, bạn cũng cần hiểu rằng nếu tôi thực hiện một thay đổi, ít nhất nó sẽ không làm hỏng thứ gì đó thực sự cốt lõi của sản phẩm. Vì vậy, chúng tôi có các evaluations để làm điều đó. Đồng thời, chúng tôi cực kỳ cẩn thận trong việc tìm hiểu cách khách hàng đang sử dụng nó. Ví dụ, gần đây chúng tôi đã xây dựng sản phẩm đánh giá mã (code review product) này và nó đã nhận được một lượng lực kéo (traction) cực lớn, và tôi cảm thấy nhiều lỗi (bugs) trong OpenAI cũng như ngay cả các khách hàng bên ngoài (external customers) cũng đang bị bắt bởi điều này.

Và bây giờ, giả sử tôi đang thực hiện một thay đổi mô hình (model change) đối với đánh giá mã hoặc một loại cơ chế học tăng cường (RL) (RL mechanism) khác mà tôi đã huấn luyện với nó, và bây giờ nếu tôi định triển khai nó, tôi chắc chắn muốn kiểm thử A/B (A/B test) và xác định xem liệu nó có thực sự tìm ra những sai sót (mistakes) phù hợp hay không và người dùng phản ứng với nó như thế nào. Và đôi khi, nếu người dùng bị khó chịu (annoyed) bởi các bộ sửa mã (code riggers) không chính xác của bạn, họ sẽ đi đến mức tắt sản phẩm. Vì vậy, đó là những tín hiệu mà bạn muốn xem xét và đảm bảo rằng những thay đổi mới của bạn đang làm điều đúng đắn, và việc chúng tôi phải nghĩ ra những kịch bản (scenarios) này từ trước và phát triển evaluation data sets cho chúng là cực kỳ khó khăn.

Đánh giá Mô hình và Phản hồi Người dùng

Tôi cảm thấy có một chút của cả hai: có rất nhiều vibes và rất nhiều phản hồi từ khách hàng. Chúng tôi cực kỳ tích cực trên các nền tảng mạng xã hội để nắm bắt nếu có ai đang gặp phải các vấn đề nhất định và nhanh chóng khắc phục chúng. Vì vậy, tôi cảm thấy đây là một — làm thế nào để tôi diễn đạt điều này? — Nó giống như một lĩnh vực đa dạng các việc bạn làm ở đây. Điều đó rất hợp lý. Được rồi, những gì tôi đang nghe là các evals Codex Pro là cần thiết, nhưng chưa đủ. Bạn cần phải... Vâng. Nhưng ngoài ra, còn cần theo dõi hành vi và phản hồi của khách hàng, và cũng có một số vibes—kiểu như liệu nó có ổn không? Liệu khi tôi sử dụng nó có tạo ra mã tuyệt vời mà tôi cảm thấy hào hứng và nghĩ rằng nó thật tốt không?

Tôi không nghĩ rằng nếu ai đó đến và nói rằng: "Tôi có một bộ evals cụ thể mà tôi có thể đặt cược cả đời vào đó, và tôi không cần phải nghĩ về bất cứ điều gì khác", thì điều đó sẽ không hiệu quả. Và mỗi mô hình mới mà chúng tôi sắp ra mắt, chúng tôi đều tập hợp lại như một đội và thử nghiệm các thứ khác nhau. Mỗi người tập trung vào một khía cạnh khác nhau, và chúng tôi có danh sách các vấn đề khó mà chúng tôi ném vào mô hình để xem chúng tiến triển tốt đến mức nào. Vì vậy, nó giống như các evals tùy chỉnh cho mỗi kỹ sư, và chỉ để hiểu sản phẩm đang làm gì trong mô hình mới này.

Brex: Nền tảng Tài chính Thông minh

Nếu bạn là nhà sáng lập, phần khó nhất khi bắt đầu một công ty khởi nghiệp (startup) không phải là có ý tưởng. Đó là việc mở rộng kinh doanh mà không bị chôn vùi trong công việc back office work. Đó là lúc Brex xuất hiện. Brex là nền tảng tài chính thông minh dành cho các nhà sáng lập. Với Brex, bạn có thể nhận được thẻ tín dụng doanh nghiệp high limit corporate cards, ngân hàng dễ dàng, quản lý kho bạc high yield treasury hiệu suất cao, cùng với một đội tác nhân AI xử lý các tác vụ tài chính thủ công cho bạn. Chúng sẽ làm tất cả những việc bạn không muốn làm, như nộp chi phí của bạn, quét các giao dịch để tìm sự lãng phí, và chạy báo cáo, tất cả đều theo quy tắc của bạn. Với tác nhân AI của Brex, bạn có thể di chuyển nhanh hơn trong khi vẫn giữ quyền kiểm soát hoàn toàn. Một trong ba công ty khởi nghiệp (startup) ở Hoa Kỳ đã đang hoạt động trên Brex. Bạn cũng có thể làm như vậy tại brex.com.

Giới thiệu Khung Phát triển Liên tục

Chúng ta đã nói chuyện gần một giờ rồi mà thậm chí còn chưa đề cập đến quy trình phát triển phần mềm cực kỳ mạnh mẽ của bạn để xây dựng sản phẩm AI mà cả hai bạn đã phát triển, mà bạn giảng dạy trong khóa học của mình, về cơ bản kết hợp tất cả những gì chúng ta đã nói vào một phương pháp tiếp cận từng bước để xây dựng sản phẩm AI. Bạn gọi nó là khung Phát triển liên tục, Hiệu chỉnh liên tục. Hãy cùng xem một hình ảnh để mọi người hiểu chúng ta đang nói về điều gì và sau đó hãy giải thích cho chúng ta cách thức này hoạt động, cách các đội có thể thay đổi cách họ xây dựng sản phẩm AI theo phương pháp này để giúp họ tránh được nhiều nỗi đau và sự vất vả.

Trước khi chúng ta đi vào giải thích vòng đời (life cycle), một câu chuyện ngắn gọn về lý do Kita và tôi nghĩ ra điều này là vì có rất nhiều công ty mà chúng tôi liên tục nói chuyện, họ đang chịu áp lực từ các đối thủ cạnh tranh vì tất cả họ đều đang xây dựng tác nhân. Chúng ta cũng nên xây dựng các tác nhân hoàn toàn tự động (autonomous). Và tôi đã thực sự làm việc với một vài khách hàng nơi chúng tôi xây dựng các tác nhân đầu cuối (end-to-end). Và hóa ra là bởi vì bạn bắt đầu từ một nơi mà bạn không biết người dùng có thể tương tác với hệ thống của bạn như thế nào và AI có thể đưa ra loại phản hồi hoặc hành động nào, nên thực sự khó để khắc phục vấn đề khi bạn có một workflow thực sự lớn, mất bốn hoặc năm bước, đưa ra hàng tấn quyết định. Bạn cứ thế mà gỡ lỗi (debugging) quá nhiều và sau đó sửa lỗi nóng (hot fixing) đến mức tại một thời điểm chúng tôi đang xây dựng cho một trường hợp sử dụng hỗ trợ khách hàng, đó cũng là ví dụ chúng tôi đưa ra trong bản tin, và chúng tôi phải đóng sản phẩm đó vì chúng tôi đã thực hiện quá nhiều sửa lỗi nóng (hot fixing) và không có cách nào chúng tôi có thể tính toán tất cả các vấn đề mới nổi đang xuất hiện.

Và cũng có khá nhiều tin tức trực tuyến gần đây, tôi nghĩ Air Canada đã có một vụ việc trong đó một trong các tác nhân của họ đã dự đoán hoặc tạo ra chính sách sai lệch về chính sách hoàn tiền mà không phải là một phần của quy trình ban đầu của họ và họ phải tuân theo vì các vấn đề pháp lý. Và đã có rất nhiều sự cố thực sự đáng sợ và đó là nơi ý tưởng này ra đời: làm thế nào bạn có thể xây dựng để không làm mất lòng tin của khách hàng và tác nhân của bạn hoặc hệ thống trí tuệ nhân tạo (AI) của bạn không đưa ra các quyết định quá nguy hiểm đối với chính công ty, đồng thời xây dựng một flywheel để bạn có thể cải thiện sản phẩm của mình theo thời gian? Và đó là lý do tại sao chúng tôi đưa ra ý tưởng về khung Phát triển liên tục, Hiệu chỉnh liên tục.

Phát triển Liên tục

Ý tưởng khá đơn giản là chúng ta có phía bên phải của vòng lặp, đó là phát triển liên tục, nơi bạn xác định khả năng (scope capability) và sắp xếp dữ liệu (curate data), về cơ bản là tạo một tập dữ liệu (data set) về các đầu vào dự kiến của bạn và các đầu ra dự kiến của bạn nên trông như thế nào. Đây là một bài tập rất tốt trước khi bạn bắt đầu xây dựng bất kỳ sản phẩm AI nào bởi vì nhiều khi bạn nhận ra rằng rất nhiều người trong đội chỉ đơn giản là không đồng bộ về cách sản phẩm nên hoạt động, và đó là lúc Quản lý Sản phẩm (PMs) của bạn có thể cung cấp thêm rất nhiều thông tin, cũng như Chuyên gia lĩnh vực (SME) của bạn. Vì vậy, bạn có một tập dữ liệu mà bạn biết sản phẩm AI của mình nên hoạt động thực sự tốt. Nó không toàn diện, nhưng nó cho phép bạn bắt đầu, và sau đó bạn thiết lập ứng dụng, rồi thiết kế các chỉ số đánh giá (evaluation metrics) phù hợp. Và tôi cố ý sử dụng thuật ngữ chỉ số đánh giá (evaluation metrics) mặc dù chúng ta nói eval vì tôi chỉ muốn rất cụ thể về nó là gì, bởi vì đánh giá là một quá trình, còn chỉ số đánh giá (evaluation metrics) là các khía cạnh bạn muốn tập trung vào trong quá trình đó. Và sau đó bạn tiến hành triển khai, chạy các chỉ số đánh giá (evaluation metrics) của mình.

Hiệu chỉnh Liên tục

Phần thứ hai là hiệu chỉnh liên tục, là phần bạn hiểu được hành vi mà bạn không mong đợi lúc ban đầu. Bởi vì khi bạn bắt đầu quá trình phát triển, bạn có một tập dữ liệu mà bạn đang tối ưu hóa, nhưng thường thì bạn nhận ra rằng tập dữ liệu đó không đủ toàn diện, vì người dùng bắt đầu tương tác với hệ thống của bạn theo những cách mà bạn không dự đoán được. Và đó là lúc bạn muốn thực hiện phần hiệu chỉnh. Tôi đã triển khai hệ thống của mình. Bây giờ tôi thấy có những mẫu mà tôi không thực sự mong đợi, và các chỉ số đánh giá (evaluation metrics) của bạn nên cung cấp cho bạn một số hiểu biết sâu sắc về những mẫu đó. Nhưng đôi khi bạn nhận ra rằng những chỉ số đó cũng không đủ, và bạn có thể có các mẫu lỗi mới mà bạn chưa từng nghĩ đến, và đó là lúc bạn phân tích hành vi của mình, phát hiện các mẫu lỗi. Bạn áp dụng các sửa lỗi (fixes) cho các vấn đề bạn thấy, nhưng bạn cũng thiết kế các chỉ số đánh giá (evaluation metrics) mới hơn để phát hiện ra rằng đó là những mẫu đang nổi lên. Và điều đó không có nghĩa là bạn luôn phải thiết kế chỉ số đánh giá (evaluation metrics). Có một số lỗi mà bạn có thể chỉ cần sửa và không cần quay lại, bởi vì chúng là những lỗi rất cụ thể. Ví dụ, có một lỗi tool calling error chỉ vì công cụ của bạn không được định nghĩa tốt và những thứ tương tự. Bạn có thể chỉ cần sửa nó và tiếp tục, phải không? Và đây là cách mà một vòng đời sản phẩm AI sẽ trông như thế nào.

Quản lý Quyền tự chủ và Kiểm soát

Nhưng điều chúng tôi đặc biệt đề cập thêm là, trong khi bạn đang trải qua các vòng lặp (iterations) này, hãy cố gắng nghĩ đến các vòng lặp có quyền tự chủ (agency) thấp hơn ở giai đoạn đầu và các vòng lặp có kiểm soát (control) cao hơn. Điều đó có nghĩa là hãy giới hạn số lượng quyết định mà hệ thống trí tuệ nhân tạo (AI) của bạn có thể đưa ra và đảm bảo rằng có con người trong quy trình (humans in the loop), sau đó tăng dần theo thời gian bởi vì bạn đang xây dựng một flywheel hành vi và bạn đang hiểu được loại trường hợp sử dụng nào đang xuất hiện hoặc cách người dùng của bạn đang sử dụng hệ thống. Và một ví dụ mà tôi nghĩ chúng tôi đưa ra trong bản tin là tác nhân hỗ trợ khách hàng. Đây là một hình ảnh đẹp mô tả cách bạn có thể nghĩ về quyền tự chủ (agency) và kiểm soát (control) như hai chiều, và mỗi phiên bản của bạn liên tục tăng quyền tự chủ (agency) hoặc khả năng đưa ra quyết định của hệ thống trí tuệ nhân tạo (AI) của bạn và giảm kiểm soát (control) theo thời gian.

Và một ví dụ mà chúng tôi đưa ra là của tác nhân hỗ trợ khách hàng, nơi bạn có thể chia nó thành ba phiên bản. Phiên bản đầu tiên chỉ là định tuyến (routing), tức là liệu tác nhân của bạn có khả năng phân loại và định tuyến một ticket cụ thể đến đúng phòng ban hay không. Và đôi khi khi bạn đọc điều này, bạn có thể nghĩ rằng liệu việc định tuyến có khó đến vậy không? Tại sao một tác nhân không thể dễ dàng làm điều đó? Và khi bạn làm việc với các doanh nghiệp (enterprises), việc định tuyến tự nó có thể là một vấn đề cực kỳ phức tạp. Bất kỳ công ty bán lẻ phổ biến nào mà bạn có thể nghĩ đến đều có hệ thống phân loại theo cấp bậc (hierarchical taxonomies). Hầu hết các thời gian, các hệ thống phân loại này đều cực kỳ lộn xộn. Tôi đã làm việc trong các trường hợp sử dụng mà bạn có thể có các hệ thống phân loại nói về, bạn biết đấy, một số loại phân cấp và sau đó nói về giày, rồi giày nữ và giày nam đều ở cùng một cấp độ, trong khi ý tưởng là bạn nên có giày và sau đó giày nữ và giày nam nên là các lớp con. Và sau đó bạn nghĩ, "được thôi, tôi có thể hợp nhất chúng," và bạn đi xa hơn và bạn thấy rằng cũng có một phần khác dưới giày nói về dành cho nữ và dành cho nam và nó chỉ không được tổng hợp, nó không được sửa chữa vì một lý do nào đó. Vậy nếu một tác nhân nhìn thấy loại hệ thống phân loại như thế này, nó phải làm gì? Nó phải định tuyến đến đâu, và rất nhiều lần chúng ta không nhận thức được những vấn đề này cho đến khi bạn thực sự bắt đầu xây dựng thứ gì đó và hiểu rõ nó, phải không?

Và khi những loại vấn đề này, các tác nhân con người thực sự gặp phải những vấn đề này, họ biết phải kiểm tra gì tiếp theo. Có thể họ nhận ra rằng nút nói "dành cho nữ" và "dành cho nam" nằm dưới "giày" được cập nhật lần cuối vào năm 2019, điều đó có nghĩa là nó chỉ là một nút chết nằm đó và không được sử dụng. Vì vậy, họ biết rằng họ nên tìm một nút khác và những thứ tương tự. Và tôi không nói rằng các tác nhân không thể hiểu điều này hoặc các mô hình không đủ khả năng để hiểu điều này, nhưng có những quy tắc thực sự kỳ lạ trong các doanh nghiệp (enterprises) không được ghi lại ở bất cứ đâu và bạn muốn đảm bảo rằng các tác nhân có tất cả ngữ cảnh (context) đó thay vì chỉ ném vấn đề vào chúng, phải không?

Các Phiên bản Tác nhân Hỗ trợ Khách hàng

Quay lại các phiên bản chúng ta đã có, định tuyến là một trong số đó, nơi bạn có kiểm soát (control) rất cao vì ngay cả khi tác nhân của bạn định tuyến sai phòng ban, con người vẫn có thể nắm quyền kiểm soát (control) và, bạn biết đấy, hoàn tác những hành động đó. Và trên đường đi, bạn cũng nhận ra rằng bạn có thể đang đối phó với rất nhiều vấn đề về dữ liệu mà bạn cần khắc phục và đảm bảo rằng lớp dữ liệu của bạn đủ tốt để tác nhân hoạt động.

Điều chúng tôi làm tiếp theo là một co-pilot, tức là sau khi bạn đã xác định được định tuyến hoạt động tốt sau vài vòng lặp và bạn đã khắc phục tất cả các vấn đề về dữ liệu, bạn có thể chuyển sang bước tiếp theo là liệu tác nhân của tôi có thể đưa ra các đề xuất (suggestions) dựa trên một số quy trình vận hành tiêu chuẩn (standard operating procedures) mà chúng ta có cho tác nhân hỗ trợ khách hàng không? Và nó có thể tạo ra một bản nháp (draft) mà con người có thể thực hiện thay đổi. Và khi bạn làm điều này, bạn cũng đang ghi lại hành vi của con người, điều đó có nghĩa là bao nhiêu bản nháp này đã được tác nhân hỗ trợ khách hàng sử dụng hoặc những gì đã bị bỏ qua. Vì vậy, bạn thực sự nhận được phân tích lỗi miễn phí khi bạn làm điều này bởi vì bạn đang ghi lại mọi thứ mà người dùng đang làm, điều mà bạn có thể xây dựng lại vào flywheel của mình.

Và sau đó chúng tôi nói rằng, sau khi bạn đã xác định rằng những bản nháp đó trông tốt và hầu hết thời gian có lẽ con người không thực hiện quá nhiều thay đổi, họ đang sử dụng những bản nháp này nguyên trạng. Đó là lúc bạn muốn chuyển sang trợ lý giải quyết đầu cuối (end-to-end) của bạn, có thể, bạn biết đấy, soạn thảo một giải pháp (resolution) có thể sắp xếp ticket nữa. Và đó là các giai đoạn của quyền tự chủ (agency) nơi bạn bắt đầu với quyền tự chủ (agency) thấp và sau đó bạn đi lên cao.

Học hỏi và Cải tiến Liên tục

Chúng tôi cũng có một bảng rất hay mà chúng tôi đã cùng nhau lập ra, đó là bạn làm gì ở mỗi phiên bản và bạn học được gì để có thể chuyển sang bước tiếp theo, và bạn nhận được thông tin gì mà bạn có thể đưa vào vòng lặp. Khi bạn chỉ thực hiện định tuyến của mình, bạn có dữ liệu định tuyến chất lượng tốt hơn. Bạn cũng biết loại prompts nào bạn cần xây dựng để cải thiện hệ thống định tuyến.

Điều chỉnh cấu trúc và chu trình xây dựng

Về cơ bản, bạn đang xây dựng cấu trúc của mình cho context engineering và tạo ra flywheel mà bạn muốn, phải không? Trong quá trình trình bày, tôi cũng muốn làm rõ hai điều. Thứ nhất, khi bạn xây dựng với CCCD (Continuous Calibration Continuous Development) trong tâm trí, điều đó không có nghĩa là bạn giải quyết vấn đề một lần và mãi mãi. Có thể bạn đã trải qua V3 và thấy một phân phối dữ liệu mới mà bạn chưa từng hình dung trước đây. Nhưng đây chỉ là một cách để giảm thiểu rủi ro, đó là bạn có đủ thông tin về cách người dùng tương tác với hệ thống của mình trước khi đạt đến điểm tự chủ (autonomy) hoàn toàn.

Tầm quan trọng của hệ thống ghi nhật ký ngầm

Thứ hai, bạn cũng đang xây dựng một hệ thống ghi nhật ký (logging system) ngầm. Nhiều người thường hỏi chúng tôi rằng, "Có evals rồi, tại sao lại cần một thứ như thế này?" Vấn đề khi chỉ xây dựng một loạt chỉ số đánh giá (evaluation metrics) và đưa chúng vào production là các chỉ số đánh giá chỉ phát hiện những lỗi mà bạn đã biết. Nhưng có thể có rất nhiều mẫu hình mới nổi mà bạn chỉ hiểu được sau khi đưa mọi thứ vào production, phải không? Vì vậy, đối với những mẫu hình mới nổi đó, bạn đang tạo ra một khuôn khổ rủi ro thấp để có thể hiểu hành vi người dùng (user behavior) và không bị rơi vào tình huống có hàng tấn lỗi mà bạn phải cố gắng khắc phục tất cả cùng một lúc.

Các phương pháp giới hạn quyền tự chủ của tác nhân

Đây không phải là cách duy nhất để làm điều đó. Có rất nhiều cách khác nhau. Bạn muốn quyết định cách giới hạn quyền tự chủ (autonomy) của mình. Nó có thể dựa trên số lượng hành động mà tác nhân (agent) đang thực hiện, đây là điều chúng tôi làm trong ví dụ này. Nó có thể dựa trên chủ đề. Có một số domain mà việc để hệ thống hoàn toàn tự chủ đối với một số quyết định nhất định có rủi ro khá cao, nhưng đối với một số chủ đề khác thì việc đó lại hoàn toàn ổn. Tùy thuộc vào độ phức tạp của vấn đề, đó là lúc bạn thực sự muốn quản lý sản phẩm (product managers), kỹ sư (engineers) và Chuyên gia lĩnh vực (Subject Matter Experts) của mình cùng thống nhất về cách xây dựng hệ thống và liên tục cải tiến nó. Ý tưởng chỉ đơn giản là hiệu chỉnh hành vi (behavior calibration) và không làm mất lòng tin của người dùng khi bạn thực hiện hiệu chỉnh hành vi đó.

Tôi đoán chúng tôi sẽ liên kết mọi người đến bài đăng thực tế này nếu họ muốn đi sâu hơn. Về cơ bản, bạn sẽ đi qua tất cả các bước này từng bước, với rất nhiều ví dụ. Và ý tưởng ở đây là, như bạn đã nói, mọi thứ về những gì bạn đang mô tả ở đây là về việc làm cho nó liên tục và lặp đi lặp lại, và di chuyển theo tiến trình tự chủ (autonomy) cao hơn, kiểm soát ít hơn. Và ý tưởng thậm chí gọi hiệu chỉnh liên tục (continuous calibration) phát triển liên tục (continuous development) là để truyền đạt rằng đây là một loại quy trình lặp đi lặp lại. Và để làm rõ, việc đặt tên này là để ghi nhận CI/CD (tích hợp liên tục - continuous integration, triển khai liên tục - continuous deployment). >> Chính xác. Và ý tưởng ở đây là đây là phiên bản của CI/CD cho trí tuệ nhân tạo (AI), nơi thay vì chỉ tích hợp vào kiểm thử đơn vị (unit tests) và triển khai liên tục, đó là >> chạy evals, xem xét kết quả, lặp lại trên các chỉ số (metrics) bạn đang theo dõi, tìm ra nơi nó bị lỗi và lặp lại trên điều đó.

Các câu hỏi thường gặp về hiệu chỉnh

Tuyệt vời. Được rồi, một lần nữa, chúng tôi sẽ hướng mọi người đến bài đăng này nếu họ muốn đi sâu hơn. Đó là một cái nhìn tổng quan tuyệt vời. Có bất cứ điều gì khác, trước khi tôi chuyển sang một chủ đề khác về khuôn khổ (framework) này, mà bạn nghĩ là quan trọng để mọi người biết không? >> Tôi nghĩ một trong những câu hỏi phổ biến nhất mà chúng tôi nhận được là: "Làm thế nào để tôi biết liệu tôi có cần chuyển sang giai đoạn tiếp theo hay liệu điều này đã được hiệu chỉnh đủ chưa?" Thực sự không có một cuốn sổ tay quy tắc nào bạn có thể làm theo, nhưng tất cả là về việc giảm thiểu sự bất ngờ, có nghĩa là, giả sử bạn đang hiệu chỉnh mỗi một hoặc hai ngày, và bạn nhận ra rằng bạn không thấy các mẫu phân phối dữ liệu mới, hành vi người dùng (user behavior) của bạn khá nhất quán với cách họ tương tác với hệ thống. Khi đó, lượng thông tin bạn thu được khá thấp, và đó là lúc bạn biết rằng bạn thực sự có thể chuyển sang giai đoạn tiếp theo, phải không? Và tất cả là về vibe vào thời điểm đó. Kiểu như, bạn có biết mình đã sẵn sàng chưa? Bạn không nhận được bất kỳ thông tin mới nào.

Yếu tố ảnh hưởng đến hiệu chỉnh hệ thống

Nhưng điều đó cũng thực sự hữu ích để hiểu rằng đôi khi có những sự kiện có thể hoàn toàn làm hỏng quá trình hiệu chỉnh hệ thống của bạn. Một ví dụ là GPT-4o không còn tồn tại nữa, hoặc nó sẽ bị loại bỏ trong các giao diện lập trình ứng dụng (API)s. Vì vậy, hầu hết các công ty đang sử dụng GPT-4o nên chuyển sang GPT-5, và GPT-5 có những đặc tính rất khác. Đó là lúc hiệu chỉnh (calibration) của bạn lại bị lệch. Bạn muốn quay lại và thực hiện lại quy trình này. Đôi khi, người dùng cũng bắt đầu tương tác với hệ thống khác đi theo thời gian, hoặc hành vi người dùng (user behavior) phát triển ngay cả với các sản phẩm tiêu dùng (consumer products), phải không? Bạn không nói chuyện với ChatGPT theo cách bạn đã nói chuyện cách đây hai năm, chỉ vì khả năng của nó đã tăng lên rất nhiều. Và hơn nữa, mọi người cũng trở nên hào hứng khi các hệ thống này có thể giải quyết một nhiệm vụ; họ muốn thử nó trên các nhiệm vụ khác nữa.

Tương tác của người dùng và sự tiến hóa sản phẩm

Chúng tôi đã xây dựng hệ thống này cho các underwriter vào một thời điểm nào đó, phải không? Underwriting là một nhiệm vụ đau đầu. Có những thỏa thuận, như các đơn xin vay, dài 30 hoặc 40 trang. Và ý tưởng của ngân hàng này là xây dựng một hệ thống có thể giúp các underwriter chọn chính sách và lấy thông tin về ngân hàng để họ có thể phê duyệt các khoản vay, phải không? Trong ba hoặc bốn tháng liền, mọi người đều khá ấn tượng với hệ thống. Các underwriter của chúng tôi thực sự đã báo cáo những lợi ích về thời gian họ dành ra, v.v. Sau 3 tháng, chúng tôi nhận ra rằng họ quá hào hứng với sản phẩm đến nỗi họ bắt đầu hỏi những câu hỏi rất sâu sắc mà chúng tôi chưa từng lường trước. Họ sẽ chỉ ném toàn bộ tài liệu ứng dụng vào hệ thống và hỏi, "Đối với một trường hợp như thế này, các underwriter trước đây đã làm gì?" Đối với người dùng, điều đó chỉ có vẻ là một phần mở rộng tự nhiên của những gì họ đang làm, nhưng việc xây dựng đằng sau nó phải thay đổi đáng kể. Bây giờ bạn cần hiểu "đối với một trường hợp như thế này" có nghĩa là gì trong ngữ cảnh (context) của chính khoản vay. Nó có đề cập đến những người có một mức thu nhập cụ thể, hay nó đề cập đến những người ở một khu vực địa lý (geo) cụ thể, v.v. Và sau đó bạn cần tìm các tài liệu lịch sử, phân tích các tài liệu đó và sau đó nói với họ, "Okay, đây là những gì nó trông giống như," thay vì chỉ nói rằng có một chính sách X, Y, Z và bạn muốn tìm kiếm chính sách đó. Vì vậy, một cái gì đó có vẻ rất tự nhiên đối với một người dùng cuối (end user) có thể rất khó để xây dựng dưới vai trò một nhà xây dựng sản phẩm (product builder), và bạn thấy rằng hành vi người dùng (user behavior) cũng phát triển theo thời gian, và đó là lúc bạn biết rằng bạn muốn quay lại và hiệu chỉnh lại (recalibrate).

Các khái niệm bị đánh giá quá cao và đánh giá thấp trong AI

Bạn nghĩ điều gì đang bị đánh giá quá cao (overhyped) trong không gian trí tuệ nhân tạo (AI space) hiện nay, và quan trọng hơn nữa, bạn nghĩ điều gì đang bị đánh giá thấp (underhyped)?

Như tôi đã nói, tôi rất lạc quan về nhiều điều đang diễn ra trong trí tuệ nhân tạo (AI). Vì vậy, tôi sẽ không nói là quá thổi phồng, nhưng tôi cảm thấy khái niệm về đa tác nhân (multi-agents) bị hiểu lầm. Mọi người có quan niệm rằng, "Tôi có một vấn đề cực kỳ phức tạp. Bây giờ tôi sẽ chia nhỏ nó thành: này, bạn là tác nhân này, hãy lo việc này; bạn là tác nhân kia, hãy lo việc kia." Và bây giờ, nếu tôi bằng cách nào đó kết nối tất cả các tác nhân này, họ nghĩ rằng họ đang ở thiên đường tác nhân (agent utopia). Không phải lúc nào cũng có những hệ thống đa tác nhân (multi-agent systems) được xây dựng thành công rực rỡ; không nghi ngờ gì về điều đó. Nhưng tôi cảm thấy phần lớn vấn đề nằm ở việc bạn giới hạn các cách thức mà hệ thống có thể đi chệch hướng như thế nào. Ví dụ, nếu bạn đang xây dựng một tác nhân giám sát (supervisor agent) và có các tác nhân phụ (sub-agents) thực hiện công việc cho tác nhân giám sát, đó là một mô hình rất thành công. Nhưng việc đến với ý tưởng rằng tôi sẽ chia trách nhiệm dựa trên chức năng và bằng cách nào đó mong đợi tất cả chúng hoạt động cùng nhau theo một loại giao thức tin đồn (gossip protocol) nào đó – điều đó bị hiểu lầm trầm trọng là có thể làm được. Tôi không nghĩ rằng các phương pháp xây dựng hiện tại và khả năng mô hình (model capabilities) hiện tại đã đủ để xây dựng các loại ứng dụng đó. Tôi cảm thấy điều đó bị hiểu lầm hơn là bị đánh giá quá cao (overrated).

Về đánh giá thấp (underrated). Tôi nghĩ có lẽ khó tin, nhưng tôi vẫn cảm thấy tác nhân lập trình (coding agents) bị đánh giá thấp (underrated) theo nghĩa là bạn có thể lên Twitter và Reddit và thấy rất nhiều cuộc trò chuyện về tác nhân lập trình. Nhưng khi nói chuyện với một kỹ sư (engineer) ở bất kỳ công ty ngẫu nhiên nào, đặc biệt là bên ngoài Bay Area, bạn có thể thấy mức độ tác động mà các tác nhân lập trình này có thể tạo ra và mức độ thâm nhập còn rất thấp. Vì vậy, tôi cảm thấy năm 2025 và 2026 sẽ là những năm đáng kinh ngạc để tối ưu hóa tất cả các quy trình này, và tôi cảm thấy điều đó sẽ tạo ra rất nhiều giá trị với trí tuệ nhân tạo (AI).

Điều đó thực sự thú vị ở điểm đầu tiên. Vì vậy, ý tưởng ở đây là bạn có lẽ sẽ thành công hơn khi xây dựng và sử dụng một tác nhân (agent) có khả năng tự phân chia công việc thành các tác nhân phụ (sub-agent splitting), so với việc sử dụng một loạt tác nhân Codex (Codex agents) mà bạn giao "bạn làm việc này, bạn làm việc kia". Bạn có thể có các tác nhân (agents) để làm những việc này và bạn với tư cách là con người có thể điều phối chúng, hoặc bạn có thể có một tác nhân lớn hơn sẽ điều phối tất cả những thứ này. Nhưng việc để các tác nhân (agents) giao tiếp theo kiểu peer-to-peer protocol và đặc biệt là thực hiện điều này trong một trường hợp sử dụng (use case) kiểu hỗ trợ khách hàng (customer support) là vô cùng khó để kiểm soát loại tác nhân nào đang trả lời khách hàng của bạn, bởi vì bạn cần phải điều chỉnh hàng rào bảo vệ (guardrails) của mình ở khắp mọi nơi và những thứ tương tự.

Vấn đề thiết kế và giải quyết điểm đau

Vâng. Được rồi. Các lựa chọn tuyệt vời. Được rồi, Ash, bạn có gì? >> Tôi có thể nói email không? Liệu tôi có bị hủy hoại (cancelled) không? >> Ở hạng mục nào? Chúng thuộc nhóm nào? >> Đánh giá quá cao (Overrated). >> Đánh giá quá cao. Được rồi, cứ nói đi. Chúng tôi sẽ không để bạn bị hủy hoại (cancelled) đâu. >> À, chỉ đùa thôi. Tôi nghĩ evals bị hiểu lầm. Chúng rất quan trọng, mọi người. Tôi không nói là chúng không quan trọng. Nhưng tôi nghĩ rằng việc cứ nhảy hết công cụ này đến công cụ khác và học một công cụ mới là đánh giá quá cao (overrated). Tôi vẫn theo lối cũ (old school) và cảm thấy bạn thực sự cần phải bị ám ảnh bởi vấn đề kinh doanh (business problem) mà bạn đang cố gắng giải quyết. Trí tuệ nhân tạo (AI) chỉ là một công cụ. Hãy cố gắng nghĩ theo cách đó. Tất nhiên, bạn cần phải học hỏi những điều mới nhất và tuyệt vời nhất, nhưng đừng quá ám ảnh với việc xây dựng quá nhanh. Việc xây dựng ngày nay thực sự rất rẻ.

Thiết kế (Design) thì đắt đỏ hơn. Việc thực sự suy nghĩ về sản phẩm của bạn, những gì bạn sẽ xây dựng, liệu nó có thực sự giải quyết được điểm đau (pain point) hay không – đó mới là điều có giá trị hơn rất nhiều ngày nay và sẽ chỉ càng đúng hơn trong tương lai gần, phải không? Vì vậy, việc thực sự ám ảnh về vấn đề và thiết kế của bạn là đánh giá thấp (underrated), còn việc xây dựng một cách máy móc (rote building) thì tôi nghĩ là đánh giá quá cao (overrated).

Tầm nhìn AI đến năm 2026: Tác nhân chủ động

Tuyệt vời. Được rồi. Một câu hỏi tương tự từ góc độ sản phẩm (product point of view). Bạn nghĩ một năm tới của trí tuệ nhân tạo (AI) sẽ trông như thế nào? Hãy cho chúng tôi một tầm nhìn (vision) về nơi bạn nghĩ mọi thứ sẽ đi đến, chẳng hạn như vào cuối năm 2026. >> Vâng, tôi cảm thấy có rất nhiều hứa hẹn về các tác nhân nền (background agents) hoặc tác nhân chủ động (proactive agents) – những người về cơ bản sẽ hiểu rõ hơn quy trình làm việc (workflow) của bạn. Nếu bạn nghĩ về việc trí tuệ nhân tạo (AI) đang thất bại trong việc tạo ra giá trị ở đâu ngày nay, chủ yếu là do nó không hiểu ngữ cảnh (context). Và lý do nó không hiểu ngữ cảnh là vì nó không được kết nối vào đúng những nơi công việc thực sự đang diễn ra, phải không? Và khi bạn làm điều này nhiều hơn, bạn có thể cung cấp cho tác nhân (agent) nhiều ngữ cảnh hơn, và sau đó nó bắt đầu nhìn thế giới xung quanh bạn và hiểu đâu là tập hợp các chỉ số (metrics) mà bạn đang tối ưu hóa hoặc loại hoạt động nào bạn đang cố gắng thực hiện. Đó là một phần mở rộng rất dễ dàng từ đó để thực sự đạt được nhiều hơn từ nó và sau đó để tác nhân nhắc nhở bạn.

Tác nhân thông minh và Trải nghiệm đa phương thức trong tương lai

Chúng ta đã và đang làm điều này với ChatGPT Pulse, cung cấp cho bạn bản cập nhật hàng ngày về những điều bạn có thể quan tâm. Việc có một công cụ như vậy thực sự rất hữu ích để khơi gợi ý tưởng trong đầu bạn, theo kiểu "Ồ, đây là điều mình chưa nghĩ đến, có lẽ nó tốt đấy." Và khi bạn mở rộng điều này sang các tác vụ phức tạp hơn, như một tác nhân lập trình nói rằng: "Được thôi, tôi đã sửa năm ticket của bạn và đây là các patch, hãy xem lại chúng vào đầu ngày nhé." Tôi cảm thấy điều đó sẽ cực kỳ hữu ích và tôi coi đó là một hướng đi mạnh mẽ mà các sản phẩm sẽ xây dựng vào năm 2026. Thật tuyệt vời! Về cơ bản, các tác nhân sẽ dự đoán những gì bạn muốn làm, đi trước bạn một bước và nói: "Tôi đã giải quyết những vấn đề này cho bạn," hoặc "Tôi nghĩ điều này sẽ làm sập trang web của bạn, có lẽ bạn nên sửa nó ngay đây," hoặc "Tôi thấy sự tăng đột biến ở đây, hãy refactor cơ sở dữ liệu của chúng ta." Thật kinh ngạc, một thế giới thật đáng kinh ngạc.

Ash, bạn có điều gì muốn chia sẻ không? Tôi hoàn toàn ủng hộ các trải nghiệm đa phương thức vào năm 2026. Tôi nghĩ chúng ta đã đạt được những tiến bộ đáng kể vào năm 2025, không chỉ về khả năng tạo sinh mà còn về khả năng hiểu. Cho đến nay, mô hình ngôn ngữ lớn (LLM) là các mô hình được sử dụng phổ biến nhất của chúng ta. Tuy nhiên, với tư cách là con người, chúng ta là những sinh vật đa phương thức. Ngôn ngữ có lẽ là một trong những dạng tiến hóa cuối cùng của chúng ta. Khi ba chúng ta đang nói chuyện, tôi nghĩ chúng ta liên tục nhận được rất nhiều tín hiệu, ví dụ như "Ồ, Lenny đang gật đầu, vậy có lẽ tôi nên đi theo hướng này," hoặc "Lenny có vẻ chán rồi, để tôi ngừng nói." Vì vậy, có một chuỗi suy nghĩ đằng sau chuỗi suy nghĩ của bạn, và bạn liên tục điều chỉnh nó bằng ngôn ngữ. Chiều biểu đạt đó chưa được khám phá tốt. Nếu chúng ta có thể xây dựng những trải nghiệm đa phương thức tốt hơn, điều đó sẽ đưa chúng ta đến gần hơn với sự phong phú của cuộc trò chuyện giống con người. Và tôi nghĩ, với các loại mô hình hiện có, có rất nhiều tác vụ nhàm chán phù hợp với trí tuệ nhân tạo (AI). Nếu khả năng hiểu đa phương thức được cải thiện, sẽ có rất nhiều tài liệu viết tay và các tệp PDF thực sự lộn xộn mà ngay cả những mô hình tốt nhất hiện nay cũng không thể phân tích được. Nếu điều đó khả thi, sẽ có rất nhiều dữ liệu mà chúng ta có thể khai thác.

Tuyệt vời. Tôi vừa thấy Demis từ DeepMind AI, Google, hay bất cứ tên gọi nào của họ, nói về điều này. Anh ấy nghĩ rằng đây sẽ là một phần lớn trong định hướng của họ, kết hợp công việc về mô hình hình ảnh, LLM và cả các mô hình thế giới của họ, như Genie, tôi nghĩ đó là tên của nó. Điều đó sẽ tạo nên một thời điểm điên rồ.

Kỹ năng phát triển sản phẩm AI: Tư duy, Khả năng phán đoán và Thị hiếu

Được rồi, câu hỏi cuối cùng. Nếu ai đó muốn trở nên giỏi hơn trong việc xây dựng sản phẩm AI, bạn nghĩ họ nên tập trung phát triển một hoặc hai kỹ năng nào?

Tôi nghĩ chúng ta đã đề cập đến một loạt các thực hành tốt nhất cho sản phẩm AI, đó là bắt đầu nhỏ, cố gắng đẩy nhanh các lặp lại và xây dựng một chu trình tăng trưởng (flywheel) cùng với tất cả những điều đó. Nhưng một lần nữa, nếu bạn nhìn ở cấp độ cao, đối với bất kỳ ai xây dựng sản phẩm ngày nay, như tôi đã nói, việc triển khai sẽ cực kỳ rẻ trong vài năm tới. Vì vậy, hãy thực sự trau dồi thiết kế, khả năng phán đoán và thị hiếu của bạn. Và nói chung, nếu bạn đang xây dựng một lộ trình sự nghiệp, tôi cảm thấy trong vài năm qua, những năm đầu tiên của bạn, khoảng hai đến ba năm đầu tiên xây dựng lộ trình sự nghiệp, luôn tập trung vào các cơ chế thực thi và tất cả những điều đó. Và bây giờ chúng ta có AI có thể giúp bạn nhanh chóng nắm bắt công việc. Sau đó, tôi nghĩ sau vài năm, công việc của mọi người đều trở thành về thị hiếu của bạn, khả năng phán đoán của bạn và những gì là phẩm chất độc đáo của bạn. Tôi nghĩ hãy tập trung vào phần đó và cố gắng tìm ra cách bạn có thể mang lại một quan điểm như vậy. Điều đó không có nghĩa là bạn phải lớn tuổi hơn đáng kể hoặc có nhiều năm kinh nghiệm.

Chúng tôi gần đây đã thuê một người và chúng tôi sử dụng một ứng dụng rất phổ biến để theo dõi các tác vụ của mình, đúng không? Chúng tôi đã sử dụng nó trong nhiều năm và phải trả một khoản phí đăng ký cao cho nó. Và anh chàng này chỉ đến cuộc họp với ứng dụng tự viết của riêng mình. Anh ấy đã hướng dẫn chúng tôi sử dụng tất cả và nói: "Được rồi, hãy bắt đầu sử dụng cái này." Tôi nghĩ chủ động và tinh thần làm chủ đó, khả năng thực sự suy nghĩ lại về trải nghiệm, là điều sẽ khiến mọi người trở nên khác biệt. Tôi không bỏ qua thực tế rằng các ứng dụng tự viết có chi phí bảo trì cao và có thể khi chúng tôi mở rộng quy mô công ty, chúng tôi sẽ phải thay thế nó hoặc phải nghĩ ra những cách tiếp cận tốt hơn. Nhưng với việc chúng tôi là một công ty quy mô nhỏ hiện tại, tôi thực sự bị sốc vì tôi chưa bao giờ nghĩ về điều đó. Nếu bạn đã quen làm việc theo một cách nhất định, bạn sẽ liên tưởng chi phí với việc xây dựng. Và tôi cảm thấy những người lớn lên trong thời đại này có chi phí thấp hơn nhiều trong tâm trí; họ không ngại xây dựng một cái gì đó và thực hiện nó. Họ cũng rất nhiệt tình thử các công cụ AI mới. Đó có lẽ là lý do tại sao các sản phẩm AI gặp vấn đề giữ chân người dùng, vì mọi người quá hào hứng thử các công cụ AI mới và tất cả những điều đó. Nhưng về cơ bản, việc có chủ động và tinh thần làm chủ – và tôi nghĩ đây cũng sẽ là sự kết thúc của kỷ nguyên công việc bận rộn nhưng ít giá trị, đúng không? Bạn không thể ngồi một góc làm một việc không tạo ra sự khác biệt cho công ty. Bạn thực sự cần phải suy nghĩ về các quy trình làm việc đầu cuối, cách bạn có thể tạo ra nhiều tác động hơn. Tôi nghĩ tất cả những điều đó sẽ cực kỳ quan trọng.

Tác động của AI đến lực lượng lao động

Điều đó làm tôi nhớ lại, tôi vừa có Jason Lumprick trên podcast. Anh ấy rất thông minh về bán hàng, tiếp cận thị trường (Go-to-Market), điều hành Zaster, và anh ấy đã thay thế toàn bộ đội ngũ sales của mình bằng các tác nhân. Anh ấy có 10 nhân viên sales, bây giờ anh ấy có 1,2 người và 20 tác nhân. Một trong các tác nhân chỉ theo dõi các bản cập nhật của mọi người lên Salesforce và tự động cập nhật chúng dựa trên các cuộc gọi của họ. Một trong những nhân viên sales đã nói: "Được rồi, tôi bỏ việc." Và hóa ra anh ta không thực sự làm gì cả. Anh ta chỉ ngồi chơi xơi nước. Và anh ta nghĩ: "Được rồi, cái này sẽ phát hiện ra mình. Mình phải rời khỏi đây." Đúng vậy. Vì vậy, theo quan điểm của bạn, việc ngồi chơi xơi nước sẽ khó khăn hơn. Tôi nghĩ điều đó thực sự đúng.

"Nỗi đau là lợi thế cạnh tranh mới"

Vâng. Tôi nghĩ để bổ sung thêm, sự kiên trì cũng là một điều cực kỳ giá trị, đặc biệt khi thông tin nằm trong tầm tay của bất kỳ ai muốn xây dựng thứ gì đó, thậm chí còn nhiều hơn so với thập kỷ trước. Bạn có thể học bất cứ điều gì chỉ sau một đêm và trở thành kiểu người như Iron Man. Vì vậy, tôi cảm thấy việc có sự kiên trì và trải qua nỗi đau khi học hỏi, triển khai và hiểu điều gì hiệu quả và điều gì không, cũng như khi bạn trải qua nỗi đau phát triển nhiều cách tiếp cận khác nhau rồi giải quyết vấn đề, tôi cảm thấy đó sẽ là lợi thế cạnh tranh thực sự của một cá nhân. Tôi thích gọi nó là "Nỗi đau là lợi thế cạnh tranh mới," nhưng tôi cảm thấy điều đó cực kỳ hữu ích, đặc biệt khi bạn đang xây dựng các sản phẩm AI.

Hãy nói thêm về điều này. Tôi yêu khái niệm này. Nỗi đau là lợi thế cạnh tranh mới. Còn gì nữa không? Vâng, tôi cảm thấy với tư cách là một công ty, những công ty thành công hiện nay đang xây dựng trong bất kỳ lĩnh vực mới nào, họ thành công không phải vì họ là người đầu tiên ra mắt thị trường hay họ có một tính năng hấp dẫn mà nhiều khách hàng yêu thích hơn. Họ đã trải qua nỗi đau để hiểu những yếu tố không thể thỏa hiệp nào và đánh đổi chúng một cách chính xác với những tính năng hoặc khả năng của mô hình mà họ có thể sử dụng để giải quyết vấn đề đó. Đây không phải là một quá trình đơn giản, đúng không? Không có sách giáo khoa nào để làm điều này hay một lộ trình đã biết nào để đến đây. Vì vậy, phần lớn nỗi đau mà tôi đang nói đến chỉ là việc trải qua lặp lại kiểu như "được rồi, hãy thử cái này, và nếu cái này không hiệu quả, hãy thử cái kia." Và loại kiến thức mà bạn xây dựng trong toàn bộ tổ chức hoặc từ kinh nghiệm sống của bạn, tôi cảm thấy nỗi đau đó chính là thứ chuyển hóa thành lợi thế cạnh tranh của công ty, đúng không? Đây có thể là một sản phẩm đánh giá hoặc một thứ gì đó bạn đã xây dựng, và tôi cảm thấy điều đó sẽ là yếu tố thay đổi cuộc chơi.

Điều đó thật tuyệt vời, giống như biến than thành kim cương. Đúng vậy. Được rồi, tôi cảm thấy chúng ta đã làm rất tốt trong việc giúp mọi người tránh được một số vấn đề lớn nhất mà họ thường gặp phải khi xây dựng sản phẩm AI. Chúng ta đã đề cập đến rất nhiều cạm bẫy và cách để thực hiện đúng. Trước khi đến với vòng hỏi nhanh rất thú vị của chúng ta, bạn có muốn chia sẻ thêm điều gì không? Có điều gì bạn muốn để lại cho người nghe không?

Say mê khách hàng và vấn đề: Bí quyết thành công với AI

Hãy say mê khách hàng của bạn. Hãy say mê vấn đề. AI chỉ là một công cụ, và hãy đảm bảo rằng bạn thực sự hiểu quy trình làm việc của mình. 80% cái gọi là kỹ sư AI, Quản lý Sản phẩm AI dành thời gian để thực sự hiểu rất rõ quy trình làm việc của họ. Họ không xây dựng những mô hình hay quy trình làm việc hào nhoáng và tuyệt vời nhất. Họ thực sự đi sâu vào chi tiết, tìm hiểu hành vi và dữ liệu của khách hàng. Và bất cứ khi nào một kỹ sư phần mềm chưa từng làm AI trước đây nghe cụm từ "hãy nhìn vào dữ liệu của bạn," tôi nghĩ đó là một sự giác ngộ lớn đối với họ, nhưng điều đó luôn đúng. Bạn cần phải đến đó. Hãy nhìn vào dữ liệu của bạn, hiểu người dùng của bạn, và đó sẽ là một yếu tố tạo nên sự khác biệt rất lớn.

Đó là một cách tuyệt vời để kết thúc. AI không phải là câu trả lời. Nó là một công cụ để giải quyết vấn đề. Với điều đó, chúng ta đã đến với vòng hỏi nhanh rất thú vị của chúng ta. Tôi có năm câu hỏi cho cả hai bạn. Các bạn đã sẵn sàng chưa? Yay. Vâng. Được rồi. Cả hai bạn đều có thể trả lời. Các bạn có thể chọn một câu mà bạn muốn trả lời. Tùy các bạn. Hai hoặc ba cuốn sách nào mà bạn thấy mình thường xuyên giới thiệu nhất cho người khác?

Vòng hỏi nhanh: Sách khuyến nghị

Đối với tôi, đó là cuốn sách có tên "Khi Hơi Thở Hóa Thinh Không" (When Breath Becomes Air), Lenny ạ. Nó được viết bởi Paul Kalanithi. Tôi nghĩ anh ấy là một bác sĩ phẫu thuật thần kinh gốc Ấn Độ, được chẩn đoán mắc bệnh ung thư phổi ở tuổi 31 hoặc 32, và toàn bộ cuốn sách là hồi ký của anh ấy, được viết sau khi anh ấy được chẩn đoán. Nó thực sự rất đẹp, đặc biệt là vì tôi đọc nó trong thời kỳ dịch bệnh và tất cả những gì chúng tôi muốn làm trong thời kỳ đó là được sống. Có rất nhiều trích dẫn hay trong cuốn sách, nhưng tôi nhớ một trong số đó, anh ấy đã tranh luận chống lại một câu nói rất phổ biến của Socrates: "Cuộc đời không được xem xét thì không đáng sống," hay đại loại như vậy. Điều đó có nghĩa là bạn thực sự cần phải suy nghĩ về những lựa chọn của mình. Bạn cần phải hiểu giá trị, sứ mệnh của mình và tất cả những điều đó. Và Paul nói: "Nếu cuộc đời không được xem xét thì không đáng sống, vậy cuộc đời chưa sống có đáng để xem xét không?" Điều đó có nghĩa là bạn có đang dành quá nhiều thời gian chỉ để hiểu sứ mệnh và mục đích của mình mà quên mất việc sống không? Và tôi nghĩ tất cả những ai đang sống trong kỷ nguyên AI và xây dựng, liên tục trải qua giai đoạn tái tạo bản thân, cần phải tạm dừng và sống một chút. Tôi đoán họ cần ngừng đánh giá cuộc đời quá nhiều. Tôi định nói rằng đó là nơi tâm trí tôi hướng tới. Hãy tạo một vài email cho cuộc đời bạn. Ôi Chúa ơi, chúng ta đã đi quá xa rồi. Vâng. Đúng vậy. Đúng vậy. Đó là cuốn sách yêu thích của tôi.

Tôi thích sách khoa học viễn tưởng hơn. Vì vậy, tôi thực sự thích loạt truyện "Tam Thể" (Three Body Problem). Đó là một bộ ba cuốn sách. Nó có các yếu tố khoa học viễn tưởng vĩ đại hơn, sự sống ngoài trái đất và cách nó tác động đến quá trình ra quyết định của con người. Nó cũng có các yếu tố địa chính trị và tầm quan trọng hoặc giá trị của khoa học cơ bản đối với sự tiến bộ của loài người. Và khi điều đó bị đình trệ, nó không dễ nhận thấy trong cuộc sống hàng ngày, nhưng nó có thể gây ra những hậu quả tàn khốc. Vì vậy, tôi cảm thấy AI giúp đỡ trong những lĩnh vực này, ví dụ, sẽ cực kỳ quan trọng, và cuốn sách đó là một ví dụ hay về điều gì có thể xảy ra nếu không có AI.

Đề xuất sách Sci-fi

Hoàn toàn đồng ý, tôi thực sự yêu thích. Có lẽ đây là bộ sách sci-fi yêu thích của tôi, hoặc thậm chí là cả series. Nó có ba quyển, nhân tiện, tôi phải đọc hết cả ba. Tôi thấy rằng nó chỉ thực sự hay kể từ khoảng giữa quyển thứ hai. Vì vậy, nếu ai đó đã thử đọc và cảm thấy "chuyện quái gì đang xảy ra ở đây vậy", hãy cứ tiếp tục đọc đến giữa quyển thứ hai, rồi bạn sẽ thấy nó cực kỳ ấn tượng.

Vâng. Nếu bạn yêu thích sci-fi và bạn là người làm về trí tuệ nhân tạo (AI), bạn nhất định phải đọc cuốn sách có tên 'A Fire Upon the Deep' của Vernon Vinge. Ừm. Hãy tìm đọc nó. Thật đáng kinh ngạc. Tôi thấy Noah Smith trên newsletter của anh ấy đã giới thiệu cuốn sách này, và có cả các phần tiếp theo của nó, nhưng đây là cuốn quan trọng nhất. Nó thật phi thường, và thực ra nó nói về Trí tuệ tổng hợp nhân tạo (AGI) và super intelligence cùng tất cả những thứ đó, nó chỉ đơn giản là quá hoành tráng mà ít người biết đến. Cảm ơn bạn. Vậy đó, tôi trả lại bạn một cái.

Đề xuất phim, TV Show và Game

Được rồi, câu hỏi tiếp theo. Bộ phim hay chương trình truyền hình yêu thích gần đây mà bạn thực sự yêu thích là gì?

Tôi bắt đầu xem lại 'Silicon Valley', và tôi nghĩ nó vẫn rất đúng. Nó vượt thời gian. Mọi thứ đang lặp lại. Bất cứ ai đã xem nó vài năm trước nên xem lại, và bạn sẽ thấy nó giống một cách kỳ lạ với mọi thứ đang diễn ra hiện tại với làn sóng trí tuệ nhân tạo (AI). Đó là một ý hay để xem lại. Tôi thích việc toàn bộ công việc kinh doanh của họ là một thuật toán để nén, giống như một thuật toán nén. Nó giống như một tiền thân của mô hình ngôn ngữ lớn (LLM) theo một cách nào đó nhỏ bé. Rất tốt. Được rồi, GT, bạn có gì? À, tôi sẽ lạc đề một chút và nói rằng không phải một bộ phim hay chương trình truyền hình, mà là một trò chơi tôi vừa chơi gần đây có tên 'Expedition 33'. Nó không liên quan gì đến trí tuệ nhân tạo (AI), nhưng nó là một trò chơi được làm cực kỳ, cực kỳ tốt về mặt gameplay, hoặc giống như bộ phim và câu chuyện cũng như âm nhạc. Nó thật tuyệt vời. Tôi rất thích việc bạn có thời gian để chơi game. Đó là một dấu hiệu tuyệt vời. Tôi rất thích điều đó. Vậy là, một cái nhìn cởi mở. Tôi chỉ tưởng tượng bạn không làm gì khác ngoài coding và... Vâng, thực sự rất khó để tìm thời gian cho việc đó. Tốt quá. Đó là một dấu hiệu tốt. Tôi rất vui khi nghe điều này.

Các sản phẩm và công cụ yêu thích

Được rồi. Sản phẩm yêu thích mà bạn vừa khám phá gần đây và thực sự yêu thích là gì?

Đối với tôi, đó là Whisper Flow. Tôi nghĩ mình đã sử dụng nó khá nhiều và không ngờ lại cần nó đến vậy. Phần tuyệt vời nhất là nó là một công cụ phiên âm theo khái niệm, có nghĩa là nếu bạn vào Codex và bắt đầu sử dụng Whisper Flow, nó sẽ bắt đầu nhận dạng các biến và tất cả những thứ đó, và nó cực kỳ liền mạch trong việc chuyển từ phiên âm sang chỉ dẫn. Bạn có thể nói điều gì đó như "Hôm nay tôi rất phấn khích!", thêm ba dấu chấm than, và nó sẽ tự động chuyển đổi, thêm ba dấu chấm than đó thay vì bạn phải viết "thêm ba dấu chấm than". Tôi nghĩ điều đó khá tuyệt vời. Nếu bạn chưa dùng nó, bạn nên thử. Tôi sẽ quảng cáo một chút: hãy dùng Whisper Flow miễn phí trong cả một năm miễn phí trong một năm bằng cách đăng ký hàng năm newsletter của tôi. Và đó là cách tôi có quyền truy cập vào nó. Lenny, Đúng vậy. Tôi nghĩ tôi đã giới thiệu ưu đãi này. Tôi nghĩ mọi người không thực sự hiểu được điều này tuyệt vời đến mức nào. Họ nói: "Không thể nào. Điều này là thật ư?" Nó là thật đấy. Và còn 18 sản phẩm khác nữa. Hãy truy cập Lenny's productbass.com để kiểm tra. Tiếp theo. K. Tuyệt vời. Tôi thực sự là người rất coi trọng Năng suất (Productivity). Tôi liên tục thử nghiệm các công cụ CLI mới và những thứ có thể giúp tôi làm việc nhanh hơn. Vì vậy, tôi cảm thấy Raycast thật tuyệt vời. Tôi đã khám phá ra tất cả những phím tắt mới mà bạn có thể sử dụng để mở các thứ khác nhau, nhập các lệnh phím tắt và những thứ tương tự. Và Caffeinate là một thứ khác mà tôi mới được đồng đội giới thiệu gần đây. Nó giúp ngăn máy Mac của bạn chuyển sang chế độ ngủ. Vì vậy, bạn có thể chạy tác vụ Codex rất dài này trong khoảng bốn hoặc năm giờ cục bộ. Hãy để nó xây dựng mọi thứ và sau đó bạn có thể thức dậy và nói "được rồi, cái này tốt đấy. Tôi thích nó." Nghe thật buồn cười. Sự kết hợp giữa Codex và Caffeinate. Các bạn, các bạn cần phải sử dụng nó. Giống như tự mình xây dựng nó vậy. Một phiên bản trí tuệ nhân tạo (AI) mở của nó hoặc tác nhân Codex nên giữ cho máy Mac của bạn không ngủ. Thật buồn cười. Nhân tiện, Raycast cũng là một phần của Lenny's product pass. Một năm dùng Raycast miễn phí. Chúng tôi, chúng tôi, Lenny đã không nói cho chúng tôi biết về những người này. Đây thực sự là những sản phẩm yêu thích của chúng tôi. Đây chỉ là hai trong số 19 sản phẩm. Không có Caffeinate dù. Tôi không biết nó có phải trả phí không. Được rồi, chúng ta hãy tiếp tục.

Châm ngôn sống

Bạn có một châm ngôn sống yêu thích nào mà bạn thường quay lại với nó trong công việc hay cuộc sống không?

Đối với tôi, tôi nghĩ đây là điều bố tôi đã nói với tôi khi tôi còn nhỏ và nó luôn in sâu trong tâm trí, đó là, "Họ nói điều đó không thể thực hiện được, nhưng kẻ ngốc không biết điều đó, vì vậy anh ta vẫn làm." Tôi nghĩ hãy đủ ngốc nghếch để tin rằng bạn có thể làm bất cứ điều gì nếu bạn dốc hết tâm huyết. Đặc biệt là bây giờ bởi vì bạn có quá nhiều dữ liệu trong tay có thể chỉ ra rằng bạn có thể sẽ không thành công. Với bao nhiêu podcast đã đạt hơn một nghìn người đăng ký, hoặc bao nhiêu startup đã đạt hơn 1 triệu doanh thu định kỳ hàng năm (ARR), và luôn có dữ liệu để cho bạn thấy rằng bạn sẽ không thành công, nhưng đôi khi hãy cứ ngốc nghếch và tiếp tục làm. Tuyệt vời. Vâng, đối với tôi, tôi là người hay suy nghĩ quá nhiều, vì vậy tôi thực sự thích câu nói này của Steve Jobs rằng "bạn chỉ có thể kết nối các dấu chấm khi nhìn lại phía sau." Vì vậy, rất nhiều lần có vô số lựa chọn, và bạn không thực sự biết lựa chọn tối ưu để chọn, nhưng cuộc sống hoạt động theo những cách mà bạn thực sự có thể nhìn lại và nói, "Ồ, những điều này thực sự đẹp đẽ theo cách tôi sẽ chuyển đổi." Vì vậy, tôi cảm thấy điều đó cực kỳ hữu ích trong việc, bạn biết đấy, tiếp tục tiến lên, tiếp tục thử nghiệm.

Ngưỡng mộ lẫn nhau

Câu hỏi cuối cùng. Bất cứ khi nào tôi có hai khách mời trên podcast cùng một lúc, tôi đều thích hỏi câu này. Điều gì ở người kia mà bạn ngưỡng mộ?

Với Kir, tôi nghĩ anh ấy khá điềm tĩnh và rất thực tế. Anh ấy luôn là người lắng nghe tôi. Tôi có thể ném hàng tấn ý tưởng vào anh ấy và anh ấy luôn đưa ra được, anh ấy có khả năng dự đoán những loại vấn đề có thể phát sinh. Và anh ấy cực kỳ tốt bụng, anh ấy để công việc của mình nói lên tất cả thay vì nói nhiều, tôi đoán vậy. Nhưng nếu phải chọn một điều, tôi nghĩ anh ấy là người chồng tuyệt vời nhất. Điều mà ít người biết đến. Vâng. Chúng tôi đã kết hôn được bốn năm và đó là bốn năm đẹp nhất trong cuộc đời tôi. Ồ, wow. Được rồi. Làm thế nào bạn có thể theo kịp điều đó? Vâng, thực sự rất khó để theo kịp điều đó. Tôi phải nói rằng tôi cực kỳ may mắn khi được làm việc với những người thực sự thông minh trong các startup tuyệt vời ở Thung lũng Silicon. Và tôi cảm thấy điều độc đáo mà Ashwaryia nổi bật hơn bất kỳ người thông minh nào khác mà tôi từng làm việc cùng là cô ấy có khả năng truyền đạt và giải thích mọi thứ một cách rất dễ hiểu và dễ nắm bắt. Và điều đó kết hợp với sự kiên trì thì cực kỳ hữu ích, đặc biệt là trong thế giới trí tuệ nhân tạo (AI) đang phát triển nhanh chóng này mà chúng ta đang sống. Theo nghĩa là có rất nhiều điều mới xuất hiện, nó cảm thấy choáng ngợp, nhưng khi tôi nghe cô ấy nói về việc "đây là cách bạn hiểu toàn bộ điều này, đây là nơi nó kết nối," tôi cảm thấy "ồ, điều đó thật đơn giản, tôi cũng có thể làm được điều đó." Vì vậy, cô ấy trao quyền cho rất nhiều người bằng cách đơn giản hóa mọi thứ và, bạn biết đấy, giải thích mọi thứ theo cách dễ hiểu nhất. Vì vậy, tôi cảm thấy đó là một phẩm chất đáng kinh ngạc. Tuyệt vời. Thật ngọt ngào. Tôi phải làm điều này mọi lúc. Tôi cần nhiều sự đồng ý hơn cho điều đó, thật tuyệt vời. Được rồi.

Liên hệ và Tài nguyên

Những câu hỏi cuối cùng. Mọi người có thể tìm thấy những gì bạn đang làm ở đâu? Tìm bạn trực tuyến. Chia sẻ liên kết khóa học của bạn và làm thế nào thính giả có thể hữu ích cho bạn?

Tôi viết khá nhiều trên LinkedIn. Vì vậy, nếu bạn muốn lắng nghe những người thực dụng đã trực tiếp làm việc với sản phẩm trí tuệ nhân tạo (AI) và những gì họ đang thấy, bạn có thể theo dõi công việc của tôi. Chúng tôi cũng có một kho lưu trữ GitHub với khoảng 20 nghìn stars, và kho lưu trữ đó hoàn toàn là về các tài nguyên tốt để học trí tuệ nhân tạo (AI). Nó hoàn toàn miễn phí, và nếu bạn thích những gì chúng tôi đã nói hôm nay, chúng tôi cũng có một khóa học rất phổ biến. Chúng tôi sẽ để lại một liên kết đến khóa học đó về việc xây dựng sản phẩm trí tuệ nhân tạo (AI) sẵn sàng cho doanh nghiệp (enterprise-ready). Và khóa học này chủ yếu nói về việc loại bỏ các tư duy cũ và theo cách tiếp cận ưu tiên vấn đề thay vì cách tiếp cận ưu tiên công cụ hoặc ưu tiên sự cường điệu. Vì vậy, bạn cũng có thể kiểm tra khóa học đó. Và nếu bạn không muốn tham gia khóa học, chúng tôi viết rất nhiều. Chúng tôi cung cấp rất nhiều tài nguyên miễn phí. Chúng tôi có các buổi học miễn phí. Vì vậy, hãy đảm bảo rằng bạn theo dõi công việc của chúng tôi. Vâng, tôi cũng muốn bổ sung rằng bạn cũng có thể tìm thấy tôi trên LinkedIn. Tôi đoán là tôi không viết nhiều, nhưng tôi luôn rất hào hứng khi nói chuyện về bất kỳ sản phẩm phức tạp nào bạn đang xây dựng, và nếu bạn có suy nghĩ về cách bạn có thể sử dụng tác nhân coding để làm cho cuộc sống của bạn tốt hơn, hoặc những vấn đề bạn đang gặp phải, tin nhắn trực tiếp (DM) của tôi luôn mở, và chúng ta có thể có một cuộc thảo luận tuyệt vời. Tuyệt vời. Vâng, Kiriti và Ash, cảm ơn rất nhiều vì đã có mặt ở đây. Cảm ơn rất nhiều. Cảm ơn Lenny. Điều này thật vui. Thật vui. Tạm biệt mọi người. Cảm ơn rất nhiều vì đã lắng nghe. Nếu bạn thấy điều này có giá trị, bạn có thể đăng ký theo dõi chương trình trên Apple Podcasts, Spotify, hoặc ứng dụng podcast yêu thích của bạn. Ngoài ra, xin hãy cân nhắc đánh giá hoặc để lại review vì điều đó thực sự giúp những thính giả khác tìm thấy podcast. Bạn có thể tìm tất cả các tập trước hoặc tìm hiểu thêm về chương trình tại lennispodcast.com. Hẹn gặp lại trong tập tiếp theo.