RAG или fine-tuning: сначала определите, чего не хватает AI-системе — знаний или поведения

Бизнес часто начинает не с проблемы, а с названия технологии.

«Нам нужен RAG».«Давайте дообучим модель».«Нужна собственная база знаний».«Fine-tuning сделает ответы стабильными».

Но RAG и fine-tuning меняют разные части AI-системы. Один подход помогает модели получать внешние знания во время работы. Другой меняет поведение самой модели на основе обучающих примеров.

Поэтому вопрос «что лучше — RAG или fine-tuning?» поставлен неправильно.

Сначала нужно понять, какой именно сбой наблюдается:

Пока этот диагноз не поставлен и не подтверждён тестами, покупка сложной архитектуры остаётся ставкой на предположение.

RAG — Retrieval-Augmented Generation, или генерация с дополненным поиском.

В такой системе перед формированием ответа появляется дополнительный этап: retrieval. Система ищет релевантную информацию во внешнем источнике или индексе, собирает найденный контекст и передаёт его модели вместе с запросом пользователя.

Упрощённо процесс выглядит так:

вопрос пользователя → поиск релевантных фрагментов → передача найденного контекста модели → формирование ответа

Знания при этом не обязательно переносятся в веса базовой модели. Они могут оставаться во внешнем корпусе: документах, базе знаний, индексе или другом подключённом источнике.

Это важно, когда информация:

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

Но RAG не означает, что модель автоматически получает свежие и правильные знания.

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

Само наличие векторной базы ничего из этого не гарантирует.

Supervised fine-tuning обучает существующую модель на примерах желаемых входов и выходов.

Модели показывают, как она должна выполнять конкретную задачу:

В отличие от RAG, fine-tuning меняет параметры модели. Он не добавляет этап поиска по внешней базе во время каждого запроса.

Упрощённая логика выглядит так:

подготовленные примеры → обучение модели → изменение её поведения → проверка на отдельном наборе задач

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

Он также не является правильным способом «загрузить документы в модель», чтобы потом точно извлекать из неё факты. Если информация регулярно меняется или должна сопровождаться проверяемыми источниками, проблему нельзя автоматически считать задачей fine-tuning.

Разделение на knowledge problem, behavior problem и combined problem — моя архитектурная эвристика. Это не универсальный отраслевой закон, но для бизнеса она помогает не смешивать разные типы сбоев.

Knowledge problem возникает, когда модель не получает:

Признак такой проблемы: даже хорошо сформулированный запрос не может дать правильный ответ, потому что необходимых фактов просто нет во входном контексте модели.

В этом случае рассматривается RAG.

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

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

Behavior problem возникает, когда модель получает необходимую информацию, но:

Однако из этого ещё не следует, что системе нужен fine-tuning.

Сначала я бы проверила более простые способы управления поведением:

Few-shot examples позволяют показать модели нужный pattern прямо внутри prompt без отдельного обучения.

Structured Outputs в OpenAI могут обеспечить соответствие ответа заданной JSON Schema. Это снижает количество форматных дефектов, но не доказывает, что содержание ответа правильно, факты верны или бизнес-правила соблюдены.

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

Fine-tuning рассматривается, когда после настройки этих controls измеряемое поведение всё равно не достигает установленной цели и это подтверждено eval-результатами.

Не потому, что fine-tuning звучит серьёзнее. А потому, что уже доказана недостаточность более простого решения.

Иногда система должна одновременно:

Тогда RAG и fine-tuning могут применяться совместно.

Retrieval отвечает за получение текущих знаний. Fine-tuning может оптимизировать поведение модели на конкретной задаче.

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

Сначала нужно отдельно доказать:

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

Prompt часто воспринимают как временную настройку перед «настоящей архитектурой». Это ошибка.

Хорошие instructions, примеры и ограничения могут решить значительную часть поведенческих задач без изменения модели.

Для начала можно проверить:

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

Именно такую последовательность — eval baseline, prompting и только затем возможный fine-tuning — описывает официальный OpenAI optimization workflow.

Это vendor guidance OpenAI, а не универсальный закон для каждого поставщика и каждой задачи.

RAG стоит рассматривать, когда системе нужны внешние, внутренние, большие или изменяющиеся знания.

Сильными признаками являются:

Но перед выбором RAG нужно ответить не только на вопрос «где будет векторная база».

Нужно определить:

RAG может улучшить grounding, если retrieval действительно находит нужную информацию. Но слабый поиск или неправильная генерация всё равно могут привести к неподтверждённому ответу.

Fine-tuning можно рассматривать, когда у проекта есть измеримая поведенческая задача и representative examples желаемого результата.

Например:

Но до начала обучения нужны:

Fine-tuning может улучшить целевую задачу и одновременно ухудшить поведение за её пределами. Среди рисков остаются overfitting, drift и необходимость повторной проверки после изменений данных, модели или требований.

Точный объём training data, продолжительность обучения, стоимость и ожидаемый прирост качества нельзя определить без конкретного provider, model, task и eval baseline.

Fine-tuning — не абстрактная возможность, которую можно просто заложить в архитектуру и считать доступной.

Его доступность зависит от конкретного:

Условия и список поддерживаемых моделей у провайдеров могут меняться.

Поэтому перед проектированием нельзя исходить из формулы:

«Если понадобится fine-tuning, потом просто включим его».

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

У OpenAI доступность fine-tuning менялась в 2026 году, поэтому перед проектированием нельзя считать этот метод автоматически доступным. Нужно проверять актуальную документацию, поддерживаемые модели и ограничения конкретной организации или аккаунта.

То же относится и к другим провайдерам: возможность fine-tuning может зависеть от модели, региона и типа кастомизации.

Это важный архитектурный принцип:

