RAG vs Fine-tuning: когда что выбрать

TL;DR. Если вам нужны ответы по меняющимся или приватным документам с опорой на источники, по состоянию на 17.08.2026 разумнее начинать с RAG: OpenAI прямо описывает retrieval как способ расширить знания модели, а для новых проектов рекомендует Responses API с File Search. Если вам нужен не доступ к свежим документам, а устойчивое изменение поведения модели — тон, формат, стиль суммаризации, код-стайл или task-specific ответы, — выбирайте fine-tuning, но только после проверки, доступен ли он вашей организации.

• ✅ Выбирайте RAG, если база знаний часто обновляется, ответы должны быть grounded на документах и вам важна проверяемость через цитаты.
• ✅ Выбирайте fine-tuning, если задача — стабильно изменить поведение модели, а не подключить её к новым документам.
• ⚠️ Не выбирайте по принципу «что современнее»: для новых OpenAI-проектов retrieval-путь сейчас явно поддержан лучше, а fine-tuning находится в режиме wind-down для новых пользователей.
• ❌ Оба подхода в таком виде не закрывают всё, если вам нужен retrieval по .csv/.jsonl, разбор изображений внутри документов или жёстко настраиваемый ingestion/search pipeline.

Условие сравнения	RAG	Fine-tuning
Реализация в статье	Responses API + File Search / vector stores	Fine-tuning API
Официальный статус на 17.08.2026	Для новых проектов OpenAI рекомендует Responses API; Assistants API считается legacy и запланирован к удалению в августе 2026	Платформа fine-tuning находится в wind-down для новых пользователей; текущую доступность нужно проверять у своей организации
«Версия»/поверхность API	Текущий официальный старт — Responses API quickstart с built-in tools, включая file search	Текущая доступность моделей и лимитов проверяется через /v1/fine_tuning/model_limits
Тариф/биллинг, зафиксированный в source pack	Для File Search storage: $0.10 за 1 GB в день, первый 1 GB бесплатно; отдельная стоимость инференса модели в source pack не зафиксирована	Стабильная актуальная публичная цена в captured sources не зафиксирована; перед бюджетированием нужно сверять live docs
Дата проверки источников	2026-08-17	2026-08-17
Одинаковая практическая задача	Внутренний помощник по меняющимся корпоративным документам с обязательной цитируемостью	Та же задача
Воспроизводимость	Сравнение опирается на официальные docs и paper sources, а не на наш живой benchmark	Сравнение опирается на официальные docs и paper sources, а не на наш живой benchmark

Критерий	RAG	Fine-tuning
Актуальные знания	Да: retrieval по внешним и приватным документам — основной сценарий	Не основной сценарий: OpenAI позиционирует fine-tuning как кастомизацию поведения
Поведение, стиль, формат	Можно усиливать промптом и контекстом, но это не основной заявленный смысл механизма	Основной сценарий: code-style improvement, формат суммаризации, personalized content
Проверяемость ответа	file_search генерирует file_citation annotations в message content	В source pack нет эквивалентного встроенного механизма цитирования training corpus в ответе
Контроль retrieval	Есть vector-store search/ranking controls, но hosted File Search имеет фиксированные defaults по chunking/embedding	Неприменимо: это не retrieval-слой
Работа со структурированными файлами	Hosted File Search не поддерживает retrieval по .csv и .jsonl; изображения внутри документов не парсятся	В source pack fine-tuning не описан как решение для document retrieval
Текущий официальный путь для нового проекта	Да: Responses API — рекомендуемый старт	С ограничением: доступность зависит от организации и текущего статуса платформы
Порог входа	Нужны vector store и file search в response workflow	Нужны JSONL-датасет, upload с purpose fine-tune, training job и, желательно, validation file
Прозрачность цены в captured sources	Частично есть: storage price зафиксирована	Нет: в source pack нет одной стабильной актуальной таблицы цены

Что реально меняет выбор между RAG и fine-tuning

Это не спор двух «моделей», а выбор между двумя разными слоями системы. Даже исследовательская литература ставит вопрос именно так: paper Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs напрямую сравнивает unsupervised fine-tuning и RAG как два способа knowledge injection.

