5 mô hình chuỗi prompt giúp giải quyết các vấn đề thực tế

Vượt xa quy trình tuần tự: 5 mô hình cho công việc thực tế

Trong bài học trước, bạn đã xây dựng một chuỗi tuần tự — Bước 1 → Bước 2 → Bước 3. Mô hình này giải quyết được nhiều tác vụ, nhưng các vấn đề trong thực tế lại phức tạp hơn nhiều. Đôi khi bạn cần điều hướng sang các luồng xử lý khác nhau. Có lúc bạn cần thực hiện nhiều phân tích song song. Đôi khi bạn cần một vòng lặp để tinh chỉnh kết quả đầu ra cho đến khi đạt yêu cầu.

Đội ngũ kỹ thuật của Anthropic đã công bố 5 mô hình workflow đáp ứng phần lớn các nhu cầu tự động hóa bằng AI. Đây không phải là lý thuyết suông - chúng là các mô hình được áp dụng trong các hệ thống AI thực tế tại những công ty đang phát triển ứng dụng dựa trên Claude, GPT và các mô hình khác. Hãy cùng tìm hiểu từng mô hình.

Mô hình 1: Chuỗi (Quy trình tuần tự)

Bạn đã biết mô hình này rồi: Bước 1 chuyển dữ liệu sang Bước 2, rồi sang Bước 3. Tuy nhiên, điểm khác biệt giữa chuỗi dùng trong thực tế và chuỗi bạn đã xây dựng ở Bài học 3 chính là: các chốt kiểm soát chất lượng.

Một chuỗi quy trình thực tế không chuyển tiếp kết quả đầu ra một cách mù quáng. Nó sẽ kiểm tra kết quả trước khi thực hiện bước tiếp theo.

Ví dụ - Quy trình xuất bản nội dung:

• Bước 1: "Tạo dàn ý bài blog về [chủ đề]" - Chốt kiểm soát: Dàn ý có ít nhất 4 phần không? Có đề cập đến từ khóa mục tiêu không? Nếu không, hãy thực hiện lại Bước 1.
• Bước 2: "Viết bài hoàn chỉnh dựa trên dàn ý này: [kết quả Bước 1]" - Chốt kiểm soát: Bài viết có độ dài từ 800-1.500 từ không? Có chứa từ khóa trong đoạn đầu tiên không? Nếu không, hãy chỉnh sửa lại.
• Bước 3: "Viết mô tả meta (meta description) và nội dung đăng mạng xã hội cho bài viết này: [kết quả Bước 2]"

Các chốt kiểm soát giúp chuỗi quy trình trở nên đáng tin cậy. Nếu thiếu chúng, một dàn ý kém chất lượng sẽ dẫn đến bài viết kém chất lượng và bản tóm tắt cũng kém chất lượng - các lỗi sẽ tích tụ và trầm trọng hơn. Với các chốt kiểm soát, bạn có thể phát hiện vấn đề trước khi chúng gây ra hậu quả dây chuyền.

Mô hình 2: Điều hướng (Phân loại → Luồng xử lý chuyên biệt)

Mô hình điều hướng sử dụng bước đầu tiên để phân loại dữ liệu đầu vào, sau đó chuyển dữ liệu đó sang luồng xử lý chuyên biệt phù hợp. Nó giống như hệ thống menu tổng đài điện thoại: "Nhấn phím 1 để gặp bộ phận thanh toán, phím 2 để được hỗ trợ kỹ thuật."

Ví dụ - Xử lý tài liệu:

