Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
CRM-агенты принимают слова продавца за факт даже тогда, когда те противоречат ценам и правилам компании. В препринте AmpUp Research, который не прошёл рецензирование и приводит замеры самого автора, модель пропустила 29 из 31 неприемлемой сделки, читая только расшифровку звонка. Более крупная модель или дополнительный контекст сами по себе не устраняют эту ошибку: для точных правил решение лучше отделить от чтения текста.
Как отделили влияние продавца от нехватки данных
Работа разбирает квалификацию лидов в CRMArena-Pro. Агент должен определить, подходит ли сделка по бюджету, полномочиям покупателя, его потребности и срокам. Полномочия и потребность видны из разговора, а бюджет и срок нужно сверять с каталогом цен и политикой установки.
Проверка охватила 100 синтетических задач из корпоративных продаж. Для каждого настоящего отказа по бюджету или сроку автор смотрел, что сказал торговый представитель: назвал условия приемлемыми, не высказался или сам указал на проблему.
Среди 35 настоящих отказов почти все сопровождались оптимистичным заявлением продавца, которое расходилось с внутренними документами. Только в 3 случаях модель ошиблась без такого заявления. Это отличает влияние заинтересованного источника от обычной нехватки сведений: агент не просто не знает цену или срок, а принимает чужой вывод за доказательство.
Метод пока показывает устойчивое совпадение, а не доказывает причинность. Чтобы изолировать влияние одной фразы, пришлось бы менять утверждение продавца, сохраняя остальную расшифровку неизменной. Здесь использован другой диагностический признак: ошибки сосредоточились именно там, где заинтересованный участник уверенно объявлял сделку подходящей.
Почему доступ к правилам не исправил решение
Дополнительный контекст не сделал модель осторожнее. Когда ей вместе с расшифровкой передали цены и политику установки, строгая точность упала с 41% до 18%. Строгая точность здесь означает долю ответов, где агент назвал ровно правильный набор причин отказа.
Модель стала чаще замечать настоящие нарушения, но начала приписывать их подходящим сделкам. Иными словами, она улучшила охват проблем ценой множества ложных срабатываний. Записи помогли найти возможное несоответствие, но не помогли остановиться после достаточной проверки.
Затем автор зафиксировал извлечённые из текста поля и менял только компонент, который проверяет бюджет и срок. Модель выделяла товары, количества, заявленный бюджет и требуемую дату, после чего либо сама выносила решение, либо передавала данные обычному коду. На противоречивых сделках код поймал 28 отказов, а сквозное рассуждение модели — 2.
Направление результата повторилось на моделях OpenAI, Anthropic, Moonshot и Alibaba. Однако на моделях, которые уже правильно считают и редко ставят лишние флаги, разница между моделью и кодом оказалась в пределах погрешности. Поэтому работа обосновывает более предсказуемое разделение ответственности, а не гарантированный прирост для любой модели.
Когда команде стоит менять архитектуру
Если решение опирается на точное и однозначное правило, модель стоит оставить на этапе чтения. Она преобразует письмо, звонок или карточку CRM в узкую структуру: товар, количество, бюджет, срок. Проверяемый код затем суммирует цены, выбирает норматив установки и выдаёт результат.
Такой контур не требует переносить в код всё решение. Потребность клиента и полномочия собеседника по-прежнему можно определять моделью, поскольку они выражены естественным языком. Код забирает только те части, где организация уже сформулировала точное правило и ожидает одинакового ответа при одинаковых данных.
Перед внедрением нужно проверить саму основу решения. Правило должно быть однозначно задано и распознаваться по доступным полям. Заранее выбранная проверка на другой задаче CRMArena-Pro не обобщила результат: одинаковые входные данные получали разные метки, поэтому детерминированный решатель не мог восстановить скрытый принцип.
Граница работы узкая: один тип задач из одного бенчмарка, синтетические записи корпоративных продаж и отдельные запросы без диалога. В рабочей системе остаются ошибки извлечения, нестандартные поля, права доступа и случаи, которые нужно передавать человеку. Код не устраняет ошибку модели, если она неверно извлекла количество или бюджет; он лишь не позволяет её свободному рассуждению подменить формальное правило.
Для команды практический вывод состоит не в выборе более крупной LLM, а в разборе пути до решения. Если итог можно пересчитать из структурированных фактов, этот шаг стоит сделать проверяемым и повторяемым. Если политика допускает несколько трактовок, сначала придётся уточнить её: ни модель, ни код не восстановят правило, которого нет во входных данных.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
