Дообучение Embedding-модели под домен заказчика

Дообучение embedding-модели: когда поиск не понимает домен

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

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

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

Симптом узнаётся по трём признакам: сотрудники перестают формулировать запросы словами и ищут по номерам, качество выдачи падает по мере наполнения базы, а на доменных формулировках поиск не находит нужное при живом документе в индексе. Это ровно тот случай, когда дообучение embedding-модели на парах «запрос — релевантный фрагмент» из вашей предметной области возвращает попадание в топ. Разбираем, как это закрывается.

Что меняется в качестве поиска после доменной адаптации

После дообучения на внутреннем корпусе меняется не «ощущение» поиска, а измеримые величины. Базовое сопоставление ищет по точным формулировкам, поэтому запрос «оформить отпуск за свой счёт» срабатывает, только если в документе есть те же слова. Адаптация сдвигает векторное пространство к языку базы знаний: доля релевантных выдач в первой тройке на эталонном наборе растёт с 40–55% до 85–90%, а средняя позиция первого нужного документа сокращается примерно вдвое.

Сильнее всего эффект виден на синонимах, транслите и внутренних сокращениях. «ГО», «КП», «СФ», аббревиатуры отделов и названия внутренних систем для общей модели почти неотличимы от опечаток, для адаптированной — устойчивые смысловые якоря. Именно на таких запросах качество выдачи проседало заметнее всего, и сотрудники переписывали их вручную по два-три раза.

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

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

Способы адаптации поиска: сравнение подходов

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

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

Как проходит дообучение модели на доменных данных

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

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

2. Разметка доменных пар. Собираем пары «запрос — релевантный документ» и добавляем сложные негативы: близкие по теме, но не подходящие. Разметку ведут носители предметной области, спорные случаи разбирает отдельное правило.

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

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

5. Регресс-тесты поиска. Набор эталонных запросов остаётся в репозитории, поэтому каждая следующая версия модели проходит те же проверки и деградация видна до выката.

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

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

Что передаём на выходе: конфигурации, схемы, регламенты

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

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

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

Кейс: точность поиска по внутренней базе знаний до и после

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

Что снимали до работ

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

Что изменили и что стало

Дообучение embedding-модели шло на парах «запрос — релевантный фрагмент», размеченных носителями домена. К векторному индексу на OpenSearch добавили поиск по ключевым словам, переранжирование и фильтр по правам доступа. Попадания в топ-3 выросли с 47% до 86%, полнота на топ-10 — с 71% до 94%, средняя позиция правильного документа сместилась с шестой на вторую.

Прирост проверили на отложенной выборке: расхождение с обучающими метриками — в пределах 2 процентных пунктов. Откат предусмотрен: веса модели и версия индекса переключаются одной настройкой, без пересборки и простоя.

Что делать, если поиск уже работает на готовом решении

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

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

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

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

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

Технические сомнения: сколько данных нужно и как проверить

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

Не ухудшится ли модель на общих запросах?

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

Как проверить качество без эталонного набора?

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

Как часто дообучать модель?

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

Обсудим задачу: с чего начать и что понадобится от вас

Чтобы вернуться с оценкой и планом работ, нам не нужен доступ к вашему продакшену и не требуется заранее написанное техническое задание. Достаточно показать, как сейчас устроен поиск и какие запросы он отрабатывает плохо — этого хватает, чтобы понять объём адаптации embedding-модели под ваш домен и язык предметной области.

Что стоит подготовить к первому разговору:

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

Дальше работу берём на себя: разбираем корпус, собираем разметку пар «запрос — релевантный ответ», дообучаем модель на домене и сравниваем её с текущей на отложенной выборке. На выходе вы получаете план работ с этапами, точками контроля и метриками качества, по которым принимается решение о старте проекта.