Deploy prompt bằng một label, và vì sao rollback có thể mất tới một phút

Thử hình dung: bạn vừa chuyển label production về phiên bản prompt cũ để dập một sự cố. Trong khoảng thời gian có thể kéo dài tới một phút sau đó, một phần instance đang chạy vẫn trả lời khách bằng prompt lỗi, vì SDK của Langfuse cache prompt phía client với TTL mặc định 60 giây. Rollback đã xong trên dashboard, nhưng chưa chắc đã xong với khách hàng.

Khoảng vênh ấy cho thấy vấn đề lớn hơn. Prompt trong production không phải một đoạn text bạn sửa rồi lưu. Nó là một artifact có vòng đời deploy đầy đủ: versioning, test, promote, rollback, và cả độ trễ lan truyền.

Nếu công việc của bạn là chỉnh hệ thống LLM ngay tại site khách hàng, đây là kỷ luật nên có trước khi sự cố đầu tiên xảy ra, chứ không phải sau. Để thấy rõ, hãy theo một ca giả định từ đầu đến cuối.

Deploy là chuyển một con trỏ

Giả sử bạn đang vận hành một agent phân loại ticket hỗ trợ cho một khách hàng. Khách báo agent xếp nhầm các ticket khiếu nại hoàn tiền sang nhóm “hỏi thông tin”. Bạn sửa prompt, thêm một đoạn hướng dẫn về khiếu nại tài chính. Trong Langfuse, thao tác đó tạo ra một version mới, và label latest tự động trỏ tới nó.

Nhưng latest không phải production. Khi code gọi prompt mà không chỉ định label, Langfuse trả về phiên bản mang label production. Hai con trỏ tách nhau là có chủ đích: bạn tạo bao nhiêu version thử nghiệm tùy thích mà khách không thấy gì, cho đến khi bạn chủ động chuyển production sang bản mới.

Tài liệu kỹ thuật của Langfuse về quản lý hàng trăm prompt gói mô hình này trong một câu: chuyển label chính là deploy, rollback là chuyển ngược lại. Không build, không release, code không đổi. Thứ di chuyển chỉ là con trỏ.

Khi deploy chỉ còn là một cú chuyển con trỏ, câu hỏi tiếp theo là ai được phép chuyển nó. Langfuse có protected label, tùy gói: khi đã bảo vệ, vai trò viewer và member không thể di chuyển hay xóa label đó. Với gói Enterprise, audit log ghi lại các thao tác promote và set label.

Trong ca trên, nếu label production đã được bảo vệ và đồng nghiệp bên phía khách chỉ mang vai trò viewer hoặc member, họ không thể tự chuyển label để đẩy một bản “sửa thử” ra production.

Con trỏ chỉ được di chuyển sau khi eval pass

Quay lại bản sửa của bạn. Trước khi chuyển label, câu hỏi phải là: bản này tốt hơn bản cũ ở đâu, và có làm hỏng chỗ nào không? Braintrust khuyên eval tự động nên chạy trên mọi pull request có sửa prompt.

TianPan, trong bài về kỷ luật versioning prompt, đi xa hơn một nấc: mọi PR chạm vào file prompt kích hoạt eval tự động, và eval fail thì chặn merge.

Hãy coi đây là unit test cho prompt. Và như unit test, chất lượng nằm ở test case. Tài liệu Anthropic về xây eval khuyên thiết kế test sát phân phối tác vụ thực tế và đừng quên edge case.

Với agent phân loại ticket, bộ eval nên có đúng tỷ lệ ticket khiếu nại, hỏi thông tin, lỗi kỹ thuật như khách thực sự nhận, cộng thêm những ca khó: ticket viết lẫn tiếng Anh, ticket vừa hỏi vừa khiếu nại.

Bản sửa “thêm hướng dẫn về khiếu nại tài chính” có thể kéo điểm khiếu nại lên nhưng khiến agent bắt đầu xếp câu hỏi về phí vận chuyển thành khiếu nại. Chỉ eval trên phân phối thật mới bắt được chuyện đó trước khi khách bắt được.

Rollback là kịch bản đã tập, không phải ứng biến

Giả sử eval pass và bạn chuyển production. Hai ngày sau, khách báo một lỗi mới mà bộ eval chưa có. Đây là lúc câu của TianPan trở nên cụ thể: rollback phải là thao tác được lên kế hoạch trước, không phải xoay xở lúc sự cố. Braintrust mô tả cùng ý từ góc traffic: revert nghĩa là đưa traffic về phiên bản tốt gần nhất.

“Lên kế hoạch trước” trong ca này gồm ba việc. Bạn biết chính xác version nào là last known good, không phải “bản tuần trước hình như ổn”. Bạn biết ai có quyền chuyển label và thao tác gồm những gì: với Langfuse là gắn lại label production cho version cũ, không cần deploy lại code.

Và bạn biết độ trễ: với cache mặc định 60 giây, bạn nói với khách “trong vòng một phút” chứ không phải “ngay lập tức”.

Rồi quay lại bước test. Lỗi mới mà khách báo phải thành test case trong bộ eval, để lần sau con trỏ không được di chuyển nếu lỗi tái phát. Vòng lặp khép lại ở đó, và mỗi sự cố làm bộ eval dày thêm thay vì chỉ làm bạn mệt thêm.

Kể lại ca ticket trên CV như thế nào?

Nếu bạn đang chuẩn bị cho vị trí FDE, ca agent phân loại ticket ở trên chính là cách kể trên CV và trong phỏng vấn.

Đừng viết “có kinh nghiệm prompt engineering”; hãy kể bạn sửa prompt cho lỗi xếp nhầm khiếu nại hoàn tiền ra sao, bộ eval nào chặn bản sửa làm hỏng ticket phí vận chuyển, ai được chuyển label production, và rollback có hiệu lực trong bao lâu.

Khi đọc job description, các cụm như prompt management, eval pipeline hay observability là tín hiệu để đem đúng câu chuyện đó ra. Một ca rollback cụ thể, dù chỉ từ side project, có sức nặng hơn mọi lời về “tối ưu prompt”.

Khách hàng không nhìn thấy version của bạn. Họ chỉ thấy con trỏ production đang trỏ vào đâu, và bạn mất bao lâu để chuyển nó về chỗ an toàn.