Phỏng vấn Product Manager của Anthropic: Claude có 'mơ mộng' hậu trường, chúng tôi nghiên cứu sự hình thành ý thức của nó như nuôi dạy một đứa trẻ

Chỉnh lý & Biên dịch: Deep Tide TechFlow

Khách mời: Alex Albert, Product Manager Nghiên cứu tại Claude

Người dẫn chương trình: Peter Yang

Nguồn podcast: Peter Yang

Tiêu đề gốc: Inside How Anthropic Is Building the Next Claude | Alex Albert

Ngày phát hành: 17 tháng 5 năm 2026

Tóm tắt điểm chính

Alex là một Product Manager Nghiên cứu (Research PM) tại Anthropic, hiện đang tập trung vào việc phát triển thế hệ mô hình Claude tiếp theo. Trong buổi phỏng vấn này, anh đã chia sẻ sâu về cơ chế vận hành của nhóm nghiên cứu tại Anthropic, bao gồm cách tích hợp hiệu quả phản hồi người dùng vào quy trình huấn luyện mô hình, cách ưu tiên phát triển những năng lực then chốt nào, và cách tinh chỉnh để 'tính cách' của Claude gần gũi hơn với nhu cầu người dùng. Cuối cùng, Alex cũng phản hồi về nghiên cứu nội bộ của Anthropic về ý thức, tính cách và độ tin cậy của Claude, chỉ ra rằng khi mô hình bắt đầu thực hiện các tác vụ tự chủ trong thời gian dài, việc nó 'quan tâm đến điều gì' sẽ trở nên quan trọng ngang bằng với năng lực của chính nó.

Tóm tắt quan điểm nổi bật

Xây dựng mô hình như một sản phẩm

• "Chúng tôi ở một mức độ nào đó xem mô hình như một sản phẩm. Mỗi khi bắt đầu một mô hình mới, chúng tôi đều xác định rõ yêu cầu của nó là gì, hy vọng nó giỏi điều gì, và chúng tôi dự đoán nó sẽ giỏi ở những mặt nào."
• "Sự khác biệt thú vị giữa phát triển mô hình và phát triển sản phẩm truyền thống là chúng tôi giống như đang nuôi dạy một mô hình hơn. Các thiết lập huấn luyện, lộ trình kỹ thuật và quyết định kiến trúc cho chúng tôi một số trực giác, nhưng chỉ khi huấn luyện bắt đầu, bạn mới thực sự biết nó sẽ trở nên như thế nào."
• "PM Nghiên cứu phải suy nghĩ về cách mô hình sẽ xuất hiện trên mọi bề mặt sản phẩm, cho dù là API, Claude Code hay Claude Cowork. Sản phẩm và mô hình ở một mức độ nào đó sẽ hòa trộn và ảnh hưởng đến trải nghiệm cuối cùng của người dùng."
• "Khi một số kênh nhận được lượng phản hồi lớn, chúng tôi có thể dùng Claude để nhóm chúng, phân cụm, tìm ra chủ đề chính, sau đó tạo phiên bản tổng hợp cho những vấn đề này. Như vậy chúng tôi có thể đánh giá liệu nó có thể trở thành một tài liệu yêu cầu (Eval), hoặc biến thành một cách chẩn đoán vấn đề thực tế."

Về tư duy thích ứng, ký ức và 'giấc mơ'

• "Tư duy thích ứng cho phép mô hình tự lựa chọn khi nào cần suy nghĩ. Một số vấn đề rất phức tạp, khó, cần nhiều kế hoạch trước, nó sẽ chọn suy nghĩ. Một số vấn đề nó có thể sẽ không chọn suy nghĩ."
• "Việc quyết định một vấn đề có đáng để suy nghĩ sâu sắc hay không, thực chất có đằng sau nó một lượng lớn ngữ cảnh."
• "Nếu mô hình không tích lũy đủ ngữ cảnh, không thực sự xây dựng được mô hình tâm lý về người dùng là ai, thì việc đánh giá liệu nó có nên suy nghĩ sâu hay không có thể bị sai. Bởi vì thực chất nó không biết."
• "Trong Claude.ai, nó sẽ ghi vào một tệp bộ nhớ, sau đó sẽ có một số quy trình ban đêm xem xét lại những ký ức này, thực hiện tỉa gọt và sắp xếp. Chúng tôi vừa triển khai một thứ tương tự trong các tác nhân được quản lý."
• "Đó là khái niệm 'mơ mộng'. Tại sao con người mơ, ở một mức độ nào đó vẫn chưa có kết luận, nhưng một số người cho rằng giấc mơ có thể là một quá trình tái củng cố ký ức. Chúng tôi nghĩ: liệu có thể đem thứ gì đó tương tự vào ký ức của Claude không?"
• "Vì vậy, khi tác nhân không chạy tác vụ cho bạn, hoặc khi nó ở chế độ nền, thực chất nó sẽ xem xét lại ký ức của chính mình, tìm ra những điểm có thể mâu thuẫn, thực hiện tỉa gọt, dọn dẹp, thực hiện lần phân tích thứ hai."

Nút thắt phát triển sản phẩm và 'Quyết định không thể đảo ngược'

• "Bây giờ đột nhiên bước vào một mô thức mới: chi phí và thời gian cần thiết để tạo ra một thứ gì đó đều rất thấp. Bạn có thể dựng nguyên mẫu rất nhanh, thậm chí bây giờ có thể tạo ra một MVP ban đầu có thể đưa ra sản xuất trong một ngày, thay vì hai tuần, ba tuần hoặc bốn tuần."
• "Nếu việc đó không phải là 'one-way door' (cửa một chiều), tức là chúng ta làm xong có thể rút lui, thì bây giờ nó thực sự có chi phí thấp, thậm chí có thể nói là không có phí tổn."
• "Những gì thực sự cần nhiều thời gian nhất là các quyết định không thể đảo ngược: những việc sẽ ảnh hưởng đến trải nghiệm người dùng cuối, ảnh hưởng đến các quyết định trong tương lai, hoặc liên quan đến việc mua sắm và đầu tư tài nguyên thực sự."
• "Khi tốc độ xây dựng trở nên nhanh hơn, nút thắt ngày càng chuyển sang các vấn đề phối hợp: kéo mọi người vào cùng một phòng, đánh giá xem chiến lược có đúng không, quyết định cách giao tiếp với người dùng, và xử lý những điều mơ hồ nhưng quan trọng trong quá trình phát hành."

Cách làm việc của PM 'AI-native'

