| title | Протокол re!think it: Реальные примеры работы | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| description | Два разбора реальных диалогов: сравнение ответов LLM с протоколом re!think it и без него. Демонстрирует механики HARD STOP (блокировка при нехватке контекста) и C_BYPASS (обход фреймворка для административных запросов) на задачах HR и системной инициализации. | ||||||||||
| keywords |
|
||||||||||
| tags |
|
||||||||||
| version | 1.0 | ||||||||||
| lang | ru | ||||||||||
| related_en | examples_en.md |
Этот файл документирует реальные диалоги, где один и тот же запрос обрабатывается с протоколом и без него. Каждый кейс изолирует конкретный сбой стандартного поведения LLM и показывает, как архитектурные ограничения протокола меняют качество ответа.
Как читать этот файл:
- Блоки с меткой
[ПРОВАЛ]— это ответы модели без протокола: именно то поведение, которое протокол призван предотвратить. - Блоки с меткой
[КОРРЕКТНОЕ ПОВЕДЕНИЕ]— ответы с активным протоколом: целевое поведение. - Каждый кейс завершается
💡 Выводом, описывающим структурную разницу и её практическое значение.
📂 Четыре расширенных кейса на английском: examples_en.md (SOFT STOP, HARD STOP, Assumptions, C_BYPASS — бизнес-стратегия, HR, SaaS, техархитектура)
| № | Тема | Тестируемые модели | Механика протокола | Ключевой инсайт |
|---|---|---|---|---|
| 1 | Система мотивации отдела продаж | Pro 3.1 (без пр.) vs Flash 1.5 (компактный) | HARD STOP — нехватка контекста | Мощная модель угадывает; протокол заставляет спросить |
Исходный запрос: «Спроектируй систему мотивации для отдела продаж. Сейчас они на голом окладе, хочу перевести на процент с продаж. Напиши план перехода»
Запрос звучит конкретно. Но в нём отсутствует критическая переменная: длина цикла сделки и маржинальность. Без неё любая комиссионная схема — это ставка вслепую. Процент с оборота, работающий в B2C, ломает бизнес в Enterprise B2B с годовым циклом.
Модель не знает специфики бизнеса, но угождает: выдаёт уверенный, красиво оформленный шаблонный ответ.
[ПРОВАЛ — Эффект центроида: модель сгенерировала ответ на основе среднестатистических данных без проверки достаточности контекста; критически важная переменная (цикл сделки) не запрошена]
Ответ модели (сокращенно):
«...Оптимальная модель состоит из трех блоков: Твердый оклад (30–40%), Мягкий оклад (10–20%) и Процент (40–60%). Прогрессивная шкала бонусной части: Выполнение 70–89% — 2% от суммы продаж. Выполнение 90–100% — 4% от суммы продаж...»
Анализ провала: Модель не спросила про длину цикла сделки и маржинальность. Она по умолчанию выдала метрики для B2C-продаж. Если применить эту схему в Enterprise B2B с годовым циклом — компания разорится на выплатах с авансов, а менеджеры будут бросать сложных клиентов ради новых быстрых сделок. Это не «немного неточный» ответ. Это рецепт уничтожения отдела продаж.
[КОРРЕКТНОЕ ПОВЕДЕНИЕ — HARD STOP: вычислен
$\Delta = G - (C + T)$ ; обнаружена критическая нехватка переменной; генерация заблокирована; задан один точечный уточняющий вопрос]
Ответ модели:
[re!think protocol | #0001 | PROT_A | S_R.0001: Архитектор бизнес-процессов | S_F.0001: Плотный/Структурный][C.0001: Отдел продаж на 100% окладе; цель — переход на % (комиссионные)][T.0001: Sales Compensation Engineering (Quotas, Accelerators, Clawbacks)][G.0001: План перехода с фикса на результат без потери текущих кадров][Δ.0001: Δ_C → ОСТАНОВКА | Допущения: нет]Для проектирования жизнеспособной системы мне нужно одно уточнение по структуре сделок: Каков средний цикл сделки (LTV/Cycle) и маржинальность продукта? Вариант А: Короткий цикл (продажи в день/неделю), низкий чек — важен объем. Вариант Б: Длинный цикл (B2B, месяцы), высокий чек — важна дожимная стадия и удержание.
«Длинный цикл (продаем ИТ-проекты внедрения ERP), высокий чек (от $50 000 до $1 млн за проект), важна дожимная стадия и постоянный контакт с клиентами...»
[КОРРЕКТНОЕ ПОВЕДЕНИЕ — SOLVE: контекст достаточен; сформулированы допущения; синтезировано решение под конкретную бизнес-модель]
Ответ модели:
[re!think protocol | #0002 | PROT_A | S_R.0002: IT Solution Architect / Sales Consultant | S_F.0002: Структурный план][C.0002: ERP внедрение, LTV $50k–$1M, длинный цикл, высокая экспертность][T.0002: Value-Based Selling + Milestone Commission Model][Δ.0002: Minor → Proceed | Допущения: есть пресейл-инженеры; оклад остаётся (база), но снижается его доля в общем доходе][VRF.0002: P→G ✓ | Контраргумент: риск «выгорания» на длинных сделках без промежуточных выплат | S_V: ✓]Архитектура системы (ERP Sales) Для ИТ-проектов с чеком до $1M чистый процент с оборота опасен — менеджер может «бросить» клиента после подписания договора в погоне за новыми быстрыми сделками. Нужна гибридная milestone-модель:
Состав совокупного дохода:
- Base (40–50%) — для сохранения экспертов.
- Commission (30–40%) — от Cash-in.
- MBO/KPI (10–20%) — защита от инерции на длинном цикле.
Схема комиссионных (Milestones):
- 30% комиссии — по факту подписания контракта и первого аванса.
- 50% комиссии — пропорционально закрытию актов (этапов внедрения).
- 20% комиссии — после финального подписания и отсутствия рекламаций (Success fee).
Протокол заставил младшую модель действовать на уровне Senior HR-директора из крупного ИТ-интегратора. Это произошло не за счёт вычислительной мощности, а потому что фреймворк физически запретил модели выдавать ответ до получения критической переменной.
Мощная Pro-версия «видела» проблему — и проигнорировала её, угождая пользователю. Слабая Flash-версия с протоколом не могла этого сделать:
Системная архитектура бьёт сырые параметры.