Створіть в n8n робочий процес підтримки з ШІ та перевіркою людиною
Редакційна вправа з класифікації синтетичних звернень до служби підтримки, перевірки чутливих випадків, підготовки чернеток відповідей і демонстрації робочого процесу обробки помилок в n8n.
Перевірено за документацією n8n .
Редакційна вправа: завдання та навчальна мета
Це редакційна вправа, а не перевірений робочий процес обслуговування клієнтів. Ваше завдання — створити основний робочий процес n8n, який класифікує вигадані звернення до служби підтримки, готує структуровані чернетки відповідей і спрямовує чутливі або нерозпізнані випадки на перевірку людиною. Ви також створите другий робочий процес, який оброблятиме навмисно спричинений збій в основному робочому процесі.
Навчальна мета — попрактикуватися в класифікації, умовній маршрутизації, людському контролі, структурованій підготовці чернеток і обробці помилок без контакту з реальними клієнтами. Успішне виконання цієї невеликої вправи не підтверджує точність класифікації, безпечність відповідей, стійкість у робочому середовищі чи готовність до використання в реальній службі підтримки.
Передумови, вхідні дані та обмеження безпеки
Використовуйте власне середовище n8n та отримайте дозвіл на створення й налаштування двох робочих процесів. Вам знадобляться доступ до сумісної чат-моделі та її облікові дані. Якщо ви вирішите продемонструвати етап погодження через Gmail, вам також знадобляться облікові дані Gmail і тестова адреса, контрольована фасилітатором. Погодження через Gmail тут є необов’язковою пропозицією, а не твердженням, що саме цей робочий процес було протестовано.
Підготуйте невеликий набір синтетичних вхідних даних. Пропоновані категорії: звичайне запитання, запит із чутливими даними облікового запису, запит із чутливими платіжними даними та образливе повідомлення або повідомлення з погрозами. Додайте щонайменше одне навмисно неоднозначне повідомлення для маршруту нерозпізнаних випадків і один елемент із явним маркером тестування збою. Ці категорії є редакційними пропозиціями, а не універсальною політикою служби підтримки.
Не використовуйте справжні імена, адреси електронної пошти, ідентифікатори облікових записів, платіжні дані, секрети чи історії клієнтів. Спрямовуйте звичайні результати у гілку лише для попереднього перегляду й не налаштовуйте автоматичне надсилання клієнтам. Людина має перевіряти кожен чутливий або нерозпізнаний випадок. Фасилітаторам слід обрати консервативні правила, доречні для їхнього вигаданого сценарію, оскільки наведена документація не визначає універсального порога впевненості чи політики ескалації.
Класифікуйте повідомлення та зберігайте нерозпізнані випадки
Почніть основний робочий процес із тригера, придатного для автоматичного виконання, а після нього додайте джерело синтетичних повідомлень. Додайте Text Classifier і визначте кожну категорію за допомогою зрозумілої назви та опису. Вузол розподіляє вхідні елементи за категоріями, налаштованими в його параметрах, але сама ця можливість не підтверджує точність або придатність для робочої служби підтримки.
Увімкніть окремий вихід Other і використовуйте його як безпечний маршрут замість відкидання повідомлень, які не відповідають запропонованим категоріям. Під’єднайте Other безпосередньо до шляху перевірки людиною. Для запланованого набору прикладів перевірте, чи кожне звичайне й чутливе повідомлення потрапляє до передбаченої категорії або в Other. Якщо елемент зникає, перевірте налаштування Other і відкоригуйте описи категорій, не вважаючи успішний тестовий запуск доказом загальної надійності.
Sources: S4
Підготуйте структуровану чернетку відповіді, не надсилаючи її
У кожній класифікованій гілці, де потрібна чернетка, додайте Basic LLM Chain, під’єднаний до обраної моделі. Створіть промпт із динамічним виразом, який містить лише синтетичне повідомлення та призначену категорію. Попросіть надати структурований результат, що містить принаймні категорію та чернетку. Вимога використовувати парсер вихідних даних є корисним пропонованим обмеженням, якщо вам потрібні передбачувані поля.
Зазначте в промпті, що відповідь є чернеткою для перевірки, а не підтвердженою відповіддю. Не просіть модель вигадувати правила, факти про обліковий запис, повернення коштів або зобов’язання. Спрямовуйте звичайні чернетки лише на етап попереднього перегляду. Здатність вузла приймати динамічні промпти або вимагати розібрані структуровані дані не підтверджує якість, фактичну правильність чи безпечність створеної відповіді.
Якщо чернетка відсутня, перевірте вираз промпту, підключення моделі, облікові дані та налаштування парсера. Поміркуйте, як робочий процес має обробляти некоректно сформовані структуровані дані; наведені можливості не гарантують, що кожна відповідь моделі матиме потрібну форму.
Sources: S5
Спрямовуйте чутливі та нерозпізнані випадки на перевірку людиною
Додайте вузол If після класифікації або підготовки чернетки, щоб оцінювати призначену категорію. Використайте умови порівняння, які спрямовують запропоновані чутливі категорії до гілки перевірки, а звичайні запитання — до гілки лише для попереднього перегляду. Під’єднайте вихід Other класифікатора до того самого місця перевірки. Ці умови реалізують вашу редакційну політику; можливість умовної маршрутизації в n8n не надає й не перевіряє цю політику.
Запис для перевірки має показувати синтетичні вхідні дані, запропоновану категорію та чернетку відповіді, щоб перевіряльник мав достатньо контексту для ухвалення рішення. У цій вправі не надсилайте чутливі, неоднозначні або нерозпізнані чернетки автоматично. Якщо ви демонструєте погодження через Gmail для контрольованого інструмента ШІ, розглядайте його як необов’язковий етап погодження та обмежте будь-яке повідомлення тестовою адресою, контрольованою фасилітатором. Задокументований механізм погодження може призупинити виклик інструмента ШІ до виконання контрольованого інструмента, але запропоноване налаштування тут не тестувалося.
Створіть і продемонструйте пов’язаний робочий процес обробки помилок
Створіть другий робочий процес, який починається з Error Trigger, а потім додайте етап попереднього перегляду або перевірки отриманих відомостей про збій. Збережіть цей робочий процес і виберіть його в налаштуванні Error workflow основного робочого процесу. Пов’язаний робочий процес обробки помилок запускається, коли в основному робочому процесі виникає помилка, і надає інформацію про робочий процес, що завершився збоєм, та його помилку.
В основному робочому процесі розмістіть Stop And Error за умовою, яка відповідає лише елементу з явним маркером тестування збою. Налаштуйте коротке власне повідомлення про помилку, яке чітко ідентифікує вправу. Цей вузол може навмисно завершити виконання з помилкою та передати власні відомості про неї до робочого процесу обробки помилок; це не доводить, що відновлення чи подальше сповіщення спрацює успішно.
Запустіть шлях збою через автоматичний тригер. Ручний запуск робочого процесу не активує пов’язаний робочий процес Error Trigger. Переконайтеся, що другий робочий процес запускається, а невдале виконання основного процесу доступне для перевірки. За потреби потренуйтеся повторно запускати його на вкладці Executions зі збереженою або початковою версією робочого процесу, пам’ятаючи, що видимість виконань залежить від прав доступу, а видалені робочі процеси втрачають історію виконань.
Критерії завершення, усунення несправностей і рефлексія
Вважайте вправу завершеною, коли кожен синтетичний приклад потрапляє до передбаченої категорії або маршруту Other; кожен чутливий і нерозпізнаний елемент доходить до перевірки людиною; звичайні відповіді залишаються чернетками; автоматичний тест збою активує пов’язаний робочий процес обробки помилок; а невдале виконання доступне для перевірки або повторного запуску. Це редакційні критерії завершення практичної вправи, а не докази ефективності в робочому середовищі.
Якщо вхідні дані губляться, перевірте описи категорій і вихід Other. У разі неправильної маршрутизації перевірте порівняння If та значення, які вони отримують. Якщо чернетки відсутні, перевірте динамічний промпт, під’єднану модель, облікові дані й очікувані структуровані поля. Якщо робочий процес обробки помилок не запускається, переконайтеся, що його збережено, пов’язано в налаштуваннях основного робочого процесу, він починається з Error Trigger і тестується через автоматичне, а не ручне виконання.
Поміркуйте над такими запитаннями: які вигадані випадки завжди мають потребувати перевірки? Який контекст потрібен перевіряльнику? Що має відбуватися, коли модель повертає некоректно сформовані дані? Як консервативно обробляти суперечливі категорії? Чому успішні тестові запуски не підтверджують точність класифікації, безпечність або готовність до робочого використання? Пропоноване рішення — використовувати явні категорії, спрямовувати Other і всі чутливі випадки до одного шляху перевірки, залишати звичайні результати лише для попереднього перегляду та ізолювати навмисний збій за умовою, призначеною лише для тестування.
Sources: S4, S5, S6, S7, S8, S2
