Bài 23: Task description — yêu cầu cụ thể

Sau bài này, bạn cần trả lời được:

• Task description nằm ở đâu trong anatomy của một prompt và đảm nhiệm vai trò gì.
• Vì sao task description khác question, và đặc tính nào làm nó "specific".
• Các kỹ thuật cụ thể: action verb, constraint, step-by-step, numbered list, imperative voice.
• Khi nào dùng negative constraint, khi nào positive — và lý do positive thường thắng.
• Quy trình iterate / A/B test một task description trên data thật.

Bài 22 đã xử lý Context — phần thông tin nền cho LLM. Bài 24 sẽ xử lý Output format. Task description chính là phần "yêu cầu" nằm giữa hai phần đó, và thường là phần quyết định nhất chất lượng output.

Anthropic và OpenAI cùng đề xuất một anatomy 4 phần cho prompt sản phẩm:

┌─────────────────────────────────────────────┐
│ 1. Context        (B22 đã xử lý)            │
│    — background, persona, tài liệu reference│
├─────────────────────────────────────────────┤
│ 2. Task           (B23 — bài này)           │
│    — chỉ rõ LLM cần LÀM GÌ                  │
├─────────────────────────────────────────────┤
│ 3. Output format  (B24)                     │
│    — JSON / Markdown / bullet / cấu trúc cố định │
├─────────────────────────────────────────────┤
│ 4. Examples       (B26 — few-shot)          │
│    — minh họa input → output                │
└─────────────────────────────────────────────┘

Bốn phần này có thể đứng trong cùng system message hoặc trải qua nhiều user turn. Thứ tự thường là context trước, task sau, format và examples đặt gần cuối để giữ vị trí ưu tiên trong context window (nhắc lại "lost in the middle" ở B7).

Trong các API tham chiếu (Anthropic messages.create, OpenAI responses.create), task description thường nằm phía cuối của system hoặc đầu user — ngay trước input cụ thể cần xử lý.

Question yêu cầu thông tin; task yêu cầu hành động kèm điều kiện.

Question : What is Python?
Task     : Explain Python to a 10-year-old in 3 short sentences.

Question để LLM tự diễn dịch độ chi tiết, độ dài, audience. Task ép sẵn các tham số đó. Trên cùng một model, task thường cho output ổn định hơn giữa các lần gọi vì variance nội tại bị thu hẹp.

Quy tắc thực tế: nếu bạn cần dùng output cho hệ thống (parse, lưu DB, hiển thị UI), viết task chứ không phải question.

Nguyên tắc xuyên suốt prompt engineering (Anthropic Prompt Engineering Guide, OpenAI Best Practices): càng specific, output càng ổn định và đúng ý.

Vague    : Help me with my code.
Specific : Review the Python function below for bugs. List each bug
           with line number and a suggested fix. Output as a Markdown
           table with columns: line, bug, suggested_fix.

"Specific" ở đây có ba lát:

• Hành động rõ (review, list, output).
• Phạm vi rõ (function below, từng bug).
• Hình thức rõ (Markdown table, 3 cột cố định).

Vague prompt buộc model "đoán" — output sẽ biến thiên giữa các lần gọi và giữa các model.

Mỗi task description nên bắt đầu bằng một động từ hành động rõ ràng. Một số verb dùng nhiều:

Translate    — đổi ngôn ngữ, giữ nghĩa.
Summarize    — rút gọn, giữ ý chính.
Classify     — gán nhãn trong tập hữu hạn.
Extract      — lấy thông tin theo schema.
Rewrite      — viết lại cùng nội dung, đổi form.
Compare      — đặt cạnh nhau, chỉ ra khác biệt.
Explain      — giải thích, có audience cụ thể.
Generate     — sinh nội dung mới theo spec.
Critique     — đánh giá, chỉ ra điểm yếu.
Refactor     — đổi cấu trúc, giữ behavior.

Verb mơ hồ ("handle", "deal with", "process") nên tránh vì không đặc tả output. Verb "help" gần như không có nghĩa với LLM trừ khi đi kèm điều kiện chi tiết.

Ví dụ áp dụng:

Translate the paragraph below to English. Keep the formal tone.
Summarize the article in 3 bullet points, mỗi bullet ≤ 15 từ.
Classify the email into one of: spam, promotion, personal, work.
Extract all dates (ISO 8601) and people names from the text.
Rewrite the sentence to be more concise, removing redundant phrases.

Sau verb là constraint. Bốn nhóm constraint dùng nhiều nhất:

