Прикладной ИИ и машинное обучение
Разработка ИИ-систем под задачи бизнеса
Разработка ИИ-систем под задачи бизнеса начинается с нужного результата: что должна сделать программа, на каких данных и как человек проверит её работу. GradientPrime помогает оценить применимость ИИ и определить программное решение для конкретного процесса.
Сначала сравниваем задачу с возможностями более простых правил и готовых средств. Если ИИ применим, обсуждаем данные, прототип, критерии качества и включение результата в работу. Модель — часть системы; для использования нужны также интерфейс, права, обработка ошибок и контроль.
Какая задача требует проверки применимости ИИ
Полезно сформулировать одну операцию и решение, которое следует за ней. Например: определить тему обращения, извлечь нужные поля из документа или подготовить прогноз для планирования. Само желание «внедрить ИИ» не задаёт требований к системе.
Условный пример: сотрудники распределяют обращения о сервисном обслуживании между группами исполнителей. Формулировки разные, часть обращений содержит несколько тем. Можно проверить, поможет ли модель предложить категорию и выделить сведения, которые сотрудник должен уточнить.
Сначала нужно выяснить, как люди выполняют операцию сейчас, какие ошибки существенны и какие правила уже известны. Если нужная категория определяется выбранным полем формы, может быть достаточно обычной логики. Для неоднозначного текста требуется проверка на примерах.
Для обследования: кто использует результат, какое действие выполняет после него и что происходит, если результат неверен? Ответ определяет границы автоматизации и обязательное участие человека.
Определить программный результат
ИИ может быть отдельным компонентом приложения или частью внутреннего процесса. Если задача решается формой, расчётом по известному правилу или обычным обменом данными, проект можно обсуждать как заказную разработку ПО.
Документы, классификация, прогнозирование и аналитика как сценарии
Ниже — возможные направления для проверки, а не перечень готовых универсальных функций. Для каждого сценария нужны собственные данные, ожидаемый результат и способ оценки.
Обработка документов
Можно проверить извлечение согласованных полей из документов разных форматов или поиск фрагментов для проверки сотрудником. Нужно определить виды документов, качество исходных файлов и допустимость пропусков.
Условный пример: программа предлагает номер заявки и описание неисправности из письма с вложением, а сотрудник сверяет поля с источником перед сохранением.
Работа с документамиКлассификация обращений
Для распределения по темам сначала описывают категории и разбирают неоднозначные примеры. Должно быть понятно, можно ли назначить несколько категорий и когда обращение нужно передать на ручной разбор.
В примере с обслуживанием сообщение может одновременно содержать вопрос о документах и описание поломки. Правильный результат зависит от согласованного порядка работы с такими случаями.
Прогнозирование
Прогноз можно обсуждать, если доступны история, понятный показатель и горизонт планирования. Перед применением модели проверяют, как собирались данные и какие изменения влияют на сравнимость периодов.
Условный пример: оценка числа обращений для планирования работы. Прогноз сравнивают с простым ориентиром, например предыдущим сопоставимым периодом; сам запрос на прогноз не делает ИИ обязательным.
Аналитика и поиск по материалам
Можно рассмотреть подготовку тематической сводки или поиск ответа в заданном наборе материалов. Для обсуждения нужны источники, права доступа и правило проверки каждого существенного вывода.
Условный пример: сотрудник получает подборку повторяющихся причин обращений со ссылками на исходные записи. Если нужен точный подсчёт по известным полям, сначала рассматривают обычный запрос и отчёт.
Данные и критерии качества результата
Качество оценивают относительно действия пользователя и последствий ошибки. Нужны примеры входа, ожидаемый результат и согласованные правила, по которым его можно признать пригодным.
Собрать представительные примеры
В набор для проверки включают обычные случаи, редкие важные ситуации, неполные и неоднозначные данные. Уточняют источник, возможность использования, правила доступа и необходимость обезличивания.
Для классификации обращений полезны примеры каждой категории и случаи разногласия сотрудников. Если люди по-разному понимают правильный ответ, сначала нужно уточнить правила.
Определить цену разных ошибок
Одного общего показателя может быть недостаточно. Нужно различить ошибочную категорию, пропущенное поле и необоснованный ответ, а затем определить, какие результаты требуют обязательной проверки.
В условном примере ошибочная передача обращения другой группе и пропуск срочного обращения имеют разные последствия. Критерии задают отдельно для значимых категорий.
Проверить результат в условиях работы
Часть примеров оставляют для проверки после настройки подхода. Помимо качества ответа обсуждают время ожидания, затраты на обработку и объём ручного контроля. Значения критериев согласуются под задачу.
Для обследования: по какому набору новых примеров можно решить, что система помогает сотруднику, и кто подтверждает правильность эталонного результата?
Прототип и сравнение с более простым подходом
Прототип нужен для проверки конкретной гипотезы на согласованных данных. Он помогает решить, стоит ли продолжать разработку, изменить постановку задачи или выбрать другой способ автоматизации.
1
Выбрать одну операцию
Фиксируем вход, ожидаемый выход и границы примера. Для обращений это может быть предложение категории с передачей спорных случаев человеку; полный процесс обслуживания в прототип включать необязательно.
2
Подготовить простой ориентир
Описываем действующую ручную работу или подход на понятных правилах. На одних и тех же проверочных примерах сравниваем полезный результат, ошибки и необходимость ручного исправления.
3
Проверить вариант с ИИ
Выбираем способ применения модели с учётом задачи и доступных данных. На примерах, не использованных для настройки, проверяем качество, задержку и затраты. Отдельно разбираем важные ошибки и неопределённые ответы.
4
Принять решение о следующем шаге
Если результат соответствует согласованным критериям, определяем состав рабочей версии и проверки интеграции. Если нет — обсуждаем уточнение категорий, подготовку данных, ограничение сценария или более простой подход.
Результат прототипа относится к проверенному набору и условиям. Он не подтверждает готовность к любым документам, нагрузке или изменениям процесса. Переход к рабочей системе требует отдельной проверки прав, интерфейса, ошибок и действий пользователей.
Интеграция в рабочий процесс и контроль человеком
До включения ИИ в работу определяют, откуда поступают данные, где сотрудник видит результат и какое действие разрешено выполнить дальше. Предложение модели и подтверждённое решение должны быть различимы.
В условном примере модель предлагает категорию обращения, сотрудник видит исходный текст и может подтвердить или исправить предложение. Если данных недостаточно либо случай выходит за согласованные границы, обращение остаётся доступно для ручного разбора.
Нужно предусмотреть недоступность модели, повторную обработку и изменение обращения после получения ответа. До сохранения или передачи результата проверяются права и согласованные правила процесса. Критичные действия не должны зависеть от непроверенного свободного ответа.
Способ сбора исправлений обсуждают отдельно: какие сведения нужны для разбора ошибок, кто их видит и как они используются при следующей проверке. Исправление сотрудником не следует автоматически считать разрешением на обучение или изменение работающей модели.
Связать компонент с системой
Если результат передаётся в другую программу, нужны правила обмена и подтверждения. Если для работы сотрудников создаются новые роли, очереди и состояния, их описывают как часть внутренней информационной системы.
Ограничения, состав работ и развитие системы
Объём проекта определяется проверенной задачей, состоянием данных и условиями применения. До разработки согласуем, что входит в поставку и какие решения требуют дополнительных исследований.
Определить состав проекта
В проект могут входить обследование, подготовка данных, проверка подхода, разработка компонента и интерфейса, интеграция и приёмка. Размещение, допустимые способы обработки данных и использование внешних сервисов обсуждаются с учётом ограничений заказчика.
На оценку влияют разнообразие входных данных, сложность проверки, число подключений и объём контроля человеком. Сроки, стоимость и целевые показатели качества уточняются по задаче и результатам обследования.
Проверять изменения после запуска
Новые документы, категории и правила работы могут изменить пригодность результата. До обновления модели или настроек полезно повторять согласованную проверку, включая важные ошибки и сценарии передачи человеку.
В условном примере появление нового типа обращения требует пересмотра категорий и проверочных примеров. Заранее определяют, кто замечает такое изменение, кто подтверждает результат проверки и как организован возврат при неудачном обновлении.
Рабочая система должна иметь явно описанные границы: с какими данными она проверена, какой результат выдаёт и когда требуется участие человека. Сопровождение, наблюдение за качеством и дальнейшее развитие согласуются для проекта отдельно.
Частые вопросы
Вопросы перед заказной разработкой ИИ-системы
Обсудим задачу и способ проверки ИИ
Расскажите, какое действие требуется автоматизировать, какие данные доступны и кто использует результат. Описание текущей работы и обезличенные примеры помогут определить, что проверить в первую очередь и нужен ли для этого ИИ.
Обсудить задачу