AI-нутрициолог. Небольшой pet-проект по анализу состава продуктов

Каждый поход в магазин для меня был квестом. Стоишь у полки, вертишь в руках упаковку и пытаешься расшифровать состав, написанный мелким шрифтом. Что такое «фосфат калия»? Насколько вреден «сорбит»? Это вообще съедобно? Мне надоело постоянно гуглить каждый ингредиент.

Я решил, что соберу себе личного AI-нутрициолога, который будет жить в Telegram и делать всю эту скучную работу за меня. Так родился Foody Scan — мой pet-проект, который из простой идеи превратился в сервис с AI-анализом, базой данных и даже монетизацией через Telegram Stars.

И самое интересное — я собрал его практически целиком на no-code/low-code стеке, разместив на собственном хостинге. Ниже я покажу, как он устроен под капотом, какие инженерные костыли пришлось изобретать и почему этот опыт оказался ценнее любого ютуб-ролика по подобным штукам.

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

Каждый запрос на обработку фото через LLM/vLLM обходился мне примерно в 3-4 рубля. Даже с бесплатным лимитом в 3 анализа в день, если бы бот внезапно «хайпанул» и им начали пользоваться хотя бы 100 человек, я бы улетел в минус за пару дней.

Поэтому монетизация через Telegram Stars — это не попытка заработать, а, по сути, решение для самоокупаемости. Простая страховка от случайного успеха.

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

Давайте по шагам разберем, что происходит, когда пользователь отправляет боту фотографию этикетки.

Шаг 1. Регистрация и проверка.

Когда пользователь впервые пишет боту, Telegram Trigger в n8n ловит это событие. Сценарий первым делом идет в Supabase и проверяет: есть ли такой user_id в базе? Если нет — создает новую запись с базовым балансом сканирований. Если есть — просто обновляет время последней активности. Стандартная, но обязательная рутина.

Шаг 2. Запрос на анализ и проверка баланса.

Пользователь отправляет фото. Воркфлоу проверяет, что это именно фото, а не текст, и снова лезет в Supabase, чтобы посмотреть поле usage_limit. Если баланс позволяет (например, больше 10 «пончиков» 🍩, это местная валюта в боте), процесс идет дальше. Если нет — пользователю вежливо предлагается пополнить баланс командой /topup.

Шаг 3. OCR (Распознавание) с помощью Vision-модели.

Это первый и самый важный этап AI-анализа.

Шаг 4. Анализ и оценка с помощью текстовой LLM.

Теперь у нас есть чистые, структурированные данные. Их мы отправляем во вторую, уже чисто текстовую модель (google/gemini-2.0-flash-001), которая получает гораздо более сложную роль.

Шаг 5. Форматирование и отправка отчета.

Полученный от второй LLM JSON — это еще не готовый отчет. Он содержит данные, но не форматирование. Поэтому последним шагом идет нода Code, в которой простой JavaScript-код собирает из этого JSON красивое, отформатированное HTML-тегами сообщение для Telegram, расставляет эмодзи, выделяет заголовки жирным и формирует инлайн-кнопки («Показать полный состав»).

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

Я решил попробовать новую фичу Telegram — оплату «звездами». И тут же выяснилось, что в n8n нет и, скорее всего, не будет готовых нод для этого.

Я наивно полагал, что одна большая модель решит все мои задачи. Как же я ошибался.

Мощные модели работают медленно. Анализ одного фото занимал от 60 до 120 секунд. Для пользователя это вечность, за которую он успеет подумать, что бот сломался, и уйти.

LLM API иногда «моргают»: возвращают ошибку сети, невалидный JSON или просто тайм-аут. Встроенные в n8n ретраи не всегда помогали, так как ошибка могла быть на уровне данных, а не соединения.

Supabase, а точнее — особенность его бесплатного тарифа, о которой я знал, но не придал значения. Если к вашему проекту нет обращений в течение 7 дней, Supabase ставит его на паузу. База данных просто отключается.

Да, они присылают email-предупреждение, но в потоке сотен писем его легко пропустить. Для пользователя это выглядит как полная поломка сервиса. Для меня это означало панический забег в админку Supabase, чтобы вручную нажать кнопку "Restore project" и ждать, пока он "проснется".

Этот проект — живое доказательство того, что n8n — это лучший MVP и худший продакшн. Я подробно разбирал эту дилемму в отдельной заметке, где собрал основные "боли", с которыми сталкивается сообщество, и четко разграничил, когда n8n — идеальный выбор, а когда нужно сразу смотреть в сторону кода.

Проект Foody Scan научил меня главному: порог входа в создание реальных AI-продуктов стал прозрачней. Немного не по себе представлять, что больше не нужна команда из 10 человек и несколько недель на разработку MVP. С помощью инструментов вроде n8n, Supabase и готовых LLM-моделей можно в одиночку за несколько вечеров собрать, протестировать и запустить работающий сервис. Не сказать, что идеальный, но самое главное – работающий.

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

А какие pet-проекты вы собирали на подобных стеках? Сталкивались с похожими проблемами? Поделитесь в комментариях!