• Length: "trong 2 câu", "100 từ", "1 paragraph", "≤ 50 token", "3-5 bullet". Càng định lượng càng tốt.
• Style: "formal", "casual", "academic", "neutral", "report style".
• Detail level: "high-level overview" / "detailed explanation" / "executive summary" / "step-by-step walkthrough".
• Audience: "for beginners", "for a senior Python engineer", "for a non-technical stakeholder", "for a 10-year-old".

Một câu task gộp đủ bốn:

Explain `dict comprehension` for a Python beginner (audience),
in 3-5 sentences (length), with a casual tone (style),
giving 1 short code example after the explanation (detail).

Lưu ý ràng buộc về length không phải tuyệt đối — model có thể lệch một hai câu. Nếu cần đúng số lượng, kết hợp với output format có schema (B24).

Khi task có nhiều phần phụ thuộc nhau, mô tả từng step thay vì gộp một câu dài:

Task: Phân tích đoạn code Python phía dưới.

Step 1: Xác định mục đích chính của function.
Step 2: Liệt kê các bug tiềm tàng (logic, edge case, performance).
Step 3: Đề xuất sửa cho từng bug, kèm đoạn code thay thế.

Code:
<<< paste code here >>>

Step-by-step có hai lợi ích: model thực thi đúng thứ tự bạn muốn, và phần output dễ parse hơn vì có structure ngầm theo step.

Đây là tiền đề cho Chain-of-Thought (B27) — kỹ thuật ép model "suy luận từng bước trước khi trả lời", tăng accuracy ở task reasoning. Step-by-step ở task description là baseline; CoT là phiên bản có thêm "think out loud".

So sánh hai cách viết cùng một task:

A: "Read the document, extract key points, then summarize them
    in 3 bullet points."

B: "1. Read the document.
    2. Extract key points.
    3. Summarize them in 3 bullet points."

Cùng nội dung, nhưng B cho output ổn định hơn vì:

• Mỗi step có boundary rõ — model dễ "đếm" mình đang ở step nào.
• Khi reasoning sai ở một bước, dễ debug bằng cách bám theo step number.
• Model có xu hướng tôn trọng cấu trúc xuất hiện trong prompt (mirror back) — output cũng có structure.

Quy tắc thực tế: nếu task có ≥ 3 thao tác liên tiếp, dùng numbered list.

Dùng câu mệnh lệnh trực tiếp, tránh câu hỏi vòng vo:

Yếu  : Could you maybe try to translate this to English if possible?
Mạnh : Translate the text below to English.

Câu mệnh lệnh có 3 ưu điểm:

• Ngắn — bớt token, đỡ "lost in the middle".
• Rõ — không có modal verb ("could", "should", "maybe") làm yếu yêu cầu.
• Tránh model trả lời câu hỏi tu từ thay vì thực hiện task.

Tiếng Việt áp dụng tương tự: "Hãy dịch...", "Tóm tắt...", "Phân loại..." thay vì "Bạn có thể giúp tôi dịch không?".

Từ mơ hồ là kẻ thù của task description. Ba pattern hay gặp:

Ambiguous: "Make it better."
Clear    : "Rewrite to be more concise, removing redundant phrases and
            passive voice."

Ambiguous: "Improve performance."
Clear    : "Reduce time complexity from O(n²) to O(n log n) if possible.
            Note the new complexity in the comment."

Ambiguous: "Clean up the data."
Clear    : "Drop rows with null `email` or `created_at`. Lowercase the
            `email` column. Convert `created_at` to ISO 8601."

Mẹo: đọc lại prompt và hỏi "câu này có thể hiểu theo mấy cách?". Nếu ≥ 2 → cần specific hơn.

Task lớn ("phân tích báo cáo tài chính rồi viết khuyến nghị đầu tư") thường vượt khả năng model nếu nhồi vào một call. Hai chiến lược:

• Sub-task trong cùng prompt: dùng step-by-step (mục 7) để model làm tuần tự. Phù hợp khi tổng độ phức tạp vẫn vừa với context window.
• Sub-task nhiều call: chia task thành chuỗi API call, output của call trước là input của call sau. Mỗi call có task description riêng, ngắn và rõ. Phù hợp khi mỗi bước cần kiểm soát chất lượng độc lập.

Ví dụ chia task "viết blog post 1500 từ":

Call 1 — Outline: Tạo outline 5-7 mục cho topic X.
Call 2 — Draft : Cho outline đã duyệt, viết draft 1500 từ.
Call 3 — Edit  : Đọc draft, cắt câu trùng, gợi ý 3 chỗ thêm dữ liệu.

Pipeline kiểu này dễ test, dễ thay model ở từng bước, dễ cache phần ổn định.

Negative constraint là chỉ thị "đừng làm X":

DO NOT include personal opinions.
AVOID using technical jargon.
DO NOT explain the reasoning, just provide the final answer.
DO NOT add any markdown formatting; output plain text only.

Negative constraint có ích khi:

• Có một hành vi cụ thể, dễ tên gọi, mà bạn muốn cấm.
• Hành vi đó là default của model — không cấm thì model làm.
• Bạn không có cách "dương" tự nhiên để diễn đạt.

Negative constraint không nên trở thành chính thân của task. Nếu phải liệt kê 10 thứ "không được làm", có khả năng cao bạn chưa định nghĩa rõ "cần làm gì".

Hiện tượng kinh điển trong tâm lý học (Wegner 1987): bảo người ta "đừng nghĩ đến con voi màu hồng" lại khiến họ nghĩ đến nó. LLM, tuy không phải con người, cũng dễ trượt theo từ vựng xuất hiện trong prompt — kể cả khi đi kèm "không".

Yếu   : "Do not mention pricing in your response."
       → model vẫn có khả năng nhắc giá vì token "pricing" xuất hiện
         trong context.

Mạnh  : "Focus only on the product's features and use cases."
       → định nghĩa miền cần làm, không gợi ý miền cấm.

Quy tắc thực hành: ưu tiên diễn đạt dương (instruct what TO DO). Chỉ dùng dạng âm khi không có cách dương tự nhiên, và đặt ở cuối prompt — sau khi đã nói đủ phần dương.

Anthropic Prompt Engineering Guide cũng note pattern này: "Tell Claude what to do, not what not to do".

Tone là một loại constraint riêng, đáng tách ra vì ảnh hưởng nhiều đến cảm nhận end-user. Một vài tone phổ biến:

"Trả lời professional, polite."
"Trả lời friendly, conversational, dùng 'bạn' thay vì 'anh/chị'."
"Trả lời technical, no jargon, mỗi thuật ngữ nếu dùng phải kèm 1 câu giải thích."
"Trả lời neutral, không cảm xúc, không emoji."

Đặt tone ở phần đầu prompt (gần persona) thay vì cuối — tone là "frame", không phải "modifier" cuối câu. Hai cách viết tương đương về thông tin nhưng khác về vị trí có thể cho output khác nhau.

Lưu ý: tone instruction hoạt động tốt hơn khi đi cùng audience instruction (mục 6). "Friendly" với end-user khác với "friendly" giữa senior engineer.

Cùng nguyên tắc, áp dụng vào các domain cụ thể:

Code      : "Write a Python function `parse_iso_date(s: str) -> date`
             that parses ISO 8601 date strings. Raise ValueError for
             invalid input. Add a docstring with 2 example calls."

Writing   : "Compose a professional email to client X about delay of
             feature Y by 1 week. Tone: apologetic but confident. Length:
             ≤ 150 words. Include: cause, new ETA, mitigation plan."

Analysis  : "Analyze the sales data below. Identify the top-3 month
             with highest revenue, and 1 trend across all months.
             Output as 4 short bullets."

Translation: "Dịch đoạn văn sang tiếng Anh, giữ formal tone. Giữ nguyên
             tên riêng và số liệu. Đặt bản dịch trong block ```en ... ```."

Mỗi domain có verb "đặc dụng" (write / compose / analyze / translate) và set constraint quen thuộc. Khi viết task cho domain mới, lấy 3-5 ví dụ task tốt trong domain đó và quan sát pattern.

Khi prompt chứa nhiều task song song (model phải làm cả 3), dùng delimiter rõ ràng:

Task 1: Tóm tắt document phía dưới trong 3 câu.
Task 2: List 3 insight chính, mỗi insight kèm bằng chứng từ document.
Task 3: Đề xuất 2 hành động tiếp theo dựa trên các insight.

Định dạng output:
### Task 1
...
### Task 2
...
### Task 3
...

Document:
<<< paste document >>>

Delimiter có thể là tag (<task1>...</task1>), heading Markdown, hoặc separator ---. Anthropic khuyến nghị XML-like tag với Claude; OpenAI thường dùng Markdown heading. Trong thực tế cả hai đều chạy được trên cả hai model.

Mục đích: model phân định rõ ranh giới task, không trộn output, dễ parse.

