không muốn Lặp lại chính mình *

Cách thiết kế thư viện nguồn mở cho máy học hiện đại

Ý tưởng thiết kế máy biến áp

"Đừng lặp lại chính mình", hay DRY, là một nguyên tắc phát triển phần mềm nổi tiếng. Nguyên tắc này xuất phát từ "The Pragmatic Programmer" (tên tiếng Anh: The pragmatic Programming), cho đến nay đây là cuốn sách được đọc nhiều nhất trong lĩnh vực thiết kế mã. Nguyên tắc này rất đơn giản và toàn diện: tái sử dụng thay vì viết lại logic hiện có ở nơi khác. Điều này đảm bảo rằng mã luôn được đồng bộ hóa, giúp bảo trì dễ dàng hơn và mạnh mẽ hơn. Cách thực hành này làm cho bất kỳ thay đổi nào đối với logic mã chung đều ảnh hưởng thống nhất đến tất cả các mã phụ thuộc vào logic mã chung đó.

Thoạt nhìn, thiết kế của thư viện máy biến áp Ôm Mặt đi ngược lại nguyên tắc DRY. Mã cho cơ chế chú ý đã được sao chép sang các tệp mô hình khác nhau không dưới 50 lần. Đôi khi toàn bộ mã mô hình BERT được sao chép vào các tệp mô hình khác. Khi cộng tác viên thêm mô hình mới, nếu mô hình mới sử dụng mô hình có sẵn, chúng tôi thường bắt họ sao chép toàn bộ mã của mô hình hiện có vào mã mô hình mới, ngay cả một điều chỉnh logic nhỏ cũng không phải là ngoại lệ. Tại sao chúng tôi làm điều này? Có phải vì chúng ta quá lười biếng hay chỉ vì chúng ta không đủ khả năng gánh vác khối lượng công việc tập trung tất cả logic công khai vào một nơi?

Không, chúng tôi không lười biếng - việc sử dụng nguyên tắc DRY trong thư viện máy biến áp không phải là cố ý. Chúng tôi quyết định áp dụng nguyên tắc thiết kế khác với DRY mà chúng tôi gọi là chính sách tệp mô hình đơn. Chính sách tệp mô hình đơn yêu cầu tất cả mã cho bất kỳ mô hình nào chỉ được đặt trong một tệp, đó là tệp mô hình của chính mô hình đó. Nếu người đọc muốn hiểu cách BERT thực hiện suy luận, họ chỉ cần đọc tệp model_bert.py của BERT. Thông thường, chúng tôi từ chối mọi nỗ lực trừu tượng hóa và tập trung các mô hình con giống hệt nhau của các mô hình khác nhau vào một tệp mới. Chúng tôi không muốn một Chú ý_layer.py chứa tất cả các cơ chế chú ý có thể có.

Tại sao chúng tôi thực hiện thiết kế này? Chúng tôi tóm tắt lý do như sau

• 1. Transformers ra đời bằng mã nguồn mở và phục vụ mã nguồn mở
• 2. Sản phẩm của chúng tôi là mẫu mã và khách hàng của chúng tôi là người dùng đọc hoặc sửa đổi mã mẫu.
• 3. Lĩnh vực học máy đang phát triển cực kỳ nhanh chóng.
• 4. Mô hình học máy là mô hình tĩnh.

1. Ra đời từ nguồn mở, phục vụ nguồn mở

Transformers tích cực khuyến khích sự đóng góp từ bên ngoài. Đóng góp thường rơi vào hai loại: sửa lỗi và bổ sung mô hình mới. Nếu ai đó tìm thấy lỗi trong tệp mô hình, chúng tôi muốn người đó có thể sửa lỗi đó một cách dễ dàng. Không có gì bực bội hơn việc sửa một lỗi nhưng lại phát hiện ra rằng nó gây ra 100 lỗi trên các mẫu máy khác.

