Scaling interpretability

• Nhóm Khả năng Tương tác của Anthropic đã thành công trong việc mở rộng quy mô kỹ thuật học từ điển (dictionary learning) để diễn giải các đặc trưng bên trong Claude 3 Sonnet, chuyển từ mô hình ngôn ngữ nhỏ bé sang mô hình AI quy mô sản xuất. Đây là một nỗ lực kỹ thuật khổng lồ, diễn ra trong nhiều tháng.
• Họ đã phát hiện ra các đặc trưng có khả năng diễn giải cao, thể hiện sự hiểu biết sâu sắc của mô hình về các khái niệm phức tạp như nhận diện hàm số trong mã, chủ nghĩa thuần chay, và thậm chí là cửa hậu trong mã, thường có tính đa phương thức và đa ngôn ngữ.
• Dự án nhấn mạnh rằng việc áp dụng một thuật toán đơn giản, có khả năng mở rộng như bộ tự mã hóa thưa thớt (sparse autoencoder), kết hợp với các giải pháp kỹ thuật phức tạp như phân mảnh tăng cường (upsharding) và xáo trộn dữ liệu song song đa giai đoạn (multi-stage parallel shuffling) cho khối lượng dữ liệu petabyte, có thể mang lại những hiểu biết sâu sắc đáng ngạc nhiên về cách thức hoạt động của các hệ thống AI.

• Kỹ thuật dictionary learning và sparse autoencoders là các phương pháp khả thi để trích xuất các đặc trưng có thể diễn giải từ các mô hình ngôn ngữ lớn, ngay cả ở quy mô sản xuất.
• Mở rộng quy mô các kỹ thuật diễn giải từ các mô hình nghiên cứu nhỏ lên các hệ thống AI lớn đòi hỏi nỗ lực kỹ thuật lặp lại và sự hợp tác chặt chẽ giữa các nhóm nghiên cứu và kỹ thuật.
• Các đặc trưng nội bộ của LLM tiên tiến có thể thể hiện mức độ hiểu biết khái niệm phức tạp đáng ngạc nhiên, bao gồm nhận diện khái niệm đa phương thức (văn bản và hình ảnh), đa ngôn ngữ và trừu tượng.
• Các đặc trưng đa phương thức (ví dụ: một đặc trưng kích hoạt cho cả lỗ hổng mã và hình ảnh liên quan) cho thấy LLM hình thành các biểu diễn sâu, tích hợp thay vì chỉ đơn thuần ghi nhớ dữ liệu đầu vào.
• Khi mở rộng quy mô hệ thống AI lên khối lượng dữ liệu petabyte, các phương pháp xử lý dữ liệu truyền thống (ví dụ: xáo trộn trong bộ nhớ) không còn phù hợp và cần các giải pháp phân tán mới như xáo trộn song song đa giai đoạn.
• Phân mảnh tăng cường (upsharding), tức là phân phối các tham số của bộ tự mã hóa thưa thớt trên nhiều GPU, là một cách tiếp cận kỹ thuật cần thiết để huấn luyện các mô hình này ở quy mô lớn.
• Thành công của các thuật toán đơn giản, có khả năng mở rộng khi được áp dụng cho tập dữ liệu lớn có thể vượt trội so với các phương pháp phức tạp hơn nhưng khó mở rộng, nhấn mạnh tầm quan trọng của kỹ thuật cho khối lượng dữ liệu lớn.

• Interoperability Team — Nhóm Khả năng Tương tác
• Dictionary learning — Học từ điển
• Interpretability — Khả năng diễn giải
• Sparse autoencoder (SAE) — Bộ tự mã hóa thưa thớt
• Upsharding — Phân mảnh tăng cường
• Multi-stage parallel shuffling — Xáo trộn song song đa giai đoạn
• Multimodal — Đa phương thức
• Latent states — Trạng thái tiềm ẩn
• Feature — Đặc trưng / Tính năng

Giới thiệu & Mục tiêu Dự án

Josh Batson và tôi ở đây cùng các thành viên khác của Nhóm Khả năng Tương tác tại Anthropic để nói về một số công việc kỹ thuật đã thực hiện trong bản phát hành lớn gần đây của chúng tôi về việc diễn giải bên trong Claude 3 Sonnet. Vậy chúng ta hãy bắt đầu với phần giới thiệu, Jonathan, bạn là ai? Tôi là Jonathan Marcus. Tôi đã làm việc trong Nhóm Khả năng Tương tác trong tám tháng dài đáng kinh ngạc trước khi đến đây. Trước đó, tôi đã làm việc tại Jump Trading, thực hiện tài chính định lượng khoảng 13 năm. Tuyệt vời, Adley. Vâng, tên tôi là Adley. Tôi cũng ở trong Nhóm Khả năng Tương tác. Tôi đã ở đây làm những công việc liên quan đến Nick Shale learning và Adwin Carter khoảng 14 tháng qua. Trước đó, tôi làm việc về suy luận mô hình ngôn ngữ lớn hiệu quả tại một công ty khởi nghiệp khác. T.C.? Vâng, tôi là Tom hay T.C. Tôi đã làm việc trong Nhóm Khả năng Tương tác khoảng một năm qua, làm việc về dictionary learning. Trước đó, tôi làm việc tại cùng công ty với Jonathan, Jump, thực hiện giao dịch tần suất cao. Và trước đó nữa, tôi ở Facebook năm năm, làm công việc suy luận backend ở đó.

Lý do chúng tôi có mặt ở đây bây giờ là vì gần đây đã có một bản phát hành lớn về khả năng diễn giải. Các bạn đã cố gắng làm gì ở đó và tại sao? Vâng, tôi nghĩ cách tốt nhất để mô tả điều này là vào năm ngoái, chúng tôi đã xuất bản một bài báo có tên Towards Monocentricity, thực sự chứng minh rằng kỹ thuật này có thể hoạt động để trích xuất các đặc trưng có thể diễn giải trên một mô hình ngôn ngữ nhỏ bé. Và sau đó, trong những tháng kể từ đó, chúng tôi đã mở rộng quy mô kỹ thuật này cho đến khi chúng tôi đạt được khả năng trích xuất các đặc trưng thực sự tốt từ một trong những mô hình AI đang được Anthropic triển khai vào sản xuất. Bạn có thể giúp tôi hiểu sự khác biệt giữa một mô hình ngôn ngữ nhỏ và mô hình AI mà bạn đã xử lý cho công việc này không?

Sự khác biệt giữa Mô hình Ngôn ngữ Nhỏ và Lớn

Vâng, mô hình ngôn ngữ nhỏ đó sẽ rất khác so với bất kỳ mô hình ngôn ngữ nào bạn đã thực sự sử dụng. Chẳng hạn, nếu bạn cố gắng hỏi nó bất kỳ loại câu hỏi nào mà bạn nghĩ một mô hình ngôn ngữ sẽ rất giỏi, nó sẽ hoàn toàn thất bại. Nó chỉ là một mô hình rất, rất kém. Vì vậy, nó hữu ích cho công việc ban đầu mà chúng tôi đang làm vì chúng tôi nghĩ nó có nhiều cấu trúc tương tự như một mô hình lớn, nhưng nó nhỏ hơn nhiều nên dễ làm việc hơn. Tuy nhiên, nó hầu như không hữu ích cho bất kỳ tác vụ thực tế nào. Và ngay cả khi bạn hỏi nó một câu hỏi khá cơ bản như "Mèo kêu thế nào?", tôi không tự tin rằng nó sẽ trả lời đúng. Nó sẽ không làm tôi kinh ngạc. Không, tôi không nghĩ vậy. Nhưng có lẽ chúng tôi chưa thực sự thử.

Vì vậy, thay vào đó, một phép ẩn dụ hay là: tám tháng trước, chúng tôi nói, "Này, tôi nghĩ trái đất được làm bằng đất." Và thế là chúng tôi có một mũi khoan cầm tay và khoan xuống vài inch, kiểu như, "Này, có đất ở đó." Và bây giờ chúng tôi đã tạo ra một mũi khoan laser khổng lồ và đi sâu vào lớp phủ đầu tiên, kiểu như, "Này, có dung nham ở đó." Tôi đoán người đó là bạn. Ai đó. Ai đó. Tôi nghĩ đó là một ý hay, bạn nói điều đó thực sự in sâu vào tôi vì nó giống như, vâng, về mặt kỹ thuật, đó là điều tương tự. Và vâng, chúng tôi mong đợi có dung nham ở đó. Nhưng đó là một nỗ lực kỹ thuật rất lớn để thực sự khoan xuống và tìm ra những gì ở bên dưới. Và chúng tôi thực sự đã tìm thấy nhiều điều mà chúng tôi mong đợi. Nhưng thật tuyệt vời khi chúng tôi đã đạt được điều đó.

Tôi nghĩ điều tôi muốn thêm vào đó là cảm giác thỏa mãn khi nhìn vào những Mô hình ngôn ngữ lớn (LLM) có thể thực hiện tất cả những điều thực sự mạnh mẽ này. Vì vậy, trong mô hình một lớp, chúng tôi đã tìm thấy các đặc trưng, nhưng các đặc trưng đó tương ứng với những thứ như đếm đến 10 và tạo ra chuỗi ký tự và số ngẫu nhiên mà bạn thấy sau các URL. Và khi bạn mở rộng quy mô điều này lên một mô hình mạnh mẽ hơn nhiều, cùng một kỹ thuật có thể tìm thấy các đặc trưng thực sự thú vị, không chỉ từ góc độ khoa học, mà còn đại diện cho các chủ đề có sắc thái thú vị và thực sự có thể làm sáng tỏ cách hệ thống AI có thể thực hiện các tác vụ rất khó. Và đặc biệt, Mô hình ngôn ngữ lớn (LLM) có thể thực hiện các tác vụ mà chúng ta không biết cách lập trình máy tính để làm. Chúng thực sự có tất cả những khả năng mà chúng ta không hiểu. Và vì vậy, nếu bạn có thể tìm thấy các đặc trưng từ chúng, thì bạn thực sự có thể có được thông tin chi tiết hấp dẫn về cách chúng có thể làm những điều này.

