RAG vs Fine-tuning: как научить ИИ работать с вашими данными

Большие языковые модели (LLMs) обучаются на открытых данных. Модель, которая “прочитала” большую часть текстов и данных в интернете, все равно ничего не знает о вашей внутренней документации, спецификациях продуктов, комплаенс-политики или тикете, который ваша служба поддержки закрыла в прошлый вторник. Преодоление этого разрыва является главным инженерным вызовом при внедрении ИИ. Практикующие специалисты решают его преимущественно с помощью двух подходов: генерация с дополненной выборкой информации (Retrieval-Augmented Generation, RAG) и тонкая настройка (fine-tuning).

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

Проблема знаний

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

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

RAG решает проблемы контента и обновляемости. Fine-tuning решает проблему поведения. Путаница между ними приводит к созданию архитектур, которые решают не ту задачу.

Однако прежде чем прибегать к какому-либо из этих методов, стоит спросить себя, нельзя ли решить проблему более простым способом. Удивительно большой объем “знаний” можно передать с помощью хорошо структурированного системного запроса (system prompt) – определение роли, ограничения поведения, несколько готовых примеров, ключевые факты, которые никогда не меняются. Промпт инжиниринг (prompt engineering) часто недооценивают как первый шаг, отчасти из-за его дешевизны и скорости, а отчасти потому, что процесс написания запроса заставляет четко разобраться в том, что именно модель должна знать, а не в том, как она должна себя вести. Момент, когда системный промпт становится слишком громоздким – излишне длинным, нестабильным или перегруженным редкими случаями – обычно является сигналом того, что RAG или fine-tuning действительно нужны. Контекстные окна моделей стали настолько большими, что некоторые команды просто “запихивают” целые базы знаний в промпт. Это работает только до определенного момента. Понимание того, почему это перестает работать (задержка, стоимость, ухудшение внимания при очень длинном контексте), помогает в принятии дальнейших архитектурных решений.

Как работает RAG

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

Базовая инфраструктура довольно проста: конвейер для загрузки данных, модель встраивания (embedding), векторное хранилище, уровень поиска и сама языковая модель. На практике это обычно означает использование LangChain или LlamaIndex для оркестрации процессов. Цепочка RetrievalQA от LangChain объединяет поиск и генерацию текста всего в нескольких строках кода. VectorStoreIndex от LlamaIndex обеспечивает фрагментацию, встраивание и поиск по вашим документам с умными настройками по умолчанию. Выбор векторного хранилища зависит от стадии проекта. Chroma и Qdrant популярны для локальной разработки и ранних прототипов: не требуют учетной записи, легко настраиваются и интегрируются с LangChain и LlamaIndex. Если ваша команда уже использует PostgreSQL, расширение pgvector добавляет векторный поиск без внедрения новой инфраструктуры. Для масштабного производства Pinecone и Weaviate являются наиболее распространенными хостинговыми вариантами. Weaviate особенно полезен, если вам нужен гибридный поиск (сочетание векторного сходства и фильтрации по ключевым словам), что часто важно для реальных корпоративных данных. В крайнем случае (миллиарды векторов и требования к задержке на уровне миллисекунд) стандартным выбором является FAISS – библиотека с открытым кодом от Meta.

Практические преимущества значительны. Добавление новых документов не требует переобучения – достаточно их проиндексировать, и они сразу становятся доступными. Источники можно отображать вместе с ответами, что крайне важно для проверки информации или отслеживания решений до первоисточников. Для быстро меняющихся баз знаний RAG почти всегда является лучшим вариантом по умолчанию.

Впрочем, ограничения тоже существуют. Поиск может давать сбои. Контекстные окна ограничивают количество информации, которую можно использовать. Производительность сильно зависит от стратегии разбиения текста и качества индекса – проблемы, которые выглядят как ошибки модели, часто на самом деле являются ошибками поиска. Это инженерные задачи, но они далеко не тривиальны.

Как работает fine-tuning

Fine-tuning изменяет саму модель. Вы берете предварительно обученную модель: Llama 3, Mistral, DeepSeek или модель типа Claude или GPT-5.4, которая предоставляет API для тонкой настройки, и продолжаете ее обучение на примерах из конкретной отрасли. Веса модели обновляются в соответствии с паттернами в ваших данных: терминологией, стилем рассуждений, форматом ответов, отраслевыми стандартами.