• Bước 1 (Phân loại): "Đây là loại tài liệu nào? Các danh mục: hóa đơn, hợp đồng, báo cáo, thư từ, khác."
  • Nếu là hóa đơn → "Trích xuất: nhà cung cấp, số tiền, ngày tháng, các hạng mục chi tiết, điều khoản thanh toán"
  • Nếu là hợp đồng → "Trích xuất: các bên tham gia, điều khoản chính, nghĩa vụ, ngày tháng, điều khoản chấm dứt"
  • Nếu là báo cáo → "Tóm tắt: các phát hiện chính, khuyến nghị, các điểm dữ liệu"
  • Nếu là thư từ → "Xác định: ý định của người gửi, hành động cần thiết, giọng điệu, mức độ khẩn cấp"

Tại sao cách này ưu việt hơn so với việc dùng một câu lệnh (prompt) duy nhất? 

Mỗi luồng xử lý chuyên biệt đều sử dụng từ vựng và mô hình trích xuất được thiết kế riêng cho loại tài liệu đó. Câu lệnh trích xuất hợp đồng sẽ biết tìm kiếm các cụm từ như "bên thứ nhất" và "bồi thường". Câu lệnh xử lý hóa đơn sẽ biết tìm kiếm các thông tin như "thanh toán trong vòng 30 ngày" và "số đơn đặt hàng". Một câu lệnh chung chung kiểu "trích xuất thông tin quan trọng" sẽ bỏ sót những chi tiết tinh tế này.

Khi nào nên sử dụng phương pháp điều hướng?

Khi tác vụ của bạn bao gồm các danh mục riêng biệt đòi hỏi cách xử lý khác nhau. Ví dụ: hỗ trợ khách hàng, xử lý tài liệu, kiểm duyệt nội dung, hệ thống đa ngôn ngữ - bất kỳ trường hợp nào mà việc phân loại sẽ quyết định phương pháp xử lý phù hợp.

Mô hình 3: Xử lý song song (Phân tách rồi hợp nhất)

Gửi cùng một dữ liệu đầu vào tới nhiều câu lệnh cùng lúc. Mỗi câu lệnh sẽ phân tích dữ liệu đó từ một góc độ khác nhau. Bước cuối cùng sẽ tổng hợp các kết quả lại.

Ví dụ - Đánh giá hồ sơ ứng tuyển:

• Phân tách (cả ba câu lệnh cùng chạy trên một bản sơ yếu lý lịch):
  • Câu lệnh A: "Đánh giá kỹ năng chuyên môn của ứng viên. Liệt kê các điểm mạnh và những điểm còn thiếu hụt."
  • Câu lệnh B: "Đánh giá mức độ phù hợp về kinh nghiệm của ứng viên đối với vị trí này: [mô tả công việc]"
  • Câu lệnh C: "Đánh giá chất lượng giao tiếp, các dấu hiệu cảnh báo và các tín hiệu về văn hóa qua phong cách viết của họ"
• Hợp nhất: "Tổng hợp ba đánh giá này thành một bản nhận xét ứng viên duy nhất kèm theo khuyến nghị: [kết quả từ A + B + C]"

Mỗi câu lệnh tập trung vào một khía cạnh cụ thể, do đó nó đi sâu hơn so với việc dùng một câu lệnh duy nhất để đánh giá mọi thứ cùng lúc. Và vì ba quá trình phân tích diễn ra độc lập, chúng không gây ảnh hưởng hay thiên kiến ​​lẫn nhau - việc đánh giá văn hóa ở Câu lệnh C không bị chi phối bởi việc Câu lệnh A có tìm thấy kỹ năng chuyên môn tốt hay không.

Khi nào nên sử dụng xử lý song song?

Khi bạn cần nhiều góc nhìn hoặc các phân tích độc lập. Ví dụ: báo cáo nghiên cứu, kiểm duyệt nội dung, đánh giá rủi ro, phân tích đối thủ cạnh tranh - những tác vụ mà việc nhìn nhận từ các góc độ khác nhau sẽ mang lại những hiểu biết sâu sắc khác nhau.

Mô hình 4: Orchestrator - Worker (Ủy quyền linh hoạt)

