LLM-as-Judge - паттерн, в котором одна модель оценивает выходы другой по заданным критериям. Автоматический quality gate для LLM-приложений.

Зачем это нужно

Стандартный мониторинг (HTTP 200, latency, rate limits) ничего не говорит о качестве ответов. Модель может галлюцинировать в 15% случаев, а все метрики будут зелёными. Ручная проверка не масштабируется: при 10 000 запросов в день ни один человек не справится.

LLM-as-Judge работает так: генератор отвечает на вопрос, модель-судья проверяет ответ и выставляет числовой score. Zheng et al. (2023) показали, что GPT-4 в роли судьи совпадает с человеческими оценками в 80%+ случаев. Два человека-асессора между собой - 81%.

Какие метрики оценивать

Зависит от задачи. Для RAG: faithfulness (ответ основан на контексте, не выдуман) + answer relevance (ответ по теме вопроса). Для чат-ботов: relevance + toxicity. Для агентов: task completion.

Начинать с двух метрик. Добавлять по мере обнаружения проблем.

Что важно в промпте судьи

«Оцени качество» не работает - слишком размыто. «Извлеки каждый факт из ответа, проверь наличие подтверждения в контексте, выдай ratio подтверждённых к общему числу» - работает. Chain-of-thought обязателен: без промежуточных шагов оценки нестабильны.

Три точки интеграции

Pre-deploy: DeepEval прогоняет golden dataset при каждом изменении промпта. Score ниже порога - merge заблокирован.

Runtime gate: судья оценивает каждый ответ до отправки пользователю. GPT-4o-mini на 10K запросов/день: ~$0.75.

Post-hoc мониторинг: Langfuse оценивает выборку трейсов. Дешевле runtime gate, ловит тренды деградации.

Подводные камни

Self-enhancement bias: GPT-4 завышает оценки текстам GPT-4, Claude предпочитает Claude. Решение - генерировать на одном провайдере, оценивать на другом.

Position bias: при парном сравнении судья предпочитает первый ответ. Сдвиг до 15%. Решение - pointwise scoring.

Судья тоже галлюцинирует. Chain-of-thought помогает, но полного решения нет. Фундаментальное ограничение.

Рабочий сетап: DeepEval (OSS) для CI + Langfuse (OSS) для прода. От нуля до quality gate - 2-3 дня.

Подробный гайд с промптами, кодом и CI/CD конфигом - в блоге: https://futurecraft.pro/blog/llm-as-judge-automated-quality-gate/

В большинстве команд до 5 человек процессы не документированы. Деплой в голове у одного человека. Настройка staging — в Slack-переписке трёхмесячной давности. Инцидент-респонс — «ну позвони Васе».

Bus factor = 1. Стандартная ситуация.

Почему так

Описание 5-минутного деплоя занимает 40 минут. Через месяц половина шагов устаревает. Экономика работает против документации — ты вечно «допишешь потом».

LLM меняют расклад. Генерация SOP из сырых данных — минуты, не часы.

Три источника, которые уже есть

Записи экрана: включаешь Loom или asciinema при следующем деплое. Транскрибируешь (Whisper). Скармливаешь LLM — получаешь пошаговую инструкцию за 3-5 минут.

Чат-логи: ответ коллеге «как настроить staging?» в 10 сообщениях — уже черновик SOP. Копируешь в Claude, получаешь структурированный документ.

Код и конфиги: CI/CD pipeline, Dockerfile, Makefile — формализованные процессы на языке, который LLM читает отлично. Модель разбирает deploy.yml и генерирует человекочитаемую инструкцию.

Что документировать первым

Пересечение «критично» и «часто». Обычно это деплой и инцидент-респонс. Три фильтра: повторяемость (раз в месяц+), передаваемость (больше одного исполнителя), критичность (сбой наносит ущерб). Два из трёх — документируем.

Типичные ошибки

LLM галлюцинирует шаги. Может добавить несуществующий флаг команды или лишний этап. Каждый SOP прогоняй вручную хотя бы раз.

Избыточная детализация: модель разложит тривиальное действие на 5 подшагов. Калибруй под читателя.

Минимальный набор — 5 документов: деплой, инцидент-респонс, доступы и секреты, онбординг, периодическое обслуживание. 15-20 минут на процесс. Полтора часа — и критичные знания перестают зависеть от одного человека.

Полный гайд с промптами и шаблонами: https://futurecraft.pro/blog/sop-generator-ai-documentation/

#инструкции

Холодные письма с AI-персонализацией работают не потому, что AI хорошо пишет. Они работают потому, что AI хорошо читает.

Стандартная "персонализация" в B2B outreach выглядит так: подставить имя, компанию, индустрию. Результат - письмо, которое мог получить любой человек в этой индустрии. Inbox продакт-менеджера в SaaS-компании получает 15-20 таких писем в неделю. Все начинаются одинаково. Все удаляются одинаково.