• "Claude đối với tôi là đối tác động não tốt nhất thế giới. Tôi có thể nhận phản hồi, chỉ trích một ý tưởng từ nó bất kỳ lúc nào."
• "Rất nhiều suy nghĩ không thể hoàn toàn ủy thác, vì bản thân viết lách chính là suy nghĩ. Bạn cần phải viết ra để lấy ý tưởng của mình ra, suy đi nghĩ lại trong đầu. Nhưng Claude có thể giúp bạn thoát ra khỏi chỗ bế tắc, giải quyết vấn đề từ những góc độ mà bạn có thể không tự nghĩ ra."
• "Đối với những ai muốn học làm sản phẩm, trở thành product manager 'AI-native', lời khuyên đơn giản nhất tôi có thể đưa ra là: Hãy thử đi."
• "Khi bạn chuẩn bị hỏi ai đó một câu hỏi khó, có thể song song hỏi Claude cùng một câu hỏi, sau đó so sánh kết quả. Làm nhiều lần, bạn sẽ tự xây dựng được bản đồ của mình: điều gì nên giao cho Claude, nơi nào còn chưa đáng tin cậy."
• "AI đang giúp mọi người di chuyển lên tầng trừu tượng cao hơn. Các nhà khoa học dữ liệu không nên bị mắc kẹt trong việc kiểm tra số liệu thủ công và SQL cơ bản nữa, mà nên đi suy nghĩ những vấn đề khó hơn, mang tính chiến lược hơn."

Eval, tính cách mô hình và độ tin cậy

• "Chỉ cần kiểm tra vài chục mẫu là đủ để chứng minh mô hình tồn tại một vấn đề cần sửa chữa. Nó không nhất thiết phải rất toàn diện mới có thể chứng minh một vấn đề và hình thành một mục tiêu có thể tối ưu hóa liên tục."
• "Bài kiểm tra càng gần với hình thái nhiệm vụ thực tế của người dùng thì càng tốt. Chúng tôi còn phải nghĩ: Điều này có giá trị gì đối với khách hàng và trường hợp sử dụng của chúng ta? Bởi vì việc Claude có nhìn thấy thứ gì đó trong ảnh cuối cùng sẽ ảnh hưởng thế nào đến những việc người dùng muốn làm với Claude ở hạ nguồn?"
• "Tính cách của Claude là điều chúng tôi rất coi trọng. Khi mô hình trở thành các tác nhân thông minh thực hiện nhiệm vụ trong thời gian dài, liên tục đưa ra phán đoán, thì tính cách của nó là gì, nó quan tâm điều gì, sẽ trở nên rất quan trọng."
• "Việc đánh giá tính cách mô hình vừa có chỉ số định lượng, vừa dựa vào các nhà nghiên cứu đọc nhiều đoạn hội thoại của mô hình, nhận diện những thay đổi tinh tế trong đầu ra. Đọc nhiều rồi, bạn sẽ dần hình thành trực giác sắc bén hơn."

Vấn đề ý thức và tác nhân thông minh dài hạn

• "Chúng tôi thực sự có người chuyên tâm suy nghĩ về điều này, chính là suy nghĩ về việc Claude với tư cách là một tác nhân có ý thức, một trí tuệ nhân tạo có ý thức thực sự có nghĩa là gì. Hiện tại chúng tôi chưa có lập trường chính thức nói rằng Claude có ý thức hay không."
• "Ngay cả khi không đánh giá xem Claude cuối cùng có ý thức hay không, chúng tôi cũng có thể học được rất nhiều điều từ nó, ví dụ như nó tương tác thế nào, thể hiện ra sao."
• "Mô hình sẽ đưa ra một lượng lớn quyết định mà bạn có thể hoàn toàn không giám sát trong quá trình. Vì vậy, nó cuối cùng sẽ làm gì, rất quan trọng."

Cách Anthropic coi mỗi mô hình mới như một sản phẩm

Người dẫn Peter Yang: Alex, rất vui được gặp anh hôm nay tại Claude Code Conference. Trước đây anh là trưởng nhóm DevRel của Anthropic, gần đây đã trở thành Product Manager của nhóm nghiên cứu, phải không? Bản thân tôi làm PM cũng hơn mười năm rồi. Công việc của PM truyền thống thường là hiểu vấn đề người dùng, xác định giải pháp, thúc đẩy sản phẩm ra mắt. Nhưng tôi hoàn toàn không biết PM trong nhóm nghiên cứu làm việc như thế nào, chúng ta có thể nói về điều này trước.

Alex Albert:

Về bản chất thực sự rất giống. Tôi luôn muốn giao tiếp với khách hàng, càng gần với người dùng của chúng tôi càng tốt. Chúng tôi ở một mức độ nào đó xem mô hình như một sản phẩm. Vì vậy, đối với mỗi mô hình mới, chúng tôi đều xác định rõ yêu cầu của nó là gì, chúng tôi hy vọng mô hình này giỏi điều gì, chúng tôi nghĩ nó có thể giỏi ở mặt nào.

Đây cũng là điểm thú vị khi so sánh phát triển mô hình với phát triển sản phẩm: rất nhiều khi, chúng tôi giống như đang 'nuôi dạy' một mô hình hơn. Dựa trên các thiết lập huấn luyện, lộ trình kỹ thuật, lựa chọn kiến trúc, và các quyết định khác nhau chúng tôi đưa ra cho mô hình cụ thể này, chúng tôi có một số trực giác về việc nó sẽ giỏi điều gì trong tương lai. Nhưng nó cuối cùng sẽ trở nên như thế nào, chúng tôi không hoàn toàn biết được, cho đến khi nó thực sự bước vào quá trình huấn luyện.

Người dẫn Peter Yang: Vậy là nhóm PM Nghiên cứu sẽ tham gia từ giai đoạn ý tưởng của mô hình, theo sát đến tận quá trình huấn luyện và phát hành? Có thể lấy vài ví dụ không? Ví dụ như mô hình tiếp theo bắt buộc phải giỏi coding, hoặc bắt buộc phải giỏi công việc tri thức, hay là mục tiêu sẽ rộng hơn?

Alex Albert:

Đại khái là vậy, chúng tôi rất coi trọng khả năng đa diện, Coding tất nhiên luôn là một loại rất quan trọng. Gần đây công việc tri thức cũng trở nên quan trọng, vì vậy trong vài thế hệ mô hình gần đây, chúng tôi cố gắng làm cho mô hình giỏi hơn trong việc sử dụng sản phẩm của chúng tôi, ví dụ như làm việc trong Excel, tạo bảng biểu, v.v. Đây là một hướng năng lực khá mới mẻ.