Các Đặc trưng Đáng Chú ý

Những đặc trưng nào bạn thấy là ấn tượng hoặc gây xúc động nhất đối với bạn? Tôi thực sự thích tính năng nhận diện các hàm cộng số trong mã và nó không quá hẹp, không chỉ kích hoạt trên các hàm rõ ràng là a + b. Mà nếu có một hàm nào đó gọi một hàm khác đang thực hiện phép cộng, thì đặc trưng đó cũng được kích hoạt. Vì vậy, nó có một hiểu biết sâu sắc hơn về ý nghĩa của một hàm cộng so với hàm cơ bản. Tôi nghĩ điều đó thật siêu tuyệt vời và có lẽ đáng ngạc nhiên khi nó tồn tại. Nhưng đối với nhiều đặc trưng này, khi bạn nhìn thấy chúng lần đầu, bạn sẽ bị sốc. Và sau đó khi bạn suy nghĩ kỹ hơn, bạn sẽ nghĩ, "Ồ vâng, điều đó có vẻ là một điều hữu ích và rất hợp lý để mô hình thực hiện." Có lẽ tôi không nên ngạc nhiên đến thế khi nó ở đó.

Tôi nhớ lần đầu tiên tìm thấy tính năng chủ nghĩa thuần chay, nó thực sự rất thú vị. Tôi không ngờ sẽ thấy nó. Nó thậm chí không phải là mô hình lớn nhất. Không phải người thuần chay, nhưng xin lỗi. Nhưng thật thú vị khi thấy cùng một mô hình có thể nhận diện khái niệm không ăn thịt, lo lắng về chăn nuôi công nghiệp và không mặc đồ da, nhưng cũng bằng nhiều ngôn ngữ khác nhau. Và việc nó có thể kết nối tất cả các khái niệm này lại với nhau đã làm tôi không thể tin vào những gì mình đang thấy. Mô hình AI thực sự, bạn biết đấy, nó không chỉ lặp lại những từ ngẫu nhiên một cách bừa bãi. Nó chắc chắn đã có sẵn kết nối này trong mô hình, rất cụ thể. Và chúng tôi chỉ đơn giản là khám phá ra nó. Và điều đó thực sự làm tôi kinh ngạc.

Tính năng Đa phương thức và Đa ngôn ngữ

Vâng, tôi nghĩ một trong những điều khá ấn tượng đối với tôi là hiểu được cách mô hình tư duy về những thứ này. Tôi nghĩ rằng khi Mô hình ngôn ngữ lớn (LLM) bắt đầu phát triển, có một quan niệm rằng có lẽ chúng chỉ lặp lại những điều chúng đã thấy trong dữ liệu huấn luyện. Và khi nó nói điều gì đó, đó là vì có một câu rất tương tự ngoài kia. Và nó chỉ đơn giản là lấy nó và sau đó đưa cho bạn bất cứ điều gì ai đó đã nói trong ngữ cảnh đó. Nhưng khi thấy những đặc trưng đa phương thức, đa ngôn ngữ về một điều gì đó. Bạn có ý gì khi nói đa phương thức? Đa phương thức, ý tôi là hình ảnh của vật thể kích hoạt cùng một đặc trưng với văn bản của vật thể đó.

Một trong những điều tôi yêu thích là có một tính năng về cửa hậu trong mã mà cũng kích hoạt trên hình ảnh của ổ đĩa USB bị hack và các hình thức âm mưu khác nhau. Vâng, vâng, tôi nghĩ có khoảng năm hoặc sáu thiết bị khác nhau với camera ẩn trong đó và nó kích hoạt cho các camera ẩn khác nhau trong các đồ vật hàng ngày. Điều này, khi khi nhìn lại, có vẻ hoàn toàn hợp lý. Nhưng tôi chắc chắn sẽ không thể đoán được điều đó. Đúng vậy, phần mô hình thực sự nhận ra một dòng mã có vấn đề sẽ là điều tương tự như việc có một chiếc chảo có camera trong đó. Vâng. Và sau đó bạn thậm chí có thể kích hoạt một cách nhân tạo điều đó và nói, "Này, bạn có thể hoàn thành hàm của tôi không?" Và nó sẽ viết mã đó trong khi giới thiệu một lỗ hổng tinh vi có thể bị hack sau này. Điều đó thực sự làm tôi kinh ngạc. Tôi thực sự đánh giá cao việc Claude đã đủ tử tế để gán nhãn hàm là cửa hậu. Còn bất kỳ điều yêu thích nào khác không?

Thử nghiệm Golden Gate Claude

Chúng ta có thể nói về Golden Gate Claude không? Vâng, ý tôi là Golden Gate Claude rất vui. Golden Gate Claude là gì? Golden Gate Claude chính xác là gì? Golden Gate Claude là một đặc trưng trong bài báo của chúng tôi. Đó là tiêu đề chính và chúng tôi thực sự thích nó, nơi Claude sẽ kích hoạt dựa trên các mô tả về cầu Golden Gate. Bạn biết đấy, cây cầu hùng vĩ, mang tính biểu tượng, cao chót vót giữa Moran và San Francisco. Vì vậy, ai đó đã có ý tưởng tuyệt vời, "Này, bạn có nghĩ chúng ta có thể nói chuyện với Golden Gate Claude không?" Và đây là phần yêu thích của tôi về Anthropic. Tôi nghĩ điều này sẽ khó khăn. Nhưng sau đó, một người từ nhóm kỹ thuật chỉ cần vào cơ sở mã của chúng tôi, tìm ra nó và triển khai Golden Gate Claude như một thử nghiệm, kiểu như, "Này, bạn có nghĩ tôi có thể thực sự lấy kết quả từ bài báo dictionary learning của bạn và sử dụng nó không?" Và sau đó chúng tôi đã thử và nó đã hoạt động. Và sau đó mọi người bắt đầu chơi với nó. Đó là một trải nghiệm tuyệt vời khi kết quả bài báo của chúng tôi được hiện thực hóa như vậy. Vâng, thật đáng kinh ngạc.

Chúng tôi công bố bài báo vào sáng thứ Ba và sau đó tất cả chúng tôi đi ăn tối vào tối thứ Ba. Và mọi người trong công ty rất hào hứng với hình ảnh đó, khi chúng tôi bật tính năng Golden Gate và hỏi Claude, "Hình dạng vật lý của bạn là gì?" Claude nói rằng đó là cây cầu Golden Gate hùng vĩ. Và đó chỉ là một thứ tĩnh. Và Oliver nói, "Hãy làm điều đó. Hãy tạo Golden Gate Claude." Và trong khi chúng tôi đang ăn uống và ăn mừng, họ bắt đầu làm việc và 36 giờ sau, chúng tôi đã có một sản phẩm hoàn chỉnh có thể được phát hành và thế giới đã có thể nói chuyện với một mô hình AI có đặc trưng này mà chúng tôi chỉ mới khám phá vài tuần trước đó đã được khuếch đại và có cảm giác về ý nghĩa của việc điều khiển mô hình theo hướng này hay hướng khác.

Thách thức Mở rộng Quy mô Dictionary Learning

Vì vậy, tôi biết mô hình rất lớn. Claude thực sự lớn so với những mô hình chúng tôi đã làm việc trước đây. Bạn đã phải làm gì để áp dụng kỹ thuật dictionary learning để tìm các đặc trưng và mở rộng quy mô nó để hoạt động trên một thứ như vậy? Vâng, trước hết, tôi chỉ muốn nói rằng đây là một câu hỏi rất dài để trả lời vì đây có lẽ là phần lớn công việc của chúng tôi giữa việc xuất bản Towards Monocentricity và việc xuất bản bài báo này. Giống như có rất nhiều điều và chúng ta nên đi sâu vào chúng, nhưng tôi chỉ muốn nhấn mạnh rằng chúng ta sẽ không thể nói về một phần nhỏ những điều đã phải làm ở đây vì đây là một nỗ lực thực sự lớn.

Tôi cũng muốn đặt vấn đề theo một cách hơi khác. Khi chúng tôi lần đầu tiên nhận được kết quả trong Towards Monocentricity và bắt đầu nghĩ về những gì chúng tôi sẽ làm tiếp theo. Chúng tôi không ngay lập tức nói, "Ồ, chúng ta sẽ mở rộng quy mô này lên Sonnet. Điều này chắc chắn sẽ hoạt động." Chúng tôi không biết liệu điều này có hoạt động ở quy mô lớn hơn không, vì vậy chúng tôi không muốn dành tám tháng chỉ để mở rộng quy mô và sau đó kiểm tra xem nó có thực sự hoạt động không. Vì vậy, đó là một sự qua lại giữa bộ phận kỹ thuật và bộ phận nghiên cứu để xem chúng ta có thể làm những thử nghiệm nào để mở rộng quy mô này nhằm mang lại cho chúng ta sự tự tin hơn rằng việc mở rộng quy mô thực sự có tác dụng. Vì vậy, nó không phải là một thứ nguyên khối mà chúng ta có thể lập kế hoạch. Đó là một điều mà chúng tôi đã mở rộng quy mô theo từng phần, xác nhận rằng điều này vẫn ổn và sau đó mở rộng quy mô hơn khi chúng tôi có thêm sự tự tin.

