Prompt Engineering — 4 nhóm lớn, 24 kỹ thuật hiện đại

Từ PromptingGuide.ai đến survey 2024-2026 và docs vendor mới: prompt engineering hiện đại là một stack gồm framing, context, reasoning và reliability, không phải danh sách magic phrases.

Cập nhật: 2026-04-22Phạm vi: text-first, inference-timeKỹ thuật: 24Nguồn survey: 58 text techniques

Tổng quan Overview

Luận điểm chính: prompt engineering bây giờ phải đọc như một chuỗi quyết định về instruction, context, reasoning scaffold và output reliability. Những “mẹo” cũ vẫn đúng, nhưng chúng chỉ là một lát cắt hẹp của bức tranh hiện tại.

4 nhóm lớn taxonomy layer-1 của report

24 kỹ thuật cốt lõi được phân tích ngay trên layer 1

58 text techniques baseline từ Prompt Report

2026 taxonomy mới nhất 4 aspects: instruction, knowledge, reasoning, reliability

Prompt engineering hiện đại là một stack. Mỗi layer giải một loại failure mode khác nhau.

flowchart TB
  P["Prompt engineering"] --> A["1. Frame the job"]
  P --> B["2. Load the right context"]
  P --> C["3. Make the model think"]
  P --> D["4. Keep outputs reliable"]

  A --> A1["Role / task / examples / XML / schema"]
  B --> B1["RAG / query rewrite / long context / caching"]
  C --> C1["CoT / decomposition / search / tools / code"]
  D --> D1["Critique / ensembles / evals / guardrails"]

Điểm cần giữ trong đầu khi đọc toàn report: phần lớn technique không cạnh tranh trực tiếp với nhau. Chúng xếp chồng. Ví dụ: bạn có thể dùng role + few-shot + RAG + CoT + self-consistency + structured outputs trong cùng một flow.

Taxonomy mới Taxonomy

ID	Nhóm lớn	Câu hỏi mà nhóm này giải quyết
1	Profile & instruction	Instruction
2	Knowledge & context	Context
3	Reasoning & planning	Reasoning
4	Reliability & optimization	Reliability

Quick tags: instruction context reasoning reliability

Đừng đọc taxonomy như phân loại cứng. Một technique có thể nằm ở nhiều nhóm. Ví dụ XML tags là instruction shaping, nhưng cũng là context shaping; prompt chaining là reasoning, nhưng cũng là workflow orchestration.

Cách đọc report này

Nhóm 1 trả lời: model nên đóng vai gì và output phải trông như thế nào?
Nhóm 2 trả lời: cần nạp thêm context gì và context phải được shape ra sao?
Nhóm 3 trả lời: model nên suy luận, phân rã, gọi tool và ghép bước như thế nào?
Nhóm 4 trả lời: làm sao kiểm tra, siết, tối ưu và bảo vệ output?

Ví dụ thực chiến Examples

Phần này nối 4 nhóm lớn với tình huống thật. Điểm chính không phải là prompt “hay” hơn, mà là thấy được prompt engineering hoạt động như một contract có mục tiêu, input, output và failure mode rõ ràng.

Tình huống	Kỹ thuật chính	Output contract
Support triage	`Role` + `Task instruction` + `XML` + `Structured outputs`	Phân loại ticket, trả JSON, kèm customer reply ngắn.
Docs Q&A	`RAG` + `Long-context order` + `Quote grounding`	Chỉ trả lời từ nguồn, quote evidence trước khi kết luận.
Research synthesis	`Query rewrite` + `Multi-hop` + `Prompt chaining`	Tra từng hop, ghi note trung gian, rồi synthesize memo.
Extraction / audit	`Structured outputs` + `Self-refine` + `Guardrails`	JSON strict, kiểm schema, từ chối input rủi ro.

Ví dụ 1: Triage ticket support

Mục tiêu: model đọc ticket, xác định mức độ ưu tiên, trích thông tin cần xử lý và viết phản hồi ngắn theo đúng tone support. Đây là pattern rất điển hình cho role + task instruction + structured outputs.

Prompt mẫu cho support triage

TEXT

<system>
You are a support triage lead for a SaaS product.
Classify each ticket, choose one priority, and draft a customer reply.
</system>
<ticket>
Subject: Billing charged twice after upgrade
Body: I upgraded yesterday and saw two charges on my card.
</ticket>
<rules>
- Return valid JSON only.
- Use priority one of: low, medium, high, urgent.
- If billing is involved, add category "billing".
- The customer reply must be under 80 words and empathetic.
</rules>

Output kỳ vọng: một JSON hợp lệ, parse được ngay vào workflow tự động. Cùng một prompt này có thể đem đi gắn vào pipeline mà không cần parse tự do.