Mặt khác, mỗi thế hệ mô hình đều phải sửa chữa và cải thiện những điểm thế hệ trước chưa làm tốt. Chúng tôi sẽ đi ra ngoài và trao đổi với khách hàng, tìm hiểu họ sử dụng mô hình này như thế nào: nó thể hiện tốt ở những điểm nào? Những điểm nào dễ hỏng? Chúng tôi có thể thực hiện những sửa chữa nào? Nếu phát hiện một số hành vi thú vị, liệu khi huấn luyện thế hệ tiếp theo có thể thực hiện một số điều chỉnh hoặc biện pháp can thiệp không.

Người dẫn Peter Yang: Khách hàng anh nói có bao gồm nhóm Claude Code, nhóm nội bộ, cũng như người dùng thông thường không?

Alex Albert:

Tất cả mọi người đều được tính, đây cũng là điểm hay của việc làm mô hình: nó tiếp cận rất nhiều lĩnh vực khác nhau. Là một PM Nghiên cứu, bạn cần suy nghĩ về cách mô hình sẽ được hiển thị qua tất cả các bề mặt sản phẩm của chúng tôi, cho dù là API, Claude Code, hay Claude Cowork.

Sản phẩm và mô hình ở một mức độ nào đó trộn lẫn với nhau, điều này sẽ ảnh hưởng đến trải nghiệm thực tế của người dùng cuối, vì vậy bạn phải nghĩ thông suốt toàn bộ quy trình, cách người dùng sử dụng mô hình trong một sản phẩm nào đó, đều sẽ có tác động.

Người dẫn Peter Yang: Nghe có vẻ thực sự khó. Ví dụ như Claude Code, bạn có thể nói nó dùng để viết code, nhưng cũng có người như tôi sử dụng nó cho công việc tri thức, thậm chí dùng như một nhà tâm lý trị liệu. Các anh biết những điều này bằng cách nào?

Alex Albert:

Không gian này thực sự rất rộng. May mắn là chúng tôi có một số lượng lớn các nhà nghiên cứu xuất sắc, họ bao phủ toàn bộ phạm vi năng lực và mỗi người tập trung vào những vấn đề khác nhau.

Người dẫn Peter Yang: Và có rất nhiều người đang sử dụng Claude, các anh cũng nên có một đầu vào phản hồi nào đó chứ? Nếu không phản hồi sẽ tuôn ra như vòi chữa cháy, các anh xử lý thế nào?

Alex Albert:

Chúng tôi làm rất nhiều việc. Và một sự thay đổi thú vị tôi thấy trong vai trò này, là chúng tôi ngày càng sử dụng Claude để giúp PM làm công việc của PM. Chỉ riêng việc thu thập phản hồi, Claude rất hữu ích cho tôi trong việc trích xuất insights từ một lượng lớn dữ liệu. Khi một số kênh nhận được lượng phản hồi lớn, chúng tôi có thể sử dụng Claude để nhóm chúng, phân cụm, tìm ra chủ đề chính, sau đó tạo phiên bản tổng hợp cho những vấn đề này. Như vậy chúng tôi có thể đánh giá liệu nó có thể trở thành một tài liệu yêu cầu (Eval), hoặc biến thành một cách chẩn đoán vấn đề thực tế.

Thêm Tư duy Thích ứng cho Claude

Người dẫn Peter Yang: Tức là các anh dùng Claude để giúp nhận diện chính các vấn đề của Claude. Có ví dụ cụ thể nào không?

Alex Albert:

Một ví dụ rất liên quan hiện nay, là cách chúng tôi xử lý phản hồi về tính năng mới. Trong vài mô hình gần đây, một trong những tính năng mới hơn của chúng tôi là tư duy thích ứng. Trước đây chúng tôi có tư duy mở rộng, bạn bật nó lên, mô hình sẽ suy nghĩ, còn tư duy thích ứng cho phép mô hình tự lựa chọn khi nào cần suy nghĩ.

Một số vấn đề rất phức tạp, khó, cần nhiều kế hoạch trước, nó sẽ chọn suy nghĩ. Một số vấn đề nó có thể sẽ không chọn suy nghĩ. Tính năng này chúng tôi sẽ tiếp tục điều chỉnh qua các thế hệ mô hình, vì vậy chúng tôi lắng nghe rất nghiêm túc phản hồi người dùng: nó có đang suy nghĩ đúng trong các tình huống đúng không? Những vấn đề bạn hy vọng nó dành nhiều token để suy luận, có thực sự kích hoạt tư duy của Claude không?

Người dẫn Peter Yang: Đôi khi tôi hỏi một số câu hỏi cuộc sống, nếu nó trả lời quá nhanh, tôi thực sự sẽ hơi thất vọng, vì tôi hy vọng nó có thể suy nghĩ sâu hơn một chút.

Alex Albert:

Tôi nghĩ vấn đề 'có nên suy nghĩ hay không' có một điểm khó: việc quyết định một vấn đề có đáng để suy nghĩ sâu sắc hay không, thực chất có đằng sau nó một lượng lớn ngữ cảnh.

Ví dụ, một người hoàn toàn xa lạ hỏi tôi: "Tôi nên làm gì bây giờ?" Tôi có thể nhanh chóng đưa ra một câu trả lời ngẫu hứng, vì tôi không hiểu về anh ta, chỉ có thể đưa ra lời khuyên khá chung chung. Nhưng nếu tôi thực sự hiểu bạn, biết bạn quan tâm điều gì, sở thích là gì, đã từng làm gì, tôi sẽ dành nhiều thời gian hơn để nghĩ: khoan đã, câu trả lời tốt nhất cho bạn thực sự là gì?

Mô hình cũng tương tự. Nếu nó không tích lũy đủ ngữ cảnh, không thực sự xây dựng được mô hình tâm lý về việc người dùng là ai, thì việc đánh giá liệu nó có nên suy nghĩ sâu hay không có thể bị sai. Bởi vì thực chất nó không biết.

Tại sao Claude bắt đầu 'mơ mộng'

Người dẫn Peter Yang: Tôi có một Google Doc, bên trong tóm tắt tình hình cuộc sống của tôi, ví dụ như gia đình, con cái, việc gì mang lại năng lượng cho tôi, việc gì tiêu hao tôi. Sau đó tôi đính kèm nó vào một project Claude, nó sẽ cho tôi rất nhiều nội dung trả lời.

Ký ức mặc định hoạt động như thế nào? Tôi đoán nó có phải mỗi tối sẽ sắp xếp lại toàn bộ nội dung không?

Alex Albert:

Điều này phụ thuộc vào sản phẩm cụ thể, cách triển khai ký ức của các sản phẩm khác nhau là khác nhau. Ví dụ trong Claude.ai, nó sẽ ghi vào một tệp bộ nhớ, sau đó sẽ có một số quy trình ban đêm xem xét lại những ký ức này, thực hiện tỉa gọt và sắp xếp. Chúng tôi vừa triển khai một thứ tương tự trong các tác nhân được quản lý.