На уровне текущих OpenAI-источников разведение ролей ещё жёстче. OpenAI прямо пишет, что retrieval расширяет знания модели, а fine-tuning нужен для кастомизации поведения; среди типовых use cases fine-tuning перечислены улучшение code style, формат суммаризации и personalized content.

Если вам нужен базовый терминологический контекст, удобно освежить два коротких определения: RAG (Retrieval-Augmented Generation) и Fine-tuning (дообучение). Для практического выбора этого уже достаточно: RAG отвечает за доступ к знаниям, fine-tuning — за устойчивое поведение.

Редакционное ограничение: в source pack нет нашего живого head-to-head прогона с одинаковыми model ids, latency и cost-per-request. Поэтому вывод ниже — это практический выбор по механике, ограничениям API и официальному позиционированию на 17.08.2026, а не числовой бенчмарк «кто лучше отвечает».

Цена и лимиты

С ценой у этого сравнения есть важная асимметрия. Для RAG через OpenAI-hosted File Search в captured sources зафиксирована конкретная стоимость хранения vector store: $0.10 за 1 GB в день, при этом первый 1 GB бесплатен.

Для fine-tuning такой же устойчивой и полной ценовой таблицы в source pack нет. Поэтому честный вывод здесь такой: по состоянию доступных источников нельзя доказать, что fine-tuning дешевле или дороже RAG в целом; можно только сказать, что для RAG зафиксирована storage-составляющая, а для fine-tuning перед расчётом бюджета нужно сверять live pricing и фактическую доступность.

Отдельно учитывайте организационный риск. OpenAI указывает, что платформа fine-tuning находится в wind-down для новых пользователей, а текущую доступность моделей нужно проверять через /v1/fine_tuning/model_limits. Это значит, что даже корректная экономическая модель может оказаться теоретической, если вашей организации доступ уже не открыт.

Качество на задаче с меняющимися документами

Если критерий звучит как «модель должна отвечать по свежим внутренним документам и не выдумывать источник», RAG остаётся базовым выбором. Это совпадает и с текущим позиционированием OpenAI, и с исходной идеей RAG из paper 2020 года про knowledge-intensive NLP tasks.

Практически это означает следующее: знания лежат не только в параметрах модели, а во внешнем retrieval-слое. Вы обновляете документы в vector store, а не пытаетесь «впекать» новые факты в fine-tuned поведение. Для сценариев внутренней базы знаний это обычно ближе к реальной эксплуатации.

Для сравнения: OpenAI не описывает fine-tuning как основной путь для доступа к меняющемуся корпусу документов. Наоборот, в официальных материалах fine-tuning вынесен в область поведения, стиля и формата. Поэтому вопрос «RAG vs fine-tuning» для документации обычно решается в пользу RAG ещё до тонких тестов качества.

Если вы колеблетесь между большим контекстом и retrieval, а не между retrieval и tuning, полезен соседний разбор Длинный контекст vs RAG: что выбрать. Это другой архитектурный выбор, и его не стоит смешивать с fine-tuning.

Поведение, стиль и формат: где нужен fine-tuning

Fine-tuning имеет смысл там, где вы хотите не «подложить документ», а поменять способ ответа модели. OpenAI прямо перечисляет характерные случаи: улучшение code style, заданный формат суммаризации и personalized content.

Это важная граница. Если ваша боль — модель пишет «почти так, как надо», но постоянно срывается с нужного шаблона, tone of voice или структуры ответа, retrieval сам по себе проблему не решает. Он приносит факты, но не гарантирует устойчивую манеру работы.

В operational terms fine-tuning требует подготовить JSONL training file, загрузить его с purpose fine-tune и запустить training job. Если добавить validation file, вы получите метрики в results file. То есть это уже не просто добавление источников, а отдельный обучающий pipeline.

Если вы ещё сомневаетесь, нужен ли именно tuning, сначала сравните его с более дешёвой адаптацией через примеры: Few-shot vs Fine-tuning: что выбрать для адаптации LLM. А если путь tuning уже выбран, следующий вопрос обычно такой: LoRA vs Full fine-tuning: что выбрать.

Контроль retrieval, проверяемость и ограничения File Search