Ví dụ output hợp lệ

JSON

{
  "priority": "high",
  "category": "billing",
  "customer_reply": "Sorry about the duplicate charge. I’m checking this now and will update you shortly.",
  "next_action": "Investigate billing logs and reconcile duplicate authorization"
}

Ví dụ 2: Hỏi đáp trên bộ tài liệu

Mục tiêu: model trả lời đúng theo nguồn, không bịa thêm. Đây là chỗ mà RAG + long-context ordering + quote grounding phát huy rõ nhất.

Prompt mẫu cho docs Q&A

TEXT

<instructions>
Use only the documents below.
If the answer is missing, say "not found".
Quote the relevant evidence before the final answer.
</instructions>
<documents>
  <document id="1" source="policy.md">
    All enterprise accounts must rotate API keys every 90 days.
  </document>
  <document id="2" source="faq.md">
    Billing resets happen at the beginning of each month.
  </document>
</documents>
<question>
When do enterprise accounts need to rotate API keys?
</question>

Output tốt không chỉ đúng, mà còn traceable. Người đọc phải nhìn ra ngay câu nào đến từ `policy.md` và câu nào là inference của model.

Ví dụ 3: Tổng hợp research nhiều hop

Mục tiêu: biến một câu hỏi rộng thành chuỗi bước nhỏ, mỗi bước có evidence riêng. Đây là phối hợp của query rewrite + multi-hop retrieval + prompt chaining.

Prompt chain cho research synthesis

TEXT

Step 1: Rewrite the user's question into 3 search queries.
Step 2: Retrieve evidence for each query and write short notes.
Step 3: Merge the notes into a 1-paragraph memo with caveats.

Question: What changed in prompt engineering after 2024?

Query rewrite -> hop 1 evidence -> hop 2 evidence -> memo

Điểm lợi: bạn thấy ngay hop nào thiếu evidence. Nếu bước 1 rewrite kém, cả pipeline sẽ lộ ra sớm thay vì ẩn trong một câu trả lời dài.

Ví dụ 4: Trích xuất và kiểm soát đầu ra

Mục tiêu: model chuyển text lộn xộn thành JSON hợp lệ, rồi tự kiểm tra trước khi trả. Đây là nơi structured outputs + self-refine + guardrails cực kỳ hữu ích.

Prompt mẫu cho extraction

TEXT

<task>
Extract the incident fields and return strict JSON.
</task>
<schema>
{
  "severity": "low|medium|high|critical",
  "owner_team": "string",
  "summary": "string",
  "needs_followup": "boolean"
}
</schema>
<input>
PagerDuty alert: latency spiked after deploy 2.1.4...
</input>
<verification>
Check that every required field exists and no extra properties are added.
</verification>

Đừng để freeform text lọt vào bước downstream. Nếu workflow có action thật, output phải là contract, không phải prose.

Ví dụ thực chiến

Support triage là case tốt nhất để thấy role/instruction/schema ghép với nhau.
Docs Q&A cho thấy retrieval + ordering quan trọng không kém wording.
Research synthesis và extraction là hai nơi nên dùng chaining, self-refine và guardrails sớm.

Nhóm 1 — Profile & instruction Instruction

Đây là lớp nền của mọi prompt. Nếu lớp này yếu, các lớp sau sẽ phải sửa chữa quá nhiều. Bốn câu hỏi của nhóm này là: ai đang nói, đang làm việc gì, cần mức cụ thể nào, và format đầu ra ra sao.

Failure modes phổ biến của nhóm instruction

Role quá chung chung nên chỉ làm model “văn vẻ” hơn mà không tăng độ đúng.
Task nhồi quá nhiều mục tiêu vào một lượt làm prompt trông “đủ ý” nhưng khó thực thi.
Ví dụ lẫn format hoặc label space khiến few-shot học sai pattern.
Delimiter mơ hồ khiến context, instruction và data bị trộn vào nhau.

1. Role / persona prompting

Sources: 2026 taxonomy, OpenAI, Google, Anthropic

Role đặt “lăng kính” cho model. Nó không thêm kiến thức mới, nhưng nó thay đổi cách model ưu tiên thông tin, giọng điệu và mức độ chi tiết.

Dùng khi bạn cần model trả lời như một chuyên gia có bối cảnh rõ ràng: reviewer, lawyer, tutor, analyst, planner. Trong taxonomy 2026, đây là phần “profile”. Trong thực tế, nó là cách rẻ nhất để giới hạn không gian trả lời trước khi bạn phải thêm examples hay tools.

Role + task skeleton

TEXT

<system>
You are a senior technical editor.
</system>
<user>
Review the draft for clarity, factuality, and missing assumptions.
</user>

