Файн-тюнинг LLM для RAG на практике: реальные кейсы GPT OSS 20B от разработчиков

Зачем вообще это нужно? RAG против файн-тюнинга

Вы построили RAG-систему. Векторизовали документы, настроили ретривер, подобрали промпты. Модель отвечает, но... как-то криво. Не в том стиле, путает термины, игнорирует форматирование. Знакомо?

Тут два пути: либо бесконечно править промпты и чанкинг, либо взять модель и научить ее работать именно с вашими данными. Первый путь - это как пытаться объяснить иностранцу нюансы русского мата через Google Translate. Второй - просто выучить с ним русский.

Кейс 1: Юридические документы - где ломаются все промпты

Команда из моего окружения работала с договорами аренды. Стандартная RAG на базе GPT OSS 20B выдавала ответы типа: "Сторона А должна платить стороне Б". Технически верно, но юридически бесполезно.

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

1 Что сделали не так сначала

Попытались решить промптами. Добавили в системный промпт: "Всегда используй термины 'Арендодатель' и 'Арендатор'". Результат? Модель начала вставлять эти слова куда попало, даже когда в чанке их не было. Она галлюцинировала.

2 Как решили через файн-тюнинг

Собрали датасет из 500 пар "вопрос-ответ" на основе реальных договоров. Каждый ответ:

• Использовал точную терминологию из документа
• Содержал цитаты с номерами пунктов
• Был структурирован: сначала суть, потом детали

Обучение заняло 8 часов на одной RTX 4090. Не миллионы, как многие думают.

Кейс 2: Форматирование ответов - когда красота важна

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

Пользователи жаловались: "Читать невозможно". Особенно когда речь шла о дозировках препаратов или последовательностях процедур.

3 Секрет успеха: учить на плохих примерах

Вместо того чтобы показывать только идеальные ответы, добавили в датасет пары "плохой ответ - хороший ответ".

Пример плохого ответа: "Пациент принимает лекарство утром и вечером по 10 мг."

Пример хорошего ответа:

**Режим приема:**
- Утро: 10 мг
- Вечер: 10 мг

**Источник:** исследование Джонсона et al., 2023, раздел 4.2

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

Технические детали, о которых молчат в туториалах

Все говорят про LoRA, QLoRA, gradient checkpointing. Но реальные проблемы другие.

Проблема 1: Переобучение на стиль

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

Как избежать:

• Использовать больше разнообразных примеров (минимум 300-500)
• Добавлять вариации одних и тех же вопросов
• Останавливать обучение раньше (ранняя остановка - ваш друг)

Проблема 2: Потеря общих знаний

Модель на 20B параметров - не гигант. Интенсивный файн-тюнинг может "затереть" часть базовых знаний. Особенно если датасет узкоспециализированный.

Решение: смешанное обучение. 80% датасета - специализированные примеры, 20% - общие вопросы и ответы (брали из Alpaca датасета). Это сохраняет баланс.

Сравнение с другими подходами

Почему именно GPT OSS 20B, а не, скажем, IQuest-Coder-V1 40B или ожидание GPT OSS 120B?

20B - это золотая середина для большинства бизнес-задач. Особенно если учесть предостережения из статьи "Конец эйфории: Почему LLM — не серебряная пуля".

Интеграция с RAG: как не сломать то, что работает

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

1. Промпт-инжиниринг упрощается. Убираем микроменеджмент стиля, оставляем только суть запроса.
2. Температуру снижаем. Обученная модель более предсказуема. temperature=0.3 вместо 0.7.
3. Проверяем ретривер. Если модель теперь лучше понимает термины, возможно, нужно переиндексировать эмбеддинги.

И да, эта обученная модель будет плохо работать с другими типами документов. Это не баг, а фича. Она заточена под вашу задачу.

Ошибки, которые совершают все (и как их избежать)

Когда файн-тюнинг 20B не сработает

Есть задачи, где даже обученная модель не поможет:

• Сложная логическая цепочка. Если для ответа нужно сделать 5 логических шагов, модель на 20B часто сбивается. Тут нужны либо более крупные модели, либо фреймворки для reasoning.
• Мультимодальность. GPT OSS 20B - текстовая. Для работы с таблицами, схемами, изображениями нужно другое.
• Динамический контекст. Если правила меняются ежедневно, файн-тюнинг бессмысленен. Только RAG с актуальной базой.

Что в итоге? Цифры и впечатления

Из трех проектов, где применяли этот подход:

• Юридические договоры: качество ответов выросло на 32% (оценка экспертов)
• Медицинские исследования: время на анализ документа сократилось в 2 раза
• Техническая документация: количество уточняющих вопросов от пользователей упало на 70%

Обучение одной модели обходилось в 8-12 часов на RTX 4090 и ~50$ на облачные GPU, если своих нет. Не миллионы, как многие боятся.

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

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

А пока - если ваша RAG-система выдает посредственные ответы, не спешите переходить на модели за 100B параметров. Возможно, вашей 20B-модели просто нужно дать правильные примеры для подражания.