Một prompt (chỉ dẫn đầu vào) dài dòng không chỉ tốn tiền — nó còn làm agent chậm hơn, dễ lạc hướng hơn, và khó bảo trì hơn khi team cần sửa đổi. Trong bài này, chúng ta sẽ bóc tách vì sao việc tối ưu token nên bắt đầu từ chính prompt (không phải từ model hay hạ tầng), nhận diện các "khối u" phổ biến khiến prompt phình to, và học một quy trình lặp (iterative) để nén một prompt cồng kềnh thành bản gọn mà không làm giảm chất lượng output. Nội dung áp dụng cho mọi vai trò tham gia vào việc viết và duyệt prompt — từ dev, QA, đến product manager review system prompt của một feature AI.

Vì Sao Tối Ưu Token Phải Bắt Đầu Từ Prompt

Khi nói về "tối ưu token" (token optimization), nhiều người nghĩ ngay đến việc chọn model rẻ hơn hoặc bật caching. Nhưng điểm khởi đầu rẻ nhất và hiệu quả nhất luôn là prompt, vì hai lý do: prompt là phần bạn kiểm soát 100%, và nó là chi phí lặp lại trên mọi request, không phải chi phí một lần.

Cần phân biệt rõ hai loại token trong một lượt gọi LLM (large language model — mô hình ngôn ngữ lớn):

• Input token: toàn bộ những gì bạn gửi lên — system prompt, lịch sử hội thoại, tài liệu ngữ cảnh (context), tool schema (định nghĩa công cụ), câu hỏi của user. Đây là phần bạn chủ động thiết kế được.
• Output token: phần model sinh ra để trả lời. Bạn ảnh hưởng được (qua chỉ dẫn về độ dài, format) nhưng không kiểm soát tuyệt đối.

Điều quan trọng: input token thường rẻ hơn output token trên mỗi đơn vị (ví dụ nhiều nhà cung cấp định giá input khoảng 3 USD/triệu token, output khoảng 15 USD/triệu token), nhưng input token lại nhiều hơn về số lượng tuyệt đối trong hầu hết hệ thống agent thực tế, vì system prompt, tool schema và context bị gửi lại từ đầu ở mỗi turn (lượt hội thoại) nếu không có cơ chế cache.

Hãy làm một bài toán cụ thể để thấy tác động thực. Giả sử:

• System prompt của agent hỗ trợ khách hàng dài 1.800 token (khoảng 1.350 từ tiếng Anh).
• Agent xử lý 40.000 request/ngày.
• Đơn giá input: 3 USD/1 triệu token.

Chi phí riêng cho system prompt mỗi ngày:

1,800 tokens × 40,000 requests = 72,000,000 tokens/day
72,000,000 / 1,000,000 × $3 = $216/day

Chỉ riêng phần "lời chào đầu" lặp đi lặp lại này đã tốn khoảng 6.480 USD/tháng — chưa tính context, tool schema, hay output. Nếu bạn nén system prompt đó xuống 900 token (giảm 50%) mà vẫn giữ đúng hành vi mong muốn, bạn tiết kiệm ngay 108 USD/ngày, tương đương khoảng 3.240 USD/tháng, chỉ bằng một lần chỉnh sửa văn bản — không cần đổi model, không cần đầu tư hạ tầng cache.

Ngoài chi phí tiền, còn hai áp lực khác mà kỹ sư thường bỏ qua:

• Latency (độ trễ): model phải xử lý (tokenize, encode, attend) toàn bộ input trước khi sinh token đầu tiên. Prompt dài trực tiếp kéo dài "time to first token".
• Context window (cửa sổ ngữ cảnh): mọi model có giới hạn tổng token cho một request. Một system prompt phình to chiếm chỗ của lịch sử hội thoại hữu ích hoặc tài liệu cần retrieve, làm agent "quên" sớm hơn trong các task dài.

Về công cụ đo đếm: đừng đoán số token bằng mắt. Dùng tokenizer (bộ tách token) phù hợp với model bạn dùng — ví dụ thư viện tiktoken cho các model kiểu OpenAI, hoặc endpoint đếm token chính thức của nhà cung cấp cho các model Claude. Một đoạn script nhỏ để đo trước/sau khi sửa prompt:

import tiktoken

def count_tokens(text: str, model: str = "gpt-4o") -> int:
    encoding = tiktoken.encoding_for_model(model)
    return len(encoding.encode(text))

original_prompt = open("prompt_v1.txt").read()
compressed_prompt = open("prompt_v2.txt").read()

print(f"Original: {count_tokens(original_prompt)} tokens")
print(f"Compressed: {count_tokens(compressed_prompt)} tokens")

Đo trước, đo sau, ghi lại số — đó là cách duy nhất để biến "tối ưu prompt" từ cảm tính thành một chỉ số kỹ thuật có thể theo dõi trong CI hoặc dashboard chi phí.

Mẹo: Thêm một bước "token budget check" vào pipeline review prompt — mỗi khi PR sửa system prompt, chạy script đếm token và comment thẳng vào PR số token cũ/mới/chênh lệch, giống như cách team vẫn check bundle size cho frontend.

Cấu Trúc Của Một Prompt Phình To

Prompt bị phình to (bloated) không phải vì ai đó cố ý viết dài — mà vì nó bị "vá" dần theo thời gian: mỗi lần gặp một edge case lạ, ai đó thêm một câu vào system prompt để "chặn" nó, và không ai quay lại dọn dẹp. Sau vài tháng, prompt trở thành một lớp trầm tích của các chỉ dẫn không còn ai nhớ rõ vì sao nó tồn tại.

Dưới đây là các nguyên nhân phổ biến nhất, xếp theo mức độ hay gặp trong thực tế:

1. Chỉ dẫn lặp (redundant instructions) — nói cùng một ý ba, bốn cách khác nhau vì sợ model "không hiểu". Ví dụ: "Trả lời ngắn gọn. Đừng dài dòng. Giữ câu trả lời súc tích. Không lan man." — bốn câu, một ý.
2. Giải thích quá mức (over-explaining) — giải thích tại sao cần một quy tắc thay vì chỉ nêu quy tắc. Model không cần biết "vì khách hàng thường phàn nàn về câu trả lời dài nên hãy trả lời ngắn" — chỉ cần "trả lời tối đa 3 câu."
3. Lặp ngữ cảnh giữa các turn (repeated context) — gửi lại toàn bộ hướng dẫn định dạng, toàn bộ profile công ty, ở mọi user turn trong khi nó đã có sẵn trong system prompt.
4. Định dạng dài dòng (verbose formatting) — dùng markdown lồng nhiều cấp, tiêu đề trang trọng, khung phân tách kiểu "=== SECTION 4: TONE GUIDELINES ===" cho một hướng dẫn chỉ cần một dòng.
5. Lịch sự/filler không cần thiết — các cụm như "Please kindly make sure that you always try your best to..." không thêm giá trị hành vi, chỉ thêm token.
6. Đặc tả quá chi tiết cho edge case hiếm — dành 200 token mô tả cách xử lý một tình huống xảy ra 0,1% số request, trong khi tình huống đó có thể xử lý bằng một câu tổng quát hoặc bằng logic code thay vì prompt.

Ví dụ một đoạn system prompt thực tế bị phình (rút gọn để minh họa, khoảng 95 token cho một đoạn nhỏ):

Please always remember that you are a customer support assistant, and it is
very important that you always try to be polite and helpful to the customer
at all times. You should always make sure that your responses are not too
long, and please try your best to keep things concise and to the point,
avoiding unnecessary verbosity wherever possible, because we have received
feedback that customers do not like long responses.

Cùng ý đó, viết lại còn khoảng 20 token:

Tone: polite, helpful. Keep replies under 3 sentences.

Giảm gần 80% token cho đúng đoạn này, không mất bất kỳ hành vi nào model cần tuân theo. Nhân con số này với hàng chục đoạn tương tự trong một system prompt thật, và bạn có ngay một prompt gấp 3-5 lần kích thước cần thiết.

Mẹo: Khi review một system prompt cũ, tô màu (highlight) từng câu và tự hỏi "nếu xóa câu này, model sẽ làm gì khác đi?" — nếu không trả lời được cụ thể, đó là ứng viên để cắt.

Kỹ Thuật Cấu Trúc Để Nén Token

Sau khi nhận diện được "khối u", bước tiếp theo là áp dụng các kỹ thuật cấu trúc cụ thể để nén prompt. Đây không phải là việc cắt xén tùy tiện — mỗi kỹ thuật dưới đây nhằm giữ nguyên hoặc tăng độ rõ ràng cho model, đồng thời giảm token.

1. Chuyển từ văn xuôi (prose) sang danh sách (bullet list)

Văn xuôi cần các từ nối (liên từ, mạo từ, chuyển ý) mà danh sách không cần. So sánh:

Trước (52 token):

When you receive a request from the user, first you need to check if they
are logged in, and then after that you should verify their subscription
tier, and finally you can proceed to answer their question based on what
tier they have.

Sau (24 token):

Steps:
1. Check login status.
2. Verify subscription tier.
3. Answer based on tier.

Giảm ~54% token, đồng thời model thường tuân theo instruction dạng danh sách có số thứ tự chính xác hơn văn xuôi, vì ranh giới giữa các bước rõ ràng hơn.

2. Loại bỏ chỉ dẫn lặp

Gộp các câu nói cùng một ý thành một câu duy nhất, đặt ở vị trí dễ thấy nhất (thường là đầu hoặc cuối system prompt — model có xu hướng chú ý nhiều hơn ở hai đầu, hiệu ứng này thường được gọi là "lost in the middle").

3. Dùng định dạng có cấu trúc (structured format) cho dữ liệu lặp

Nếu prompt liệt kê nhiều mục cùng loại (ví dụ danh sách sản phẩm, danh sách quy tắc theo cặp điều kiện → hành động), bảng hoặc JSON compact thường tiết kiệm hơn văn xuôi lặp cấu trúc câu:

Trước (dạng văn xuôi, ~48 token):

If the order status is "pending", tell the customer it takes 2-3 days.
If the order status is "shipped", tell the customer to check the tracking link.
If the order status is "delivered", ask if they need a return.

Sau (dạng bảng, ~28 token):

| status    | response                     |
|-----------|-------------------------------|
| pending   | ETA 2-3 days                 |
| shipped   | Point to tracking link       |
| delivered | Ask if return needed         |

4. Viết tắt phần "boilerplate" (khuôn mẫu lặp lại)

Với các cụm chuẩn hóa xuất hiện nhiều lần (tên công ty, disclaimer, format ngày giờ), định nghĩa một lần bằng ký hiệu ngắn và tham chiếu lại, thay vì viết đầy đủ mỗi lần — đặc biệt hữu ích khi prompt có nhiều nhánh điều kiện lặp lại cùng một cụm dài.

5. Tránh lặp ngữ cảnh giữa system và user turn

Nếu system prompt đã quy định "luôn trả lời bằng tiếng Việt, định dạng ngày kiểu DD/MM/YYYY", đừng lặp lại điều này trong mỗi user message do code chèn vào — đó là lỗi kiến trúc rất thường gặp khi nhiều dev cùng chỉnh sửa một pipeline prompt mà không có "single source of truth".

Bảng tổng hợp before/after cho một prompt hoàn chỉnh (giả định):

Tổng cộng giảm ~51% token so với bản gốc chỉ bằng bốn kỹ thuật thuần cấu trúc, chưa cần đụng đến nội dung nghiệp vụ.

Mẹo: Luôn giữ một bản "before" trong version control (ví dụ commit riêng trước khi nén) để có thể A/B test output của v1 và v4 trên cùng bộ test case — nén token mà không đo output là đánh cược mù.

Chỉ Dẫn Vai Trò: Giữ Gì, Cắt Gì

Phần "role instruction" (mô tả vai trò/persona cho agent, ví dụ "Bạn là một trợ lý hỗ trợ khách hàng chuyên nghiệp...") là nơi dễ phình to nhất vì nó mang tính mô tả, cảm tính, và dễ bị viết theo cảm hứng thay vì theo mục tiêu hành vi cụ thể.

Nguyên tắc phân loại: một câu trong role instruction chỉ nên tồn tại nếu nó thay đổi hành vi quan sát được của model. Nếu một câu chỉ mô tả "không khí" hoặc "cảm giác" mà không map được sang một hành vi cụ thể, nó là ứng viên để cắt hoặc rút gọn.

Load-bearing (chịu tải — nên giữ)

