Menu
Học tập
Khóa học Lộ trình nghề nghiệp Roadmap BA → CPO BA → Product Manager Tài liệu & Sách
Cộng đồng
Cộng đồng Interview Questions
Công cụ
Phân tích CV Theo dõi ứng tuyển Hiring Pipeline Luyện phỏng vấn Tối ưu LinkedIn Đàm phán lương
Tài khoản
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 15 — Advanced Prompt Patterns

AI Product Manager Bài 15/60

Mở đầu — vì sao bài này quan trọng

Ở Bài 14, bạn đã nắm được nền tảng prompt engineering: cách viết một prompt rõ ràng, gán vai trò (role), đưa ví dụ few-shot, kiểm soát định dạng đầu ra. Những kỹ thuật đó đủ để giải quyết phần lớn các tác vụ đơn giản — tóm tắt, phân loại, viết lại. Nhưng khi bạn xây dựng một AI product thật sự, bạn sẽ nhanh chóng gặp một bức tường: mô hình trả lời sai khi bài toán cần suy luận nhiều bước, cần dùng công cụ bên ngoài (gọi API, tra database), hoặc cần tự kiểm tra và sửa lỗi của chính nó.

Đây chính là lãnh địa của advanced prompt patterns. Đó không còn là chuyện "viết câu lệnh hay hơn", mà là thiết kế quy trình tư duy cho mô hình. Bạn dạy nó cách phân rã vấn đề, cách xen kẽ giữa suy nghĩ và hành động, cách phản tỉnh trước khi chốt câu trả lời. Với vai trò một AI Product Manager, hiểu các pattern này quyết định trực tiếp đến chất lượng, độ tin cậy và chi phí của tính năng bạn ship. Một chatbot hỗ trợ khách hàng dùng đúng pattern ReAct có thể tự tra cứu đơn hàng và trả lời chính xác; dùng sai, nó sẽ "bịa" số đơn hàng và làm khách giận.

Trong bài này, chúng ta đi sâu vào bốn nhóm pattern cốt lõi: Chain-of-Thought, ReAct (Reason + Act), Self-Consistency và Reflection/Self-Critique. Đây là những viên gạch nền cho các chủ đề nâng cao hơn về sau như Function Calling (Bài 16) và AI Agents (Bài 43).

Khái niệm cốt lõi

Chain-of-Thought (CoT) — buộc mô hình "suy nghĩ ra giấy"