Cuối task description, nói rõ "câu trả lời tốt trông như thế nào". Hai pattern:

A — Explicit checklist:
    "A good answer must include:
     - A short summary (≤ 2 sentences).
     - Three concrete risks, mỗi risk kèm mitigation.
     - One overall recommendation (approve / reject / revise)."

B — Self-verification:
    "Before answering, verify that:
     - Mọi số liệu bạn dùng đều xuất hiện trong document.
     - Không có khuyến nghị mâu thuẫn nhau.
     Nếu một trong hai sai, sửa và trả lời lại."

Pattern B đặc biệt hiệu quả với task có khả năng hallucinate. Nó ép model "đọc lại output" trước khi finalize — một dạng self-critique nhẹ.

Lưu ý: validation criteria không thay thế eval thực sự (B54-59). Nó chỉ giảm tỉ lệ output rõ ràng sai, không đảm bảo đúng.

Không có cách nào viết đúng prompt ngay lần đầu. Quy trình thực tế:

1. Viết prompt v1 dựa trên các nguyên tắc trên.
2. Chạy trên 5-10 case đại diện. Đọc output thủ công.
3. Phát hiện failure mode (vd: model trả lời dài quá, sai format, đoán linh tinh).
4. Sửa prompt v2 — chỉ sửa 1 thay đổi tại một thời điểm, để tách ảnh hưởng.
5. Khi muốn chọn giữa hai version, A/B test trên 20-50 case, chấm điểm.

Một số tooling 2024-2026 hỗ trợ:

• Anthropic Workbench — chạy prompt với nhiều version, so sánh side-by-side.
• Anthropic prompt improver / generator — tự động đề xuất chỉnh sửa.
• OpenAI Playground — variant testing.
• Promptfoo, Langfuse, Helicone, Arize Phoenix — eval framework open-source / SaaS, chạy batch case, log diff, chấm theo metric.

Quy tắc khi A/B: cố định model, temperature, sampling param; chỉ thay đổi prompt. Nếu thay nhiều biến cùng lúc, không thể attribute thay đổi kết quả cho biến nào.

Bốn pattern hay gặp:

• Quá vague: "tell me about X", "help with Y" — không có verb cụ thể, không constraint.
• Quá dài: 500 từ chỉ riêng phần task description, lặp ý, chèn lan man. Tăng cost, tăng noise, đẩy thông tin quan trọng ra khỏi vùng "đầu / cuối" prompt.
• Mâu thuẫn nội tại: "ngắn nhưng đầy đủ chi tiết", "tránh jargon nhưng phải technical", "neutral nhưng thuyết phục". Model sẽ chọn một trong hai, không thể satisfy cả hai.
• Open-ended không boundary: "viết gì cũng được", "tùy bạn". Output sẽ rất biến thiên. Nếu thực sự không có boundary, ít nhất chỉ định length và format.

Mỗi khi nhận output kém, kiểm tra prompt theo 4 pattern này trước khi đổ lỗi cho model.

Template tổng quát có thể tái sử dụng:

Bạn là [persona].

Cho [context], hãy [action verb] để đạt [goal].

Yêu cầu:
- [constraint 1 — length]
- [constraint 2 — style / tone]
- [constraint 3 — audience]
- [constraint 4 — output format hint]

Cách xác định trả lời tốt:
- [validation 1]
- [validation 2]

Bắt đầu:

Ví dụ áp dụng thành prompt code review:

Bạn là một senior Python reviewer.

Cho function dưới đây, hãy review để tìm bug và đề xuất sửa.

Yêu cầu:
- Length: ≤ 200 từ.
- Tone: technical, neutral.
- Audience: mid-level Python dev.
- Output: Markdown table 3 cột (line, bug, fix).

Trả lời tốt:
- Mỗi bug đều có line number tương ứng trong code.
- Fix được trình bày dưới dạng diff hoặc snippet thay thế.

Bắt đầu:
<<< paste function here >>>

Ba cặp ví dụ tổng kết bài:

Bad : "Help me with Python."
Good: "Tôi đang học Python. Hãy giải thích `dict comprehension`
       cho người mới, trong 3-5 câu, kèm 1 ví dụ code đơn giản
       in ra `{1: 1, 2: 4, 3: 9}`."

Bad : "Tóm tắt cái này."
Good: "Tóm tắt document phía dưới trong 3 bullet point. Mỗi bullet
       ≤ 20 từ, tập trung vào quyết định và số liệu cụ thể, bỏ qua
       phần mô tả nền."

Bad : "Sửa code."
Good: "Review function `parse_user(data)` dưới đây. Tìm tối đa 5 bug.
       Output Markdown table 3 cột: line, mô tả bug, diff sửa. Không
       cần giải thích quyết định, chỉ trả về bảng."

Khác biệt chính ở cột Good: verb rõ, length định lượng, audience cụ thể, format có schema, và domain language phù hợp.

So sánh vague vs specific trên cùng một input:

import anthropic

client = anthropic.Anthropic()

INPUT = """def divide(a, b):
    return a / b
"""

VAGUE = "Help me with this code:\n\n" + INPUT

SPECIFIC = f"""Review the Python function below.

Yêu cầu:
- Tìm tối đa 3 bug (logic, edge case, validation).
- Output Markdown table 3 cột: line, bug, suggested_fix.
- Không thêm phần giải thích bên ngoài bảng.

Code:
{INPUT}"""

def run(prompt: str) -> str:
    resp = client.messages.create(
        model="claude-opus-4",
        max_tokens=512,
        messages=[{"role": "user", "content": prompt}],
    )
    return resp.content[0].text

print("--- VAGUE ---")
print(run(VAGUE))
print("--- SPECIFIC ---")
print(run(SPECIFIC))

Apply step-by-step task:

STEP_BY_STEP = f"""Phân tích function Python phía dưới.

Step 1: Tóm tắt mục đích của function trong 1 câu.
Step 2: Liệt kê 3 edge case có thể fail.
Step 3: Đề xuất bản sửa hoàn chỉnh, kèm docstring và type hint.

Code:
{INPUT}"""

print(run(STEP_BY_STEP))

A/B test hai version trên một bộ case:

CASES = [
    "def divide(a, b):\n    return a / b\n",
    "def get_user(id):\n    return users[id]\n",
    "def avg(xs):\n    return sum(xs) / len(xs)\n",
]

def make_vague(code: str) -> str:
    return "Help me with this code:\n\n" + code

def make_specific(code: str) -> str:
    return (
        "Review the Python function below.\n"
        "- Tìm tối đa 3 bug.\n"
        "- Output Markdown table: line, bug, fix.\n"
        "- Không có text ngoài bảng.\n\n"
        f"Code:\n{code}"
    )

def score(output: str) -> int:
    """Heuristic: có bảng + có line number + có suggested fix."""
    s = 0
    if "|" in output and "line" in output.lower(): s += 1
    if "fix" in output.lower(): s += 1
    if len(output.splitlines()) < 30: s += 1   # không lan man
    return s

results = {"vague": 0, "specific": 0}
for code in CASES:
    results["vague"]    += score(run(make_vague(code)))
    results["specific"] += score(run(make_specific(code)))

print(results)

Heuristic score ở trên rất thô — trong production bạn sẽ dùng LLM-as-Judge (B56) hoặc reference-based metric (B55). Mục đích ở đây chỉ là minh họa workflow A/B.

1. Refactor 3 prompt vague sau đây thành specific (theo template ở mục 20): (a) "Giúp tôi viết bio LinkedIn"; (b) "Sửa lại đoạn văn cho hay hơn"; (c) "Phân tích dataset bán hàng".
2. Viết task description cho 3 domain: dịch (Việt → Anh), summarize (article tin tức), classify (review thành positive / negative / neutral). Mỗi task kèm action verb, ≥ 3 constraint, validation criteria.
3. Lấy một task lớn (ví dụ "viết blog post 1500 từ về RAG") và áp dụng decomposition: chia thành ≥ 3 sub-task, mỗi sub-task có prompt riêng. Mô tả input/output kỳ vọng cho từng bước.
4. A/B test hai phiên bản task description (vague vs specific) cho cùng một use case trên 5 case input. Dùng anthropic hoặc openai SDK. Log output, chấm thủ công theo 3 tiêu chí (đúng format, độ dài, không hallucinate), tổng điểm so sánh.
5. (Tùy chọn) Lấy một prompt cũ bạn từng dùng (chatbot, code helper, content tool). Đánh dấu trong prompt đâu là Context, đâu là Task, đâu là Output format, đâu là Examples. Phần nào còn vague? Viết lại task description theo template mục 20 và đo lại chất lượng trên 5-10 case.

Bài tiếp theo (B24 — Output format) sẽ tập trung phần "ép LLM trả về đúng cấu trúc" — bổ sung trực tiếp cho phần "constraint output format" đã nhắc tới nhiều lần ở bài này.