Mở rộng Quy mô: Ví dụ về Upsharding

Vậy việc mở rộng quy mô thực sự trông như thế nào? Tôi nghĩ một ví dụ ở đây rất minh họa. Đây là điều xuất hiện khá sớm trong quá trình chúng tôi mở rộng quy mô, khi chúng tôi đang làm việc trên Towards Monocentricity, tất cả các mô hình của chúng tôi đều nằm gọn trên một GPU duy nhất. Mỗi bộ tự mã hóa thưa (sparse autoencoder) mà chúng tôi huấn luyện đều nằm gọn trên một GPU duy nhất. Và điều chúng tôi nhận ra rất nhanh là nếu bạn cứ tiếp tục mở rộng quy mô này, nó sẽ không còn hoạt động nữa. Bạn sẽ phải nối một loạt GPU lại với nhau và triển khai một thứ mà chúng tôi gọi là phân mảnh tăng cường (upsharding), nơi bạn lấy các tham số của bộ tự mã hóa thưa và phân phối chúng trên một số lượng lớn GPU.

Sparse Autoencoder là gì?

Vậy bộ tự mã hóa thưa là gì? Có lẽ không phải ai cũng biết chúng là gì? Vậy thì, một bộ tự mã hóa (autoencoder) là một thứ nhận vào một số dữ liệu, một vectơ và biến đổi nó thành một biểu diễn khác mà từ đó bạn có thể đọc lại dữ liệu gốc. "Auto" ở đây có nghĩa là bạn nhận lại dữ liệu gốc; "encoder" là khi bạn thay đổi biểu diễn. Bộ tự mã hóa thưa (sparse autoencoder) là một loại bộ tự mã hóa mà biểu diễn mới bạn nhận được rất thưa thớt.

Bộ Tự Mã Hóa Thưa Thớt và Khả Năng Diễn Giải

Chỉ có một vài phần tử khác không ở đó. Và điều này thực sự hữu ích vì nếu bạn đang cố gắng hiểu ý nghĩa của dữ liệu này là gì? Và có chính xác ba phần tử khác không trong mã hóa. Bạn chỉ cần xem xét từng phần tử đó, trong khi nếu véc-tơ ban đầu có hàng nghìn thành phần hoặc tương tự, thì có thể nó sẽ không có ý nghĩa gì. Và thử nghiệm cơ bản mà chúng tôi thực hiện ở đây, điều khiến tôi bất ngờ là nó đã hoạt động, là chúng tôi đã lấy một số trạng thái tiềm ẩn (các véc-tơ bên trong Claude), huấn luyện một bộ tự mã hóa thưa thớt để xem liệu chúng tôi có thể biểu diễn chúng chỉ bằng một vài mảnh mỗi lần hay không. Và câu trả lời là có. Và sau đó, khi chúng tôi xem xét từng mảnh, chúng có khả năng diễn giải đáng kinh ngạc.

Từ góc độ toán học, tôi nghĩ một bộ tự mã hóa thưa thớt thực sự đơn giản. Chỉ có hai ma trận liên quan. Từ góc độ kỹ thuật, tôi nghĩ nó hóa ra lại không hề đơn giản chút nào. Và bạn có thể viết lại phép toán từ bài báo của chúng tôi vào tháng Mười. Và chúng tôi có thể sao chép và dán về cơ bản cùng một phép toán vào bài báo của chúng tôi bây giờ. Và đó không phải là cách nó hoạt động trên phần cứng. Ôi trời ơi!

Tôi nghĩ một trong những điều thực sự thú vị ở đây đối với tôi là khi chúng tôi bắt đầu dự án này vào năm ngoái, chúng tôi đã thử nghiệm rất nhiều kỹ thuật khác nhau cho nó. Và chúng tôi đã thử nghiệm nhiều kỹ thuật phức tạp hơn. Có rất nhiều phép toán phức tạp ngoài kia giải quyết vấn đề này. Có thể phép toán đó vẫn hoạt động tốt hơn, nhưng chúng tôi thực sự đã thấy rất nhiều thành công với bộ tự mã hóa thưa thớt vì bạn có thể thực sự mở rộng quy mô chúng lên. Chúng tôi đã thử chạy tất cả các kỹ thuật khác này, nhưng bạn chỉ có thể chạy chúng trên một lượng dữ liệu nhỏ. Và một trong những điều chúng tôi nhận ra là để thấy được kết quả thực sự tốt, bạn phải chạy nó trên rất nhiều dữ liệu, nhiều hơn đáng kể so với bất kỳ ai trong tài liệu toán học cổ điển đã từng làm.

Và vì vậy, bộ tự mã hóa thưa thớt theo một cách nào đó thực sự đơn giản đến kinh ngạc một cách đẹp đẽ. Và đó chỉ là triết lý rằng nếu bạn lấy một thuật toán đơn giản, có khả năng mở rộng, và bạn có thể thực sự tăng các con số lên, bạn có thể nhận được những thứ thực sự tuyệt vời từ nó. Nhưng việc tăng các con số lên, đó mới là phần khó.

Thách Thức Mở Rộng Quy Mô và Xáo Trộn Dữ Liệu

Tôi hầu như không làm toán. Bạn làm toán. Bạn làm toán. Nhưng có rất nhiều, rất nhiều công việc liên quan đến việc, này, hãy làm cho thứ này lớn hơn gấp 10, 100, 1000 lần, v.v. Và điều đó phá vỡ tất cả các khái niệm trừu tượng, phá vỡ tất cả mã của chúng ta theo rất nhiều cách khác nhau. Nó trở nên quá lớn ở tất cả các khía cạnh mà bạn không lường trước được, hoàn toàn không chuẩn bị. Nó gây ra các lỗi kỳ lạ. Tôi nghĩ một trong số các bạn đã nói với tôi rằng một trong những khía cạnh đó liên quan đến việc xáo trộn dữ liệu. Ai đó đã giải thích vấn đề xáo trộn là gì và bạn phải làm gì.

Vâng, vậy là có một vấn đề vốn đã khó trong học máy là bạn có dữ liệu đầu vào của mình. Và bạn muốn đảm bảo rằng nếu bạn có rất nhiều A, rất nhiều B, rất nhiều C và rất nhiều D, và bạn đưa chúng qua mô hình của mình, nếu bạn chỉ đưa chúng vào theo một thứ tự, nó sẽ học, này, tôi chỉ nên học A. Này, tôi chỉ nên học B. Nhưng nếu tất cả bị trộn lẫn, thì nó phải học toàn bộ phân phối ở mỗi bước.

Và quá trình xáo trộn này rất dễ dàng khi dữ liệu của bạn nhỏ. Bạn chỉ cần tải vào bộ nhớ, bạn biết đấy, thực hiện xáo trộn ngẫu nhiên và sau đó ghi lại. Điều đó không quá khó. Bây giờ bạn có dữ liệu petabyte thì làm thế nào? Giống như, ồ, vậy tôi đoán nó có thể giống như nếu bạn phải xáo trộn một bộ bài, bạn có thể làm điều đó bằng tay. Đúng vậy. Và nếu ai đó đưa cho bạn bảy dặm bài liên tiếp được xếp chồng lên nhau, thì không rõ bạn sẽ xáo trộn bộ bài đó như thế nào. Vâng, thực ra, đó là một phép loại suy rất hay. Đúng vậy, giống như tôi có một trăm nhà kho đầy thẻ bài. Vâng.

Và vì vậy chúng tôi đã làm, tôi cuối cùng như chúng tôi đã nói rất nhiều, đã tìm ra, này, có cách nào để làm điều này song song không? Và nó giống như, tốt, nếu bạn xáo trộn một trăm nhà kho thẻ bài, trước tiên bạn sẽ xáo trộn một nhà kho thẻ bài và bạn sẽ chia thành một trăm vấn đề con và sau đó làm thế nào để tôi xáo trộn 101 nhà kho thẻ bài? Tôi sẽ chia nhỏ và làm theo từng phần. Và sau đó bạn sẽ trộn các phần khác nhau theo một cách nào đó, một cách có thể chứng minh được để đảm bảo rằng mỗi phần được trộn lẫn với mọi phần khác. Và như, tôi không biết, điều đó nghe có vẻ rất đơn giản. Và một cách nào đó, sau khi chúng tôi đã hiểu vấn đề rằng ồ, chúng tôi chỉ cần thực hiện xáo trộn song song đa giai đoạn này, nơi chúng tôi chia nhỏ nó ra, giống như ồ, có lẽ bất kỳ ai cũng có thể, không phải bất kỳ ai, nhưng nhiều người có thể triển khai nó như một phần của một buổi phỏng vấn lập trình. Đó không phải là một bài toán thuật toán quá khó.

Nhưng để đạt đến điểm mà chúng tôi thậm chí nhận ra điều đó, ồ, việc chỉ cần đặt vấn đề đã chiếm 90% công việc. Một khi chúng tôi đã làm điều đó và chúng tôi có thể khái niệm hóa rằng ồ, chúng tôi cần thực hiện một xáo trộn song song đa giai đoạn. Và sau đó, một khi bạn đã định nghĩa đúng cách đệ quy của mình, thì việc mở rộng nó ra là một tác vụ khá dễ dàng. Ồ, bạn muốn xử lý 100 terabyte, bạn muốn xử lý 10 petabyte. Tuyệt vời. Chỉ cần thêm một lớp nữa.