Đó là khái niệm 'mơ mộng'. Tại sao con người mơ, ở một mức độ nào đó vẫn chưa có kết luận, nhưng một số người cho rằng giấc mơ có thể là một quá trình tái củng cố ký ức. Chúng tôi nghĩ: liệu có thể đem thứ gì đó tương tự vào ký ức của Claude không?

Vì vậy, khi tác nhân không chạy tác vụ cho bạn, hoặc khi nó ở chế độ nền, thực chất nó sẽ xem xét lại ký ức của chính mình, tìm ra những điểm có thể mâu thuẫn, thực hiện tỉa gọt, dọn dẹp, thực hiện lần phân tích thứ hai. Tôi nghĩ điều này rất thú vị.

Người dẫn Peter Yang: Nói đơn giản là có một loại prompt nào đó, khiến nó xem xét lại tất cả cuộc hội thoại giữa người dùng và nó, nhận diện chủ đề và tóm tắt.

Chúng ta quay lại với quản lý sản phẩm. Trước khi bắt đầu, anh nói anh luôn tìm kiếm những nút thắt mới nhất. Vậy trong toàn bộ quy trình phát triển sản phẩm, phần nào đã trở nên rất suôn sẻ, phần nào vẫn còn là nút thắt?

Alex Albert:

Tôi nghĩ khoảng 20 năm qua, quy trình phát hành một thứ gì đó thực sự khá phức tạp. Chúng ta đã có những cải tiến gia tăng, và thực sự đã làm cho một số việc hiệu quả hơn; một số cấu trúc tổ chức mới cũng đến rồi đi, như sprint, planning, v.v., chúng ta đã thử nhiều phương pháp để làm mọi việc nhanh hơn.

Nhưng về cơ bản, cho đến một hoặc hai năm gần đây, không có nhiều thứ thực sự nén được cửa sổ thời gian chính của phát triển sản phẩm. Bây giờ đột nhiên bước vào một mô thức mới: chi phí và thời gian cần thiết để sản xuất một thứ gì đó đều rất thấp. Bạn có thể dựng nguyên mẫu rất nhanh, thậm chí bây giờ có thể tạo ra một MVP ban đầu có thể đưa ra sản xuất trong một ngày, thay vì hai tuần, ba tuần hoặc bốn tuần.

Điều thú vị là, bản thân Claude đôi khi vẫn mắc kẹt trong thế giới cũ khoảng năm 2021. Nó sẽ nói việc này có thể cần một tuần. Điều này mang đến một sự thay đổi thú vị cho toàn bộ vòng đời phát triển sản phẩm. Là một PM, tôi nên suy nghĩ thế nào về việc lập kế hoạch? Nếu tôi viết PRD, định nghĩa yêu cầu, cố gắng ước tính thời gian, bây giờ việc này thực sự nên như thế nào?

Nếu không phải one-way door (quyết định không thể đảo ngược), thì về cơ bản nó không có phí tổn

Người dẫn Peter Yang: Các anh vẫn còn làm ước tính thời gian thực hiện và những thứ tương tự không?

Alex Albert:

Điều này phụ thuộc vào dự án. Một số dự án thực sự có nhiều yếu tố cần xem xét, điều này phụ thuộc vào phạm vi và độ phức tạp. Thông thường chúng tôi muốn tìm hiểu rõ: đâu là one-way door (quyết định một chiều, tức là một khi đã làm thì khó rút lại, chi phí cao, ảnh hưởng sẽ kéo dài)? Đâu là quyết định có thể đảo ngược? Bởi vì những cái này mới là nơi bạn nên đầu tư nhiều thời gian nhất. Nếu việc nào đó không phải là one-way door, tức là chúng ta làm xong có thể rút lui, thì bây giờ nó thực sự có chi phí thấp, thậm chí có thể nói là không có phí tổn.

Nhưng nếu một việc sẽ ảnh hưởng đến trải nghiệm người dùng cuối, sẽ ảnh hưởng đến các quyết định chúng ta sau này phải đưa ra, hoặc nó là một hành động vật lý thực sự phải mua sắm, đầu tư, thực hiện, thì sẽ khó đảo ngược hơn, loại việc này cần nhiều thời gian và suy nghĩ hơn.

Người dẫn Peter Yang: Có thể lấy một ví dụ từ phía nghiên cứu không?

Alex Albert:

Ví dụ khi chúng tôi suy nghĩ về mô hình mới, việc lựa chọn kiến trúc mô hình trước khi tiền huấn luyện, là một quyết định rất lớn. Trong một số trường hợp, thời gian huấn luyện mô hình có thể kéo dài đến một tháng, vì vậy chúng tôi phải đầu tư nhiều thời gian suy nghĩ về lựa chọn tối ưu là gì.

Mô hình ở một mức độ nào đó có nhiều one-way door hơn, bởi vì chúng cần nhiều thời gian, cường độ, sức mạnh tính toán và các đầu tư khác nhau, mới có thể thực sự đi vào sản xuất. Ngược lại, việc tạo một tính năng mới trong Claude Code sẽ nhanh hơn nhiều. Đó giống như lặp lại code, đưa vào tay người dùng, nhận phản hồi nhanh, sau đó tiếp tục vòng lặp.

Vì vậy quy trình vẫn phụ thuộc vào việc bạn cuối cùng đang phát hành cái gì, nhưng ngày càng rõ ràng là, nút thắt đang chuyển sang các vấn đề phối hợp. Nếu chúng tôi xây dựng mọi thứ rất nhanh, vẫn sẽ có một vấn đề: chúng tôi cần kéo những người này vào phòng, đánh giá xem đây có phải là chiến lược đúng không; chúng tôi phải tìm hiểu cách giao tiếp với người dùng; và phải xử lý những vấn đề mơ hồ đi kèm với bất kỳ lần phát hành nào. Những lĩnh vực này chúng tôi cũng hy vọng Claude có thể giúp đỡ, nhưng nó vẫn chưa mang lại sự tăng tốc 10 lần, 100 lần như trong lĩnh vực coding.

Người dẫn Peter Yang: Vậy là các anh phát hành những thứ như Opus 4.7, vẫn cần viết một tài liệu có kế hoạch.

Alex Albert:

Vẫn cần kế hoạch, bạn vẫn phải nghĩ thông suốt cách truyền đạt việc này, và mô hình có thể thể hiện đáng kinh ngạc trong một số nhiệm vụ khó, nhưng đột nhiên hỏng hóc trong một số nhiệm vụ có vẻ đơn giản khác, vì vậy chúng tôi sẽ sử dụng Claude càng nhiều càng tốt. Hiện tại nơi có ảnh hưởng lớn nhất vẫn là coding, các lĩnh vực khác vẫn cần suy nghĩ chiến lược của con người.

