Hai cấu hình, một GPU, một quyết định bạn có thể giải thích.

1. Viết câu hỏi trước khi chuẩn bị các biến thể

Một so sánh hữu ích trả lời một quyết định cụ thể: tăng độ dài tối đa có giúp tránh các câu trả lời bị cắt không? Một mức độ chi tiết có giữ được các đường nét cần thiết không? Một nhóm lớn hơn có chạy xong mà không lỗi không? Hãy chọn một câu hỏi và chỉ một tham số. «Tìm cấu hình tốt nhất» là quá rộng cho một buổi đầu tiên.

Gọi A là mốc tham chiếu và B là biến thể. Ghi lại giá trị chính xác đã thay đổi. Thay đổi đồng thời mô hình, kích thước và số lần chạy có thể tạo ra kết quả khác, mà không cho biết thay đổi nào giải thích điều đó. Hãy để những thử nghiệm này cho các so sánh riêng.

2. Cố định một tập dữ liệu nhỏ và các quy tắc đánh giá

Gom cùng các đầu vào cho A và B. Khoảng một tá trường hợp có thể đủ cho một quyết định ban đầu có giới hạn, nếu bao gồm các khó khăn của dự án: chữ nhỏ trong ảnh, tài liệu dài, dữ liệu thiếu hoặc định dạng lạ. Con số này là một lựa chọn thực tế, không phải một bảo đảm thống kê. Tránh chỉ đưa vào những ví dụ vốn đã thành công.

Với mỗi đầu vào, hãy viết trước khi thử các điều kiện thành công. Phân biệt một sở thích về cách trình bày với một lỗi nghiêm trọng. Trong một trợ lý tài liệu, một câu trả lời dễ chịu hơn vẫn có thể bị từ chối nếu nó bịa ra một quy tắc. Với một hình ảnh sản phẩm, một màu sắc hấp dẫn không bù đắp cho việc mất đi một chi tiết quan trọng.

Cũng hãy đặt số trường hợp tối thiểu được chấp nhận, các lỗi bị cấm và thời gian kiểm tra tối đa. Những ngưỡng riêng của dự án này phải giữ nguyên khi bạn xem xét kết quả.

3. Giữ nguyên cùng một buổi chạy và cùng các phụ thuộc

Hãy giữ nguyên mô hình, phiên bản, tiện ích mở rộng, engine tính toán và các thông số khác. Dùng cùng môi trường và cùng GPU, không chạy một tác vụ xử lý nào khác xen giữa hai biến thể. Ghi chú lại những gì bạn không thể kiểm soát: hoạt động đồng thời có thể thấy được, thay đổi phiên bản bị ép buộc hoặc cách tải khác nhau. Một so sánh bị ảnh hưởng bởi những thay đổi này cần thận trọng hơn.

Nếu công cụ sử dụng hạt ngẫu nhiên và cho phép cố định hạt đó, hãy giữ nguyên giá trị cho mỗi cặp đoạn văn. Điều này giúp việc so sánh dễ dàng hơn, nhưng không đảm bảo kết quả đầu ra giống hệt nhau ở mọi nơi. PyTorch cho biết không thể đảm bảo khả năng tái lập hoàn toàn giữa các phiên bản hoặc nền tảng, ngay cả khi dùng cùng một hạt ngẫu nhiên.

Tạo hai thư mục, A và B, với cùng một danh sách mã định danh. Giữ nguyên các kết quả đầu ra thô trước khi chỉnh sửa thủ công. Một lần chỉnh sửa sau đó phải được ghi nhận như một thao tác bổ sung, kèm theo thời gian làm việc của nó, chứ không được quy cho cài đặt đã tạo ra tệp ban đầu.

4. Chạy kiểm tra, sau đó so sánh các cặp

Trước tiên, hãy kiểm tra xem một mục nhập đơn giản có đi đến được tệp hoặc phản hồi đã truy xuất hay không. Phần này kiểm soát phương thức. Hãy báo cáo riêng một lần tải đầu tiên hoặc một bước chuẩn bị đặc biệt: đừng so sánh toàn bộ quá trình khởi động của A với một phần B mà mọi thành phần đều đã được tải sẵn.

Chạy các trường hợp giống nhau cho A và B. Nếu công cụ cho phép, hãy đảo thứ tự, rồi chạy lại một vài cặp quyết định theo thứ tự ngược lại. Kiểm tra xem liệu một kết quả đơn lẻ hay lợi thế về thứ tự có đang chi phối toàn bộ kết luận hay không.

Hãy ghi lại cả các lỗi và kết quả bị từ chối. Nếu B thất bại với một đầu vào lớn, đừng loại nó khỏi bảng để cải thiện điểm trung bình của B. Có thể khắc phục nguyên nhân trong một lần thử B2 riêng biệt. Như vậy bạn vẫn giữ được một so sánh dễ đọc thay vì một hồ sơ mà biến thể thay đổi theo từng khó khăn.

5. Tách biệt kết quả được chấp nhận và thời gian quan sát được

Trước tiên, hãy xem xét chất lượng ở đúng kích thước hoặc trong công cụ sử dụng. Nếu có thể, hãy tạm thời ẩn tên A và B tại thời điểm đánh giá. Một người có thể chỉ cần xem các kết quả theo thứ tự xáo trộn, rồi khôi phục lại sự tương ứng của chúng. Hãy giữ các tiêu chí đã công bố và một lý do ngắn gọn cho mỗi lần từ chối.

Về thời gian, hãy chọn một định nghĩa duy nhất: ví dụ từ lúc khởi chạy đến khi ghi xong toàn bộ đầu ra. Sau đó tách biệt phần kiểm tra của con người và các chỉnh sửa. Đồng hồ bấm giờ quanh một lệnh gọi GPU không phải lúc nào cũng đo được phép tính đã hoàn tất: với PyTorch/CUDA, các thao tác có thể diễn ra bất đồng bộ. Hãy dùng phương pháp đo mà công cụ ghi trong tài liệu nếu bạn muốn tách riêng phần tính toán.

Nếu các lần lặp lại chồng chéo lên nhau hoặc nếu việc bấm giờ vẫn còn gần đúng, hãy ghi « chênh lệch thời lượng không kết luận được ». Một khác biệt nhỏ trong một lần chạy duy nhất không đủ để biện minh cho một tỷ lệ phần trăm lợi ích được trình bày như chắc chắn.

Ví dụ: 128 hay 256 token mới cho một trợ lý tài liệu

Một nhóm nhỏ muốn có câu trả lời đầy đủ cho mười hai câu hỏi cố định. Họ giữ nguyên mô hình, cùng các tài liệu, cùng chỉ dẫn và cùng GPU. Chỉ giới hạn trả lời thay đổi: A cho phép 128 token mới, B cho phép 256. Trong Transformers, max_new_tokens giới hạn việc sinh văn bản mà không tính các token của văn bản đầu vào. Một token không phải là một từ: giới hạn này không định nghĩa một số câu chính xác.

Trước thử nghiệm, nhóm đặt ra một quy tắc mang tính minh họa: ít nhất mười câu trả lời được chấp nhận trên mười hai và không có quy tắc nào bị bịa ra. Bảng dưới đây là một tình huống giả định để đọc kết quả. Nó không mô tả một trợ lý đã được đo lường và không dự đoán tác động của những giá trị này lên mô hình của bạn.

A đã đạt mức tối thiểu, B nhận được nhiều câu trả lời được chấp nhận hơn nhưng vẫn giữ một lỗi nghiêm trọng. Quyết định là giữ A cho phạm vi này, đồng thời xem xét lại các câu trả lời, và tìm nguyên nhân lỗi của B trước khi so sánh lần khác. Độ dài lớn hơn không phải là bằng chứng về chất lượng cũng không phải là nguyên nhân chắc chắn của việc bịa đặt.

Nhóm sẽ chạy lại các câu hỏi giúp phân biệt A và B cùng hai câu hỏi đã vượt qua trước đó. Nếu lỗi cũng xuất hiện với A, nhóm tạm hoãn kết luận: tập dữ liệu ban đầu chưa đủ để xác lập tính ổn định. Nhóm giữ lại dấu vết của cả hai lần chạy thay vì chỉ giữ lần thuận lợi nhất.

Tránh những kết luận mà bài kiểm tra của bạn không cho phép

Đừng chọn B chỉ vì một trong các kết quả của nó gây ấn tượng trong khi những kết quả khác suy giảm. Đừng thay đổi tập dữ liệu giữa chừng, đừng tính hai lần chạy lại như hai mục khác nhau và đừng xóa một thất bại khỏi mẫu số. Mười hai mục được trình bày vẫn là mười hai trường hợp cần giải thích, kể cả khi một số trường hợp không tạo ra tệp nào.

Cấu hình được chọn chỉ có giá trị với các mục, phiên bản và tiêu chí đã xem xét. Nó có thể không còn phù hợp với một tài liệu dài gấp mười lần hoặc với những hình ảnh khác. Hãy bổ sung dần các trường hợp tiêu biểu. Việc mở rộng này mở rộng phạm vi kiểm soát, chứ không biến một bài kiểm tra nhỏ thành chứng nhận cho toàn hệ thống.

Giữ lại một quyết định ngắn gọn và lần kiểm tra tiếp theo

Hồ sơ cuối cùng của bạn gồm tập dữ liệu, hai cấu hình, các kết quả đầu ra, các phán quyết theo mã định danh và vài dòng kết luận. Hãy nêu rõ cấu hình được chọn, lý do và giới hạn: “A được giữ lại trên mười hai câu hỏi này; hai câu trả lời vẫn cần xem lại; các tài liệu dài bổ sung chưa được bao phủ”. Người khác phải có thể hiểu được lựa chọn này mà không cần tham dự buổi làm việc.

Hãy giữ A làm đối chứng cho lần chẩn đoán tiếp theo. Nếu không biến thể nào đáp ứng tiêu chí, đừng chọn biến thể nào để bàn giao; hãy đặt ra giả thuyết mới. Dành thời gian sao chép và kiểm tra trước khi bắt đầu loạt thử tiếp theo. Một thử nghiệm đã kết thúc với giới hạn rõ ràng đã đủ để đưa ra quyết định; nó không bắt buộc phải tiếp tục cho đến khi tìm được người thắng.