Что должно быть в техзадании на AI-агента
Плохое техзадание — это описание того, что агент должен «уметь». Хорошее отвечает на вопрос, по каким признакам мы поймём, что он работает. Разбираем структуру по пунктам.
Девять разделов
- Цель и метрика. Один показатель, его текущее значение, способ замера и целевое значение. Не «улучшить обработку заявок», а конкретное число.
- Границы процесса. Где он начинается и заканчивается. Что агент точно не делает — этот пункт важнее, чем кажется.
- Источники данных. Из каких систем берутся данные, через какие механизмы, под какой учётной записью, с какими правами.
- Правила принятия решений. Записанные словами условия, по которым агент выбирает вариант. Здесь всплывают правила, которые жили в головах.
- Точки согласования человеком. Какие действия требуют подтверждения и кто подтверждает.
- Обработка исключений. Что делает агент, когда не уверен, когда данных не хватает, когда система недоступна.
- Что уходит наружу и что пишется в логи. Перечень полей поимённо.
- Критерии приёмки. На какой выборке и как проверяется результат.
- Условия признания неудачи. При каком значении метрики проект закрывается.
Что забывают чаще всего
| Раздел | Чем оборачивается пропуск |
|---|---|
| Что агент НЕ делает | Бесконечное расширение объёма по ходу проекта |
| Обработка исключений | Агент угадывает там, где должен был спросить |
| Критерии приёмки | Спор о том, готово или нет, на защите результата |
| Условия неудачи | Проект не закрывается никогда и тянет бюджет |
| Права на результат | Непонятно, чьи промпты и настройки после расторжения |
Про правила принятия решений
Это самый трудоёмкий раздел и самый полезный. Когда вы садитесь записывать словами, по каким признакам менеджер квалифицирует лид или бухгалтер принимает документ, выясняется, что единых правил нет — каждый делает по-своему.
Это открытие само по себе ценно, независимо от внедрения. Но пока правила не записаны, агента учить нечему.
Критерии приёмки: как формулировать
Формулировка должна быть проверяемой на конкретной выборке:
«На выборке из 200 обращений за последний месяц агент корректно определяет тему не менее чем в 85% случаев; ошибки категории „передал не в ту группу“ — не более 5%».
Такую формулировку нельзя истолковать двояко. «Агент должен корректно обрабатывать обращения» — можно, и в этом вся разница.
Кто пишет техзадание
В нашем случае — мы, по результатам аудита, и отдаём вам как документ, с которым можно идти к любому подрядчику. Это сознательно: техзадание, написанное подрядчиком под себя, обычно нельзя использовать больше нигде.
Частые вопросы
Может ли заказчик написать ТЗ сам?
Может, если внутри есть человек, знающий и процесс, и возможности технологии. На практике чаще получается либо слишком общее описание, либо список функций без метрики.
Нужно ли ТЗ для небольшого агента?
Нужны как минимум метрика, границы и критерии приёмки. Без них спор о готовности неизбежен даже на маленьком проекте.
Что делать, если правила нигде не записаны?
Записать. Это часть работы на аудите: садимся с владельцем процесса и формулируем словами то, что он делает по интуиции.
Кому принадлежит ТЗ?
У нас — заказчику, включая случай, когда вы решили не продолжать. Мы считаем это нормой: вы за него заплатили.
Составим техзадание на аудите
Получите документ с метрикой, правилами и критериями приёмки — пригодный для любого подрядчика.
Оставить заявку