
Supervised fine-tuning dạy được mô hình bắt chước. Nó không dạy được mô hình
giỏi hơn thứ nó bắt chước.

Đó là toàn bộ lý do RLHF tồn tại. Nếu bạn có một tập dữ liệu gồm những câu trả
lời tốt, bạn huấn luyện mô hình tái tạo lại chúng từng token một — đó vẫn là dự
đoán token kế tiếp, chỉ với dữ liệu đẹp hơn. Nhưng phần lớn cái làm nên một câu
trả lời tốt lại không viết ra được thành một chuỗi mục tiêu. Nó mang tính so
sánh: câu này hữu ích hơn câu kia, câu này từ chối trong khi lẽ ra không nên,
câu này đúng về kỹ thuật nhưng đọc không nổi. Không ai viết ra được câu trả lời
đúng, nhưng gần như ai cũng chọn được câu nào hay hơn trong hai câu.

RLHF là bộ máy biến phép so sánh đó thành gradient. PPO là phần giữ cho gradient
không phá hỏng mô hình trên đường đi.

## Ba giai đoạn

RLHF không phải một thuật toán. Nó là ba lượt huấn luyện xếp chồng lên nhau, và
nhầm lẫn giữa chúng là nguồn gốc thông thường của mọi hiểu lầm về nó.

**Giai đoạn 1 — supervised fine-tuning.** Lấy một mô hình pretrained và fine-tune
trên dữ liệu minh hoạ: prompt kèm câu trả lời do người viết hoặc phê duyệt. Đây
là huấn luyện cross-entropy thông thường. Nhiệm vụ của nó không phải làm mô hình
giỏi, chỉ là làm nó trả lời đúng định dạng để hai giai đoạn sau có thứ dùng được
mà lấy mẫu. Gọi kết quả là mô hình SFT.

**Giai đoạn 2 — reward model.** Lấy nhiều câu trả lời cho cùng một prompt từ mô
hình SFT, cho người xếp hạng, rồi huấn luyện một mô hình riêng dự đoán thứ hạng
đó dưới dạng một số vô hướng.

**Giai đoạn 3 — reinforcement learning.** Để mô hình SFT sinh ra câu trả lời,
chấm điểm bằng reward model, rồi cập nhật mô hình sao cho điểm cao hơn. Đây là
chỗ PPO xuất hiện.

<RlhfStages />

Những quyết định thiết kế đáng chú ý đều nằm ở giai đoạn 2 và 3.

## Giai đoạn 2: học một reward từ phép so sánh

Con người chấm điểm tuyệt đối rất tệ. Bảo mười người chấm một câu trả lời từ 1
đến 10 thì bạn nhận về mười thang đo khác nhau. Hỏi họ trong hai câu thì câu nào
hơn, mức đồng thuận cao hơn hẳn. Nên dữ liệu ưu tiên được thu thập theo cặp: với
prompt `x`, một câu được chọn `y_w` và một câu bị loại `y_l`.

Reward model `r` thường chính là mô hình SFT, thay đầu ra ngôn ngữ bằng một đầu
ra vô hướng. Nó được huấn luyện bằng hàm mục tiêu Bradley-Terry, phát biểu rằng
xác suất một người thích `y_w` hơn `y_l` là sigmoid của hiệu hai điểm số:

```python
# reward_chosen, reward_rejected: (batch,) số vô hướng từ reward model
loss = -torch.nn.functional.logsigmoid(reward_chosen - reward_rejected).mean()
```

Ba hệ quả rơi ra từ hàm mất mát này, và cả ba đều quan trọng về sau.

Reward chỉ có ý nghĩa **tương đối so với các câu trả lời khác của cùng một
prompt**. Không có gì neo giá trị tuyệt đối lại — cộng một hằng số vào mọi điểm
thì hàm mất mát không đổi. Nên những con số reward model xuất ra không so sánh
được giữa các prompt khác nhau, và "reward tăng" chỉ có nghĩa trong phạm vi một
prompt.

Nó là một **hàm xấp xỉ đã học, không hoàn hảo**, cho sở thích của con người,
huấn luyện trên một mẫu hữu hạn. Ở bất cứ đâu policy đi lạc ra ngoài phân phối mà
reward model từng thấy, đầu ra của nó là phỏng đoán.

Và nó **bị đóng băng** trong giai đoạn 3. Policy sẽ tối ưu ngược lại một hàm cố
định, không hoàn hảo, suốt hàng nghìn bước. Nhớ kỹ điều này.

## Tại sao lại cần reinforcement learning?

Đây là phiên bản thẳng thắn của câu hỏi: bạn đã có một số vô hướng cho mỗi chuỗi
sinh ra rồi. Sao không fine-tune luôn trên những câu điểm cao và kết thúc ở đó?

Bạn làm được, và đó gần như chính là rejection sampling hay best-of-n
fine-tuning. Nó hiệu quả, và đơn giản hơn nhiều. RL xứng đáng với độ phức tạp của
nó vì một lý do: reward đến **một lần duy nhất, ở cuối cả chuỗi**, và nó **không
khả vi** theo tham số của mô hình.

Nghĩ xem mô hình thực sự làm gì. Ở mỗi bước nó chọn một token từ một phân phối
trên toàn bộ từ vựng. Việc lấy mẫu không khả vi — bạn không thể lan truyền ngược
qua "và rồi nó chọn token thứ 4.712". Reward model chấm điểm văn bản đã hoàn
chỉnh, nên không có mục tiêu ở cấp token nào để tính cross-entropy.

Reinforcement learning chính là bộ công cụ cho đúng dạng bài toán này: hành động
rời rạc, phản hồi không khả vi, và công lao phải được gán ngược lại cho một chuỗi
lựa chọn. Ánh xạ sang thuật ngữ RL:

- **state** — prompt cộng với mọi thứ đã sinh ra tới thời điểm đó
- **action** — token kế tiếp
- **policy** — chính mô hình ngôn ngữ
- **reward** — điểm của reward model, trả về ở token cuối cùng

## Policy gradient, và chỗ nó hỏng

Ý tưởng policy gradient cơ bản khá trực giác. Tăng log-probability của những hành
động dẫn tới reward cao, giảm của những hành động dẫn tới reward thấp, đánh trọng
số theo mức độ tốt hơn kỳ vọng:

```python
loss = -(log_prob * advantage).mean()
```

`advantage` là reward trừ đi một mức nền — hành động này tốt hơn bao nhiêu so với
mức bạn thường mong đợi ở trạng thái đó. Trừ đi mức nền không làm đổi hướng
gradient tính trung bình, nhưng giảm phương sai của nó rất mạnh, và đó là lý do
mọi bản cài đặt thực tế đều có một value network dự đoán mức nền ấy.

Vấn đề nằm ở độ dài bước. Gradient này chỉ đúng với chính policy đã sinh ra dữ
liệu. Đi một bước lớn thì policy mới đã khác đủ nhiều để các trajectory đã thu
thập không còn mô tả nó nữa, và lần cập nhật kế tiếp được tính từ thông tin đã
cũ. Ở mô hình ngôn ngữ, kiểu hỏng này rất kịch tính: mô hình tìm thấy một vùng
suy biến có reward cao, sụp về đó, rồi bắt đầu nhả ra cùng một đoạn văn nịnh nọt
bất kể prompt là gì. Một khi nó ngừng sinh ra mẫu đa dạng, nó không hồi phục
được, vì nó không còn khám phá bất cứ thứ gì mà reward model chấm khác đi.

Vậy nên bạn cần bước nhỏ. Nhưng "dùng learning rate nhỏ" là một công cụ thô — cùng
một learning rate sẽ quá lớn ở vùng này và nhỏ đến lãng phí ở vùng khác.

## PPO: chặn bước cập nhật, không phải chặn learning rate

Cái hay của PPO là ràng buộc bước cập nhật theo **mức thay đổi của phân phối đầu
ra**, chứ không theo khoảng cách tham số đã dịch chuyển.

Định nghĩa tỉ lệ xác suất giữa policy mới và policy đã sinh ra dữ liệu:

```
ratio = pi_new(a | s) / pi_old(a | s)
```

Tỉ lệ bằng 1 nghĩa là policy không đổi với token đó. Lớn hơn 1 nghĩa là policy
mới có xu hướng sinh ra token đó nhiều hơn. Hàm mục tiêu thay thế có cắt ngưỡng
là:

```python
ratio = torch.exp(new_log_probs - old_log_probs)   # exp của hiệu hai log
unclipped = ratio * advantages
clipped = torch.clamp(ratio, 1 - eps, 1 + eps) * advantages
policy_loss = -torch.min(unclipped, clipped).mean()
```

với `eps` thường bằng 0.2. Đọc kỹ chữ `min`, vì đó là toàn bộ mẹo, và nó **không
đối xứng**.

<PpoClip />

Khi advantage **dương** — token này tốt hơn kỳ vọng — hàm mục tiêu muốn tăng tỉ
lệ. Cắt ngưỡng chặn nó lại ở `1 + eps`. Qua điểm đó gradient bằng không: mô hình
không được thưởng thêm vì đẩy xác suất token này cao hơn nữa trong lần cập nhật
này. Nó đã dịch chuyển đủ rồi.

Khi advantage **âm**, hàm mục tiêu muốn giảm tỉ lệ, và cắt ngưỡng chặn sàn ở
`1 - eps`. Cùng một logic, theo chiều ngược lại.

Vì lấy giá trị nhỏ hơn giữa số hạng bị cắt và không bị cắt, PPO mang tính bi
quan. Nó không bao giờ để việc cắt ngưỡng làm một bước cập nhật trở nên *hấp dẫn
hơn*, chỉ có thể kém hơn. Và cách cắt này một chiều theo một nghĩa hữu ích: nếu
tỉ lệ đã vọt xa khỏi khoảng theo hướng sai, số hạng không cắt được chọn và
gradient vẫn kéo nó về. Cắt ngưỡng ngăn bạn chạy đi mất; nó không ngăn bạn quay
về.

Cái lợi thực tế là bạn có thể lấy vài bước gradient trên cùng một lô dữ liệu đã
sinh trước khi nó trở nên cũ — bình thường bạn chỉ được một bước — và điều đó cực
kỳ đáng giá khi việc sinh ra lô dữ liệu ấy nghĩa là chạy inference qua một mô
hình lớn.

## Dây xích KL

Cắt ngưỡng giới hạn policy dịch chuyển bao xa **trong mỗi lần cập nhật**. Nó
không nói gì về chỗ policy sẽ dừng lại sau mười nghìn lần. Cứ để mặc, mô hình sẽ
vui vẻ trôi tới nơi nào đó mà reward model chấm cao còn con người thấy vô dụng,
bởi reward model là một hàm xấp xỉ, và mọi hàm xấp xỉ đều có kẽ hở.