Сильная сторона RAG в текущем OpenAI-стеке — проверяемость использования источников. Reference по Messages API указывает, что file_search генерирует file_citation annotations в message content. Для практики это критично: вы можете проверять не только сам ответ, но и факт того, что retrieval вообще был задействован.

Но hosted File Search — это не полностью настраиваемый retrieval-конвейер. В FAQ зафиксированы текущие defaults: chunk size 800 tokens, overlap 400, embedding model text-embedding-3-large в 256 dimensions и до 20 chunks в контексте. Там же сказано, что вы не можете изменять chunking, embedding и retrieval settings в этом hosted режиме.

При этом reference по vector stores показывает, что на search-слое всё же есть элементы управления, включая max_num_results, ranker, score_threshold и query rewrite. Практический вывод такой: часть поискового поведения вы можете направлять, но не стоит путать это с полным контролем над ingestion и индексированием.

Есть и жёсткие ограничения. Hosted File Search не поддерживает retrieval по структурированным форматам вроде .csv и .jsonl, а также не парсит изображения внутри документов. Если ваш corpus именно такой, спор «RAG vs fine-tuning» в этом виде уже неполон: сначала нужен другой retrieval-слой или иной data pipeline.

Текущий статус платформ и порог входа

Для новых проектов OpenAI сейчас рекомендует Responses API вместо Assistants API. Это важно не как косметическое переименование, а как сигнал о том, на какой surface лучше строить систему сегодня.

Assistants API v2 в FAQ помечен как путь, который будет удалён в августе 2026. Если у вас уже есть legacy-приложение, это отдельный вопрос миграции; если проекта ещё нет, закладывать новую архитектуру на Assistants API смысла мало.

С fine-tuning ситуация обратная: не технологически устаревший слой, а продуктовый доступ с ограничением. OpenAI пишет, что платформа wind-down для новых пользователей уже идёт; существующие пользователи могут ещё некоторое время создавать training jobs, а fine-tuned models останутся доступны для inference до депрекации их base models.

Практический вердикт по порогу входа поэтому такой: для нового OpenAI-проекта RAG через Responses API сейчас имеет более понятный и формально поддержанный старт. Fine-tuning остаётся валидным только там, где он реально нужен по задаче и где у вашей организации ещё есть доступ.

Приватность и работа с данными

По captured data-controls источникам /v1/vector_stores и /v1/responses File Search доступны во всех регионах. Но в тех же документах есть существенная оговорка: если выбранный регион не поддерживает regional processing, данные могут обрабатываться или храниться вне выбранного региона.

Для регулируемых сценариев этого достаточно, чтобы не обещать «полную локализацию данных» без дополнительной проверки. Если для вас критичны residency, retention и регион обработки, их нужно подтверждать в live OpenAI docs под конкретный проект и организацию.

Для fine-tuning в source pack нет сопоставимо подробной текущей региональной таблицы. Поэтому здесь ограничение ещё жёстче: помимо организационной доступности самой функции, отдельно проверяйте data controls и policy-условия в живой документации.

Практический тест: корпоративный помощник по меняющимся документам

Ниже не «скриншотный» benchmark, а source-led workflow test. В исходниках нет живых прогонов одной и той же модели на одинаковом промпте, поэтому сравниваем воспроизводимый путь реализации и проверяемые свойства ответа.

1. Задача. Нужен внутренний ассистент по HR/Legal-документам компании. Документы регулярно меняются. Ответ должен опираться только на загруженные материалы и по возможности показывать, откуда взят факт.
2. Одинаковый вход.

   Ответьте на вопрос сотрудника по внутренней политике.
   Используйте только предоставленные документы.
   Если источник не найден, так и скажите.
   Если retrieval использован, верните ответ так, чтобы можно было проверить цитаты.

3. RAG: что даёт стек по docs. Responses API — текущая официальная стартовая точка для built-in tools, а vector stores и file_search дают retrieval по документам. Важный проверяемый сигнал — file_citation annotations в message content. Для этой задачи это прямое попадание в требования: документы можно обновлять отдельно от модели, а факт использования источников можно верифицировать.
4. Fine-tuning: что даёт стек по docs. Fine-tuning API требует JSONL training file и training job. Он подходит, если вам нужно закрепить стиль ответа, формат или типовую манеру интерпретации запросов. Но в source pack нет признаков, что этот путь сам по себе решает задачу доступа к свежим документам и встроенной цитируемости по ним.
5. Вывод. Для именно этой задачи выбирайте RAG. Fine-tuning здесь можно рассматривать только как дополнительный слой поведения, но не как замену retrieval.

