Học tăng cường khiến LLM mạnh càng thêm mạnh: Phương pháp 'Never Give Up' giải mã các bài toán khó

Học cách giải quyết các bài toán khó trong RL cho LLM bằng cách "Không bao giờ bỏ cuộc" (Never Give Up)

15 tháng 9, 2026

Đây là bài blog về bài báo gần đây của tôi về RL post-training cho LLM: giới thiệu về Hiệu ứng Matthew (Matthew Effect) và đề xuất giải quyết nó bằng phương pháp Never Give Up. Bài viết được trình bày theo phong cách tương tác và ít trang trọng hơn, giống như cách tôi thuyết trình. Để tìm hiểu sâu hơn về mặt kỹ thuật, hãy xem bài báo trên arxiv và mã nguồn trên github.

Đánh giá (eval) của bạn thực sự đang đo lường điều gì? #

Bất kỳ người làm RL giỏi nào chắc chắn cũng từng thấy đường cong đánh giá đi lên. Đây là kết quả đánh giá AIME 2025 trong quá trình huấn luyện RL cho mô hình Olmo 3.1 RL-Zero Math(1) (1)xem bài blog và arxiv của Olmo 3.1.

Đường cong này thực sự có ý nghĩa gì?

Kết quả đánh giá của chúng tôi là trung bình cộng của 30 câu hỏi AIME. Hãy chia 30 câu hỏi đó thành 3 cấp độ khó. Mọi câu hỏi mà mô hình ban đầu (trước khi RL) đạt 0 điểm ở chỉ số pass@32 sẽ được gắn nhãn là "khó". Các câu hỏi còn lại được chia đều thành "trung bình" và "dễ" dựa trên tỷ lệ vượt qua (pass-rate). Như vậy, tỷ lệ pass@1 ban đầu của chúng tôi lần lượt là 0%, 3,8% và 22,7% cho các tập con này. Bạn nghĩ hiệu suất trên mỗi tập con sẽ tiến triển như thế nào?

Việc lấy trung bình kết quả đánh giá AIME đã che giấu một điều quan trọng: phần lớn sự cải thiện đến từ các bài toán dễ nhất, chuyển từ trạng thái "được giải quyết một phần" sang "được giải quyết phần lớn". Các bài toán khó nhất hầu như không cải thiện. Điều này hiển thị rõ ràng nếu bạn quan sát cách tỷ lệ giải thành công của từng ví dụ thay đổi theo thời gian (xem biểu đồ ở lề). ⊕ Độ chính xác của từng ví dụ đánh giá AIME trong quá trình huấn luyện. Chúng tôi sắp xếp các ví dụ theo độ khó từ trên (mô hình ban đầu pass@32=0) xuống dưới (mô hình ban đầu pass@1 > 30%). Các ví dụ khó nhất (các hàng trên cùng) hầu như không cải thiện trong quá trình huấn luyện. Mô hình chủ yếu học cách giải tốt hơn các ví dụ dễ và trung bình vốn đã được giải khá tốt. Chúng tôi gọi sự chênh lệch này là Hiệu ứng Matthew. Nhưng đây là đối với RL toán học trên LLM. Còn các lĩnh vực khác thì sao?

Chúng tôi đánh giá RL cho mã nguồn (code RL) và RL cho tác nhân (agentic RL) bằng cách sử dụng Deepcoder và DeepSWE, hai dự án mã nguồn mở rất tốt đã công bố mô hình và nhật ký huấn luyện. Chúng tôi có thể sử dụng mô hình ban đầu để chia mỗi benchmark thành các nhóm độ khó (Deepseek-R1-Distilled-Qwen-14B trên LCBv6) hoặc sử dụng các nhãn độ dài/độ khó tác vụ có sẵn (SWEBench).

Những lợi ích từ RL tỷ lệ thuận với độ dễ của bài toán. Chúng tôi liên kết thiên kiến này với một hiện tượng tương tự trong khoa học mạng và kinh tế học, Hiệu ứng Matthew(2) (2)Merton (1968), xem thêm Wikipedia, thường được tóm tắt là "người giàu càng giàu thêm".

Do đó, chúng tôi đề xuất Hiệu ứng Matthew trong RL cho LLM.

RL cải thiện hiệu suất trên một tác vụ tỷ lệ thuận với năng lực ban đầu của mô hình—làm cho các tác vụ dễ trở nên dễ hơn trong khi các tác vụ khó thường vẫn giữ nguyên độ khó.

Điều gì gây ra Hiệu ứng Matthew? #

Bạn có thể cho rằng vấn đề nằm ở GRPO. Nếu chúng ta không nhận được câu trả lời đúng cho bài toán trong $k$ lần lấy mẫu hoàn thiện, thì chúng ta không nhận được bất kỳ gradient nào và không thể cải thiện bài toán đó.(3) (3)Xiong và cộng sự (2025) gọi đây là sự mất tín hiệu (signal loss). Một câu trả lời khả thi là lấy mẫu nhiều lần hoàn thiện hơn, tức là $k$ lớn hơn.(4) (4)Các phương pháp khác bao gồm sử dụng thông tin đặc quyền và học theo chương trình (curriculum learning). Những phương pháp này thường bổ trợ cho cách tiếp cận của chúng tôi.

Để kiểm chứng, chúng tôi huấn luyện Qwen 2.5 0.5B Instruct với GRPO trên tập GSM8k platinum và kiểm tra trên cùng tập đó. Chúng tôi chia tập dữ liệu thành các cấp độ khó sử dụng pass@1 ban đầu: dễ (25%), trung bình (10%), khó (5%) và siêu khó (0%). Chúng tôi thay đổi $k \in \{4, 8, 16, 32\}$ nhưng giữ nguyên kích thước batch.

Hóa ra $k=4$ nhỏ hơn lại thực sự tốt nhất! Tại sao lại như vậy?

Hãy nhìn vào thành phần thực tế của batch huấn luyện. Vì chúng tôi lọc bất kỳ prompt nào mà tất cả các câu trả lời hoàn thiện đều đúng hoặc đều sai, nên batch huấn luyện luôn phải bao gồm các bài toán có một số câu trả lời đúng và một số câu trả lời sai. Chúng tôi vẽ biểu đồ tỷ lệ phần trăm của tập con dễ và tập con siêu khó trong batch và cách nó thay đổi theo thời gian.

$k$ lớn hơn làm tăng cơ hội tìm thấy một lời giải đúng hiếm hoi cho một bài toán rất khó. Vì vậy, theo suy nghĩ thông thường, chúng ta mong đợi nó sẽ có nhiều bài toán khó hơn trong batch. Vấn đề là $k$ lớn hơn cũng làm tăng cơ hội tìm thấy một lời giải sai hiếm hoi cho một bài toán dễ.

Đầu quá trình huấn luyện, $k=32$ tìm thấy các lời giải hiếm cho các bài toán khó. Nhưng sau điểm uốn khoảng bước 200, $k=4$ lại làm tốt hơn. $k=4$ lọc bỏ bất kỳ bài toán nào được giải đúng trong 4/4 lần hoàn thiện. Ngược lại, để $k=32$ lọc bỏ cùng bài toán đó, nó phải được giải đúng nhiều hơn: 32/32. $k=4$ cuối cùng tốn ít tài nguyên tính toán hơn cho các bài toán dễ, đặc biệt là khi chúng nhận được một lời giải sai hiếm hoi. Điểm uốn xảy ra khi lợi ích của việc tìm thấy các câu trả lời đúng hiếm hoi cho các câu hỏi khó bị lu mờ bởi việc lãng phí tài nguyên tính toán để huấn luyện trên các câu trả lời sai hiếm hoi cho các câu hỏi dễ.

Do thiết lập RL không đồng bộ (asynchronous RL) cho LLM của chúng tôi(5) (5)Async RLHF (Noukhovitch và cộng sự, 2025) là một sự tự trích dẫn rõ ràng nhưng cũng là bài báo đầu tiên về async RL cho LLM. Xem thêm PipelineRL (Piche và cộng sự, 2025), tất cả tài nguyên tính toán chúng tôi tiết kiệm được từ việc lọc các bài toán dễ đều được dùng để huấn luyện trên các bài toán khó hơn. Chúng tôi lập luận rằng vấn đề đằng sau Hiệu ứng Matthew không chỉ là lấy mẫu thiếu cho các bài toán khó, mà là dành quá nhiều tài nguyên tính toán cho các bài toán dễ.(6) (6)Trái ngược với mất tín hiệu, chúng tôi gọi đây là hiệu suất tín hiệu (signal efficiency).

Không bao giờ bỏ cuộc (Never Give Up) với các bài toán khó #

Do đó, mục tiêu của chúng tôi là chỉ sử dụng $k$ nhỏ cho các bài toán dễ nhưng có $k$ lớn cho các bài toán khó. Chúng tôi đề xuất một phương pháp đơn giản nhưng hiệu quả để thích ứng việc lấy mẫu RL không đồng bộ: Never Give Up. Chúng tôi bắt đầu lấy mẫu với một lượng nhỏ $k$. Nếu một prompt được giải trong $k$ lần hoàn thiện đầu tiên, hãy huấn luyện trên đó! Nếu một prompt được giải hoàn toàn trong $k/k$ lần hoàn thiện, thì chúng ta có thể lọc nó một cách dễ dàng và nhanh chóng.

Phần khó là nếu tất cả các lần hoàn thiện đều sai. Với xác suất $p$, chúng tôi không bao giờ bỏ cuộc và thêm prompt đó trở lại bộ tạo (generator) để lấy mẫu thêm $k$ lần nữa. Chúng tôi theo dõi các lần hoàn thiện cũ và khi giải được bài toán, chúng tôi huấn luyện trên toàn bộ $k * \text{số vòng NGU}$ lần hoàn thiện. Điều này tạo ra một phân phối hình học cho số lượng mẫu chúng tôi lấy: nếu chúng tôi không bao giờ giải được prompt, theo kỳ vọng, chúng tôi sẽ lấy $\frac{k}{1-p}$ mẫu.

Phương pháp này mang tính thích ứng ngầm định. Trong khi học theo chương trình (curriculum learning) thiết lập sẵn độ khó của bài toán, chúng tôi nhận thấy rằng các phương pháp thích ứng trực tuyến (online, adaptive) hoạt động tốt hơn vì các bài toán dễ có thể trở nên khó hơn trong quá trình huấn luyện và ngược lại. Trên GSM8k, $k=4$ với NGU $p=0,9$ vượt trội hơn tất cả các giá trị của GRPO tiêu chuẩn với $k$ khác nhau. Điều này đặc biệt rõ ràng trên tập con khó nhất.

Nó đạt được điều này bằng cách tận dụng ưu điểm của $k$ lớn ở giai đoạn đầu huấn luyện và $k$ nhỏ ở giai đoạn sau.

Sự cũ kỹ (staleness) trong Async RL và các thủ thuật cho NGU #

Những độc giả tinh ý có thể đã thấy một nhược điểm của phương pháp này: các lần hoàn thiện cũ (stale completions). Phần này giới thiệu hai thủ thuật để xử lý sự cũ kỹ, nhưng nó không cần thiết cho thông điệp chính nên bạn có thể bỏ qua.

Nếu chúng ta thực hiện nhiều vòng NGU để có được một lần hoàn thiện đúng, thì $k$ lần hoàn thiện ban đầu của chúng ta sẽ khá cũ vào thời điểm chúng ta huấn luyện trên chúng. Các mẫu âm cũ (stale negatives) được biết là có hại cho LLM và RL(7) (7)Async RLHF lập luận rằng dữ liệu cũ làm chậm quá trình huấn luyện, điều này cũng đúng với deep RL. Le Roux và cộng sự (2025) cho thấy các mẫu âm cũ đặc biệt có hại. Vì vậy, việc lọc các lần hoàn thiện dưới một ngưỡng tuổi nhất định là rất quan trọng.

$T=4$ giành chiến thắng nhưng điều này để lại một vấn đề khác: baseline GRPO của chúng ta. Chỉ vì chúng ta không huấn luyện trên một lần hoàn thiện cũ không có nghĩa là chúng ta không nên sử dụng nó trong baseline GRPO. Giả sử chúng ta có 4 lần hoàn thiện âm cũ, 3 lần hoàn thiện âm mới và chỉ 1 lần hoàn thiện dương mới. Chúng ta nên coi lần hoàn thiện dương là một hiện tượng hiếm và đặt baseline GRPO là $\frac{1}{8}$. Nhưng nếu chúng ta chỉ huấn luyện trên 4 lần hoàn thiện mới nhất, phần thưởng của nhóm chúng ta trở thành khác không: $\frac{7}{8} - \frac{1}{8} - \frac{1}{8} - \frac{1}{8} = \frac{3}{8}$. Các lựa chọn của chúng ta là bỏ qua các lần hoàn thiện đã lọc khỏi baseline (ignore), để baseline khác không (no rescale), hoặc neo lần hoàn thiện dương và điều chỉnh lại các lợi thế âm theo tỷ lệ $\frac{7}{3}$ để duy trì tổng phần thưởng bằng 0 (anchor pos).

