Khi bạn kết nối một mô hình ngôn ngữ lớn vào một quy trình làm việc cần con người xác nhận qua email, mô hình hiếm khi là nguyên nhân gây ra lỗi. Lỗi xảy ra ở nơi mã nguồn kết thúc và hộp thư đến bắt đầu. Một lượt chạy tự động gửi đi một yêu cầu. Sau đó, một lượt chạy khác bắt đầu trước khi lượt đầu tiên hoàn tất. Một hộp thư chung thu thập các luồng thư từ các tiến trình khác nhau. Ai đó nhấn phê duyệt một tin nhắn đến trễ mười hai tiếng. Giờ đây bạn có kết quả đầu ra. Bạn có một quyết định. Nhưng bạn không thể chứng minh lượt chạy nào đã tạo ra cái gì, hoặc liệu sự phê duyệt đó có thực sự dành cho lần tạo này hay không. Tôi đã dọn dẹp đủ nhiều các đường ống tự động hóa nội bộ để biết được mô hình này. Nó leo thang từ sự nhầm lẫn thành sự cố nhanh hơn hầu hết các đội ngũ mong đợi.

Ranh giới Vận hành

Ranh giới giữa bộ điều phối (orchestrator) và nhà cung cấp email của bạn không chỉ là một bước nhảy mạng (network hop). Đó là một ranh giới về trạng thái. Khi LLM hoàn tất việc tạo bản thảo, lượt chạy vẫn đang tồn tại. Nó đang chờ đợi. Nếu hệ thống của bạn coi việc gửi đi là một sự kiện "gửi rồi quên" (fire-and-forget), bạn đã đánh mất sự liên kết ngay từ đầu.

Tôi đã thấy các đường ống mà một lượt chạy duy nhất tạo ra hai yêu cầu phê duyệt riêng biệt vì chính sách thử lại (retry policy) quá quyết liệt. Tôi đã thấy một lượt chạy khác sử dụng lại một hộp thư vẫn còn chứa các tin nhắn từ tuần trước. Người phê duyệt không nhìn thấy các ID lượt chạy (run IDs). Họ chỉ thấy dòng tiêu đề và một nút bấm. Nếu không có cấu trúc, họ đang phải đoán mò trong cùng một hộp thư nơi chứa cả bản tin tiếp thị và các cảnh báo giám sát.

Bước bị bỏ qua

Các đội ngũ sẽ dành hàng tuần để tinh chỉnh câu lệnh (prompts), thêm các rào chắn (guardrails) và đánh giá hiệu suất đầu ra. Sau đó, họ kết nối bước phê duyệt với một kênh Slack hoặc một hộp thư hỗ trợ chung và coi như đã xong. Điều này tạo ra ba tổn thương có thể dự đoán trước:

  • Một hộp thư chung trở thành nơi chứa rác cho các sự kiện từ nhiều lượt chạy. Ngữ cảnh bị sụp đổ. Bạn không thể tái dựng lại tin nhắn nào thuộc về giao dịch kinh doanh nào mà không cần mở từng luồng thư và phân tích dấu thời gian (timestamps) bằng tay.
  • Việc thử lại ghi đè lên bằng chứng. Nếu một lượt chạy gửi lại yêu cầu phê duyệt, tin nhắn gốc có thể bị chôn vùi, bị xóa hoặc bị đánh dấu là trùng lặp bởi một trình duyệt email quá nhạy bén. Dấu vết kiểm tra (audit trail) bị đứt đoạn.
  • Các quyết định của con người nằm ngoài hệ thống. Ai đó trả lời "trông ổn đấy" trong một phiếu hỗ trợ (ticket) hoặc tin nhắn trực tiếp. Ý kiến đó không bao giờ trở thành dữ liệu có cấu trúc bên trong quy trình làm việc. Tác nhân (agent) không có cách nào để xác minh ai đã nói gì, hoặc nói khi nào.

Khi có lỗi xảy ra và bạn cần điều tra, bạn chỉ nhận được những lời đồn đoán. "Tôi nghĩ đó là email đúng." Trí nhớ không phải là khả năng truy xuất nguồn gốc. Một nhật ký kiểm tra (audit log) không thể tiêu hóa một linh cảm.

Từ Chi tiết Giao hàng đến Điểm kiểm soát

Để khắc phục điều này, cần có một sự thay đổi trong thiết kế. Hãy ngừng coi email là một chi tiết giao hàng. Hãy bắt đầu coi nó là một điểm kiểm soát (checkpoint) của hệ thống. Điều đó có nghĩa là mỗi tin nhắn là một sự chuyển đổi trạng thái, và mỗi sự chuyển đổi trạng thái đều cần danh tính, sự ủy quyền và bằng chứng.

Khi bạn áp dụng tư duy này, các câu hỏi sẽ thay đổi. Bạn ngừng hỏi liệu email đã được gửi thành công hay chưa. Bạn bắt đầu hỏi lượt chạy nào đã gửi nó, nó để lại bằng chứng gì, và quy tắc nào đã cho phép quy trình làm việc tiếp tục. Tác nhân hoàn toàn có thể viết nội dung email. Nhưng nền tảng của bạn phải thực thi các lộ trình xác minh và danh tính. LLM là người viết. Cơ sở hạ tầng là công chứng viên.

Một Thiết kế Tối thiểu

Bạn không cần một gia tài để xây dựng điều này. Phiên bản khả thi tối thiểu (minimum viable version) của tôi sử dụng năm thành phần có tính toán kỹ lưỡng.

  • Bộ điều phối tạo ra một run_id ngay tại thời điểm quy trình làm việc bắt đầu. Mã định danh này là xương sống của mọi hành động tiếp theo. Nó không bao giờ thay đổi và không bao giờ được tái sử dụng.
  • Mọi hành động email đều mang theo ba trường: run_id, một nhãn message_type chẳng hạn như "approval_request" hoặc "evidence_notification", và một chuỗi policy_version để xác định các quy tắc quản trị nào đang hoạt động. Điều này biến một tin nhắn thông thường thành một sự kiện có kiểu dữ liệu (typed event).
  • Bằng chứng được lưu giữ trong một hộp thư được cô lập theo lượt chạy. Điều đó không nhất thiết có nghĩa là mỗi lượt chạy cần một tài khoản email riêng biệt. Nó có thể là một nhãn chuyên dụng, một thư mục con, hoặc một quy tắc định tuyến để phân đoạn các luồng thư, sao cho thư từ của lượt chạy này không bị lẫn lộn với lượt chạy khác.
  • Phản hồi phê duyệt phải là một sự kiện có cấu trúc, không phải là một văn bản tự do kiểu "ok". Con người vẫn nhấn hoặc trả lời, nhưng hệ thống sẽ chuyển đổi hành động đó thành một payload mà máy có thể đọc được, bao gồm run_id, quyết định và dấu thời gian.
  • Luồng công việc chỉ tiếp tục nếu bằng chứng và quyết định khớp nhau. Quy trình làm việc không tin tưởng sự phê duyệt một cách riêng lẻ. Nó xác thực payload phê duyệt với yêu cầu ban đầu trước khi cho phép kết quả đầu ra của LLM đi vào môi trường production.

Những gì một Điểm kiểm soát Hữu ích Xác thực

Một điểm kiểm soát hữu ích sẽ thực thi bốn điều kiện trước khi chấp nhận một quyết định từ con người.

  • Người nhận phải thuộc ngữ cảnh thực thi (run context). Nếu người phê duyệt không phải là người xem xét được chỉ định cho phiên bản quy trình công việc (workflow instance) cụ thể này, hệ thống sẽ từ chối tín hiệu.
  • Đối tượng hoặc siêu dữ liệu định tuyến (routing metadata) phải khớp với trạng thái luồng hiện tại. Việc phê duyệt cho bước ba không được phép bỏ qua bước hai.
  • Dấu thời gian (timestamp) phải nằm trong khoảng thời gian dự kiến. Một quyết định đến sau khi hết thời gian chờ (timeout) nên kích hoạt một đợt xem xét mới, chứ không phải tự động thông qua.
  • Bằng chứng không được tái sử dụng bởi một lần thực thi khác. Nếu cùng một ID tin nhắn hoặc mã thông báo (token) xuất hiện trong hai yêu cầu phê duyệt riêng biệt, đó là một sự xung đột (collision), và hệ thống nên dừng lại.

Cái giá thực sự

Mô hình này không hề miễn phí. Bạn phải lưu trữ nhiều siêu dữ liệu hơn. Bạn thêm vào một lớp chính sách mà ai đó phải duy trì. Bạn buộc đội ngũ của mình phải ghi lại các quyết định của con người dưới dạng dữ liệu có cấu trúc thay vì các bình luận tùy tiện. Nó trông có vẻ giống như sự quan liêu. Nhưng trên thực tế, đây là một sự đánh đổi tuyệt vời.

Bạn đang đánh đổi tốc độ để lấy sự rõ ràng.