Một prompt đóng vai trò điều phối (orchestrator) sẽ xem xét nhiệm vụ, chia nhỏ nó thành các tác vụ con, giao từng phần cho một prompt chuyên trách (worker) thực hiện, và sau đó tổng hợp kết quả lại. Mô hình này giống như một người quản lý dự án phân công công việc cho các thành viên trong nhóm.

Điểm khác biệt so với phương pháp xử lý song song: Orchestrator sẽ quyết định các tác vụ con ngay trong quá trình thực thi (runtime) - chúng không được định sẵn hay lập trình cứng từ trước.

Ví dụ - Tạo báo cáo nghiên cứu:

• Orchestrator: "Tôi cần một báo cáo nghiên cứu về [chủ đề]. Tôi nên đề cập đến những chủ đề phụ nào? Hãy liệt kê 4-6 câu hỏi nghiên cứu cụ thể."  Kết quả đầu ra của orchestrator có thể là: quy mô thị trường, các đơn vị chủ chốt, xu hướng công nghệ, bối cảnh pháp lý, hoạt động đầu tư
  • Worker 1: "Nghiên cứu quy mô thị trường cho [chủ đề]. Bao gồm các số liệu, tốc độ tăng trưởng và dự báo."
  • Worker 2: "Xác định 5 đơn vị hàng đầu trong lĩnh vực [chủ đề]. Ghi chú thị phần và các điểm khác biệt chính của họ."
  • Worker 3: "Phân tích xu hướng công nghệ trong [chủ đề]. Những gì đang nổi lên? Những gì đang suy giảm?"
  • Worker 4: "Tóm tắt bối cảnh pháp lý cho [chủ đề]. Các quy định chính và những thay đổi sắp tới."
• Orchestrator (bước cuối cùng): "Kết hợp những phần này thành một báo cáo nghiên cứu hoàn chỉnh và mạch lạc: [tất cả kết quả từ các worker]"

Mô hình này rất hiệu quả đối với các nhiệm vụ mà bạn chưa biết rõ phạm vi đầy đủ ngay từ đầu. Orchestrator sẽ thích ứng với dữ liệu đầu vào cụ thể thay vì tuân theo một khuôn mẫu cứng nhắc.

Khi nào nên sử dụng mô hình orchestrator-worker? Các nhiệm vụ phức tạp mà những tác vụ con thay đổi tùy thuộc vào dữ liệu đầu vào. Ví dụ như nghiên cứu, phân tích phức tạp, tạo tài liệu gồm nhiều phần - bất kỳ trường hợp nào mà một người quản lý dự án cần phải "xác định phạm vi công việc trước tiên".

Mô hình 5: Evaluator - Optimizer (Vòng lặp đánh giá - tối ưu hóa)

Hai prompt hoạt động theo chu trình: Một prompt tạo hoặc chỉnh sửa nội dung, prompt còn lại thực hiện đánh giá nội dung đó. Vòng lặp này tiếp diễn cho đến khi evaluator xác nhận kết quả đã "đạt yêu cầu".

Ví dụ - Tinh chỉnh email bán hàng:

• Generator: "Viết email chào hàng gửi cho [khách hàng tiềm năng] về [sản phẩm]. Cá nhân hóa dựa trên: [thông tin khách hàng]"
• Evaluator: "Chấm điểm email này từ 1-10 dựa trên các tiêu chí: tính cá nhân hóa, độ rõ ràng, sức mạnh của lời kêu gọi hành động (CTA), và độ dài phù hợp. Liệt kê các điểm cần cải thiện cụ thể."
• Nếu điểm < 8 → Optimizer: "Chỉnh sửa email này dựa trên các nhận xét: [email + nhận xét]"
• Evaluator chấm điểm lại: "Chấm điểm email đã chỉnh sửa..."
• Lặp lại quy trình cho đến khi đạt điểm ≥ 8 hoặc hoàn tất 3 vòng lặp (tùy điều kiện nào đến trước).

