Phỏng vấn đầu tiên của Jeff Dean sau khi rời Google: Những chia sẻ đầy sức nặng

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400">

21/08/2026 12:05:11 Nguồn: QbitAI

Một trong những lý do rời Google: Các đội ngũ nhỏ có thể tập trung tối đa!

Meng Yao đưa tin từ Aofeisi

QbitAI | Kênh chính thức QbitAI

Phải thừa nhận là thời kỳ đầu, khả năng lập trình (Coding) của Gemini thực sự chưa được tốt lắm...

Phải nói là "Jeff" (Jeff Dean) vẫn rất thẳng thắn~

Trong buổi phỏng vấn công khai đầu tiên kể từ khi rời Google, ông ấy không hề giấu giếm mà trực tiếp thực hiện màn "Cựu nhân viên đánh giá sếp cũ"!

Tại sự kiện Frontier & Pioneer Symposium 2026 ở Stanford, Jeff Dean đã chia sẻ một mạch về nhiều chủ đề mà trước đây hiếm khi được công khai—

Từ lý do rời Google, tại sao Gemini từng chưa tốt, bí quyết nghiên cứu khoa học của bản thân, cho đến việc công ty mới Discovery Loop sắp tới sẽ đặt cược vào điều gì... tất cả đều được ông chia sẻ hết trong buổi phỏng vấn.

Sau khi nghe trọn vẹn buổi trò chuyện, có thể thấy mật độ thông tin là cực kỳ cao. Tôi đã giúp các bạn tóm tắt lại một vài nhận định cốt lõi mà Jeff đã đưa ra lần này—

Dưới đây là nội dung ghi chép trọng tâm của buổi phỏng vấn, được chọn lọc xoay quanh các quan điểm chính, một số đoạn văn đã được biên tập lại đôi chút mà không làm thay đổi ý nghĩa gốc~

Khả năng lập trình của Gemini thời kỳ đầu thực sự còn thiếu sót

Q: Nhìn lại quá trình phát triển Gemini, điều gì khiến ông bất ngờ nhất? Có kinh nghiệm nào có thể ảnh hưởng đến các hệ thống AI thế hệ tiếp theo không?

Jeff Dean: Gemini thực chất là kết quả hội tụ của một vài dự án nghiên cứu sớm hơn bên trong Google—

Bao gồm DeepMind trước đây, Google Brain và một số công việc từ các nhóm khác thuộc Google Research.

Khi đó, chúng tôi dần nhận ra rằng mọi người thực chất đều đang đi theo những hướng rất giống nhau.

Ví dụ như việc liên tục mở rộng quy mô mô hình, đồng thời cũng có nhiều nhóm đang nghiên cứu cách để mô hình ngôn ngữ sở hữu khả năng đa phương thức (multimodal), giúp nó có thể hiểu được các thông tin như hình ảnh.

Vì vậy, tôi đã viết một bản ghi nhớ (Memo) dài một trang, tôi nghĩ rằng việc mỗi người làm một kiểu như vậy thật ngớ ngẩn, chúng ta nên cùng nhau thực hiện.

Tập hợp nhân sự, ý tưởng và tài nguyên tính toán của mọi người lại để huấn luyện một mô hình có khả năng đa phương thức ngay từ đầu, quy tụ những nhân tài xuất sắc nhất từ nhiều tổ chức nghiên cứu bên trong Google.

Sau đó, tôi cùng Oriol Vinyals khởi xướng dự án Gemini, đảm nhiệm vai trò đồng lãnh đạo kỹ thuật ban đầu để thực sự gắn kết các đội ngũ này lại với nhau.

Nhìn lại bây giờ, việc để mô hình có khả năng đa phương thức ngay từ đầu là một quyết định vô cùng thành công.

Bởi vì nếu bạn muốn một mô hình cuối cùng có thể được sử dụng cho mọi việc, nó cần phải hiểu đồng thời văn bản, ngôn ngữ, mã nguồn (code), hình ảnh, video, âm thanh và các phương thức khác.

Khi đó, chúng tôi thậm chí còn đưa một chút dữ liệu LiDAR vào dữ liệu huấn luyện, ít nhất là để mô hình biết đến sự tồn tại của loại dữ liệu này, vì sau này khi huấn luyện sâu hơn cho Gemini, nó có thể trở thành một kịch bản ứng dụng quan trọng.

Nhưng lúc đó chúng tôi muốn mô hình thể hiện tốt ở nhiều khía cạnh, nên tôi nghĩ rằng chúng tôi đã hơi chậm trễ trong việc chú trọng làm sao để khả năng lập trình (Coding) của Gemini thực sự gây kinh ngạc.

Sau đó chúng tôi đã nhận ra điều này và luôn nỗ lực bắt kịp, hiện tại đã có một số công việc rất tốt đang được triển khai.

Hơn nữa, tôi nghĩ Coding thực sự là một khả năng rất quan trọng.

Khi bạn chuyên tâm nâng cao khả năng lập trình của mô hình, cuối cùng bạn thường sẽ nhận được một hệ thống giỏi suy luận hơn, bởi vì việc viết code đòi hỏi mô hình phải xử lý vấn đề từng bước một, chia nhỏ một vấn đề phức tạp thành nhiều vấn đề con và giải quyết từng cái một.

Vì vậy, khi khả năng Coding được cải thiện, khả năng này thường cũng sẽ chuyển đổi sang nhiều tác vụ không liên quan đến lập trình.

Thừa nhận TensorFlow từng có hai sai lầm rõ rệt

Q: Nhìn lại TensorFlow, có những thiết kế nào mà hôm nay ông sẽ cân nhắc lại? Nếu làm lại từ đầu bây giờ, những điểm nào sẽ được thực hiện khác đi?

Jeff Dean: Tôi nghĩ chúng tôi đã làm sai một vài việc vào thời điểm đó.

Thứ nhất, ban đầu chúng tôi đã không thêm chế độ Eager Execution.

Sau này, cách tiếp cận này trở nên rất phổ biến trong các framework như PyTorch và JAX, TensorFlow sau đó cũng đã bổ sung nó vào, tôi nghĩ điều này thực sự làm cho toàn bộ cấu trúc trừu tượng trở nên tốt hơn.

Một vấn đề khác là khi chúng tôi mở mã nguồn (open source) TensorFlow, chúng tôi đã tạo ra một thư mục con tên là "contrib", cho phép nhiều nhà phát triển bên ngoài đóng góp các thư viện hỗ trợ và các phương thức triển khai khác nhau.

Sau đó, điều này đã gây ra sự nhầm lẫn khá lớn cho cộng đồng, vì dần dần trở thành một việc nhưng có tới mười cách làm khác nhau, bạn nên dùng cách nào lại phụ thuộc vào việc bạn sử dụng thư mục con nào hay thư viện nào trong "contrib".

Nhìn lại bây giờ, lẽ ra chúng tôi nên giữ cho cốt lõi của TensorFlow tinh gọn hơn và coi những thứ đó là các thư viện bên ngoài được xây dựng dựa trên cốt lõi.

Nếu làm lại lần nữa vào hôm nay, chúng tôi sẽ không thiết kế như vậy nữa.