Ưu Tiên và Đánh Đổi trong Kỹ Thuật Nghiên Cứu

Tôi nghĩ một số ngữ cảnh nữa ở đây khá thú vị vì chúng ta sẽ tập trung vào phần sau khi chúng tôi quyết định tăng tốc quá trình xáo trộn. Nhưng tôi nghĩ phần trước đó cho thấy rất nhiều về bản chất của công việc này, nơi chúng tôi đang mở rộng mọi thứ và sau đó chạy các thử nghiệm khi chúng tôi mở rộng. Và bước xáo trộn trước khi chúng tôi cải thiện nó đã mất nhiều thời gian hơn. Vì vậy, chúng tôi biết rằng bước này không mở rộng tốt và nó làm chậm quá trình thu được kết quả nghiên cứu. Nhưng chúng tôi cũng biết có điều gì đó tốt hơn ở đó, nhưng không phải là điều tôi có thể làm trong vài giờ. Tôi đã nghĩ, ồ, điều này có thể mất vài ngày, vài tuần. Vì vậy, chúng tôi đã trì hoãn nó vì chúng tôi vẫn có thể nhận được kết quả thử nghiệm cho đến khi cuối cùng điều này mất 24 giờ, hoặc tương tự. Và chúng tôi kiểu, được rồi, cuối cùng chúng ta cần phải khắc phục điều đó.

Và sau đó tôi nghĩ rằng giải pháp mà chúng tôi đã thực hiện có thể làm điều gì đó hoàn hảo hơn hoặc hoàn toàn giải quyết được vấn đề xáo trộn. Nhưng chúng tôi không tập trung vào việc tối ưu hay ý tưởng Platonic của xáo trộn song song. Điều chúng tôi quan tâm là công việc của chúng tôi đang mất 24 giờ. Làm thế nào để nó không mất 24 giờ?

Vì vậy, tôi nghĩ rất nhiều về công việc này là chúng tôi muốn nhận được kết quả thử nghiệm. Đó là trọng tâm của chúng tôi. Và sau đó với mục tiêu đó, làm thế nào để bạn đạt được chúng? Vì vậy, thông thường không phải là làm thế nào để bạn làm cho bất kỳ bước nào trở nên hoàn hảo? Mà là làm thế nào để bạn làm cho bất kỳ bước nào đủ tốt để có được kết quả mà chúng ta cần ngay bây giờ. Và sau đó khi những kết quả đó trở lại, bạn sẽ có được nhiều hay ít niềm tin vào phương pháp bạn đang áp dụng. Và khi bạn có nhiều niềm tin hơn rằng cơ sở mã và phương pháp này là thứ chúng ta sẽ sử dụng sáu tháng sau, một năm sau, bạn sẵn sàng đầu tư nhiều thời gian hơn để làm mọi thứ tốt hơn. Và tôi nghĩ bản chất của công việc là làm thế nào để bạn thực hiện đánh đổi đó về việc đầu tư bao nhiêu thời gian vào bất kỳ phần nào của toàn bộ quy trình này?

Kỹ Thuật Nghiên Cứu so với Phát Triển Sản Phẩm

Tôi muốn làm rõ điều đó hơn. Nghe có vẻ như loại kỹ thuật mà có một kết quả thử nghiệm ở cuối lại là một quy trình khác so với việc có lẽ tạo ra một sản phẩm. Bạn có thể nói thêm về việc làm kỹ sư cho nghiên cứu thì như thế nào không? Vâng, tôi nghĩ thật thú vị khi so sánh nó với công việc đầu tiên của tôi tại Facebook và tôi đang xây dựng một dịch vụ back-end cung cấp năng lượng cho trang web Facebook. Và tôi sẽ nói rằng sự khác biệt lớn là các yêu cầu về mã ở công việc đó tại Facebook hầu như không bao giờ thay đổi. Chúng tôi luôn biết rằng điều này sẽ chạy ở quy mô lớn. Nó không thể gặp sự cố. Chúng tôi quan tâm đến chi phí máy chủ mà chúng tôi đang chạy.

Nhưng tôi đã ở đó vài năm và nó luôn có cùng mục tiêu, trong khi ở một công việc kỹ thuật nghiên cứu bây giờ, bạn không biết phần nào của mã bạn sẽ vứt bỏ trong hai tuần nữa và phần nào của mã bạn sẽ sử dụng nhiều năm sau đó. Và rất nhiều mã học từ điển ban đầu là các phương pháp mà chúng tôi đã xóa, chúng đã biến mất. Chúng tôi sẽ không bao giờ chạm vào nó. Và dành thời gian để làm cho mã đó hoàn hảo sẽ hoàn toàn lãng phí vì nó đã bị xóa. Nhưng cũng trong suốt quá trình kéo dài một năm này, chúng tôi đã tập trung vào những gì chúng tôi đang làm đang hoạt động và điều cốt lõi này là tốt. Chúng tôi cần làm cho điều này tốt hơn. Chúng tôi sẽ sử dụng nó lâu hơn. Và nếu chất lượng mã kém, nó sẽ làm chúng tôi chậm lại trong nhiều năm. Vì vậy, chúng tôi thực sự cần phải đi và trau chuốt điều này nhiều hơn. Vì vậy, tôi nghĩ bạn liên tục phải giữ những đánh đổi đó trong đầu và chúng thay đổi khi bạn làm việc.

Dự đoán Thiết kế Hạ tầng và Khắc phục Lỗi

Có một khía cạnh khác của vấn đề này mà tôi muốn nói thêm là có rất nhiều ý tưởng mà chúng tôi muốn thử. Và khi bạn xem xét việc triển khai những ý tưởng này, bạn đang nghĩ về cách thiết kế cơ sở hạ tầng. Và giống như bất kỳ thiết kế phần mềm nào, một số thiết kế cơ sở hạ tầng sẽ làm cho một số việc dễ dàng và một số việc khó khăn. Vì vậy, có một điều thực sự nan giải và tôi nghĩ theo một cách nào đó đó là một vấn đề bất khả thi và bạn chỉ có thể cố gắng làm điều này một cách rất kém. Nhưng cố gắng dự đoán những hướng bạn muốn đi trong tương lai, cố gắng dự đoán những loại ý tưởng chung nào bạn có thể muốn thử và cố gắng dự đoán làm thế nào để chúng ta làm cho những loại chung này dễ dàng hơn. Và chúng ta đang đóng lại điều gì? Chúng ta đang làm gì trở nên khó khăn hơn? Và cố gắng thực hiện những đánh đổi đó là một thách thức thực sự, thực sự khó khăn mà chúng tôi cố gắng hết sức nhưng đó là điều không thể hoàn hảo được.

Bạn có mắc lỗi lớn nào không? Không. Tôi nghĩ nhiều lỗi ở đây cảm giác giống như chúng tôi lẽ ra nên dọn dẹp thứ gì đó sớm hơn một tháng. Vì vậy, nó giống như ồ, có lẽ chúng tôi nên làm điều này sớm hơn nhưng vì các đánh đổi của bạn đang thay đổi, nếu bạn nên làm, giống như nếu bây giờ bạn đang kiểu tôi không thực sự chắc chắn liệu chúng ta có nên làm điều này hay không, trong một tháng nữa nó thường hiển nhiên đến mức khó tin. Giống như ồ vâng, chúng tôi chắc chắn nên làm điều đó. Vì vậy, bạn mất một tháng đó giống như sẽ tốt hơn nếu bạn đến đó sớm hơn. Nhưng tôi thường nghĩ rằng cuối cùng bạn sẽ được đẩy theo đúng hướng.

Nhưng tôi cũng nghĩ rằng có một điểm quan trọng là tôi không phải là một nhà khoa học chuyên nghiệp chỉ tìm cách công bố bài báo. Tôi cũng không phải là một kỹ sư chuyên nghiệp chỉ tìm cách xây dựng một hệ thống hoàn hảo, đẹp đẽ, hài hòa, được trừu tượng hóa tốt nhất. Giống như chúng tôi có một mục tiêu cụ thể là có thể tìm ra và thực hiện đủ khoa học để tìm ra khả năng diễn giải để chúng tôi biết những cỗ máy này hoạt động như thế nào để đạt được một mục tiêu an toàn cụ thể. Rằng chúng ta phải làm đủ khoa học để đạt được điều đó. Tôi phải xây dựng đủ thứ kỹ thuật để hỗ trợ khoa học nhưng cuối cùng rất có thể vào cuối ngày chúng ta sẽ vứt bỏ mọi thứ chúng ta đã xây dựng ngoại trừ một kết quả cuối cùng đó. Và vì vậy tôi không muốn dành thêm thời gian nghiên cứu những thứ không hữu ích. Tôi không muốn dành thêm thời gian xây dựng những thứ không hữu ích. Và việc thực hiện đánh đổi đó là siêu khó. Tôi không phải lúc nào cũng giỏi về điều đó nhưng các bạn thì khác. Nhìn lại thì mọi thứ cũng luôn dễ dàng hơn. Vậy lỗi khó hiểu nhất trong quá trình này là gì?

Thử thách Xác Minh Mã Học Máy

