В техническом задании на ИИ-проект обязательны шесть вещей: цель и граница задачи, оценочная выборка с эталонными ответами, критерий приёмки числом, поведение системы при неуверенности и ошибке, данные и права доступа, эксплуатация после запуска. Всё остальное (интерфейс, сроки, стек) пишется как в обычном задании. Именно эти шесть пунктов чаще всего пропускают, и поэтому потом спорят о том, «работает ли» система.
Почему так: обычная программа при тех же входных данных даёт один и тот же ответ, и приёмка проверяет, совпал ли он с ожидаемым. Модель иногда ошибается даже у хорошего исполнителя, и вопрос приёмки звучит иначе: как часто и в чём именно. Общие правила написания задания собраны в статье «Как составить техническое задание на разработку», здесь только то, что добавляет ИИ.
Чем задание на ИИ отличается от задания на обычную программу
Различие в природе результата. Из него вытекает, что в задании нужно записать то, что в обычном проекте подразумевается.
| Что | Обычная программа | ИИ-система |
|---|---|---|
| Результат | Детерминированный: на тот же вход тот же выход | Вероятностный: ответ может отличаться, часть ответов неверна |
| Приёмка | Сценарии с ожидаемым результатом | Замер на выборке: доля верных, виды ошибок, поведение на спорных случаях |
| Ошибка | Дефект, исправляется | Ожидаемое свойство; важно, какая она и во что обходится |
| Данные | Нужны для работы и тестов | Определяют качество; без размеченной выборки задачу нельзя принять |
| После запуска | Работает, пока не меняют код | Качество меняется вместе с данными, нужен мониторинг и владелец |
Из этого следует, что задание на ИИ нельзя написать до знакомства с данными. Поэтому полноценное задание обычно получается как результат обследования, а не до него.
Из каких разделов состоит задание
Ниже структура, которую можно взять за основу. Для каждого раздела указано, что пишут и какая формулировка слабая.
| Раздел | Что записать | Слабая формулировка |
|---|---|---|
| Цель и граница | Какую операцию заменяет или ускоряет система и чего не делает | «Внедрить ИИ в отдел продаж» |
| Процесс как есть | Кто, что, как часто и сколько времени тратит сейчас; сколько ошибок сегодня | «Сотрудники тратят много времени» |
| Процесс как будет | Что делает система, что человек, где точка подтверждения | «Система автоматизирует процесс» |
| Данные | Источники, форматы, объём, кто владелец, что содержит персональные данные | «Данные есть в 1С» |
| Оценочная выборка | Кто и из чего собирает, сколько примеров, кто размечает, как хранится | «Проверим на тестовых примерах» |
| Критерий приёмки | Метрика, порог, способ замера, что считается ошибкой | «Высокая точность» |
| Поведение при неуверенности | Порог, куда уходит спорное, как пользователь видит источник | Не описано |
| Права и контур | Роли, что видит каждая, где работает модель, журнал действий | «Безопасно» |
| Нефункциональное | Время ответа, число одновременных пользователей, доступность в рабочие часы | «Работает быстро» |
| Эксплуатация | Кто смотрит качество, как откатить версию, как обновлять | «Сопровождение по запросу» |
| Не входит в объём | Что явно откладывается на следующие этапы | Раздела нет |
Оценочная выборка: самый важный раздел
Оценочная выборка (её называют эталонной или тестовой) — набор реальных входов с правильными ответами, по которому принимается работа. Без неё приёмка превращается в «посмотрели, вроде нормально».
Что в задании записать про выборку
- Откуда берётся. Из реальных обращений, документов или снимков за прошлые периоды, а не придуманные специально. Если реальные примеры нельзя показывать, их обезличивают.
- Какого размера. Достаточного, чтобы разбить по видам случаев: типовые, редкие, пограничные. Конкретное число называют на обследовании, оно зависит от разнообразия данных.
- Кто размечает. Специалист вашей предметной области, не исполнитель. Для спорных случаев разметку делают двое и сверяют; расхождение между ними само по себе информативно.
- Что закрыто от настройки. Часть выборки исполнитель не видит и не использует при подборе параметров. Иначе замер покажет, насколько хорошо модель запомнила примеры.
- Как обновляется. Со временем данные меняются: добавляются новые формы, термины, продукты. Выборка пополняется, и порядок записан.
Чем замеряется качество для разных типов систем, описано на странице оценки качества LLM-систем, а подготовка данных — в статье «Как подготовить данные для ИИ-пилота».
Критерий приёмки: как записать так, чтобы его можно было проверить
Критерий — это метрика, порог и способ проверки. Без любого из трёх он не работает.
| Тип системы | Что измеряем | Пример формулировки (условный) | Что ещё записать |
|---|---|---|---|
| Ассистент по документам | Верность ответа и наличие верного источника | На выборке вопросов не меньше согласованной доли ответов признана верной экспертом, и каждый ответ содержит ссылку на документ | Как ведёт себя на вопросе без ответа в базе: отказывается, а не выдумывает |
| Распознавание документов | Верность каждого поля, а не документа в целом | Суммы и реквизиты извлечены верно в согласованной доле документов; остальные уходят оператору | Какие поля критичны: ошибка в одной цифре суммы дороже ошибки в адресе |
| Классификация обращений | Полнота и точность по каждому классу | Для класса «жалоба» ни одна жалоба не должна уходить в прочие чаще согласованного порога | Цена ошибки в обе стороны: пропуск и ложная тревога |
| Прогноз | Отклонение от факта на отложенном периоде | Ошибка прогноза на последних неделях не выше согласованной, интервал показан | Сравнение с текущим способом планирования |
| Агент с действиями | Верные действия и отсутствие запрещённых | Ни одного действия вне разрешённого набора; спорные ушли на подтверждение | Тестовая копия систем, журнал каждого шага |
Порог не берётся с потолка. Его определяет цена ошибки и текущее качество ручной работы: сотрудники тоже ошибаются, и сравнивать нужно с их показателем, а не со ста процентами. Первое число часто выбирают по итогам прототипа на вашей выборке, и это нормально: в задании фиксируют способ получения порога и срок, когда он утверждается.
Что делает система, когда не уверена или ошиблась
Раздел почти всегда отсутствует, хотя именно он определяет, можно ли пользоваться системой. Запишите три сценария.
- Низкая уверенность. Система отдаёт случай человеку, показывает источник или отказывается отвечать. Порог настраивается и записан. Подробнее в статье «Порог уверенности модели».
- Явная ошибка. Пользователь может пометить ответ неверным, пометка попадает в разбор, а исправленный пример пополняет выборку.
- Сбой. Недоступна модель или учётная система. Что видит пользователь, что происходит с запросом, как возобновляется работа без дублей.
Для агентов, которые выполняют действия, добавляется список разрешённых действий, права отдельной учётной записи и точки подтверждения человеком; см. статью «Права и подтверждение действий ИИ-агента».
Данные, права и контур
Здесь задание отвечает на вопрос службы безопасности ещё до разработки.
- Где работает модель. На ваших серверах, у хостера по вашему выбору или через внешний программный интерфейс. Для данных ограниченного доступа последний вариант чаще не подходит по требованиям заказчика, и это нужно записать явно, иначе исполнитель выберет самый удобный себе.
- Какие данные видит каждая роль. Ассистент по документам не должен показывать сотруднику то, к чему у него нет доступа. Права учитываются при поиске, а не при показе ответа.
- Что пишется в журнал. Запрос, источники, ответ, действие, кто подтвердил. Срок хранения определяет ваша политика.
- Персональные данные. Какие есть, где хранятся, кто оператор. Юридическую квалификацию даёт юрист заказчика, мы описываем технические меры.
- Лицензии. Лицензия выбранной модели допускает коммерческое использование в вашем сценарии; перечень лицензий компонентов входит в документацию.
Нефункциональные требования и стоимость эксплуатации
У ИИ-системы есть расход, которого нет у обычной программы: каждый запрос потребляет вычислительные ресурсы. Поэтому в задании нужны числа, а не пожелания.
- Нагрузка. Сколько пользователей работают одновременно в пик и сколько запросов в день ожидается. От этого зависит оборудование.
- Время ответа. Для диалога допустимое ожидание иное, чем для пакетной обработки документов за ночь. Запишите оба, если нужны оба.
- Доступность. В рабочие часы или круглосуточно. Если нужно круглосуточно, скажите об этом сразу: у нас дежурной смены нет, и мы называем это до договора.
- Потолок затрат на эксплуатацию. Допустимая стоимость обработки одного запроса или документа. Если расчёт не сходится, это видно на обследовании, а не после запуска.
Эксплуатация после запуска
Это тот раздел, на котором держится остальное. ИИ-система без владельца качества деградирует тихо: данные меняются, а метрику никто не смотрит. Причины остановки пилотов описаны в статье «Почему ИИ-пилоты не доходят до продуктива».
В задании запишите: кто отвечает за качество после запуска (должность, не «ИТ-отдел»); как часто повторяется замер на свежей выборке; как откатиться на предыдущую версию модели; кто и как обновляет базу знаний или данные; что считается поводом остановить систему. И отдельно: кто принимает работу на этапах и кто один утверждает изменения требований.
Типичные ошибки в задании на ИИ
| Ошибка | К чему приводит | Как исправить |
|---|---|---|
| Нет оценочной выборки | Приёмка идёт по впечатлению, спор неизбежен | Сделать сбор выборки первым результатом |
| Критерий без числа | Любой результат можно назвать успешным или провальным | Метрика, порог, способ замера |
| Порог взят из презентации исполнителя | Ждёте то, чего ваши данные не позволяют | Утвердить порог после прототипа на вашей выборке |
| Не описано поведение при ошибке | Пользователи теряют доверие после первой же ошибки | Прописать порог, источник и канал исправления |
| Задание на систему целиком | Объём не ограничен, цена и срок тоже | Задание на первый этап и рамка остального |
| Зафиксирована модель или стек до разбора данных | Выбрано то, что не подходит по контуру или качеству | Писать ограничения, а выбор оставлять за обследованием |
| Не назван владелец качества | Система стареет без присмотра | Назначить роль и периодичность замера |
Что делаем мы и с чего начать
Задание на ИИ-проект лучше получать как результат обследования. Оно стоит 200 000 ₽ и занимает 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели за несколько систем, 500 000 ₽ и 4–6 недель за производство или контур. На выходе документ с разбором данных, критериями приёмки, оценочной выборкой и вилкой бюджета. С ним можно прийти к нам, к другому подрядчику или в тендер. Сумма вычитается из первого этапа, если вы продолжаете с нами.
Дальше пилот (лёгкий 150 000–400 000 ₽, тяжёлый 400 000–1 200 000 ₽), вывод в эксплуатацию от 1 500 000 ₽ этапами по 300 000–700 000 ₽ и сопровождение от 20 000 ₽ в месяц. Все цены и сроки на странице «Тарифы». Кого выбрать исполнителем, разобрано в статье «ИИ-агентство, своя команда или фрилансер», а как мы работаем, описано на странице «ИИ-агентство». Какие задачи ИИ решает уже сейчас, показано на странице «ИИ для бизнеса».
Частые вопросы
Можно ли написать техническое задание на ИИ до начала работ?
Рамочное можно: цель, процесс, данные, ограничения контура. Критерий приёмки числом без знакомства с данными составить нельзя, потому что предел достижимого качества виден только на вашей выборке. Поэтому полноценное задание обычно получается по итогам обследования или прототипа.
Сколько примеров нужно в оценочной выборке?
Зависит от разнообразия данных, поэтому единого числа нет. Выборка должна быть такой, чтобы в ней были и типовые, и редкие, и пограничные случаи в количестве, на котором метрика не прыгает от одного примера. Размер называют на обследовании после просмотра данных.
Кто должен размечать эталонные ответы?
Специалист вашей предметной области: юрист для договоров, технолог для дефектов, оператор поддержки для обращений. Исполнитель размечать не должен, иначе он проверяет сам себя. Для спорных случаев разметку делают двое.
Нужно ли указывать модель в техническом задании?
Нет, если нет ограничения по контуру или лицензиям. Выбор модели делают по замеру на вашей выборке. Записывают требования: работает на ваших серверах, лицензия допускает коммерческое использование, версия фиксируется и обновляется по согласованию.
Что делать, если ИИ не набирает нужный порог?
Заранее записать, что будет дальше: доработка данных, смена подхода, снижение порога с добавлением проверки человеком или остановка проекта. Остановка после пилота не провал, а результат: вы потратили сумму лёгкого пилота и узнали, что задача не решается на этих данных.
Чем ТЗ на ИИ-ассистента по документам отличается от ТЗ на распознавание?
У ассистента критичны корректность ответа, ссылка на источник и поведение на вопросе без ответа. У распознавания считают верность каждого поля и очередь оператора. Общие разделы одни, критерии и ошибки разные, см. таблицу в статье.
Нужно ли описывать интерфейс?
На уровне ролей и сценариев да: кто что делает, где подтверждение, где ссылка на источник. Описание до пикселя не нужно, оно устареет на первой демонстрации. Макеты интерфейса делаются по ходу работ.
Сколько стоит составление технического задания на ИИ-проект?
Отдельной цены нет, документ является результатом обследования: 200 000 ₽ за один-два процесса, 350 000 ₽ за несколько систем, 500 000 ₽ за производство или контур. Сумма вычитается из первого этапа, если вы продолжаете с нами.