Для моделей с открытыми весами инструментарий существенно улучшился. Библиотека trl от Hugging Face с SFTTrainer позволяет выполнять контролируемую тонкую настройку с минимальным количеством шаблонного кода. Методы с эффективным количеством параметров, такие как LoRA и его квантованный вариант QLoRA – оба реализованы в библиотеке peft – позволяют дообучать большие модели даже на ограниченном оборудовании, обновляя лишь небольшую часть весов. В частности, при использовании QLoRA базовая модель сжимается до 4-битной точности перед обучением, что значительно снижает требования к памяти. Например, модель Llama 3 70B, которая обычно требует кластера из нескольких графических процессоров, может быть адаптирована даже на одном узле A100. Для разработчиков, которые не хотят управлять инфраструктурой обучения, OpenAI и Anthropic предлагают API для тонкой настройки своих облачных моделей: вы предоставляете набор данных, они выполняют вычисления, и вы получаете идентификатор модели, который вызываете как любой другой.

Это идеальный инструмент, когда вам нужен не просто доступ к документам, а усвоенные знания. Модель, обученная на клинических записях, не просто воспроизводит медицинскую терминологию – она рассуждает как специалист, работавший с медицинскими текстами. Аналогично, модель, обученная на юридических документах, иначе структурирует аргументы. Такие поведенческие изменения достигаются не через поиск информации, а через обучение.

Впрочем, затраты существенны. Вычислительные ресурсы для обучения больших моделей остаются дорогостоящими даже при использовании LoRA. Подготовка набора данных – сложная задача: некачественные данные ухудшают результаты, и это трудно диагностировать. Обновление знаний требует повторного обучения или дополнительных циклов fine-tuning. И даже дообученные модели могут “галлюцинировать”, поскольку генерируют ответы на основе весов, а не проверенных источников.

Когда и что лучше использовать

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

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

Существует также аспект стоимости, который легко упустить на этапе проектирования, но трудно игнорировать на этапе производства. RAG-пайплайн обычно предполагает вызов embedding-модели, поиск в векторной базе и генерацию ответа большой моделью – это создает значительную задержку и затраты на каждый запрос, которые быстро растут при масштабировании. Вместо этого хорошо настроенная меньшая модель, например, вариант Mistral или Llama с 7 или 13 млрд параметров, может обслуживать сценарии использования с большим объемом данных значительно дешевле и со значительно меньшей задержкой на выходе (наихудшее время отклика, которое имеет наибольшее значение в пользовательских приложениях). Если ваша задача четко определена, а обучающие данные качественные, отлаженная небольшая модель часто будет превосходить более крупную общую модель с RAG, причем делать это быстрее и дешевле. Компромиссы очевидны: уязвимость к обновлениям знаний, накладные расходы на обслуживание наборов данных и отсутствие привязки к источникам.

На практике зрелые системы часто сочетают оба подхода. Дообученная модель обеспечивает отраслевую экспертизу, а RAG поддерживает актуальность данных. Поисковая система находит релевантный контекст, а модель знает, что с ним делать. Распространенный паттерн – использование абстракций агентов LangChain для маршрутизации запросов: фактические запросы направляются в RAG, а задачи для открытого рассуждения – в точно настроенную модель. Такой гибридный подход сложнее в реализации и поддержке, но для критически важных приложений он обычно оправдан.

Как понять, что это работает

Именно эту часть большинство команд пропускает, и в итоге это создает проблемы. Построить RAG-пайплайн или провести fine-tuning модели – вполне выполнимая задача. Зато проверить, действительно ли система работает эффективно в производственной среде, гораздо сложнее и менее привлекательно.

Для RAG-систем практическим стандартом стала система Retrieval-Augmented Generation Assessment (RAGAS). Это фреймворк, предназначенный для оценки качества RAG-конвейеров без необходимости в полной ручной аннотации. RAGAS оценивает эффективность по четырем критериям:

1. достоверность (действительно ли ответ отражает найденный контент, или модель что-то придумывает?);
2. релевантность ответа (отвечает ли модель на заданный вопрос?);
3. точность контекста (являются ли найденные фрагменты релевантными, и есть ли там шум?);
4. воспроизведение контекста (найдены ли все важные фрагменты, или что-то пропущено).

Запуск RAGAS на репрезентативном наборе запросов перед релизом дает вам базовую оценку и словарь для диагностики сбоев. Без этого вы в основном только догадываетесь, являются ли некачественные результаты следствием сбоев в поиске, генерации или фрагментации.

