Go/no-go фреймворк для продактов: когда LLM правда нужна, как проверить качество и как посчитать эффект.
Когда начинаешь делать AI-фичи, легко попасть в ловушку: если задача связана с текстом, значит, туда просится LLM. У меня тоже были такие гипотезы – особенно в чатах, где любая подсказка, автоответ или модерация будто должны стать «умными».
Но эксперименты быстро отрезвляют. В одном месте LLM дает эффект, потому что нужно ответить за пользователя с учетом контекста диалога. В другом экспертный список коротких подсказок работает лучше: пользователю нужна не «человечность», а быстрый выбор. В третьем классический ML-классификатор оказывается дешевле и надежнее, потому что задача давно сводится к определению класса.
Поэтому главный вопрос про AI в продуктовых фичах звучит не «как встроить LLM?». Почти всегда можно встроить. Вопрос другой: почему именно здесь LLM лучше простого решения?
Go/no-go: должна ли LLM заслужить место в фиче
Перед PRD на AI-фичу я бы ответила на четыре вопроса: что должно измениться в поведении пользователя; какой шаг воронки улучшаем; почему это не решается проще; какова цена ошибки.
Если поведенческого изменения нет, это не продуктовая фича, а демо. Если вариантов ответа мало, контекст простой, а точность важнее разнообразия, LLM может быть лишней. Если фича может отправить ответ за пользователя, пообещать скидку, оформить возврат или дать совет в чувствительной теме, требования к качеству и safety должны быть намного выше.
| Вопрос | Go к LLM | Лучше проще |
|---|---|---|
| Нужен ли живой язык? | Важны тон, контекст, вариативность | Нужен короткий предсказуемый ответ |
| Можно ли описать правилами? | Слишком много исключений | Сценариев мало, правила стабильны |
| Что на выходе? | Текст, объяснение, диалог, саммари | Метка, скор, сортировка, простое действие |
| Цена ошибки | Ошибка обратима, есть эскалация | Ошибка юридически, финансово или репутационно опасна |
| Данные и контекст | Есть релевантный контекст | Данные грязные, поиск плохой |
| Экономика | Эффект покрывает инференс, evals, поддержку и риск | Эффект на мелком шаге воронки |
Я для себя использую простой тест: если могу заранее выписать 10–20 хороших ответов и они покроют большую часть сценариев, LLM, скорее всего, не нужна. Если на каждый хороший ответ появляется десяток исключений – разный контекст, тон, история пользователя, ограничения, – LLM стоит рассматривать серьезнее.
Второй тест экономический: если я не могу объяснить, как output модели дойдет до продуктовой или бизнес-метрики, значит, пока у меня не AI-фича, а демо.
Где LLM нужна, а где проще лучше
LLM имеет смысл рассматривать там, где задача плохо сводится к правилам и классической классификации: нужно синтезировать ответ из нескольких источников, работать с живым языком, учитывать историю диалога, адаптировать тон и не выдавать пользователю один и тот же шаблон каждый раз.
Но LLM сама по себе не знает специфику вашего бизнеса. Продакт проектирует не только промпт, но и контекст, который подается в модель. Часто для этого используют RAG: модель получает запрос пользователя и найденные во внешнем индексе документы или данные, или семантические деревья. Если внутренний поиск, база знаний или структура данных работают плохо, LLM сгенерирует красивую чушь. Качество AI-ответа ограничено качеством контекста.
Возьмем, например, нескольких соседних сценариев внутри одного продукта – некого маркетплейса. В подсказках продавцам LLM уместна: ответ должен учитывать вопрос покупателя, карточку товара и историю диалога. Там важны контекст, язык и вариативность.
Для старта чата покупателя LLM уже выглядит лучшим решением. Задача другая: помочь быстро начать диалог. Вариантов немного, разнообразие не нужно, а слишком длинный «умный» текст мешает интерфейсу. Экспертно собранные короткие подсказки могут быть сильнее.
А для защиты от грубости в чатах вообще не обязательна. Это задача классификации: определить, есть ли нарушение, и не отправлять сообщение. Такие задачи много лет хорошо решаются классическим ML: дешевле, быстрее и предсказуемее.
Один и тот же продукт, интерфейс и воронка – но разные задачи требуют разных технологий. Иногда лучший AI-продукт – это фича без AI: улучшенная форма, структурированное поле, подсказка в интерфейсе, регулярное выражение или классическая модель ранжирования.
Как продакт должен описывать evals: от вайб-чека к приемке
AI-фича без evals – это фича без критериев приемки.
На старте почти любую LLM-фичу проверяют через вайб-чек: команда руками прогоняет несколько примеров и обсуждает, «похоже ли это на нормальный ответ». Это полезно для прототипа: вайб-чек быстро показывает, есть ли в фиче магия, где модель ведет себя странно, какие ответы хочется переписать.
Но вайб-чек не должен быть критерием запуска. Он ловит только очевидные ошибки на маленькой выборке. Модель может хорошо отвечать на пять красивых демо-примеров и провалиться на длинном хвосте: опечатках, сарказме, конфликтных ситуациях, редких категориях, prompt injection или случаях, где пользователь просит модель сделать то, что ей делать нельзя.
Evals нужны, чтобы превратить субъективное «выглядит нормально» в повторяемую систему приемки. В Lenny’s Newsletter Aman Khan пишет, что evals становятся одним из ключевых навыков PM в AI-продуктах: они помогают измерять качество AI-системы, разложить ее поведение на отдельные шаги и понять, какое изменение действительно улучшило продукт. Он же сравнивает evals с регрессионными тестами или бенчмарками, которые задают, что именно считается «хорошо» для AI-фичи.
На практике я начинаю evals не с таблицы метрик, а со списка страхов. Что я боюсь увидеть в проде? Что ассистент пообещает скидку за продавца. Что выдумает характеристику товара. Что ответит в конфликтной ситуации вместо человека. Что будет звучать так уверенно, что пользователь поверит ошибке.
Из этих страхов рождаются labels: hallucinated, unsafe, needs human, too long, wrong tone, promises action. Потом – golden set: вход пользователя, контекст, ожидаемое поведение, недопустимое поведение, правильный label. Через несколько итераций у команды появляется не коллекция мнений, а тестовый набор, на котором можно сравнивать промпты, модели, RAG-источники и guardrails.
Такой подход помогает продакту говорить с ML-командой не абстрактно: «сделайте хорошо, а плохо не делайте», а конкретно: «вот типы ошибок, которые ломают пользовательское доверие и бизнес».
Дальше встает вопрос масштаба. Часть проверок можно сделать кодом: например, ответ не длиннее 200 символов, JSON валиден, ссылка на источник есть, запрещенных слов нет. Часть обязательно оставлять людям: тон, бренд, спорные ответы, чувствительные сценарии. А когда примеров становятся сотни или тысячи, появляется третий слой – LLM-as-judge.
LLM-as-judge – это отдельная модель, которая оценивает ответы основной AI-фичи по заданной рубрике. Это не магическая замена человеку: judge-модель тоже ошибается, ее нужно калибровать на человеческой разметке и проверять на достаточном объеме данных. Но она помогает масштабировать оценку и быстрее ловить регрессии. В Lenny’s этот подход описан как один из трех базовых типов evals наряду с human evals и code-based evals; там же подчеркивается, что LLM-based evals удобны для PM, потому что критерии можно описывать естественным языком.
Для продакта здесь появляется важный навык: писать eval prompt почти как мини-PRD. Не просить модель «оцени, хороший ли ответ», а явно описывать роль judge-модели, контекст, цель оценки и определения labels.
Это хороший пример того, как роль продакта меняется в AI-фичах. Он не просто пишет acceptance criteria для разработчика, а описывает границы поведения системы: что модель имеет право делать, где должна молчать, где эскалировать, какие ошибки ломают доверие и какие пороги нужно пройти перед запуском.
И важный принцип: offline evals не заменяют A/B-тест. Они отвечают на вопрос «достаточно ли качественно и безопасно, чтобы запускать». A/B-тест отвечает на другой вопрос: «изменилось ли поведение пользователей и бизнес-метрика».
Production UX, safety и rollout: магия заканчивается на последней миле
LLM медленнее и менее предсказуема, чем обычный алгоритм. Поэтому UX для AI-фичи должен не просто красиво показать ответ, а сгладить ограничения технологии.
Streaming и pacing. Для длинных ответов streaming снижает ощущение ожидания: пользователь видит начало ответа, пока модель продолжает генерацию. Но в completion-сценариях важнее не стримить каждый токен, а правильно дозировать момент и объем подсказки. OpenAI в документации описывает streaming как способ получать события по мере генерации, а не ждать полный ответ целиком.
На моем опыте, в completion мы подбирали debounce перед генерацией и размер фрагмента, который показываем пользователю. Если подсказка появляется слишком рано, она перебивает мысль. Если слишком поздно – пользователь уже сам написал текст. Если показать слишком мало слов, подсказка выглядит дерганой; если слишком много – начинает конкурировать с намерением пользователя.
Это оказалась не «магия AI», а классическая продуктовая настройка микровзаимодействия: момент появления, объем подсказки, механика принятия или игнорирования, acceptance rate, доля правок после принятия, time-to-send и стоимость одной полезной подсказки. В AI UX продакт настраивает не только качество ответа, но и момент, когда этот ответ имеет право появиться.
Graceful degradation и feedback loops. Продакт должен заранее описать, что произойдет, если модель не ответила, API упал, RAG не нашел контекст или ответ не прошел safety-проверку. Это может быть обычный поиск, шаблонная подсказка, кнопка «позвать оператора» или честное сообщение: «Не можем ответить автоматически». А кнопки 👍/👎, жалоба на ответ и «перегенерировать» помогают собирать данные о качестве модели в проде.
Safety шире, чем «не ругаться» и «не предлагать сделать бомбу». Риск может быть в том, что модель уверенно выдумала факт, раскрыла чувствительную информацию, дала вредный совет, нарушила тон бренда или совершила действие без подтверждения. OWASP в Top 10 для LLM-приложений на 2025 год выделяет, среди прочего, prompt injection, sensitive information disclosure, excessive agency и misinformation.
Чем больше модель может сделать от имени пользователя, тем ниже должен быть acceptable error rate. Хороший rollout поэтому выглядит не как «запустим и посмотрим», а как shadow mode, dogfood, маленький процент трафика, A/B-тест, мониторинг, rollback и расширение только после прохождения evals и safety-порогов.
И здесь возникает проблема последней мили. Демо AI-фичи можно собрать за вечер в Jupyter Notebook: взять API, написать промпт, показать магию на пяти примерах. Production-версия – это другой продукт: evals, guardrails, мониторинг, fallback, контроль стоимости, edge cases, юридические ограничения и ручная разметка. Продакту важно защищать эту невидимую работу перед бизнесом.
Как считать эффект и чему учат кейсы
Дорогая технология не отменяет продуктовую дисциплину. Сначала выбираем output-метрику: сделки, выручка, удержание, активация, cost-to-serve, NPS, скорость закрытия задачи. Потом input-метрику, на которую реально влияет AI: доля сообщений, где ассистент ответил; доля принятых подсказок; доля задач, решенных без оператора.
Дальше оцениваем покрытие: сколько реальных кейсов можно автоматизировать, в каких сегментах и с каким expected uplift. Потом вводим понижающие коэффициенты: модель ответит не на все сообщения, часть ответов будет хуже человеческих, часть пользователей не доверится автоматике, часть сценариев уйдет в fallback, а стоимость инференса и модерации съест часть эффекта.
Хороший пример такой дисциплины – Avito Assistant: авторы кейса описывают traction-модель, где input-метрика связывается с ответами в первый час, сделками и модельной выручкой; отдельно показывают ручную разметку 5 тысяч первых сообщений и понижающие коэффициенты для реалистичной оценки эффекта.
Формула для продакта простая:
инкрементальная польза от фичи − полная стоимость AI − стоимость риска > альтернатива без AI.
Полная стоимость – это не только токены. Это задержка ответа, инфраструктура, разметка, evals, мониторинг, модерация, поддержка, юридические и brand-safety риски.
Свежие международные кейсы показывают ту же мысль. Nubank в 2026 описал evaluation-driven подход к AI-агентам в поддержке на масштабе 100M+ пользователей; в одном из A/B-тестов команда получила +37 п.п. к AI transactional NPS и +29 п.п. к self-service rate.
Apple в 2025 задержала AI-обновление Siri, потому что фича не достигла нужной надежности. Это можно читать как зрелый no-go: если AI-фича действует от имени пользователя и может выполнять действия в приложениях, acceptable error rate должен быть намного ниже, чем у развлекательного чатбота.
Другой тип риска – неверно выбранные границы роли модели. В 2026 Пенсильвания подала иск против Character.AI: по версии властей, некоторые чатботы выдавали себя за лицензированных медицинских специалистов; компания указывала на fictional labels и предупреждения. Для продакта вывод продуктовый: дисклеймер сам по себе не спасает, если UX создает у пользователя ощущение, что перед ним врач, психолог или эксперт.
Вывод
AI в продуктовых фичах стоит применять не там, где хочется сказать «powered by AI», а там, где без AI продукт заметно хуже.
Продакт должен уметь ответить на три вопроса: почему здесь нужна именно LLM, а не правила, классический ML или UX-изменение; как мы поймем, что модель работает достаточно хорошо и безопасно; какой бизнес-эффект должен окупить стоимость и риск технологии.
После нескольких AI-экспериментов я стала относиться к LLM не как к новому типу фичи, а как к дорогому и сильному инструменту. Если задача требует живого языка, контекста и вариативности – LLM может дать продуктовый скачок. Если задача сводится к классификации, короткому выбору или стабильному правилу – часто лучше не усложнять.
Самый сильный навык продакта в AI-фичах – не умение написать промпт. А умение доказать, что LLM здесь правда лучше правил, классического ML, UX-изменения или решения вообще ничего не делать.