Нужно ли ТЗ для ИИ-проекта: что фиксировать вместо перечня функций

Классическое ТЗ с фиксированным перечнем функций для ИИ-проекта работает плохо: два главных параметра — достижимое качество и стоимость обращения — неизвестны до проверки на реальных данных, а значит, не могут быть корректно зафиксированы на старте. Вместо описания «как сделать» нужен документ, определяющий критерий приёмки: что считается правильным результатом, какая доля ошибок допустима и как это проверяется. Документ нужен обязательно — не нужен именно классический его формат.

Почему обычное ТЗ ломается на ИИ-проектах

Традиционное ТЗ построено на допущении, что систему можно описать через перечень функций, каждая из которых либо работает, либо нет. Для обычной разработки это допущение верно: кнопка либо сохраняет документ, либо не сохраняет, и приёмка сводится к проверке пунктов.

ИИ-решение устроено иначе. Оно вероятностное: на один и тот же вопрос система может ответить правильно, а на похожий — ошибиться. Функция «система отвечает на вопросы по базе знаний» не бывает выполненной или невыполненной — она выполнена на какую-то долю. И эта доля неизвестна до тех пор, пока не проверена на конкретных данных.

Отсюда две типичные патологии.

ТЗ, требующее невозможного. В документ попадает формулировка вроде «система должна давать корректные ответы на вопросы пользователей». Она выглядит разумно, но не проверяема: не определено, что такое корректный ответ и сколько ошибок допустимо. Подрядчик формально не может её выполнить никогда, заказчик формально может не принять работу всегда.

ТЗ, фиксирующее не то. Документ детально описывает интерфейс, роли и кнопки — то, что легко расписать, — и молчит о качестве ответов, то есть о единственном, ради чего проект затевался. Работа сдаётся по пунктам, решение при этом бесполезно.

Причина обеих в одном: перенос привычной формы документа на задачу с другой природой.

Что нельзя зафиксировать заранее, а что можно

Разделение простое, и оно определяет структуру документа.

Нельзя зафиксировать до проверки на данных:

• достижимую точность — она свойство ваших материалов, а не мастерства подрядчика;
• стоимость обращения — зависит от размера контекста, который выясняется на прототипе;
• полный перечень сценариев — реальный поток всегда содержит случаи, которых никто не предусмотрел.

Можно и нужно зафиксировать сразу:

• границы задачи: на какие вопросы система отвечает, а на какие обязана не отвечать;
• что считается правильным ответом — с примерами;
• порог приёмки: допустимая доля ошибок и, отдельно, недопустимые виды ошибок;
• поведение при неуверенности: система обязана сказать «не знаю» и передать человеку, а не угадывать;
• требования к данным: где хранятся, что нельзя передавать вовне;
• что происходит при недоступности решения.

Обратите внимание на пункт про поведение при неуверенности — его пропускают чаще всего, а он важнее процента точности. Система, которая честно отказывается отвечать в спорном случае, безопаснее системы с более высокой средней точностью, которая уверенно ошибается. Механика этого разобрана в статье «Почему нейросеть выдумывает ответы».

Критерий приёмки — центральный документ проекта

Если из всей документации оставить одну страницу, это должен быть критерий приёмки. Он отвечает на вопрос, по которому стороны будут расходиться: сделана работа или нет.

Рабочий критерий содержит:

• Набор проверочных примеров. Случайная выборка из реального потока, а не подготовленные образцы. Составляется заказчиком, а не подрядчиком, — это принципиально: тот, кто делает систему, не должен определять экзамен для неё.
• Эталонные ответы. Что именно считается правильным на этих примерах. Готовит эксперт со стороны заказчика — человек, чью работу решение замещает.
• Порог по доле правильных ответов. Число, согласованное заранее.
• Список недопустимых ошибок. Отдельные категории, которые не компенсируются процентом: например, выдача несуществующего пункта регламента или ответ по устаревшей редакции документа.
• Процедура замера. Кто, когда и как проводит проверку, чтобы результат не зависел от того, кто смотрит.

Ключевое требование: критерий фиксируется до начала разработки и не меняется после того, как увидели результат. Изменение порога по факту — это не приёмка, а переговоры.

Двухшаговая схема вместо одного большого ТЗ

Рабочая практика — разбить документ на два, по границе неопределённости.

Шаг 1. Задание на discovery. Короткий документ: какой процесс, какие данные, что проверяем, какой критерий успеха, в какой срок. Результат этапа — не система, а обоснованный ответ: достижимо ли качество, сколько будет стоить эксплуатация, какие проблемы обнаружены в данных.

Шаг 2. ТЗ на разработку. Пишется после discovery, когда неизвестные стали известными. Здесь уже можно фиксировать и точность, и архитектуру, и стоимость — не как пожелание, а как подтверждённое проверкой значение.

Такая схема защищает обе стороны. Заказчик не платит за разработку решения, качество которого не проверено, и получает точку выхода. Подрядчик не принимает на себя обязательство по цифре, выполнимость которой никто не проверял, — а именно попытка зафиксировать точность до проверки данных превращает проект в конфликт.

Подробнее об этом этапе — в статье «PoC в ИИ-проекте», а общий порядок работ — в «Этапы внедрения ИИ в компании».

Обычный проект и ИИ-проект: что меняется в документах

Что писать в договоре

Несколько пунктов, отсутствие которых регулярно приводит к спорам:

• Этапность с точкой выхода. Discovery оплачивается отдельно, продолжение — право, а не обязанность заказчика.
• Предмет приёмки — критерий, а не впечатление. Ссылка на согласованную методику замера.
• Права на результат. Кому принадлежат подготовленная база знаний, промпты и настройки. Это актив, который создаётся в проекте, и он нередко ценнее кода.
• Что происходит при смене модели. Модели снимаются с поддержки; кто и за чей счёт выполняет миграцию.
• Ответственность за данные. Где обрабатываются, что не передаётся вовне. Если в процессе есть персональные данные, требования закона определяют архитектуру — см. «152-ФЗ и нейросети».
• Условия сопровождения. Что входит в поддержку после запуска и по какой цене.

Когда полное ТЗ всё-таки необходимо

Есть ситуации, где развёрнутый формальный документ обязателен независимо от природы задачи: государственные закупки и тендерные процедуры, проекты с обязательной сертификацией, сложные интеграции в регламентированном ИТ-ландшафте, а также внутренние правила крупных компаний.

В этих случаях подход не отменяется, а встраивается: формальное ТЗ пишется по требуемой форме, но раздел о приёмке строится на критерии качества, а не на перечне функций, а сам документ по возможности готовится после discovery. Если по процедуре ТЗ должно предшествовать любым работам, проверку достижимости имеет смысл провести как отдельный предварительный контракт — иначе в документ придётся вписывать цифры, взятые из воздуха.

Частые вопросы

Так нужно ТЗ для ИИ-проекта или нет?

Документ нужен обязательно, не нужен классический формат с перечнем функций. Работающая замена — критерий приёмки: что считается правильным ответом, на какой выборке проверяем, какая доля ошибок допустима и какие ошибки недопустимы в принципе. Без такого документа стороны расходятся в понимании того, сделана работа или нет.

Кто должен писать критерий приёмки — заказчик или подрядчик?

Проверочную выборку и эталонные ответы готовит заказчик, потому что только он знает, какой результат правильный. Подрядчик помогает с формой: подсказывает, что измеримо, а что нет, и предупреждает о непроверяемых формулировках. Если экзамен для системы составляет тот, кто её делает, приёмка теряет смысл.

Можно ли зафиксировать точность в процентах в договоре?

До проверки на данных — нет, это обязательство, выполнимость которого не установлена. После discovery — да, и это нормальная практика: проверка показала достижимый уровень, он и фиксируется с разумным запасом. Требование конкретного процента на старте обычно приводит либо к отказу подрядчика, либо к завышенной цене, в которую заложен риск.

Что делать, если подрядчик отказывается фиксировать качество?

Различать два отказа. Отказ фиксировать точность до проверки на данных обоснован и говорит о профессионализме. Отказ фиксировать критерий приёмки после discovery — тревожный признак: к этому моменту достижимый уровень уже известен, и нежелание его закрепить означает либо неуверенность в результате, либо намерение сдать работу по формальным признакам.

Нужно ли описывать в ТЗ, какую модель использовать?

Обычно нет, и жёсткая фиксация модели чаще вредит: модели обновляются и снимаются с поддержки быстрее, чем идут проекты. Фиксировать стоит требования, из которых выбор следует: где обрабатываются данные, каков потолок стоимости обращения, какая нужна скорость ответа. Выбор конкретной модели — решение исполнителя в этих рамках, и он должен оставаться заменяемым.

Что дальше

Документы имеют смысл в связке с этапами: сначала задание на проверку, потом ТЗ на разработку — см. «Этапы внедрения ИИ в компании» и «PoC в ИИ-проекте». Какие вопросы задать исполнителю до подписания — в статье «10 вопросов подрядчику по внедрению ИИ». Полная картина — в опорной статье «Внедрение ИИ в бизнес».

Постановка задачи и критерий приёмки — часть этапа discovery при разработке и внедрении ИИ; начать можно с аудита процессов.