Главное
Для меняющихся корпоративных фактов начните с RAG и eval retrieval, grounding, цитат и доступа. Fine-tuning проверяйте только после этого — для стабильного формата, стиля или повторяемой узкой операции, а не как способ хранить вчерашние документы.
«Хотим обучить нейросеть на наших документах» — одна из самых частых формулировок на старте. Обычно за ней скрываются две разные задачи: модель должна знать свежие факты компании и отвечать в нужном формате. Для первой чаще нужен RAG. Для второй иногда действительно нужен fine-tuning.
Если перепутать задачи, получится дорогая система, которая всё равно не знает вчерашний приказ и не может показать источник.
Короткий ответ
RAG находит релевантные фрагменты во внешней базе знаний и передаёт их модели в момент ответа. Документы можно обновлять без переобучения модели; ответ можно связать с источником и правами пользователя.
Fine-tuning меняет веса модели на примерах. Он полезен для устойчивого формата, стиля, классификации, терминологии или поведения, которое трудно задать инструкцией. Это плохой способ постоянно «заливать» изменяющиеся факты.
Эти подходы не являются взаимоисключающими. Часто рабочая система использует RAG для знаний, а fine-tuning — только если eval показывает, что базовая модель нестабильно выполняет повторяемый тип задачи.
Когда выбирать RAG
RAG подходит, если:
- документы меняются чаще, чем вы готовы переобучать модель;
- пользователю нужны ссылки и цитаты;
- разные сотрудники имеют разные права;
- важно удалить или отозвать источник;
- ответ должен честно зависеть от утверждённой версии базы знаний;
- нужно понять, какой документ привёл к ошибке.
Главное преимущество RAG — управляемость знаний. Но векторная база сама по себе не обеспечивает качество. Отдельно проверьте разбиение документов, поиск нужных фрагментов, версии источников, фильтры доступа и поведение при отсутствии ответа. Если нужный фрагмент не попал в контекст, настройка стиля ответа не исправит причину ошибки.
Когда fine-tuning действительно полезен
Рассмотрите fine-tuning, если у вас есть стабильная задача и качественные пары «вход — правильный выход»:
- классификация обращений по внутренней таксономии;
- строгое заполнение специфичной структуры;
- устойчивое следование отраслевому стилю;
- выбор известного типа действия из ограниченного набора;
- сокращение длинного prompt при массовой однотипной нагрузке.
Но сначала сравните с хорошим prompt, несколькими примерами и детерминированной постобработкой. Fine-tuning добавляет набор данных, pipeline обучения, версионирование, оценку и повторное обучение. Иногда это оправдано; иногда маскирует слабую постановку задачи.
Что fine-tuning не решит
Он не создаёт надёжную базу свежих фактов. Если завтра изменится тариф, положение или состав услуги, старые веса нельзя «удалить» так же просто, как документ из активного индекса. Модель также не получает автоматически систему прав доступа и проверяемую цитату.
Fine-tuning не лечит плохие источники. Если в датасете противоречия и устаревшие ответы, модель выучит именно их.
Матрица решения
| Требование | RAG | Fine-tuning |
|---|---|---|
| Часто обновлять факты | Сильный выбор | Слабый выбор |
| Показывать источник | Да | Сам по себе — нет |
| Отзывать документ | Управляемо | Сложно |
| Учитывать права пользователя | Через retrieval и ACL | Сам по себе — нет |
| Стабилизировать формат/стиль | Ограниченно | Сильный выбор |
| Обучить узкой повторяемой операции | Иногда | Часто полезен |
| Объяснить причину конкретного ответа | По найденным фрагментам | Ограниченно |
Рабочая последовательность без лишней магии
- Соберите 50–100 реальных вопросов и ожидаемые источники.
- Сделайте baseline на модели без RAG и fine-tuning.
- Добавьте retrieval и отдельно измерьте попадание нужного документа.
- Проверьте grounding, цитаты, отказ и права доступа.
- Посмотрите, какие ошибки остались.
- Только если они относятся к устойчивому поведению, оцените fine-tuning на том же наборе.
Так решение принимается по ошибкам, а не по модному слову.
Пример гибридной архитектуры
В нашем RAG-проекте для утверждённой базы знаний факты разрешено брать только из активной версии индекса. Dense-поиск дополняется лексическим поиском, результаты объединяются, а ответ обязан показать источник или отказаться. Диалоговая память помогает продолжать разговор, но не считается источником фактов.
Если бы этому продукту понадобился устойчивый формат классификации обращений, fine-tuning можно было бы проверить отдельно. Но обучать модель на каждом новом документе приёмной кампании было бы сложнее и менее прозрачно, чем обновить версионированную базу.
Как принять решение за одну встречу
Возьмите три примера, на которых текущий AI ошибается, и спросите:
- Ошибка из-за отсутствующего или устаревшего факта? Нужен retrieval или исправление источника.
- Нужный документ найден, но ответ не опирается на него? Нужны grounding и eval, а не обязательно fine-tuning.
- Факты верны, но формат нестабилен на сотнях однотипных задач? Fine-tuning становится кандидатом.
- Ответ видит документ, который пользователю запрещён? Это архитектура доступа; ни один из двух подходов сам по себе её не исправит.
Хорошая система может содержать оба подхода. Плохая начинается с технологии и потом ищет для неё проблему.
Сравнение
RAG и fine-tuning по инженерным признакам
| Требование | RAG | Fine-tuning |
|---|---|---|
| Обновлять факты | Удобно | Сложно |
| Показывать источник | Да | Сам по себе нет |
| Учитывать роли | Через retrieval и ACL | Сам по себе нет |
| Стабилизировать формат | Ограниченно | Сильнее подходит |
Что проверить
Как принять решение по реальным ошибкам
- Собрать 50–100 вопросов и ожидаемые источники.
- Отдельно измерить попадание нужного документа.
- Проверить grounding, цитаты, отказ и права.
- Классифицировать оставшиеся ошибки по причине.
- Сравнивать fine-tuning с prompt и постобработкой на том же eval.
Как мы подходим к задаче
CENTURY использует RAG для управляемых знаний и рассматривает fine-tuning только как гипотезу, которую нужно доказать на стабильном классе ошибок. Технология выбирается после baseline, а не до него.