Đây không phải chuyện giả định. Tối ưu đủ mạnh ngược lại một reward model và bạn
nhận về những đầu ra nhồi đầy các đặc điểm bề mặt mà nó tương quan với chất
lượng: rào đón quá mức, bullet point khắp nơi, nhắc lại câu hỏi, và trên hết là
**độ dài**, vì câu trả lời dài chấm điểm cao hơn trong hầu hết tập dữ liệu ưu
tiên, và reward model đã học được điều đó.

Cách chữa là một khoản phạt KL so với mô hình SFT đã đóng băng, tính trên từng
token:

```python
# reference = mô hình SFT đã đóng băng; cả hai đều là log-prob của token đã lấy mẫu
kl = new_log_probs - ref_log_probs
rewards = reward_model_score - kl_coef * kl
```

Policy giờ tối ưu điểm của reward model *trừ đi* một khoản phí cho mỗi token mà
nó lệch khỏi mô hình nó xuất phát. Hệ số quy định tỉ giá: một đơn vị trôi dạt
đáng giá bao nhiêu reward. Đặt cao quá thì không có gì thay đổi; thấp quá thì mô
hình đi lạc và luồn lách reward.

Hai chi tiết đáng biết. Điểm của reward model là một con số duy nhất ở cuối
chuỗi, trong khi số hạng KL bị tính ở mọi token — tín hiệu reward tổng thể dày
đặc về KL và thưa thớt về sở thích thật. Và trên thực tế KL thường được ước lượng
bằng một estimator không chệch có phương sai thấp hơn, thay vì hiệu log-ratio
thô, vì bản ngây thơ đủ nhiễu để gây hại.

## Toàn bộ vòng lặp

```python
for batch in prompts:
    # 1. sinh, và ghi lại log-prob của chính policy đã sinh ra chúng
    responses, old_log_probs = policy.generate(batch)

    # 2. chấm điểm
    scores = reward_model(batch, responses)             # một số vô hướng mỗi câu
    ref_log_probs = reference_model.log_probs(batch, responses)
    kl = old_log_probs - ref_log_probs
    rewards = scores - kl_coef * kl                     # theo từng token

    # 3. gán công lao
    values = value_head(batch, responses)
    advantages = compute_gae(rewards, values, gamma, lam)

    # 4. vài epoch trên cùng một lô -- đây là thứ mà cắt ngưỡng mua cho bạn
    for _ in range(ppo_epochs):
        new_log_probs = policy.log_probs(batch, responses)
        ratio = torch.exp(new_log_probs - old_log_probs)

        policy_loss = -torch.min(
            ratio * advantages,
            torch.clamp(ratio, 1 - eps, 1 + eps) * advantages,
        ).mean()

        value_loss = ((value_head(batch, responses) - returns) ** 2).mean()
        loss = policy_loss + vf_coef * value_loss

        loss.backward()
        optimizer.step()
```

Tức là bốn mô hình cùng nằm trong bộ nhớ một lúc: policy đang được huấn luyện,
bản reference đóng băng, reward model, và value head. Đó là lý do RLHF được nhớ
đến vì tốn kém và rắc rối chẳng kém gì vì thành quả nó mang lại.

## Những gì thực sự hỏng

**Reward hacking** là kiểu hỏng nổi bật nhất, và nó không phải một lỗi bạn sửa
được bằng cách cẩn thận hơn. Reward model là xấp xỉ từ mẫu hữu hạn cho sở thích
con người; tối ưu một hàm xấp xỉ đủ mạnh thì luôn tìm ra khoảng cách giữa nó và
thứ nó đại diện. Nhìn đường reward đi lên tự nó không nói lên điều gì — nó đi lên
y hệt nhau dù mô hình đang tốt lên hay đang học cách khai thác kẽ hở.

**Length bias** xứng đáng có tên riêng vì nó xuất hiện quá đều đặn. Người gán
nhãn hơi thích câu trả lời đầy đủ, reward model học "dài hơn thì tốt hơn" như một
tương quan dễ nắm, và policy học cách nói dài dòng. Vài bản cài đặt trừ thẳng một
khoản phạt độ dài; phần lớn chỉ theo dõi số token trung bình.

**KL sụp theo cả hai chiều.** Phạt quá nặng thì bạn tiêu tốn rất nhiều tính toán
để tái tạo lại đúng mô hình SFT. Phạt quá nhẹ thì policy rời khỏi phân phối mà
reward model hiểu được, nơi điểm số của nó chỉ là phỏng đoán, và nó tối ưu ngược
lại nhiễu.

**Value function bất ổn.** Value head khởi đầu chẳng biết gì, nên advantage giai
đoạn đầu chủ yếu là nhiễu, sinh ra những bước cập nhật tệ đúng lúc policy dễ bị
uốn nắn nhất. Làm nóng value head trước khi cho policy dịch chuyển là cách chữa
phổ biến.

## Sau đó là gì

Điều dễ phàn nàn nhất về quy trình trên là nó quá đồ sộ so với việc nó làm. Huấn
luyện một reward model, rồi chạy một vòng lặp RL với bốn mô hình thường trú, cân
bằng cẩn thận với một số hạng KL, chỉ để rút tín hiệu ra từ dữ liệu vốn chỉ là
những cặp "câu này hơn".

Direct Preference Optimization là câu trả lời nổi tiếng cho chuyện đó. Phần dẫn
giải cho thấy policy tối ưu dưới một hàm mục tiêu reward có ràng buộc KL tồn tại
ở dạng đóng, và dạng đó sắp xếp lại được để biểu diễn *reward* theo policy và mô
hình reference. Thay ngược vào hàm mất mát Bradley-Terry thì reward model triệt
tiêu. Còn lại là một hàm mất mát có giám sát tính thẳng trên các cặp ưu tiên:

```python
chosen_logratio = policy_chosen_logps - reference_chosen_logps
rejected_logratio = policy_rejected_logps - reference_rejected_logps
loss = -torch.nn.functional.logsigmoid(beta * (chosen_logratio - rejected_logratio)).mean()
```

Không reward model, không vòng lặp lấy mẫu, không value head. Hai mô hình thay vì
bốn, và một vòng huấn luyện bình thường.

Nó không hẳn tốt hơn. DPO chỉ huấn luyện trên tập ưu tiên cố định, nên nó không
bao giờ nhìn thấy đầu ra hiện tại của chính policy — mà khả năng sinh ra, chấm
điểm, rồi học từ thứ mô hình tạo ra *ngay lúc này* mới đúng là thứ online RL mang
lại. Đó là lý do các biến thể online tồn tại, và là lý do PPO chưa biến mất.

Và đó là cách hữu ích để nhìn toàn bộ chuyện này: PPO không phải trọng tâm của
RLHF. Trọng tâm là chuyển sở thích thành tín hiệu huấn luyện. PPO là một câu trả
lời cho câu hỏi làm sao đi theo tín hiệu đó mà không ngã, và hiểu **tại sao** nó
cắt ngưỡng cho bạn nhiều hơn là thuộc lòng rằng nó có cắt.

## Tham khảo

