Опишите её в двух-трёх предложениях. Я отвечу, что проверить первым и нужен ли здесь ИИ.
Практическая система измерений: базовое время, участие человека, стоимость проверки, ошибки и доля задач, принятых без доработки на сопоставимых примерах.
В моей локальной статистике ORCH было 15 завершённых запусков, ни одного сбоя и 79,4 минуты работы агентов. На первый взгляд — безупречный результат. Но в папке с карточками задач лежала другая сводка: 12 работ завершены, четыре ждут проверки, одна отменена.
Обе сводки верны. И обе по отдельности почти бесполезны.
Счётчик запусков отвечает на вопрос, сколько раз система дошла до технического конца. Карточки задач показывают состояние работы. Ни тот, ни другой источник не говорит, сколько времени сэкономил человек, сколько результатов принято без исправлений и не стала ли проверка дороже самой работы.
Эта разница и есть главная ловушка измерения ИИ-агентов. Мы хорошо считаем их активность и плохо считаем исчезнувший человеческий труд.
Вот что можно извлечь из журнала запусков ORCH:
| Показатель активности | Число | Чего мы всё ещё не знаем |
|---|---|---|
| Завершённые запуски | 15 | Сколько результатов принято |
| Технические сбои | 0 | Сколько результатов пришлось исправлять |
| Работа агентов | 79,4 минуты | Сколько минут потратил человек |
| Токены модели | 137 633 | Какова стоимость принятого результата |
| Токены из кеша | 13 856 271 | Сколько ручной работы исчезло |
| Карточки со статусом «готово» | 12 из 17 | Выполнены ли критерии приёмки |
| Карточки на проверке | 4 из 17 | Сколько времени займёт проверка |
| Отменённые карточки | 1 из 17 | Какова цена отменённой попытки |
Цифры слева описывают двигатель: обороты, температуру, расход. Цифры справа нужны водителю: приехали ли мы, сколько потратили и не разбили ли машину по дороге.
Средний запуск агента в этой выборке длился около 5,3 минуты. Это любопытная техническая характеристика. Пользой она станет только после сравнения с ручным процессом и учёта времени человека. Если специалист раньше тратил на задачу 40 минут, а теперь тратит три минуты на постановку и пять на проверку, результат отличный. Если запуск занимает пять минут, но затем требует получаса чтения, повторных запусков и исправлений, экономии может не быть.
Токены, вызовы инструментов, созданные файлы и параллельно занятые агенты удобно показывать на панели наблюдения. Они помогают искать сбои и понимать нагрузку. Для оценки пользы этого мало.
Рабочий вопрос звучит иначе: какие действия после внедрения агента человек перестал выполнять сам?
Например, раньше разработчик собирал сведения из пяти файлов, искал связанные участки кода, писал черновик изменения, запускал проверки и составлял отчёт. Теперь агент делает первые три шага, а человек формулирует задачу, оценивает изменение и принимает решение. Польза находится в исчезнувших шагах. Она уменьшается, если проверка растягивается, а исправление ошибок возвращает прежнюю работу через чёрный ход.
Поэтому я бы не начинал оценку агента с вопроса «сколько он сделал». Лучше сразу записать:
Эти показатели связывают работу агента с работой команды. Остальные числа объясняют, почему итог получился именно таким.
Фраза «агент ускорил разработку в три раза» ничего не значит без описания сравнения. Кто выполнял работу вручную? Были ли задачи одинаковой сложности? Совпадали ли критерии готовности? Включили ли в ручное время проверку, которую раньше делал сам исполнитель?
Нужен базовый уровень: несколько задач того же типа, выполненных без агента. Для каждой задачи стоит записать четыре вещи:
Сравнивать «написать небольшую функцию вручную» и «поручить агенту перестройку подсистемы» нельзя. Размер выборки здесь менее важен, чем сопоставимость. Десять похожих задач дадут больше пользы, чем тысяча запусков, перемешанных по сложности, риску и типу работы.
Критерии приёмки нужно записать до запуска. Иначе после результата планка начнёт двигаться: удачный ответ объявят готовым, неудачный — экспериментом. Так система почти неизбежно покажет успех.
Агент может работать час, пока человек занимается другими делами. Такой час может быть дешёвым. Бывает и обратная картина: агент выдаёт ответ за две минуты, но всё это время человек следит за процессом, уточняет команды, снимает блокировки и затем проверяет каждую строку. Две минуты на часах превращаются в дорогие две минуты.
Я разделяю время на четыре части:
Сумма этих частей — активное время человека. Именно его стоит сравнивать с ручным базовым уровнем.
Отдельно измеряется полная длительность цикла: от момента постановки до принятого результата. Она важна, когда работа лежит на критическом пути. Агент может сэкономить час внимания специалиста, но задержать выпуск на сутки из-за очереди или долгой проверки. В одном процессе это приемлемо, в другом перечёркивает всю экономию.
Получается две независимые оси: сколько внимания мы освободили и насколько быстро получили готовый результат. Смешивать их в один показатель нельзя.
Самая приятная метрика — стоимость запуска. Она обычно видна сразу: столько-то токенов, столько-то рублей, столько-то минут вычислений. Самая неприятная — стоимость приёмки. Её часто не записывают.
В приёмку входит чтение отчёта, проверка фактов, просмотр изменений, запуск тестов, ручная проверка результата и оценка последствий. Если найдена ошибка, добавляются исправление, новая постановка и повторная проверка. Иногда нужно ещё восстановить испорченные данные или откатить изменение.
Поэтому считать нужно не стоимость попытки, а стоимость принятого результата:
Предположим, ручная работа занимает 42 минуты. Агент тратит 17 минут своего времени, а человек — три минуты на постановку, семь на проверку и четыре на исправление. Для команды экономия составляет 28 минут человеческого труда, а не 25 минут разницы между ручной работой и длительностью запуска. Если исправление потребовало второго запуска, его вычисления тоже входят в счёт.
стоимость принятого результата = вычисления всех попыток + стоимость активного времени человека + ожидаемый ущерб от ошибок.
Особенно полезна доля результатов, принятых без доработки. Она быстро показывает зрелость процесса. Агент, который выдаёт десять ярких черновиков и заставляет переписывать девять, может выглядеть деятельным. Агент, чьи восемь спокойных результатов принимают сразу, обычно ценнее.
Простой счётчик ошибок уравнивает опечатку в черновике и неверно изменённые права доступа. Из-за этого безопасный агент с частыми мелкими огрехами может выглядеть хуже агента, который ошибается редко, но дорого.
Практичнее делить ошибки хотя бы на три класса:
| Класс | Пример | Как считать |
|---|---|---|
| Обратимая | неверный формат, опечатка, неудачное имя | минуты на исправление |
| Требующая восстановления | сломанная сборка, потерянное изменение, неверная миграция | исправление + простой + повторная проверка |
| Критическая | утечка данных, неправильный доступ, финансовое или правовое последствие | вероятность события × возможный ущерб |
Так появляется ожидаемая цена ошибки. Если критический сбой маловероятен, это не повод записывать его как ноль. Для задач с доступом к данным, деньгам и внешним системам редкий тяжёлый промах способен съесть экономию от сотен удачных запусков.
Измерение меняет и устройство процесса. Низкорисковые действия можно выполнять автоматически. Для дорогих ошибок нужны ограничения, изолированная среда, контрольные проверки и явное подтверждение человеком.
Для начала не нужна отдельная аналитическая платформа. Достаточно дополнить карточку задачи несколькими полями:
| Поле | Что записать |
|---|---|
| Тип задачи | поиск, изменение кода, анализ, подготовка текста |
| Сложность | простая, средняя, высокая — по заранее заданным признакам |
| Ручной базовый уровень | минуты и обычная доля ошибок |
| Время агента | полная длительность всех попыток |
| Время человека | постановка, наблюдение, проверка, исправление |
| Вычисления | стоимость модели и инфраструктуры |
| Повторы | число запусков до готового результата |
| Приёмка | сразу, после доработки, отклонено |
| Ошибка | класс, время исправления, возможный ущерб |
| Результат | что изменилось в рабочем процессе |
Последнее поле защищает от ещё одной подмены. «Создан отчёт» — это выпуск системы. «Инженер нашёл причину сбоя и сократил время восстановления» — результат работы. Агент может произвести много материалов, которые никто не использует. Их стоимость есть, пользы нет.
Из карточек можно получить пять показателей, достаточных для управленческого решения:
Я бы добавил разрез по типу и сложности задач. Среднее по всем работам скрывает главное: агент может отлично справляться с поиском и плохо — с изменениями, где цена ошибки выше.
На первых десяти задачах нельзя объявлять, что агент повышает производительность всей компании на 37 процентов. Но уже можно увидеть, где именно уходит время.
Для небольшой выборки подходит парное сравнение. Берём повторяемую работу, заранее определяем сложность и критерии приёмки. Часть задач выполняется обычным способом, часть — с агентом. Затем сравниваем медиану, а не только среднее: один зависший запуск или одна тяжёлая ручная задача не должны переворачивать картину.
Полезно показывать и разброс. Если агент обычно экономит 20 минут, но каждый пятый раз требует час восстановления, среднее значение маскирует риск. Команде важна предсказуемость, особенно на критическом пути.
Маленькая выборка ограничивает силу вывода, но не отменяет наблюдение. Она помогает решить, стоит ли продолжать, изменить границы задачи или отказаться от автоматизации этого участка.
Панель с числом запусков и токенов нужна инженеру, который обслуживает систему. Руководителю процесса нужен другой итог:
Формулу не обязательно сразу переводить в деньги. На первом этапе можно считать минуты специалистов, долю приёмки и цену исправлений. Главное — сохранить единицу результата. Не «один запуск» и не «один ответ модели», а работа, прошедшая заранее заданную приёмку.
польза на один принятый результат = стоимость ручного процесса − стоимость участия человека − стоимость вычислений − ожидаемый ущерб от ошибок.
Хороший отчёт приводит к одному из четырёх решений:
Если отчёт не помогает выбрать действие, перед нами журнал активности.
Выберите повторяемую работу, которая случается достаточно часто: разбор ошибки, подготовку изменения, проверку документа, сбор сведений. Найдите десять сопоставимых примеров ручного процесса и десять — с агентом. До начала запишите критерии приёмки. Во время работы измеряйте минуты человека отдельно от времени агента. После завершения учтите все проверки, исправления и повторные попытки.
Через двадцать задач у вас не появится универсальный ответ о пользе ИИ. Появится ответ лучше: в каком месте вашего процесса агент уже убрал ручную работу, а в каком только перенёс её в проверку.
Именно это стоит масштабировать.