Vâng, một trong những phần thực sự nguy hiểm của học máy, và đặc biệt là khi bạn đang thực hiện học máy trên chủ đề kỳ lạ, chưa được khám phá này, là rất khó để biết liệu bạn đã viết mã của mình đúng hay chưa. Tôi nhớ giáo sư học máy của tôi đã nói với tôi điều này ở trường đại học và tôi đã nghĩ rằng điều đó không có vẻ khó lắm. Điều này không thể là một vấn đề lớn đến vậy. Và sau đó bạn nhận ra rằng đây chính là điều sẽ tiêu tốn nhiều thời gian của bạn hơn bất kỳ vấn đề nào khác.

Xử lý Lỗi trong Các Chỉ số Đánh giá (Evaluation Metrics)

Chúng tôi đã gặp phải những trường hợp mất hàng tuần công sức vì có một thứ gì đó và chúng tôi có một số evaluation metrics (chỉ số đánh giá). Evaluation metrics bị lỗi theo cách khiến chúng có vẻ quá tốt để tin và rất thú vị, và chúng tôi đã dành rất nhiều thời gian để theo đuổi điều đó trước khi nhận ra rằng có một lỗi rất tinh vi trong các metrics của chúng tôi, và rất khó để kiểm tra điều đó. Về cơ bản, bạn phải dành nhiều thời gian engineering để đảm bảo rằng những thứ này hoạt động và bạn có thể tin tưởng vào các đánh giá của mình. Lỗi trong metrics rất đáng sợ vì nếu bạn cố gắng làm cho con số giảm xuống và con số đó đang giảm, bạn sẽ nghĩ: "Tuyệt vời, mọi thứ đều tốt đẹp," rồi hóa ra bạn chỉ đang theo đuổi một ảo ảnh hoàn toàn trong nhiều tuần.

Vậy, làm thế nào để đối phó với điều đó? Việc testing (kiểm thử) đối với mã nghiên cứu thì như thế nào? Tôi nghĩ rằng các lỗi về độ chính xác như vậy rất khó kiểm thử vì không rõ đâu là câu trả lời đúng. Vì vậy, các unit tests (kiểm thử đơn vị) cổ điển của bạn không thực sự hiệu quả trong trường hợp này. Tôi nghĩ điều hữu ích ở đây là ghi lại càng nhiều metrics càng tốt trong quá trình training (huấn luyện). Bạn có thể nghĩ ra mọi con số có thể ghi lại, sau đó vẽ đồ thị chúng, và sau các lần chạy, bạn có thể nhìn vào những đồ thị này và tự hỏi: "Nó trông như thế nào? Nó có hợp lý không?" Và tôi nghĩ không có câu trả lời dễ dàng nào ở đây; chỉ là cần thời gian.

Tôi nghĩ một phần khác của vấn đề này là thực sự xem xét mã một cách cẩn thận và tự nhủ: "Tôi biết math (toán học) cho ML (Máy học) nói rằng nó phải làm điều này, nhưng nó thực sự đang làm gì?" Và chúng tôi đã có một số lần điều đó không khớp, và tôi nghĩ việc theo dõi những điều đó là rất quan trọng. Tôi cũng muốn nói rằng có những lỗi tiềm ẩn trong master mà bạn lo lắng. Tôi nghĩ có một cách khác mà điều này xuất hiện: mỗi khi bạn có một ý tưởng mới về cách ML sẽ thay đổi, bạn sẽ code (viết mã) nó và chạy nó. Sau đó, đôi khi kết quả là: "Ồ, điều này tệ hơn baseline (đường cơ sở) của bạn," và bạn không thực sự chắc chắn: "Ý tưởng đó tệ, hay khi tôi viết mã, nó bị lỗi?" Và bạn không biết. Tôi nghĩ đó là một sự đánh đổi khó khăn về việc phải làm gì tiếp theo, bởi vì bạn có thể đi và xem mã, bạn có thể đi và xem graphs (đồ thị) và cố gắng hiểu: "Liệu điều này có bị lỗi theo một cách nào đó không?" Nhưng đến một lúc nào đó, bạn phải quyết định: "Ý tưởng này không hiệu quả, và tôi bỏ cuộc, tôi chuyển sang thứ khác."

Đánh Đổi Giữa Ngắn Hạn và Dài Hạn trong Kỹ thuật Nghiên cứu

Một trong những điều nổi bật đối với tôi, người có nền tảng chính xác hơn khi làm việc trong một nhóm các engineer (kỹ sư) thực sự có kỹ năng, là nhận ra sức mạnh của việc đẩy một số công việc engineering về phía trước để tăng iteration time (thời gian lặp lại) của bạn. Tôi nghĩ rằng ý tưởng của bạn càng quan trọng, bạn càng muốn dành nhiều thời gian để suy nghĩ. Nhưng nếu bạn không biết điều gì sẽ hiệu quả hay không, thì việc tạo điều kiện để bạn có thể kiểm tra nhiều ý tưởng một cách nhanh chóng thực sự mang lại hiệu quả lớn. Và kiểu nhìn nhận không ngừng này: "Làm thế nào tôi có thể chạy thử nghiệm này? Được thôi, liệu tôi có thể chạy thử nghiệm đó trong một ngày thay vì một tuần? Tôi có thể chạy nó trong một giờ thay vì một ngày? Tôi có thể khởi động nó trong một phút không?" Và ý tưởng của bạn có thể tốt hơn, nhưng không ai có những ý tưởng tốt hơn đến 200 lần đến mức bạn thà mất nhiều thời gian để chạy một thử nghiệm. (Người nói thứ hai: "Tự nói về mình thôi.")

Tôi nghĩ điều này quay trở lại sự đánh đổi giữa ngắn hạn và dài hạn, mà tôi nghĩ thực sự chỉ là một trong những căng thẳng cơ bản khi thực hiện loại research engineering (kỹ thuật nghiên cứu) này. Nơi bạn phải quyết định bao nhiêu nỗ lực để đầu tư vào việc làm cho mọi thứ tốt hơn về dài hạn so với việc bạn muốn thử một cái gì đó, thử nó theo cách tệ nhất có thể và nhận được kết quả nhanh chóng. Và tôi nghĩ rằng, không giống như trong nhiều engineering truyền thống, bạn không chỉ muốn nghiêng hoàn toàn về phía điều dài hạn. Nó phụ thuộc vào nhiều yếu tố: nó phụ thuộc vào mức độ tự tin của bạn rằng một thứ gì đó trong lĩnh vực chung này sẽ hoạt động; nó phụ thuộc vào mức độ bạn nghĩ rằng infrastructure (cơ sở hạ tầng) này sẽ có thể tái sử dụng trong tương lai; và việc code (viết mã) và làm cho nó hoạt động tốt sẽ dễ dàng đến mức nào.

Nhưng nó cũng, bạn biết đấy, được thông báo bởi science (khoa học) về việc "Chúng ta có nghĩ rằng dictionary learning là một quy trình mà chúng ta nên dồn toàn lực vào không?" Đó là việc có niềm tin, được hướng dẫn bởi scientific intuition (trực giác khoa học) của chúng ta, rằng nếu chúng ta tiếp tục đẩy mạnh ở đây, chúng ta đang đẩy một cách mù quáng. Chúng ta không thực sự biết liệu chúng ta có đang tiến tới bất cứ đâu hay không cho đến khi chúng ta đào đủ sâu và, "Ồ, có dung nham!" Giống như, nó chỉ là rất nhiều đất, và rồi đột nhiên bạn kéo lên và bạn nhận ra: "Ôi trời ơi, chúng ta thực sự đã đi xa đến vậy và chúng ta thực sự đã tìm thấy một cái gì đó!" Nhưng trong một thời gian, bạn chỉ đang mò mẫm trong bóng tối, và không có gì hoạt động, không có gì trông tốt, không có gì hợp lý. Nhưng bạn chỉ cần tin rằng nếu chúng ta tiếp tục researching (nghiên cứu) theo hướng này, có thể có dấu hiệu của sự sống, và cuối cùng chúng ta sẽ thấy điều gì đó hữu ích.

Động lực cá nhân: Khám phá so với Khả năng Dự đoán

Câu hỏi cá nhân: Tại sao bạn thích làm công việc này? Với tôi, ở các vai trò trước đây tại công ty, tôi từng làm việc trong inference team (đội suy luận). Đội suy luận có ít khía cạnh research (nghiên cứu) hơn nhiều. Chúng tôi gần như biết chính xác các operations (thao tác) cần thực hiện, math (toán học), và chúng tôi chỉ cần làm cho chúng chạy thật nhanh. Và điều đó dẫn bạn đến những vấn đề systems (hệ thống), low-level GPU optimization (tối ưu hóa GPU cấp thấp) thực sự thú vị. Nhưng đối với tôi, giống như tôi có thể lập kế hoạch cho sáu tháng tới sẽ như thế nào. Bạn có thể hình dung: "Chúng ta sẽ thiết kế nó chính xác như thế này, và chúng ta cần làm A, B, C và D," và bạn có một kế hoạch chính xác như vậy, rồi bạn thực hiện nó. Và tôi thấy công việc thực hiện kế hoạch chính xác đó hơi tedious (tẻ nhạt) hoặc boring (nhàm chán). Có rất nhiều người ở công ty yêu thích điều đó; cá nhân tôi thì không. Trong khi đó, ở đội này, chúng tôi không thể lập kế hoạch trước sáu tháng, phải không? Và chúng tôi không biết thực sự phải xây dựng cái gì, và bạn đang đi theo nơi mà research results (kết quả nghiên cứu) dẫn dắt, và mọi thứ luôn thay đổi. Vì vậy, tôi thực sự yêu thích khía cạnh đó của công việc này.

Động lực của Adley: Khoa học thần kinh tính toán trên Trí tuệ nhân tạo

Adley, bạn thích điều gì ở công việc này? Vâng, tôi nghĩ có hai câu hỏi ở đó: tại sao tôi yêu thích phần research (nghiên cứu) và tại sao tôi yêu thích phần engineering (kỹ thuật), bởi vì thực sự tôi yêu cả hai. Và tôi yêu thích phần research chỉ vì, thành thật mà nói, không có cách nào tốt hơn để mô tả ngoài việc "đây thực sự là một vấn đề đẹp đẽ", và rất hấp dẫn khi cố gắng hiểu điều này. Và cảm giác thật tuyệt vời khi bạn có thể chiếu một chút ánh sáng nhỏ vào black box (hộp đen) của các mô hình (AI model).

Một trong những điều tôi thích về điều này là engineering rất thú vị, chắc chắn rồi, nhưng đó cũng là bản thân vấn đề. Giống như, và điều này quay trở lại câu hỏi: "Tại sao tôi thích, điều này so sánh thế nào với công việc trước đây của tôi làm quant finance (tài chính định lượng) so với công việc này?" Chỉ riêng việc nghiên cứu markets (thị trường) đã thực sự rất hấp dẫn. Chúng luôn thay đổi, có rất nhiều modeling (mô hình hóa) thú vị cần thực hiện. Nhưng ở đây, về cơ bản chúng ta đang thực hiện computational neuroscience (khoa học thần kinh tính toán) trên một artificial mind (trí tuệ nhân tạo). Và chưa ai từng làm điều đó trước đây trong lịch sử vì những thứ này chưa từng tồn tại. Chưa ai từng làm – chúng ta giống như một trong những người đầu tiên hiện nay có quyền tiếp cận với artificial minds là rất lớn với lượng computational infrastructure (cơ sở hạ tầng tính toán) cần thiết để analyze (phân tích) chúng. Chúng ta thực sự đang cố gắng tìm hiểu cách những thứ này suy nghĩ. Chúng ta đang nghiên cứu cognition (nhận thức) theo một quantitative way (cách định lượng) rất sâu sắc. Và điều đó thật mind-blowing (gây kinh ngạc) đối với tôi khi gần như cùng một skill set (bộ kỹ năng) mà tôi trước đây dùng để dự đoán price (giá) tiếp theo giờ đây trở thành decoding thought (giải mã suy nghĩ). Và tôi đã yêu thích finance (tài chính) trong nhiều năm, nhưng điều này đối với tôi có ý nghĩa hơn rất nhiều.

Và tôi nghĩ phần thực sự thú vị khi cố gắng giải quyết những vấn đề này bằng engineering là nó khiến chúng trở nên solvable (có thể giải quyết được). Nếu bạn tự hỏi: "Làm thế nào để bạn làm neuroscience trên một artificial mind?" thì đó không phải là loại vấn đề mà bạn thực sự sẽ giải quyết, hoặc có thể bạn có thể giải quyết nó, nhưng bạn không có sự tự tin cao vào bất cứ điều gì. Có điều gì đó về việc xây dựng infrastructure để làm điều này và xây dựng infrastructure để thực hiện nhiều experiments (thí nghiệm) khiến bạn cảm thấy có thể nói: "Chúng ta thực sự sẽ làm được điều này." Engineering chỉ là một cách để biến điều này thành công và khả thi.

Lời Khuyên cho Kỹ sư muốn tham gia Nghiên cứu AI

Vậy, đối với những người đang lắng nghe chúng tôi và thấy điều này khá thú vị, bạn có lời khuyên nào về việc tham gia interpretability research (nghiên cứu khả năng diễn giải) hoặc AI research (nghiên cứu AI) từ góc độ engineering (kỹ thuật) không? Điều đầu tiên tôi muốn nói là, tôi nghĩ nhiều người cho rằng công việc của interpretability team (nhóm khả năng diễn giải) đòi hỏi nhiều research skill set (bộ kỹ năng nghiên cứu) hơn thực tế. Tức là, research skill set rất quan trọng, nhưng engineering skill set (bộ kỹ năng kỹ thuật) cũng thực sự, thực sự quan trọng. Vì vậy, chúng tôi không chỉ tìm kiếm những người chỉ làm math (toán học) và ML (Máy học). Chúng tôi cần những người rất giỏi coding (lập trình) nữa. Và hiện tại, chúng tôi đang bị bottlenecked (thắt nút cổ chai) bởi việc tuyển dụng những engineer rất, rất giỏi. Vì vậy, chúng tôi cần thêm những người như vậy nộp đơn xin việc sẽ là điều đầu tiên. Bạn có thể làm gì nếu bạn quan tâm đến điều này và bạn là một engineer giỏi? Hãy hỏi chúng tôi về một công việc, vì chúng tôi đang tuyển dụng những người như bạn. Điều đó nghe có vẻ ngớ ngẩn, nhưng tôi nghĩ rất dễ underestimate (đánh giá thấp) những contributions (đóng góp) mà bạn có thể thực hiện, đặc biệt nếu bạn tự coi mình là một engineer khi tham gia vào lĩnh vực này. Và lời khuyên thực sự là chỉ cần apply (nộp đơn).

Điều khác tôi muốn lưu ý về engineering skill sets, kiểu như những gì chúng tôi đang tìm kiếm, những gì mọi người có thể học, là tôi nghĩ chúng tôi cần nhiều breadth (kiến thức rộng). Chúng tôi không – giống như, chúng tôi cần làm cho GPUs (đơn vị xử lý đồ họa) chạy nhanh cho công việc chúng tôi làm, nhưng chúng tôi không đẩy mọi thứ đến bleeding edge (công nghệ tiên tiến nhất), phải không? Vì vậy, chúng tôi cần những người có thể thực hiện nhiều skills (kỹ năng) khác nhau và đến và nhận thấy: "Ồ, tôi có thể thực hiện một thay đổi nhanh chóng mang lại cho chúng ta một win (thắng lợi) lớn." Chúng tôi không phải là những người – chúng tôi không thực sự tìm kiếm skill set của: "Tôi có thể dành hai tháng để sử dụng graphics card (card đồ họa) hiệu quả hơn 10% ở đây."

Tầm quan trọng của Kỹ năng Kỹ thuật Đa diện

Chúng ta sẽ không dành hai tháng cho việc đó; chúng ta sẽ chuyển sang, chẳng hạn như, song song hóa các tác vụ khác, tìm hiểu lý do tại sao một số mã Python thực sự chậm. Vì vậy, bạn cần có sự linh hoạt này để có thể xác định điểm nghẽn nằm ở đâu trong quy trình phức tạp này và tìm cách cải thiện nó trong vài ngày. Đó là một kỹ năng lớn mà chúng tôi thực sự rất muốn thấy nhiều hơn.

Có vẻ như nhóm có rất nhiều kỹ sư full stack, nơi stack có thể đi từ việc bạn có thể tạo một vài GPU kernels cho đến xây dựng các giao diện front-end để xem cách hình ảnh làm cho Claude hoạt động khác đi. Và bạn không bao giờ biết đâu trong toàn bộ chuỗi đó có thể là thứ bạn cần thực hiện. Chẳng hạn, có một lỗi front-end vào ngày nọ hóa ra lại là một lỗi upsharing. Bạn nghĩ rằng máy chủ đang từ chối yêu cầu của bạn, nhưng sau đó hóa ra là chúng tôi đã xáo trộn các tensor theo cách transpose, và đó mới là thứ cần được sửa. Vì vậy, thực tế có rất nhiều cách để đóng góp, và loại kiến thức rộng cũng như sự thông thạo này thực sự có thể mang lại lợi ích.

Hợp tác đa ngành và Giải pháp Tối ưu

Josh, bạn là một nhà khoa học hơn chúng tôi rất nhiều; tôi phải nói rằng tất cả chúng tôi đều thiên về kỹ thuật. Điều gì khiến bạn khó chịu nhất với những người như tôi? Ý tôi là, những người như bạn rất quyến rũ! Không, tôi không nghĩ có sự khó chịu nào cả. Tôi nghĩ nó tạo ra những sự hợp tác rất tốt bởi vì thường xuyên, bạn biết đấy, chúng ta đang ở những giai đoạn rất sơ khai, nên thường có rất nhiều chỗ để cải thiện. Và đôi khi hóa ra là chúng ta chỉ cần vẽ biểu đồ đúng chỉ số hoặc thay đổi sơ đồ khởi tạo cho một ma trận có thể tăng tốc quá trình huấn luyện lên 5 lần. Và cũng có thể bạn cần tăng tốc quá trình huấn luyện lên 5 lần thông qua song song hóa.

Vì vậy, tôi nghĩ rằng có những cơ hội như vậy. Điều tôi muốn nói về full stack thực sự kéo dài cho đến toán học và tất cả các phần của nó. Do đó, tôi nghĩ việc có một cách tiếp cận đa ngành cho những thứ này thực sự hữu ích, bởi vì đôi khi bạn có thể, bạn biết đấy, làm sắc bén như: "Bạn có thực sự cần chạy các quan hệ của mình trên toàn bộ tập dữ liệu không? Hay bạn đang cố gắng ước tính một vô hướng mà tại đó thống kê cho bạn biết bạn cần một nghìn mẫu là đủ, và bạn có thể tiết kiệm rất nhiều thời gian."

