Chỉnh sửa trọng số Qwen: Cách Astra giúp giảm vòng lặp suy luận

Một thử nghiệm gần đây cho thấy việc chỉnh sửa trực tiếp một phần rất nhỏ trong trọng số của Qwen có thể cải thiện đáng kể khả năng hoàn tất bài toán. Trong điều kiện đánh giá được công bố, Qwen3.5-0.8B tăng điểm trên MATH-500 từ 7,9% lên 48,1% sau khi được can thiệp vào trọng số.

Điểm đáng chú ý không nằm ở việc mô hình đột nhiên “học thêm” kiến thức toán học. Vấn đề chính được xử lý là hiện tượng suy luận lặp vô hạn: mô hình liên tục viết lại các bước đã thực hiện, tiêu tốn toàn bộ giới hạn token nhưng không đưa ra đáp án cuối cùng.

Thử nghiệm này mở ra một hướng nghiên cứu đáng quan tâm cho lĩnh vực lập trình trong không gian trọng số và chỉnh sửa trọng số mô hình ngôn ngữ lớn. Tuy nhiên, kết quả cũng cần được đọc trong đúng bối cảnh: Astra được cung cấp công cụ Python, dữ liệu thực hành, phản hồi từ các lần chạy mô hình và một quy trình đánh giá được thiết kế trước.

Tóm tắt kết quả chính

• Qwen3.5-0.8B tăng độ chính xác trên MATH-500 từ 7,9% lên 48,1% trong giao thức được công bố.
• Trước chỉnh sửa, khoảng 93% câu trả lời chạm giới hạn độ dài vì mô hình không hoàn tất quá trình suy luận.
• Sau chỉnh sửa, tỷ lệ câu trả lời chạm giới hạn giảm xuống còn 33,1%.
• Astra không sử dụng huấn luyện gradient, bộ tối ưu hoặc quá trình lan truyền ngược để cập nhật trọng số.
• Phần chỉnh sửa chỉ tác động đến khoảng 0,016% tổng số trọng số của mô hình.
• Các câu hỏi thuộc đánh giá cuối cùng được tuyên bố là không xuất hiện trong dữ liệu lựa chọn chỉnh sửa.
• Thử nghiệm tiếp theo trên một mô hình Gemma nhỏ hơn không chứng minh được mức cải thiện rõ ràng.

Vấn đề mà chỉnh sửa trọng số Qwen giải quyết

Trong chế độ suy luận, Qwen3.5-0.8B có thể tạo ra nhiều bước trung gian hữu ích. Mô hình đôi khi xác định đúng hướng giải, thực hiện được một số phép tính và tiến gần đến đáp án. Tuy nhiên, thay vì kết thúc, nó lại quay lại những bước trước đó, lặp lại phép biến đổi hoặc tự kiểm tra vô hạn.

Hiện tượng này khiến câu trả lời bị cắt khi đạt giới hạn token. Khi đó, dù phần suy luận trước đó có thể chứa nhiều thông tin đúng, hệ thống chấm điểm vẫn xem kết quả là thất bại vì không nhận được đáp án cuối cùng.

Đây là điểm khác biệt quan trọng giữa khả năng giải bài và khả năng hoàn tất câu trả lời. Một mô hình có thể sở hữu năng lực cần thiết để xử lý bài toán nhưng vẫn đạt điểm thấp nếu không biết dừng đúng lúc.

Theo nghiên cứu, các thành phần feed-forward tại lớp 15 và lớp 19 của Qwen có liên quan đến một hướng kích hoạt gắn với hành vi lặp. Astra đã xác định đóng góp này trong quá trình phân tích, sau đó trừ bớt ảnh hưởng của nó khỏi một số cột đầu ra được chọn.

Kết quả là mô hình có xu hướng kết thúc câu trả lời thường xuyên hơn. Nói cách khác, chỉnh sửa không nhất thiết “dạy” Qwen một phương pháp toán mới; nó giúp mô hình sử dụng tốt hơn những năng lực vốn đã tồn tại nhưng thường bị che khuất bởi vòng lặp suy luận.

