Рабочая таблица приёмки ИИ-процесса: шаблон и пример

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

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

Что зафиксировать до первого прогона

До тестирования заполните четыре условия:

1. Функция и результат. Например: «подготовить проект протокола встречи с решениями, ответственными, сроками и открытыми вопросами».
2. Набор задач. Используйте одни и те же типы входов для текущего процесса и варианта с ИИ. Включите типичные, пограничные и заведомо недостаточные данные.
3. Критерий пригодности. Запишите, что проверяющий должен подтвердить до использования результата.
4. Порог остановки. Определите ошибку, после которой функцию нельзя продолжать использовать без исправления: например, раскрытие недоступного документа или выдуманный ответственный.

Состав функции, роли, источники и ограничения удобно сначала закрепить в паспорте ИИ-функции. Если эти границы меняются между прогонами, результаты нельзя сравнивать напрямую.

Поля рабочей таблицы

Одна строка соответствует одной завершённой или остановленной операции.

Версию источников формируйте из реестра документов, а не из даты копирования папки. Порядок подготовки такого реестра описан в материале о базе знаний для ИИ-функции.

Как считать четыре итоговых показателя

Время до пригодного результата

Считайте полное рабочее время до подтверждения результата, включая ручную проверку и исправления. Время генерации само по себе не показывает, стала ли операция быстрее.

Сравнивайте медиану для одинаковых типов задач: один сложный случай меньше искажает медиану, чем среднее значение. Если состав задач изменился, начинайте новую серию.

Доля результатов с существенными правками

Сначала определите существенную правку. Для протокола встречи это может быть исправление решения, ответственного, срока или пропущенного поручения. Стилистику и замену синонима можно учитывать отдельно.

Формула:

число результатов с существенной правкой / число проверенных результатов × 100%.

Не объединяйте принятые и непроверенные результаты: отсутствие проверки не равно отсутствию ошибки.

Завершённые операции

Операция считается завершённой, когда результат принят уполномоченным проверяющим. Технический статус «задача выполнена» не доказывает пригодность для процесса.

Отдельно считайте остановленные операции и причины остановки. Правильный отказ при недостатке данных может быть ожидаемым поведением, а не сбоем.

Расход на LLM

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

В Тау Хаб использование LLM оплачивается отдельно от платформы и внедрения: модель подключается ключом заказчика либо через прокси Тау. Поэтому расход на LLM нужен в таблице независимо от выбранного варианта размещения платформы.

Заполненный пример: проект протокола встречи

Это иллюстративный пример структуры, а не клиентский результат Тау Хаб.

Условия серии: функция готовит проект протокола по разрешённой расшифровке; руководитель проекта проверяет решения, ответственных, сроки и открытые вопросы; автоматическая отправка запрещена.

Из четырёх строк нельзя делать вывод об экономическом эффекте: выборка слишком мала, а значения придуманы для объяснения формы. Но таблица уже показывает, какие проверки нужно повторить после исправления обработки сроков и какие остановки являются ожидаемыми.

Пустой шаблон для пилота

Скопируйте таблицу и замените примеры своими критериями.

Рядом с таблицей сохраните:

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

Как принять решение после серии

Используйте три исхода.

1. Продолжить пилот. Пороговые ошибки не возникли, результаты проверены, а качество и время достаточно стабильны для следующей серии.
2. Доработать и повторить. Причина ошибок понятна: источник, правило, доступ или формат результата можно изменить и проверить на том же наборе.
3. Остановить сценарий. Функция выходит за пределы допустимого риска, не достигает критерия пригодности или стоимость проверки делает процесс бессмысленным.

NIST AI RMF Playbook рекомендует определять процедуры и метрики пригодности системы, допустимые пределы ошибок, документировать результаты тестов и корректировать систему при выходе за пределы. Страница проверена 20 сентября 2026 года. Приведённая таблица — практический шаблон Тау Хаб, а не обязательная форма NIST.

После приёмки перенесите фактические время, долю существенных правок, число принятых операций и расход на модели в расчёт экономики пилота. Только измеренная серия, а не сценарные 800 ₽ за час и 25% роста производительности, может служить основанием для решения о масштабировании.