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

В Точка Банк эту задачу решают диалог‑коучи — эксперты, которые оценивают чаты по множеству критериев и проводят подробные разборы на специальных встречах. Но при потоке в сотни обращений в день часть диалогов не попадает в разбор, а часть может оцениваться субъективно.

Мы задались вопросом: можно ли сократить объём рутинной ручной работы и при этом сохранить — а возможно, и повысить — точность оценки? Гипотеза была простой: если использовать LLM для предварительной оценки чатов, то диалог‑коучи смогут работать только с отобранными, действительно показательными диалогами без необходимости просматривать весь массив вручную.

Такой подход позволил бы:

• сэкономить часы на ручной проверке сотен чатов,

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

• стандартизировать первичную оценку и снизить субъективность.

Проект назвали «Автомануал для диалог‑коучей». Предполагалось, что пул диалогов будет прогоняться через серию промптов, получать оценки по ряду критериев с помощью LLM и общую среднюю оценку диалога с помощью кода.

Как проходила ручная оценка диалогов до внедрения LLM

Изначально диалог‑коучи просматривали чаты вручную и выставляли оценки по 10 критериям:

• «Шаг вперёд»: дал ли специалист больше, чем просто ответ на вопрос?

• «Отработка возражений»: как специалист справился с негативом или сомнениями клиента?

• «Ответственность»: взял ли специалист на себя ведение запроса, проявил ли инициативу?

• «Работа с информацией»: насколько корректным и информативным был ответ.

• «Язык Точки»: был ли ответ грамотным и структурированным?

• «Эмоциональный контакт»: почувствовал ли клиент, что его услышали?

• «Общение на языке выгод»: предложил ли специалист продукт, который поможет клиенту вести бизнес?

• «Инициативность»: предложил ли специалист решение, даже если клиент прямо о нём не просил?

• «Приёмы активного слушания»: насколько специалист был вовлечен в диалог?

• «Правильные вопросы»: задал ли специалист нужные уточняющие вопросы?

Каждый критерий включал в себя несколько параметров. Например, при анализе по критерию «Язык Точки» оценивались:

• грамотность,

• умение просто и доступно объяснить сложные процессы,

• уместность использование эмодзи,

• структурность ответа,

• форматирование, облегчающее чтение с экрана,

• отсутствие канцеляризмов и бюрократических выражений.

По каждому критерию диалог оценивался от 1 до 3:

1 — зона роста;

2 — есть, над чем поработать;

3 — сильная сторона.

Оценка по критерию складывалась из оценок параметров, которые выставлялись достаточно субъективно. Существовали инструкции и примеры, но каждый человек применял их так, как сам понимает. В месяц на предварительный отбор и анализ диалогов могло уходить до 900 часов.

Ограничения LLM при работе с комплексными задачами

На старте проекта предполагалось, что LLM будет оценивать диалоги точно так, как человек. Но довольно скоро выяснилось, что

Один промпт = одна задача

Каждый критерий включал в себя несколько параметров. И если человек без проблем выводил по ним среднюю оценку, то для LLM это стало сложной задачей. Сначала хотели для оценки каждого критерия использовать один промпт. Однако попытки разом выполнить несколько задач (оценить несколько параметров, входящих в один критерий) сильно увеличивали промпт и приводили к ошибкам.

Оценивать некоторые параметры с помощью LLM было нерентабельно

Например, не было смысла оценивать форматирование текста: абзацы и отступы видны сразу.

Некоторые моменты не поддавались оценке LLM

Например, LLM не хватало контекста для оценки процессуальных ошибок, уместности предоставления скидки и др.

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

С чего начали: оценка критерия «Шаг вперёд» и первые тесты промптов

Серию промптов начали с оценки по критерию «Шаг вперёд», в котором анализировали два параметра: «Полнота ответа» (насколько исчерпывающий ответ дал специалист) и «Предоставление дополнительной информации» (предоставил ли специалист полезную информацию за рамками прямого ответа на вопрос). Для каждого параметра написали свой промпт. LLM возвращала оценку параметра в виде числа (1, 2, 3) и обоснование этой оценки.

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

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

Работу над проектом начали в январе 2025: в качестве LLM использовали gpt-4о и gpt-4о‑mini. Мини хорошо справлялась в общим анализом. Например, на должном уровне оценивала реплики специалистов с точки зрения умения строить диалог, исходя из ценностей клиента, полноту ответа, корректность предложения сервисов.

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

Критерий «Язык Точки» оказался самым сложным для LLM

Одним из самых сложных для оценки LLM стал критерий «Язык Точки», в котором для оценки оставили только параметры «Структурность ответа» и «Канцеляризмы». От остальных — определения грамотности, умения просто и доступно объяснить сложные процессы, уместности использования эмодзи, форматирования — отказались.

Частично потому, что LLM допускала много ошибок (неверно считала смайлики, протестовала против их использования, путалась в запятых), частично потому, что по некоторым параметрам (умение просто и доступно объяснить сложные процессы, форматирование) специалисты получали нарекания от диалог‑коучей крайне редко.

Со структурностью ответа gpt-4o справилась отлично, а вот количество версий промпта по оценке канцеляризмов перевалило за 30. Необходимо было найти в диалоге запрещенные к употреблению слова (например, ручная проверка, чиновник) и сокращения (физик, ПК, техотдел).

Уточнение инструкции в попытке заставить LLM различать части речи (актуализация — актуализировать) приводили к тому, что так же «ответственно» она относилась и к поиску слов. В результате мы получали ложноотрицательные ответы, когда ошибкой назывался не «операционный день» (словосочетание из списка), а «рабочий день».

Для повышения точности в промпте пробовали использовать два списка слов: запрещённых и разрешённых, и просили LLM после завершения анализа и поиска слова в первом списке проверять, не находится ли слово во втором. Это помогло, но незначительно.

Качество ответов LLM было значительно ниже, чем на всех остальных промптах. Например, на других критериях точность составляла 95-97%, а при оценке канцеляризмов — только 87-90%.

Сравнение моделей: где лучше справилась gpt-4.1, а где — 4о

После появления новой версии gpt мы протестировали все промпты на gpt-4.1 и gpt-4.1-mini. Обнаружили, что gpt-4.1, с одной стороны, более дотошно работала с текстом и учитывала больше нюансов в определении роли, с другой — достаточно часто перегибала палку там, где нужна была точность. Поэтому часть промптов оставили на gpt-4о и gpt-4о‑mini, а часть перевели на gpt-4.1 и gpt-4.1-mini, которые в ряде случаев работали гораздо лучше и были дешевле.

Параллельно с промптами: разработка дашборда для работы с диалогами

Параллельно с подготовкой промптов разрабатывали архитектуру. Первоначально реализовать Автомануал решили в виде дашборда на базе Power BI, в котором диалог‑коуч мог бы просмотреть диалоги за определённый период, увидеть среднюю оценку, оценку по параметрам, обоснование оценки.

Однако из‑за сложности связки «DWH — маскиратор — Prompt Storage — ChatGPT» отказались от дашборда и реализовали в рамках внутреннего сервиса.

Prompt Storage — это инструмент для хранения и систематизации промптов, который позволяет их хранить, использовать и адаптировать под разные задачи.

Структура промптов и процесс их улучшения на основе реальных данных

Для каждого критерия мы создавали один большой промпт с более‑менее повторяющейся структурой: Role, Context, Task, Input, Rules, Masked Data, определения понятий (например, Types of specialist responses), Algorithm, Output, Output Template, Examples.

После первого прогона сразу становилось ясно:

• где модель понимает не так;

• какие нюансы человек учитывает, а модель — нет.

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

В ряде случаев в промпте мы:

• Давали наше определение понятия, чтобы избежать размытости и приблизить ответ LLM к оценке человеком.

• Меняли структуру: например, размещали примеры не в конце промпта, а включали в пункты Rules.

• К Examples дополнительно указывали, какой это пример (хороший/плохой) и как он был бы оценён диалог‑коучем.

Также мы отказались от детальной шкалы (1, 2, 3), которая использовалась в ручной оценке. LLM на ней часто «плавала», особенно между 2 и 3.

Поэтому перешли к упрощённой:

2 — всё хорошо, явное попадание в критерий;

1 — есть, над чем поработать.

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

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

Как мы тестировали промпты

Тестирование шло в несколько итераций. Процесс выглядел так:

• Пишем черновой промпт — логичный, по‑человечески понятный.

• Прогоняем на части реальных диалогов с ручной оценкой коучей.

• Сравниваем ответы: совпадают ли оценки? Совпадают ли аргументы?

• Находим расхождения и разбираемся, почему они возникли:

  • Коуч смотрит на контекст глубже?

  • Модель не различает полутона?

  • Не хватает определения понятия?

• Правим промпт — иногда это одна строка, иногда полная перестройка.

• Повторяем — пока промпт не даёт стабильные и логичные ответы на новой выборке.

Иногда мы отдавали определение понятия модели, если результат был ближе к оценке человеком. Например, наличие эмоционального присоединения и эмпатии LLM более точно находила без наших подсказок. В других случаях, наоборот, поясняли, что мы имеем в виду, чтобы исключить неоднозначность. Например, что считать возражением в чате. Так для LLM это было явное противостояние: «Нет, этот продукт мне не подходит», но специалисты обращали внимание и на более тонкие нюансы.

Такой подход дал надёжную базу промптов, которую можно адаптировать под другие задачи.

С чем столкнулись в процессе работы

1. Дособирали датасеты

Мы взяли одну большую выборку без фильтрации под конкретный критерий. На практике это обернулось перекосом:

• для одного промпта хватало примеров «хорошо» и «плохо»;

• для другого было мало релевантных кейсов.

2. Проблема общения: заказчик ≠ промпт‑инженер

Диалог‑коучи не всегда понимали ограничения LLM. Например, при ручной оценке они видели, какие сервисы подключены у клиента, какую информацию специалист может получить самостоятельно, с каким вопросом клиент уже обращался. С учётом этой информации они оценивали ответ специалиста и такой же глубины ожидали от LLM.

Также, несмотря на единые требования, оценка диалог‑коучем всегда была субъективна. Это проявилось и в оценке результатов работы LLM: одни соглашались, другие — нет.

Количество итераций увеличивало также то, что ответы LLM далеко не всегда устраивали диалог‑коучей. Например, модель оценивала ответ как неэмпатичный, а по мнению диалог‑коуча специалист проявил достаточно эмпатии. Или специалист видел в вопросе возражение, а LLM — нет.

Приходилось:

• Возвращаться и переосмыслять логику критериев с учётом того, как работает модель, а не человек,

• Вносить в промпт уточнения где‑то через правила, где‑то через примеры.

При передаче результатов работы LLM диалог‑коучам часто возникали «всплывающие» требования: забытые сервисы, новые сценарии, нюансы оценки. Приходилось добавлять забытое в промпт, заново тестировать, проходить ревью.

Несмотря на то, что это несколько замедляло работу, было очевидно, что многие детали сложно было предусмотреть на этапе ТЗ.

Практики, которые улучшили качество генерации и снизили шум в ответах

• Использовали чёткие формулировки: без метафор и без «похоже на».

• Форматированный вывод: заранее задавали шаблон ответа, чтобы результат можно было сразу обрабатывать без дополнительной очистки.

• Упор на интерпретируемость: в ответах модели обязательно запрашивали обоснование оценки — это помогало в ревью и уточнении критериев.

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

• Тестирование на разных типах кейсов: проверяли промпт не только на типичных примерах, но и сложных случаях.

• Фокус на устойчивость: приоритет отдавался формулировкам, которые давали стабильные ответы при повторных запусках.

• Обобщённые правила: мы не пытались описать все частные случаи и делали ставку на общую логику.

• Примеры с пометками: указывали, какой это пример (плохой/хороший) и как он оценивается.

• Гибкая структура: иногда мы ставили примеры сразу после правил — ближе к началу промпта.

• Минимум лишнего: сокращали всё, что не влияло на оценку.

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

Работа на проде и планы развития

Сейчас доступ к инструменту открыт всем диалог‑коучам, но активно им пользуется примерно половина — около 30 человек. Первая версия уже показала ценность: время на подбор диалогов сократилось на 35%. Специалисты отмечают, что LLM подсвечивает моменты, на которые они не обратили внимания, подсказывает более точные формулировки.

Раньше на подготовку анализа уходило от 600 часов работы. В планах команды сократить это время вдвое. 

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

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

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

Затраты при этом остаются минимальными: за 1,5 месяца работы сервиса на оценку диалогов потратили чуть больше $150.

Заключение

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