Ізоляція електронних листів LLM в автоматизованих робочих процесах
Коли LLM-агент починає надсилати електронні листи або схвалювати тікети, характер проблеми змінюється. Питання вже не в тому, чи працює ваш промпт. Тепер ваша система покладається на три рівні: прийняття рішення, виконання та верифікація.
Якщо ви змішаєте ці рівні, вашій команді буде важко зрозуміти, що саме зробив агент.
Етап надсилання листа часто здається завершенням робочого процесу. Насправді саме тут помилки проявляються першими. Агент може правильно класифікувати запит, але надіслати його не тій особі або використати застаріле посилання. Ви повинні ізолювати тести та трасування.
Стабільний дизайн не намагається протестувати інтелект одночасно в усьому. Замість цього розділіть свою систему на невеликі контракти:
- Контракт вхідних даних: Визначте, які дані використовує агент і які дії він може запитувати.
- Контракт виконання: Визначте, як дія перетворюється на конкретний електронний лист.
- Контракт спостережуваності: Пов'яжіть логи, отримані повідомлення та кінцевий стан системи.
Тримайте логіку електронної пошти поза межами вільного промпту. LLM може запропонувати таку дію, як "send_followup_email". Однак модель не повинна вирішувати, які будуть заголовки, отримувачі або політики повторних спроб. Використовуйте детермінований код для цих перетворень.
Такий підхід знижує операційні ризики. LLM пропонує, система валідує, а виконавець надсилає.
Щоб підтримувати чітку видимість, відстежуйте ці чотири сигнали:
- Рішення, прийняте агентом, та використаний контекст.
- Остання команда, надіслана виконавцю електронної пошти.
- Повідомлення, отримане в ізольованому поштовому ящику.
- Кінцевий ефект після натискання на посилання або підтвердження дії.
Використовуйте спільний trace_id від початкової події до останнього кліку. Це допоможе вам швидко знаходити помилки. Ви будете знати, чи сталася помилка в моделі, у політиці інструменту чи у воркері.
Дотримуйтесь цього чек-листа для кращої автоматизації:
- Кожне виконання має свій власний trace_id.
- LLM запитує лише ті дії, які відповідають валідній схемі.
- Виконавець електронної пошти повторно перевіряє отримувача та шаблон.
- Кожен тестовий сценарій використовує власний ізольований поштовий ящик.
- Остання дія (клік) підтверджує очікувану зміну стану.
- Логи дозволяють відстежувати випадок без припущень.
Розділення цих кроків додає трохи більше роботи. Але це дає вам щось цінне: можливість пояснити, чому лист було надіслано або чому він не надіслався.
Додаткова спільнота для навчання: https://t.me/GyaanSetuAi