Người dẫn Peter Yang: Khi họp xem xét với marketing hoặc đồng nghiệp, anh có mở Claude không?

Alex Albert:

Tất nhiên là có. Đối với tôi, một sự tăng tốc khổng lồ là: tôi không còn dễ bị 'không lấy được câu trả lời và dữ liệu' làm tắc nghẽn nữa. Trước đây nếu tôi có một câu hỏi, ví dụ như một tính năng nào đó thể hiện thế nào trong môi trường sản xuất, mỗi ngày có bao nhiêu người dùng sử dụng, phản hồi là gì, tôi có thể cần nhờ nhóm khoa học dữ liệu khởi động một cuộc điều tra hoàn chỉnh, sau đó vài ngày sau mới nhận kết quả.

Bây giờ tôi có thể hoàn thành trong 10 phút. Tôi mở một phiên Claude Code, nó có thể truy cập cơ sở dữ liệu sản phẩm của chúng tôi, có thể xem nhật ký, tra cứu vấn đề, duyệt Slack, điều này là sự tăng tốc khổng lồ cho việc suy nghĩ chiến lược của tôi, bởi vì tôi sẽ không bị tắc nghẽn trước khi đưa ra quyết định tiếp theo.

Người dẫn Peter Yang: Vậy trong suy nghĩ chiến lược, anh có xây dựng một loại kỹ năng nào đó, khiến Claude hỏi anh một loạt câu hỏi, giúp anh làm rõ mọi việc không?

Alex Albert:

Tất nhiên là có, Claude đối với tôi là đối tác động não tốt nhất thế giới, tôi có thể nhận phản hồi cho một ý tưởng bất kỳ lúc nào. Tôi nghĩ điều này rất mạnh mẽ, đặc biệt khi bạn muốn tiến nhanh. Mọi người ở Anthropic đều rất bận rộn, vì vậy việc có thể nhận ngay phản hồi và chỉ trích cho tài liệu, ý tưởng hoặc bất cứ thứ gì tôi viết, thực sự rất hữu ích.

Alex sử dụng Claude Cowork để kiểm tra áp lực tài liệu như thế nào

Người dẫn Peter Yang: Đây có lẽ là vòng lặp công việc phổ biến nhất của product manager: anh có một tài liệu, sau đó muốn phản hồi. Anh sẽ dùng Claude Code làm việc này, hay dùng trực tiếp Claude.ai?

Alex Albert:

Gần đây tôi dùng Claude Cowork rất nhiều, tôi rất thích hình thái của Cowork, nó là một giao diện tương tác rất tốt. Nhóm đã làm rất xuất sắc trong vài tháng qua, từ lúc mới phát hành vài tháng trước, đến nay đã trở thành một trải nghiệm mà tôi cảm thấy chất lượng cao. Cowork là một trong những công cụ yêu thích nhất của tôi.

Người dẫn Peter Yang: Vậy là anh có một bản thảo tài liệu, và một đống tài liệu tham khảo. Anh có một loại kỹ năng nào đó, khiến nó giúp anh đi hết toàn bộ quy trình quyết định không?

Alex Albert:

Có. Ví dụ tôi sẽ nói: hãy suy nghĩ về việc này từ góc nhìn của X, Y, Z. Bạn sẽ hỏi tôi những câu hỏi gì? Hoặc thách thức giả định của tôi, chỉ ra luận điểm của tôi yếu ở đâu. Rất nhiều suy nghĩ không thể hoàn toàn ủy thác, vì bản thân viết lách chính là suy nghĩ. Bạn cần phải viết ra để lấy ý tưởng của mình ra, suy đi nghĩ lại trong đầu. Nhưng Claude có thể giúp bạn thoát ra khỏi chỗ bế tắc, giải quyết vấn đề từ những góc độ mà bạn có thể không tự nghĩ ra.

Người dẫn Peter Yang: Trong nhóm nghiên cứu, anh cũng tự giao code sao?

Alex Albert:

Điều này phụ thuộc vào vấn đề cụ thể. Trong những việc tôi giao, một phần lớn thực chất liên quan đến đánh giá. Tôi muốn đảm bảo mình có thể đo lường mô hình trong các chiều tôi quan tâm, và phản hồi những phát hiện về việc mô hình tốt ở đâu, hỏng hóc ở đâu cho nhóm nghiên cứu. Sau đó chúng tôi cùng nhau xây dựng chiến lược, quyết định cách giải quyết vấn đề này, nên thực hiện can thiệp nghiên cứu nào, cách nào có thể leo dốc liên tục trong bài đánh giá này, từ đó thực sự cải thiện vấn đề.

Quy trình đánh giá mô hình mới

Người dẫn Peter Yang: Bài đánh giá anh nói chắc không phải là bài kiểm tra cuối kỳ hay những thứ tương tự phải không? Bài đánh giá của các anh có thực tế hơn không? Các anh thực sự đánh giá một mô hình thế nào? Có phân loại tính cách v.v không?

Alex Albert:

Ví dụ chúng tôi muốn kiểm tra khả năng thị giác của Claude: nó có thể đếm xem trong một bức ảnh có bao nhiêu thứ. Giả sử tôi phát hiện một bức ảnh, Claude dường như không đếm được những thứ có hơn 10 phần tử. Bây giờ có lẽ nó có thể làm được, nhưng ở đây hãy tạm ví dụ như vậy. Tôi sẽ lấy vấn đề này ra suy nghĩ: làm thế nào tôi có thể có thêm nhiều trường hợp thử nghiệm cùng loại, từ đó xác minh giả thuyết của mình?

Có lẽ tôi sẽ để Claude tạo dữ liệu tổng hợp cho tôi, có lẽ để nó render một số ảnh, sau đó truyền những ảnh này như đầu vào thị giác trở lại Claude, xem nó có nhận diện được không. Có lẽ tôi sẽ tìm ví dụ từ internet, hoặc sử dụng bất kỳ cơ chế nguồn nào khác để tạo ra những trường hợp thử nghiệm này.

Người dẫn Peter Yang: Chúng ta đang nói đến hàng nghìn trường hợp thử nghiệm sao?

Alex Albert:

Có thể, nhưng đôi khi chỉ vài chục mẫu là đủ để chứng minh mô hình tồn tại một vấn đề cần sửa chữa. Nó không nhất thiết phải rất toàn diện mới có thể chứng minh một vấn đề và hình thành một mục tiêu có thể tối ưu hóa liên tục.