Настоящая персонализация требует ресерча. SDR тратит 20-40 минут на один контакт: читает LinkedIn, смотрит новости компании, находит вакансии, понимает приоритеты. Потом пишет письмо, которое показывает - отправитель разбирается в ситуации получателя. При 100 контактах в день на это нужно 30-60 человеко-часов. Математика не сходится.

AI-агент делает тот же ресерч за 10-15 секунд на контакт. Но ключевой момент: автоматизируется ресерч, а не шаблон. Разница принципиальная.

Pipeline состоит из четырёх шагов:

1. Сбор контактов через Apollo.io (фильтры по ICP, должности, размеру компании, технологиям)
2. Enrichment в Clay - на каждый контакт подтягивается 15-20 data points: раунды инвестиций, последние новости, LinkedIn-активность, вакансии, tech stack
3. Двухшаговая генерация через Claude API - сначала research-промпт анализирует данные и выдаёт JSON (приоритет, боль, факт для зацепки), потом отдельный промпт генерирует письмо на 60-90 слов
4. Отправка через Instantly с warming, ротацией аккаунтов и follow-up последовательностью

Двухшаговый промпт - самая важная часть. Если скормить модели "напиши персонализированное письмо для Алексея из DataFlow", получится тот же шаблон, только дороже. Разделение на ресерч и генерацию позволяет контролировать каждый шаг по отдельности. Research-промпт выдаёт структурированный анализ. Generation-промпт работает с готовыми данными, а не пытается одновременно анализировать и писать.

Пример разницы. Шаблонное письмо: "Видел что DataFlow активно растёт. Хотели бы рассказать, как помогаем компаниям ускорить разработку." AI-персонализированное: "DataFlow только закрыл Series B и строит мобильную команду с нуля. Три месяца на MVP при параллельной разработке core-платформы - амбициозный таймлайн. Есть подход, который сокращает срок до 5 недель." Первое - о чём угодно кому угодно. Второе показывает понимание конкретной ситуации.

Стоимость стека: $250-350/мес (Apollo + Clay + Instantly + Claude API). SDR с аналогичной пропускной способностью - $4 000-6 000/мес.

Но есть подводные камни.
AI-слоп - ранние версии промпта генерируют текст с маркерами типа "в быстро меняющемся ландшафте". Промпт нужно итерировать 5-10 раз с explicit-запретами.
Фактические ошибки - агент иногда приписывает компании несуществующий раунд инвестиций. Добавление validation-промпта стоит $0.002 на контакт и ловит около 5% ошибок.
Одинаковая структура - без рандомизации стиля получатели из одной компании могут сравнить письма и понять систему.

Deliverability - отдельная тема. Отдельный домен, SPF/DKIM/DMARC с первого дня, максимум 30 писем в день с аккаунта, две недели warming до первой отправки. Масштабирование - через новые домены, не через увеличение нагрузки на существующие.

Ещё один неочевидный факт: breakup email на день 12 ("понимаю, не приоритет") даёт непропорционально большую долю ответов. Люди, проигнорировавшие два тщательно персонализированных письма, отвечают на третье "извините, пропустил".

Подробный гайд с промптами - в блоге: https://futurecraft.pro/ru/blog/ai-cold-outreach-personalization/

Техническая статья занимает 4 часа. Дистрибуция по 5 платформам - ещё 4. В итоге вторая часть откладывается, и контент гниёт на одной площадке.

Парадокс: создатели технического контента тратят основное время не на создание, а на упаковку. При этом 80% аудитории никогда не зайдёт в блог напрямую - они сидят в X, LinkedIn, Telegram, смотрят Shorts.

Формула 1-к-5 решает это через LLM-pipeline. Одна статья, пять промптов, 40 минут вместо 4 часов.

Почему нельзя просто сказать модели "сделай тред из статьи":
- Результат - пресный пересказ без учёта платформы
- У каждой площадки свой ритм, длина, ожидания аудитории
- Модели нужна роль, контекст платформы и жёсткие ограничения формата

Что работает в промптах для каждой платформы:

1. X/Twitter тред - хук в первом твите, ссылка только в последнем (алгоритм понижает посты со ссылками). Каждый твит - законченная мысль, до 280 символов
2. LinkedIn - первые 3 строки до ката решают всё. Одна идея, открытый вопрос в конце (комментарии - главный сигнал алгоритма)
3. Email-рассылка - не пересказ, а закулисье. Почему тема актуальна, что осталось за рамками, 1-2 инсайта вне статьи
4. Reels/Shorts - 60 секунд, ~140 слов. Хук за 2 секунды, зацепки каждые 10 секунд для удержания
5. Telegram - суть в первом предложении, плотный формат, жирный для ключевых фраз

