Как выбрать первый процесс для ИИ-автоматизации

• ИИ

К вопросам по статье

Ищите операцию, а не должность

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

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

Оцените пригодность задачи

• Она повторяется достаточно часто, чтобы улучшение было заметно.
• Есть примеры входных данных, которые разрешено использовать.
• Качество результата можно проверить по понятным критериям.
• Ошибка обнаруживается до значимого действия.
• Есть сотрудник, который может принять или исправить результат.
• Известно, как задача решается сейчас и сколько ресурсов занимает.

Определите контрольную выборку

Не выбирайте только удобные примеры. Добавьте короткие и длинные обращения, неполные данные, неоднозначные формулировки и случаи, в которых правильный ответ — запросить уточнение.

Для каждого примера определите признаки пригодного результата. Например: нужные поля извлечены, ничего не выдумано, неизвестные значения отмечены, итог не требует полного переписывания человеком.

Практический выбор: сравните несколько операций на одном листе

Сравните хотя бы два кандидата на материалах одной команды. Для каждой операции найдите несколько разрешённых исходников и попросите сотрудника показать пригодный результат. Если он не может объяснить, где ответ верен, а где его надо вернуть на уточнение, пилот пока проверит впечатление от текста, а не помощь в работе.

Сначала сравните пригодность, а не привлекательность демонстрации. Эффектный диалог может быть редкой задачей без понятного потребителя. Неприметное извлечение нескольких сведений из повторяемого обращения иногда даёт более удобный пилот: результат проверяется по исходнику, а границы легко сохранить.

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

Рабочий процесс пилота: от потребности до решения о развитии

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

Первый шаг — назвать проблему без готовой технологии. Например, сотруднику приходится выделять одни и те же сведения из входящего текста. Уточните, какие поля нужны дальше и как сегодня проверяют их правильность. Если вопрос в отсутствии единого формата, иногда достаточно обычной формы или правила. Сравнение простого варианта должно происходить до затрат на сложный ИИ-маршрут.

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

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

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

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

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

Паспорт пилота, который можно согласовать до разработки

В GlossCheck я разработал ИИ-сервис с чатом, файлами, историей и настройками использования. Этот опыт относится к устройству инструмента вокруг модели. Для нового пилота качество конкретной операции всё равно нужно измерить на ваших разрешённых материалах; наличие готового чата не доказывает полезность резюме, классификации или поиска в другой компании.

Как подготовить выборку без удобного отбора

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

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

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

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

Матрица оценки одного результата

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

Как разобрать неудачный результат по причине

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

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

После исправления повторите исходный и соседний случай. Если правило изменено для длинного текста, проверьте, что короткий не потерял важный смысл. Если добавлена проверка данных, убедитесь, что она не отклоняет нормальные обращения. Исправление полезно, когда причина устранена, а не когда единственный пример наконец выглядит убедительно.

Как оценить ресурсы пилота

Учитывайте подготовку данных, настройку, выполнение, проверку и разбор исключений. Для эксплуатационной оценки важны входной объём, результат, инструменты и повторы по всей цепочке. Не берите стоимость одного короткого ответа за стоимость любого обращения. Разные типы задач могут существенно различаться по составу обработки.

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

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

Как решить, что делать после пилота

Развивать имеет смысл, когда согласованный тип входа даёт пригодный результат, проверка управляемая, а ограничения понятны. Сузить — когда полезность подтверждена только для определённой группы. Изменить — когда причина связана с источниками, структурой задачи или процессом. Остановить — когда выбранная гипотеза не дала достаточной пользы либо требует несоразмерного сопровождения.

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

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