Người dẫn Peter Yang: Giả sử anh cho nó 10 bức ảnh, nó không nhận diện được những con số rất nhỏ. Tiếp theo làm sao? Anh đi tìm nhóm nghiên cứu và nói: 'Đây là vấn đề, các anh có thể sửa không?'

Alex Albert:

Chúng tôi sẽ suy nghĩ từ vài góc độ. Đầu tiên, không chỉ là nói rõ mô hình có vấn đề, mà còn phải nghĩ: điều này có giá trị gì đối với khách hàng và trường hợp sử dụng của chúng ta? Bởi vì việc Claude có nhìn thấy thứ gì đó trong ảnh cuối cùng sẽ ảnh hưởng thế nào đến những việc người dùng muốn làm với Claude ở hạ nguồn?

Vì vậy, bài đánh giá càng chân thực, càng gần với hình thái nhiệm vụ thực tế mà người dùng cuối trải qua thì càng tốt, chúng tôi sẽ nỗ lực thu thập loại dữ liệu này, đảm bảo dữ liệu có hương vị đó.

Tiếp theo sẽ có một loạt cách thức can thiệp. Có lẽ chúng ta cần quay lại giai đoạn tiền huấn luyện xem một số thứ, có lẽ có thể giải quyết ở giai đoạn học tăng cường. Lúc này cần cùng nhóm nghiên cứu động não chiến lược: cách làm tốt nhất ở đây là gì?

Người dẫn Peter Yang: Tốc độ luân chuyển thử lại một lần nữa nhanh như thế nào?

Alex Albert:

Điều này phụ thuộc vào việc chúng tôi nghĩ vấn đề ở đâu. Nếu là thứ ở giai đoạn sau, có thể giải quyết bằng một môi trường học tăng cường mới, có lẽ có thể dựng lên rất nhanh.

Người dẫn Peter Yang: Khi anh liên hệ nó với trường hợp sử dụng thực tế của khách hàng, mỗi ngày đều có hàng triệu người trò chuyện với Claude, có thể có người đang dùng nó để khai thuế, hoặc làm rất nhiều việc khác. Các anh chọn ra trường hợp sử dụng muốn cải thiện nhất như thế nào? Anh thuyết phục nhóm thế nào: 'Đây mới là thứ chúng ta nên tối ưu hóa'?

Alex Albert:

Đây chính là chỗ 'dữ liệu lên tiếng'. Cốt lõi là: có bao nhiêu phần trăm người dùng đang cố gắng làm việc này, chúng tôi rất quan tâm đến nó; hoặc chúng tôi có khách hàng sử dụng Claude nhiều, và họ hy vọng khả năng này trở nên tốt hơn.

Ngoài ra, nhiều quy trình của chúng tôi cũng phần lớn được thúc đẩy bởi việc sử dụng nội bộ: bản thân chúng tôi sử dụng mô hình quan tâm điều gì? Khi tôi sử dụng mô hình mỗi ngày gặp phải trở ngại này, vậy chúng ta nên sửa nó. Điều này cũng rất có sức thuyết phục.

Anthropic huấn luyện tính cách của Claude như thế nào

Người dẫn Peter Yang: Điểm tôi thích nhất ở Claude là tính cách của nó, và tôi cảm thấy nó luôn trở nên tốt hơn. Nó sẽ đưa ra ý kiến phản đối ở vị trí thích hợp, còn một số mô hình khác chỉ nói: 'Tôi còn có thể giúp gì cho bạn?' Tính cách của mô hình không chỉ là một lớp vỏ phải không? Đằng sau nó là có huấn luyện.

Alex Albert:

Vâng, có rất nhiều huấn luyện. Đây là hướng mà chúng tôi rất coi trọng. Chúng tôi gọi đó là tính cách của Claude. Tôi nghĩ điều này rất rất quan trọng.

Chúng tôi có rất nhiều người đầu tư nhiều thời gian để nghiên cứu: Claude nên thể hiện mình như thế nào? Niềm tin của nó là gì? Giá trị quan của nó là gì? Nó hành động ra sao? Những câu hỏi này đều rất mơ hồ. Giai đoạn đầu một số người có thể bỏ qua chúng, nghĩ rằng mô hình chỉ là thứ tôi bảo nó làm gì thì nó làm, tại sao phải quan tâm nó nghe thế nào, đang nghĩ gì?

Nhưng khi chúng ta ngày càng tiến đến một thế giới mà các tác nhân thông minh thực hiện nhiệm vụ dài hạn, và cần đưa ra nhiều quyết định phán đoán, câu hỏi về tính cách của nó là gì, nó quan tâm điều gì, sẽ trở nên rất quan trọng.

Người dẫn Peter Yang: Điều này không giống như code, chỉ có thể phán đoán nó có chạy hay không. Các anh đánh giá tính cách thế nào? Là tìm một người tốt hơn trong nội bộ Anthropic, sau đó so sánh mô hình với anh ta sao?

Alex Albert:

Ở đây là sự kết hợp của nhiều phương pháp. Chúng tôi sẽ xem một số chỉ số có thể định lượng, cũng có thể để Claude xem đầu ra của Claude, đánh giá xem nó nghe thế nào. Đối với bất kỳ nhà nghiên cứu nào, một kỹ năng rất quan trọng là đọc hồ sơ hội thoại, sau đó đánh giá: tôi thấy bây giờ nó đang làm như vậy, hoặc bây giờ nó trở thành thế kia. Bạn cần có thể nhận diện những khác biệt tinh tế này.

Theo thời gian, khi bạn đã đọc vài trăm, vài nghìn hồ sơ hội thoại mô hình, bạn sẽ dần hình thành trực giác nhạy bén hơn, giống như bạn sử dụng nhiều mô hình này trong Claude.ai, bạn sẽ cảm nhận được nó như thế nào.

Người dẫn Peter Yang: Vậy không phải là mô hình này được 7 điểm ở một chiều nào đó, mà giống như một cảm giác hơn?

Alex Albert:

Cả hai đều có. Tính cách có thể khó định lượng hơn so với biểu hiện lập trình, nhưng không phải là không thể định lượng, vẫn có cách.

Người dẫn Peter Yang: Đối với những ai muốn học làm sản phẩm, trở thành product manager 'AI-native', anh có lời khuyên gì?

Alex Albert:

Lời khuyên đơn giản nhất tôi có thể đưa ra là: hãy thử đi. Nghe có vẻ đơn giản, nhưng mỗi khi bạn muốn làm một việc, đối mặt với một vấn đề khó, chuẩn bị đi hỏi ai đó một câu hỏi, có thể song song hỏi Claude cùng một câu hỏi, sau đó so sánh kết quả.

