Три вопроса, которые я задаю любой цифре от ИИ, прежде чем нести её руководителю
Полтора месяца назад я чуть не озвучил на совещании цифру, которая была занижена в восемь раз. ИИ посчитал по выгрузке остатков, сколько кубометров освободится после пересортировки одной товарной группы. Число выглядело аккуратным и правдоподобным. Я решил проверить его руками за час до совещания — просто по привычке, без особого повода. Хорошо, что проверил: с той цифрой я бы пообещал руководству свободные места, которых на самом деле нет, а через месяц пришлось бы объяснять, почему склад снова забит под потолок.
Все цифры и товарные позиции здесь изменены и округлены, речь не о конкретном складе. Это не реклама инструмента — только про три проверки, которые я теперь прогоняю сам, прежде чем нести любую цифру от ИИ наверх.
Раньше процесс был простым: выгрузка остатков в CSV, промпт «посчитай суммарный объём по категории», готовый ответ вставляю в презентацию. Работало месяцами на привычных категориях, где количество и физическая единица совпадают один в один: пришла коробка — записали коробку. Ощущение надёжности росло с каждым разом, пока не сложилось три случая подряд.
Утеплитель. Часть позиций в справочнике заведена в штуках, часть — в упаковках, а упаковка там содержит восемь рулонов. Кладовщики годами приходовали товар кто во что горазд: кто-то заводил каждую упаковку отдельной строкой, кто-то — как одну позицию с количеством восемь. ИИ честно сложил колонку «количество» по всем строкам, не сверяя единицу измерения у каждой из них. Для трети ассортимента это дало восьмикратное завышение объёма. Заметил я это не по логике, а случайно: цифра по одной подкатегории оказалась больше, чем физически помещается на всём стеллаже под неё, и я это знал на глаз, потому что хожу мимо этого места каждую неделю. После разбора завёл отдельный столбец «физическая единица хранения» в справочнике, и теперь любой расчёт объёма сначала приводит всё к нему, а не берёт колонку «количество» как есть.
Бухты. Название товара вида «Шланг поливочный, бухта 25 м» хранит длину прямо в тексте, а в остатках стоит количество бухт, не метров. Три бухты по 25 метров — это 75 погонных метров, но если считать по названию буквально, легко принять «3» за метраж и потерять на порядок. У меня в одном расчёте так пропало примерно 90% фактической длины кабельной продукции. Нашёл это не сразу: сначала цифра просто показалась маленькой, и я списал это на низкий спрос в межсезонье. Пересчитал только когда сверял с прошлогодней закупкой того же периода — расхождение было слишком большим, чтобы объяснить его сезонностью. Корень тот же, что в статье про 380 ошибок в справочнике габаритов: название и структурированные данные о товаре живут отдельно друг от друга, и пока это так, любой автоматический счёт рискует принять одно за другое.
Клей. Остаток 0,02 литра среди соседних позиций по 4–6 литров. Человек такое видит сразу: это опечатка или потерянный ноль, а не реальный остаток. ИИ такую цифру просто суммирует вместе с остальными, потому что формально это валидное число в нужной колонке. Разобрался в причине уже постфактум: при приёмке товара кладовщик один раз вбил объём в миллилитрах в поле, которое система читает как литры. Ошибка одной строки, но она незаметно тянула вниз средний показатель по всей подкатегории, и по отчётам казалось, что клей заканчивается быстрее обычного, а на деле остатка было в разы больше.
После этого я стал добавлять к любому промпту на агрегацию отдельный блок проверки, и он теперь идёт первым, до самого расчёта:
Первая версия этого промпта не сработала: я просто попросил «проверь данные на ошибки перед расчётом» и получил в ответ общую фразу про то, что данные выглядят корректно. Пришлось расписать, что именно значит «ошибка» в этом контексте — иначе модель проверяет то, что легко проверить (пустые ячейки, отрицательные числа), а не то, что реально ломает расчёт.
Проверка не ловит всё. Она находит грубые расхождения — на порядок и больше, а более тонкие ошибки единиц, где значения отличаются не в разы, а на десятки процентов, через неё до сих пор проскакивают. Плюс это дополнительный шаг перед каждым расчётом, и на потоковых ежедневных цифрах его прогонять избыточно — годится для разовых сводных отчётов, которые идут наверх, а не для каждого чата с ИИ.
Более широкий вывод для себя я сформулировал так: проблема не в том, что ИИ считает неправильно. Он считает ровно то, что написано в данных, буквально и без иронии. Проблема в том, что я долго путал «модель посчитала» с «модель проверила», а это разные вещи. Арифметику можно отдать полностью, суждение о том, доверять ли исходным цифрам — нет, и этот шаг всё ещё держится на человеке, который знает, как физически выглядит склад за этими цифрами. Три вопроса выше — не разовый фикс, а попытка формализовать именно эту часть работы, чтобы она не зависела от того, вспомню ли я в этот раз проверить или нет.
Дальше — разбор: пересчитал топ-500 товаров по 11 правилам и нашёл больше сотни, живущих не в своей категории.
Вопрос к тем, кто уже гонял похожие проверки: какой четвёртый вопрос вы бы добавили в этот список — то, что один раз подвело именно вас?
В Telegram выложил сам чек-лист отдельным файлом — три вопроса плюс шаблон промпта целиком, можно сразу вставлять в свои расчёты: t.me/ii_na_skladah