Дорожча модель не робить бізнес-процес надійним. Вона піднімає середню якість відповіді, але не знає, що саме ваша компанія вважає готовою роботою. Передбачуваність дає система навколо моделі: перевірка результату другим агентом, контракт результату та вузький набір інструментів. Ці три рівні коштують менше за постійний апгрейд моделі.
Якщо стандарт компанії живе тільки в голові керівника, жодна модель його не вгадає. Опишіть стандарт у системі навколо агента, і результат стане повторюваним.
Дорожча модель не компенсує неописаний процес: стандарт компанії має жити в системі навколо агента. Перший рівень контролю — агент-перевіряч, який оцінює чужу роботу на ШІ-слоп, відповідність голосу бренду та виконання задачі. Другий рівень задає контракт результату: перелік полів, які обов'язково мають бути у відповіді. Третій звужує набір інструментів, щоб агенту були доступні лише потрібні для задачі дії. Разом ці рівні обходяться дешевше за перехід на дорожчу модель.
Короткий словник
- ШІ-агент — програма на основі мовної моделі, яка виконує робочу задачу від початку до кінця.
- ШІ-слоп — гладкий на вигляд текст без змісту: загальні формулювання, вода, вигадані подробиці.
- Агент-перевіряч — окремий агент, єдина задача якого оцінити чужу відповідь за списком критеріїв.
- Контракт результату — заздалегідь описаний перелік того, що обов'язково має бути у відповіді.
- Інструменти агента — дії, які агент може виконати назовні: пошук у базі, запис, надсилання листа.
Чому заміна моделі на дорожчу не робить процес надійним
Апгрейд моделі приваблює простотою. Змінив налаштування, і результат наче став кращим. Домовлятися ні з ким не треба, описувати нічого не треба, робота команди лишається як була. Саме тому апгрейд обирають першим, коли агент почав видавати дивні відповіді.
Проблема в тому, що дивні відповіді зазвичай не про модель.
Що модель справді робить краще, а що лишається на боці процесу
Розумніша модель краще тримає довгі інструкції, точніше розуміє нечітко сформульовану задачу, рідше плутається в складних міркуваннях. Це реальні переваги. Але жодна з них не відповідає на питання, який вигляд має готова робота саме у вашій компанії.
Мовна модель відповідає імовірнісно. На однаковий запит вона може дати відповіді різної якості, і це властивість інструмента. Дорожча модель звужує розкид, проте не прибирає його повністю. Якщо у вас немає способу відсіяти невдалу відповідь, ви побачите її в роботі.
| Що робимо | Що змінюється | Що це ловить | Скільки роботи |
|---|---|---|---|
| Переходимо на дорожчу модель | Середня якість відповіді | Складні міркування, довгі інструкції | Разово змінити налаштування, далі вища вартість кожного запиту |
| Додаємо агента-перевіряча | Брак не доходить до людини | Слоп, чужий голос бренду, невиконану задачу | Разово описати критерії, далі майже нічого |
| Описуємо контракт результату | Зникають суперечки про якість | Неповні відповіді без обов'язкових полів | Разово описати поля під кожен тип задачі |
| Звужуємо набір інструментів | Поведінка стає повторюваною | Дії, яких агент взагалі не мав робити | Разово розрізати доступи між агентами |
Стандарт компанії має жити в системі навколо моделі
Стандарт відповідає на питання, що ви приймаєте як зроблену роботу. Скільки полів у звіті, яким тоном написана відповідь клієнту, що робити, коли даних не вистачає. Поки ці правила існують тільки в голові керівника, агент їх не бачить і бачити не може.
Тримати правила всередині одного довгого діалогу теж не вихід: чим довша розмова, тим гірше модель пам'ятає сказане на початку. Про цей ефект ми писали в розборі, чому нейромережа забуває твої правила в довгому чаті. Правила мають жити в системі навколо моделі: у критеріях перевірки, у контракті результату, у наборі доступних дій.
Три рівні контролю не прив'язані до конкретного сервісу. Вони працюють однаково для агента в чаті, у таблиці чи всередині вашої CRM. Змінюється тільки те, як технічно оформлені перевірка й доступи.
Шлях однієї задачі через три рівні контролю
- Задача від людини
- Рівень 3: вузькі інструменти
- Агент-виконавець робить роботу
- Рівень 2: контракт результату
- контракт виконаноРівень 1: агент-перевіряч
- перевірку пройденоРезультат іде людині
- Рівень 2: контракт результату
- полів не вистачаєАгент-виконавець робить роботу
- Рівень 1: агент-перевіряч
- слоп, чужий голос, задача не виконанаАгент-виконавець робить роботу
Рівень перший: перевірка результату другим агентом
Один агент робить задачу. Другий отримує його результат і виносить вердикт. Це найдешевший рівень контролю: він не вимагає ні інтеграцій, ні програміста, ні зміни інструментів.
Що подають перевірячу на вхід і за якими критеріями він судить
Перевіряч отримує три речі: початкову задачу, готову відповідь і список критеріїв. Задача потрібна, щоб він міг сказати, чи виконано те, про що просили. Критерії потрібні, щоб вердикт був однаковим щоразу, а не залежав від настрою моделі.
Задача перевіряча сформульована як оцінка, а не як переписування. Це принципова різниця. Агент, якому дозволили правити текст, майже завжди щось поправить і поверне його «покращеним». Агент, у якого просять вердикт, повертає вердикт і перелік зауважень.
Вердикт має бути коротким: пройшло чи не пройшло, і якщо не пройшло, то за яким саме критерієм. Розлогі рецензії ніхто не читатиме.
Перевіряч не всесильний. Якщо виконавець і перевіряч помиляються однаково, брак пройде далі. Про цей ефект узгодженої помилки ми писали в розборі, чому згода кількох моделей не доводить їхньої правоти. Саме тому перевірка працює в парі з двома іншими рівнями.
Перевіряч не мусить бути дорожчою моделлю за виконавця. Оцінити готовий текст за списком критеріїв простіше, ніж написати його. Часто на перевірці стоїть та сама модель, якій дали іншу задачу.
Ознаки ШІ-слопу, які має ловити перевірка
ШІ-слоп впізнається за сталими ознаками. Опишіть їх перевірячу списком, інакше він шукатиме «щось не те»:
- Порожні узагальнення. Фраза «сучасні рішення відкривають нові можливості» не додає читачеві нічого.
- Канцелярит. Довгі віддієслівні конструкції там, де вистачає одного дієслова.
- Вигадані подробиці. Назви, цифри чи посилання, яких не було у вихідних даних.
- Рівний ритм. Усі речення однакової довжини, усі абзаци однакового розміру.
- Чужий голос. Текст формально правильний, але написаний не так, як говорить ваша компанія.
Як описати голос бренду, щоб ним можна було міряти
«Пиши дружньо і професійно» не працює як критерій. За таким описом перевіряч не може сказати, чи порушено правило. Голос бренду стає критерієм тоді, коли він розкладений на перевірювані ознаки: звертання на «ви» чи на «ти», гранична довжина речення, дозволені й заборонені слова, чи можна ставити запитання читачеві, чи допустимі емодзі.
Найшвидший спосіб зібрати такий опис — взяти кілька власних текстів, які вам подобаються, і виписати, чим вони схожі між собою.
Рівень другий: контракт результату
Перевірка ловить брак. Контракт результату не дає браку з'явитися. Це перелік полів, які обов'язково мають бути у відповіді, складений заздалегідь і збережений окремо від діалогу: у документі команди, у налаштуваннях агента, у шаблоні задачі. Тримати його в голові виконавця марно, бо тоді про нього знає одна людина.
Приклад контракту для звіту про баг
Співробітник пише «сайт не працює», і з цього повідомлення неможливо нічого зробити. Контракт для звіту про баг вимагає ідентифікатор, кроки відтворення, очікуваний результат, фактичний результат і логи. Немає хоча б одного поля, і звіт не приймається.
«На сайті помилка при оформленні замовлення, клієнти скаржаться. Треба терміново подивитися, бо втрачаємо продажі.» Розробник не знає ні браузера, ні кроків, ні тексту помилки, тому починає з розпитувань.
«ID: CART-SHIP. Кроки: додати товар у кошик, перейти до оплати, обрати доставку. Очікувано: форма оплати. Фактично: порожня сторінка. Логи: доданий файл.» Розробник відтворює помилку з першої спроби.
Контракти для типових задач малого бізнесу
Контракт пишеться один раз на тип задачі й далі працює для всіх однотипних звернень. Оновлює його той, хто приймає роботу: якщо ви двічі попросили дописати одне й те саме поле, воно має переїхати в контракт.
| Задача | Обов'язкові поля на виході | За чим видно, що контракт не виконано |
|---|---|---|
| Звіт про баг | Ідентифікатор, кроки відтворення, очікуваний і фактичний результат, логи | Немає кроків або логів, помилку неможливо відтворити |
| Відповідь клієнту | Пряма відповідь на питання, наступний крок, строк, контакт для уточнень | Відповідь ввічлива, але клієнт не знає, що робити далі |
| Картка товару | Назва, характеристики, для кого підходить, умови доставки | Текст красивий, а характеристик у ньому немає |
| Підсумок зустрічі | Рішення, відповідальний за кожне рішення, строк, невирішені питання | Переказ розмови без жодного відповідального |
Що робити з відповіддю, яка не пройшла контракт
Сценаріїв три, і вибір між ними варто зробити заздалегідь.
- Повернути на доопрацювання. Найчастіший випадок: агент отримує перелік відсутніх полів і робить другу спробу.
- Віддати людині. Якщо друга спроба теж провалилась, задача йде до співробітника разом з усім, що вже напрацьовано.
- Відхилити повністю. Коли задача сформульована так, що виконати її неможливо; тут виправляти треба постановку.
Повернення на доопрацювання є штатним кроком процесу. Якщо ж задача повертається щоразу, дивіться на формулювання контракту: зазвичай у ньому просять те, чого агент фізично не може дізнатися.
Рівень третій: вузькі інструменти замість доступу про запас
Інструменти агента — це дії, які він може виконати назовні: знайти клієнта в базі, надіслати листа, змінити статус замовлення. Третій рівень контролю каже давати агенту тільки ті дії, які потрібні для його задачі. Решту функціоналу тримають окремо.
Чому зайвий доступ ламає передбачуваність
Чим більше дій доступно, тим більше способів виконати задачу. Агент із десятком інструментів щоразу обирає свій шлях, і два запуски однакової задачі лишають різні сліди в системі. Звузьте набір, і поведінка стане повторюваною просто тому, що інших варіантів у агента немає.
Другий ефект стосується помилок. Агент не може зробити те, чого немає в його інструментах. Це найнадійніший запобіжник із трьох, бо він працює навіть тоді, коли модель повністю неправильно зрозуміла задачу.
Агент, який відповідає на питання клієнтів, потребує пошуку в базі знань і надсилання відповіді. Доступ до зміни замовлень йому не потрібен. Якщо клієнт попросить скасувати замовлення, агент передасть задачу далі, бо кнопки «скасувати» в нього просто немає.
Як розрізати функціонал між кількома агентами
Розріз іде по задачах. Один агент відповідає на питання, другий оформлює замовлення, третій готує звіти. У кожного свій набір дій і свій контракт результату.
Спокуса зробити одного універсального агента зрозуміла: менше налаштувань, одна точка входу, нічого не треба розділяти. Але саме такий агент найважче піддається перевірці, бо для нього неможливо скласти один контракт результату.
Як впровадити три рівні в команді без технічного спеціаліста
Більшість роботи тут текстова. Критерії перевірки, контракт результату та опис голосу бренду пишуться звичайними словами, і це найбільша частина справи.
Обрати одну задачу
- взяти найчастішу однотипну роботу
- не починати з рідкісних складних випадків
Описати контракт результату
- виписати поля, які обов'язково мають бути у відповіді
- перевірити опис на старих прикладах
Скласти критерії перевірки
- ознаки слопу
- ознаки чужого голосу
- ознака невиконаної задачі
Запустити перевіряча
- окремий агент оцінює готову відповідь і повертає короткий вердикт
Звузити інструменти
- лишити агенту тільки дії, потрібні для цієї задачі
З якого рівня починати і що можна відкласти
Починайте з контракту результату. Він дає найбільший ефект за найменших зусиль і одночасно готує матеріал для перевірки: критерії наполовину виписуються з готового контракту.
Перевіряч іде другим кроком. Вузькі інструменти лишайте наостанок, бо цей рівень єдиний вимагає технічної роботи з доступами.
Не описуйте контракти одразу для всіх задач. Візьміть одну, доведіть її до стану, коли відповіді проходять перевірку стабільно, і лише тоді беріть наступну. Опис, зроблений про запас, зазвичай доводиться переписувати після першого ж зіткнення з реальними задачами.
Як зрозуміти, що контроль працює
Рахуйте дві цифри з першого тижня. Перша цифра — частка відповідей, які пройшли перевірку з першої спроби. Друга показує, скільки разів задача поверталася на доопрацювання, доки її прийняли.
Перша має рости, друга падати.
Якщо обидві стоять на місці, справа зазвичай у критеріях: вони сформульовані так, що перевіряч не може винести однозначний вердикт. Якщо повернень стало більше після зміни контракту, ви попросили в агента поле, яке йому немає звідки взяти.
Ці метрики показують якість роботи. Окремо варто дивитися, чи окупається агент взагалі: про це є розбір трьох метрик окупності ШІ в бізнесі.
Остання перевірка найпростіша. Опишіть роботу агента так, як описали б роботу нового співробітника: задача, критерії приймання, зона доступу. Якщо всі три пункти у вас є в письмовому вигляді, рівні контролю зібрані, і агент перестає бути чорним ящиком у команді.