Автоматизация: n8n + Claude API. Триггер на новый markdown-файл, 5 параллельных вызовов, результат в один документ. Генерация - 2-3 минуты, редактура - 10 минут.

Стоимость: Claude Haiku - несколько центов за прогон. Sonnet - меньше доллара на все 5 форматов.

Ключевое правило: LLM даёт 80% готового текста. Оставшиеся 20% - авторский голос. Заменить generic-формулировки на конкретику, добавить деталь, которая есть только у тебя, убрать шаблонные предложения.

Типичные ошибки:
- Копипаст абзаца из статьи в LinkedIn без адаптации
- Публикация всего в один день (растянуть на неделю - дать алгоритмам отработать каждую единицу)
- Генерация без финальной редактуры

Экономика: 8ч 45мин (с нуля) vs 4ч 40мин (с репёрпозингом). При 2 статьях в месяц - 96 часов экономии в год. Но главное не время, а то, что дистрибуция перестаёт откладываться.

Подробный гайд с промптами - в блоге: https://futurecraft.pro/ru/blog/content-repurposing-ai-formula/

Unit economics большинства SaaS-продуктов - это три формулы в Google Sheets, которые никто не обновляет. LTV:CAC = 3.2, все довольны, расходимся. А потом churn растёт два месяца подряд - и никто не замечает, пока деньги не заканчиваются.

Проблема не в математике. Формулы элементарные: LTV = ARPU / Churn Rate, CAC = расходы / клиенты, Payback = CAC / (ARPU x Margin). Проблема в том, что статичная таблица даёт одну точку, а решения требуют диапазона.

Что происходит, если churn вырастет на 2%? Как изменится экономика при удвоении бюджета на рекламу? Какой эффект даст повышение цены на $10? Каждый такой вопрос в таблице - новая формула, новая ячейка, час работы. Или один промпт.

Разберём на конкретном примере. B2B SaaS, $11K MRR, два тарифа ($19 и $49), 420 клиентов:

- ARPU = $26.86
- LTV = $436 (при margin 78% и churn 4.8%)
- CAC = $120
- LTV:CAC = 3.6:1
- Payback = 5.7 месяцев

На первый взгляд - отличные показатели. Но sensitivity analysis через AI вскрывает три скрытые проблемы:

1. Logo churn 6.2% - выше бенчмарка для B2B. Средняя жизнь клиента 16 месяцев. При росте до 8% LTV падает до $340, а LTV:CAC - до 2.8:1.

2. Paid CAC сильно выше blended. Из 35 новых клиентов в месяц 12 приходят из органики. Paid CAC = $183, и LTV:CAC для платных каналов уже 2.4:1 - пограничная зона.

3. Дешёвый тариф захватывает долю. 74% клиентов на $19 (было 68% три месяца назад). Тренд продолжится - ARPU упадёт, paid LTV:CAC уйдёт ниже 2:1.

Ни одна из этих проблем не видна в статичной таблице. Все три - очевидны при запуске 30+ сценариев через промпт.

Ключевой инсайт из sensitivity analysis: для большинства SaaS churn влияет на LTV сильнее, чем цена. Снижение churn на 1% даёт больший прирост, чем повышение цены на $5. При этом усилия распределяются наоборот: недели на ценообразование, минимум на retention.

Минимальный набор для мониторинга - три числа: LTV:CAC, Payback Period, Monthly Churn. Обновление раз в месяц. Этого достаточно, чтобы видеть тренд и реагировать вовремя.

Бенчмарки для ориентира:
- LTV:CAC < 1:1 - убыток. 3:1 - норма. > 5:1 - недоинвестируете в рост
- Payback > 18 мес - вопрос, хватит ли денег. < 6 мес - сильный сигнал
- Net Revenue Retention > 100% - рост без новых клиентов

Подробный гайд с промптами - в блоге: https://futurecraft.pro/ru/blog/unit-economics-calculator-ai/

Мульти-агентная система из 5 агентов обходится дешевле, чем один большой промпт. Это не интуитивно, но объяснимо.

Почему один агент не справляется

Возьмём задачу "спланируй поездку в Японию на 10 дней". Один агент должен: понять намерение (NLU), найти достопримечательности (поиск), построить маршрут (оптимизация), написать описания (генерация текста), проверить на ошибки (валидация). Каждый шаг требует разную температуру, иногда разную модель. NLU - 0. Генерация текста - 0.7. Оптимизация - reasoning-модель вроде o3.

Один промпт на 3000+ токенов с противоречивыми инструкциями даёт непредсказуемое поведение. Отладить конкретный шаг невозможно.

Правило: больше двух шагов с разными требованиями к модели - пора разделять на агентов.