Tôi cũng thực sự thích điều đó, mặc dù bạn ở các tiểu đội riêng biệt, tôi không có đủ cơ hội làm việc với bạn. Tôi thực sự thích vài lần chúng tôi đã hợp tác vì tôi nghĩ chúng ta có những bộ kỹ năng bổ trợ tuyệt vời. Tôi đã nói trước đây: tôi không giỏi toán học. Tôi không... Tôi vẫn biết... Tôi xin lỗi các bạn, tôi sẽ rời đi, nhưng tôi thực sự thích văn hóa hợp tác cho phép chúng ta, như bạn và tôi, ngồi lại cùng nhau và lập trình cặp trên một vấn đề. Và chúng ta có những sở thích và kỹ năng rất bổ trợ, nơi khi chúng ta làm việc cùng nhau, chúng ta thực sự rất mạnh mẽ. Và tôi nghĩ đó là một bài học. Lý do tôi đưa ra điều này là dành cho những người đang cân nhắc, "Này, bạn có nghĩ tôi có thể tham gia vào interp và hữu ích không?" Thì câu trả lời là "Có, nếu bạn giỏi một số điều này, nhưng không phải tất cả." Có rất nhiều giá trị khi bạn làm việc cặp với những người khác có bộ kỹ năng khác nhau, và chúng tôi thực sự hưởng lợi từ sự hợp tác đó.

Tôi nghĩ rằng một trong những điều thực sự thú vị về việc này là bạn bắt đầu học hỏi từ những sự hợp tác đó — ví dụ như hình dạng của một vấn đề có thể được giải quyết — điều này diễn ra rất lâu trước khi có bất kỳ ý tưởng nào về cách giải quyết nó. Nhưng tôi nghĩ, "Hmm, tôi cá là Jonathan có thể giúp được phần này; mọi thứ có vẻ bế tắc và tôi chưa biết đủ để có thể làm điều đó." Nhưng sau đó chúng tôi có thể ngồi lại và nói, "Ồ vâng, đó là loại tác vụ mà tôi có thể hoàn thành nhanh chóng ngay bây giờ." Hoặc về phía trực quan hóa, tôi cảm thấy như mình đang nhấp chuột giữa 17 cửa sổ ngay bây giờ, và thực tế là chúng tôi đã giảm thiểu song song hóa; việc chạy các tác vụ này cực kỳ nhanh chóng, và bây giờ tôi mất khoảng 30 phút để xem kết quả. Và sau đó chúng tôi gọi Pierce và anh ấy nói, "Ồ vâng, vâng, chúng tôi hoàn toàn có thể cải thiện phần đó." Và khi bạn kết hợp tất cả lại với nhau, bạn sẽ có một hệ thống khoa học thực sự đáng kinh ngạc, nơi tất cả các phần đều hoạt động. Và, bạn biết đấy, những gì xuất hiện ở phía bên kia của một số bài báo đẹp nhất mà tôi nghĩ mình từng tham gia, hoặc thực sự đã khiến tôi tham gia nhóm, là bạn chỉ thấy những hình ảnh được trau chuốt tỉ mỉ này đến từ, bạn biết đấy, những người bị ám ảnh bởi việc làm việc trong Figma để đưa tất cả các chi tiết vào. Điều đó không phải là điều tôi nghĩ, bạn biết đấy, có lẽ làm việc trong Figma là một phần của bộ công cụ kỹ thuật tiêu chuẩn, nhưng hóa ra đó cũng là một yếu tố nhân rộng (force multiplier).

Cấu trúc nhóm: Nghiên cứu và Kỹ thuật đan xen

Vâng, một điều rõ ràng tôi muốn đề cập, đã được lồng ghép vào những câu trả lời đó, là cách nhóm được cấu trúc ở đây. Tôi nghĩ nhiều người nghĩ rằng có một nhóm nghiên cứu riêng và một nhóm kỹ thuật riêng. Và, xuyên suốt cuộc trò chuyện này, chúng tôi đã nói về sự tương tác giữa chúng. Vì vậy, việc tách rời chúng đơn giản là không hiệu quả; chúng tôi không làm điều đó. Không có những nhà nghiên cứu riêng biệt nói với các kỹ sư rằng "Hãy xây dựng cái này". Những vấn đề này về cơ bản là liên kết chặt chẽ với nhau, và bạn phải cùng nhau giải quyết chúng. Vì vậy, cách thức hoạt động của toàn bộ công ty, không chỉ nhóm khả năng diễn giải (interpretability team), là nghiên cứu và kỹ thuật luôn đi cùng nhau. Và điều đó hoàn toàn quan trọng đối với công việc này.

Thử thách Trực quan hóa Tính năng (Features)

Adley, nếu một người bạn đến hỏi bạn, "Điều gì là thú vị, kỳ lạ hoặc độc đáo nhất mà bạn đã làm?" Vâng, tôi nghĩ có một tập hợp vấn đề đáng ngạc nhiên xuất hiện sau khi bạn đã huấn luyện 34 triệu tính năng (features), và bây giờ, nghe có vẻ ngớ ngẩn, bạn muốn xem những tính năng này làm gì. Và đây là một vấn đề phức tạp khi mở rộng quy mô (at scale) bởi vì các tính năng này chỉ kích hoạt trên các chuỗi văn bản rất cụ thể — đó là ý nghĩa của từ "sparse" trong sparsato và couture.

Và vì vậy, nếu bạn thực sự muốn trực quan hóa tất cả chúng, bạn phải chạy rất nhiều tính năng thông qua rất nhiều văn bản và sau đó thực hiện những việc như: chúng tôi cũng muốn trực quan hóa xem tính năng này làm gì trên văn bản lân cận, và phân phối của tính năng này trông như thế nào, và giải quyết một loạt vấn đề như vậy. Tôi tin rằng ở thời điểm này, đó là một quy trình gồm khoảng 10 hoặc 12 bước được phân tán rất nhiều chỉ vì đây là một trong những thứ bị hỏng rất nhanh khi bạn mở rộng quy mô vấn đề. Và có rất nhiều bước đến nỗi luôn có thứ gì đó bị hỏng, và luôn có thứ gì đó khác trở thành điểm nghẽn. Và vì vậy, đây là quy trình chỉ cần nhìn vào điều này, tìm điểm nghẽn và cố gắng phân phối nó xa hơn.

Vấn đề Tính toán Ma trận ở Quy mô lớn

Vâng, đôi khi những thứ như nhân ma trận cũng không hoạt động nữa, khi bạn nhận ra rằng bạn muốn hiểu các tương tác (đây là trong nhóm của tôi) giữa 34 triệu tính năng ở đây và 34 triệu tính năng ở đó. Và thực sự, bạn có thể chỉ cần nhân các ma trận, nhưng sau đó bạn không thể lưu trữ kết quả ở bất cứ đâu hoặc đặt kết quả ở bất cứ đâu. Vì vậy, bạn bắt đầu thực hiện một số vòng lặp, đánh chỉ mục và nén phức tạp để tính toán một tích — chỉ đơn giản là các số lớn nhân với số lớn sẽ tạo ra các số rất lớn.

Một trong những điều chúng tôi gặp phải là triển khai chế độ bản đồ mặc định của PyTorch (default PyTorch map mode implementation) cho một số phép nhân ma trận hình dạng (shape matrix multiplies) nhất định chậm hơn nhiều. Vì vậy, chúng tôi đang phân tích hiệu năng công việc (profiling jobs), và chúng tôi nhìn vào nó, và hầu hết thời gian của chúng tôi là ở phép nhân ma trận. Vì vậy, chúng tôi nghĩ điều này thật tuyệt, chúng tôi đang chạy rất nhanh, nhưng chúng tôi tính toán số liệu hiệu quả, và hiệu quả không tốt. Vì vậy, chúng tôi sau đó tìm đến một người khác trong công ty có chuyên môn hơn trong lĩnh vực hẹp này, và anh ấy nói với chúng tôi rằng, "Ồ vâng, hãy thử triển khai phép nhân ma trận (matrix multiply implementation) khác; nó sẽ nhanh hơn nhiều." Và chúng tôi thường làm như vậy: khi chúng tôi gặp những vấn đề gai góc thực sự như vậy, chúng tôi chỉ cần hỏi người khác trong công ty vì chúng tôi không phải là chuyên gia trong lĩnh vực đó, nhưng điều đó vẫn quan trọng, và chúng tôi cần làm cho những thứ này nhanh hơn.

Tối ưu hóa phép nhân ma trận và những vấn đề "kỳ lạ"

Chúng tôi đang sử dụng một phiên bản chậm của phép nhân ma trận mà không hề hay biết. Đó là thiết lập mặc định, một phiên bản thường nhanh nhưng lại chậm đối với các hình dạng cụ thể của tensor mà chúng tôi đang chạy phép nhân ma trận. Có những cách triển khai khác nhau cho việc này. Về cơ bản, đối với phép nhân ma trận, điều thường xảy ra là dựa trên hình dạng của các ma trận, có những cách khác nhau mà các kernel GPU thực sự hoạt động. Một số triển khai chọn sai phương pháp và trở nên chậm ngẫu nhiên. Chúng tôi đã gặp phải những vấn đề như vậy: "Nó chậm ngẫu nhiên, làm sao để khắc phục đây?" Bạn không có thời gian để trở thành chuyên gia trong lĩnh vực này, bạn chỉ cần nhanh chóng tìm thứ gì đó để tăng tốc nó.

