CV catering: распознавание еды для робота-кассира

Нужен pipeline: quality checks, tray/dish detection, recognition/classification, business rules по меню и ценам, confidence fallback и жесткий latency budget около пары секунд.

Постановка здесь не "просто классифицировать картинку". На входе фото подноса, на выходе список блюд, их количество и чек. Поэтому pipeline лучше строить слоями: контроль качества кадра, детекция зон/тарелок/блюд, распознавание блюда, сверка с меню конкретной точки и расчет цены.

Данные критичны: меню локальное, блюда похожи, рецепты и подача меняются. Нужны фотографии из реальных точек, разметка блюд, hard cases с перекрытиями, плохим светом, перемешанной едой и новыми позициями. Для confidence ниже порога нужен fallback: ручная проверка, подсказка оператору или уточнение пользователю.

В production главное ограничение - latency. Модель, которая отвечает 40 секунд, может быть полезна как teacher/offline разметчик, но не как кассовый inference.

Смешанная еда ломает четкие границы объектов: одно блюдо может лежать внутри другого, классы похожи визуально, а cosine similarity начинает сравнивать смесь, а не отдельный item.

У обычной object detection задачи есть относительно понятные объекты. В столовой это часто не так: рис, овощи, соус и мясо могут лежать в одной зоне, перекрывать друг друга и визуально смешиваться. Поэтому bounding box или segmentation mask не всегда соответствует "блюду" как позиции в меню.

Metric learning тоже не магия. Если embedding считается по кропу, где внутри сразу несколько блюд, расстояние отражает смесь признаков. Hard negatives появляются постоянно: похожие гарниры, разные блюда одного цвета, разные подачи одного блюда, локальная кухня, которую модель не видела.

Практичный ответ - гибрид: ограничения меню конкретной точки, несколько view/камер, quality checks, business rules, confidence thresholds, active learning на ошибках и, возможно, VLM/teacher для разметки или reranking.

Большую VLM лучше использовать offline: как teacher для разметки, проверки сложных кейсов, генерации pseudo-labels и анализа ошибок. Online нужна маленькая модель или специализированный VLM, дообученный на меню/еда-домене.

Если пользователь стоит у кассы, 40 секунд inference недопустимы. Поэтому дорогая VLM может быть полезна не в online path, а в offline loop: помогать разметчикам, находить сложные примеры, генерировать pseudo-labels, объяснять ошибки и строить training set для более дешевой модели.

Online-path должен быть быстрым: специализированный detector/classifier/retriever, маленькая VLM, distillation от большой модели, quantization, batch/edge inference и жесткий timeout. Контекст меню конкретной точки можно заранее индексировать или кодировать, чтобы не прокидывать десятки изображений в prompt каждый раз.

В ответе важно назвать fallback: если confidence низкий, отправить на ручную проверку или показать оператору top-k вариантов, а не заставлять всех ждать большую модель.

Нужен цикл мониторинга ошибок, сбора hard cases, постановки разметки, дообучения, offline/online проверки, версионирования модели и безопасного rollout на точки.

После rollout CV модель почти неизбежно деградирует на новых точках: меняется меню, освещение, посуда, способы подачи, камеры и поведение людей. Поэтому production-loop должен быть частью системы, а не разовым обучением.

Минимальный loop: логировать predictions, confidence, фото с ошибками и исправления оператора; регулярно выбирать hard cases; отправлять их в разметку; дообучать модель; сравнивать с текущей версией на regression set; выкатывать постепенно и мониторить бизнес-метрики.

Для edge/on-device deployment важны формат модели, совместимость с железом, версия меню/модели и откат. Если есть несколько камер или classic CV алгоритмы, они тоже должны иметь тесты и документацию, а не жить как одноразовый notebook.