Nếu muốn cải tiến một cánh máy bay, "tốt hơn" rốt cuộc nghĩa là gì?
Hiệu quả hành trình đáng được nâng cao, các ràng buộc thiết kế cũng phải được thoả mãn, mà mỗi lần đánh giá có độ chính xác cao đều tiêu tốn ngân sách tính toán. Một phương án ứng viên nổi bật hơn ở một chỉ số, phương án khác lại có thể giữ được dư địa lớn hơn. Xếp chúng thành một hàng và chọn ra quán quân không hề trực tiếp như ta tưởng.
AI có thể tham gia đề xuất phương án mới và viết mã thực nghiệm. Sau đó, điều phải đối mặt là đánh giá, so sánh và tiếp tục khám phá như thế nào.
Khóa AI999 của EvoClass, "Hệ thống tiến hoá thông minh EvoX và thực hành nghiên cứu AI Native", triển khai theo mạch này: từ tính toán tiến hoá bước vào bài toán đa mục tiêu, rồi bàn về nền tảng tính toán hiện đại, sự tiến hoá của phương pháp, và thực hành nghiên cứu trong môi trường AI Native. Khóa học quan tâm đến việc một đề xuất đi vào thực nghiệm ra sao, và phản hồi thay đổi đề xuất tiếp theo như thế nào.
Trước hết hãy nói rõ: cải tiến kiểu nào đáng được giữ lại
Buổi 3 "Tính phức tạp của thế giới thực và đánh đổi đa mục tiêu" lấy các tình huống như thiết kế cánh máy bay để thảo luận mối quan hệ giữa mục tiêu, ràng buộc và chi phí đánh giá.
Có những chỉ số mong nâng cao càng nhiều càng tốt, có những điều kiện thì buộc phải đạt ngưỡng. Phân biệt rõ hai loại yêu cầu này trước, so sánh mới có cơ sở.
Với một nhóm ứng viên, nếu một phương án kém hơn toàn diện ở các chỉ số đang quan tâm, ta có lý do loại nó; nếu vài phương án mỗi bên có lợi ích và cái giá riêng, giữ lại những khác biệt ấy lại giúp việc cân nhắc về sau rõ ràng hơn. Chuyên gia lĩnh vực có thể kết hợp điều kiện vận hành cụ thể và sở thích để quyết định hướng nào đáng tiếp tục.
Điều này cũng nhắc nhà nghiên cứu kiểm tra cách đánh giá của chính mình. Một điểm tổng được tính ra thế nào? Vì sao trọng số lại đặt như vậy? Những ràng buộc trước đây không được viết vào, liệu có khiến phương án điểm cao mất giá trị sử dụng?
Những câu hỏi này cần được trả lời trong thiết kế thực nghiệm. Nếu không, quá trình tìm kiếm có thể tiến mãi theo điểm số, mà dần rời xa nhiệm vụ thực sự cần quan tâm.
Ứng viên ngày càng nhiều, ngân sách đánh giá nên dùng vào đâu?
Giữ lại nhiều khả năng sẽ kéo theo chi phí mới.
Buổi 3 còn thảo luận về mô hình thay thế (surrogate model): học mối quan hệ giữa tham số ứng viên và hiệu năng từ các mẫu đã có, dùng dự đoán chi phí thấp để hỗ trợ sàng lọc, rồi đưa những ứng viên đáng kiểm tra sâu hơn sang đánh giá có độ chính xác cao, và dùng kết quả để cập nhật tiếp.
Ở đây cần nhận diện trọng lượng của các loại bằng chứng khác nhau. Dự đoán của mô hình thay thế có sai số, đặc biệt cần kiểm chứng khi tìm kiếm bước vào vùng chưa quen. Một điểm dự đoán trông có vẻ rất cao vẫn cần được kiểm tra thêm.
Một phần chi phí khác đến từ cách tổ chức tính toán. Buổi 4 "Nền tảng tính toán hiện đại và tiến hoá song song dạng tensor" thảo luận cách tổ chức quần thể, kết quả đánh giá và trạng thái thành tensor, đẩy tính toán theo lô.
Có thể hiểu như sau: xếp tham số của nhiều ứng viên theo một cấu trúc nhất quán, để các thao tác có thể thực thi theo lô cùng xử lý chúng. Tài liệu phát triển bài toán tuỳ chỉnh của EvoX cũng dùng một giao diện đánh giá nhận một lô ứng viên và trả về giá trị mục tiêu tương ứng để minh hoạ cách tổ chức này.
Lợi ích thực tế vẫn phải đo: thời gian dành cho tạo ứng viên, cho hàm mục tiêu, hay cho việc di chuyển dữ liệu? Lô lớn hơn có chiếm quá nhiều bộ nhớ GPU không? Ghi nhận riêng các chi phí này mới biết bước tiếp theo nên sửa ở đâu.
Đánh giá có mô hình thay thế hỗ trợ và song song theo lô lần lượt xử lý vấn đề chi phí đánh giá và tổ chức tính toán. Hiểu sự phân công của chúng hữu ích hơn là chung chung kỳ vọng "chạy nhiều hơn sẽ tốt hơn".
Khi tìm kiếm trì trệ, cũng có thể xem lại phương pháp sinh ra ứng viên
Chạy thêm nhiều vòng mà kết quả không cải thiện rõ rệt, lúc này thứ đáng kiểm tra không chỉ là bản thân các ứng viên.
Đột biến diễn ra thế nào? Tham số được đặt ra sao? Cách tìm kiếm hiện tại có phù hợp với bài toán này không?
Buổi 5 "Sự tiến hoá của phương pháp: từ tối ưu lời giải đến tối ưu chính thuật toán" thông qua các tài liệu như MetaDE, AutoPSO, đưa cả phương pháp sinh ra ứng viên vào bàn luận.
Lấy MetaDE làm ví dụ, lớp trong dùng tiến hoá vi phân để giải bài toán mục tiêu, lớp ngoài tìm kiếm chiến lược và cấu hình tham số dựa trên hiệu năng giải. Nhờ vậy, ngoài so sánh "thu được lời giải nào", còn có thể so sánh "tìm lời giải bằng cách nào".
Tầng thay đổi này cũng cần trả giá. Khi so sánh phương pháp, số lần đánh giá mà lớp trong và lớp ngoài đã dùng, thời gian chạy chiếm bao nhiêu, đều phải tính vào ngân sách; kết luận cũng cần được hiểu trong bối cảnh bài toán và điều kiện đã kiểm thử.
Với người học, một bài tập có thể thử là trước tiên lập một đường cơ sở rõ ràng, rồi thay đổi một chiến lược, giữ lại cấu hình và kết quả đầy đủ, và chạy lặp lại. Như vậy, thay đổi về hiệu năng mới có cơ hội được giải thích, và cũng dễ phát hiện thay đổi nào chỉ đẹp trong một lần chạy.
Sau khi mã đã viết ra, nghiên cứu còn phải để lại gì?
Khi AI có thể tham gia hiện thực nhiều thực nghiệm hơn, những phán đoán mà nhà nghiên cứu phải đưa ra không vì thế mà giảm đi.
Thảo luận ở Buổi 6 về Genesis và sự tiến hoá liên tục của phần mềm đẩy trọng tâm lên mức dự án: nhiệm vụ được chia nhỏ thế nào, thay đổi mã được kiểm chứng ra sao, kết quả hiệu quả đi vào nền tảng của công việc tiếp theo như thế nào. Mô tả chính thức dự án của Genesis cũng tổ chức xây dựng, kiểm chứng và tiếp tục phát triển trên cùng một con đường công việc.
Tuy nhiên, kết luận mà việc biên dịch và kiểm thử đạt được hỗ trợ cần được phân biệt với kết luận nghiên cứu. Chúng có thể cho thấy chương trình đã đáp ứng những yêu cầu đã được kiểm tra; còn một phương pháp có hiệu quả hơn hay không, còn phải xem thiết lập bài toán, thực nghiệm đối chứng, chỉ số đánh giá và phân tích kết quả.
Buổi 7 "Mô thức nghiên cứu AI Native và điểm vào thực chiến với EvoX" đặt trách nhiệm này trở lại nơi nhà nghiên cứu: đặt câu hỏi, định nghĩa đánh giá, phán đoán hướng đi và phê phán các kết quả đã có.
"Gu nghiên cứu" cũng từ đó trở nên cụ thể. Chọn bài toán nào, vì nó quan trọng, hay vì nó dễ cho ra kết quả đẹp? Cách đánh giá có thể kiểm nghiệm được luận điểm của mình không? Nhà nghiên cứu tiếp theo nhận được mã, mô tả môi trường, tham số và nhật ký chạy, liệu có thể kiểm tra lại thực nghiệm này không?
Nếu bạn đã bắt đầu dùng AI viết mã thực nghiệm, có thể bắt đầu từ một bài toán nhỏ mà mình tự kiểm tra được: trước tiên viết mục tiêu và ràng buộc, xác định ngân sách và đường cơ sở, rồi chạy, so sánh, ghi chép, và quyết định vòng sau giữ lại điều gì. Tổng quan khóa AI999 của EvoClass cung cấp điểm vào để tiếp tục học theo con đường này.
Quay lại nhóm ứng viên cánh máy bay ban đầu, thu hoạch của nghiên cứu có thể tạm thời là một tập đánh đổi có căn cứ: phương án nào đáng giữ, phương án nào cần bổ sung đánh giá, hướng nào đã không còn đáng tiếp tục.
Khi những phán đoán và bằng chứng này có thể được thực nghiệm lần sau kế thừa, một phương án còn chưa đủ tốt đã có điểm khởi đầu để tiếp tục cải tiến.
Giới thiệu khóa học dựa trên tài liệu hiện có của EvoClass AI999; bối cảnh kỹ thuật có tham khảo thêm các tư liệu dự án chính thức được liên kết trong bài. Phần thảo luận về cánh máy bay dùng để minh hoạ mối quan hệ giữa mục tiêu và ràng buộc; cách sắp xếp thực nghiệm trong bài là gợi ý học tập, không phải đánh giá hiệu năng do bài viết này thực hiện. Các liên kết bài học trỏ đến tài liệu học tập bằng tiếng Trung giản thể.