Ưu điểm

Tạo ngữ cảnh nhanh, ít token
Giữ tone và mức detail ổn định
Phù hợp cho phong cách chuyên gia hoặc quy trình lặp lại

Nhược điểm

Có thể tạo bias không cần thiết
Không thay thế được data/context thật
Role quá “đậm” dễ làm model sa vào persona hơn là task

Tham khảo

2. Task instruction: intent, domain, demand

Sources: OpenAI, Google, 2026 taxonomy

Đây là kỹ thuật “nói rõ việc cần làm”. Nếu role trả lời câu hỏi “ai”, thì task instruction trả lời “làm gì, trên dữ liệu nào, với ràng buộc nào”.

2026 taxonomy chia instruction thành intent, domain và demand. Cách viết tốt là nêu mục tiêu trước, nguồn dữ liệu sau, rồi chốt constraint ở cuối. Tránh dồn nhiều tác vụ cognitive vào một prompt nếu output cần chính xác.

Instruction viết rõ intent / domain / demand

TEXT

You are writing a release note.
Intent: explain what changed.
Domain: an internal developer audience.
Demand: keep it under 120 words, mention only user-visible changes, and use 3 bullets.

Đừng để “chi tiết” biến thành “mơ hồ dài hơn”. Nếu prompt có 3 hành động khác nhau mà không có cấu trúc, model sẽ xử lý như một bài văn chứ không phải một task.

Tham khảo

3. Zero-shot prompting

Sources: Prompt Report, OpenAI, Google

Zero-shot là baseline. Nó cho bạn câu trả lời nhanh nhất, ít token nhất, và là điểm khởi đầu tốt khi task đủ rõ hoặc model đã mạnh ở domain đó.

Trong survey hiện đại, zero-shot không phải “cách làm thấp cấp”; nó là điểm tham chiếu để đo xem instruction, context hay examples có thực sự tạo ra giá trị hay không. Nếu một task đơn giản mà zero-shot đã ổn, thêm few-shot đôi khi chỉ làm prompt nặng và chậm hơn.

Ưu điểm

Rẻ, nhanh, ít overhead
Không bị example bias
Hợp với câu hỏi đơn giản hoặc model đã hiểu domain

Nhược điểm

Dễ thiếu format discipline
Không đủ cho task label-space hẹp
Hiệu năng biến động mạnh khi task mơ hồ

Tham khảo

4. Few-shot prompting

Sources: Prompt Report, OpenAI, Anthropic, Google

Few-shot vẫn là một trong các kỹ thuật mạnh nhất khi task có output shape rõ ràng: phân loại, trích xuất, formatting, style transfer, hoặc mapping giữa input và output.

Chất lượng examples thường quan trọng hơn số lượng. Hai đến năm ví dụ tốt, đúng format và sát task thường hiệu quả hơn nhiều ví dụ nhưng loạn tiêu chuẩn. 2026 taxonomy cũng nhấn mạnh rằng demonstrations vừa giúp hiểu intent, vừa giúp model học output format.

Few-shot format với input/output rõ ràng

TEXT

<examples>
  <example>
    <input>Return the sentiment of: The release is late but still promising.</input>
    <output>mixed</output>
  </example>
  <example>
    <input>Return the sentiment of: The update is excellent and stable.</input>
    <output>positive</output>
  </example>
</examples>

Ưu điểm

Tăng độ đúng và tính nhất quán
Giúp model học format một cách trực tiếp
Thường giảm nhu cầu viết instruction quá dài

Nhược điểm

Tốn token
Dễ mang bias từ examples
Chọn ví dụ tệ là tự bóp chất lượng

Tham khảo

5. Example selection and ordering

Sources: Prompt Report, 2026 taxonomy

Một vài ví dụ đúng chưa đủ. Prompt engineering hiện đại quan tâm đến ví dụ nào được chọn, theo thứ tự nào, và chúng có đại diện đủ cho task distribution hay không.

Survey mới chỉ ra rằng lấy ví dụ tương tự query, đa dạng hoá ví dụ, và cân bằng label space đều ảnh hưởng đáng kể. Order cũng quan trọng: nếu examples được sắp xếp kém, model có thể bám vào ví dụ cuối hoặc học sai ưu tiên.

Điều này thường bị bỏ qua. Nhiều đội chỉ hỏi “có few-shot chưa?” mà không hỏi “few-shot nào, theo thứ tự nào, và có bias label nào không?”.

Khi example selection làm hỏng prompt

Ví dụ quá giống nhau làm model học một pattern hẹp.
Ví dụ chứa edge case hiếm nhưng lại được đặt quá gần task chính.
Ví dụ có formatting noise hoặc lời giải thích dài hơn output thực.

