Дообучить модель на внутренней переписке без потери стиля

Почему переписка легко ломает стиль модели

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

Главная сложность - переписка редко бывает полной. В чатах люди отвечают обрывками: "ок", "смотри выше", "да, как в прошлый раз". Человек понимает смысл, потому что помнит разговор и знает контекст. Модель этого не знает. Если таких примеров много, она тоже начинает писать расплывчато и пропускать важные детали.

Быстро ломается и тон. Даже в одной команде сотрудники отвечают по-разному на один и тот же вопрос. Один пишет сухо и коротко, другой шутит, третий уходит в тяжелые формулировки. Для модели это не "варианты стиля", а конфликтующие правила. В результате голос начинает скакать: один ответ спокойный и ясный, следующий - резкий или слишком фамильярный.

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

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

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

Что брать в датасет, а что нет

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

Частая ошибка на старте проста: выгрузить весь архив и надеяться, что модель сама отделит хорошее от плохого. Обычно происходит обратное. В рабочих чатах слишком много мусора, и модель быстро подхватывает именно его.

Какие примеры подходят

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

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

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

Что лучше исключить

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

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

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

Что убрать до первой версии датасета

До обучения стоит убрать все, что не учит модель полезному ответу. Она охотно запоминает мусор, а потом повторяет чужие подписи, старые телефоны и фразы вроде "отправлено с iPhone" там, где их быть не должно.

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

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

Отдельный риск - личные данные. Имена, телефоны, почта, адреса, номера договоров и любые данные клиента лучше скрыть или заменить метками еще до обучения. Если команда работает с жесткими требованиями по хранению и маскированию данных, этот шаг нельзя откладывать. В инфраструктуре вроде AI Router такие проверки можно встроить в процесс, но сам датасет все равно лучше чистить заранее.

Еще одна частая ошибка - оставлять реплики не по теме. Шутки между коллегами, раздраженные ответы, спор ради спора, обсуждение отпуска в середине рабочей ветки звучат живо, но стилю не помогают. Модель не понимает офисный контекст так, как его понимает человек. Она просто копирует тон.

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

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

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

Как сохранить стиль, а не чужие ошибки

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

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

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

Отдельно приведите к одному виду сокращения, названия команд и термины. Если в одном письме пишут "ДБО", в другом "дистанционное банковское обслуживание", а в третьем просто "банк онлайн", модель начнет смешивать формы. То же касается дат, валют, названий продуктов и служебных меток.

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

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

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

Оставляйте в датасете ответы, после которых человек действительно понимает, что делать дальше. Тогда модель перенимает стиль команды, а не ее слабые привычки.

Как собрать набор по шагам

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

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

Потом разберите переписку на пары "вопрос - ответ". Для первой версии короткие и понятные фрагменты работают лучше, чем длинные ветки целиком. Если ответ зависит от пяти прошлых сообщений, лучше добавить краткий контекст вручную или не брать такой пример вовсе.

После этого отфильтруйте слабые записи. Спорные ответы, грубый тон, устаревшие инструкции, фактические ошибки и фразы вроде "ну вроде должно работать" лучше убрать. То же касается дублей. Если двадцать операторов почти одинаково ответили на один и тот же вопрос, оставьте два-три чистых примера.

Дальше приведите записи к одному виду. Одинаковые роли, одинаковая разметка, единый формат дат, имен и вложений сильно упрощают обучение и проверку. Например, если вы выбрали схему user, assistant, optional_context, используйте ее везде. Если в одной части датасета стоит "Клиент:", а в другой "Пользователь:", вы сами добавляете лишний шум.

Перед полным запуском соберите маленький пилотный набор. Часто хватает 100-300 хороших пар, чтобы заранее увидеть проблемы со стилем и не тратить лишние деньги. На таком объеме легко заметить, не стала ли модель слишком официальной, слишком резкой или, наоборот, расплывчатой.

Хороший пилот нередко спасает от дорогой ошибки. Команда может быть уверена, что учит модель вежливому стилю, а на деле половина "лучших" ответов окажется шаблонной канцелярщиной. На малом наборе это видно быстро.

Если вы уже гоняете несколько моделей через единый шлюз, сравнение пилота становится проще. Например, в AI Router можно прогнать один и тот же набор запросов через один OpenAI-совместимый эндпоинт и понять, где проблема в датасете, а где в самой модели.

Пример на одном простом сценарии

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

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

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

На практике картина часто выглядит так: у вас есть 2 000 диалогов по возвратам за полгода. После быстрой фильтрации остается 700. После ручной проверки - 280 действительно хороших примеров. Это нормально. Объем сам по себе не спасает. Качество примеров важнее.

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

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

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

Как проверить результат до запуска

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

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

Не смотрите на один признак. Ответ может звучать "по-вашему", но ошибаться в фактах или быть вдвое длиннее, чем пишет команда. Обычно достаточно оценивать три вещи: тон, точность и длину. Если проседает хотя бы одна, модель еще рано выпускать.

Короткие запросы и длинные цепочки лучше проверять отдельно. На коротких сообщениях модель чаще срывается в штампы вроде "Спасибо за обращение" или отвечает слишком общо. В длинных диалогах она теряет нить, повторяется и начинает придумывать детали, которых не было в переписке.

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

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

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

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

Где команды ошибаются чаще всего

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

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

Другая частая ошибка - смешивать сильные и слабые ответы в одном наборе. Команда берет диалоги лучших менеджеров, а потом добавляет туда черновики, спорные ответы, усталые сообщения в конце дня и письма с явными ошибками. После этого модель учится усреднять стиль. А усредненный стиль почти всегда хуже живого хорошего примера.

Когда набор искажает стиль

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

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

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

Хорошая проверка всегда немного ручная. Возьмите 30-50 реальных сценариев и посмотрите, где модель срывается. Так ошибки видно сразу, а не после запуска на всю команду.

Короткий чек-лист перед запуском

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

Проверьте личные данные: имена, телефоны, почты, номера договоров, адреса и любые фрагменты, по которым можно узнать человека или клиента. Если сомневаетесь, лучше замаскировать поле, чем оставить как есть.

Убедитесь, что каждый пример учит чему-то одному. Один диалог должен показывать один тип задачи: ответ на жалобу, уточнение условий, вежливый отказ. Если в примере сразу три темы, модель перенимает кашу.

Сверьте тон с живой работой команды. Возьмите 20-30 свежих ответов сильных сотрудников и сравните их с датасетом. Если в наборе больше сухих, резких или канцелярских формулировок, модель утащит именно их.

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

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

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

Если инфраструктура уже поддерживает быстрый возврат на прошлую модель или старый маршрут через API-шлюз, запуск проходит спокойнее. Но сам шлюз не исправит плохой датасет. Это все равно нужно проверять руками.

Что делать после первой версии

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

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

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

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

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

Если вы прогоняете несколько моделей через один OpenAI-совместимый API, этот этап удобно собрать в AI Router на airouter.kz. Один и тот же набор тестов можно запустить на базовой модели, дообученной версии и других кандидатах через один эндпоинт, не меняя SDK, код и промпты. Это упрощает честное сравнение до релиза.

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