Три паттерна оркестрации

1. Sequential Pipeline - агенты в цепочке, выход одного = вход следующего. Просто, предсказуемо, легко отлаживать. Минус: время = сумма всех шагов, нет параллелизма.

2. Fan-Out / Fan-In - несколько агентов работают параллельно над разными аспектами одной задачи. Время = самый медленный агент. Подходит для code review, мульти-аспектного анализа, валидации с разных точек зрения.

3. Router - агент-маршрутизатор на дешёвой модели классифицирует запрос и направляет к специализированному агенту. Как API gateway в микросервисах. 80%+ запросов обрабатываются дешёвыми агентами.

Специализация: кто что делает

Типичный набор для продукта:
- Classifier (Gemini Flash, temp 0) - определение intent, ~200 токенов промпт
- Extractor (DeepSeek Chat, temp 0) - извлечение данных, ~500 токенов
- Planner (Claude Sonnet / o3, temp 0.3) - генерация планов, ~1500 токенов
- Writer (Gemini Flash, temp 0.7) - текст для пользователя, ~800 токенов
- Validator (GPT-4o, temp 0) - проверка JSON-схемы и фактов, ~400 токенов
- Judge - оценка качества output по критериям, не генерация контента

Почему pipeline дешевле

Один агент на Claude Sonnet: ~3000 input + ~2000 output токенов = ~$0.025.
Pipeline из 5 агентов с mix моделей: ~2500 input + ~1800 output = ~$0.008.

Classifier на Flash - $0.0001 за вызов. Extractor на DeepSeek - $0.00014/1M input. Дорогую модель использует только Planner, и его промпт короче - параметры уже извлечены. Экономия 60-70%.

Что ломает мульти-агентные системы

- Over-engineering: три агента для задачи, которую решает один промпт с structured output
- Нет fallback: один агент недоступен - весь pipeline мёртв
- Слишком длинные цепочки: 8 агентов x 3 секунды P95 = 24 секунды на ответ
- Нет circuit breaker: агент вернул битый JSON, следующий его получил, оркестратор сделал 3 retry - потрачены токены впустую

С чего начать: Classifier + Worker. Classifier определяет тип задачи на дешёвой модели, Worker обрабатывает на подходящей. Добавить structured output (Pydantic-схемы) и трейсинг (Langfuse). Потом - Judge-агент для автоматической оценки качества.

Подробный гайд с примерами кода в блоге: https://futurecraft.pro/ru/blog/multi-agent-architecture/

Промпты в production ломаются молча. Кто-то поправил системный промпт классификатора, accuracy упала с 0.94 до 0.81, но узнали об этом через неделю - по жалобам пользователей. Потому что промпт лежал в коде, без версионирования, без тестов, без привязки к метрикам.

При 20-50 промптах в проекте это становится системной проблемой. Три человека редактируют один файл: продакт правит тон, ML-инженер режет токены, разработчик рефакторит шаблон. Результат непредсказуем.

Четыре слоя prompt engineering system:

1. Registry - централизованное хранилище. Каждый промпт: имя, версия (автоинкремент), лейбл (production/staging), переменные, параметры модели. Два подхода: Langfuse из коробки или YAML-файлы в Git с CI-синхронизацией в Langfuse

2. Testing - eval pipeline перед деплоем. Датасет из 20-30 примеров на каждый промпт. Скрипт прогоняет новую версию, считает accuracy, блокирует merge если ниже порога. Запускается в CI автоматически при изменении файлов в prompts/

3. Deploy - доставка без деплоя кода. Три стратегии:
- Мгновенное переключение - сменить лейбл на production, приложение подхватит
- Canary - 5% трафика на новую версию, сравнение метрик в реальном времени
- Feature flags - таргетирование по пользователям, сегментам, регионам

4. Monitor - версия промпта в метаданных каждого LLM-вызова. Дашборд: accuracy, latency p95, token usage, error rate, cost per request. Алерт при деградации больше 10% от baseline, автоматический откат к предыдущей версии

Паттерны организации:

- Композиция вместо монолитов. Промпт на 3000 токенов - кошмар для тестирования. Разбить на компоненты: core-логика, output-format, language-rules. Каждый компонент тестируется и версионируется отдельно

- Naming convention: {domain}-{task}-{variant}. Без этого при 50 промптах наступает хаос: ticket-classifier-v2, order-summarizer-short, quality-judge-relevance

- Метаданные: owner, model_compatibility, avg_tokens, cost_per_call, test_accuracy, dataset_size. Без них аудит невозможен

Пороги масштабирования:
- 10 промптов - нужен registry
- 30 промптов - нужен CI eval
- 50 промптов - нужен RBAC
- 100 промптов - нужен автооткат

