NVIDIA mostrou como fazer fine-tuning de um modelo de embedding para um domínio específico em um dia

NVIDIA опубликовала на Hugging Face подробный рецепт, как за несколько часов собрать специализированную embedding-модель для RAG без ручной разметки. Идея в том, чтобы взять базовую модель, сгенерировать синтетические пары вопрос–документ, дообучить её на жёстких негативных примерах и сразу проверить выигрыш в поиске.

Как устроен пайплайн В основе — модель Llama-Nemotron-Embed-1B-v2.

Авторы предлагают не собирать датасет вручную, а генерировать его из собственных документов: внутренних инструкций, контрактов, логов и справочных статей. Для этого LLM читает корпус и создаёт тысячи пар из вопроса и релевантного фрагмента. Вопросы бывают не только фактологическими, но и multi-hop, когда нужно связать несколько кусков текста.

Это важно для реальных RAG-сценариев, где пользователь редко задаёт идеально локальный запрос к одному абзацу. Дальше пайплайн автоматически разбивает данные на train и test, подготавливает BEIR-совместимый бенчмарк и запускает fine-tuning. В статье весь процесс уложен в шесть CLI-команд: от генерации данных до деплоя модели через NVIDIA NIM.

Для proof of concept хватает небольшого корпуса на 50–100 документов, а для полного запуска авторы указывают один GPU уровня A100 или H100 с 80 ГБ памяти. Для корпуса примерно на 500 документов весь цикл занимает около 2–3 часов, хотя формально заявлен как процесс «меньше дня».

Почему важны hard negatives Ключевой шаг — hard negative mining.

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

Пайплайн делает несколько вещей подряд: эмбеддит все запросы и документы корпуса считает сходство и исключает уже размеченные позитивные фрагменты выбирает top-k сложных негативов, по умолчанию пять на запрос разворачивает multi-hop вопросы в отдельные тренировочные примеры Такой подход делает fine-tuning намного ближе к боевому поиску. Модель учится различать не «правильное» и «совсем мимо», а документы, которые отличаются деталями: условиями контракта, версией инструкции, типом ошибки или контекстом использования. Именно на таких почти совпадающих фрагментах обычно ломается корпоративный поиск, а вслед за ним и качество ответов в RAG.

Именно там чаще всего прячутся дорогие ошибки при ответах LLM на базе RAG.

Метрики и прод

Проверка идёт через BEIR по четырём стандартным метрикам: nDCG, Recall, Precision и MAP на разных значениях k. На синтетическом датасете по публичной документации NVIDIA дообученная модель улучшила NDCG@10 с 0.555 до 0.

616, а Recall@10 — с 0.630 до 0.693, то есть примерно на 10%.

Авторы отдельно ссылаются на кейс Atlassian: там тот же рецепт на публичном Jira-датасете поднял Recall@60 с 0.751 до 0.951.

Для корпоративного поиска это уже не косметика, а заметное изменение релевантности. После оценки модель не оставляют в формате PyTorch. Её можно экспортировать в ONNX или TensorRT, затем поднять через NVIDIA NIM как inference-сервис с OpenAI-совместимым endpoint `/v1/embeddings`.

Это снимает часть интеграционных проблем: если у тебя уже есть пайплайн, который умеет работать с embeddings API, переписывать клиент не нужно. В статье также есть отдельная проверка точности после конвертации, чтобы поймать потери качества из-за оптимизации. То есть речь не просто о research-рецепте, а о дорожке от сырых документов до production-сервиса.

Что это значит Порог входа в кастомные embedding-модели заметно снижается.

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