- [Training language models to follow instructions with human feedback](https://arxiv.org/abs/2203.02155) — bài InstructGPT, mô tả kinh điển về quy trình ba giai đoạn
- [Proximal Policy Optimization Algorithms](https://arxiv.org/abs/1707.06347) — chính PPO, ra đời trước tất cả những thứ trên năm năm
- [Direct Preference Optimization](https://arxiv.org/abs/2305.18290) — phần dẫn giải loại bỏ reward model
- [Deep reinforcement learning from human preferences](https://arxiv.org/abs/1706.03741) — công trình trước đó, thiết lập việc học một reward model từ phép so sánh


Không thể dạy một mô hình ngôn ngữ rằng "câu này hay hơn câu kia" bằng học có giám sát. RLHF biến phép so sánh đó thành gradient, còn PPO là thứ giữ cho gradient không phá nát mô hình.

RLHF hoạt động thế nào, và tại sao lại là PPO


Mọi danh sách "toán cho ML" đều là ba môn giống nhau: đại số tuyến tính, giải
tích, xác suất. Mỗi môn một học kỳ. Cộng lại là một năm bạn không có, và phần lớn
nội dung trong đó bạn sẽ không bao giờ dùng tới.

Phiên bản hữu ích của câu hỏi thì hẹp hơn. Những ý nào cứ xuất hiện đi xuất hiện
lại trong code, và biết chúng cho phép bạn làm được gì mà không biết thì không
làm được? Danh sách đó ngắn. Khoảng sáu ý, và không ý nào khó. Cái khiến chúng
đáng học cho tử tế là chúng biến những lời gọi thư viện từ câu thần chú thành thứ
có lý do.

Nếu bạn học kỹ sư thì đã gặp hết rồi. Mình học xây dựng, và mọi thứ dưới đây đều
có trong các môn ấy — ma trận cho phân tích kết cấu, đạo hàm cho mọi thứ, xác
suất cho hệ số tải. Cái thay đổi không phải bản thân toán. Mà là nó chĩa vào đâu.

## Ma trận là một hàm, không phải bảng số

Đây là cách nhìn lại duy nhất khiến đại số tuyến tính khớp vào ML.

Ở trường, ma trận là một bảng mà bạn học quy tắc nhân. Trong ML, ma trận là một
**ánh xạ tuyến tính**: một hàm nhận vector vào và trả vector ra. Nhân hai ma trận
không phải thao tác trên bảng, nó là **ghép hai hàm**. `AB` nghĩa là làm `B`
trước, rồi làm `A`.

Nhìn theo cách đó thì một tầng mạng nơ-ron hết bí ẩn ngay:

```python
h = W @ x + b
```

`W` ánh xạ vector đầu vào sang một không gian khác, có thể khác số chiều, còn `b`
dịch nó đi. Đó là toàn bộ một tầng. Một mạng là một chồng các ánh xạ như vậy.

Và điều đó lập tức đặt ra một câu hỏi đáng ngồi lại. Nếu mọi tầng đều là ánh xạ
tuyến tính, mà ghép các ánh xạ tuyến tính lại thì vẫn ra một ánh xạ tuyến tính,
thì một trăm tầng chồng lên nhau sẽ gộp thành đúng một ma trận tương đương. Toàn
bộ chiều sâu ấy chẳng mua được gì.

Đó chính xác là lý do hàm kích hoạt không phải tuỳ chọn. `ReLU`, `sigmoid`,
`tanh` — việc của chúng là phá tính tuyến tính để phép ghép thực sự tăng khả năng
biểu diễn. Hàm kích hoạt không phải chi tiết gắn thêm cho tiện; nó là lý do chiều
sâu có ý nghĩa. Bạn không suy ra được điều này từ cách nhìn bảng-số, và suy ra
ngay lập tức từ cách nhìn hàm.

### Tích vô hướng là con ngựa kéo

Hai vector, nhân từng phần tử, cộng lại. Đơn giản đến tầm thường, mà nó đang gánh
phần lớn công việc trong ML hiện đại, bởi tích vô hướng đo **độ thẳng hàng**.

```python
similarity = a @ b        # lớn khi a và b cùng hướng
```

Mọi hệ thống dựa trên embedding đều chạy trên phép này. "Tìm tài liệu tương tự"
là một tích vô hướng với các vector đã lưu. Điểm attention là tích vô hướng giữa
query và key — token này nên quan tâm tới token kia bao nhiêu — và câu trả lời là
hai vector của chúng thẳng hàng tới mức nào.

<DotProduct />

Đây là một chi tiết cho thấy toán mua cho bạn cái gì. Attention không phải
`q @ k`, mà là:

```python
scores = (q @ k.T) / math.sqrt(d_k)
```

Tại sao chia cho căn bậc hai của số chiều? Vì nếu các thành phần của `q` và `k`
gần như độc lập với phương sai đơn vị, thì tích vô hướng qua `d_k` số hạng có
phương sai tỉ lệ với `d_k`. Nên số chiều càng lớn thì điểm số càng dàn rộng ra, mà
softmax trên các giá trị dàn rộng thì bão hoà — nó gần như thành one-hot, gradient
biến mất, và mô hình ngừng học được nên chú ý vào đâu. Chia cho căn `d_k` giữ
phương sai ổn định.

Đó là một dòng code trông có vẻ tuỳ tiện mà không hề tuỳ tiện. Một đoạn xác suất
giải thích được nó.

### Shape là công cụ debug của bạn

Thói quen ít hào nhoáng nhất và hữu ích nhất: theo dõi shape của mọi tensor.

```python
x        # (batch, seq_len, d_model)
W_q      # (d_model, d_head)
q = x @ W_q   # (batch, seq_len, d_head)
```

Một phần lớn lỗi thật là lỗi shape mà không hề crash — một phép broadcast lặng lẽ
làm sai thứ, một phép transpose lẽ ra không nên có, một chiều batch bị cộng gộp
mất. Nếu bạn đoán được shape đầu ra của từng dòng trước khi chạy, bạn bắt được
chúng bằng cách đọc. Nếu không, bạn debug bằng lệnh in.

## Đạo hàm: hướng nào là xuống dốc

Huấn luyện là một ý lặp đi lặp lại: đo xem đang sai bao nhiêu, tìm hướng làm giảm
cái sai đó, đi một bước nhỏ theo hướng ấy.

**Đạo hàm** trả lời "nếu tôi nhích đầu vào này một chút, đầu ra đổi bao nhiêu và
theo chiều nào?" **Gradient** là câu trả lời đó cho mọi tham số cùng lúc, gom lại
thành một vector. Nó chỉ về hướng tăng dốc nhất, nên bạn bước ngược lại:

```python
for p in parameters:
    p -= learning_rate * p.grad
```

Đó là gradient descent. Đó là toàn bộ câu chuyện tối ưu trước khi có các cải tiến.

### Backpropagation chính là chain rule, không hơn

Chain rule nói: để lấy đạo hàm của các hàm lồng nhau, hãy nhân đạo hàm của từng
lớp lồng.

Lấy một mạng nhỏ đến mức làm tay được:

```python
z = w * x + b          # tuyến tính
a = sigmoid(z)         # kích hoạt
L = (a - y) ** 2       # hàm mất mát
```

Hàm mất mát đổi thế nào theo `w`? Đi ngược lại, nhân vào:

```
dL/dw = dL/da * da/dz * dz/dw
      = 2 * (a - y)   *  a * (1 - a)  *  x
```

Ba đạo hàm cục bộ, mỗi cái tự nó hiển nhiên, nhân với nhau. Đó là backprop. Một
framework làm việc đó cho một triệu tham số thay vì một, và lưu lại các giá trị
trung gian để không tính lại, nhưng không có thêm ý tưởng nào cả.

Và giờ là phần đáng giá, vì nó giải thích một mẩu lịch sử. Nhìn số hạng ở giữa,
đạo hàm của sigmoid: `a * (1 - a)`. Giá trị lớn nhất có thể của nó là `0.25`, tại
`a = 0.5`. Trong một mạng sâu bạn nhân một cái như thế mỗi tầng. Mười tầng sigmoid
và gradient tới được tầng đầu tiên bị nhân với nhiều nhất là `0.25 ** 10`, tức
khoảng một phần triệu. Các tầng đầu gần như không nhận được gì và không bao giờ
học.

<VanishingGradient />

Đó là bài toán vanishing gradient, và là lý do `ReLU` — đạo hàm đúng bằng `1` với
đầu vào dương, nên nhân qua mà không co lại — từng là một bước cởi trói lớn đến
vậy. Hai dòng chain rule nói cho bạn biết vì sao một lựa chọn kiến trúc lại quan
trọng.

## Xác suất: mô hình của bạn xuất ra một phân phối

Bước làm sắp xếp lại mọi thứ: một bộ phân loại không xuất ra một câu trả lời, nó
xuất ra một **phân phối xác suất trên các câu trả lời**. Một mô hình ngôn ngữ
không xuất ra token kế tiếp, nó xuất ra một phân phối trên toàn bộ từ vựng.

Một khi chấp nhận điều đó, hàm mất mát thôi là một lựa chọn thiết kế và trở thành
một hệ quả suy ra được.

### Maximum likelihood, và các hàm mất mát đến từ đâu

Bạn có dữ liệu và một mô hình có tham số. Hỏi: bộ tham số nào làm cho dữ liệu quan
sát được trở nên khả dĩ nhất?

Giả sử các mẫu độc lập, xác suất của cả tập dữ liệu là tích các xác suất riêng lẻ:

```
likelihood = p(y_1 | x_1) * p(y_2 | x_2) * ... * p(y_n | x_n)
```

Tích của nhiều số nhỏ thì tràn số dưới, nên lấy log — phép này biến tích thành
tổng và đơn điệu nên không làm dịch điểm cực đại. Đổi dấu để thành bài toán cực
tiểu, và bạn có **negative log-likelihood**:

```
NLL = -sum( log p(y_i | x_i) )
```

Giờ đặc biệt hoá nó, và xem các hàm mất mát quen thuộc rơi ra.

**Phân loại.** Mô hình cho một xác suất mỗi lớp. Log xác suất âm của lớp đúng,
cộng trên toàn dữ liệu, chính xác là cross-entropy loss. Nó không được chọn vì
chạy tốt. Nó *là* maximum likelihood cho một đầu ra phân loại.

**Hồi quy.** Giả sử giá trị mục tiêu bằng dự đoán cộng nhiễu Gauss với phương sai
cố định. Viết ra hàm mật độ Gauss, lấy log, và mọi thứ trừ số hạng bình phương
đều là hằng số theo tham số. Cái còn lại chính là sai số bình phương. Mean squared
error là maximum likelihood dưới giả thiết nhiễu Gauss.

Điều này đáng giá hơn một mẩu kiến thức vụn. Nó cho bạn biết khi nào MSE là công
cụ sai: khi nhiễu của bạn không phải Gauss. Dữ liệu đuôi nặng với thỉnh thoảng vài
điểm ngoại lai lớn vi phạm giả thiết, số hạng bình phương để một điểm ngoại lai
chi phối gradient, và cách chữa — Huber loss, hoặc dự đoán một phân vị — đến từ
việc chất vấn giả thiết chứ không từ một danh sách các hàm mất mát thay thế.

## Lý thuyết thông tin: ba đại lượng

Ba định nghĩa, liên hệ chặt với nhau, và xuất hiện liên tục.

**Entropy** là mức bất ngờ trung bình của một phân phối — nó bất định tới đâu. Một
đồng xu cân bằng có entropy cao; một đồng xu luôn ra mặt ngửa thì không có.

**Cross-entropy** là mức bất ngờ trung bình bạn nhận khi tin vào phân phối `Q`
trong khi thực tế theo `P`. Nó nhỏ nhất khi `Q` bằng `P`, và đó là lý do nó dùng
được làm hàm mất mát: bạn bị phạt theo khoảng cách giữa phân phối dự đoán và sự
thật.

**KL divergence** là hiệu của hai đại lượng trên:

```
KL(P || Q) = cross_entropy(P, Q) - entropy(P)
```

Đọc nó là: bạn phải trả thêm bao nhiêu bất ngờ vì dùng `Q` thay cho `P` thật. Nó
bằng không khi hai bên trùng nhau và lớn dần khi chúng lệch nhau.

Hai hệ quả. Vì `entropy(P)` không phụ thuộc mô hình của bạn, cực tiểu hoá
cross-entropy và cực tiểu hoá KL divergence là cùng một bài toán tối ưu — hàm mất
mát phân loại tiêu chuẩn vốn đã là một phép cực tiểu KL, chỉ là viết mà bỏ đi
hằng số.

Và KL không đối xứng. `KL(P || Q)` không bằng `KL(Q || P)`, và sự bất đối xứng đó
có răng. Cực tiểu hoá theo chiều này cho ra một `Q` trải rộng để phủ mọi nơi `P`
có khối lượng; chiều kia cho ra một `Q` co cụm vào một mode và bỏ qua phần còn
lại. Chọn chiều nào sẽ đổi hành vi của mô hình.

Nếu bạn đã đọc [bài về RLHF](/vi/article/rlhf-and-ppo), đây chính là KL xuất hiện
ở đó dưới dạng một khoản phạt. Policy bị tính phí vì lệch khỏi mô hình nó xuất
phát, và hệ số của khoản phí đó là tỉ giá giữa reward và độ trôi dạt. Cùng một đại
lượng, dùng làm dây xích thay vì làm hàm mất mát.

## Tối ưu: tại sao thứ đơn giản lại chạy được

Gradient descent có một kiểu hỏng hiển nhiên. Gradient mang tính cục bộ — nó chỉ
biết độ dốc ngay chỗ bạn đứng — nên nó đi xuống bất cứ thung lũng nào nó tình cờ
đang ở trong, chứ không phải thung lũng sâu nhất.

Với một hàm mất mát **lồi**, hình dạng như cái bát, chỉ có một thung lũng và
chuyện này không thành vấn đề. Hồi quy tuyến tính và logistic đều lồi, và đó là lý
do chúng huấn luyện rất ổn định.

Mạng nơ-ron thì không lồi một cách dữ dội. Cực kỳ nhiều cực tiểu địa phương và
điểm yên ngựa. Theo sách vở, gradient descent lẽ ra phải vô vọng.

Nó vẫn chạy, và các lý do đáng biết vì chúng biện minh cho những thứ nếu không thì
trông như kinh nghiệm dân gian:

**Ở số chiều rất lớn, cực tiểu địa phương tệ là hiếm.** Để một điểm là cực tiểu
địa phương, hàm mất mát phải cong lên theo *mọi* hướng trong hàng triệu hướng. Đó
là một sự trùng hợp phi thường. Phổ biến hơn nhiều là điểm yên ngựa, cong lên theo
vài hướng và cong xuống theo vài hướng khác — và một điểm yên ngựa thì có hướng đi
xuống, nên bạn thoát ra được.

**Nhiễu giúp ích.** Stochastic gradient descent tính gradient trên một lô nhỏ, nên
mỗi bước là một ước lượng có nhiễu của gradient thật. Nhiễu đó không chỉ là sự
đánh đổi về tính toán; nó cho phép bộ tối ưu rung lắc để thoát khỏi những thung
lũng hẹp. Đó là một tính năng.

**Phần lớn các cực tiểu đều tốt xấp xỉ nhau.** Trên thực nghiệm, rất nhiều cực
tiểu mà một mạng lớn có thể rơi vào đều đạt mức mất mát tương đương. Bạn không đi
tìm một lời giải đặc biệt giữa hàng triệu lời giải tồi.

Đây cũng là chỗ learning rate có được tiếng tăm quá khổ của nó. Quá lớn thì bạn
bước vượt qua cực tiểu rồi dao động hoặc phân kỳ; quá nhỏ thì huấn luyện mãi không
xong và mắc kẹt ở chỗ trũng nông đầu tiên. Không có tham số nào bạn chỉnh mà quan
trọng bằng nó.

## Cái gì có thể bỏ qua, tạm thời

Thành thật về chiều ngược lại cũng quan trọng ngang vậy.

Bạn không cần tính trị riêng bằng tay, nghịch đảo ma trận bằng tay, hay chứng minh
các định lý hội tụ. Bạn không cần lý thuyết độ đo. Bạn không cần phần lớn một môn
giải tích thực. Bạn không cần dẫn ra backprop cho một kiến trúc bất kỳ — bạn cần
biết nó là chain rule, để khi một gradient ra `NaN` thì bạn biết nhìn vào đâu.

Định thức, phân tích trị riêng và SVD thực sự hữu ích, nhưng hữu ích *về sau* và ở
những chỗ cụ thể: PCA, vài cách khởi tạo, phân tích xem một mô hình đã học được
gì. Học chúng khi bạn đụng phải, đừng học trước.

Kiểu hỏng ở đây không phải bỏ qua quá nhiều. Mà là dành sáu tháng cho một khoá đại
số tuyến tính trước khi viết một dòng code nào, rồi bước ra với một mớ định lý và
không biết cái nào quan trọng.

## Một thứ tự chạy được

Học xen kẽ với việc làm ra thứ gì đó, đừng học trước.

1. **Vector, ma trận, shape.** Đủ để đọc một định nghĩa mô hình và đoán được mọi
   shape tensor. Làm cái này trước; nó có lãi ngay.
2. **Đạo hàm và chain rule.** Đủ để tự tay dẫn ra ví dụ hai tầng phía trên. Rồi
   đọc một bản cài đặt backprop từ đầu và theo dõi từng dòng.
3. **Xác suất, tới maximum likelihood.** Đủ để tự dẫn ra cross-entropy thay vì
   chấp nhận nó.
4. **Entropy, cross-entropy, KL.** Nhỏ thôi, mà mở khoá được rất nhiều bài báo.
5. **Còn lại, học khi cần.** Khi một bài báo dùng thứ bạn chưa biết, học đúng thứ
   đó. Đây là bộ lọc tốt hơn mọi giáo trình, vì những thứ bạn liên tục gặp lại
   chính là những thứ quan trọng, theo định nghĩa.

Nếu bạn muốn một nguồn duy nhất thay vì ba khoá học,
[Mathematics for Machine Learning](https://mml-book.github.io/) (Deisenroth,
Faisal và Ong) miễn phí trên mạng và viết đúng cho mục đích này — phần toán mà ML
dùng, không kèm phần còn lại của tấm bằng. Muốn trực giác thay vì kỹ thuật tính
toán thì
[Essence of linear algebra](https://www.3blue1brown.com/topics/linear-algebra) và
[Essence of calculus](https://www.3blue1brown.com/topics/calculus) của 3Blue1Brown
là vài giờ đáng bỏ ra nhất.

## Điểm mấu chốt

Chuyện này không phải để chứng minh được định lý. Nó là khác biệt giữa việc đọc
`scores / math.sqrt(d_k)` như một dòng ai đó bảo bạn viết và đọc nó như một phép
kiểm soát phương sai. Giữa "cross-entropy là hàm mất mát cho bài toán phân loại"
và "cross-entropy là thứ mà maximum likelihood rút gọn thành ở đây, nên nó thôi
đúng khi giả thiết này thôi đúng".

Khác biệt đó là thứ cho phép bạn debug một mô hình, thay vì chạy lại vòng huấn
luyện với một seed ngẫu nhiên khác và hy vọng.


Không phải một giáo trình. Vài ý cứ quay đi quay lại trong code, mỗi ý ở đó để làm gì, và phần nào trong sách giáo khoa có thể bỏ qua cho tới khi thực sự cần.

Toán nền thực sự cần cho Machine Learning


Chào mừng đến với blog của mình 🥰

## Crop View là gì?

[Crop View](https://autode.sk/3pas1jq) giới hạn những gì một view hiển thị: chỉ
các đối tượng nằm trong vùng được khoanh mới được vẽ ra, phần ngoài bị cắt bỏ.

## Bật Crop View trong Revit thế nào?

Bật hai thuộc tính trong bảng Properties, hoặc dùng icon như hình dưới.

![Cropbox Property](/assets/images/blogs/cropview/cropbox-property.png 'Cropbox Property')

## Vậy làm sao crop nhiều view bằng RevitAPI?

Trong RevitAPI, Crop View được định nghĩa bởi thuộc tính `CropBox`, và nó nhận
vào một `BoundingBoxXYZ`.

**Bắt đầu thôi 🚀🚀🚀**

### Bước 1

Vùng crop được xác định bởi hai điểm — trong view hiện hành là góc trên bên phải
và góc dưới bên trái. Phương thức `PickBox` trả về cả hai chỉ trong một lần gọi:

```csharp

// Chọn vùng bằng cách kéo một hình chữ nhật
 PickedBox pickedBox = uidocument.Selection.PickBox(PickBoxStyle.Directional, "Draw Rectangular Box, Press ESC to exit");
 XYZ pointBottomLeft = pickedBox.Min;
 XYZ pointTopRight = pickedBox.Max;
```

### Bước 2

View hiện hành có `Transform` riêng của nó. Hai điểm vừa lấy đang ở toạ độ model,
nên phải đưa chúng về hệ toạ độ của view thì `CropBox` mới đặt đúng chỗ.

```csharp

// Lấy transform nghịch đảo của view hiện hành
Transform transform = view.get_BoundingBox(null).Transform.Inverse;
// Đưa hai điểm về hệ toạ độ của view
pointBottomLeft = transform.OfPoint(pointBottomLeft);
pointTopRight = transform.OfPoint(pointTopRight);

// Xác định đúng giá trị min và max
double minX = Math.Min(pBox.Min.X, pBox.Max.X);
double maxX = Math.Max(pBox.Min.X, pBox.Max.X);

double minY = Math.Min(pBox.Min.Y, pBox.Max.Y);
double maxY = Math.Max(pBox.Min.Y, pBox.Max.Y);
```

Bỏ qua bước này thì vùng crop vẫn ra một kết quả trông có vẻ hợp lý nhưng sai vị
trí — và kiểu sai đó khó phát hiện hơn là sai hẳn.

### Bước 3

Tạo `BoundingBoxXYZ` mới rồi gán cho `CropBox`.

```csharp
// Tạo instance boundingBox mới
BoundingBoxXYZ boundingBoxXYZ = new BoundingBoxXYZ();
boundingBoxXYZ.Min = new XYZ(minX, minX, 0);
boundingBoxXYZ.Max = new XYZ(maxX, maxY, 0);
boundingBoxXYZ.Transform = view.CropBox.Transform;

// Bật Crop View và áp boundingBox mới vào CropBox
view.CropBoxActive = true;
view.CropBoxVisible = true;
view.CropBox = boundingBoxXYZ;
doc.Regenerate();
```

### Bước 4

Bọc lại trong một `while-loop` để crop được nhiều view liên tiếp mà không phải
chạy lại lệnh. Nhớ dùng `Transaction`, không có nó thì không có gì được ghi vào
model.

```csharp
PickedBox pickedBox = null;
while (true)
{
    try
    {
        pickedBox = uiDocument.Selection.PickBox(PickBoxStyle.Directional, "Draw Rectangular, Press ESC to exit");
    }
    catch
    {
        break;
    }

    if (pickedBox != null)
    {
        using (Transaction transaction = new Transaction(document))
        {
            transaction.Start("Crop view by selection");
            // khối lệnh xử lý
            transaction.Commit();
        }
    }
}
```

## Vài điểm đáng nhớ

- `CropBoxActive` phải bằng `true` thì `CropBox` mới có tác dụng nhìn thấy được.
- `CropBoxVisible` quyết định đường bao có được in ra hay không.
- Mọi thay đổi phải nằm trong `Transaction`, nếu không sẽ không commit.

## Kết

Vậy là xong 🎯 — một công cụ nhỏ giúp tạo Crop View nhanh hơn nhiều so với làm tay.

## Tham khảo

Toàn bộ source code và vài công cụ khác nằm ở
[RevitAPI-Learning](https://github.com/LDATuan/RevitAPI-Learning)


Một công cụ nhỏ giúp tạo nhanh vùng crop cho bất kỳ view nào, thay vì chỉnh tay từng cái một.

Writing

RLHF hoạt động thế nào, và tại sao lại là PPO

Toán nền thực sự cần cho Machine Learning

Crop View bằng RevitAPI