• Ranh giới phạm vi công việc: "Chỉ trả lời câu hỏi liên quan đến sản phẩm X. Với câu hỏi ngoài phạm vi, trả lời: 'Tôi không hỗ trợ vấn đề này, vui lòng liên hệ...'"
• Định dạng output bắt buộc: "Luôn trả về JSON theo schema: {intent, confidence, reply}."
• Ràng buộc cứng về hành vi: "Không bao giờ tiết lộ số thẻ tín dụng đầy đủ, chỉ hiển thị 4 số cuối."
• Độ dài/tone cụ thể có thể đo được: "Tối đa 3 câu. Không dùng emoji."

Decorative (trang trí — nên cắt hoặc rút gọn mạnh)

• Mô tả "tính cách" bay bổng: "Bạn là một trợ lý thân thiện, ấm áp, luôn lắng nghe bằng cả trái tim và mong muốn mang lại trải nghiệm tuyệt vời nhất cho khách hàng." → có thể rút thành "Tone: friendly, warm." mà hành vi model gần như không đổi, vì các tính từ hoa mỹ dư (ấm áp, cả trái tim, tuyệt vời nhất) không ánh xạ được sang một chỉ dẫn có thể kiểm chứng.
• Backstory không ảnh hưởng đến trả lời: "Bạn từng là một chuyên gia CSKH 10 năm kinh nghiệm làm việc tại các công ty công nghệ hàng đầu..." — trừ khi bạn có test case chứng minh backstory này thay đổi output, nó chỉ tốn token.
• Lặp lại tên brand nhiều lần thay vì đặt biến: nếu prompt gọi tên công ty 15 lần, xem xét việc điều đó có thực sự cần hay chỉ là quán tính viết.

Ví dụ rút gọn một role instruction thực tế:

Trước (~110 token):

You are Aria, a warm and empathetic virtual assistant working for Brightline
Bank. You genuinely care about every customer's financial wellbeing and you
always try to go above and beyond to make sure they feel heard, respected,
and valued. You should always maintain a professional yet friendly tone,
and you should never make the customer feel rushed or unimportant, no
matter how busy you are.

Sau (~28 token):

You are Aria, Brightline Bank's assistant.
Tone: professional, friendly, patient.
Never rush the customer.

Giảm ~75% token. Điểm mấu chốt: "Never rush the customer" được giữ lại vì nó map sang một hành vi kiểm chứng được (không cắt ngang, không thúc ép chốt hội thoại sớm), còn "genuinely care", "go above and beyond", "feel heard, respected, and valued" bị cắt vì chúng là mô tả cảm xúc không đo lường được bằng test case.

Cách kiểm tra nhanh khi không chắc một câu có nên giữ: viết ra một test case cụ thể mà câu đó phải "pass". Nếu bạn không nghĩ ra được test case nào, gần như chắc chắn đó là câu trang trí.

Mẹo: Với mỗi câu trong role instruction, thử tự hỏi "Nếu xóa câu này, tôi sẽ viết test case nào để phát hiện sự khác biệt?" — nếu không viết được test case, xóa ngay, đừng để "cho chắc".

Context Injection: Yếu Tố Nhân Token

Nếu role instruction là chi phí cố định (fixed cost) mỗi request, thì context injection — việc chèn tài liệu retrieve được, lịch sử hội thoại, hoặc tool schema (định nghĩa công cụ) vào prompt — là chi phí biến động và nhân theo turn, và đây thường là nguồn tiêu token lớn nhất trong các hệ thống agent thực tế, không phải system prompt.

Ba nguồn nhân token phổ biến nhất:

1. Tài liệu retrieve (RAG — retrieval-augmented generation, tức tăng cường sinh câu trả lời bằng truy xuất)

Mỗi lần agent truy vấn knowledge base, toàn bộ đoạn văn bản trả về bị nhồi vào prompt. Nếu mỗi lần retrieve trả về 5 đoạn, mỗi đoạn 400 token, đó đã là 2.000 token — gấp cả system prompt trong ví dụ trên — cho một câu hỏi duy nhất.

2. Lịch sử hội thoại (conversation history)

Nếu không cắt bớt, mỗi turn mới phải gửi lại toàn bộ các turn trước. Với một hội thoại 20 turn, turn cuối phải mang theo toàn bộ 19 turn trước — chi phí tăng gần như tuyến tính theo độ dài hội thoại, và với agent nhiều bước (multi-step), có thể tăng theo cấp số nhân nếu mỗi bước lại nhồi thêm log, kết quả tool call, v.v.

3. Tool schema (định nghĩa công cụ cho agent)

Mỗi tool mà agent có quyền gọi thường được định nghĩa bằng một schema JSON đầy đủ tên, mô tả, tham số. Một agent có 15 tool, mỗi schema trung bình 150 token, đã tốn 2.250 token — gửi lại ở mọi turn, dù turn đó chỉ dùng 1 tool trong số 15.

Bài toán minh họa: một agent hỗ trợ kỹ thuật có:
- System prompt: 900 token
- Tool schema (12 tools): 1.600 token
- Lịch sử hội thoại (turn thứ 8): 3.200 token
- Tài liệu retrieve cho câu hỏi hiện tại: 1.800 token

Tổng input cho một turn: 7.500 token. Nếu agent xử lý 10.000 hội thoại/ngày, trung bình 6 turn/hội thoại có retrieve, chi phí input riêng phần context injection (bỏ qua system prompt) có thể lên đến hàng chục triệu token/ngày — đây là lý do vì sao tối ưu context injection thường mang lại tiết kiệm lớn hơn nhiều so với việc chỉnh sửa system prompt.

Các kỹ thuật giảm tải:

• Context pruning (cắt gọt ngữ cảnh): chỉ giữ N turn gần nhất hoặc các turn có liên quan trực tiếp đến câu hỏi hiện tại, loại bỏ các turn đã "đóng" (ví dụ user đã xác nhận đã giải quyết).
• Summarization (tóm tắt): định kỳ (ví dụ sau mỗi 6-8 turn) thay toàn bộ lịch sử cũ bằng một bản tóm tắt 100-200 token do model tự sinh, giữ lại các fact quan trọng (mã đơn hàng, tên khách, vấn đề đang xử lý).
• Selective retrieval (retrieve có chọn lọc): giảm số đoạn retrieve (top-k) và tăng độ chính xác truy vấn (query rewriting, re-ranking) thay vì "retrieve nhiều cho chắc". Giảm từ top-5 xuống top-3 với re-ranker tốt thường không giảm chất lượng câu trả lời nhưng giảm ngay 40% token context.
• Lazy tool schema loading: chỉ gửi schema của các tool có khả năng liên quan đến turn hiện tại (dựa trên intent classification nhẹ), thay vì luôn gửi toàn bộ danh sách tool.
• Prompt caching: với các phần context lặp lại y hệt giữa các request (ví dụ toàn bộ tool schema, phần đầu system prompt), một số nhà cung cấp LLM hỗ trợ cache các đoạn này ở phía server, giảm chi phí tính input token cho phần đã cache tới 90% ở các lượt gọi sau — đây không hẳn là "giảm token" theo nghĩa đếm, nhưng giảm chi phí thực tế đáng kể và nên kết hợp cùng các kỹ thuật nén ở trên.

Ví dụ code minh họa cắt lịch sử hội thoại đơn giản trước khi gửi request:

MAX_TURNS_KEPT = 6

def build_context(history: list[dict], summary: str | None) -> list[dict]:
    """Keep only the most recent turns; fold older ones into a summary."""
    if len(history) <= MAX_TURNS_KEPT:
        return history

    recent = history[-MAX_TURNS_KEPT:]
    if summary:
        summary_turn = {"role": "system", "content": f"Earlier context: {summary}"}
        return [summary_turn] + recent
    return recent

Mẹo: Log số token của từng phần (system, tool schema, history, retrieved docs) riêng biệt cho mỗi request thật, không chỉ tổng — phần lớn team chỉ thấy "prompt quá dài" chứ không biết phần nào đang chiếm 60% token, và context injection gần như luôn là kẻ giấu mặt.

Quy Trình Nén Prompt Lặp: Cách Làm Thực Tế

Nén một prompt cũ mà không kiểm chứng là hành động rủi ro — bạn có thể tiết kiệm token nhưng làm gãy một hành vi mà không ai để ý cho đến khi khách hàng phàn nàn. Vì vậy nén prompt cần một quy trình lặp (iterative), có đo lường ở mỗi bước, giống như refactor code có test bao phủ.

Quy trình 6 bước dưới đây áp dụng được cho mọi persona — dev tự làm một mình, hoặc dev + QA + PM cùng review qua từng bước:

Bước 1: Lập baseline (đường mốc)

Trước khi sửa gì, thu thập:
- Số token hiện tại của prompt (dùng script đếm token ở phần 1).
- Một bộ test case đại diện (ít nhất 15-20 case, bao gồm cả case phổ biến và case biên/edge case quan trọng).
- Output hiện tại cho từng test case, lưu lại làm "golden output" (kết quả chuẩn dùng để đối chiếu) hoặc ít nhất làm điểm so sánh chất lượng.

baseline = {
    "token_count": count_tokens(prompt_v1),
    "test_cases": load_test_cases("test_cases.jsonl"),
    "outputs": {},
}
for case in baseline["test_cases"]:
    baseline["outputs"][case["id"]] = call_model(prompt_v1, case["input"])

Bước 2: Phân loại nội dung prompt

Dùng khung phân loại đã học ở phần trước (load-bearing vs decorative, chỉ dẫn vs giải thích, dữ liệu lặp vs duy nhất) để đánh dấu từng đoạn trong prompt: giữ, gộp, cắt, hoặc chuyển định dạng.

Bước 3: Cắt một lớp (không cắt hết một lần)

Đây là điểm khác biệt quan trọng nhất so với cách nhiều người làm sai: không viết lại toàn bộ prompt trong một lần rồi hy vọng nó vẫn đúng. Cắt theo từng lớp nhỏ — ví dụ lớp 1 chỉ gộp chỉ dẫn lặp, lớp 2 chỉ chuyển văn xuôi sang bullet, lớp 3 chỉ rút gọn role instruction — để nếu có regression (thoái hóa chất lượng), bạn biết chính xác lớp nào gây ra.

Bước 4: Test lại trên cùng bộ test case

Chạy đúng bộ test case ở bước 1 với prompt đã cắt, so sánh output:

def compare_outputs(baseline_outputs, new_outputs, test_cases):
    regressions = []
    for case in test_cases:
        old = baseline_outputs[case["id"]]
        new = new_outputs[case["id"]]
        if not semantically_equivalent(old, new, criteria=case.get("must_include")):
            regressions.append(case["id"])
    return regressions

Với các case có tiêu chí rõ ràng (phải chứa một field, một hành động cụ thể), dùng so sánh có quy tắc (rule-based). Với case mang tính chủ quan (tone, độ tự nhiên), dùng LLM-as-judge (dùng một LLM khác để tự động chấm chất lượng output) hoặc review thủ công bởi QA/PM — đây là bước mà sự tham gia của QA rất có giá trị, vì họ thường có bộ edge case tích lũy từ thực tế mà dev không nghĩ tới.

Bước 5: Đo và ghi lại

Với mỗi lớp cắt, ghi vào một bảng theo dõi:

Bảng này vừa là bằng chứng cho quyết định kỹ thuật, vừa là tài liệu hữu ích khi có ai hỏi "tại sao prompt lại được viết thế này" sáu tháng sau.

Bước 6: Lặp lại đến khi đạt điểm dừng

Điểm dừng hợp lý là khi: (a) không còn nội dung nào có thể phân loại rõ ràng là "decorative" hoặc "dư thừa", hoặc (b) mỗi lần cắt thêm bắt đầu gây regression liên tục dù đã sửa. Ở điểm đó, phần token còn lại là "chi phí cần thiết" để giữ đúng hành vi — đừng cắt tiếp chỉ để đạt một con số đẹp.

Áp dụng đúng quy trình này, một prompt 1.820 token có thể ổn định ở khoảng 950-1.000 token (giảm ~46-48%) mà không mất hành vi quan trọng nào — và với ví dụ chi phí ở phần 1 (40.000 request/ngày, 3 USD/triệu token input), riêng phần system prompt đã tiết kiệm khoảng 100 USD/ngày, tương đương 3.000 USD/tháng, chỉ từ một vòng làm việc có kỷ luật, không cần thay đổi model hay hạ tầng.

Mẹo: Lưu bộ test case và bảng theo dõi token vào cùng repo với prompt (ví dụ file test_cases.jsonl cạnh system_prompt.md), để lần nén tiếp theo — hoặc lần ai đó vô tình làm phình prompt trở lại — có ngay công cụ để kiểm chứng mà không phải xây lại từ đầu.