Практики для быстрых ML-прототипов 1. Fake it till you make it. Сначала делаем модель-человека. Например: • модерация контента — сначала модераторы • рекомендации — подбор вручную • скоринг — экспертная оценка Пользователь не должен знать, что внутри нет ML. Главное — проверить, нужен ли вообще этот результат. 2. Prompt вместо модели: 80% ML-гипотез можно сначала проверить через LLM. Примеры: • классификация обращений • извлечение сущностей • резюмирование текста • генерация ответов Промпт + API часто заменяет месяцы обучения модели. 3. Прототип на Google Sheets / Airtable. Многие ML-продукты можно сначала собрать как таблицу. Примеры: • ранжирование лидов • скоринг заявок • приоритизация тикетов Это позволяет быстро понять какие признаки реально влияют. 4. Правила вместо модели (Rule-based MVP). Часто 70% качества дает простая логика. Например: если • клиент VIP • активность > 5 действий • чек > 100 → показываем персональное предложение. Только после этого имеет смысл обучать модель. 5. Использовать готовые модели, а не обучать свои. Первый прототип редко требует кастомного ML. Можно использовать: • open-source модели • API провайдеров • HuggingFace • LLM Цель — доказать value, а не построить research-лабораторию. 6. Dataset сначала из 50–200 примеров. Не нужно ждать «идеальный датасет». Берем: • 50 • 100 • 200 примеров и проверяем: • возможно ли вообще решить задачу • какие признаки работают • какая точность получается Это экономит месяцы подготовки данных. 7. Оценка ценности раньше качества модели. Главный вопрос: не «какая точность модели?» а «меняет ли это поведение пользователя?» Иногда модель с точностью 60% уже дает рост метрик. 8. Wizard of Oz прототип. Интерфейс работает как будто есть ML, но решения принимает человек. Так тестировали: • автопилоты • голосовых ассистентов • чат-ботов Это самый быстрый способ понять: будут ли люди пользоваться фичей вообще. 9. Логируйте данные с первого дня. Даже если ML нет. Сохраняйте: • входные данные • действия пользователя • результат Через месяц это станет идеальным датасетом для обучения. 10. Стройте ML только после Product-Market Fit фичи ML — это ускоритель, а не источник ценности. Сначала нужно доказать: • что фича решает проблему • что пользователи ее используют • что есть рост метрик И только потом автоматизировать моделью. Приходите в кейс клуб, программа на марте тоже есть - https://t.me/productcasebar/218 Возможности для роста в профессии от редакции канала, в том числе курс по аналитике - https://t.me/FreshProductGo/1693 Также посты дублируются в VK, Tenchat, Сетке.