Bởi vì mỗi mã mô hình độc lập với nhau nên người chỉ biết mô hình mà mình đang làm việc sẽ dễ dàng sửa nó hơn nhiều. Tương tự như vậy, nếu bạn chỉ cần thêm một tệp mô hình mới, việc thêm mã mô hình mới và xem xét PR tương ứng sẽ dễ dàng hơn. Những người đóng góp không cần phải tìm ra cách thêm chức năng mới vào mã gây chú ý của công chúng mà không phá vỡ các mô hình hiện có và những người đánh giá mã ngầm biết rằng hoạt động PR này sẽ không phá vỡ bất kỳ mô hình hiện có nào.

2. Mã model là sản phẩm

Chúng tôi giả định rằng nhiều người dùng thư viện máy biến áp sẽ không chỉ đọc tài liệu mà còn xem mã mô hình thực tế và có khả năng sửa đổi nó. Xem xét rằng thư viện về máy biến áp đã được phân nhánh hơn 10.000 lần và bài báo về máy biến áp của chúng tôi đã được trích dẫn hơn 1.000 lần, giả định này có thể chấp nhận được.

Vì vậy, điều quan trọng nhất là giúp người đọc mã model máy biến áp lần đầu tiên dễ dàng hiểu và sửa đổi nó. Việc bao gồm tất cả các thành phần logic cần thiết của mô hình trong một tệp mô hình duy nhất giúp cải thiện khả năng đọc và sửa đổi. Với mục đích tương tự, chúng tôi cũng đặc biệt chú ý đến tính hợp lý của việc đặt tên biến và phương thức. Chúng tôi thích mã có tính biểu cảm/dễ đọc thay vì theo đuổi mã ngắn một cách mù quáng.

3. Học máy đang phát triển với tốc độ đáng kinh ngạc

Nghiên cứu trong lĩnh vực học máy, đặc biệt là lĩnh vực mạng lưới thần kinh, đang phát triển rất nhanh. Một mô hình tiên tiến cách đây một năm có thể đã lỗi thời ở thời điểm hiện tại. Chúng tôi thậm chí còn không biết cơ chế chú ý, nhúng vị trí hoặc kiến ​​trúc nào sẽ phổ biến trong năm tới. Do đó, chúng tôi không thể xác định một mẫu chuẩn áp dụng cho tất cả các mô hình.

Ví dụ, hai năm trước, người ta có thể định nghĩa lớp tự chú ý của BERT là lớp chú ý tiêu chuẩn cho tất cả các mẫu máy biến áp. Về mặt logic, chức năng chú ý "tiêu chuẩn" có thể được chuyển vào tệp chú ý tập trung. Nhưng sau đó xuất hiện các lớp chú ý đã thêm các phần nhúng vị trí tương đối trong mỗi lớp (chẳng hạn như T5), nhiều dạng lớp chú ý được phân đoạn khác nhau (Reformer, Longformer, BigBird) và sự chú ý giúp tách biệt phần nhúng vị trí và Cơ chế nhúng từ (DeBERTa)… Bất cứ khi nào. điều gì đó như thế này xảy ra, chúng tôi phải tự hỏi liệu chúng tôi có nên điều chỉnh chức năng chú ý “tiêu chuẩn” hay tốt hơn là thêm chức năng chú ý mới vào chú ý.py. Nhưng nếu muốn thêm một chức năng chú ý mới thì nên đặt tên như thế nào? chú ý_with_positional_embd, cải cách_ chú ý và deberta_attention ?

Việc đặt tên chung cho các thành phần của mô hình học máy là rất nguy hiểm vì cách giải thích ý nghĩa của tên có thể nhanh chóng thay đổi hoặc trở nên lỗi thời. Ví dụ: sự chú ý được phân đoạn có đề cập đến sự chú ý được phân đoạn của GPTNeo, sự chú ý được phân đoạn của Reformer hay sự chú ý được phân đoạn của BigBird không? Lớp chú ý là lớp tự chú ý, lớp chú ý chéo hay cả hai? Nếu cuối cùng chúng ta quyết định đặt tên lớp chú ý theo tên mô hình, tại sao chúng ta không đặt chức năng chú ý này vào tệp mô hình tương ứng?

4. Mô hình học máy là tĩnh

Thư viện Transformers là tập hợp các mô hình học máy thống nhất và hoàn chỉnh được tạo bởi các nhóm nghiên cứu khác nhau. Mỗi mô hình học máy thường tương ứng với một bài báo và kho lưu trữ GitHub chính thức của nó. Khi một mô hình học máy được phát hành, nó hiếm khi được điều chỉnh hoặc thay đổi sau này.

