Train agent theo ca, không theo câu

Train agent theo ca, không theo câu

Multi-turn RL không phải món đồ mới để khoe stack. Nó là quyết định hạ tầng: khi nào đáng dựng, lớp nào cần giữ, lớp nào nên bỏ qua.

Có một kiểu demo agent nhìn rất đã: bạn gõ yêu cầu, nó gọi tool, trả lời tròn trịa, cả team vỗ tay. Nhưng đến lúc đưa vào workflow thật — query database, gọi API, kiểm tra lỗi, retry, rồi cập nhật hệ thống — agent bắt đầu giống bartender mới vào ca tối: pha ly đầu đẹp, nhưng quên dọn quầy, nhầm order thứ ba, và cuối ca thì không ai biết tiền tip biến đi đâu.

Điểm mình muốn bạn đổi cách nghĩ hôm nay: đừng đánh giá agent bằng một câu trả lời đơn lẻ nữa; hãy đánh giá nó bằng cả chuỗi hành động có hậu quả.

Đó là lý do multi-turn reinforcement learning đáng được nhìn như một bài toán triển khai hệ thống, không phải một keyword mới để dán vào roadmap.

Sơ đồ minh họa cho bài Train agent theo ca, không theo câu

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: dạy agent sống sót qua cả workflow

Trong nhiều team, lộ trình quen thuộc khi agent làm sai là: chỉnh prompt, thêm RAG, thêm rule, rồi fine-tune nếu vẫn đau. Các món này vẫn có chỗ đứng.

Nhưng enterprise agent thường không chỉ trả lời. Nó phải ra quyết định tuần tự: bước này có nên gọi tool không, kết quả kia có đáng tin không, lỗi giữa chừng có nên retry hay dừng, dữ liệu thiếu thì hỏi lại hay suy luận tiếp.

Multi-turn RL, reinforcement learning nhiều lượt, là cách train qua cả chuỗi tương tác. Reward không chỉ chấm “câu trả lời cuối có hay không”, mà chấm cả quá trình: agent có kiểm tra dữ liệu trước khi hành động không, có phục hồi khi tool fail không, có tránh gây lỗi dây chuyền không.

Ví dụ cụ thể: agent xử lý invoice.

Nếu chỉ chấm output cuối, model có thể trả về JSON nhìn sạch sẽ. Nhưng trong workflow thật, nó cần phân biệt bill-to với ship-to, biết subtotal khác total after tax, và trả null khi field không có. Một lỗi nhỏ ở đầu có thể làm ledger sai ở cuối. Train theo từng câu giống như chỉ chấm ly cà phê lúc đưa ra bàn; train theo nhiều lượt là chấm luôn việc xay, chiết xuất, ghi order và xử lý khi máy pha nghẹt.

Checklist quyết định: bạn có thật sự cần multi-turn RL chưa?

Trước khi dựng hạ tầng kiểu Amazon SageMaker HyperPod hay tự ráp pipeline tương tự, mình sẽ hỏi 5 câu này:

| Câu hỏi | Nếu câu trả lời là “có” | Nếu câu trả lời là “không” |
|---|---|---|
| Agent có gọi nhiều tool trong một task không? | Multi-turn RL bắt đầu đáng xem xét | Prompt + eval đơn lượt có thể đủ |
| Lỗi ở bước đầu có gây hỏng bước sau không? | Cần reward theo chuỗi | Chấm output cuối vẫn ổn |
| Có môi trường giả lập để agent thử-sai không? | Có đất cho RL | Chưa nên vội |
| Reward có đo được bằng rule, test, hoặc verifier không? | Có thể tự động hóa training | Dễ thành chấm cảm tính |
| Team có đủ năng lực vận hành compute, logs, failure analysis không? | Có thể build custom stack | Nên dùng managed service hoặc lùi lại |

Nói thẳng ra thì: multi-turn RL chỉ đáng tiền khi workflow của bạn có trạng thái, hậu quả, và khả năng chấm điểm theo chuỗi.

Nếu agent của bạn chủ yếu viết email, tóm tắt ticket, hoặc sinh mô tả sản phẩm, đừng cố dựng sân tập RL phức tạp. Nhưng nếu agent đang thao tác với finance, compliance, coding workflow, support escalation, research pipeline, hoặc hệ thống cần tool orchestration — điều phối nhiều công cụ — thì câu chuyện khác hẳn.