Tham khảo

6. XML tags, delimiters, and sectioning

Sources: Anthropic, OpenAI, Google

Khi prompt có nhiều phần, cấu trúc rõ ràng thường quan trọng hơn wording khéo léo. XML tags và delimiters giúp model biết đâu là instruction, đâu là context, đâu là example.

Anthropic coi XML tags là một trong các công cụ thực dụng nhất để tách thành phần của prompt. Nó tăng parseability, giảm nhầm lẫn giữa instruction và data, và đặc biệt hợp với multi-document tasks hoặc output cần post-processing.

┌──────────────────────┐ │ │ │ what to do │ │ │ ├──────────────────────┤ │ │ │ untrusted data │ │ │ ├──────────────────────┤ │ │ │ I/O pairs │ │ │ └──────────────────────┘

XML tags không phải “đúng vì Claude thích XML”. Chúng đúng vì bất kỳ model nào cũng tốt hơn khi input được phân vùng rõ ràng.

Tham khảo

Nhóm 1 — điều đáng nhớ

Role + instruction + examples + structure là bốn lớp khác nhau, không phải một thứ.
Few-shot hiệu quả nhất khi examples được chọn và sắp xếp có chủ đích.
XML / delimiters là cách rẻ nhất để giảm ambiguity trước khi phải dùng RAG hay tools.

Nhóm 2 — Knowledge & context Context

Nhóm này trả lời câu hỏi: model còn thiếu gì để trả lời đúng? Trong các hệ thống hiện đại, đây không chỉ là “nhét thêm docs”, mà là một chuỗi quyết định về retrieval, ordering, compression, cacheability và memory.

Failure modes phổ biến của nhóm context

Context quá dài nhưng không có structure, làm model không biết ưu tiên gì.
Retrieval tốt nhưng post-retrieval shaping kém nên evidence bị lẫn rác.
Query ngắn / mơ hồ nhưng không rewrite trước khi đi search.
Static prefix bị thay đổi liên tục, làm cache hit rate tụt.

7. Basic RAG / grounding

Sources: 2026 taxonomy, context engineering survey

Đây là lớp grounding cơ bản nhất: lấy tài liệu ngoài model, đưa vào prompt, và bắt model trả lời dựa trên evidence đó. Nếu câu hỏi có tính thời sự, domain-specific, hoặc đòi citation, RAG thường là lựa chọn đầu tiên.

2026 taxonomy coi RAG là kỹ thuật knowledge augmentation. Context engineering survey thì đẩy nó thành một component của hệ thống: retrieval/generation, processing, management. Điều quan trọng là prompt phải chỉ ra rõ nguồn nào là ground truth và nguồn nào chỉ là hỗ trợ.

RAG prompt skeleton

TEXT

Use only the provided sources.
If the answer is not in the sources, say "not found".

<sources>
  ...
</sources>

<question>
  ...
</question>

Ưu điểm

Giảm hallucination bằng evidence ngoài model
Cập nhật được theo thời gian thực
Hợp với citation và auditability

Nhược điểm

Phụ thuộc retrieval quality
Tăng latency và chi phí
Source stuffing tệ có thể làm answer kém hơn prompt ngắn

Tham khảo

8. Query rewriting / HyDE / Query2doc

Sources: 2026 taxonomy, RAG research

Nhiều retrieval thất bại không phải vì corpus kém, mà vì query quá ngắn, quá mơ hồ, hoặc không mang ontology mà corpus đang dùng. Rewrite query là cách rẻ nhất để sửa mismatch.

Query rewriting có nhiều biến thể: paraphrase query, sinh pseudo-document kiểu HyDE, hoặc Query2doc-style expansion. Mục tiêu là đẩy prompt về “ngôn ngữ của corpus” trước khi search, thay vì hy vọng retriever tự hiểu ý người dùng.

Điểm mấu chốt: khi user query là “hỏi cái gì?”, retrieval query phải là “hỏi bằng từ nào thì corpus mới trả lời được?”.

Tham khảo

9. Multi-hop retrieval and query decomposition

Sources: 2026 taxonomy, context engineering survey

Câu hỏi khó thường không thất bại ở bước “trả lời”, mà thất bại ở bước “không biết phải tra cái gì trước”. Multi-hop retrieval tách vấn đề ra thành các hop trung gian.

Dùng cho câu hỏi so sánh, suy luận nhiều bước, hoặc phụ thuộc vào nhiều tài liệu khác nhau. Query được decomposed thành các sub-queries, mỗi sub-query tìm evidence riêng, sau đó model hợp nhất các mảnh lại thành câu trả lời cuối.