Mặc định, LLM có xu hướng "nhảy" thẳng tới đáp án. Với bài toán suy luận (toán, logic, ra quyết định nhiều điều kiện), việc nhảy tắt thường dẫn tới sai. Chain-of-Thought là kỹ thuật yêu cầu mô hình viết ra từng bước lập luận trước khi đưa kết luận. Đơn giản nhất, bạn chỉ cần thêm câu "Hãy suy nghĩ từng bước một" (Let's think step by step). Nâng cao hơn, bạn đưa ví dụ few-shot trong đó phần lập luận được trình bày tường minh.

Vì sao nó hiệu quả? Vì mỗi token mô hình sinh ra trở thành "ngữ cảnh" cho token tiếp theo. Khi mô hình viết ra bước trung gian, nó tự tạo cho mình một chuỗi gợi ý dẫn đường, giảm xác suất sai ở bước cuối. Cái giá phải trả là nhiều token hơn (tốn chi phí, tăng độ trễ) và đôi khi lập luận dài dòng. Mẹo thực tế: với sản phẩm hướng người dùng cuối, hãy để mô hình suy luận trong một vùng ẩn (ví dụ thẻ <thinking>) rồi chỉ hiển thị kết luận sạch sẽ.

ReAct (Reason + Act) — xen kẽ suy nghĩ và hành động

ReAct là pattern nền tảng cho mọi AI agent. Ý tưởng: mô hình luân phiên giữa Thought (suy luận về việc cần làm), Action (gọi một công cụ/tool) và Observation (đọc kết quả tool trả về), lặp lại cho đến khi đủ thông tin để đưa Final Answer. Một vòng lặp điển hình:

Thought: Người dùng hỏi thời tiết Đà Nẵng hôm nay. Tôi không biết, cần gọi weather API.
Action: get_weather(city="Da Nang")
Observation: {"temp": 31, "condition": "mưa rào", "humidity": 78}
Thought: Đã có dữ liệu. Tôi có thể trả lời.
Final Answer: Đà Nẵng hôm nay khoảng 31°C, có mưa rào, độ ẩm 78%.

Điểm mấu chốt: mô hình không tự bịa dữ liệu thời tiết, mà thừa nhận giới hạn và gọi công cụ. Đây là cách giải quyết vấn đề lớn nhất của LLM — kiến thức bị "đóng băng" tại thời điểm huấn luyện và không truy cập được dữ liệu thời gian thực hay nội bộ doanh nghiệp. ReAct biến mô hình từ một "bộ não đơn độc" thành một "tác nhân" biết dùng tay chân.

Self-Consistency — bỏ phiếu để giảm may rủi

Vì LLM sinh văn bản có yếu tố ngẫu nhiên (đặc biệt khi temperature > 0), cùng một prompt có thể cho lập luận khác nhau. Self-Consistency khai thác điều này: chạy cùng một prompt CoT nhiều lần, thu nhiều chuỗi lập luận, rồi lấy đáp án xuất hiện nhiều nhất (majority voting). Logic giống như hỏi ý kiến 5 chuyên gia thay vì 1: nếu 4/5 cho cùng kết quả, độ tin cậy cao hơn hẳn. Đổi lại, chi phí nhân lên theo số lần chạy, nên pattern này hợp với các bài toán giá trị cao, ít gọi (ví dụ: thẩm định một hồ sơ vay, phân loại một giao dịch nghi ngờ gian lận) hơn là tác vụ khối lượng lớn.

Reflection / Self-Critique — để mô hình tự soi lỗi

Pattern này chia làm hai bước: mô hình tạo ra một câu trả lời nháp, sau đó bạn yêu cầu nó đóng vai người phản biện để chỉ ra điểm yếu, lỗi sai, thiếu sót — rồi viết lại bản hoàn chỉnh. Reflection đặc biệt mạnh với code (tự tìm bug), với văn bản dài (kiểm tra tính nhất quán) và với các câu trả lời cần độ chính xác cao. Hạn chế: mô hình đôi khi "tự khen" và không thấy lỗi của mình, nên bạn cần đặt tiêu chí phản biện cụ thể thay vì chỉ hỏi chung chung "bản này có ổn không?".

Tình huống thực tế

Tình huống 1 — Tiki và chatbot tra cứu đơn hàng (ReAct cứu một bàn thua)

Giả định một đội sản phẩm tại sàn TMĐT như Tiki xây trợ lý chăm sóc khách hàng. Phiên bản đầu chỉ dùng prompt thường: "Bạn là trợ lý CSKH, hãy trả lời câu hỏi của khách." Khi khách hỏi "Đơn TIKI123456 của tôi giao đến đâu rồi?", mô hình — vốn không có dữ liệu đơn hàng — bịa ra "Đơn của bạn đang ở kho Bình Dương, dự kiến giao ngày mai." Trong khi thực tế đơn đã giao xong từ hôm trước. Tỷ lệ khiếu nại tăng vọt.

Đội chuyển sang ReAct với hai tool: lookup_order(order_id) và get_shipping_status(order_id). Giờ mô hình suy luận: "Khách hỏi trạng thái đơn TIKI123456 → cần gọi get_shipping_status." Nó gọi tool, nhận về {"status": "delivered", "date": "2026-06-25"}, rồi trả lời chính xác. Bài học: khi câu trả lời phụ thuộc dữ liệu mà mô hình không thể tự biết (đơn hàng, tồn kho, giá real-time), bắt buộc dùng ReAct — và quan trọng nhất, phải hướng dẫn mô hình rằng "nếu không có thông tin từ tool, hãy nói không biết, tuyệt đối không suy đoán".

Tình huống 2 — Fintech duyệt hồ sơ tín dụng với Self-Consistency

Một công ty fintech ở TP.HCM (giả định) dùng LLM hỗ trợ phân loại rủi ro hồ sơ vay tiêu dùng dựa trên mô tả thu nhập, lịch sử và mục đích vay. Mỗi hồ sơ được đưa qua prompt CoT yêu cầu mô hình lập luận và xếp loại Thấp/Trung bình/Cao. Ban đầu chạy một lần, họ thấy kết quả "nhảy" — cùng hồ sơ, hôm nay Trung bình, mai lại Cao. Điều này không chấp nhận được trong tài chính.

Họ áp dụng Self-Consistency: chạy mỗi hồ sơ 5 lần ở temperature 0.7, lấy nhãn đa số. Nếu phiếu bầu phân tán (ví dụ 2-2-1, không có đa số rõ), hệ thống tự động đẩy hồ sơ sang chuyên viên người thật thay vì để AI quyết. Kết quả: độ ổn định tăng đáng kể, và những ca khó được lọc ra đúng nơi cần con người. Bài học: Self-Consistency không chỉ cho ra đáp án ổn định hơn, mà mức độ phân tán của các phiếu còn là một tín hiệu về độ chắc chắn — hồ sơ nào mô hình "lưỡng lự" thì chuyển cho người.

Tình huống 3 — Đội nội dung dùng Reflection để giảm lỗi

Một startup edtech viết hàng trăm bài giảng bằng LLM. Bản nháp đầu thường mắc lỗi: ví dụ minh họa không khớp khái niệm, hoặc tuyên bố thiếu chính xác. Họ thêm bước Reflection vào pipeline: sau khi sinh bản nháp, prompt thứ hai yêu cầu mô hình "đóng vai biên tập viên khó tính, kiểm tra: (1) mọi ví dụ có thực sự minh họa đúng khái niệm không, (2) có con số nào đáng ngờ không, (3) có chỗ nào mâu thuẫn không" rồi viết lại. Tỷ lệ bài phải sửa thủ công giảm rõ rệt. Bài học: Reflection chỉ hiệu quả khi tiêu chí phản biện cụ thể và có thể kiểm tra được — "hãy kiểm tra lỗi" thì vô dụng, "hãy kiểm tra từng con số có nguồn không" thì hữu ích.

Hướng dẫn từng bước

Đây là quy trình chọn và triển khai pattern cho một tính năng AI:

  • Xác định bản chất bài toán. Hỏi: tác vụ này có cần suy luận nhiều bước không? Có cần dữ liệu/hành động bên ngoài không? Sai một lần thì thiệt hại tới mức nào? Câu trả lời định hướng pattern: cần dữ liệu ngoài → ReAct; cần suy luận → CoT; giá trị cao cần ổn định → Self-Consistency; cần độ chính xác cao của một output → Reflection.
  • Bắt đầu từ đơn giản nhất. Đừng nhảy ngay vào ReAct nếu CoT giải quyết được. Mỗi pattern nâng cao đều thêm token, độ trễ và chi phí. Thử CoT trước, đo kết quả, chỉ leo thang khi cần.
  • Với CoT: thêm hướng dẫn suy luận từng bước, và nếu sản phẩm hướng người dùng, tách phần suy luận vào vùng ẩn (<thinking>...</thinking>) rồi chỉ hiển thị kết luận.
  • Với ReAct: định nghĩa rõ danh sách tool (tên, mô tả, tham số), quy định định dạng Thought/Action/Observation, và giới hạn số vòng lặp (ví dụ tối đa 5 bước) để tránh mô hình lặp vô hạn. Luôn có nhánh "nếu không tìm được thông tin, hãy báo không biết".
  • Với Self-Consistency: chọn số lần chạy (3–7 là phổ biến), đặt temperature > 0, định nghĩa rõ cách trích xuất đáp án cuối từ mỗi lần chạy và quy tắc bỏ phiếu. Thiết kế nhánh xử lý khi không có đa số.
  • Với Reflection: viết tiêu chí phản biện cụ thể, kiểm tra được. Cân nhắc giới hạn 1–2 vòng phản tỉnh — lặp quá nhiều thường không cải thiện thêm mà chỉ tốn tiền.
  • Đo lường và lặp. Xây một bộ test (vài chục đến vài trăm ca) có đáp án đúng. So sánh độ chính xác, chi phí token, độ trễ giữa các pattern. Quyết định dựa trên số liệu, không dựa cảm tính.

Lỗi thường gặp & mẹo

  • Dùng ReAct khi không có tool thật. Nhiều người bắt mô hình "giả vờ" gọi API mà không có backend xử lý — mô hình sẽ tự bịa cả Observation. ReAct chỉ có nghĩa khi tool thực sự được thực thi và trả kết quả thật về.
  • Lập luận lộ ra cho người dùng. Để nguyên cả chuỗi "Thought: ... Action: ..." hiển thị cho khách là vừa rối mắt vừa rò rỉ logic nội bộ. Luôn lọc, chỉ show kết quả cuối.
  • Quên giới hạn vòng lặp. Agent ReAct không có trần số bước có thể lặp vô tận khi gặp tool lỗi, đốt tiền và treo phản hồi. Luôn đặt max-steps và fallback.
  • Self-Consistency cho tác vụ khối lượng lớn. Nhân 5 lần chi phí cho hàng triệu request là thảm họa ngân sách. Chỉ dùng cho ca giá trị cao, tần suất thấp.
  • Reflection hời hợt. Hỏi "bản này ổn chưa?" thường nhận lại "ổn rồi" vô nghĩa. Đưa checklist phản biện cụ thể.
  • Mẹo kết hợp: các pattern không loại trừ nhau. Một agent thực tế thường là ReAct (để dùng tool) + CoT bên trong mỗi Thought (để suy luận tốt hơn) + Reflection ở bước cuối (để kiểm tra trước khi chốt). Hãy nghĩ chúng như các lego ghép được.
  • Mẹo chi phí: với CoT làm độ trễ tăng, cân nhắc dùng mô hình nhỏ/nhanh cho phần suy luận và mô hình lớn cho bước chốt, hoặc ngược lại — đo để biết.

Bài tập thực hành

  • Thiết kế ReAct cho một use case Việt Nam. Chọn một tình huống (ví dụ: trợ lý đặt vé xe khách tra cứu chuyến và giá real-time). Liệt kê 2–3 tool cần thiết với tên, mô tả, tham số. Viết tay một vòng lặp Thought/Action/Observation mẫu, bao gồm nhánh xử lý khi tool không tìm thấy chuyến.
  • So sánh CoT và non-CoT. Lấy 5 bài toán suy luận (toán đố, logic điều kiện). Chạy mỗi bài hai lần — một lần prompt thường, một lần thêm "suy nghĩ từng bước". Ghi lại số bài đúng và số token mỗi cách. Rút ra kết luận về đánh đổi.
  • Viết prompt Reflection có checklist. Lấy một đoạn văn bản marketing do AI sinh. Viết một prompt phản biện với ít nhất 4 tiêu chí cụ thể, kiểm tra được. Chạy và so sánh bản gốc với bản sau khi phản tỉnh.
  • Thử nghiệm Self-Consistency. Chọn một bài phân loại có đáp án mơ hồ. Chạy 5 lần ở temperature 0.7, ghi lại các nhãn. Phân tích: phiếu có hội tụ không? Mức phân tán nói gì về độ khó của ca này?

Tóm tắt

Advanced prompt patterns là bước nhảy từ "viết lệnh cho AI" sang "thiết kế quy trình tư duy cho AI". Bốn pattern cốt lõi: Chain-of-Thought buộc mô hình suy luận từng bước để giảm sai ở bài toán phức tạp; ReAct xen kẽ suy nghĩ và hành động, cho mô hình dùng tool để truy cập dữ liệu thật thay vì bịa; Self-Consistency chạy nhiều lần rồi bỏ phiếu để tăng độ ổn định cho các ca giá trị cao; Reflection để mô hình tự phản biện và sửa lỗi trước khi chốt. Nguyên tắc vàng cho một AI PM: bắt đầu từ pattern đơn giản nhất, chỉ leo thang khi cần, luôn cân nhắc đánh đổi giữa chất lượng — chi phí — độ trễ, và quyết định dựa trên một bộ test có số liệu. Các pattern này ghép được với nhau và chính là nền móng cho Function Calling (Bài 16) và AI Agents (Bài 43) mà bạn sẽ học tiếp.

Trước Tiếp