Команда AI Sous-chef за 2,5 месяца выпустила приложение и бота с облачным ИИ

Приложение получило список продуктов, вернуло рецепт в нужном формате и показало пользователю салат из сырой картошки и баклажана. Этап приготовления этих ингредиентов в инструкции отсутствовал. Именно такой отзыв, по словам команды AI Sous-chef, пришёл после запуска. Для разработчика здесь знакомая проблема: ответ модели успешно проходит технические проверки, а пользователь получает неудачный результат.

В опубликованном на Habr разборе команда показывает, как за два с половиной месяца собрала Android-приложение и Telegram-бота с общим бэкендом. Практическая ценность материала — в подробностях: как выбираются версии промптов, что проверяется в ответах и почему этих проверок пока недостаточно.

Два клиента, общий бэкенд и промпты в файлах

Сценарий простой: человек фотографирует продукты или вводит их текстом, подтверждает распознанный список и получает варианты блюд. У мобильного приложения на React Native и бота общий сервер на Python и FastAPI. Распознавание и генерация рецептов разделены между двумя облачными моделями; запросы отправляются в API Яндекса.

Инструкции хранятся отдельно от кода: для каждой задачи есть системный и пользовательский файлы. Нужные версии задаёт pin.json. Например, распознавание можно оставить на v1, а для рецептов выбрать другую подготовленную версию. Загрузчик читает файлы и подставляет значения в выражения вроде {{ products }}. Если файла или необходимого значения нет, он выдаёт ошибку.

Это позволяет править формулировки без переписывания функции вызова модели. Но есть эксплуатационная деталь: указатель версий кешируется в памяти процесса. После изменения pin.json требуется перезапуск или очистка кеша. Тексты инструкций при этом читаются заново при каждом обращении к загрузчику.

Есть и более существенная граница. По описанию авторов, список продуктов подставляется в том числе в системную инструкцию. Отдельные файлы сами по себе не отделяют пользовательские данные от правил поведения модели. Реакцию на посторонние указания внутри входного текста ещё нужно проверять.

JSON проверяет структуру, а рецепт требует другой оценки

При генерации рецептов приложение запрашивает JSON параметром API, затем разбирает ответ через json.loads и проверяет ожидаемую структуру через model_validate. Это помогает обнаружить ответ, который код не сможет обработать. Однако наличие нужных полей ничего не говорит о полноте кулинарных шагов.

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

В репозитории собраны десять проверочных сценариев: пустой ввод, один ингредиент, дробные количества, неоднозначный текст и другие случаи. Описаны лишние ингредиенты, расплывчатые инструкции и ошибки формата. Но единой надёжной метрики пока нет: между проверками менялись сразу промпты, настройки генерации и обработка ответов.

Дополнительно воспроизводимость ограничивает использование latest в адресах моделей. Версия промпта может остаться прежней, а модель за этим адресом — обновиться. Для сопоставимых прогонов нужно сохранять вход, ответ, настройки и точную доступную идентификацию модели.

Что пригодится в собственном продукте

В AI Sous-chef предусмотрен режим AI_MODE=stub: вместо облачных запросов приложение получает заранее записанные продукты и рецепты. На таких ответах удобно проверять интерфейс и взаимодействие компонентов. Качество генерации этот режим не измеряет, поскольку генерации в нём нет.

Для продакта показательно другое ограничение первого релиза: распознанный список можно было подтвердить, но нельзя было исправить. Человек видел ошибку и не мог убрать неверный ингредиент перед следующим шагом. Редактирование списка стало одной из ближайших доработок.

Основной репозиторий, по данным статьи, опубликован под GNU AGPL v3.0. Из него можно изучить загрузчик промптов, выбор версий, проверку ответов и подмену моделей готовыми данными. При переносе придётся учитывать структуры конкретного приложения и кеширование.

Для команды, которая строит похожий сервис, кейс задаёт полезный порядок работы: отдельно проверять обработку ответа и его содержание, сохранять проблемные примеры, сравнивать изменения в одинаковых условиях. Вынесенные в файлы промпты упрощают обслуживание. Доказательство качества всё равно придётся собирать на реальных ответах.