Продуктовый магазин, который берётся накормить 200 человек за один заход, это уже не магазин, а маленькое производство. Edy's Grocer из таких: розница плюс кейтеринг, где крупная заявка превращается в задачу на планирование. Три сценария в этой работе закрывает Gemini, и интересны здесь не сами сценарии, а то, почему они вообще уходят модели.
Три этапа, на которых обычно ломается закупка
Логика кейса простая: крупный заказ разбивается на три этапа, и на каждом своя задача. Сначала меню под конкретное число гостей. Потом пересчёт рецептур и закупка под них. Потом организация самого дня: кто, что и когда готовит, что везут, что делают на месте.
Ни один из этих этапов не про кулинарное творчество. Все три про арифметику, ограничения и бумаги. Именно поэтому они и уезжают модели, а не шефу.
Почему рецепт нельзя просто умножить на 50
Четыре порции превратить в двести - это коэффициент 50. Звучит как одно действие, на деле нет.
Соль, специи, загустители и разрыхлители масштабируются нелинейно: удвоение объёма не значит удвоение всего списка. Меняется время термической обработки, потому что масса прогревается иначе. Меняется посуда, потому что десять литров соуса не варят в той же кастрюле, что литр. Меняется логика закупки, потому что продукт продаётся упаковками, а не граммами.
Человек с калькулятором проходит этот путь и на третьем ингредиенте начинает округлять в свою пользу. Модель держит весь список сразу и пересчитывает его целиком.
Что всё равно проверяют руками
- итоговые граммовки по каждому пункту, особенно по специям и соли;
- единицы упаковки: заказ в килограммах, а поставка в коробках;
- сроки годности и температуры хранения, тут модель ничего не гарантирует;
- санитарные нормы и требования площадки, где проходит мероприятие.
Меню под 200 гостей: ограничения важнее вкуса
На двухстах человек вкус перестаёт быть главным вопросом. Главными становятся аллергии, вегетарианцы и постящиеся, дети, бюджет на порцию, сезонность продуктов и то, что вообще есть у поставщика на этой неделе.
Это задача на перебор вариантов с ограничениями, и она модели даётся легко: собрать несколько версий меню, предложить замены под каждый запрет, посчитать, как изменение одного блюда тянет за собой закупку. Быстрее, чем вручную, и без забытых пунктов.
Ответственность при этом никуда не девается. Если гость с аллергией получит не то, виноват не чат-бот, а тот, кто подписал меню.
Где модель ошибается и как это ловить
Основная проблема не в том, что LLM не умеет считать, а в том, что она одинаково уверенно выдаёт и верный расчёт, и выдуманный. Цены поставщиков, наличие товара, конкретные бренды, нормы по конкретной площадке - всё это модель может сочинить с абсолютно ровным тоном.
Отсюда рабочий порядок: модель делает черновик, человек сверяет его с прайсом, складом и технологом. Не наоборот. Если сначала посчитать закупку, а потом удивиться счёту, экономия превращается в убыток.
Что из этого кейса применимо к малому бизнесу
Кейс про еду, но механика универсальная. Пересчёт объёмов, смета под нестандартный заказ, шаблон письма поставщику, черновик коммерческого предложения - везде одна и та же схема: есть таблица, которую каждый раз собирают руками, и есть модель, которая соберёт её за секунды.
Правило отбора простое. Если задача повторяется, состоит из чисел и правил, и её результат потом кто-то проверяет, это хороший кандидат. Если задача разовая, творческая или цена ошибки необратима, модель остаётся на подхвате, но решение принимает человек.
Стоит ли тащить это на свою кухню
Gemini в этом кейсе не повар и не технолог. Это ассистент по арифметике и бумагам, который экономит часы, а не улучшает вкус. Начинать разумно с одного повторяющегося расчёта, который сейчас делают вручную, и с честной проверки на выходе. Масштаб в 200 гостей тут не главное, главное, что считать перестали в блокноте.