Кому подойдёт RAG

• Командам, которые отвечают по приватным документам, меняющимся политикам, базам знаний, SOP и внутренним инструкциям.
• Тем, кому нужна проверяемость: наличие file_citation annotations важнее, чем «красивый стиль ответа».
• Проектам, стартующим на текущем OpenAI-стеке с нуля: по состоянию на 17.08.2026 именно Responses API — официальный путь для новых интеграций с retrieval.
• Сценариям, где содержимое обновляется чаще, чем вы готовы пересобирать обучающий датасет.

Кому подойдёт fine-tuning

• Командам, которым нужен стабильный формат вывода: например, одинаковый шаблон суммаризации или предсказуемый style guide для кода и текста.
• Сценариям, где знание относительно стабильно, а ключевая проблема — не поиск фактов, а манера ответа модели.
• Проектам, где уже есть организационный доступ к fine-tuning и понятный pipeline с JSONL-датасетами, validation и оценкой результата.
• Задачам, где RAG уже приносит нужные факты, но продукту не хватает устойчивого поведения поверх этих фактов.

Когда оба не подходят

• Когда основная информация лежит в .csv, .jsonl или в изображениях внутри документов: hosted File Search из source pack это не закрывает.
• Когда вам нужен полный контроль над chunking, embeddings и ingestion-пайплайном, а не только hosted defaults и часть search/ranking controls.
• Когда data residency нельзя оставлять на уровне «проверьте live docs»: в captured sources есть региональные оговорки, и этого может быть недостаточно для комплаенса.
• Когда у вашей организации уже нет доступа к fine-tuning, а задача требует именно устойчивого изменения поведения, а не retrieval.

Итог

Если упростить до одного правила, оно звучит так: для знаний — RAG, для поведения — fine-tuning. На текущем OpenAI-стеке это не просто удобная эвристика, а официально поддержанное разделение ролей.

Для новых проектов приоритет у RAG через Responses API и File Search, особенно если документы меняются и вам важна цитируемость. Fine-tuning стоит выбирать только под стабильные изменения формата и поведения — и только после проверки, что функция вообще доступна вашей организации. Абсолютного победителя здесь нет: это два разных инструмента для двух разных слоёв задачи.

Вопросы и ответы

Что выбрать для базы знаний, которая обновляется каждую неделю?

RAG. По captured official sources retrieval — это как раз механизм расширения знаний модели внешними документами, а для новых проектов OpenAI рекомендует Responses API с File Search.

Что выбрать, если нужен стабильный JSON-формат, тон ответа или code style?

Fine-tuning ближе к задаче. OpenAI прямо перечисляет format/style-подобные сценарии как типовые use cases fine-tuning.

Что дешевле — RAG или fine-tuning?

По source pack это нельзя честно доказать. Для File Search зафиксирована только storage-цена — $0.10 за 1 GB в день, первый 1 GB бесплатно; для fine-tuning стабильная актуальная публичная цена в captured sources не зафиксирована.

Можно ли строить новый проект на Assistants API?

Для новых проектов OpenAI рекомендует Responses API вместо Assistants API. Assistants API, согласно FAQ, запланирован к удалению в августе 2026.

Что делать, если документы в CSV или JSONL?

Hosted File Search в captured sources не поддерживает retrieval по .csv и .jsonl. В таком сценарии нужен другой retrieval/data pipeline; ни vanilla hosted RAG в этом виде, ни сам fine-tuning проблему не закрывают.

Источники

• Introducing improvements to the fine-tuning API and expanding our custom models program
• Assistants API v2 FAQ | OpenAI Help Center
• How can I get started with fine-tuning? | OpenAI Help Center
• Vector stores | OpenAI API Reference
• Developer quickstart – OpenAI API
• Messages | OpenAI API Reference
• Fine-tuning | OpenAI API Reference
• Data controls in the OpenAI platform – OpenAI API
• Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks