Почему CRM-цепочки ломаются на длинных сценариях

Почему CRM-цепочки ломаются на длинных сценариях

У языковых моделей есть неприятная особенность: они могут хорошо отвечать на короткий запрос, но теряют контекст, когда цепочка условий и действий растягивается. Исследование на arXiv показывает, что модель не всегда ведёт «состояние» постепенно. Часто она собирает нужные признаки уже в конце, когда запрос становится полностью явным.

Для CRM это важный сигнал. Если сценарий построен как «пользователь открыл письмо → потом кликнул → потом не купил → потом вернулся через 10 дней», модель или автоматизация могут уверенно звучать, но ошибаться на переходах между состояниями. Особенно это заметно в сложных playbooks, где нужно учитывать:
- источник лида;
- стадию воронки;
- давность последнего контакта;
- поведение в нескольких каналах;
- исключения по продукту или сегменту.

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

Практический вывод для CRM/lifecycle-команды простой. Чем длиннее сценарий, тем меньше надежды на неявную память системы. Нужны явные маркеры состояния: теги, стадии, timestamps, флаги последнего действия, зафиксированные сегменты. Иначе сценарий будет выглядеть логичным только на бумаге.

Если упростить: в длинных lifecycle-цепочках лучше опираться не на «понимание по ходу», а на явно записанное состояние. Именно оно чаще всего спасает retention-логики, триггеры и LTV-сценарии от тихих ошибок.