С чего начать за 4 недели:
- Неделя 1: инвентаризация - собрать все промпты в единый формат
- Неделя 2: датасеты - 20-30 примеров на промпт из production-логов
- Неделя 3: eval pipeline в CI
- Неделя 4: версия промпта в каждом трейсе + дашборд + алерты

Подробный гайд с кодом и шаблонами в блоге: https://futurecraft.pro/ru/blog/prompt-engineering-system/

78% откликов на вакансии в LinkedIn - от кандидатов, которые не соответствуют требованиям. На hh ситуация аналогичная. Рекрутеры тратят 23 часа в неделю на скрининг нерелевантных резюме. Причина - сами тексты вакансий.

Что не так с типичной вакансией

Три источника текста: шаблон с прошлого найма, список требований от тимлида, корпоративное описание из HR. Результат предсказуем:

- 10-12 технологий в требованиях без приоритизации. Кандидат не понимает, что используется ежедневно, а что вписали «на всякий случай»
- Обязанности описывают любую backend-позицию в мире: «разработка серверной части, проектирование API, код-ревью»
- «Конкурентная зарплата» и «дружный коллектив» - информационный ноль
- Нет контекста задач: что делать в первый месяц, какую проблему решает команда, почему открылась позиция

Сильные специалисты пропускают вакансию, если не попадают в 100% списка. Слабые откликаются на всё подряд. ATS фильтрует по ключевым словам - кандидаты вставляют ключевые слова белым шрифтом. Обе стороны оптимизируют под алгоритм, а не под качество найма.

Что работает

Конкретные задачи вместо абстрактных обязанностей. Не «разработка высоконагруженных систем», а «перевести монолит биллинга (PostgreSQL, 50M транзакций/месяц) на event-driven архитектуру за 6 месяцев». Кандидат за 30 секунд оценивает: интересно, по силам, хочу.

Разделение must-have и nice-to-have. Максимум 5 обязательных, максимум 5 желательных. Исследование LinkedIn: женщины откликаются при соответствии 100% требований, мужчины - при 60%. Чёткое разделение расширяет воронку.

Прозрачность условий. Зарплатная вилка, формат работы, размер команды, стек в продакшне. Каждый скрытый параметр - это отказ на этапе оффера.

Двухшаговая генерация через LLM

Инженеры понимают задачу, но не пишут тексты. HR пишет, но не знает контекста. LLM закрывает этот разрыв.

Шаг 1 - сбор сырых данных: 5-10 минут голосового от нанимающего менеджера, текущий стек, контекст команды, причина открытия позиции, провалы прошлого найма.

Шаг 2 - генерация с ограничениями: начать с задачи (не с компании), разделить требования, описать первые 3 месяца, запретить клише («динамично развивающаяся», «лидер рынка», «проактивный»).

Шаг 3 - ревью вторым промптом. Проверяет конкретность, фильтрацию, клише, баланс требований, прозрачность условий. Двухшаговый подход стабильно превосходит одноразовую генерацию.

Типичные ошибки

LLM раздувает требования - добавляет технологии, которых нет во входных данных. Генерирует восторженный тон: «уникальная возможность», «невероятная команда». Явно ограничивай и то, и другое в промпте.

Не адаптировать под площадку - LinkedIn (лимит 2600 символов) и hh.ru (структурированные поля) требуют разного формата.

Пропускать ревью менеджера - AI не знает, что «Kafka - это планы на следующий год, а не текущий стек».

Метрики

Конверсия просмотр-отклик: целевой 8-15%. Доля релевантных откликов: до AI - 15-25%, после - 40-60%. Сохраняй связку «текст вакансии - результат найма» для каждой позиции.

Подробный гайд с промптами и примерами в блоге: https://futurecraft.pro/ru/blog/ai-job-descriptions/

В 68% компаний до 200 человек интервью проходят без подготовленных вопросов. Интервьюер импровизирует, кандидат получает рандомный опыт, решение принимается на ощущениях.

Structured interview kit - это четыре компонента, которые превращают хаотичный процесс в воспроизводимую систему.

Матрица компетенций - список навыков, привязанных к этапам интервью. Каждая компетенция - один этап, один интервьюер. Без матрицы два человека задают одинаковые вопросы, пропуская критичные области. Типичная матрица: 6-8 компетенций, разделённых на hard и soft skills, с весами - critical, important, nice-to-have.

Вопросы по компетенциям - behavioral (прошлый опыт) и situational (гипотетические сценарии). Каждый вопрос тестирует ровно одну компетенцию. Если вопрос проверяет две - его невозможно нормально оценить. К каждому вопросу идут follow-up, критерии сильного ответа и red flags.