Query ──▶ Hop 1 evidence ──▶ Sub-answer 1 └──▶ Hop 2 evidence ──▶ Sub-answer 2 └──▶ Hop 3 evidence ──▶ Final synthesis

Tham khảo

10. Post-retrieval restructuring

Sources: 2026 taxonomy, RAG literature

Retrieval xong chưa phải xong. Documents thường vẫn còn rác, thứ tự không tối ưu, và không phải đoạn nào cũng nên được model nhìn thấy với cùng trọng số.

Đây là bước trộn content adjusting, structure adjusting và attention refocusing. Một số paper cho thấy việc phân loại lại tài liệu theo mức relevance, hoặc rút gọn/viết lại retrieved context trước khi generation có thể cải thiện mạnh.

Ưu điểm

Làm retrieved evidence “dễ đọc” hơn cho model
Có thể tăng factuality đáng kể
Giảm bớt noise từ docs dài hoặc lẫn tài liệu phụ

Nhược điểm

Nếu reshape quá tay thì mất traceability
Có thể vô tình làm méo evidence
Pipeline phức tạp hơn basic RAG

Tham khảo

11. Long-context ordering and quote grounding

Sources: Anthropic, OpenAI, Google

Khi context dài lên, thứ tự và placement của thông tin trở thành một phần của prompt engineering. Nói cách khác: bạn đang điều khiển attention, không chỉ text.

Anthropic khuyên đặt longform data lên đầu, query ở cuối, và yêu cầu model quote đoạn liên quan trước khi giải quyết task. Kết hợp XML tags với metadata giúp nhiều-document tasks ít bị “tan chảy” hơn.

Long-context prompt skeleton

TEXT

<documents>
  <document index="1">
    <source>paper-a.pdf</source>
    <content>...</content>
  </document>
  <document index="2">
    <source>paper-b.pdf</source>
    <content>...</content>
  </document>
</documents>

<task>
  Quote the relevant evidence first, then answer the question.
</task>

Ưu điểm

Giúp model neo vào source thay vì hallucinate
Hợp với multi-document synthesis
Đơn giản nhưng hiệu quả trong long context

Nhược điểm

Vẫn bị giới hạn bởi context window
Nếu docs không có structure thì chỉ “đổ thêm token”
Queries đặt sai chỗ có thể giảm chất lượng rõ rệt

Tham khảo

12. Prompt caching and compression

Sources: OpenAI, prompt compression survey

Đây là layer engineering “lợi ích thật” nhưng hay bị gọi nhầm là prompt trick. Caching và compression giúp giảm latency/cost và biến prompt thành một artifact có thể tối ưu hóa.

OpenAI cache dựa trên exact prefix match: content tĩnh, instruction và examples nên đặt trước, variable content để sau. Prompt compression literature thì đi xa hơn: giảm prompt length trong khi giữ semantic content cần thiết.

Điểm mới của 2025-2026: prompt engineering không chỉ là “đúng hơn” mà còn là “rẻ hơn và ổn định hơn”.

Khi compression làm hỏng prompt

Giảm token nhưng mất ngoại lệ quan trọng.
Nén quá mức khiến schema hoặc policy bị mờ.
Static prefix không ổn định làm cache hit rate tụt.

Tham khảo

Nhóm 2 — điều đáng nhớ

Retrieval tốt chưa đủ; post-retrieval shaping quyết định model có đọc đúng evidence không.
Long-context tasks là bài toán về ordering, not just length.
Caching và compression là phần economics của prompt engineering hiện đại.

Nhóm 3 — Reasoning & planning Reasoning

Khi instruction và context đã đủ, lớp này quyết định model sẽ đi qua vấn đề như thế nào.

Đây là nhóm kỹ thuật giúp model phân rã bài toán, thử nhiều đường suy luận, gọi tool, và ghép lại thành câu trả lời cuối. Đặc điểm chung là chúng không chỉ viết prompt tốt hơn; chúng thay đổi thứ tự xử lý của model.

Failure modes phổ biến của nhóm reasoning

Đòi model giải quyết task lớn bằng một lần trả lời tuyến tính.
Không có bước tách subproblem nên thought process bị chậm hoặc loạn.
Tool có nhưng không có protocol rõ ràng để reason, act và observe.
Không biết khi nào cần branching search thay vì linear CoT.

13. Chain-of-thought / zero-shot CoT

Sources: CoT paper, OpenAI, Anthropic

CoT là kỹ thuật nền tảng nhất của reasoning prompting. Nó cho model “không gian nghĩ” để đi qua các bước trung gian trước khi chốt answer.