Provider capability нельзя считать частью архитектуры, пока она не подтверждена для реального проекта.

Основной риск RAG — считать его одним готовым компонентом.

На практике качество зависит от всей retrieval pipeline:

Система должна корректно извлекать содержание из исходных файлов. Если важные таблицы, заголовки или связи потеряны при обработке, поиск будет работать по повреждённому представлению документа.

Слишком маленькие фрагменты могут потерять смысл. Слишком большие — добавить лишний контекст и ухудшить поиск.

Выбор способа индексации и представления документов влияет на то, какие фрагменты будут считаться релевантными.

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

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

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

Система не должна извлекать документ только потому, что он технически присутствует в corpus. Доступ должен учитывать права конкретного пользователя и назначение запроса.

Retrieval layer требует собственной проверки. Недостаточно оценивать только красивый финальный ответ. Нужно понимать, был ли найден правильный источник и на чём построен результат.

Поэтому RAG — это не «подключить векторную базу». Это отдельная система поиска, обновления, контроля доступа и оценки качества.

Fine-tuning не компенсирует слабую постановку задачи.

Если обучающие примеры:

модель может закрепить неправильное поведение.

Даже успешный результат на training examples ещё не доказывает качество на новых входах.

После обучения остаются вопросы:

Fine-tuning не отменяет необходимость prompt, контроля результата и человеческой проверки в критических процессах.

Нельзя универсально утверждать, что RAG дешевле, а fine-tuning дороже. Эти подходы переносят расходы в разные части жизненного цикла системы.

RAG может потребовать:

К этому добавляется latency: перед генерацией система должна выполнить поиск и собрать контекст.

Fine-tuning может потребовать:

В некоторых provider contexts fine-tuning может уменьшить объём инструкций или примеров, которые приходится передавать при каждом запросе. Но делать универсальный вывод о снижении стоимости или latency без конкретных условий нельзя.

Hybrid-система объединяет два контура:

Следовательно, она может объединить и расходы обоих подходов.

Поэтому экономику нужно считать не по названию архитектуры, а по полному lifecycle:

создание → проверка → эксплуатация → обновление → мониторинг → исправление ошибок → откат

Без выбранного provider, модели, объёма traffic, размера corpus и quality target точные расходы остаются UNKNOWN.

Архитектурный выбор нельзя отделять от данных.

До загрузки документов в retrieval-систему нужно определить:

Traceability не возникает автоматически вместе с RAG. Она появляется только тогда, когда система сохраняет происхождение найденных фрагментов и выводит его в проверяемой форме.

Для fine-tuning отдельно нужно подтвердить право использовать examples для обучения. Наличие технического доступа к переписке, документу или базе не означает наличия разрешения включать эти данные в training dataset.

Для consumer ChatGPT и Plus использование данных зависит от account-level Data Controls. По официальной документации OpenAI пользователь может выключить настройку Improve the model for everyone, после чего новые conversations не используются для обучения моделей.

Но эта настройка не является разрешением загружать клиентские или закрытые данные.

Сначала нужны право использования, правила доступа и подходящий контур обработки. Только потом — выбор технологии.

Я бы не начинала с покупки vector database, подготовки dataset или выбора модели для fine-tuning.

Первый шаг — зафиксировать один измеряемый failure.

Например:

Затем я бы собрала небольшой набор representative examples и создала baseline eval.

Для knowledge problem нужно проверить:

Для behavior problem нужно сравнить:

Только после этого можно принимать решение:

не хватает знаний → проверяем RAG не хватает поведения → проверяем controls → при доказанной недостаточности рассматриваем fine-tuning не хватает обоих компонентов → отдельно доказываем обе потребности → только затем рассматриваем hybrid

Без baseline невозможно понять, улучшила ли новая архитектура результат или просто сделала систему сложнее.

Перед тем как оплачивать RAG, fine-tuning или hybrid, предпринимателю или заказчику стоит получить ответы на двенадцать вопросов.

Системе не хватает знаний, поведения или обоих компонентов?

Сохранены ли реальные примеры ошибок и измерен ли текущий уровень качества?

Кто отвечает за обновление источников, удаление устаревших данных и повторную индексацию?

Должен ли пользователь видеть, из какого документа взята информация, и можно ли восстановить этот источник?

Достаточны ли instructions, few-shot, structured output и validators?

Отражают ли примеры реальные задачи и есть ли право использовать их для обучения?

Доступен ли fine-tuning или нужный retrieval stack для конкретной модели, региона и аккаунта?

Какие метрики показывают retrieval relevance или stability поведения?

Что относится к разовой подготовке, а что — к постоянной эксплуатации и сопровождению?

Можно ли вернуться к предыдущей версии corpus, prompt, index, dataset или модели?

Какие данные разрешено использовать, где они находятся и кто может получить к ним доступ?

Какой результат должен показать, что RAG, fine-tuning или hybrid действительно лучше более простого решения?

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

Я считаю, что главный выбор происходит не между RAG и fine-tuning.

Главный выбор — между диагностикой и догадкой.

RAG решает проблему доступа к внешним знаниям. Fine-tuning может решать проблему специализированного поведения. Prompt, examples, Structured Outputs и validators могут оказаться достаточными для части задач. Hybrid может быть оправдан, когда отдельно доказаны оба типа проблемы.

Но ни один из этих подходов не должен покупаться только потому, что его название появилось в техническом предложении.

Я бы начинала с одного измеряемого сбоя, реальных примеров и baseline eval. Затем проверяла бы самое простое решение, способное устранить этот сбой. И только после этого добавляла бы новый архитектурный слой.

Сильная AI-система — не та, в которой использовано больше технологий.

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

Provider-specific сведения перепроверены перед публикацией; для изменяемых возможностей нужно ориентироваться на актуальную документацию конкретного поставщика.