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/