Пример для компетенции "Приоритизация":
- Behavioral: "Расскажите о ситуации, когда запросов было больше, чем ресурсов. Как решали, что попадёт в релиз?"
- Red flag: "Я делал всё, что просил CEO" - нет самостоятельности в принятии решений.

Scorecard - шкала от 1 до 4 с конкретными индикаторами на каждом уровне. "Хорошие коммуникативные навыки" - плохой индикатор. "Структурировал ответ, назвал цифры, задал уточняющий вопрос" - хороший. Scorecard заполняется сразу после интервью, до разговора с другими интервьюерами. Иначе срабатывает эффект якоря.

Debrief agenda - структура финальной встречи. Порядок:
1. Каждый зачитывает оценки (без обсуждения до конца раунда)
2. Модератор выносит расхождения в 2+ балла
3. Обсуждение red flags и рисков
4. Голосование: Strong Yes / Yes / No / Strong No

Порядок выступлений: от junior к senior. Если первым говорит CTO и ставит Strong Yes, остальные подсознательно подтягивают оценки вверх.

AI генерирует весь kit за 30 минут. Ключевое - качество промпта. Чем точнее описана позиция, стек, культура компании, тем релевантнее результат. После 10+ наймов накапливается библиотека проверенных вопросов с реальными примерами сильных и слабых ответов.

Три уровня автоматизации:
- Шаблоны промптов в базе знаний команды - экономят 3-4 часа на вакансию
- Библиотека вопросов - AI подбирает из проверенных, а не генерирует с нуля
- Интеграция с ATS - scorecards в системе, автоматический анализ расхождений

Structured interview - не бюрократия. Это воспроизводимость: одинаковые вопросы, единая шкала, решения на данных.

Подробный гайд с промптами и шаблонами в блоге: https://futurecraft.pro/ru/blog/structured-interview-kit/

Ручной анализ 200 ревью занимает 2-3 недели, и к моменту завершения приоритеты уже сменились. Поэтому большая часть пользовательских отзывов никогда не становятся product decisions.

Есть способ пройти путь от сырых отзывов до конкретных Jobs-to-be-Done за 2 часа. Четыре шага, на каждом работает LLM.

Шаг 1 - извлечение сигналов. Не sentiment analysis и не классификация. Из каждого отзыва извлекается структура: что человек пытался сделать, что пошло не так, какой результат ожидал. Формат - JSON с полями situation, intent, outcome_expected, outcome_actual, emotion, signal_strength. 200 отзывов разбиваются на батчи по 20, обрабатываются за 5-7 минут.

Шаг 2 - кластеризация. Два подхода. Для датасетов до 200 записей достаточно LLM-кластеризации: передать все сигналы и попросить сгруппировать по смыслу intent + situation. Для больших объёмов - embeddings через sentence-transformers и HDBSCAN. Алгоритм сам определяет количество кластеров и выделяет шум. Типичный результат для 200 записей: 8-15 кластеров, 10-20% шума.

Шаг 3 - формулировка JTBD. Каждый кластер содержит повторяющийся паттерн. LLM преобразует его в формулу: "Когда [ситуация], я хочу [действие], чтобы [результат]." Принципиальный момент - JTBD описывает job, не фичу. "Хочу оффлайн-режим" - это фича. "Хочу не зависеть от связи и следовать плану в поездке" - это job. Второе открывает пространство решений: оффлайн-карты, предзагрузка, SMS-fallback, печатная версия.

Шаг 4 - валидация. Три проверки. Обратная трассировка: каждый JTBD должен прослеживаться минимум до 5 конкретных отзывов, иначе это может быть галлюцинация модели. Тест на overlap: два JTBD не должны описывать один job разными словами (порог - 0.6). Тест на actionability: можно ли за 2 недели сделать минимальное решение для этого job.

Ключевое отличие от ручного процесса - воспроизводимость. Три прогона одного датасета с temperature 0.3 дают 85-90% совпадения JTBD. Два аналитика, работающие вручную - 40-60%.

Несколько ловушек. Анализ без контекста продукта - модель генерирует JTBD для фич, которые уже существуют. Игнорирование позитивных отзывов - пятизвёздочные ревью содержат JTBD, которые продукт уже закрывает, это валидация стратегии. Кластеризация по словам вместо смысла - "карта тормозит" и "маршрут не загружается оффлайн" выглядят по-разному, но это один кластер (доступ к маршруту).

Стоимость полного цикла: $3-6 за 200 отзывов. День работы product-аналитика - $300-500.

Минимальный стек: один LLM API, Python-скрипт для батчинга, Google Sheets для результата.

Подробный гайд с промптами и примерами в блоге: https://futurecraft.pro/ru/blog/jtbd-ai-research/

Pitch deck - не набор слайдов, а инструмент продажи с драматической аркой. Большинство фаундеров этого не понимают и теряют инвестора на второй минуте.