Bóc hệ thống theo lớp: giữ lớp nào, bỏ lớp nào?

Nguồn AWS mô tả một pipeline multi-turn RL cho Amazon Nova trên SageMaker HyperPod, với event-driven pipeline khởi động training khi upload data lên S3. Task minh họa là Wordle, nhưng phần đáng học không nằm ở trò chơi. Nó nằm ở cách hệ thống được tách lớp.

Mình sẽ bóc thành 4 lớp để bạn dễ quyết định.

1. Lớp môi trường agent

Đây là nơi agent hành động: gọi tool, nhận observation, đưa ra bước tiếp theo. Với Wordle là đoán chữ. Với team bạn có thể là xử lý invoice, debug performance, hoặc truy vấn dữ liệu khách hàng.

Điểm cần giữ: môi trường phải tái lập được. Cùng input, cùng seed hoặc cùng fixture, bạn phải chạy lại được để phân tích vì sao agent fail.

Nếu không tái lập được, bạn đang train trong khói sương. Hôm nay agent đúng, mai sai, không ai biết do model, data, tool hay API ngoài đổi hành vi.

2. Lớp orchestration

Orchestration là phần điều phối bước nào chạy trước, tool nào được gọi, retry ra sao, timeout thế nào. Đây là nơi nhiều demo chết khi lên production.

Với multi-turn RL, orchestration không chỉ để chạy workflow. Nó còn phải ghi lại trajectory — chuỗi hành động, observation, reward — để training dùng được.

Ví dụ cụ thể: với performance audit, thay vì đưa cho coding agent câu “làm site nhanh hơn”, bạn lưu finding có cấu trúc: metric nào chậm, resource nào liên quan, file nào nên xem trước, tiêu chí verify là gì. Đây là một dạng trajectory mini: từ phát hiện → prompt sửa → patch → kiểm chứng.

3. Lớp reward routing

Reward routing là cách đưa tín hiệu chấm điểm về đúng hành động hoặc đúng đoạn trong chuỗi. Đây là phần nhiều team đánh giá thấp.

Nếu invoice agent trả sai balance_due, reward nên phạt lỗi field đó. Nếu coding agent sửa LCP nhưng phá layout, reward không thể chỉ nhìn metric performance. Nếu research agent đề xuất phân tử mới, điểm không thể chỉ là potency dự đoán; còn drug-likeness, novelty, synthesizability và các gate khác.

Bản chất thật sự: reward là menu chấm điểm của quầy pha. Nếu menu chỉ ghi “ngon hoặc dở”, bartender sẽ học rất chậm. Nếu menu tách ra vị, nhiệt độ, đúng order, thời gian phục vụ, bạn mới biết cần chỉnh đoạn nào.

4. Lớp compute và job lifecycle

SageMaker HyperPod phù hợp khi bạn cần kiểm soát training stack: instance configuration, custom environment, orchestration riêng. AWS cũng có hướng managed/serverless cho multi-turn RL trong SageMaker training jobs, nhưng khi bạn cần toàn quyền thì hạ tầng kiểu HyperPod mới có ý nghĩa.

Tradeoff nằm ở đây: managed service giảm gánh vận hành; custom stack tăng quyền kiểm soát nhưng kéo theo logging, quota, cost, retry, checkpoint, versioning, và cleanup.

Với team Việt Nam quy mô nhỏ, mình sẽ không bắt đầu bằng cụm GPU hoành tráng. Mình sẽ bắt đầu bằng một môi trường giả lập nhỏ, reward rõ, eval chạy được trong CI, rồi mới tính chuyện scale.

Kế hoạch 1 buổi: dựng bản nháp trước khi đốt compute

Bạn không cần triển khai full RL infrastructure ngay. Trong một buổi chiều, hãy dựng “bản nháp quyết định” để biết có nên đi tiếp không.

Bước 1: Chọn một workflow có hậu quả rõ

Đừng chọn task chung chung như “trợ lý nội bộ”. Chọn một ca cụ thể:

Viết task dưới dạng:

workflow: invoice_extraction
success: ledger_fields_valid_and_balance_consistent
failure_modes:
  - confuse_bill_to_and_ship_to
  - use_total_as_subtotal
  - mark_partial_paid_as_paid
  - hallucinate_missing_po_number

