Первый раз я столкнулся с этим выбором на задаче, которая казалась очевидной: нужно было сделать чат-бота, который отвечает на вопросы по внутренней документации компании. Я сразу полез в fine-tuning — звучит солидно, модель "обучается" на твоих данных, всё как надо. Потратил несколько дней, выгрузил данные, написал скрипт подготовки датасета... и получил модель, которая уверенно врала. Красиво и связно, но врала.
Оказалось, что я выбрал не тот инструмент для задачи. И это не редкость — вокруг этих двух подходов столько маркетингового шума, что разобраться с нуля реально сложно. Поэтому вот мой разбор: что такое RAG и fine-tuning, чем они отличаются на практике, и как я теперь принимаю этот выбор.
Что вообще происходит под капотом
RAG расшифровывается как Retrieval-Augmented Generation. Идея простая: вместо того чтобы "вшивать" знания в модель, ты держишь их снаружи — в базе документов — и подтягиваешь нужные куски прямо в контекст перед генерацией. Модель видит вопрос плюс релевантные фрагменты и отвечает на основе них. Никакого обучения, никакой магии.
Fine-tuning — это другое. Ты берёшь базовую модель и дообучаешь её на своих примерах. Модель не просто запоминает факты — она меняет свои веса, перестраивает то, как генерирует текст. После fine-tuning она по-другому "думает", а не просто смотрит в другую шпаргалку.
Разница принципиальная. RAG меняет то, что модель знает в моменте. Fine-tuning меняет то, как она работает в принципе.
Когда RAG — очевидный выбор
Если у тебя есть документы, которые часто меняются — RAG выигрывает без вопросов. Представь базу знаний с инструкциями, которые обновляются каждую неделю. При fine-tuning тебе придётся переобучать модель при каждом обновлении. При RAG ты просто обновляешь базу документов.
Я делал проект с юридической документацией: законы менялись, редакции обновлялись, добавлялись новые постановления. Гонять переобучение каждые несколько недель ради нескольких изменённых страниц — это не стратегия, это мазохизм. RAG решил задачу элегантно: обновил документы в векторной базе, и всё.
Ещё один сигнал в пользу RAG — когда тебе важно знать источник ответа. RAG по природе своей позволяет отдавать ссылки на конкретные фрагменты, из которых сформирован ответ. Для медицинских, юридических или любых фактических задач это часто критично.
Дело в том что RAG проще запустить быстро. Минимальный рабочий прототип на LangChain или LlamaIndex — это реально несколько часов, если данные уже есть. Fine-tuning с нуля до первого осмысленного результата — это дни.
Когда без fine-tuning не обойтись
Fine-tuning нужен, когда проблема не в том что модель не знает фактов, а в том как она отвечает.
Классический пример: ты хочешь, чтобы модель всегда отвечала в определённом формате — JSON с конкретными полями, SQL-запросы в нужном диалекте, ответы строго в стиле бренда. Сколько угодно документов в контекст не засунешь — это не поможет. Модель должна усвоить паттерн на уровне весов.
Второй случай — специализированный язык или домен. Я пробовал запустить RAG для задачи с медицинскими текстами: модель технически находила нужные куски, но формулировала ответы так, что профильный специалист скривился бы. Fine-tuning на корпусе из похожих текстов реально помогает — модель начинает говорить на нужном языке.
На практике есть ещё один момент, который часто упускают: latency. Каждый RAG-запрос — это поиск по базе плюс обращение к модели. Если у тебя высоконагруженный сервис и каждая миллисекунда важна, модель, которая сразу знает что отвечать, работает быстрее.
Как это выглядит на практике
Для RAG минимальный рабочий стек такой: векторная база (Chroma, Qdrant, Pinecone — смотри по бюджету и инфраструктуре), модель эмбеддингов (text-embedding-3-small от OpenAI или что-то локальное типа nomic-embed), и LLM для генерации.
Процесс примерно такой. Загружаешь документы и режешь на чанки — обычно 300-500 токенов с перекрытием. Строишь эмбеддинги и кладёшь в векторную базу. При запросе строишь эмбеддинг вопроса, ищешь ближайшие чанки, передаёшь их в промпт. LLM генерирует ответ на основе того, что нашёл.
Главные грабли: размер чанков влияет на качество сильнее, чем кажется. Я несколько раз ставил слишком большие чанки и получал нерелевантные куски в контексте. Пришлось переиндексировать с другими параметрами — час работы коту под хвост. Ещё один момент — качество эмбеддингов для русскоязычного текста сильно варьируется между моделями, это стоит проверять отдельно.
С fine-tuning pipeline другой. Если берёшь API — OpenAI, Together AI, Fireworks — готовишь датасет в формате JSONL с парами prompt/completion, загружаешь, запускаешь джоб. Если работаешь с открытыми моделями, смотришь в сторону LoRA через PEFT или Unsloth, они реально снизили порог входа. На потребительской видеокарте сейчас можно дообучить 7B-модель — год назад это звучало бы странно.
Главное в датасете — качество важнее количества. Я проверял это дважды: 200 хорошо размеченных примеров давали лучший результат, чем 2000 наскоро сгенерированных. Модель очень хорошо усваивает мусор.
Можно ли совместить оба подхода
Можно, и иногда это правильное решение. Fine-tuning обучает модель "говорить правильно" — нужный стиль, формат, поведение. RAG снабжает её актуальными знаниями в моменте. Вместе они закрывают разные проблемы.
На практике я делал так: сначала fine-tuning на небольшом датасете для закрепления формата ответов, потом RAG для фактической базы. Результат был ощутимо лучше, чем каждый подход по отдельности.
Но это и дороже, и сложнее в поддержке. Если задача решается одним инструментом — не надо тянуть второй.
Как я теперь принимаю этот выбор
Прежде чем что-то запускать, я задаю себе три вопроса. Данные меняются? Если да — RAG. Проблема в фактах или в поведении модели? Если модель не знает фактов — RAG, если ведёт себя не так, как нужно — fine-tuning. Сколько времени на прототип? RAG быстрее, и если нужно проверить гипотезу — начинаю с него.
Fine-tuning я теперь рассматриваю как второй шаг, а не первый. Сначала запускаю RAG, смотрю где он ломается, и только потом думаю — поможет ли здесь fine-tuning или проблема в другом месте.
Ошибка, которую я сделал в самом начале, была не технической. Я просто не понял, какую проблему решаю. После того как разобрался с этим — инструмент стал выбираться почти автоматически.
