Các mô hình ngôn ngữ lớn thường lúng túng khi bạn yêu cầu chúng làm quá nhiều việc cùng một lúc. Hãy thử ném một tệp PDF dài năm mươi trang vào cửa sổ chat và yêu cầu một bản phân tích có cấu trúc, một bản đánh giá rủi ro và một bản tóm tắt điều hành trong cùng một lượt. Kết quả thường là nội dung sơ sài, mơ hồ hoặc sai hoàn toàn. Một cách tiếp cận tốt hơn mang tính cơ học hơn: Chia nhỏ công việc thành các giai đoạn riêng biệt. Đưa đầu ra của giai đoạn đầu tiên trực tiếp vào giai đoạn thứ hai, và cứ tiếp tục như vậy. Anthropic gọi mô hình này là prompt chaining. Google gọi đó là một sequential pipeline. Cả hai cái tên đều mô tả cùng một thứ: một dây chuyền lắp ráp, nơi mỗi trạm xử lý một bước biến đổi cụ thể.
Cách thức hoạt động trong thực tế
Thay vì một prompt khổng lồ, bạn xây dựng một chuỗi các bước nhỏ và tập trung. Hãy hình dung một đội ngũ tuân thủ đang xử lý các bản đánh giá bảo mật của nhà cung cấp. Bước một: trích xuất văn bản thô từ một tệp PDF đã quét. Bước hai: xác định mọi đề cập đến các tiêu chuẩn mã hóa và kiểm soát truy cập. Bước ba: đối chiếu các phát hiện đó với một danh sách kiểm tra nội bộ. Bước bốn: soạn một bản ghi nhớ ngắn cho trưởng bộ phận bảo mật. Một agent chuyển đổi PDF thành văn bản. Agent tiếp theo trích xuất dữ liệu cụ thể từ văn bản đó. Agent cuối cùng viết bản tóm tắt dựa trên dữ liệu đó. Không có bước nào trong số này là hào nhoáng, và không có bước nào làm đa nhiệm. Mỗi phần chỉ làm tốt một việc duy nhất.
Đây là lý do tại sao phép ẩn dụ về dây chuyền lắp ráp lại rất hợp lý. Trong một nhà máy, một công nhân không lắp ráp toàn bộ chiếc xe. Sự chuyên môn hóa giúp duy trì chất lượng cao và thu hẹp các lỗi có thể xảy ra. Logic tương tự cũng áp dụng cho các mô hình ngôn ngữ. Một prompt chỉ yêu cầu trích xuất JSON sẽ ít có khả năng xảy ra hiện tượng ảo giác (hallucinate) hơn là một prompt vừa yêu cầu trích xuất, vừa yêu cầu đưa ra ý kiến và định dạng trong cùng một yêu cầu.
Xây dựng các "cổng kiểm soát", đừng dựa vào phỏng đoán
Điểm yếu nhất trong bất kỳ chuỗi nào là bước chuyển giao. Một mô hình có thể trả về một lời từ chối lịch sự, một đoạn markdown thay vì JSON, hoặc một phản hồi bị cắt cụt. Nếu đống dữ liệu rác đó chảy vào bước hai, toàn bộ chuỗi sẽ sụp đổ. Giải pháp chính là một "cổng kiểm soát" (gate).
Một "gate" không phải là một lệnh gọi mô hình. Nó là mã code đơn giản. Bạn viết một đoạn script ngắn chạy giữa các bước. Nó có thể kiểm tra độ dài của đầu ra để đảm bảo không bị trống. Nó có thể chạy xác thực JSON schema để xác nhận các key khớp với những gì bước ba mong đợi. Một lệnh kiểm tra regex có thể xác minh xem địa chỉ email hoặc trường ngày tháng có thực sự hiện diện hay không trước khi prompt tiếp theo được xây dựng. Điều này giúp ngăn chặn lỗi trước khi bạn lãng phí tiền bạc vào các đầu ra kém chất lượng. Một "gate" chỉ tốn vài micro giây tính toán. Một lệnh gọi LLM thất bại ở các bước sau sẽ tiêu tốn token, độ trễ và cả sự kiên nhẫn của bạn.
Hãy coi nó như một điểm kiểm tra chất lượng trên sàn nhà máy. Bạn không cần AI để đếm các linh kiện. Bạn cần một cây thước.
Khi nào nên dùng chuỗi, và khi nào nên dừng lại
Prompt chaining không phù hợp cho mọi vấn đề. Hãy sử dụng nó khi công việc có các bước cố định và có thể lặp lại. Các báo cáo tài chính hàng tháng, đánh giá hợp đồng tiêu chuẩn và các quy trình phân tích nhật ký (log analysis) là những ví dụ điển hình. Nếu bạn có thể viết quy trình dưới dạng một danh sách kiểm tra, bạn có thể áp dụng prompt chaining. Bạn cũng nên sử dụng phương pháp này khi cần độ chính xác cao cho các công việc phức tạp. Việc chia nhỏ một vấn đề thành các giai đoạn buộc mô hình phải xử lý từng lớp logic một tại một thời điểm. Cuối cùng, các chuỗi (chains) dễ gỡ lỗi hơn so với các prompt nguyên khối. Khi bản tóm tắt bị sai, bạn kiểm tra phần trích xuất. Khi phần trích xuất bị sai, bạn kiểm tra văn bản nguồn. Bạn có các kết quả trung gian để kiểm tra.
Tránh prompt chaining khi bạn không biết trước các bước thực hiện. Nghiên cứu khám phá, động não (brainstorming) mở hoặc các nhiệm vụ điều tra không đi theo một đường thẳng. Cũng hãy bỏ qua nó nếu tốc độ là ưu tiên duy nhất của bạn. Các chuỗi có tính tuần tự; bước hai không thể bắt đầu cho đến khi bước một kết thúc. Nếu các bước của bạn không phụ thuộc vào nhau, hãy chạy chúng song song thay vì nối chuỗi. Không có lý do gì để nối chuỗi ba bản dịch độc lập của cùng một tài liệu.
Cái bẫy của sự cứng nhắc
Sự đánh đổi cho tất cả cấu trúc này là sự cứng nhắc. Một chuỗi cố định không thể thích nghi với các tình huống mới. Nếu một nhà cung cấp gửi một biểu mẫu có sáu trường dữ liệu trong khi cổng xác thực schema của bạn mong đợi năm trường, dây chuyền sẽ dừng lại. Nếu người dùng tải lên một tài liệu Word thay vì PDF, bước đầu tiên sẽ bị lỗi và phần còn lại của chuỗi sẽ không có gì để xử lý.
Tệ hơn nữa, các lỗi sẽ lan truyền. Một sai sót xảy ra sớm sẽ chảy qua toàn bộ chuỗi. Nếu trình trích xuất PDF làm mất dấu âm của một con số tài chính, mọi bước tiếp theo sẽ coi con số sai đó là