Коли це вам потрібно
Ручне ведення щоденника харчування — це те місце, де вмирають хороші харчові звички. Щоб зафіксувати тарілку курячого каррі старим способом, користувач шукає "chicken curry", прокручує список, вгадує розмір порції і повторює це для кожного елемента на тарілці. Це точно в теорії та занедбано на практиці — тертя переважає мотивацію.
Камера все це спрощує. Наведіть телефон на страву, і за кілька секунд відповідні рецепти з повною інформацією про харчування будуть готові до фіксації. Цей шаблон завойовує своє місце, коли збір даних є бар'єром між користувачами та цінністю вашого продукту — коли "просто зробіть фото" може замінити багатоетапний ручний ввід. Це та проблема, яка знаходиться саме в тому просторі, де працюють послуги з розробки AI від MicrocosmWorks: перетворення технічно здібної моделі на конвеєр, що усуває реальне тертя.
Огляд шаблону
Фотографія стає зафіксованою, кількісно визначеною стравою в чотири етапи:
- Зйомка — сфотографуйте або оберіть зображення; оптимізуйте його на пристрої перед завантаженням.
- Розпізнавання — модель комп'ютерного зору ідентифікує страву, виражену як ранжовані пошукові терміни, а не сирі мітки.
- Зіставлення — ці терміни керують пошуком рецептів, чий рейтинг успадковує впевненість моделі.
- Фіксація — користувач вибирає рецепт, бачить інгредієнти та інформацію про харчування, вибирає кількість та зберігає її.
Ключова ідея: комп'ютерний зір і пошук не є окремими системами, прикрученими одна до одної. Модель комп'ютерного зору отримує підказку генерувати саме те, що потрібно пошуковій системі, а пошукова система довіряє порядку, в якому модель видає результати. Відмінність між "тим, що ми показуємо" і "тим, що на фото" зникає.
Еталонна архітектура
Зйомка, оптимізована на пристрої. Зображення змінюються до ширини ~512px і стискаються до якості JPEG ~40% перед завантаженням — API комп'ютерного зору мають жорсткі обмеження розміру, і необроблене фото з телефону їх перевищує. Сервер встановлює обмеження в 2MB як резервний захід.
Розпізнавання: модель формує пошук. Зображення надсилається до GPT-4o. Запит просить п'ять пошукових назв рецептів, розташованих від найбільш впевнених до найширшого резервного варіанту — назва страви в цілому, а не її начинки — замість "що це за їжа?" Бургер повертається як:
["cheeseburger", "beef burger", "cheese burger", "hamburger", "burger"]Зіставлення: впевненість стає релевантністю. П'ять назв виконуються як один пошук "match-any" за індексом рецептів Elasticsearch, кожна з яких має підвищення, зважене за позицією (від 50× до 5×). Рецепт під назвою Cheeseburger перевершує загальний Burger не через текстову статистику, а тому, що модель була більш впевненою. П'ять OR-зіставлених термінів означають, що користувач майже завжди бачить щось; підвищення виводять найкращий здогад нагору.
Фіксація: від картки рецепта до кількісно визначеної страви. Інгредієнти — що зберігаються як звичайний текст, куровані посилання та зовнішні посилання FatSecret — нормалізуються в один чистий список. Користувач вибирає одиницю виміру та кількість; калорії та макроси обчислюються на льоту, і страва зберігається в його щоденнику.
Другий напрямок для сирих інгредієнтів. Коли немає страви для пошуку, спеціалізований API для розпізнавання їжі повертає інформацію про харчування безпосередньо — дешевше та краще підходить, ніж загальна модель комп'ютерного зору. Додаток маршрутизує на основі наміру.
Дизайнерські рішення та компроміси
Підказуйте моделі у формат вводу наступної системи. Ранжовані, пошукові назви — а не довільні мітки — роблять передачу даних чистою. Підказка є частиною контракту; ми розглядаємо її як код, а не текст.
Широка мережа краще, ніж один найкращий здогад. П'ять OR-зіставлених термінів значно зменшують кількість повідомлень "результатів не знайдено", ціною випадкових, слабо пов'язаних результатів далі по списку.
Оптимізуйте зображення там, де воно знаходиться. Стиснення на пристрої економить час завантаження та уникає обмежень API, ціною невеликої клієнтської залежності — що варто для реальної мобільної надійності.
Правильна модель, правильне завдання. Загальна модель комп'ютерного зору чудово справляється з питанням "що це за страва?", але є надмірною для питання "скільки калорій у цьому яблуці". Два напрямки контролюють вартість і покращують результати.
Деградуйте чесно. Немає виявлення, немає збігу — додаток говорить про це прямо і пропонує ручний пошук, замість того, щоб вдавати або порушувати потік.
Захисні механізми, такі як обмеження швидкості запитів, ліміти завантажень та коректна відмова, працюють лише тоді, коли інфраструктура під ними створена для цього — такий тип основи покликані надавати послуги хмарної інфраструктури MicrocosmWorks.
Коли це використовувати — і коли уникати
Використовуйте цей шаблон, коли ручне введення є справжнім бар'єром, фотографія може замінити багатоетапний ввід, у вас є каталог для зіставлення, і "достатньо добре, миттєво" перевершує "ідеально, з часом". Уникайте його, коли домен вимагає лабораторної точності, немає каталогу для зіставлення, витрати на API комп'ютерного зору перевищують отриману залученість, або вхідні дані занадто візуально неоднозначні, щоб їх надійно ідентифікувати.
Наш підхід
Інстинкт у комп'ютерному зорі полягає в тому, щоб гнатися за моделлю, яка ідеально називає їжу. Справжній важіль знаходиться в іншому місці: у тому, як вихідні дані комп'ютерного зору пов'язані з усім подальшим. Підкажіть моделі говорити мовою пошукової системи, дозвольте її впевненості стати ранжуванням, нормалізуйте безлад за лаштунками — і все це зводиться до кількох дотиків. Перемога — це не розумніший класифікатор; це конвеєр без швів.
Будуєте щось подібне? Ознайомтеся з рішеннями AI-агентів від MicrocosmWorks або зв'яжіться з нами, щоб обговорити архітектуру вашого конвеєра.
Інші блоги
1. Персоналізований пошук рецептів: Вибірка, яка знає, що вам слід їсти далі
2. Масштабування цифрової медичної платформи за допомогою мікросервісів
3. Синхронізація Apple Health та Health Connect