Dùng CoT khi task cần math, logic, multi-step synthesis, hoặc reasoning có cấu trúc. Zero-shot CoT với một gợi ý như “Let's think step by step” vẫn là một trick đơn giản nhưng có tác dụng thật trên nhiều baseline model, đặc biệt khi task không đòi tool.

Zero-shot CoT prompt

TEXT

Solve the problem step by step.
Show the intermediate reasoning only if it helps the final answer.
Then give the final answer in one sentence.

Ưu điểm

Cải thiện reasoning trên task nhiều bước
Đơn giản và dễ áp dụng
Tạo đường đi rõ hơn để debug prompt

Nhược điểm

Tăng latency và token
Không phải task nào cũng cần CoT
Có thể làm model “nói dài nhưng không đúng hơn”

Tham khảo

Phân tích sâu: Chain-of-Thought / zero-shot CoT — reasoning scaffold, monitorability và controllability

14. Plan-and-Solve / Least-to-Most

Sources: plan-first papers, 2026 taxonomy

Đây là decomposition prompting theo kiểu “lập kế hoạch trước, giải sau”. Nó giảm tải working memory và giúp model không nhảy thẳng vào lời giải khi bài toán còn chưa được chia nhỏ.

Least-to-Most tách bài toán thành chuỗi subproblems; Plan-and-Solve thêm một bước lập kế hoạch rõ ràng trước khi triển khai. Với những task có dependency rõ, đây thường là cách ổn định hơn so với việc hỏi model viết CoT tự do ngay từ đầu.

Plan -> Subproblem 1 -> Subproblem 2 -> Merge -> Final answer

Tham khảo

Phân tích sâu: Plan-and-Solve / Least-to-Most — decomposition-first reasoning, easy-to-hard generalization

15. Tree-of-Thought / Graph-of-Thought

Sources: ToT, GoT, reasoning survey

Khi bài toán không có một đường suy luận tuyến tính tốt, branching search thường mạnh hơn CoT thuần. ToT và GoT biến reasoning thành một không gian tìm kiếm.

ToT cho model thử nhiều thought branches, đánh giá, backtrack và chọn đường tốt hơn. GoT mở rộng ý tưởng này bằng cấu trúc graph. Đây là lựa chọn phù hợp cho planning, creative search, puzzle, hoặc các task mà “đúng theo từng bước” chưa chắc là tối ưu toàn cục.

Ưu điểm

Tăng khả năng tìm được đường đi tốt hơn
Hợp với problem solving khó và planning
Cho phép search + evaluation rõ ràng hơn

Nhược điểm

Đắt token và controller logic
Khó triển khai nếu không có scoring rõ
Có thể overkill với task đơn giản

Tham khảo

Phân tích sâu: Tree-of-Thought / Graph-of-Thought — branching search, scoring và backtracking

16. Self-consistency

Sources: CoT + ensemble literature

Self-consistency là cách làm reasoning bớt phụ thuộc vào một đường suy luận duy nhất: sample nhiều chains rồi vote trên answer cuối.

Nó đặc biệt hữu ích khi câu trả lời cuối ổn định hơn các lý do trung gian. Nói đơn giản: đừng tin một đường CoT ngẫu nhiên; lấy nhiều đường, rồi chọn đáp án đồng thuận cao nhất.

Self-consistency sketch

TEXT

for each question:
  sample N reasoning paths
  extract final answers
  vote / aggregate
  return the consensus answer

Ưu điểm

Tăng robustness mà không đổi model
Rất hợp cho reasoning nhiều bước
Dễ ghép với CoT hoặc tool use

Nhược điểm

Đắt vì phải sample nhiều lần
Vote có thể che bias chung của model
Không sửa được reasoning sai một cách hệ thống

Tham khảo

Phân tích sâu: Self-consistency — sampling nhiều reasoning path rồi vote trên final answer

17. ReAct / tool-augmented reasoning

Sources: ReAct paper, OpenAI, Anthropic

ReAct ghép reasoning với hành động. Nó không chỉ “nghĩ”; nó còn biết khi nào phải gọi tool, quan sát kết quả và cập nhật kế hoạch.

Đây là một trong các mẫu nền của agentic prompting hiện đại. Prompt thường có protocol rõ: thought, action, observation. Cái hay là model vừa không bị nhốt trong CoT thuần, vừa không phung phí tool calls khi chưa cần.

ReAct protocol

TEXT

Thought: I should verify the latest source.
Action: search_docs["prompt engineering taxonomy"]
Observation: retrieved 2026 taxonomy paper
Thought: I can now synthesize the result.

ReAct không tự động an toàn. Tool outputs vẫn là untrusted inputs; nếu không có structured outputs và approvals, bạn chỉ thay một loại rủi ro bằng một loại rủi ro khác.