Evaluator đóng vai trò như một tiêu chuẩn chất lượng. Thay vì hy vọng bản nháp đầu tiên đã đủ tốt, bạn tích hợp bước kiểm tra chất lượng ngay vào workflow.

Chi tiết quan trọng: Luôn đặt giới hạn số lần lặp lại. Nếu không có giới hạn, một evaluator quá khắt khe có thể tạo ra vòng lặp vô tận. Thông thường, hai đến ba vòng chỉnh sửa sẽ mang lại 90% hiệu quả cải thiện; sau đó, lợi ích thu được sẽ giảm dần.

Khi nào nên sử dụng mô hình Evaluator - Optimizer? 

Đối với bất kỳ sản phẩm sáng tạo hoặc phân tích nào có thể đo lường được chất lượng - ví dụ như viết nội dung, lập trình, dịch thuật, hay tóm tắt phân tích dữ liệu. Mô hình này đặc biệt hữu ích khi bạn có thể xác định các tiêu chí chấm điểm rõ ràng.

Kết hợp các mô hình

5 mô hình này không loại trừ lẫn nhau. Các quy trình thực tế thường kết hợp chúng lại:

• Một hệ thống hỗ trợ khách hàng có thể sử dụng cơ chế điều hướng (routing) để phân loại vấn đề, sau đó dùng cơ chế chuỗi (chaining) để xử lý, kết hợp với vòng lặp đánh giá - tối ưu hóa để hoàn thiện phản hồi cuối cùng.
• Một quy trình nghiên cứu có thể sử dụng Orchestrator để lập kế hoạch, cơ chế xử lý song song (parallelization) cho quá trình nghiên cứu thực tế, và cơ chế chuỗi để tổng hợp và định dạng báo cáo.

Hãy bắt đầu với một mô hình duy nhất và đảm bảo nó hoạt động trơn tru. Sau đó, mới bổ sung thêm các mô hình khác khi chất lượng đầu ra đòi hỏi điều đó. Lời khuyên của Anthropic - "bắt đầu đơn giản và chỉ thêm sự phức tạp khi cần thiết" - hoàn toàn phù hợp trong trường hợp này.

Hãy thử ngay: Xây dựng chuỗi điều hướng

Điều hướng (routing) là mô hình nhanh nhất để bạn thấy kết quả thực tế. Hãy cùng xây dựng một bộ điều hướng phản hồi khách hàng. Hãy mở ChatGPT, Claude hoặc Gemini. Đây là chuỗi gồm 2 tin nhắn.

Tin nhắn 1 (Phân loại - điều hướng)

Cách sao chép câu lệnh (prompt) này: Nhấp vào bất kỳ đâu trong khối màu xám, nhấn Cmd+A rồi Cmd+C (trên Mac) hoặc Ctrl+A rồi Ctrl+C (trên Windows). Hoặc sử dụng biểu tượng sao chép xuất hiện.

Bạn là chuyên gia phân loại phản hồi khách hàng. Hãy đọc tin nhắn dưới đây và đưa ra MỘT nhãn phân loại, kèm theo mức độ khẩn cấp.

Các nhãn (chọn chính xác một nhãn):
- BUG — có lỗi xảy ra với sản phẩm
- FEATURE_REQUEST — yêu cầu tính năng mới
- QUESTION — cần giải đáp cách thực hiện/sử dụng
- COMPLAINT — bày tỏ sự bức xúc, có thể cần sự thấu cảm trước tiên
- PRAISE — phản hồi tích cực, mức độ khẩn cấp thấp
- BILLING — vấn đề về thanh toán/gói đăng ký

Mức độ khẩn cấp: HIGH (ảnh hưởng đến khả năng sử dụng sản phẩm ngay lúc này) / MEDIUM / LOW.

Định dạng đầu ra CHÍNH XÁC như sau:
LABEL: [một trong 6 nhãn trên]
URGENCY: [HIGH/MEDIUM/LOW]
ONE-LINE REASON: [1 câu giải thích]

Tin nhắn của khách hàng:
"""
[DÁN TIN NHẮN THỰC TẾ CỦA KHÁCH HÀNG — từ hàng đợi hỗ trợ, đánh giá ứng dụng, tweet gửi công ty, v.v.]
"""

Kết quả: Chỉ trong vài giây, AI sẽ trả về phản hồi có cấu trúc dựa trên câu lệnh trên. Hãy đọc kỹ và coi đó là bản nháp, không phải câu trả lời cuối cùng.

Tin nhắn 2 (Bộ xử lý chuyên biệt - chọn nội dung phù hợp với nhãn từ Tin nhắn 1)

Nếu là BUG (Lỗi):

Hãy đóng vai kỹ sư hỗ trợ cấp cao. Soạn thảo phản hồi cho báo cáo lỗi này:

"""
[DÁN TIN NHẮN GỐC CỦA KHÁCH HÀNG]
"""

Phân loại: BUG, ​​mức độ khẩn cấp [từ Tin nhắn 1]

Bao gồm:
1. Một câu ghi nhận sự bức xúc của họ (không xin lỗi quá đà).
2. 3 câu hỏi chẩn đoán cần thiết để tái hiện lỗi.
3. Giải pháp tạm thời nếu có cho loại lỗi này.
4. Quy trình chuyển tiếp lên cấp cao hơn nếu mức độ khẩn cấp là HIGH.
5. Giọng văn: trực diện, mang tính kỹ thuật, tôn trọng thời gian của khách hàng.

Nếu là YÊU CẦU TÍNH NĂNG (FEATURE_REQUEST):

Đóng vai trò quản lý sản phẩm. Soạn thảo phản hồi cho yêu cầu tính năng này:

"""
[DÁN NỘI DUNG TIN NHẮN GỐC CỦA KHÁCH HÀNG]
"""

Bao gồm:
1. Cảm ơn ngắn gọn.
2. Nhắc lại kết quả/mục tiêu mà họ muốn đạt được (không chỉ là tính năng họ đã yêu cầu).
3. 2 giải pháp thay thế hiện có trong sản phẩm có thể giải quyết một phần vấn đề (hoặc nêu rõ "hiện chưa có giải pháp nào tương tự").
4. Liệu chúng tôi có cân nhắc ưu tiên việc này không, kèm theo mốc thời gian dự kiến ​​trung thực (hoặc "chưa có kế hoạch trong tương lai gần").
5. Đặt một câu hỏi làm rõ để giúp chúng tôi đánh giá nhu cầu.

Nếu là KHIẾU NẠI (COMPLAINT):

Đóng vai trò quản lý cấp cao bộ phận Chăm sóc khách hàng (CS). Soạn thảo phản hồi cho khiếu nại này:

"""
[DÁN NỘI DUNG TIN NHẮN GỐC CỦA KHÁCH HÀNG]
"""

Bao gồm:
1. Câu thể hiện sự thấu cảm ngay ĐẦU TIÊN — thừa nhận cụ thể sự bức xúc của họ (nhắc lại vấn đề họ đã nêu).
2. Tóm tắt ngắn gọn những gì chúng tôi đã nắm được.
3. Hành động cụ thể tiếp theo kèm mốc thời gian thực tế.
4. Thể hiện trách nhiệm cá nhân — không dùng câu xin lỗi sáo rỗng kiểu "chúng tôi xin lỗi", mà hãy nói "Tôi sẽ đích thân theo dõi vấn đề này và phản hồi lại vào lúc [thời gian]."
5. Giọng điệu: gần gũi, không phòng thủ, tập trung vào kết quả.

(Có các câu lệnh xử lý tương tự cho các trường hợp CÂU HỎI, LỜI KHEN NGỢI, VẤN ĐỀ THANH TOÁN — hãy làm theo cấu trúc tương tự).

Cách điền thông tin chi tiết: Thay thế các phần trong ngoặc vuông [] bằng thông tin cụ thể từ tình huống thực tế của bạn. Đầu vào mơ hồ sẽ tạo ra kết quả mơ hồ - hãy đưa ra thông tin cụ thể.

Kết quả bạn sẽ nhận được: Một phản hồi chuyên biệt, sắc bén và hiệu quả hơn nhiều so với việc chỉ dùng một câu lệnh chung chung như "soạn thư trả lời khách hàng này". Mỗi câu lệnh xử lý chuyên biệt đều hiểu rõ thuật ngữ và các ưu tiên của từng loại tình huống - báo cáo lỗi cần câu hỏi về cách tái hiện lỗi, khiếu nại cần sự thấu cảm trước tiên, còn yêu cầu tính năng cần sự thấu hiểu về nhu cầu cốt lõi.

Cách xử lý kết quả: Lưu phản hồi vào file Notes. Chọn ra một đề xuất mang lại hiệu quả cao nhất và thực hiện ngay trong tuần này - đừng cố gắng làm tất cả mọi thứ cùng lúc.

Nếu kết quả chưa phù hợp: Nếu các đề xuất có vẻ quá chung chung, hãy dán thêm câu lệnh này: "Hãy đưa ra phản hồi cụ thể hơn dựa trên bối cảnh thực tế của tôi. Bỏ qua những lời khuyên chung chung". Nếu hệ thống bỏ qua các chi tiết quan trọng mà bạn đã cung cấp, hãy thêm yêu cầu: "Bạn đã bỏ sót [X] trong bối cảnh tôi đưa ra - hãy thực hiện lại với [X] là yêu cầu bắt buộc hàng đầu".

Khi nào nên áp dụng phương pháp tổng quát này? 

Đối với bất kỳ luồng dữ liệu đầu vào lớn nào (yêu cầu hỗ trợ, khách hàng tiềm năng, phản hồi của người dùng, kết quả khảo sát). Bước phân loại hầu như không tốn chi phí nhưng lại giúp cải thiện hiệu quả của mọi câu lệnh (prompt) ở các bước xử lý tiếp theo. Đây chính là Mô hình 2 (định tuyến/routing) đã đề cập ở trên, và là quy trình chuỗi mang lại hiệu quả cao nhất mà hầu hết các nhóm nên bổ sung vào workflow của mình.

Những điểm chính cần lưu ý

• 5 mô hình đáp ứng hầu hết các nhu cầu tự động hóa bằng AI: Chuỗi (chaining), định tuyến (routing), xử lý song song (parallelization), điều phối-thực thi (orchestrator-workers), và đánh giá-tối ưu hóa (evaluator-optimizer)
• Việc kết hợp chuỗi xử lý kèm các chốt kiểm soát chất lượng giúp phát hiện lỗi trước khi chúng lan rộng trong toàn bộ quy trình
• Định tuyến sử dụng cơ chế phân loại để chuyển dữ liệu đầu vào đến các bộ phận xử lý chuyên biệt - hiệu quả hơn so với việc dùng một câu lệnh chung cho mọi trường hợp
• Xử lý song song giúp thu thập nhiều góc nhìn độc lập mà không để chúng gây ảnh hưởng hay thiên kiến ​​lẫn nhau
• Mô hình điều phối-thực thi cho phép AI tự xác định các tác vụ con trong quá trình vận hành - linh hoạt nhưng khó kiểm soát hơn
• Mô hình đánh giá-tối ưu hóa tạo ra vòng lặp phản hồi dựa trên tiêu chuẩn chất lượng có thể đo lường được - hãy luôn thiết lập giới hạn số lần lặp lại
• Có thể kết hợp các mô hình tùy theo nhu cầu, nhưng hãy bắt đầu với quy trình đơn giản