DocSend проанализировал 200 000+ сессий: среднее время на один pitch deck - 3 минуты 44 секунды. 72% этого времени уходит на три слайда: финансы, команда, продукт. Остальные семь слайдов делят между собой меньше минуты. Задача нарратива - протащить инвестора через эти семь слайдов до финансов, не потеряв его внимание.

Каталог vs. история. Типичный подход: шаблон на 10 слайдов, каждый забит фактами. Результат - каталог. Инвестор видит 20-30 таких в неделю. Нарратив работает иначе: каждый слайд создаёт эмоциональный переход. Problem строит напряжение. Solution снимает его. Traction доказывает, что снятие уже происходит. Ask превращает историю в конкретное предложение.

Три правила, которые держат нарратив.

Первое - один тезис на слайд. Два аргумента на одном слайде означают, что один из них теряется. Инвестор тратит 20-25 секунд на слайд. За это время он усвоит одну мысль, не две.

Второе - каузальная связь между слайдами. Каждый следующий слайд отвечает на вопрос, который возник на предыдущем. Problem вызывает "Как это решить?". Solution вызывает "Это работает?". Product вызывает "Какой рынок?". Если связь рвётся, инвестор начинает листать вперёд.

Третье - эскалация ставок. От "проблема существует" к "проблема стоит $ X млрд" к "мы решаем её прямо сейчас с трекшеном Y". Каждый слайд повышает ставки, не повторяет предыдущий.

Структура следует драматической арке. Экспозиция (Cover + Problem), кульминация (Solution + Product + Market), доказательная база (Business Model + Traction + Competition), развязка (Team + Ask). Порядок не случаен - Problem до Solution всегда, без исключений. Если инвестор не почувствовал боль, решение ему безразлично.

Где чаще всего ломается нарратив. Пять точек разрыва. Market без связи с Problem - описали боль SMB, а TAM считают по enterprise. Traction без контекста - "10 000 пользователей" ничего не значит, "10 000 за 3 месяца без платного маркетинга" значит многое. Ask без обоснования - "$5M на рост" не объясняет ничего, разбивка по направлениям с привязкой к метрикам объясняет всё. Competition через принижение - инвестор знает конкурентов лично, признайте их силу. Начало с решения - инвестор ещё не понимает, зачем ему это.

Адаптация под стадию. Angel-инвестору усиливайте Team и Problem, минимизируйте Market. Seed-фонду - Traction и Market. Series A - Business Model и unit economics. Ядро нарратива одно, акценты разные.

Практический подход. Не пытайтесь собрать весь deck за раз. Начните с Problem-слайда. Если описание проблемы заставляет кивать, продолжайте. Если нет - уточняйте входные данные. Problem - фундамент, на котором стоят остальные девять слайдов.

Подробный гайд с промптами для каждого слайда в блоге: https://futurecraft.pro/ru/blog/pitch-deck-narrative-ai/

AI генерирует посредственную рекламу не из-за ограничений модели, а из-за отсутствия структуры в промпте.

Запрос "напиши рекламный текст для курса по Excel" предсказуемо даёт список функций, пустые обещания и CTA "запишитесь сейчас". Модель заполняет пустоту средним по больнице. Фреймворк убирает эту пустоту — задаёт последовательность: какую эмоцию вызвать первой, когда вводить продукт, как подвести к действию.

Пять фреймворков покрывают 90% рекламных задач.

PAS (Problem - Agitate - Solution) - самый прямой. Три шага: назвать проблему, усилить боль, предложить решение. Работает для аудитории, которая уже осознаёт свою проблему. Формат: короткие объявления, посты, email-темы.

Пример разницы. Без фреймворка: "Наш курс включает 50+ уроков и сертификат. Запишитесь со скидкой 40%." С PAS: "Отчёт, который коллега собирает за 20 минут, у вас занимает полдня. За квартал - 130 часов на задачи, которые решаются тремя функциями. Курс закрывает этот разрыв за 6 недель." Первый описывает курс. Второй описывает ситуацию читателя.

AIDA (Attention - Interest - Desire - Action) - для холодной аудитории, которая пока не осознаёт проблему. Четыре фазы: факт, останавливающий скролл; контекст, почему это важно сейчас; результат через чужой кейс; одно действие. Подходит для лендингов, email-рассылок, описаний продуктов.

BAB (Before - After - Bridge) - фреймворк контраста. Текущая реальность, желаемая реальность, механизм перехода. Работает, когда нужно показать трансформацию. Ключевое правило: конкретные цифры в "Before" и "After", механизм вместо обещания в "Bridge".

FAB (Features - Advantages - Benefits) - технический фреймворк для B2B и продуктов, где характеристики решают. Переводит спецификации в преимущества, преимущества - в выгоды. Формат: таблица, не сплошной текст. Работает на этапе сравнения вариантов.