Tham khảo

Phân tích sâu: ReAct / tool-augmented reasoning — thought, action, observation loop

18. Prompt chaining

Sources: Anthropic, Google, agent workflows

Khi task có nhiều bước rõ ràng và bạn cần kiểm tra kết quả trung gian, prompt chaining thường tốt hơn một prompt dài. Nó biến output của bước trước thành input có trách nhiệm cho bước sau.

Prompt chaining hữu ích cho research synthesis, document analysis, content pipelines, và nhiều workflow có thể tách thành stages: extract -> transform -> judge -> format. Nó cũng giúp debug vì mỗi link trong chain có một mục tiêu duy nhất.

Prompt 1: gather facts ↓ Prompt 2: normalize / compare ↓ Prompt 3: synthesize / format

Khi nào chaining thắng CoT đơn lẻ

Khi bạn cần xem intermediate outputs.
Khi mỗi bước có format khác nhau.
Khi một bước sai có thể được sửa trước khi sang bước tiếp theo.

Tham khảo

Phân tích sâu: Prompt chaining — inspectable multi-step pipelines với artifact trung gian

19. PAL / Program-of-Thought

Sources: PAL, program-of-thought literature

Với các bài toán symbolic, arithmetic, tabular, hoặc logic có thể mã hóa được, code là một intermediate representation mạnh hơn tự nhiên ngữ.

PAL / Program-of-Thought bảo model sinh chương trình hoặc pseudo-code thay vì prose reasoning. Cái được là tính chính xác của computation; cái mất là bạn phải có runtime hoặc executor.

PAL-style prompt

TEXT

Write Python to solve the problem.
Use comments for reasoning.
Return the final numeric answer after executing the code.

Ưu điểm

Rất mạnh cho symbolic reasoning và toán
Tách reasoning khỏi computation
Code dễ kiểm tra hơn prose

Nhược điểm

Phụ thuộc runtime
Có rủi ro an toàn nếu execute code bừa bãi
Không hợp cho mọi domain

Tham khảo

Phân tích sâu: PAL / Program-of-Thought — code as intermediate representation

Nhóm 3 — điều đáng nhớ

CoT là nền, nhưng decomposition, branching search và tool use mới là lớp mở rộng thực dụng.
Self-consistency là cách rẻ nhất để biến một reasoning path thành một ensemble.
Prompt chaining và PAL cho thấy prompt engineering đang tiến sát workflow orchestration.

Nhóm 4 — Reliability & optimization Reliability

Nhóm này làm cho prompt system không chỉ thông minh hơn, mà còn ổn định hơn, parseable hơn và an toàn hơn.

Đây là nơi prompt engineering gặp evaluation, guardrails và tool governance. Nếu ba nhóm trước nói về cách để model trả lời tốt, thì nhóm này nói về cách để câu trả lời có thể dùng được trong production.

Failure modes phổ biến của nhóm reliability

Prompt chạy tốt một lần nhưng không ổn định qua nhiều input.
Output đúng về mặt nội dung nhưng không parse được bởi downstream.
Model tự tin nhưng sai, hoặc tự tối ưu theo format mà hy sinh generality.
Untrusted input len vào developer context hoặc tool call mà không bị chặn.

20. Self-refine + external verification

Sources: Self-Refine, CRITIC, OpenAI safety

Self-refine biến model thành reviewer của chính nó. External verification đưa thêm một lớp kiểm tra từ tool hoặc model khác để giảm sai sót.

Đây là pattern rất hữu ích cho drafting, summarization, extraction và các task mà một vòng phản hồi ngắn có thể sửa lỗi lớn. Nhưng nó không phải phép màu: khi bản chất reasoning sai, việc tự sửa đôi khi chỉ làm câu trả lời đẹp hơn chứ không đúng hơn.

Self-refine loop

TEXT

Draft -> Critique -> Revise -> Verify -> Finalize

Ưu điểm

Tốt cho polishing và error reduction
Có thể dùng tool để verify fact / code / search
Dễ nhúng vào pipeline production

Nhược điểm

Có thể tăng verbosity mà không tăng correctness
Nếu critique kém thì refinement kém
Tốn thêm latency

Tham khảo

Phân tích sâu: Self-refine + external verification — draft, critique, revise, verify

21. Prompt ensembling / bagging / boosting

Sources: 2026 taxonomy, Prompt Report

Khi một prompt đơn lẻ không đủ ổn định, ensemble prompts là cách tăng reliability bằng redundancy: nhiều prompt, nhiều đường, rồi hợp nhất kết quả.

2026 taxonomy mô tả bagging và boosting cho LLM prompting. Self-consistency là một biến thể bagging; các cách như DiVeRSe hay AMA cho thấy hệ thống có thể dùng vote, verifier, hoặc weighting để đánh đổi giữa độ mạnh và chi phí.