Thay vào đó, các nhóm nghiên cứu có xu hướng tung ra các mô hình mới được xây dựng trên các mô hình trước đó, hiếm khi thực hiện những thay đổi đáng kể đối với mã đã phát hành. Đây là nhận thức quan trọng khi quyết định nguyên tắc thiết kế cho thư viện máy biến áp. Điều này có nghĩa là khi lược đồ mô hình được thêm vào máy biến áp thì các thành phần cơ bản của mô hình sẽ không thay đổi. Một số lỗi có thể được tìm thấy và sửa chữa, các phương thức hoặc biến có thể được đổi tên và định dạng đầu ra hoặc đầu vào của mô hình có thể được tinh chỉnh, nhưng các thành phần cốt lõi của mô hình nhìn chung sẽ không bị thay đổi. Do đó, nhu cầu thực hiện những thay đổi lớn trên toàn cầu đối với tất cả các mô hình trong máy biến áp đã giảm đi đáng kể, điều này khiến cho việc mỗi mô-đun logic chỉ tồn tại một lần ít quan trọng hơn vì chúng ta hiếm khi thay đổi nó.

Nhận thức thứ hai là không có sự phụ thuộc hai chiều giữa các mô hình. Các mô hình mới được phát hành có thể phụ thuộc vào các mô hình hiện có, nhưng rõ ràng là các mô hình hiện tại không phụ thuộc một cách hợp lý vào các mô hình trước đó. Ví dụ: T5 được xây dựng một phần trên BERT, do đó mã mô hình của T5 có thể phụ thuộc một cách hợp lý vào mã mô hình của BERT, nhưng BERT không bao giờ có thể phụ thuộc một cách hợp lý vào T5. Do đó, việc cấu trúc lại chức năng chú ý của BERT để đáp ứng các yêu cầu của T5 là không hợp lý về mặt logic - người đọc mã của lớp chú ý của BERT không cần phải có bất kỳ kiến ​​thức nào về T5. Tương tự như vậy, điều này thúc đẩy chúng tôi không tập trung các thành phần như lớp chú ý vào một mô-đun chung mà tất cả các mô hình đều có thể truy cập được.

Mặt khác, mã cho một mô hình mới có thể có một số phụ thuộc logic vào mô hình trước đó. Ví dụ: mã của DeBERTa-v2 phụ thuộc vào mã của DeBERTa ở một mức độ nào đó. Khả năng bảo trì có thể được cải thiện đáng kể bằng cách đảm bảo rằng mã mẫu của DeBERTa-v2 vẫn được đồng bộ hóa với mã của DeBERTa. Về mặt lý thuyết, việc sửa lỗi trong DeBERTa cũng sẽ sửa được các lỗi tương tự trong DeBERTa-v2. Làm cách nào để chúng tôi duy trì một chiến lược tệp mô hình duy nhất trong khi vẫn đảm bảo rằng các mô hình mới luôn đồng bộ hóa với các mô hình mà chúng phụ thuộc vào?

Bây giờ, hãy giải thích lý do tại sao chúng tôi thêm dấu hoa thị $ {}^{\textbf{*}} $ sau "lặp lại chính mình". Chúng tôi không vô tình sao chép và dán mã tương ứng từ mô hình hiện có, ngay cả khi có vẻ như đó là điều chúng tôi đang làm. Sylvain Gugger, một trong những người bảo trì cốt lõi của Transformers, đã phát hiện ra một cơ chế tốt tôn trọng chính sách một tệp trong khi vẫn giữ chi phí bảo trì trong một phạm vi nhất định. Cơ chế này, hãy gọi nó là "cơ chế sao chép", cho phép chúng ta sử dụng câu lệnh #Copied from . để đánh dấu các thành phần logic nhất định (chẳng hạn như các chức năng của lớp chú ý), từ đó buộc mã hiện tại được đánh dấu phải nhất quán với Giống như . Ví dụ: dòng mã này trong lớp DeBERTa-v2 buộc toàn bộ lớp DebertaV2Layer phải giống hệt với lớp DebertaLayer ngoại trừ tiền tố tên lớp DeBERTav2. Như bạn có thể thấy, cơ chế sao chép làm cho mã mô hình rất dễ hiểu, đồng thời giảm đáng kể chi phí bảo trì. Nếu ai đó thay đổi chức năng của một mô hình, chúng ta có thể sử dụng công cụ tự động để sửa mã tương ứng cho tất cả các mô hình khác phụ thuộc vào chức năng đó của mô hình đó.

