Thực hành: chỉnh top-p, top-k, penalty, max tokens và stop sequence theo từng tác vụ của khách

Trang tài liệu Messages API của Anthropic ghi rằng các model ra mắt sau Claude Opus 4.6 không còn cho đặt temperature. Hướng dẫn prompt của Google cho Gemini thì “khuyến nghị mạnh” giữ các tham số sampling ở giá trị mặc định với dòng Gemini 3.x. Núm vặn quen thuộc nhất của LLM đang bị khóa dần.

Dù núm sampling bị khóa, việc chỉnh tham số vẫn còn đó. Nó chỉ chuyển sang các núm khác. Max tokens, stop sequence và penalty vẫn quyết định output có dùng được trong hệ thống của khách hay không, và chúng phải chỉnh riêng cho từng loại tác vụ.

Nếu muốn làm FDE, bạn cần nắm chắc chuyện này. Khách không trả tiền để bạn chạy demo với cấu hình mặc định. Họ cần bot hỗ trợ không lặp tên khách hàng ba lần trong một câu, và pipeline trích xuất không bị cắt giữa chừng một object JSON.

Bạn sẽ dựng gì sau bài này?

Bạn sẽ dựng một file cấu hình theo tác vụ cho bốn loại việc: trích xuất dữ liệu có cấu trúc, chatbot hỗ trợ khách hàng, viết nội dung sáng tạo và tóm tắt.

Kèm theo là một đoạn code kiểm tra lý do output dừng. Để làm theo, bạn cần quyền gọi API của ít nhất một nhà cung cấp, Python cơ bản, và quan trọng nhất là 10 đến 20 input thật của khách để thử.

Các đoạn code dưới đây đã được rút gọn để minh họa. Tên tham số và dải giá trị khác nhau giữa các nhà cung cấp, nên hãy đối chiếu với tài liệu của model bạn đang dùng.

Bước 1: model này còn cho chỉnh những gì?

Trước khi vặn núm nào, hãy lập một bảng nhỏ ghi những tham số model đang dùng còn chấp nhận. Lý do đã nói ở trên: Claude đời mới bỏ temperature, còn Google khuyên giữ mặc định với Gemini 3.x. Một cấu hình bê từ dự án cũ sang có thể bị API từ chối, hoặc âm thầm làm output kém hơn.

Bảng này nên có thêm cột penalty và top_k, để bạn ghi rõ API đang dùng có nhận chúng hay không, thay vì đoán.

Kiểm tra: với mỗi tham số định dùng, bạn trả lời được “model này có nhận không, và nhà cung cấp có khuyên giữ mặc định không”. Lỗi hay gặp là copy cấu hình từ một blog viết cho model khác.

Bước 2: chọn temperature hoặc top-p, đừng chọn cả hai

Prompt Engineering Guide của DAIR.AI khuyên chỉ chỉnh temperature hoặc top-p chứ không chỉnh cả hai. Nếu vặn cả hai cùng lúc rồi output tệ đi, bạn không biết núm nào gây ra. Thêm một điều cần hiểu đúng về top-p: theo Vellum, đây là tổng xác suất cộng dồn chứ không phải phần trăm số token.

Thử hình dung token tiếp theo có ba ứng viên với xác suất 0,6, 0,3 và 0,1. Với top-p 0,9, model chỉ chọn trong hai token đầu vì 0,6 cộng 0,3 đã đủ 0,9. Nếu hiểu nhầm là giữ 90% số token thì sẽ ra ba token. Vellum cũng lưu ý top-p rất thấp cho output gò bó và đơn giản.

Top-k thì dễ hình dung hơn. Đó là một số nguyên giới hạn số token có xác suất cao nhất được xét. Top-k bằng 1 là chọn tham lam (greedy) nên kết quả mang tính tất định.

Tài liệu Gemini cũng nói temperature 0 là tất định: luôn chọn phản hồi có xác suất cao nhất. Với tác vụ trích xuất, bạn cần đúng tính chất này. Ngược lại, DAIR.AI gợi ý tăng temperature cho thơ ca hay các tác vụ sáng tạo khác.

Bước 3: đặt max tokens từ số đo, không phải từ cảm giác

Tài liệu Anthropic ghi rõ max_tokens chỉ là số token tối đa được sinh. Model có thể dừng sớm hơn. Nghĩa là con số này là mức trần để chặn chi phí và output chạy lan man, không phải chiều dài bạn yêu cầu.

Để ước lượng nhanh, tài liệu Gemini cho biết một token vào khoảng bốn ký tự. Giả sử bản tóm tắt khách muốn dài khoảng 2.000 ký tự, tức chừng 500 token. Đó mới là điểm xuất phát: quy tắc bốn ký tự chỉ là ước lượng, nên với văn bản thật của khách bạn vẫn cần đếm.

Anthropic cho dùng API đếm token miễn phí, nhưng có giới hạn số request mỗi phút theo hạng sử dụng, và kết quả chỉ là ước lượng. Tài liệu cũng cảnh báo tokenizer mới cho ra khoảng 30% token nhiều hơn.

Nếu 500 token đo được trên model cũ, sau khi đổi model cùng văn bản đó có thể thành khoảng 650 token. Vì vậy mỗi lần đổi model, hãy đếm lại.