Nhìn chung, việc sử dụng tất cả các mẫu bạn có cho baseline GRPO là hợp lý, ngay cả khi bạn không huấn luyện trên chúng.(8) (8)Baseline này + việc điều chỉnh lại có thể hữu ích chung cho async RL nếu có việc lọc các mẫu vì quá xa chính sách (off-policy).

NGU ở quy mô lớn hơn: Toán học #

Chúng tôi mở rộng quy mô lên một thiết lập RL toán học lớn hơn: DeepScaler với nền tảng Qwen 3 4B.(9) (9)thường tuân theo thiết lập của Li và cộng sự (2025). Trên nền tảng baseline GRPO $k=16$ mạnh mẽ, NGU cải thiện hiệu suất hơn nữa, đặc biệt là trên các tập con khó nhất của đánh giá AIME + BRUMO 2025.

Hiệu ứng Matthew vẫn tồn tại, nhưng chúng ta có thể giảm thiểu nó; NGU giúp giải các câu hỏi khó hơn mà không làm giảm hiệu suất trên các câu hỏi dễ hơn.

NGU ở quy mô khác: Mã nguồn (Code) #

Code RL về cơ bản khác với toán học vì toán học thường có bộ kiểm chứng nhị phân: đúng hoặc sai. Một bài toán lập trình có nhiều bài kiểm tra (tests) và các bài kiểm tra này có thể thay đổi từ dễ đến khó trong cùng một bài toán. Các bài toán toán học chỉ đơn giản là dễ hoặc khó. Giải một bài toán lập trình nghĩa là giải được cả các bài kiểm tra dễ và khó.

Chúng tôi xem xét một thiết lập đặc biệt khó: Manufactoria.(10) (10)tuân theo thiết lập benchmark của Sun và cộng sự (2025). GRPO tiêu chuẩn cải thiện hiệu suất nhưng cuối cùng bị đình trệ: cải thiện trên một số bài kiểm tra nhưng không vượt qua được tất cả. Chia các bài kiểm tra theo độ khó, chúng ta thấy rõ Hiệu ứng Matthew.

Các bài kiểm tra dễ gần như được giải hoàn toàn và sự cải thiện trên các bài kiểm tra khó bị đình trệ. GRPO dành phần lớn tín hiệu huấn luyện để liên tục xem xét lại các bài kiểm tra trung bình đã được giải một phần và dao động giữa việc giải chúng tốt hơn một chút hoặc kém hơn một chút.(11) (11)Chúng ta có thể coi đây chỉ là một vấn đề khác về hiệu suất tín hiệu, nhưng đối với Code RL.

Nếu $k$ lần hoàn thiện đầu tiên của chúng ta đều vượt qua $\frac{7}{12}$ bài kiểm tra, thì Never Give Up sẽ không chấp nhận $k$ lần hoàn thiện tiếp theo trừ khi chúng vượt qua nhiều hơn $\frac{7}{12}$, thúc đẩy mô hình cải thiện dần dần. Nơi mà GRPO tiêu chuẩn bị đình trệ, GRPO + NGU tiếp tục giải các bài kiểm tra ngày càng khó hơn cho đến khi nó bắt đầu vượt qua hoàn toàn tất cả các bài kiểm tra cho một bài toán nhất định.

Hiệu ứng Matthew là một Thiên kiến ưu tiên (Primacy Bias), đại loại vậy #

Một số độc giả rất tinh ý có thể đã nhận thấy rằng Hiệu ứng Matthew giống với thiên kiến ưu tiên, nơi các LLM có xu hướng giải quyết các bài toán nhất định theo trạng thái ban đầu của chúng. Điều này liên kết trực quan Hiệu ứng Matthew với Thiên kiến ưu tiên trong Deep RL(12) (12)Nikishin, Schwarzer, D’Oro và cộng sự, (2022), nơi các quá trình huấn luyện deep RL có thể bị chệch hướng do các mẫu sớm kém chất lượng. Điều này một phần là do các vấn đề về tính dẻo (plasticity) trong các mạng thần kinh được huấn luyện bằng RL.