Как мы строили и улучшали LLM‑слой для общения с покупателями

Мы начали с бота, который должен был снять с поддержки рутинные напоминания. Затем добавили языковую модель, научились учитывать смысл ответов покупателей и собрали каскад из двух судей и арбитра. По обновлённой сводке экспериментов совпадение действий с разметкой выросло с 74% до 84%, а общее число ошибок сократилось на 38% при примерно прежней средней стоимости решения.

Расскажем, как получили этот результат: меняли промпты, проверяли правила, увеличивали контекст и сравнивали модели. Покажем, где показатели улучшались, где мы теряли полезные продолжения вместе с ошибками и почему дополнительный признак процесса оказался важнее части экспериментов с моделями. Результат относится к экспериментальной оценке: выбранный каскад ещё предстоит проверить на новых диалогах и включить в прод.

1. Что мы хотели автоматизировать

Мы работаем с поддержкой покупателей на маркетплейсе. После отзыва с низкой оценкой площадка открывает чат с покупателем. Дальше в разговор может включиться менеджер: уточнить проблему, объяснить порядок действий, помочь разобраться с возвратом.

Некоторые разговоры при этом зависают: покупатель ответил, получил сообщение менеджера и замолчал. Менеджеры возвращались к таким диалогам вручную и отправляли напоминания. Эту часть работы мы и решили автоматизировать.

В первой версии были расписание, тихие часы, ограничение длительности кампании и общий выключатель. По умолчанию бот работал в сухом прогоне. Реальные отправки включали постепенно: сначала на 10% диалогов, затем расширяли охват до 30%, 50% и, наконец, 100%. Так мы могли проверить работу на небольшой выборке покупателей и обнаружить проблемы до того, как они затронут всех. В первой версии любой ответ покупателя останавливал напоминания.

Довольно быстро обнаружилась проблема: бот возвращался в разговоры, которые менеджер уже завершил. Например, вопрос с возвратом был согласован, покупателю оставалось дождаться обработки, а система отправляла ему очередное напоминание.

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

Наша цель была убрать человека из рутинного отбора диалогов. Если сотруднику нужно регулярно открывать разговоры, определять их состояние и расставлять флаги, часть пустой работы остаётся на нём. Мы хотели, чтобы менеджер работал с активными обращениями, где действительно нужны его знания или действие, а состояние остальных разговоров система определяла сама.

Поэтому решили попробовать определять завершённость по тексту переписки.

2. Первый LLM‑слой: завершил ли менеджер разговор

Сначала мы посмотрели, можно ли обойтись шаблонами и ключевыми словами. Оказалось, что вежливое завершение разговора часто содержит приглашение обратиться снова. В обновлённой сводке из 655 «прощальных» сообщений специалиста в 605 одновременно была просьба написать.

Фраза вроде «если появятся вопросы, напишите нам» сама по себе не означает, что покупателю сейчас нужно напоминание. А по наличию слов «напишите» или «обратитесь» отличить открытый вопрос от завершённого разговора не получалось.

Первую задачу для LLM мы намеренно сузили: передавали только последнюю реплику специалиста и просили вернуть одно из трёх состояний — open, closingили unclear. Для начала выбрали Qwen3-30B‑A3B в Cloud.ru ^[1].

Упрощение давало очевидное ограничение: без предыдущих сообщений часть формулировок неоднозначна. Но так мы могли быстро встроить модель в существующую систему и проверить сам подход.

Провайдера и модель вынесли в конфигурацию. Предусмотрели режим наблюдения, в котором вердикты записываются, но не влияют на отправки. При сбое модельного слоя отправку удерживали.

В сводке первого прогона — 260 ответов на 265 запросов: 200 открытых диалогов, 50 завершённых и 10 неопределённых. Среднее время ответа составило около 0,95 секунды. Для этого слоя нас прежде всего интересовало, что модель можно встроить в процесс без заметного ожидания со стороны приложения.

Это подтверждало, что интеграция работает. Качество классификации тогда системно не измерили: посмотрели несколько примеров и пошли дальше. Позже стало понятно, почему такой проверки недостаточно.

3. Почему мы перешли к ответам покупателя

Первый слой отвечал на вопрос о последнем сообщении менеджера. Но после напоминания появлялось новое событие — ответ покупателя. И правило «пришёл любой ответ — останавливаемся» слишком грубо описывало происходящее.

Покупатель мог поблагодарить за решение, попросить больше не писать, сообщить, что деньги ещё не пришли, или отправить короткую реплику без понятного смысла. В одном случае разговор завершён, в другом нужна помощь специалиста, в третьем автоматизация должна прекратить общение. Сам факт ответа не давал достаточной информации.

Это было видно и по ручному разбору переписок после напоминаний. В обновлённой сводке — 435 диалогов с реальными напоминаниями и 310 ответивших покупателей. Из них 155 ждали решения со стороны продавца, 85 попали в группу раздражения, конфликта ^[2] или угроз, 60 — в группу решённых вопросов и благодарностей, ещё 10 — в группу отказов и просьб не писать. Категории были крупными, но уже показывали, насколько различаются следующие действия.

Так появился второй слой: анализировать сообщения покупателя и возвращать решение — продолжать автоматические напоминания, остановиться или остановиться с передачей менеджеру.

В первой постановке было 12 классов. Среди них — благодарность, ожидание решения, просьба не писать, угроза, отказ, сообщение, что предложенное действие не получается, и пустой ответ.

Некоторые категории сразу оказались спорными. Например, «не буду» может означать отказ от конкретного действия или нежелание продолжать разговор. В ранней политике часть отказов допускала продолжение напоминаний. Насколько такое решение уместно, зависит от контекста. Поэтому отказ от общения и отказ выполнить предложенное действие нужно различать явно.

Мы начали улучшать слой принятия решения. Его результатом было действие системы: писать дальше, остановиться или подключить человека. Свободный ответ покупателю эта модель не генерировала.

4. Улучшаем промпт и смотрим на показатели

Для оценки использовали срезы диалогов: доступный на момент решения контекст, ответ модели и ожидаемое действие. На этом этапе эталонную разметку делал AI‑ассистент.

Нас интересовали три показателя:

• Совпадение действия с разметкой. Как часто система выбирает ожидаемое действие.

• Ошибочные «продолжаем». Число случаев, когда модель разрешила продолжение, а по разметке требовалась остановка, делённое на общее число разрешённых продолжений. Именно эта ошибка ^[3] может привести к лишнему сообщению.

• Потеря допустимых продолжений. Сколько случаев, где по разметке можно было продолжить, система остановила.

Последние два показателя имеют разные знаменатели. Их нельзя складывать или напрямую сопоставлять как доли одного потока.

После первых изменений промпта результат выглядел обнадёживающе. На 715 срезах версия r3 чаще совпадала с разметкой, чем r2, и разрешала больше продолжений при том же абсолютном числе ошибок.

На первой выборке доля ошибочных продолжений снизилась примерно с 20% до 12%. Но на дополнительном наборе оказалось 25 ошибок из 60 разрешённых продолжений. В объединённой выборке — 35 из 145, или 24%.

При этом общая точность действия оставалась высокой — около 92%. Противоречия здесь нет: система часто правильно останавливалась, а решения продолжать встречались редко. Хороший общий показатель скрывал заметную долю ошибок в действии, которое нас особенно интересовало.

В ошибочных продолжениях встречались различного рода жалобы, сообщения о том, что покупатель уже выполнил предложенное действие, короткое «всё», номера и выбор вариантов. Модель могла принять их за общий отказ или пустой ответ.

Ещё одна проверка показала нестабильность отдельных решений: повторные прогоны одного промпта меняли часть классов и действий. Поэтому небольшое улучшение в единственном запуске мы уже не могли считать надёжным доказательством.

5. Пробуем правила, дополнительный вопрос и другой контекст

Фильтр после модели

Первый вариант — разрешать продолжение только тогда, когда в тексте есть признаки отказа или определённой жалобы. По сводке, на наборе из 2270 срезов проводили пять диагностических прогонов. С фильтром доля ошибочных продолжений снижалась с 24–31% до 0–7%.

Но фильтр отбрасывал около 40% продолжений, которые по разметке считались допустимыми. Фильтр разрешал лишь небольшую часть случаев, а правила писались после просмотра тех же примеров. Независимой проверки, которая подтвердила бы такой результат, у нас не было. В прод этот фильтр не пошёл.

Ещё один вопрос модели

Затем попробовали дополнительно спрашивать, ждёт ли покупатель действий продавца. Идея казалась разумной: если ждёт, напоминание не заменит решение проблемы. На практике второй вопрос почти всё останавливал — из 145–180 разрешённых продолжений оставалось 15–20.

Такое изменение могло уменьшить число лишних сообщений, но вместе с ними почти исчезало и целевое действие. Нужно было оценивать обе стороны результата.

Больше контекста

Мы сравнили четыре и восемь сообщений контекста. В серии на 1705 срезах восемь не помогли: у r3 получилось 85 ошибок среди 195 продолжений против 65 среди 170 при четырёх сообщениях — около 44% против 38%.

Зато узкое правило «пустой ответ после живого менеджера останавливает напоминания» снизило показатель с 65 ошибок из 170 до 40 из 140 — примерно с 38% до 29%. Число допустимых продолжений сократилось со 105 до 100.

Эта серия проводилась после пересборки контекста. Её исходные 38% нельзя соединять с прежними 24% в график ухудшения: изменились входные данные.

Заодно посмотрели на токены. В среднем из 1520 входных токенов около 1320 занимал системный промпт и только 200 — сам диалог. Сокращение истории почти не влияло бы на стоимость: основная часть запроса приходилась на инструкции.

6. Проверяем, с чем вообще сравниваем модель

Мы сделали форму разметки для одного из менеджеров по общению с покупателями. В ней показывался диалог с контекстом, а менеджер выбирал, следует ли продолжать напоминания или остановиться. На основе его решений мы хотели понять, как перестроить работу модели и приблизить её поведение ^[4] к практике поддержки.

В обновлённой сводке первичная проверка менеджером охватывает 200 примеров. Модель совпала с ним в 170 случаях. При этом ранняя разметка AI‑ассистента совпала с менеджером только в 120 из 200 — в 60% случаев.

Это означало, что прежние цифры измеряли согласие с эталоном, который не вполне отражал ожидаемое поведение ^[5] продукта. Промпт мог лучше соответствовать меткам ассистента и при этом не становиться полезнее с точки зрения ^[6] менеджера.

У человека тоже обнаружились пограничные решения. Например, похожие жалобы на отказ в возврате без прямой просьбы иногда допускали напоминание, а иногда останавливали его. Следовательно, часть расхождений требовала уточнить саму политику.

Для следующей серии в сводке указан набор из 500 диалогов с разметкой менеджера: в 345 случаях следовало остановиться, в 155 — продолжить. Все основные варианты сравнивали на этом наборе.

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

Следующая гипотеза: две модели разных семейств могут по‑разному ошибаться на сложных случаях. Если они согласны, используем общее решение; если расходятся — подключаем более сильную модель.

В качестве судей выбрали Qwen3-30B‑A3B и gpt‑oss-120b. Арбитром — DeepSeek‑V4-Flash, с резервной моделью GLM-4.5-Air. Арбитр получал два анонимных вердикта в случайном порядке и выбирал один из них.

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

На тех же 500 диалогах сравнили одиночные модели и каскад. Помимо r3 попробовали промпт action, построенный вокруг вопроса о необходимости менеджера.

Каскад с r3 уменьшил число ошибочных продолжений с 85 до 50, но стал чаще останавливать допустимые: 60 вместо 45. Более сильная одиночная модель с тем же промптом показала ту же точность действия, что и исходная Qwen.

Промпт action заметно сокращал число продолжений. Изолированно доля ошибок среди них выглядела лучше, но каскад пропускал 125 из 155 допустимых случаев. Для нашей задачи это было слишком сильным сдвигом к остановке.

При r3 судьи соглашались по действию примерно в 78% случаев, арбитр вызывался примерно в 21%. Поэтому каскад по средней стоимости остался сопоставим с одной дешёвой моделью: более дорогой этап требовался лишь части запросов.

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

8. Добавляем признак, которого моделям не хватало

Мы посмотрели на диалоги, где ошибались почти все варианты. Среди них повторялись описания неисправности без явной просьбы. Часть таких диалогов менеджер считал подходящими для продолжения, а инструкции r3 склоняли модели к остановке.

При разборе выяснилось, что важна история участия менеджера. Если человек ещё не отвечал покупателю, такой разговор оценивался иначе, чем ситуация, где специалист уже включился и покупатель ждёт его следующего действия.

На 500 метках менеджера это выглядело так:

• если в диалоге ещё не участвовал сотрудник поддержки, при разметке продолжение разрешалось в 85 из 105 случаев;

• если сотрудник поддержки уже отвечал, при разметке напоминания останавливались в 325 из 395 случаев.

Простое правило «менеджера не было — продолжаем, менеджер был — стоп» совпало с решениями менеджера в 410 случаях из 500, то есть в 82%. Это больше, чем любой вариант предыдущей серии.

Такое правило ещё не готовая политика для эксплуатации: оно не учитывает все важные исключения. Но как базовая точка сравнения оно показало, какой информации недоставало моделям. Мы добавили явную пометку «менеджер уже отвечал: да/нет».

Одновременно уточнили инструкции и сравнили два языка промпта и два набора категорий — 12 и семь. Получилась следующая таблица.

Выбрали русский промпт с семью классами. У английских вариантов точечная оценка точности была немного выше: 85% против 84% у выбранного. Само по себе такое сравнение не отделяет эффект языка от остальных изменений и вариативности ответов. Утверждать преимущество английского промпта по этой сводке мы не стали.

В выбранном варианте судьи сходились по действию в 84% случаев против 80% у русского варианта на 12 классов. Семь категорий давали более простую схему решений при точности 84%. Это стало основанием выбрать её для следующего этапа проверки. Точное число обращений к арбитру здесь не приводим: в обновлённой таблице не уточнено, относятся числа к количеству запросов или к процентам.

Средняя стоимость решения составила около 0,03 ₽, оценка максимальной стоимости — 0,042 ₽. Цена осталась примерно на уровне исходной одиночной модели.

9. Как изменились показатели

Для итогового сравнения возьмём исходную одиночную Qwen с r3 и правилом, каскад с r3 и выбранный новый каскад. По обновлённой сводке все три варианта проверялись на одних и тех же 500 диалогах с метками менеджера.

В этом сравнении совпадение действий выросло на 10 процентных пунктов, общее число ошибок сократилось со 130 до 80 — примерно на 38%. Число ошибочных продолжений снизилось с 85 до 50 — примерно на 41%. При этом допустимых продолжений потеряли 30 вместо 45 — на треть меньше. Средняя стоимость осталась примерно прежней.

10. Итоги и дальнейшее развитие

В итоге мы получили хорошее улучшение системы: слой решений стал чаще выбирать нужное действие и реже разрешать лишние напоминания. К этому привела последовательная работа с промптами, контекстом и категориями ответов, а также переход к каскаду моделей. Решения менеджера помогли связать инструкции модели с реальными ситуациями в поддержке.

По результатам описанных экспериментов итог этого этапа — 84% совпадений действий вместо 74%, на 38% меньше ошибок в целом и на 41% меньше ошибочных продолжений при примерно прежней средней стоимости решения — около 0,03 ₽.