Đây là reliability bằng thống kê, không phải bằng lời hứa. Thay vì cố tìm một prompt thần kỳ, ta dùng nhiều prompt vừa đủ tốt để triệt bớt may rủi.

Tham khảo

Phân tích sâu: Prompt ensembling — bagging/boosting style reliability at inference time

22. Automatic prompt optimization

Sources: OpenAI, Anthropic, Google, RL/optimization surveys

Đây là bước trưởng thành của prompt engineering: không chỉ viết prompt, mà còn có hệ thống để cải thiện prompt bằng dữ liệu, grader, feedback và iteration.

OpenAI prompt optimizer, Anthropic prompt improver và Google Vertex prompt optimizer đều đi theo logic chung: lấy prompt hiện tại + dataset + feedback, rồi đề xuất phiên bản tốt hơn. Không có evaluator tốt thì tối ưu chỉ là đoán mò có hệ thống.

Optimization flywheel

TEXT

prompt -> dataset / eval -> optimizer -> manual review -> redeploy

Điểm cần giữ kỷ luật

Optimizer không thay thế human review.
Grader phải narrow và rõ.
Prompt tốt cho benchmark chưa chắc tốt cho production edge cases.

Tham khảo

Phân tích sâu: Automatic prompt optimization — dataset, graders và review loop

23. Structured outputs / strict mode / allowed tools

Sources: OpenAI GPT-5.4, function calling, structured outputs

Nếu downstream cần machine-readable output, structured outputs là cách biến prompt từ “nói chuyện” thành “giao thức”. Đây là kỹ thuật reliability quan trọng nhất trong agentic systems.

JSON schema, strict mode, allowed tools và CFG constraints làm cho output space hữu hạn và dễ kiểm tra. Điều này không chỉ giúp parsing; nó giảm rủi ro prompt injection vì model không được tự do phát minh command text ngoài schema.

Structured output sketch

JSON

{
  "type": "object",
  "properties": {
    "decision": { "type": "string", "enum": ["approve", "reject"] },
    "reason": { "type": "string" }
  },
  "required": ["decision", "reason"],
  "additionalProperties": false
}

Ưu điểm

Parseable và deterministic hơn
Tốt cho tool calling và downstream automation
Giảm freeform channels cho injection

Nhược điểm

Schema quá chặt có thể làm giảm linh hoạt
Cần thiết kế tốt nếu muốn model không bị bó tay
Một số task sáng tạo không nên quá constrained

Tham khảo

Phân tích sâu: Structured outputs / strict mode / allowed tools — contract hóa output

24. Safety and injection defenses

Sources: OpenAI, Anthropic, AWS

Prompt engineering hiện đại phải coi untrusted text là nguy cơ, không chỉ là input. Khi model được nối với tools, safety là một phần của prompt design.

Nguyên tắc cốt lõi: đừng cho untrusted input đi thẳng vào developer message; tách data khỏi instruction; giữ tool approvals; và dùng guardrails hoặc validators để hạn chế dữ liệu trôi qua các node. Đây là lớp “không để prompt đẹp mà hệ thống vẫn dễ bị thao túng”.

Anti-patterns cần tránh

Nhét raw user text vào developer context.
Cho model tự do sinh tool arguments không có schema.
Cho phép tool approval mặc định là tắt trong workflow rủi ro cao.
Không có evals / trace grading cho các quyết định quan trọng.

Tham khảo

Phân tích sâu: Safety and injection defenses — defense-in-depth cho agentic prompts

Nhóm 4 — điều đáng nhớ

Reliability không phải lớp “sau cùng cho đẹp”; nó là điều kiện để prompt usable trong production.
Structured outputs và safety guardrails là hai kỹ thuật nên được đưa vào sớm, không phải cuối.
Optimization tooling làm prompt engineering chuyển từ craft sang flywheel có thể lặp lại.

Kết luận Wrap

Khuyến nghị thực dụng: nếu một prompt chưa tốt, hãy sửa theo thứ tự instruction → context → reasoning scaffold → reliability. Đừng nhảy thẳng vào “CoT”, “RAG” hay “agents” nếu lớp trước còn mơ hồ.

Reading order cho người muốn học nhanh

Nguồn nên đọc theo thứ tự

Nếu phải rút gọn toàn bộ report thành một câu: prompt engineering hiện đại là việc thiết kế đầu vào, ngữ cảnh, đường suy luận và output contract sao cho model không chỉ trả lời “có vẻ đúng”, mà còn trả lời ổn định, kiểm tra được và dùng được trong hệ thống.