thiếu sót

Rõ ràng, chiến lược một tập tin cũng có những nhược điểm và chúng tôi sẽ đề cập ngắn gọn về hai nhược điểm ở đây.

Mục tiêu chính của Transformers là cung cấp API thống nhất để suy luận và đào tạo tất cả các mô hình để người dùng có thể nhanh chóng chuyển đổi giữa các mô hình khác nhau. Tuy nhiên, việc đảm bảo API nhất quán giữa các mô hình sẽ khó khăn hơn nhiều nếu tệp mô hình không được phép sử dụng mẫu thiết kế trừu tượng. Chúng tôi giải quyết vấn đề này bằng cách chạy một số lượng lớn thử nghiệm (khoảng 20.000 thử nghiệm mỗi ngày tính đến thời điểm viết bài này) để đảm bảo rằng mô hình tuân theo API nhất quán. Trong trường hợp này, chiến lược một tệp yêu cầu chúng tôi phải rất nghiêm ngặt khi xem xét các mô hình mới và trường hợp thử nghiệm mới.

Thứ hai, có nhiều nghiên cứu chỉ tập trung vào các thành phần riêng lẻ của mô hình học máy. Ví dụ: một số nhóm nghiên cứu sẽ nỗ lực phát triển một dạng cơ chế chú ý mới phù hợp với tất cả các mô hình được đào tạo trước hiện có, như đã thực hiện trong bài viết Suy nghĩ lại về sự chú ý với người biểu diễn. Chúng ta nên kết hợp nghiên cứu đó vào thư viện máy biến thế như thế nào? Nó thực sự khó để làm. Chúng ta có nên thay đổi tất cả các mô hình hiện có? Điều này sẽ vi phạm điểm 3 và 4 ở trên. Hay chúng ta nên thêm hơn 100 tệp mô hình mới, mỗi tệp có tiền tố là Trình biểu diễn...? Điều này cũng thật buồn cười. Thật không may, chúng tôi chưa có giải pháp tốt cho tình huống này và chúng tôi phải chọn không tích hợp kết quả của bài báo này vào máy biến áp. Khi bài viết này được chú ý nhiều hơn và có điểm kiểm tra đào tạo trước mạnh mẽ, chúng tôi có thể thêm tệp mô hình mới cho mô hình quan trọng nhất, ví dụ: chúng tôi hiện có modelling_performer_bert.py.

Tóm tắt

Nhìn chung, tại Ôm Mặt, chúng tôi tin chắc rằng chiến lược một tập tin là một khái niệm thiết kế mã phù hợp cho máy biến áp.

Bạn nghĩ gì? Chúng tôi rất muốn nghe ý kiến ​​từ bạn! Nếu có điều gì muốn nói hãy để lại tin nhắn dưới bài viết này.

---

Văn bản gốc tiếng Anh: https://hf.co/blog/transformers-design-philosophy.

Tác giả gốc: Patrick von Platen.

Người phiên dịch: Matrix Yao (Yao Weifeng), Kỹ sư Deep Learning của Intel, đang nghiên cứu ứng dụng các mô hình dòng máy biến áp trên nhiều dữ liệu phương thức khác nhau cũng như đào tạo và suy luận về các mô hình quy mô lớn.

Người phản biện/sắp chữ: zhongdongy (阿东).

Cuối cùng, bài viết này về [Đừng] Lặp lại chính mình* - Cách thiết kế thư viện nguồn mở cho máy học hiện đại kết thúc tại đây. Nếu bạn muốn biết thêm về [Đừng] lặp lại chính mình* - Cách thiết kế nguồn mở. Thư viện dành cho máy học hiện đại Về nội dung của thư viện, vui lòng tìm kiếm các bài viết của CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .