Руководитель просит внедрить ИИ для распределения заявок. За этой формулировкой могут стоять разные действия: проверить заполнение полей, назначить специалиста по расписанию, предсказать срок обработки или понять свободный текст обращения. Каждому действию подходит свой способ решения.
Выбор начинается с описания результата. Если ответ задается известным правилом, команда формализует правило. Если предстоит распределить ограниченные ресурсы, рассматривает оптимизацию. Для прогноза по накопленной истории сравнивает статистические методы и машинное обучение. Для работы с текстом оценивает языковую модель вместе с источниками и проверками.
Ниже приведена методическая матрица. Она помогает задать вопросы к задаче и подготовить проверку кандидатов. Окончательный выбор опирается на примеры, требования и измерения конкретного проекта.
Правила: точное действие по известному условию
Представим обработку заказа. При заполненном адресе, подтвержденной оплате и готовом товаре оператор переводит заказ на следующий шаг. Условия можно описать явно и проверить на примерах. Здесь полезны обычная программная логика, таблица решений и удобный интерфейс.
В таблице решений каждой комбинации условий соответствует действие. Рядом стоит указать, кто имеет право менять статус и что произойдет при изменении исходных данных. Разработчик получает проверяемое описание, а сотрудник видит причину выбора системы.
Правила особенно удобно проверять в пограничных случаях. Оплату только что отменили, товар готов частично, адрес изменился после подтверждения. Для каждого случая владелец процесса задает допустимый результат. Ошибка в самом бизнес-правиле требует обсуждения с владельцем, а ошибка кода требует исправления реализации.
Количество правил со временем может вырасти. Тогда оцените, сохраняется ли ясность таблицы и сколько стоит ее поддержка. Это основание сравнить другие подходы на тех же примерах.
Оптимизация: распределение при ограничениях
Другой тип задачи возникает, когда правильных вариантов много. Например, нужно распределить работы между сотрудниками с учетом навыков, смен и обещанных сроков. Команда определяет ограничения и цель: сократить опоздания, уменьшить пробег или распределить загрузку по выбранному принципу.
Инструменты математической оптимизации ищут подходящие варианты среди возможных комбинаций. Официальное описание Google OR-Tools приводит маршруты, расписания и размещение грузов как примеры таких задач. Конкретный метод и критерий качества зависят от постановки. Обзор OR-Tools.
Для заказчика полезен список двух видов условий. Обязательные условия определяют допустимость: вместимость машины, квалификация сотрудника, временное окно. Предпочтения помогают сравнивать допустимые варианты: более короткий маршрут, равномерная загрузка, удобный порядок действий.
В кейсе TMS описаны габариты, масса, колесная база и ограничения загрузки автомобилей. Это предметный пример того, как ограничения формируют бизнес-систему. Описание кейса подтверждает саму задачу и ее параметры; выбор конкретного класса алгоритмов требует отдельного технического материала.
ML: прогноз по наблюдениям
Для прогноза спроса, оценки времени обработки или ранжирования предложений сначала определите, что именно предстоит предсказывать. Нужны единица наблюдения, момент принятия решения и правильный ответ, который станет известен позже.
В методическом примере компания прогнозирует спрос на товар на следующую неделю. Команда описывает продажи, остатки, возвраты и периоды ограниченной доступности товара. Затем сравнивает модель с понятным исходным способом, например повторением значения прошлого сопоставимого периода. Такой способ называют baseline.
Google советует начинать ML-проект с простой модели и надежной передачи данных. Этот подход позволяет увидеть вклад усложнения и разобраться в причинах изменений результата. Инженерное руководство Google.
При проверке важно сохранить условия момента прогноза. Значения, появившиеся позже, относятся к будущему результату. Их попадание в подготовку признаков создает утечку данных и завышает оценку. В документации scikit-learn отдельно рассматриваются разделение выборок и контроль такой утечки. Практики проверки scikit-learn.
Полезность прогноза оценивает владелец решения. Для закупок существенны последствия избытка и дефицита. Для очереди обращений существенны просрочка и ручное перераспределение. Метрика модели должна помогать обсуждать эти последствия.
LLM: работа с языком и документами
Языковую модель стоит рассмотреть, когда сотрудник обрабатывает разные формулировки, составляет текст по сведениям или ищет ответ в документах. Пример результата: черновик сообщения, категория обращения, извлеченные поля, объяснение найденного регламента.
Проверка строится вокруг конкретного выхода. Для сообщения важны верность фактов и пригодность текста. Для категории важно правильное направление обращения. Для полей важны значения и связь с оригиналом. Общая оценка «ответ понравился» слишком широко описывает разные задачи.
Разделите получение сведений и подготовку текста. Статус заказа приходит из учетной системы. Модель может сформулировать объяснение этого статуса. Переход заказа на другой этап проходит через отдельные правила и права пользователя. Такое устройство дает понятные точки контроля.
Технический выбор тоже проверяется на задаче. Модель общего назначения, поиск по документам, настройка инструкций и дообучение решают разные части проекта. Сначала сформулируйте причину ошибки на примерах, затем выбирайте способ ее устранения.
Матрица для встречи с командой
| Вопрос | Кандидат для проверки | Что подготовить | Как оценить результат |
|---|---|---|---|
| Действие следует из известных условий? | Правила и обычная автоматизация | Таблица условий и исключений | Совпадение с утвержденными решениями. |
| Нужно распределить ресурсы при ограничениях? | Математическая оптимизация | Ограничения, предпочтения и входные задачи | Допустимость варианта и выбранная цель. |
| Нужно предсказать значение по истории? | Статистика и ML | Наблюдения, целевая величина и исходный способ | Качество на отложенных примерах и польза решения. |
| Нужно понять или подготовить текст? | LLM и подходящие инструменты | Примеры запросов, источники и эталонные результаты | Верность выхода, объем исправлений и труд сотрудника. |
Матрицу можно заполнить для каждого шага одного процесса. В распределении заявок модель определяет тему письма, правила проверяют обязательные поля, а планировщик выбирает время исполнителя. Система связывает результаты через согласованные идентификаторы и статусы.
Как провести сравнение подходов
Выберите характерные случаи и заранее запишите правильный результат. Добавьте сложные примеры: несколько подходящих категорий, конфликт расписания, редкое сочетание условий. Согласуйте, кто разберет спорный ответ и как будет фиксироваться решение.
Сравнивайте полный рабочий путь. Учитывайте получение данных, время ответа, проверку человеком и исправление. Если модель быстро создает текст, а сотрудник долго сверяет источники, это должно попасть в оценку. Для вариантов с разной степенью автоматизации сохраняйте одинаковое определение завершенной задачи.
По итогам сравнения составьте короткий документ: выбранный подход, проверенные примеры, измерения, ограничения и следующий этап. Отдельно укажите, какие вопросы еще требуют эксперимента. Этот документ связывает инженерный выбор с бюджетом и ожиданиями бизнеса.
Обсудить ИИ-разработку можно с одного рабочего действия и примеров правильного результата. Для задач с известными правилами подходит разговор об автоматизации процесса, а для прогнозов и показателей полезна оценка аналитического контура. Команда сможет сравнить варианты на общем языке: данные, действие, результат и приемка.