Kiểm tra: lấy 10 output thật, đếm token, rồi đặt max tokens cao hơn output dài nhất một khoảng an toàn. Lỗi hay gặp là đặt max tokens sát mức trung bình, khiến output dài nhất bị cắt.

Bước 4: thêm stop sequence và đọc lý do output dừng

Stop sequence là một chuỗi mà khi model sinh tới thì dừng. DAIR.AI nhắc rằng cùng với giới hạn độ dài, nó giúp kiểm soát chi phí và định dạng. Với API của Anthropic, khi khớp stop sequence, response trả stop_reason là "stop_sequence" và trường stop_sequence chứa đúng chuỗi đã khớp.

Request rút gọn cho tác vụ trích xuất, trong đó prompt yêu cầu model kết thúc bằng ###:

{
  "model": "<model-ban-dang-dung>",
  "max_tokens": 600,
  "stop_sequences": ["###"],
  "messages": [{"role": "user", "content": "Trích xuất hóa đơn sau thành JSON, kết thúc bằng ###: ..."}]
}

Phần quan trọng nằm ở code đọc response:

# Rút gọn: response là dict đã parse từ API
if response["stop_reason"] == "stop_sequence":
    parse_json(response)          # model đã kết thúc đúng chỗ
else:
    log_for_review(response)      # dừng vì lý do khác: có thể bị cắt

Kiểm tra: chạy với một input cố ý thật dài và xác nhận nó rơi vào nhánh log_for_review. Lỗi hay gặp là chọn stop sequence có thể xuất hiện ngay trong nội dung, chẳng hạn một dấu xuống dòng, khiến output bị cắt sau dòng đầu tiên.

Bước 5: chọn frequency hoặc presence penalty

Hai loại penalty khác nhau ở cách tính. DAIR.AI giải thích rằng frequency penalty tăng theo số lần token đã xuất hiện, còn presence penalty là mức phạt cố định: token xuất hiện hai lần hay mười lần đều bị phạt như nhau. Theo Vellum, presence penalty phạt một từ ngay sau lần dùng đầu tiên. Lời khuyên lại giống bước 2: chỉ chỉnh một trong hai.

Vellum chỉ ra một tình huống rất quen ở site khách: chatbot hỗ trợ lặp đi lặp lại một số tên hoặc cụm từ. Đây là chỗ hợp với presence penalty.

Vellum cho biết dải của presence penalty là từ -2 đến 2, nhưng thường nên giữ trong khoảng -1 đến 1. Muốn bot bớt lặp, cách thận trọng là bắt đầu với một giá trị dương nhỏ, ví dụ 0,1 đến 0,5, rồi tăng dần nếu bot vẫn lặp.

Với frequency penalty, Vellum cho rằng nếu chỉ muốn giảm lặp một chút, các giá trị từ 0,1 đến 1 là hợp lý. Nếu bảng ở bước 1 cho thấy API bạn dùng không có tham số penalty, hãy bỏ qua bước này.

Bước 6: gom thành một file cấu hình theo tác vụ

# Cấu hình minh họa; tên tham số đổi theo nhà cung cấp
PROFILES = {
  "extraction": {"top_k": 1, "max_tokens": 600, "stop": ["###"]},
  "support_bot": {"presence_penalty": 0.3, "max_tokens": 400},
  "creative": {"temperature": 0.9, "max_tokens": 800},  # chỉ giữ temperature nếu model cho phép
  "summary": {"max_tokens": 500},  # thay bằng số đo từ 10 output thật
}

Tác vụ	Núm chính	Lý do
Trích xuất JSON	top-k 1 hoặc temperature 0, stop sequence	Cần output tất định và biết chắc đã kết thúc
Bot hỗ trợ	presence penalty dương nhỏ, ví dụ 0,1 đến 0,5 (nếu API có)	Tránh lặp tên và cụm từ
Viết sáng tạo	temperature hoặc top-p, không cả hai	Cần đa dạng nhưng vẫn dò được lỗi
Tóm tắt	max tokens từ số đo	Kiểm soát chi phí và độ dài

Các con số trong file chỉ là điểm bắt đầu để thử, không phải đáp án. Nếu model thuộc diện nhà cung cấp khuyên giữ mặc định, hãy xóa núm sampling khỏi cấu hình và chỉ giữ max tokens cùng stop sequence. Tương tự, xóa top_k hay penalty nếu API không hỗ trợ.

Kỹ năng này lộ ra ở đâu khi làm cho khách?

Thử hình dung khách phàn nàn bot “nói như cái máy”, báo cáo tóm tắt dài bất thường, hoặc hệ thống phía sau báo lỗi parse JSON. Lúc đó, FDE giỏi không đoán mò. Họ mở log, xem stop_reason, đếm token, rồi đổi đúng một núm mỗi lần.

Khi đọc mô tả công việc FDE, hãy để ý các cụm như “tối ưu chi phí inference” hay “độ ổn định output”. Trên CV, đừng ghi “thành thạo prompt engineering”. Hãy viết cụ thể bạn đã giảm tỷ lệ output bị cắt bằng stop sequence và log stop_reason, kèm con số trước và sau trên dự án thật của bạn.

Các núm sampling có thể còn bị khóa thêm qua mỗi thế hệ model. Max tokens, stop sequence và thói quen đo trước rồi mới chỉnh thì vẫn sẽ dùng được ở mọi dự án.