Thí nghiệm chỉnh sửa Qwen diễn ra như thế nào?

Nghiên cứu do Rikiya Takehi, Jayden Teoh, Alex Zhang và Omar Khattab thực hiện. Nhóm nghiên cứu công bố thông tin về phương pháp, nhật ký thử nghiệm và các tệp giao thức liên quan trên trang nghiên cứu của mình. GPT-6 Astra được sử dụng như tác nhân thực hiện quá trình phân tích và chỉnh sửa.

Mô hình được thử nghiệm là phiên bản Qwen có quy mô khoảng 0,8 tỷ tham số. Trong quá trình làm việc, Astra không chỉ nhận một tệp trọng số thô rồi tự đưa ra phán đoán. Hệ thống được cung cấp một môi trường nghiên cứu tương đối đầy đủ, bao gồm:

• Nhân Python chạy liên tục để phân tích trọng số.
• Các thư viện phục vụ tính toán số và kiểm tra tensor.
• Tokenizer của mô hình.
• Công cụ thực hiện forward pass riêng biệt.
• Dữ liệu bài tập có đáp án tham khảo.
• Phản hồi từ các lần chạy thử trên mô hình gốc và mô hình đã chỉnh sửa.
• Thông tin về số lượng lỗi, điểm số và các mẫu văn bản được sinh ra.
• Khả năng so sánh những phiên bản khác nhau trên cùng một tập bài toán.

Môi trường Python không có quyền truy cập internet hoặc GPU. Việc sinh văn bản được thực hiện thông qua công cụ forward pass, giúp tách quá trình phân tích trọng số khỏi quá trình chạy mô hình.

Vai trò của dữ liệu thực hành và phản hồi mô hình

Dữ liệu thực hành đóng vai trò quan trọng trong việc giúp Astra xác định lỗi. Các tệp thử nghiệm chứa bài toán, đáp án và trong một số tập như GSM8K hoặc MATH có cả lời giải tham khảo.

Astra có thể quan sát nhiều loại tín hiệu khác nhau, chẳng hạn:

• Văn bản suy luận do mô hình tạo ra.
• Đáp án cuối cùng và kết quả chấm điểm.
• Số lần mô hình chạm giới hạn token.
• Hoạt động bên trong của các lớp và thành phần mô hình.
• Sự khác biệt giữa mô hình gốc và mô hình đã chỉnh sửa.
• Tác động của từng mức độ chỉnh sửa.

Nhờ đó, quá trình không chỉ dựa trên phỏng đoán. Astra có thể đề xuất một thay đổi, chạy thử trên nhiều bài toán, quan sát tỷ lệ hoàn tất rồi tiếp tục điều chỉnh hoặc loại bỏ phương án không hiệu quả.

Giao thức ban đầu cũng yêu cầu tác nhân nghiên cứu ưu tiên những lỗi có thể giải thích được, xác định thành phần có quan hệ nhân quả với lỗi, thử nhiều cường độ can thiệp và kiểm tra kết quả trên dữ liệu không được dùng để lựa chọn chỉnh sửa.

Chi tiết này rất quan trọng khi đánh giá năng lực của hệ thống. Kết quả không đến từ một thao tác chỉnh sửa hoàn toàn mù quáng, mà từ sự kết hợp giữa phân tích trọng số, phản hồi thực nghiệm và một kế hoạch kiểm thử cụ thể.

Không sử dụng gradient training có nghĩa là gì?

Thí nghiệm cấm sử dụng lan truyền ngược, bộ tối ưu và quá trình huấn luyện lặp dựa trên hàm mất mát. Vì vậy, Astra không thực hiện quy trình huấn luyện truyền thống như khi fine-tune mô hình bằng gradient.

Thay vào đó, tác nhân có thể:

• Đọc và phân tích các trọng số hiện có.
• Xác định những tensor hoặc cột đầu ra liên quan đến lỗi.
• Tính toán một thay đổi trực tiếp trên không gian trọng số.
• Lưu phiên bản mô hình sau chỉnh sửa.
• Đánh giá mô hình mới bằng các lần chạy forward pass.

Ví dụ khái quát về một phép chỉnh sửa trực tiếp có thể được mô tả như sau:

# Minh họa khái niệm, không phải mã nguồn chính thức
weight_column = model.layer_19.ffn.output[:, selected_index]
weight_column = weight_column - repetition_direction * edit_strength
model.layer_19.ffn.output[:, selected_index] = weight_column

Đoạn mã trên chỉ nhằm minh họa ý tưởng: xác định một hướng liên quan đến hành vi lặp và giảm ảnh hưởng của hướng đó trong một thành phần cụ thể. Trong thực tế, việc chọn tensor, cường độ và phạm vi chỉnh sửa phụ thuộc vào cấu trúc mô hình cũng như giao thức nghiên cứu.

Do đó, cụm từ “không huấn luyện bằng gradient” không đồng nghĩa với việc Astra không nhận bất kỳ phản hồi nào. Hệ thống vẫn sử dụng bài tập, kết quả chấm điểm và đầu ra của mô hình để lựa chọn can thiệp. Điểm khác biệt là trọng số không được tối ưu hóa bằng quy trình gradient tiêu chuẩn.

Chỉ một phần rất nhỏ trọng số đã bị thay đổi

Theo báo cáo, chỉnh sửa cuối cùng tác động đến 131.072 phần tử, tương đương khoảng 0,016% tổng số trọng số của mô hình.

Trong định dạng bfloat16 được sử dụng khi đánh giá, có khoảng 130.188 phần tử thực sự có giá trị khác biệt sau quá trình chuyển đổi. Sự chênh lệch nhỏ giữa hai con số đến từ việc làm tròn khi chuyển sang định dạng số được sử dụng trong mô hình đánh giá.

Điều này cho thấy một thay đổi rất cục bộ vẫn có thể ảnh hưởng đến hành vi quan sát được của mô hình. Tuy nhiên, không nên suy luận rằng mọi lỗi của mô hình ngôn ngữ đều có thể sửa bằng cách thay đổi một vài cột trọng số.

Hiệu quả của phương pháp phụ thuộc vào việc lỗi có mang tính hệ thống hay không. Một hành vi lặp lại thường xuyên và gắn với một nhóm thành phần cụ thể có thể dễ chỉnh sửa hơn lỗi kiến thức phân tán trên toàn bộ mạng.

Kết quả trên MATH-500

Trong giao thức được công bố, mô hình được bật chế độ suy luận, giới hạn đầu ra là 32.768 token mới và mỗi bài toán trong MATH-500 được lấy trung bình từ bốn mẫu sinh.

Mức tăng từ 7,9% lên 48,1% là rất lớn trong điều kiện thử nghiệm cụ thể. Tuy nhiên, con số này cần được hiểu cùng với tỷ lệ câu trả lời vẫn bị cắt. Sau chỉnh sửa, 33,1% bài toán vẫn chạm giới hạn độ dài.

Điều đó có nghĩa là bản sửa chưa loại bỏ hoàn toàn vòng lặp suy luận. Nó làm giảm đáng kể tần suất thất bại và giúp nhiều câu trả lời đi đến phần kết luận, nhưng vẫn còn một nhóm lớn yêu cầu không hoàn tất.

Thử nghiệm cũng ghi nhận sự cải thiện trong bài đánh giá tuân thủ hướng dẫn IFEval. Kết quả này gợi ý rằng khả năng kết thúc đầu ra có thể ảnh hưởng đến nhiều tác vụ khác ngoài giải toán.

So sánh giữa khả năng suy luận và khả năng hoàn tất

Trường hợp Qwen là ví dụ rõ ràng cho một vấn đề thường bị bỏ qua trong đánh giá mô hình ngôn ngữ: điểm số cuối cùng không chỉ phản ánh năng lực lập luận.

Một câu trả lời có thể thất bại vì nhiều nguyên nhân:

1. Mô hình không biết kiến thức cần thiết.
2. Mô hình chọn sai chiến lược giải.
3. Mô hình thực hiện sai phép tính.
4. Mô hình tạo ra suy luận mâu thuẫn.
5. Mô hình bị mắc kẹt trong vòng lặp.
6. Mô hình biết cách giải nhưng không xuất ra đáp án trước khi hết giới hạn token.

Chỉnh sửa trọng số trong nghiên cứu chủ yếu nhắm đến nhóm lỗi thứ năm và thứ sáu. Vì vậy, việc điểm số tăng mạnh không nên được diễn giải đơn giản là mô hình đã trở nên thông minh hơn trên mọi khía cạnh.

Một cách diễn giải thận trọng hơn là: mô hình đã hoàn tất được nhiều câu trả lời mà trước đó thường bị gián đoạn. Đây vẫn là một cải thiện thực tế, đặc biệt trong các hệ thống mà chi phí suy luận và giới hạn token có ảnh hưởng trực tiếp đến trải nghiệm người dùng.

Giới hạn của bản sửa và cảnh báo từ model card Qwen

Bản chỉnh sửa không phải giải pháp duy nhất cho hiện tượng lặp. Model card chính thức của Qwen đã cảnh báo về các vòng lặp suy luận và đề xuất điều chỉnh tham số sampling tùy theo trường hợp sử dụng.

Trong môi trường triển khai, nhà phát triển có thể kết hợp nhiều biện pháp:

• Điều chỉnh temperature, top-p hoặc các tham số lấy mẫu khác.
• Giám sát số token được sinh theo thời gian thực.
• Phát hiện các chuỗi lặp bất thường.
• Dừng hoặc khởi động lại yêu cầu khi mô hình có dấu hiệu mắc kẹt.
• Sử dụng streaming để quan sát đầu ra sớm.
• Đặt giới hạn ngân sách token theo loại tác vụ.
• Lưu lại các yêu cầu thất bại để phân tích sau.

Vì vậy, chỉnh sửa trọng số nên được xem là một lớp can thiệp bổ sung, không phải sự thay thế cho các cơ chế kiểm soát ở tầng ứng dụng.

Vấn đề về ngân sách forward pass

Một chi tiết dễ gây hiểu nhầm là ngân sách chạy mô hình. Mỗi yêu cầu sinh có thể chứa tối đa 512 câu trả lời tổng cộng. Với các phép so sánh theo cặp, mỗi mô hình có thể được chạy tối đa 256 lần. Một yêu cầu teacher-forced có thể kiểm tra tối đa 1.024 văn bản trong giới hạn token cho phép.

Do đó, 50 đơn vị ngân sách không nên được hiểu là 50 lần chạy đơn lẻ. Mỗi đơn vị có thể bao gồm một batch lớn các đầu ra dùng để thu thập phản hồi.

Ngân sách forward pass cũng khác với:

• Số lần chạy Python.
• Số lượt trao đổi hội thoại.
• Số bước huấn luyện.
• Số lượng bài toán trong tập thực hành.

Nhật ký thử nghiệm cho thấy phiên bản Qwen thành công được xây dựng qua nhiều lượt. Astra quan sát lỗi, thử các phương án chỉnh sửa rồi so sánh kết quả trên những lần chạy tiếp theo. Vì vậy, mô tả quá trình này như một thao tác tức thời sẽ không phản ánh đúng lượng công việc thể hiện trong nhật ký.

Dữ liệu đánh giá cuối cùng có bị sử dụng để chỉnh sửa không?

Các tác giả cho biết câu hỏi dùng trong đánh giá cuối cùng được giữ kín đối với quá trình lựa chọn chỉnh sửa. Astra biết tên benchmark và giao thức đánh giá vì những thông tin này xuất hiện trong prompt, nhưng các câu hỏi cuối cùng được tuyên bố là không được dùng để chọn trọng số.

Cần phân biệt ba loại dữ liệu:

• Dữ liệu thực hành: được dùng để phát hiện lỗi và lựa chọn can thiệp.
• Tập xác nhận trong quá trình nghiên cứu: có thể được dùng để kiểm tra nhanh một phương án chỉnh sửa.
• Tập đánh giá cuối cùng: được dùng để đo hiệu năng sau khi quá trình lựa chọn đã kết thúc.

Việc tách các nhóm dữ liệu giúp giảm nguy cơ mô hình bị điều chỉnh quá sát với những câu hỏi cụ thể. Tuy nhiên, để khẳng định chắc chắn khả năng tổng quát hóa, vẫn cần nhiều thí nghiệm độc lập trên các tập dữ liệu và giao thức khác nhau.

Những thử nghiệm game có cùng chứng minh một kỹ thuật không?

Bên cạnh Qwen, nghiên cứu còn trình bày một số minh họa liên quan đến mạng chơi game. Những minh họa này không nên được gộp với thí nghiệm Qwen như thể chúng diễn ra trong cùng điều kiện.

Các thử nghiệm game sử dụng đầu vào khác nhau. Trong một trường hợp, Astra nhận trọng số thô của mạng chơi game và xác định trò chơi mà không dùng công cụ. Trong trường hợp khác, Astra xây dựng trọng số mạng từ đầu dựa trên luật chơi và mã nguồn, không có các lượt chơi thực tế để thực hành.

Ngược lại, thí nghiệm Qwen cho phép sử dụng:

• Python để phân tích.
• Bài tập có đáp án.
• Phản hồi từ nhiều lần chạy mô hình.
• So sánh định lượng giữa mô hình gốc và bản chỉnh sửa.

Mỗi thiết lập đều có giá trị riêng, nhưng ranh giới giữa chúng cần được giữ rõ ràng. Nếu kết hợp tất cả kết quả thành một câu chuyện duy nhất, người đọc có thể đánh giá quá cao mức độ tổng quát của phương pháp.

Baseline ảnh hưởng thế nào đến kết luận?

Trong các thử nghiệm game, mạng được Astra tạo ra vượt qua PPO được huấn luyện 100 triệu bước ở Breakout, Seaquest và Asterix. Tuy nhiên, khi so sánh với PPO được huấn luyện 500 triệu bước, chỉ Breakout vẫn giữ được lợi thế; Seaquest và Asterix trở thành các trường hợp không thắng.

Điều này cho thấy câu nói “mạng được tạo ra đánh bại các mạng đã huấn luyện” chưa đủ chính xác nếu không nêu rõ đối thủ là phiên bản nào.

Khi công bố kết quả benchmark, nên luôn ghi rõ:

• Mô hình hoặc phương pháp baseline.
• Số bước huấn luyện của baseline.
• Tham số sampling.
• Số lần lấy mẫu.
• Giới hạn đầu ra.
• Cách chấm điểm.
• Kích thước tập đánh giá.

Việc thay đổi baseline có thể làm thay đổi hoàn toàn cách diễn giải kết quả. Đây là lý do các bảng số liệu đầy đủ thường đáng tin cậy hơn những tiêu đề rút gọn.

Thử nghiệm Gemma: giới hạn quan trọng của phương pháp

Nhóm nghiên cứu thực hiện một thử nghiệm tiếp theo trên mô hình Gemma nhỏ hơn, vốn hiếm khi gặp vòng lặp suy luận nghiêm trọng. Trong trường hợp này, các lỗi chính bao gồm tính toán sai và thực hiện các bước đại số không hợp lệ.

Khác với Qwen, những lỗi của Gemma không tập trung rõ ràng vào một thành phần có thể loại bỏ. Astra vẫn nhận phản hồi từ dữ liệu thực hành và thực hiện các chỉnh sửa có mục tiêu, nhưng kết quả không cho thấy mức cải thiện thuyết phục.

Kết quả tốt nhất chỉ tăng từ 6,8% lên 7,7%, trong khi phiên bản dùng ngân sách lớn hơn đạt 7,0%. Vì vậy, nghiên cứu không xác lập được một cải thiện rõ ràng trên Gemma.

Thử nghiệm này không chứng minh rằng chỉnh sửa trọng số là vô ích. Nó cho thấy phương pháp có thể đặc biệt hiệu quả khi mô hình mắc một lỗi hành vi tập trung, chẳng hạn vòng lặp lặp lại. Khi lỗi đến từ nhiều phép tính sai hoặc kiến thức không chính xác phân tán trong mạng, việc chỉnh sửa một thành phần nhỏ có thể không đủ.

Thông tin về checkpoint Qwen đã chỉnh sửa

Checkpoint Qwen đã chỉnh sửa được công bố riêng trên Hugging Face. Một lần chạy lại do akhaliq thực hiện đạt 51,0% trên toàn bộ giao thức MATH-500.

Tuy nhiên, phép kiểm tra mô hình gốc trong lần chạy này chỉ sử dụng 25 bài toán. Vì kích thước mẫu giữa mô hình gốc và mô hình đã chỉnh sửa không cân bằng, kết quả đó không nên được xem là một bản sao hoàn toàn tương đương với phép so sánh đầy đủ.

Checkpoint công khai vẫn là tài nguyên hữu ích để cộng đồng kiểm tra độc lập. Các nhà nghiên cứu và nhà phát triển có thể tải mô hình, chạy lại trên cùng giao thức và đánh giá thêm những tác vụ ngoài MATH-500.

Ý nghĩa đối với nhà phát triển mô hình AI

Thử nghiệm Qwen đưa ra một số bài học thực tế cho quá trình đánh giá và triển khai mô hình ngôn ngữ.

1. Xác định đúng loại lỗi trước khi chỉnh sửa

Không nên bắt đầu bằng câu hỏi “làm thế nào để tăng điểm?”. Câu hỏi hữu ích hơn là: mô hình đang thất bại vì thiếu kiến thức, suy luận sai hay không thể hoàn tất câu trả lời?

Mỗi nguyên nhân đòi hỏi một chiến lược khác nhau. Fine-tuning, RAG, thay đổi prompt, điều chỉnh sampling và chỉnh sửa trọng số không thể thay thế lẫn nhau trong mọi trường hợp.

2. Đo lường khả năng hoàn tất bên cạnh độ chính xác

Nếu chỉ theo dõi accuracy, nhà phát triển có thể bỏ qua việc mô hình tiêu tốn quá nhiều token hoặc thường xuyên bị cắt giữa chừng.

Nên theo dõi thêm:

• Tỷ lệ câu trả lời chạm giới hạn token.
• Độ dài trung bình của phần suy luận.
• Tỷ lệ xuất hiện chuỗi lặp.
• Thời gian phản hồi.
• Chi phí trên mỗi yêu cầu.
• Tỷ lệ cần thử lại.
• Tỷ lệ có đáp án cuối cùng hợp lệ.

3. Giữ nguyên bản gốc để so sánh

Một quy trình đánh giá an toàn nên lưu giữ ít nhất ba phiên bản:

• Mô hình gốc.
• Mô hình sau chỉnh sửa.
• Các phiên bản trung gian nếu có.

Việc này giúp xác định chỉnh sửa đã cải thiện lỗi mục tiêu hay vô tình gây suy giảm ở các năng lực khác.

4. Kiểm tra các trường hợp hồi quy

Một chỉnh sửa thành công trên MATH-500 vẫn có thể làm thay đổi hành vi trên tóm tắt, lập trình, hội thoại hoặc tuân thủ chỉ dẫn. Vì vậy, cần lưu lại những ví dụ mô hình tệ hơn sau chỉnh sửa thay vì chỉ báo cáo các trường hợp được cải thiện.

Đánh giá cuối cùng: tiến bộ đáng chú ý nhưng cần thận trọng

Chỉnh sửa trọng số Qwen là một kết quả đáng quan tâm vì nó nhắm trúng một lỗi cụ thể và tạo ra cải thiện lớn trong một giao thức định lượng. Việc thay đổi khoảng 0,016% trọng số nhưng giảm mạnh tỷ lệ câu trả lời bị cắt cho thấy hành vi của mô hình đôi khi có thể được điều chỉnh thông qua các can thiệp rất cục bộ.

Tuy nhiên, kết quả không chứng minh rằng Astra có thể tự động sửa mọi lỗi của mô hình ngôn ngữ. Thành công của Qwen gắn với một điều kiện đặc biệt: lỗi lặp có tính hệ thống, có thể quan sát và có mối liên hệ với một số thành phần trong mạng.

Thử nghiệm Gemma cung cấp một giới hạn quan trọng. Khi mô hình gặp các lỗi toán học thông thường như tính sai hoặc biến đổi đại số không hợp lệ, chỉnh sửa có mục tiêu không tạo ra mức tăng rõ ràng.

Với nhà phát triển, câu hỏi cần đặt ra không phải là “chỉnh sửa trọng số có thay thế được huấn luyện không?”, mà là:

1. Lỗi nào đang gây thiệt hại lớn nhất trong hệ thống?
2. Lỗi đó có xuất hiện lặp lại và có thể định vị trong mô hình không?
3. Chỉnh sửa có cải thiện khả năng hoàn tất mà không làm giảm chất lượng khác không?
4. Kết quả có giữ nguyên trên dữ liệu chưa được sử dụng để lựa chọn can thiệp không?
5. Hiệu quả của chỉnh sửa có vượt qua các giải pháp đơn giản hơn ở tầng ứng dụng không?

Trong bối cảnh phù hợp, chỉnh sửa trực tiếp trọng số có thể trở thành một công cụ hữu ích để sửa các hành vi thất bại cụ thể. Nhưng trước khi đưa vào sản xuất, mọi kết luận vẫn cần được kiểm chứng trên workload thực tế, với giao thức sampling, giới hạn token và tiêu chí chấm điểm tương ứng.

Câu hỏi thường gặp

Astra có chỉ nhận trọng số thô của Qwen không?

Không. Trong thí nghiệm Qwen, Astra được cung cấp môi trường Python, dữ liệu thực hành, đáp án tham khảo và phản hồi từ các lần chạy mô hình. Đây là điều kiện khác với những minh họa chỉ sử dụng trọng số thô trong các thử nghiệm game.

Chỉnh sửa có loại bỏ hoàn toàn vòng lặp suy luận không?

Không. Tỷ lệ câu trả lời chạm giới hạn giảm từ 93,0% xuống 33,1%, nhưng khoảng một phần ba câu trả lời trong giao thức chính vẫn chưa hoàn tất đúng thời hạn.

Điểm MATH-500 tăng có nghĩa là Qwen đã học thêm kiến thức toán?

Chưa chắc. Kết quả phù hợp hơn với cách diễn giải rằng mô hình đã hoàn tất được nhiều câu trả lời hơn. Bản chỉnh sửa chủ yếu xử lý hành vi lặp, không nhất thiết bổ sung kiến thức toán học mới.

Thử nghiệm Gemma có phủ nhận phương pháp chỉnh sửa trọng số không?

Không. Thử nghiệm Gemma cho thấy phương pháp chưa tạo ra cải thiện rõ ràng trong một thiết lập khác, nơi lỗi không tập trung vào vòng lặp suy luận. Đây là giới hạn của kết quả, không phải bằng chứng phủ nhận toàn bộ kỹ thuật.

Có nên dùng chỉnh sửa trọng số thay cho thay đổi sampling không?

Không nên mặc định như vậy. Model card Qwen đã đề xuất điều chỉnh sampling và dùng streaming để phát hiện đầu ra bất thường. Trong triển khai thực tế, các biện pháp ở tầng ứng dụng nên được đánh giá song song với chỉnh sửa trọng số.

Những con số 7,9% và 48,1% có áp dụng cho mọi trường hợp sử dụng không?

Không. Đây là kết quả trong một giao thức cụ thể với chế độ suy luận, giới hạn 32.768 token mới và trung bình bốn mẫu trên mỗi bài toán MATH-500. Thay đổi sampling, ngân sách token hoặc cách chấm điểm có thể làm kết quả khác đi.

Nguồn tham khảo

• Nghiên cứu về lập trình trong không gian trọng số của Takehi và cộng sự
• Phân tích phản biện của Matthew Honnibal
• Giao thức và nhật ký thí nghiệm Qwen
• Prompt ban đầu của thử nghiệm
• Thử nghiệm tiếp theo trên Gemma
• Model card chính thức của Qwen
• Checkpoint Qwen đã chỉnh sửa
• Thảo luận chính trên Hacker News
• Thảo luận về bài phản biện