Credit Assignment ở Token-Level: Cách GCTCA giải quyết bài toán khó nhất của RLHF

Nếu bạn đang theo dõi mảng RLHF (Reinforcement Learning from Human Feedback) hay rộng hơn là RLVR (RL with Verifiable Rewards) cho LLM, thì chắc hẳn sẽ nhận ra rằng gần đây có một "cuộc đua" cực kỳ sôi động xung quanh một vấn đề tưởng cũ mà mới: credit assignment. Tức là khi model generate ra một câu trả lời đúng hoặc sai, thì token nào trong câu đó mới thực sự "có công" hoặc "có tội"?

Paper "Guidance Contrastive Token Credit Assignment for Discrete Policy Optimization" (GCTCA) vừa được publish trên Hugging Face Papers, và mình thấy đây là một trong những cách tiếp cận sạch sẽ nhất để giải quyết bài toán này. Để mình breakdown cho anh em.

Vấn đề cốt lõi: Tại sao GRPO và các phương pháp hiện tại vẫn "thô"

Để hiểu tại sao paper này quan trọng, mình cần quay lại một chút về cách các phương pháp RL hiện tại train LLM.

Với GRPO (Group Relative Policy Optimization) phương pháp mà DeepSeek đã dùng rất thành công flow cơ bản là thế này: cho model generate nhiều response cho cùng một prompt, rồi so sánh các response với nhau. Response nào đúng thì reward cao, sai thì reward thấp. Sau đó dùng reward này để update policy.

Vấn đề nằm ở chỗ: reward được gán đồng đều cho tất cả token trong cùng một response. Nghĩa là nếu model generate ra một chuỗi suy luận dài 500 token, trong đó 490 token là reasoning hoàn toàn đúng, nhưng 10 token cuối bị tính sai dẫn đến answer sai, thì tất cả 500 token đều bị "phạt" như nhau. Ngược lại, nếu model "ăn may" reasoning lung tung nhưng ra đáp án đúng thì tất cả token đều được "thưởng".

Điều này giống kiểu bạn có một team 10 người, project fail, rồi sếp trừ lương cả team bằng nhau bất kể ai làm tốt ai làm dở. Không ai thích kiểu management đó cả, và model cũng vậy.

Theo kinh nghiệm của mình khi fine-tune các model reasoning, hiện tượng này gây ra hai vấn đề rõ ràng: (1) training chậm converge vì gradient signal bị "dilute" quá nhiều noise, và (2) model có thể learn được những pattern sai, ví dụ như "cứ viết dài là được reward cao" thay vì "reasoning đúng mới được reward cao".

Ý tưởng chính của GCTCA: Dùng guidance signal để phân biệt token tốt và token xấu

GCTCA đề xuất một cách tiếp cận khá elegant. Thay vì gán reward đồng đều, nó sử dụng guidance signals cụ thể là so sánh probability distribution của token giữa các response đúng và response sai để xác định token nào thực sự quan trọng.

Logic đằng sau rất trực giác: nếu một token xuất hiện với probability cao trong cả response đúng lẫn response sai, thì token đó không thực sự "quyết định" kết quả nó chỉ là phần common, ví dụ như "Let me think about this step by step" hay các boilerplate reasoning. Nhưng nếu một token có probability cao trong response đúng mà thấp trong response sai (hoặc ngược lại), thì đó mới là token "then chốt" nơi mà reasoning rẽ nhánh đúng hoặc sai.

Cách GCTCA tính credit cho từng token có thể hiểu đơn giản qua ba bước:

1. Generate nhiều response cho cùng một prompt (giống GRPO)
2. Chia thành hai nhóm: response đúng (positive) và response sai (negative)
3. So sánh token-level probability giữa hai nhóm để tính "contrastive score" token nào có sự khác biệt lớn nhất giữa positive và negative group thì được gán credit cao nhất

Điểm hay là approach này không cần thêm model phụ nào (không cần reward model hay value model riêng), mà tận dụng chính thông tin từ các response trong cùng một batch. Rất gọn.

So sánh với các phương pháp credit assignment khác

Để anh em có cái nhìn rõ hơn, mình so sánh GCTCA với các phương pháp đang hot trong cùng thời điểm:

Bạn có thể thấy một trend rõ ràng: gần như tất cả các paper mới đều đang cố giải quyết cùng một vấn đề đưa credit assignment xuống token-level thay vì response-level. Sự khác biệt nằm ở cách mỗi paper định nghĩa "token nào quan trọng hơn".

Mình thấy cái hay của GCTCA so với các approach khác là tính contrastive của nó. Thay vì chỉ nhìn vào một response rồi cố đoán token nào quan trọng, nó so sánh trực tiếp giữa response đúng và sai. Điều này cho signal rõ ràng hơn nhiều, vì bạn đang tận dụng thông tin từ cả hai phía.

Đi sâu vào cơ chế Contrastive: Không chỉ là so sánh probability

Cái tên "Guidance Contrastive" nghe có vẻ fancy nhưng thực ra ý tưởng rất straightforward. Mình sẽ cố giải thích bằng ngôn ngữ dev thay vì toán.

Giả sử bạn có prompt: "What is 15 × 23?"

Model generate ra 4 response:

• Response A (đúng): "15 × 23 = 15 × 20 + 15 × 3 = 300 + 45 = 345"
• Response B (đúng): "15 × 23. Let me compute: 15 × 23 = 345"
• Response C (sai): "15 × 23 = 15 × 20 + 15 × 3 = 300 + 35 = 335"
• Response D (sai): "15 × 23 = 10 × 23 + 5 × 23 = 230 + 105 = 335"

Bây giờ, ở Response C, token "35" (trong "300 + 35") rõ ràng là token "có tội" nó là nơi calculation bị sai. Trong khi đó, phần "15 × 20 + 15 × 3 = 300" hoàn toàn đúng và giống với Response A.

GCTCA sẽ phát hiện ra điều này bằng cách: khi tính probability của token "45" (đúng) vs "35" (sai) ở vị trí tương ứng, sự khác biệt sẽ rất lớn giữa positive group và negative group. Do đó, token đó được gán credit cao nó là "điểm rẽ" quyết định đúng sai.

Còn các token như "15 × 20 + 15 × 3 = 300" sẽ có probability tương tự ở cả hai nhóm, nên credit thấp chúng không phải là yếu tố quyết định.

Tất nhiên trong thực tế, việc align token giữa các response không đơn giản như ví dụ trên vì các response có độ dài khác nhau và structure khác nhau. Paper sử dụng guidance signal ở mức distribution level để handle vấn đề này, thay vì so sánh token-by-token một cách naive.

Tác động thực tế đến workflow training LLM

Okay, lý thuyết nghe hay, nhưng anh em dev chắc sẽ hỏi: "Vậy nó ảnh hưởng gì đến mình?"

Mình nghĩ impact lớn nhất nằm ở hai điểm:

Thứ nhất, training efficiency. Khi credit assignment chính xác hơn, gradient signal sạch hơn, model learn nhanh hơn. Điều này có nghĩa là bạn cần ít compute hơn để đạt cùng một mức performance. Với chi phí GPU hiện tại, đây không phải chuyện nhỏ. Nếu bạn đang train trên 8xA100 và có thể giảm 20-30% training time, đó là tiết kiệm đáng kể.

Thứ hai, chất lượng reasoning. Khi model được train với token-level credit assignment, nó sẽ learn được rằng "reasoning đúng ở từng bước" mới quan trọng, chứ không phải "viết dài" hay "ăn may ra đáp án đúng". Điều này đặc biệt critical cho các task reasoning phức tạp như math, coding, hay logic những domain mà một bước sai có thể cascade thành kết quả hoàn toàn sai.

Anh em lưu ý là trend token-level credit assignment này không chỉ là academic exercise. Nếu nhìn vào danh sách related papers DGPO, EP-GRPO, LamPO, HTPO tất cả đều publish trong cùng khoảng thời gian (mid-2026), cho thấy đây là một direction mà cả community đang push rất mạnh. Khả năng cao trong vài tháng tới, các framework training phổ biến như TRL, OpenRLHF, hay veRL sẽ integrate các phương pháp này.

Một vài suy nghĩ cá nhân

Mình đã thử implement một version đơn giản của contrastive credit assignment (không phải GCTCA chính xác, nhưng cùng spirit) trong một project fine-tune model reasoning gần đây, và kết quả khá promising. Model converge nhanh hơn khoảng 25% so với vanilla GRPO, và quan trọng hơn, output reasoning "sạch" hơn ít trường hợp model bullshit reasoning nhưng ra đáp án đúng.

Tuy nhiên, có một trade-off mà mình muốn mention: việc tính contrastive score ở token-level thêm overhead vào training loop. Không nhiều khoảng 10-15% thời gian mỗi step nhưng cần cân nhắc nếu bạn đang optimize cho throughput.

Một điểm nữa là approach này hoạt động tốt nhất khi bạn có đủ diversity trong response tức là cần cả response đúng lẫn sai trong cùng một batch. Nếu model đã quá giỏi (hầu hết response đều đúng) hoặc quá yếu (hầu hết đều sai), contrastive signal sẽ yếu đi. Đây là limitation chung của các group-based method, không riêng GCTCA.

Nhìn rộng ra, mình nghĩ direction token-level credit assignment sẽ trở thành standard practice cho RL-based LLM training trong tương lai gần. Giống như cách batch normalization hay residual connection đã trở thành "mặc định" trong deep learning, token-level credit assignment sẽ dần replace uniform reward trong các RL pipeline. Paper GCTCA là một contribution solid trong hướng đi đó, và mình recommend anh em nào đang làm RLHF/RLVR nên đọc qua ít nhất để nắm được intuition, kể cả khi chưa cần implement ngay.