4U (Urgent - Unique - Ultra-specific - Useful) - для заголовков и коротких форматов. Четыре критерия: причина действовать сейчас, отличие от конкурентов, конкретные цифры, понятная выгода. Ограничение: 70 символов. "Бесплатный вебинар по таргету" превращается в "CPL 180 р вместо 500 р: воронка VK Ads для инфобизнеса (80 мест)".

Как выбирать. Аудитория знает проблему - PAS. Не осознаёт проблему - AIDA. Нужна трансформация - BAB. Техническое сравнение - FAB. Заголовок - 4U.

На практике фреймворки комбинируются. Заголовок по 4U, тело по PAS, лендинг по AIDA. AI справляется с составными промптами, если структура задана явно.

Три правила промпт-инженерии для рекламы:

1. Ограничения вместо свободы. "Напиши текст в 150 слов, без прилагательных в превосходной степени, с одной цифрой в каждом абзаце" - даёт текст, с которым можно работать.
2. Антипаттерны. Прямой запрет конкретных слов ("без уникальный, инновационный, `лучший на рынке`") убирает маркетинговый шум эффективнее позитивных инструкций.
3. Итерация через критику. Сгенерировали текст - следующий промпт: "Оцени по конкретности, узнаваемости и действенности. Перепиши слабые части."

Типичные ошибки: генерация без описания аудитории (текст "для всех" = ни для кого), слишком много обещаний (ограничивайте: одно обещание, одно доказательство, одно действие), генерация 10 вариантов одним запросом (модель начинает повторяться - максимум 2-3 за раз, между запусками меняйте фреймворк).

Фреймворки не заменяют знание рынка. Идеально структурированный PAS провалится, если боль выбрана неверно. AI-тексты склонны быть гладкими, но безопасными - человеческая редактура нужна для остроты.

Подробный гайд с промптами и примерами в блоге: https://futurecraft.pro/ru/blog/ai-ad-copy-frameworks/

SDR тратит 60-70% времени на лиды, которые никогда не закроются. Не потому что плохой продавец - потому что нет задокументированного ICP.

68% B2B-компаний работают без формального Ideal Customer Profile. Классический подход - воркшопы, опросы клиентов, профиль на доске - занимает 2-4 недели и выдаёт субъективное мнение, а не данные. AI сжимает процесс до 2-3 дней.

Три уровня данных, которые нужны для анализа:

1. CRM-данные - закрытые сделки (won/lost), активные клиенты с NPS и retention, churned с причинами ухода
2. Внешние источники - LinkedIn Sales Navigator, G2/Capterra reviews конкурентов, вакансии компаний (нанимают на роли, связанные с вашей проблемой - значит, проблема реальна)
3. Контекст продукта - 3-5 предложений о продукте, ценовой диапазон, ключевое отличие от альтернатив

Без третьего пункта AI выдаст generic-профиль из учебника по маркетингу.

Pipeline от данных до ICP:

- Загрузить CRM-выгрузку в LLM, найти паттерны: топ-3 индустрии по win rate, оптимальный размер, корреляция источника лида и конверсии
- Сгенерировать 2-3 ICP-гипотезы - не один профиль, а три варианта с firmographics, trigger events, buying signals и disqualifiers
- Зафиксировать каждый ICP в одностраничную карточку: единый формат для SDR, маркетинга и продукта

Scoring-модель - must-have (40% веса), should-have (35%), nice-to-have (25%). Каждый входящий лид получает числовой score: 80-100 - приоритет, 60-79 - стандарт, ниже 40 - дисквалификация. В автоматическом режиме: лид попадает в CRM, обогащается через Clay/Clearbit, данные уходят в LLM, score записывается обратно.

Negative ICP экономит больше ресурсов, чем позитивный. Определить, кому не продавать: компании с win rate ниже 10%, клиенты с churn до 6 месяцев, сделки с циклом вдвое длиннее среднего. Hard disqualifiers - автоматический фильтр в CRM, лид не попадает в pipeline.

Валидация обязательна. AI-сгенерированный ICP - гипотеза. Минимальные пороги для подтверждения: coverage > 40% (ICP покрывает существенную часть won-сделок), win rate для ICP-match > 1.5x от non-match, retention > 1.2x. Если не проходит - сужайте или расширяйте критерии.

Чего не делать: один раз определили ICP и забыли. Пересматривайте минимум раз в квартал. Триггеры для внеплановой ревизии - win rate упал на 15%+, новый продукт открывает сегмент, конкурент зашёл в ваш ICP-сегмент, churn растёт в конкретной нише.

Подробный гайд с промптами и шаблонами в блоге: https://futurecraft.pro/ru/blog/icp-definition-ai/