Составляем AI роадмап вашего продукта

1. AI-роадмап для зрелого бизнеса: как внедрять LLM, если вы не AI-стартап

2. TL;DR Павел Михайлов из Ostrovok (Emerging Travel Group) рассказывает, как внедрять большие языковые модели (LLM) в компанию, которой больше 10 лет и чей основной продукт не связан с AI. Главные мысли: начинать проще с экономии костов (Cost Saving), а не с генерации выручки; внедрение AI — это постоянное прототипирование из-за непредсказуемости моделей; метрики качества нужно определять до старта разработки. Доклад про стратегию, оценку рисков и дилемму Build vs Buy.

3. Кому будет полезно

• Роли: Product Managers, CPO, CTO, Tech Leads, стратеги.
• Уровень: Middle+, Senior, C-level.
• Условия: Если вы работаете в зрелой компании (не AI-native) и ищете точки приложения для GenAI, чтобы не просто хайпануть, а получить пользу.

4. Краткий контекст

• Спикер: Павел Михайлов, NP Product Manager в Emerging Travel Group (бренд Ostrovok).
• Продукт: Тревел-платформа с 10-летней историей, большой отдел поддержки, устоявшиеся процессы.
• Задача: Понять, куда внедрить LLM в большой компании, чтобы это было экономически оправдано, и построить «фабрику гипотез».

5. Ключевые идеи

1. Формула выбора проектов: Cost Saving vs Revenue Generation

Что сказали: Все кейсы применения LLM делятся на два типа:

1. Cost Saving: Делаем то же самое, что и раньше, но дешевле (автоматизация поддержки, копирайтинг).
2. Revenue Generation: Делаем новые задачи, которые раньше были слишком дорогими (перевод миллионов отзывов, гипер-персонализация). Почему это важно: Позволяет приоритизировать бэклог гипотез. Cost Saving считать легче — данные уже есть. Revenue Generation сложнее, так как требует визионерства и тестов. Как применить на практике: Использовать формулу оценки профита: (Стоимость выполнения человеком - Стоимость выполнения AI) * Частота задачи. Начинайте поиск с Cost Saving — там деньги видны сразу.

2. Проблема «Двойного Черного Ящика» (Double Black Box)

Что сказали: Раньше в продуктовой разработке «черным ящиком» был только пользователь (мы не знали, зайдёт ли ему фича). С LLM появляется второй «черный ящик» — сама модель. Мы не знаем наверняка, сможет ли модель решить задачу качественно. Почему это важно: Это кардинально меняет процесс разработки. Нельзя просто написать ТЗ и отдать в продакшн. Как применить на практике: Внедрять культуру быстрого прототипирования. Не ввязываться в долгую разработку без MVP. Тестировать гипотезы «на коленке» за один вечер, прежде чем выделять ресурсы.

3. Оценка качества и толерантность к ошибкам

Что сказали: LLM ошибаются (галлюцинируют) — это факт. Когда ошибается человек, мы прощаем. Когда алгоритм — нет. Сложно понять, что такое «хороший ответ» модели, если нет четких метрик. Почему это важно: Внедрение AI в критические процессы (юридические документы, банковские транзакции) может нести неприемлемые риски. Как применить на практике: Заранее определить: какой % ошибок допустим? Если модель ошибается в 2% случаев, но экономит миллионы — ок ли это для бизнеса? Если нет — не внедрять туда AI.

4. Build vs Buy в гонке плотности (Density Race)

Что сказали: Стоит дилемма: пилить свое на Open Source (Llama, Mistral) или брать API (GPT-4). Свое решение дает контроль и безопасность данных, но требует ресурсов. Покупное решение (API) мощнее, но создает зависимость. Почему это важно: Рынок развивается быстрее, чем внутренняя разработка. Пока вы год пилите свою модель, выйдет GPT-5, которая сделает вашу работу бессмысленной. Как применить на практике: Для русского языка пока часто выгоднее брать API (GPT-4), так как open-source модели хуже работают с кириллицей. Строить свое стоит только если у вас уникальные данные или огромные объемы, окупающие R&D.

6. Примеры и кейсы

• Amazon (Revenue Gen): Автоматический перевод отзывов. Раньше нанять переводчиков для миллионов товаров было безумием (дорого). С LLM это стало копеечным делом — появилась новая ценность для пользователя.
• Генерация описаний товаров (Cost Saving): Раньше копирайтер писал описание за $X. Теперь LLM делает это за $X/10. Профит считается моментально.
• Чат-боты поддержки: Пример проблемы данных. Когда начали обучать бота на логах переписки людей, выяснилось, что люди-операторы часто размечают данные с ошибками или небрежно. Модель выучила эти ошибки. Пришлось чистить датасеты.

7. Ошибки и грабли

• Завышенные ожидания от «интеллекта»: Думать, что LLM обладает системным мышлением. Это не так, это просто вероятностный генератор текста.
• Отсутствие метрик до старта: Запустить проект по генерации email-ответов и только потом понять, что вы не знаете, как автоматически проверить их качество (нужна вторая LLM для проверки первой?).
• Игнорирование ошибок людей в данных: Обучение модели на «грязных» исторических данных, созданных людьми, приводит к масштабированию хаоса.

8. Что можно сделать уже сегодня

1. Выгрузить список регулярных текстовых задач в компании (саппорт, контент, SEO) и посчитать Unit Economics: сколько стоит одна операция сейчас vs сколько она будет стоить через API GPT.
2. Провести брейншторм с бизнесом: не спрашивать «куда внедрить AI?», а спрашивать «где у нас самые большие косты на текст?» и «какие фичи мы отложили, потому что это было дорого/долго рукам?».
3. Определить риск-профиль: составить список зон, где ошибки недопустимы (например, финансы), и исключить их из первого этапа внедрения LLM.
4. Запустить прототип на no-code/low-code инструментах для одной узкой задачи, чтобы проверить качество модели, не привлекая разработчиков.

9. Цитаты

«LLM позволяет понимать и генерировать текст за очень, очень маленькие деньги. Просто супер дешево». «Когда модель ошибается — мы это не прощаем. Когда человек ошибается — мы такие: "Ну ладно, бывает"». «Любой ответ LLM — это галлюцинация. Просто иногда она правильная».

10. Итоговый вывод Основная мысль: внедрение AI в зрелом бизнесе — это упражнение в экономике и управлении рисками, а не просто технологический челлендж. Спикер призывает не гнаться за хайпом, а методично искать места, где дешевая генерация текста срежет косты или откроет новые возможности, при этом трезво оценивая, что модель будет ошибаться. Первый шаг — посчитать деньги в текущих текстовых процессах.