Tôi nghĩ đây là một ví dụ thú vị, vì bạn sẽ nghĩ rằng phép nhân ma trận đã được tối ưu hóa rất nhiều, nhưng theo một nghĩa vật lý, vấn đề của chúng tôi chỉ là một hình dạng kỳ lạ. Đó là một ma trận có hình dạng kỳ lạ, và vì vậy chúng tôi đã gặp phải tất cả những vấn đề này bởi vì nghiên cứu khả năng diễn giải (interpretability research) đang làm những điều thực sự kỳ lạ như thế này. Và vì vậy, bạn gặp phải tất cả những điều kỳ lạ xảy ra. Việc suy nghĩ về tính toán phân tán cũng khá buồn cười đối với trường hợp này. Chúng tôi đã thực hiện một số tính toán phân bổ (attribution calculations) nơi bạn chỉ nhân một vector với một loạt các vector khác, và bạn phải suy nghĩ cẩn thận về nơi chúng đang tồn tại và hướng bạn gửi thông tin, bởi vì nếu bạn gửi cái này qua đây, bạn có thể gửi một số scalar trở lại, nhưng nếu bạn gửi cái này qua đây, thì một ma trận sẽ được gửi đi và đột nhiên bạn đã mất rất nhiều thời gian để luân chuyển dữ liệu qua lại. Giống như, tôi đã được đào tạo thành một nhà toán học, bạn viết phương trình và tất cả các chữ cái đều nằm trên cùng một dòng, không có nút cổ chai giao tiếp (communication bottleneck) giữa a và v mà nó đứng cạnh.

Thách thức của việc mở rộng quy mô mã nguồn

Tôi đang xem một triển khai mã nguồn mở (open source) của huấn luyện bộ tự mã hóa thưa (sparse auto encoder training) chỉ chạy trên một card đồ họa (graphics card). Tôi đã rất sốc khi thấy: "Điều này thật đơn giản, thật dễ dàng, tại sao chúng ta lại có quá nhiều mã?" Và sau đó, bạn đi qua tất cả các điểm khác nhau mà chúng tôi đã phải mở rộng quy mô này lên gấp một nghìn lần, và nó giống như, đó là nơi tất cả mã này xuất phát. Có rất nhiều trận chiến nhỏ ở đó, chẳng hạn như "thứ ngẫu nhiên này không mở rộng được" hoặc "chậm gấp đôi", những điều mà chúng tôi đã phải thêm vào nhưng không cần thiết khi chúng tôi thực hiện các tác vụ rất nhỏ và chỉ vừa với một card đồ họa duy nhất.

Tôi nghĩ điều đó cũng nói lên sự bổ sung giữa công việc có thể xảy ra trong giới học thuật hoặc các môi trường mã nguồn mở (open source environments) và những gì bạn có thể làm tại một công ty với các mô hình đã được mở rộng quy mô. Bạn có thể thử rất nhiều ý tưởng ở quy mô nhỏ và nó không quá khó từ góc độ kỹ thuật. Nhưng để thực sự làm cho nó hoạt động trên các mô hình lớn hơn nhiều bậc, bạn đang bước vào những lĩnh vực khó khăn vật lý mới để đạt được bất cứ điều gì.

Bài học đắt giá và khả năng mở rộng

Đôi khi cảm thấy có một món quà, đó là trong "bài học đắt giá" (the bitter lesson) mà Richard Sutton nói đến, đôi khi thứ có thể mở rộng quy mô (scalable thing) lại tốt hơn vì bạn luôn có thể tăng thêm quy mô. Và nếu bạn thực hiện kỹ thuật (engineering) và đạt đến giới hạn trên của sự khéo léo, thì mặc dù một số phương pháp này khá đơn giản về mặt khái niệm, nhưng hóa ra trên các phân phối dữ liệu phong phú thực sự tạo nên các mạng này, chúng thể hiện những điều thực sự tuyệt vời.

Thật thú vị, tôi nghĩ rằng "bài học đắt giá" áp dụng không chỉ cho việc huấn luyện mô hình mà còn cho cả khả năng diễn giải. Nơi mà tôi nghĩ mọi người thường coi khả năng diễn giải như việc cố gắng có được sự hiểu biết rất có nguyên tắc, và có một phần của điều đó. Nhưng có rất nhiều thứ thực sự có cùng đặc tính với "bài học đắt giá", nơi bạn chỉ lấy một thứ đơn giản và thực hiện nó ở quy mô lớn, và bạn chọn thứ có thể mở rộng quy mô. Và đối với tôi, thật tuyệt vời khi điều đó không chỉ hiệu quả để tạo ra các mô hình tốt mà còn để hiểu các mô hình.

Một điểm khác tôi muốn đưa ra về mở rộng quy mô và "bài học đắt giá" là công ty đã cho chúng tôi quyền truy cập vào tài nguyên tính toán (compute) mà chúng tôi cần để thực sự mở rộng quy mô này. Và thật vui khi điều cản trở chúng tôi mở rộng quy mô hơn nữa là liệu học máy (ML) có thực sự hoạt động ở quy mô đó hay cơ sở hạ tầng (infrastructure) có hoạt động ở quy mô đó hay không. Nó không phải là liệu chúng tôi có thể thực sự có được các card đồ họa để chạy hay không, điều đó sẽ là một lý do gây nản lòng hơn nhiều để không thể mở rộng quy mô.

Tương lai của Khả năng diễn giải

Bạn thấy khả năng diễn giải ở đâu trong một năm tới? Tôi nghĩ rằng trong một năm tới, nếu mọi thứ diễn ra tốt đẹp – đây là một trường hợp cực kỳ lạc quan – chúng ta sẽ tìm ra được. Chúng tôi đã thực hiện một lát cắt qua lớp giữa của Sonnet, và tôi muốn phân tích toàn bộ mọi lớp, mọi phần của tất cả các mô hình sản xuất (production models) của chúng tôi, và không chỉ phân tích chúng. Hiện tại, chúng tôi chỉ tìm thấy các tính năng (features), chúng tôi không biết chúng kết hợp với nhau như thế nào, chúng tôi không biết chúng hoạt động như thế nào trong nhiều ngữ cảnh (contexts) khác nhau. Và tôi thực sự muốn chúng tôi thực hiện nghiên cứu mạch (circuits work) để tìm ra: những tính năng này có ý nghĩa gì khi đứng một mình? Chúng có ý nghĩa gì khi cùng hoạt động?

Vâng, một điều mà tôi nghĩ mình đang bất ngờ hào hứng là việc tiếp tục mở rộng quy mô này. Có rất nhiều điều chúng ta cần làm sẽ phải khác biệt. Chắc chắn sẽ có nhiều cơ hội để thay đổi cách chúng ta làm mọi thứ, nhưng đồng thời, những điều này dường như hoạt động tốt hơn khi bạn tiếp tục mở rộng quy mô chúng. Vì vậy, tôi thực sự hào hứng khi cố gắng vắt kiệt thêm vài bậc độ lớn cuối cùng và xem điều gì sẽ xảy ra. Và nếu bạn muốn giúp chúng tôi điều đó, chúng tôi đang tuyển dụng. Chúng tôi rất mong được làm việc với bạn.

Tôi có thể nói là tôi yêu cụm từ "vài bậc độ lớn cuối cùng" không? Có quá nhiều điều trong những từ ít ỏi đó.

Tầm quan trọng của Khả năng diễn giải

Vậy tại sao chúng ta lại thực hiện khả năng diễn giải? Tôi nghĩ một trong những điều tôi muốn nhấn mạnh ở đây là tôi có rất nhiều sự không chắc chắn về các loại thách thức an toàn (safety challenges) sẽ phát sinh với Mô hình ngôn ngữ lớn (LLM). Và tôi rất không chắc chắn về hướng đi của mọi thứ trong tương lai. Nhưng khả năng diễn giải mang lại cảm giác rất bền vững (robust) và tôi rất hào hứng khi làm việc với nó vì tôi nghĩ bạn có thể giúp giải quyết một loạt các vấn đề rộng lớn trong một loạt các kịch bản rộng lớn. Đơn giản là hiểu mô hình có vẻ tốt, và nếu bạn có thể làm điều đó tốt hơn, có lẽ sẽ hữu ích.

Vâng, hiểu mô hình có vẻ tốt, và nếu bạn có thể làm điều đó, có vẻ như nó sẽ giúp bạn với bất kỳ hành vi (behaviors) nào bạn có thể gặp phải. Và có lẽ đó là điều tôi thực sự thích ở khả năng diễn giải, hoặc đúng hơn là các phương pháp tiếp cận mà chúng tôi đang thực hiện, có tính chất "hoàn chỉnh" (completionist) – nó cố gắng lập bản đồ toàn bộ sự đa dạng của mô hình. Bởi vì nếu bạn có thể làm điều đó, bạn có thể phóng to vào các phần bạn cần sau này, trong khi nếu bạn chỉ tập trung vào một hành vi cụ thể được quan tâm, nó có thể không tổng quát (generalize) hoặc có thể bỏ lỡ phần quan trọng của câu chuyện. Và vì vậy, bạn có thể thực hiện khả năng diễn giải tập trung vào một hành vi tại một thời điểm, nhưng nếu bạn muốn toàn bộ bức tranh, bạn cần mở rộng quy mô. Và đó là lý do tại sao những người như những người đang ngồi ở bàn này có thể giúp việc mở rộng quy mô xảy ra. Bạn ở đây, bạn ở đây. Được rồi, tay vào, một, hai, ba. Claude, một, hai, ba.