Для дообученных моделей все большее распространение получает подход “LLM как судья” (LLM-as-judge): использование мощной модели для оценки результатов вашей настроенной модели по определенной шкале. Этот метод не является совершенным и имеет свои собственные предубеждения, но он масштабируется гораздо лучше, чем оценка человеком, и достаточно быстр для использования в конвейерах непрерывной интеграции. Сочетание специализированных тестовых наборов, автоматизированной оценки на основе LLM и периодического пересмотра человеком примерно отражает современное состояние дел для команд, которые серьезно занимаются этим вопросом.

Оба подхода выигрывают от инфраструктуры логирования и отслеживания с самого начала. Такие инструменты, как LangSmith (уровень наблюдаемости LangChain) или Arize, позволяют проверять отдельные запросы, выявлять закономерности в сбоях и обнаруживать регрессии раньше, чем это сделают пользователи. Инструментарий дешево внедрить на начальном этапе, но дорого модернизировать позже.

С чего начать: фреймворки, которые стоит знать

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

Для RAG-пайплайнов стоит начать с LlamaIndex. Он специально создан для подключения LLM к внешним данным, и его абстракции хорошо соответствуют реальной логике RAG – документы, индексы, запросы. Базовый конвейер для работы с вашими собственными файлами можно собрать за один день. LangChain покрывает подобную функциональность и чаще используется в производственной среде, но его универсальность затрудняет обучение: он может делать много вещей, а это означает, что существует много способов выполнить одну и ту же задачу. Как только вы поймете, что на самом деле делает RAG-конвейер, гибкость LangChain станет вашим преимуществом. Начните с LlamaIndex, чтобы освоить концепции, а затем перейдите к LangChain, когда вам понадобится больше контроля или вы будете создавать что-то вроде агента.

Для векторных баз данных хорошим стартом станет Chroma. Эта платформа работает локально, не требует создания учетной записи или API-ключа и интегрируется с LlamaIndex и LangChain с помощью всего нескольких строк кода. Когда вы будете готовы к запуску в производственной среде, Pinecone станет самым простым вариантом с хостингом – это управляемая инфраструктура, качественная документация и SDK, которые практически не мешают в работе. О Weaviate стоит знать, если вам нужен гибридный поиск с реальными корпоративными данными, который, как оказывается, имеет большее значение, чем вы ожидали.

Для fine-tuning лучшим выбором является экосистема Hugging Face. Библиотека transformers содержит большинство моделей с открытыми весами; trl предоставляет класс SFTTrainer, который управляет циклом обучения для контролируемой тонкой настройки; а peft предлагает LoRA и QLoRA – способы тонкой настройки больших моделей без целого ряда графических процессоров. Эти три библиотеки разработаны для совместной работы, а документация Hugging Face действительно качественная. Если управление инфраструктурой обучения кажется слишком сложным на начальном этапе, компании OpenAI и Anthropic предлагают точную настройку через свои API: вы загружаете набор данных – они занимаются остальным. В результате вы получаете идентификатор модели, который можно вызвать, как и любой другой.

Для оценки стоит добавить RAGAS на ранней стадии. Хотя и существует соблазн отложить оценку до тех пор, пока не возникнут проблемы, но внедрить ее позже будет сложно. Для общего качества ответов (особенно fine-tuned моделей) стоит обратить внимание на promptfoo – легкий инструмент с открытым кодом для выполнения наборов тестов на результатах LLM, который достаточно просто интегрировать в конвейер непрерывной интеграции.

Что касается наблюдаемости, LangSmith – это путь наименьшего сопротивления (особенно если вы уже используете LangChain). Он позволяет отслеживать каждый этап: поиск, построение промпта, генерацию – и дает возможность проверять ошибки, а не гадать о них. Arize и Weights & Biases стоит знать при масштабировании, но для большинства команд, только начинающих работу, достаточно LangSmith.

Рекомендуемая последовательность обучения:

• постройте локальный RAG-пайплайн с LlamaIndex и Chroma;
• добавьте RAGAS, чтобы понять слабые места;
• попробуйте настроить небольшую модель с открытыми весами с помощью инструментов Hugging Face, чтобы увидеть, что изменится.

После этого у вас будет достаточно интуиции для принятия архитектурных решений.

Примечание об открытости

RAG обладает неочевидным, но важным преимуществом – возможностью проводить аудит. Когда система извлекает фрагмент из вашей документации и использует его для формирования ответа, вы можете показать этот фрагмент пользователю. Вы можете его зафиксировать, просмотреть и отследить. Дополнительно обученные модели работают иначе – они генерируют ответы на основе внутренних шаблонов, которые невозможно проверить таким же образом. Для регулируемых отраслей или любого контекста, где происхождение ответа имеет значение, эта разница существенна.

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

Команда разработчиков QuData