Prompt chaining: chia việc thành từng bước để AI dễ làm đúng

Huy đưa một trăm phản hồi khách hàng cho AI rồi nhờ phân loại, tìm vấn đề và viết báo cáo. Bản trả về trông gọn, nhưng một phản hồi về giao nhầm hàng lại nằm trong nhóm giao chậm. Huy sửa đoạn nhận xét, chạy lại, rồi phát hiện số lượng các nhóm cũng đổi. Trong ví dụ này, anh đang giao nhiều việc liên quan trong một lượt và khó biết lỗi bắt đầu ở đâu.

Prompt chaining là chia công việc thành các bước nối tiếp, dùng kết quả của bước trước cho bước sau. Cách làm này cho bạn chỗ kiểm tra giữa đường. Nó có thể hữu ích khi một nhiệm vụ gồm những phần tách được rõ ràng, nhưng không tự đảm bảo mọi kết quả đều đúng.

Chia việc trước khi chia lời nhắc

Huy chưa vội viết thêm prompt. Anh ghi lại việc mình thực sự cần làm: đọc từng phản hồi, gắn nhóm, kiểm số lượng và viết phần nhận xét. Nếu chưa rõ các bước này, chia một yêu cầu dài thành nhiều tin nhắn vẫn có thể giữ nguyên sự mơ hồ ban đầu.

Mỗi bước cần một đầu ra có thể kiểm. “Hiểu khách hàng hơn” còn rộng. “Gắn một nhóm chính cho từng phản hồi, giữ nguyên mã phản hồi” thì rõ hơn. Huy có thể so kết quả với dữ liệu gốc và tìm đúng dòng sai mà không đọc lại toàn bộ báo cáo.

Trong hướng dẫn về các cách xây dựng quy trình AI, Anthropic mô tả prompt chaining như chuỗi bước có thể kiểm tra kết quả trung gian. Với ví dụ của Huy, điểm đáng dùng là nhìn thấy từng đầu ra trước khi chuyển tiếp, thay vì chỉ nhận một bản cuối.

Phân biệt bước cần AI với bước có thể tính bằng công cụ thông thường. Đếm số phản hồi theo nhóm không nhất thiết cần một lượt sinh văn bản khác. Nếu đã có bảng phân loại, dùng phép đếm rõ ràng sẽ dễ kiểm hơn. AI có thể hỗ trợ diễn đạt nhận xét sau khi số liệu đã được đối chiếu.

Một chuỗi mẫu cho báo cáo phản hồi

Bước đầu, Huy chuẩn bị dữ liệu mẫu đã bỏ thông tin riêng không cần thiết. Mỗi phản hồi có một mã ổn định. Anh giữ nguyên lời khách trong một cột, không chỉnh cho câu văn đẹp hơn. Việc sửa câu trước khi phân loại có thể vô tình thay đổi ý nghĩa hoặc làm mất điều khách nhấn mạnh.

Prompt thứ nhất yêu cầu phân loại theo danh sách nhóm đã định nghĩa. Huy mô tả ngắn mỗi nhóm và thêm lựa chọn “chưa rõ” cho phản hồi thiếu thông tin. Anh không ép mọi dòng vào một nhóm chắc chắn, vì câu “lần này vẫn thế” không đủ ngữ cảnh để biết khách đang nói về chuyện gì.

Đầu ra có mã phản hồi, nhóm đề xuất và đoạn chữ hỗ trợ lựa chọn đó. Huy kiểm những dòng dễ nhầm, như giao chậm với giao nhầm. Nếu định nghĩa nhóm chưa rõ, anh sửa hướng dẫn rồi thử lại trên cùng dữ liệu. Không nên sửa tay một dòng rồi giả định cả chuỗi đã ổn.

Sau khi bảng phân loại được chấp nhận, công cụ tính số lượng từng nhóm. Tổng số dòng phải khớp với dữ liệu đưa vào, kể cả nhóm chưa rõ. Nếu thiếu mã hoặc xuất hiện mã lạ, quy trình dừng để kiểm. Một bảng thiếu vài phản hồi vẫn có thể tạo ra báo cáo rất trôi chảy nếu không có bước đối chiếu này.

Prompt cuối nhận số đã kiểm và một vài ví dụ đại diện. Huy yêu cầu viết điều quan sát được, nêu giới hạn và tách đề xuất khỏi kết luận. Báo cáo không được gọi một nhóm là “nguyên nhân chính” chỉ vì nhóm đó xuất hiện nhiều trong phần phản hồi đang có.

Nói rõ bước sau sẽ nhận thông tin gì

Mỗi bước cần hiểu dữ liệu được chuyển sang có nghĩa gì. Cột “số lượng” là số phản hồi hay số khách? Một người gửi hai phản hồi được tính thế nào? Những định nghĩa này nên nằm trong hướng dẫn chung hoặc đầu vào của bước liên quan, tránh để AI tự suy từ tên cột ngắn.

Đừng chuyển một đoạn văn dài nếu bước sau chỉ cần bảng đã kiểm. Huy giữ mã, nhóm, số lượng và ví dụ cần thiết. Các lời giải thích phụ được lưu để tra cứu, không nhất thiết đưa hết vào mọi bước. Đầu vào gọn và đúng việc sẽ dễ theo dõi hơn một lịch sử chat chứa nhiều lần sửa.

Nếu dùng định dạng cố định, kiểm xem đầu ra có tuân thủ không trước khi xử lý tiếp. Đúng cấu trúc chưa có nghĩa đúng nội dung, nhưng sai cấu trúc có thể khiến bước sau đọc nhầm. Huy kiểm cả mã hợp lệ lẫn giá trị nhóm trước khi đưa bảng vào phần tổng hợp.

Giữ đường quay lại nguồn gốc. Khi báo cáo nhắc tới một nhóm vấn đề, người xem cần mở được các phản hồi liên quan theo quyền được cấp. Cách chuẩn bị dữ liệu có cấu trúc giúp việc nối nguồn và kết quả rõ hơn, nhất là khi quy trình dùng lại nhiều lần.

Kiểm tra chuỗi như một quy trình

Huy thử các trường hợp bình thường, phản hồi nhiều ý, câu thiếu ngữ cảnh và dữ liệu trống. Anh ghi đầu ra mong đợi hoặc tiêu chí chấp nhận trước khi chạy. Nhờ vậy, việc đánh giá không chỉ dựa vào cảm giác bản trả lời đọc có vẻ hợp lý.

Kiểm từng bước và cả bản cuối. Một dòng phân loại sai có thể kéo theo số lượng sai rồi thành nhận xét sai. Ngược lại, bảng phân loại đúng vẫn có thể bị bước viết báo cáo diễn giải quá mức. Mỗi chỗ cần tiêu chí riêng, phù hợp với việc nó đang làm.

Ghi lại phiên bản hướng dẫn và dữ liệu thử. Sau khi sửa prompt, chạy lại các trường hợp cũ để xem lỗi đã được xử lý chưa và có lỗi mới không. Phần đánh giá AI trên nhiệm vụ cụ thể giúp xây một bộ kiểm tra có thể dùng lặp lại.

Với đầu ra cần người duyệt, đặt điểm dừng rõ trước hành động tiếp theo. Huy có thể xem bảng phân loại trước khi tạo báo cáo gửi nhóm. Nếu sau này có bước gửi tự động, việc chấp nhận nội dung cần được thiết kế riêng. Đừng coi một chuỗi sinh văn bản đã chạy được là đã đủ điều kiện thực hiện mọi hành động.

Khi nào chuỗi nhiều bước không đáng dùng?

Nếu chỉ cần sửa một email ngắn, một yêu cầu rõ có thể đã đủ. Chia thêm nhiều bước sẽ tăng thời gian chờ và công quản lý. Trước khi thêm bước, hỏi nó giúp kiểm lỗi nào hoặc cung cấp thông tin gì mà cách đơn giản đang thiếu.

Huy nên so chuỗi mới với cách làm cũ trên cùng bộ phản hồi. Ghi chất lượng, thời gian chờ, số lần phải sửa và công kiểm của con người. Không chỉ so thời gian AI tạo bản nháp. Một quy trình nhanh lúc chạy nhưng tốn nhiều công chữa vẫn chưa chắc đáng dùng.

Trong ví dụ này, chuỗi hữu ích khi Huy tìm được lỗi phân loại trước lúc nó thành kết luận trong báo cáo. Anh không cần làm quy trình dài nhất. Anh cần đủ bước để biết dữ liệu đi qua đâu, điều gì đã được kiểm và chỗ nào vẫn cần mình quyết định.