Bước 2: Tách state, action, observation, reward

Đây là bộ xương của multi-turn RL.

state:
  - current_document_page
  - extracted_fields_so_far
  - validation_errors
action:
  - inspect_region
  - extract_field
  - call_validator
  - ask_for_clarification
  - finalize_json
observation:
  - rendered_pdf_snippet
  - validator_result
  - schema_constraints
reward:
  - field_accuracy
  - schema_validity
  - no_fake_values
  - ledger_consistency

Nếu bạn không viết được 4 phần này, khoan nói đến RL. Bạn chưa có môi trường train; bạn mới có một ước muốn.

Bước 3: Làm verifier trước, model sau

Verifier là bộ kiểm tra tự động: schema validation, unit test, rule check, replay log, hoặc evaluator chuyên biệt. Với invoice, verifier kiểm tra tổng tiền. Với coding performance, verifier chạy audit lại. Với RAG đa phương thức, verifier kiểm tra câu trả lời có bám đúng block nguồn không.

Đây là phần ít hào nhoáng nhưng quyết định chất lượng. Không có verifier, reward sẽ mù.

Bước 4: Ghi log trajectory ngay từ đầu

Mỗi run nên lưu:

{
  "task_id": "invoice_042",
  "turns": [
    {"action": "inspect_region", "observation": "header_block"},
    {"action": "extract_field", "field": "vendor_name"},
    {"action": "call_validator", "result": "missing_balance_due"}
  ],
  "final_output": "...",
  "reward_breakdown": {
    "schema_validity": true,
    "ledger_consistency": false,
    "hallucinated_fields": 1
  }
}

Đừng đợi tới lúc train mới nghĩ đến log. Log là nguyên liệu rang xay; hạt lỗi mà lẫn lộn thì pha kiểu gì cũng đắng.

Những bẫy dễ làm team tốn tiền

Bẫy đầu tiên: dùng task đồ chơi rồi tưởng đã chứng minh production. Wordle hay synthetic PDF rất tốt để kiểm tra pipeline, nhưng không thay thế được dữ liệu biên, lỗi OCR, API chập chờn, permission thiếu, hoặc user nhập bậy.

Bẫy thứ hai: reward quá rộng. “Task success” là một điểm cuối, không phải bản đồ học tập. Với workflow nhiều bước, bạn cần reward breakdown để biết agent sai ở nhận thức tài liệu, gọi tool, kiểm tra dữ liệu hay quyết định dừng.

Bẫy thứ ba: scale hạ tầng trước khi scale hiểu biết. HyperPod, cluster, distributed training nghe hấp dẫn với builder, nhưng nếu state/action/reward chưa rõ, bạn chỉ đang chạy nhanh một thí nghiệm mơ hồ.

Bẫy thứ tư: nhầm multi-turn RL với thay thế RAG hoặc SFT. Không phải. RAG giúp có thông tin đúng; SFT giúp học format và style; multi-turn RL giúp học quyết định qua chuỗi. Ba món này bổ sung nhau, không phải xếp hàng loại nhau.

Nếu là mình, mình sẽ triển khai theo ngưỡng

Mình sẽ dùng framework 3 ngưỡng:

Ngưỡng 1 — Prompt + structured context: áp dụng khi task một lượt, ít tool, hậu quả thấp. Ví dụ tạo prompt sửa performance từ một finding đã có cấu trúc.

Ngưỡng 2 — Workflow eval + verifier: áp dụng khi task nhiều bước nhưng chưa cần train. Ví dụ invoice extraction có schema, validator, ledger check. Lúc này bạn đo agent bằng run log, không chỉ đọc output.

Ngưỡng 3 — Multi-turn RL infrastructure: chỉ bước vào khi bạn đã có môi trường tái lập, reward rõ, trajectory đủ sạch, và lỗi hiện tại đến từ quyết định tuần tự chứ không chỉ thiếu context.

Sau bài này, thứ bạn nên nghĩ khác là: triển khai agent không bắt đầu bằng chọn model mạnh nhất, mà bắt đầu bằng thiết kế sân tập và bảng chấm điểm cho cả ca làm việc.

Còn model? Model chỉ là người đứng quầy. Quầy rối, menu mơ hồ, máy pha lúc nóng lúc lạnh thì barista giỏi mấy cũng có ngày làm đổ ly.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo