Выбор и настройка Embedding-модели для RAG

Почему выбор embedding-модели для RAG определяет качество ответов

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

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

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

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

Как мы подбираем модель под конкретный корпус и как проверяем результат до переезда на неё — разбираем дальше.

Что даёт верно подобранная модель: измеримые эффекты

Первую метрику — долю релевантных фрагментов — снимаем на своём наборе из 100–200 реальных обращений: попадает ли верный фрагмент в первые пять результатов поиска. Модель, подобранная под язык и терминологию конкретной документации, поднимает эту долю примерно с половины запросов до 85–95%. Общие открытые рейтинги вроде MTEB берём как ориентир, но решающим оставляем замер на данных заказчика — они не знают ваших сокращений и внутренней лексики.

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

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

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

Сравнение подходов: готовая embedding, дообучение, гибрид

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

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

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

Этапы внедрения: от аудита корпуса до передачи в эксплуатацию

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

1. Аудит корпуса документов. Считаем объём, форматы, долю сканов и таблиц, дубли, устаревшие редакции. На выходе — карта источников и правила разбиения текста на фрагменты.
2. Разметка проверочных вопросов для оценки поиска. 50–100 реальных вопросов сотрудников с эталонным ответом и ссылкой на документ-источник. Набор дальше не меняется — иначе замеры несопоставимы.
3. Сравнение моделей на своём корпусе. Прогоняем кандидатов на одном наборе и смотрим долю попаданий нужного источника в первую пятёрку, отдельно — качество на коротких и неточных запросах.
4. Настройка индексации. Размер фрагмента и перекрытие, метаданные (версия, подразделение, срок действия), сочетание векторного и точного поиска, расписание переиндексации при обновлении документов.
5. Калибровка порога «нет ответа». Подбираем, при какой близости система отвечает, а при какой честно сообщает, что данных нет. Это убирает уверенные выдумки на пробелах в корпусе.
6. Приёмка качества поиска. Фиксируем целевые метрики и прогоняем контрольный набор. Расхождение — повод вернуться к разбиению или модели, а не переписывать вопросы.
7. Передача в эксплуатацию. Конфигурация, регламент переиндексации, контроль доли отказов, разграничение доступов и обучение команды заказчика.

Артефакты передачи: схемы индексации, регламенты, документация

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

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

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

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

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

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

Что изменили в контуре поиска

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

Через месяц после запуска доля обращений, где сотрудник уходил проверять первоисточник, упала с 40% до 8%. Замеры и конфигурацию отдаём вместе с решением — результат можно повторить на своей базе.

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

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

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

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

Технические сомнения: объём корпуса, языки, обновление данных

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

Документы на нескольких языках — один индекс или несколько?

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

Что делать с таблицами и сканами?

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

Как часто переиндексировать корпус?

Обновляем приращениями по дате изменения, полный пересчёт — только при смене модели или схемы разбиения. Хранилище на pgvector обновляет часть коллекции, не перестраивая остальное.

Как убедиться, что поиск находит нужное?

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

Обсудим задачу: вернёмся с планом и оценкой по вашему корпусу

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

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

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