ИИ может помочь найти алгоритм, после чего сам становится не нужен

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

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

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

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

И если после нескольких проверок я нахожу устойчивое правило, следующий шаг для меня может быть неожиданным:

убрать ИИ из рабочего контура и реализовать найденное правило обычным алгоритмом.

К этой мысли я пришёл именно из ограничений ИИ

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

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

В моих предыдущих экспериментах именно на расчётах риск ошибки становился слишком высоким.
Поэтому я предпочитаю другой порядок:

1. все показатели рассчитываются обычным кодом;
2. модель получает уже подготовленные значения;
3. я прошу её найти возможные сильные сигналы или предложить способы группировки;
4. результат проверяется человеком;
5. повторяющиеся полезные правила формализуются отдельно.

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

ИИ здесь нужен не для ответа, а для поиска гипотезы

Есть принципиальная разница между двумя задачами.
Первая:

Каждый день принимай решение по закупке вместо сотрудника.

Вторая:

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

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

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

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

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

Хороший сигнал должен пережить модель

Для меня полезность гипотезы начинается только после проверки.
Я хочу взять найденный сигнал и посмотреть:

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

Если после этого сигнал остаётся полезным, мне уже не обязательно каждый раз спрашивать модель заново.
Я могу записать правило напрямую.
Например:

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

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

На встрече уже был пример такого перехода

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

Мы увидели, что сотрудников полезнее сравнивать не одной общей массой, а группировать по сопоставимому объёму работы.
После этого ценность была уже не в том, чтобы нейросеть каждый раз снова формулировала эту мысль.
Ценность была в найденном принципе сравнения.
Такой принцип можно один раз встроить в отчёт.

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

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

Это похоже на временные строительные леса

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

На этапе исследования он помогает:

• быстро сформулировать несколько гипотез;
• увидеть необычные сочетания показателей;
• предложить варианты группировки;
• сравнить разные способы интерпретации;
• задать дополнительные вопросы к данным;
• ускорить обсуждение с экспертом.

Но конечная система может состоять уже из другого набора компонентов.
Расчёты.
Условия.
Приоритеты.
Автоматические задачи.
Черновики документов.
Эскалации человеку.

И никакой модели в этом участке рабочего процесса.

Почему для меня это не поражение ИИ

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

Я смотрю на это наоборот.
Моя задача не в том, чтобы сохранить модель в архитектуре любой ценой.
Моя задача в том, чтобы быстрее найти рабочий способ выполнения функции.

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

Для бизнеса важен не процент ИИ внутри решения.
Важно, что работа стала выполняться лучше.

Где я бы не спешил убирать модель

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

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

Но в закупочном кейсе значительная часть исходных данных уже структурирована.
Продажи представлены числами.
Остатки представлены числами.
Резервы известны.
История доступна.
Группы товаров определены.

Поэтому я могу отдельно спросить: какая часть решения действительно требует гибкой интерпретации, а какая после исследования превращается в набор проверяемых условий?

Чем больше второй части, тем меньше причин оставлять модель в постоянной эксплуатации.

Я бы разделил исследование на два контура

После этой встречи для себя я формулирую достаточно простой подход.

Первый контур - исследовательский.
Здесь можно использовать ИИ намного свободнее.
Я даю ему подготовленные данные.
Прошу искать гипотезы.
Сравниваю несколько вариантов.
Проверяю, какие сигналы кажутся содержательными эксперту.
Смотрю, где модель ошибается.
Цель этого этапа - не доверить ей решение, а быстрее понять саму задачу.

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

Эти два контура не нужно смешивать. Свободно экспериментировать в исследовании и так же свободно принимать операционные решения в боевой системе - совершенно разные уровни риска.

В закупках это меняет сам вопрос

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

Как научить нейросеть анализировать отчёт и подсказывать закупщику?

После разбора я бы сформулировал его иначе:

Какие полезные правила принятия решения мы пока не видим, и может ли ИИ помочь быстрее их обнаружить?

Это гораздо более узкая и проверяемая задача.

Допустим, я нахожу 10 гипотез.
6 отбрасываются.
2 оказываются очевидными и уже реализуются существующими расчётами.
1 полезна только в редком исключении.
И 1 стабильно помогает выделять нужные позиции.
Именно последнюю я хочу превратить в часть системы.
Не обязательно вместе с моделью.

Для меня это ещё одна причина начинать не с технологии

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

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

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

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

Все материалы этого исследования собраны в серии “Автоматизация оптовой компании”.

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