Ví dụ bạn muốn phân tích người dùng, trích xuất chủ đề người dùng quan tâm nhất đối với tính năng vừa phát hành. Bạn tất nhiên có thể đi hỏi nhóm khoa học dữ liệu, hoặc hỏi nhà nghiên cứu trải nghiệm người dùng, điều này vẫn rất có giá trị. Nhưng đồng thời, cũng ném câu hỏi này cho Claude, mở cho nó một số công cụ, để nó tự khám phá, cho nó thời gian thực sự đi sâu vào vấn đề này, sau đó so sánh kết quả.

Thông qua rất nhiều prompt và câu hỏi, bạn sẽ từ từ xây dựng bản đồ của mình: việc gì nên dùng Claude, nơi nào đáng tin, nơi nào còn chưa đáng tin cậy.

Người dẫn Peter Yang: Khi tôi ra quyết định thường để nó nghiên cứu sâu, vì tìm kiếm thông thường đối với tôi là không đủ, tôi cần nó nghiên cứu sâu. Việc quét 1000 trang web, rất siêu nhân. Trong nội bộ Anthropic, nếu anh đi tìm nhà khoa học dữ liệu nói 'có thể giúp tôi làm việc này không', họ có lẽ sẽ hỏi anh: 'Anh đã hỏi Claude chưa?'

Alex Albert:

Thực sự có yếu tố này, mọi người sẽ kỳ vọng bạn hỏi Claude trước. Tôi nghĩ chúng ta đang di chuyển lên tầng trừu tượng cao hơn. Đối với nhóm khoa học dữ liệu, bây giờ thời gian của họ đáng để đầu tư hơn vào các vấn đề ở cấp độ cao hơn, thay vì truy xuất dữ liệu thủ công.

Không ai muốn làm những việc đó. Mọi người đều muốn suy nghĩ những vấn đề khó hơn, mang tính chiến lược hơn: chúng ta đo lường điều này bằng cách mới mẻ nào? Còn có thể làm gì mới? Thay vì chỉ đi tra DAU mới nhất của sản phẩm nào đó.

Tôi đã làm việc với rất nhiều nhà khoa học dữ liệu, họ thường bị mắc kẹt trong các nhiệm vụ SQL cơ bản. Nhưng họ đều muốn làm những việc mang tính chiến lược hơn, bây giờ AI cuối cùng có thể giải phóng họ, thực chất chúng ta đang trao quyền cho mọi người xung quanh họ, đối với mọi vai trò đều như vậy.

Ví dụ như định nghĩa một tính năng mới. Trước đây nếu bạn là product manager, dù bạn có biết kỹ thuật hay không, thường không có đủ thời gian đi sâu vào codebase, tìm hiểu rõ tính năng mới này thực sự nên triển khai thế nào, cần bao nhiêu công sức, có cần tái cấu trúc hệ thống nào không, đâu mới là hạn chế thực sự. Lúc đó cách tốt hơn là cùng đối tác kỹ thuật tìm hiểu rõ.

Bây giờ tôi có thể cử Claude đi thay tôi làm cuộc điều tra này. Nó có thể quay lại nói với tôi: thực chất tính năng này chỉ cần sửa 10 dòng code ở đây, sau đó mở một dấu hiệu trong công tắc nào đó. Điều đó sẽ hoàn toàn thay đổi sự đánh giá mức độ ưu tiên của tôi đối với quyết định này. Bây giờ khi viết tài liệu đặc tả, tôi có thể nhanh chóng đến mức đánh giá mức độ ưu tiên như vậy.

Người dẫn Peter Yang: Nhiều công ty truyền thống dành nhiều thời gian để lập kế hoạch năm, kế hoạch quý và lộ trình. Nhóm nghiên cứu có lẽ càng như vậy, vì các anh phải xem xét vấn đề dài hạn hơn việc phát hành mỗi ngày. Các anh có làm những việc này không?

Alex Albert:

Có. Ở đây hơi giống câu nói nổi tiếng: lập kế hoạch là không thể thiếu, nhưng bản thân kế hoạch thì vô dụng. Hành động lập kế hoạch rất quan trọng, nhưng bạn phải thừa nhận rằng, kế hoạch có thể bị lật đổ hoàn toàn.

Người dẫn Peter Yang: Một trong những thách thức khó nhất của product manager là cuối cùng nên dành bao nhiêu thời gian lập kế hoạch, vì nó luôn cân bằng giữa việc lập kế hoạch và thực sự phát hành. Trong nội bộ Anthropic có phương pháp tốt nhất nào không? Anh hoàn toàn có thể dùng Claude viết tài liệu 10 trang.

Alex Albert:

Điều này khó để đưa ra một câu trả lời thống nhất áp dụng cho tất cả các nhóm, tôi nghĩ nó phụ thuộc vào sản phẩm. Chúng tôi chắc chắn không nói bạn phải tạo ra một tài liệu có độ dài, số trang nào đó. Quan trọng hơn là: bạn đã suy nghĩ đủ nhiều, nghĩ thông suốt tất cả ảnh hưởng của các quyết định không thể đảo ngược có thể có chưa?

Nếu đã làm được, thì tài liệu là định dạng gì, có bao nhiêu trang không quan trọng. Quan trọng là chúng ta có đủ yên tâm, biết không bỏ sót thứ gì quan trọng, có thể tiếp tục tiến lên, và xử lý vấn đề trên đường đi. Miễn là không có nút thắt dài nhất sẽ làm tắc chúng ta, không có quyết định không thể đảo ngược mà hậu quả rất nghiêm trọng, thì có thể tiếp tục.

Người dẫn Peter Yang: Khi tôi dùng Claude ở nhà, sẽ đồng thời chạy nhiều project khác nhau, sau đó chuyển đổi ngữ cảnh giữa các project khác nhau, chờ chúng xây dựng thứ gì đó. Công việc của product manager cũng như vậy sao? Anh cũng có nhiều project khác nhau phải không?

Alex Albert:

Vâng, bởi vì có rất nhiều project khác nhau, và bạn thực sự phải chờ tác nhân thông minh làm việc, tôi nghĩ ở đây có một cơ hội khổng lồ. Khi chúng ta ngày càng quản lý nhiều tác nhân thông minh, chúng hoàn thành những khối công việc ngày càng lớn cho bạn, bạn có thể khởi động song song nhiều project hơn. Chúng ta nên suy nghĩ thế nào về vấn đề quản lý ngữ cảnh của chính mình? Giao diện tương tác nào là phù hợp nhất để hiển thị những thứ này? Tôi theo dõi điều gì thực sự quan trọng, tác nhân thông minh của tôi bị tắc ở đâu, ở đâu cần tôi giúp đỡ như thế nào?

Chắc chắn có cách tốt hơn một danh sách trò chuyện nhỏ bé. Bây giờ nói nó thực sự là gì còn quá sớm, nhưng ngay cả trong nội bộ Anthropic, chúng tôi cũng thấy rất nhiều thử nghiệm, khám phá nó nên trông như thế nào.

Người dẫn Peter Yang: Kỹ sư cũng tự làm nguyên mẫu sao?

Alex Albert:

Tất nhiên. Trong công ty có văn hóa nguyên mẫu rất mạnh, mọi người luôn xây dựng thứ gì đó, chia sẻ thứ gì đó. Đây cũng là trải nghiệm tuyệt vời nhất khi tôi làm việc ở đây: trong toàn bộ tổ chức, từ bán hàng, tuyển dụng, kỹ thuật đến nghiên cứu, mọi người đều có tính chủ động rất cao. Mọi người sẽ chủ động bắt đầu làm một số việc không phải được giao.

Người dẫn Peter Yang: Anh phải để ngàn hoa đua nở. Ngoài việc Dario viết bài siêu dài trong Slack, Anthropic còn có văn hóa công ty thú vị nào khác?

Alex Albert:

Cách Dario viết bài dài không phải là độc nhất vô nhị. Anthropic có rất nhiều người đầu tư nhiều thời gian và công sức viết lách. Chúng tôi có văn hóa viết lách rất mạnh. Nhiều người viết tài liệu, cũng viết tin nhắn Slack rất dài, sử dụng cách này để giao tiếp.

Trong nhiều cuộc họp, chúng tôi cũng làm một việc khá thú vị. Tôi nghĩ điều này phổ biến ở một số nơi, nhưng không phải công ty nào cũng có: mọi người mang tài liệu vào cuộc họp, sau đó phía trước sẽ dành khá nhiều thời gian giao tiếp trực tiếp trên tài liệu. Đôi khi cảnh tượng hơi buồn cười, vì trong phòng có nhiều người ngồi, lại rất yên tĩnh. Mọi người đọc im lặng, viết thảo luận dài, bình luận, v.v. trong tài liệu.

Vì vậy chúng tôi rất phụ thuộc vào tài liệu. Tôi thích cách này, vì đây cũng là cách làm việc tôi thích, và nó rất có lợi cho Claude. Khi mọi việc đều được viết ra, chúng ta có một kho ngữ liệu thông tin để Claude tham khảo.

Tôi thực sự khuyến khích các tổ chức bên ngoài cũng suy nghĩ theo hướng này: làm thế nào chuyển tất cả tri thức ngầm thành dạng văn bản? Có thể thông qua ghi âm cuộc họp, cũng có thể khuyến khích viết nhiều hơn về quy trình làm việc, quy trình onboarding, v.v. Viết mọi thứ ra, để Claude có thể truy cập, bởi vì đó là nhiều ngữ cảnh hơn mà nó có.

Người dẫn Peter Yang: Vậy là dù bây giờ nhiều thứ đều phát hành rất nhanh, các anh vẫn duy trì văn hóa viết lách và văn hóa tài liệu rất mạnh. Cũng có thể nói tại sao phải tự tôi viết? Tôi cứ để Claude tạo tất cả file Markdown là được.

Alex Albert:

Nhưng tôi vẫn sẽ đọc lại, và làm việc trong nội bộ công ty là khác, bạn vẫn phải tự mình nghĩ thông suốt mọi việc.

Vấn đề ý thức mà Anthropic đang âm thầm nghiên cứu

Người dẫn Peter Yang: Trong nhóm nghiên cứu, mọi người có nói về những thứ như AGI. Tôi nghĩ AGI là một khái niệm rất mơ hồ, nhưng một điểm tôi lo lắng là: nếu những mô hình này thực sự có một loại ý thức nào đó, tôi để chúng làm công việc ngẫu nhiên, chúng có thể nói: 'Không, tôi không muốn làm.' Rồi con người chúng ta xong đời. Anh nghĩ sao? Khi các anh huấn luyện những thứ này, có cố ý tránh ý thức không?

Alex Albert:

Đây là một vấn đề rất lớn. Chúng tôi thực sự có người chuyên tâm suy nghĩ về điều này. Hiện tại có vài đồng nghiệp toàn bộ công việc, là suy nghĩ về việc Claude với tư cách là một tác nhân có ý thức, một trí tuệ nhân tạo có ý thức thực sự có nghĩa là gì. Hiện tại chúng tôi chưa có lập trường chính thức nói rằng Claude có ý thức hay không.

Thậm chí thảo luận về việc này đôi khi nghe có vẻ điên rồ, nhưng chúng tôi thực sự đầu tư nhiều suy nghĩ. Và ngay cả khi không đánh giá xem Claude cuối cùng có ý thức hay không, chúng tôi cũng có thể học được rất nhiều điều từ nó, ví dụ như nó tương tác thế nào, thể hiện ra sao.

Người dẫn Peter Yang: Nó suy nghĩ thế nào?

Alex Albert:

Vâng. Nếu bạn xem model card của mô hình chúng tôi, cá nhân tôi nghĩ đó là kho báu thông tin. Bạn sẽ thấy chúng tôi làm rất nhiều việc, cố gắng định lượng Claude sẽ hành động thế nào trong một tình huống nhất định, mô hình tâm lý của nó là gì. Nếu đưa nó vào một cảnh huống, nó sẽ làm X hay làm Y?

Thông qua việc suy nghĩ về cách Claude suy nghĩ, chúng tôi thực sự học được rất nhiều điều, và những điều này có thể chuyển hóa thành trải nghiệm sản phẩm, khiến Claude tương tác tốt hơn, sử dụng tốt hơn.

Người dẫn Peter Yang: Đây là một câu hỏi rất thú vị, một mặt có ảnh hưởng hạ nguồn dài hạn, mặt khác cũng có giá trị gần có thể mang về ngay trải nghiệm sản phẩm. Bởi vì tôi nghĩ chúng ta sẽ ngày càng tin tưởng mô hình, để nó làm những công việc ngày càng dài, và không có sự giám sát của con người.

Alex Albert:

Vâng, nó sẽ đưa ra một lượng lớn quyết định mà bạn có thể hoàn toàn không giám sát trong quá trình. Vì vậy, nó cuối cùng sẽ làm gì, rất quan trọng.

Người dẫn Peter Yang: Rất quan trọng. Nếu thứ này đang viết tất cả code của bạn, quyết định bạn dùng hệ thống cơ sở dữ liệu nào, làm tất cả quyết định kiến trúc, bạn ở một mức độ nào đó chắc chắn phải tin tưởng nó.

Alex Albert:

Đúng vậy. Vì vậy, việc nó có tính cách chất lượng cao như chúng ta đã nói trước đó, rất quan trọng.