Cô lập Email của LLM trong các Quy trình Tự động hóa

Khi một agent LLM bắt đầu gửi email hoặc phê duyệt ticket, vấn đề sẽ thay đổi. Nó không còn là câu chuyện liệu prompt của bạn có hoạt động hay không. Giờ đây, hệ thống của bạn phụ thuộc vào ba lớp: quyết định, thực thi và xác minh.

Nếu bạn trộn lẫn các lớp này, đội ngũ của bạn sẽ gặp khó khăn trong việc hiểu agent thực sự đã làm gì.

Bước gửi email thường trông giống như điểm kết thúc của một quy trình. Trên thực tế, đó là nơi các lỗi xuất hiện đầu tiên. Một agent có thể phân loại yêu cầu chính xác nhưng lại gửi cho sai người hoặc sử dụng một liên kết đã hết hạn. Bạn phải cô lập các bài kiểm tra (tests) và các vết truy vết (traces).

Một thiết kế ổn định không cố gắng kiểm tra trí thông minh cùng một lúc. Thay vào đó, hãy chia hệ thống của bạn thành các hợp đồng (contracts) nhỏ:

  • Hợp đồng Đầu vào (Input Contract): Xác định dữ liệu mà agent sử dụng và các hành động mà nó có thể yêu cầu.
  • Hợp đồng Thực thi (Execution Contract): Xác định cách một hành động trở thành một email cụ thể.
  • Hợp đồng Khả năng Quan sát (Observability Contract): Liên kết các bản ghi (logs), tin nhắn đã nhận và trạng thái cuối cùng của hệ thống.

Hãy giữ logic email tách biệt khỏi prompt tự do. LLM có thể đề xuất một hành động như "send_followup_email." Tuy nhiên, mô hình không nên quyết định các tiêu đề (headers), người nhận hoặc chính sách thử lại (retry policies). Hãy sử dụng mã nguồn xác định (deterministic code) cho các bước chuyển đổi này.

Cách tiếp cận này giúp giảm thiểu rủi ro vận hành. LLM đề xuất, hệ thống xác thực và bộ thực thi (executor) gửi đi.

Để duy trì khả năng hiển thị rõ ràng, hãy theo dõi bốn tín hiệu sau:

  • Quyết định được đưa ra bởi agent và ngữ cảnh được sử dụng.
  • Lệnh cuối cùng được gửi đến bộ thực thi email.
  • Tin nhắn nhận được trong một hộp thư cô lập.
  • Hiệu ứng cuối cùng sau khi nhấp vào một liên kết hoặc xác nhận một hành động.

Sử dụng một trace_id dùng chung từ sự kiện ban đầu đến lần nhấp cuối cùng. Điều này giúp bạn tìm lỗi nhanh chóng. Bạn sẽ biết lỗi xảy ra ở mô hình, chính sách công cụ (tool policy) hay ở worker.

Tuân thủ danh sách kiểm tra (checklist) này để tự động hóa tốt hơn:

  • Mỗi lần thực thi đều có trace_id riêng.
  • LLM chỉ yêu cầu các hành động nằm trong một schema hợp lệ.
  • Bộ thực thi email tái xác thực người nhận và template.
  • Mỗi kịch bản kiểm thử sử dụng một hộp thư cô lập riêng.
  • Lần nhấp cuối cùng xác nhận sự thay đổi trạng thái như mong đợi.
  • Các bản ghi (logs) cho phép bạn theo dõi trường hợp mà không cần phải đoán mò.

Việc tách biệt các bước này sẽ tốn thêm một chút công sức. Nhưng nó mang lại cho bạn một thứ vô giá: khả năng giải thích tại sao một email được gửi đi hoặc tại sao nó thất bại.

Source: https://dev.to/silviutech/como-aislar-emails-de-agentes-llm-en-flujos-automatizados-sin-perder-trazabilidad-26ac

Optional learning community: https://t.me/GyaanSetuAi