RAG или fine-tuning в 2026: когда что выбирать и сколько это стоит

ПОЧЕМУ ЭТОТ ВЫБОР ВООБЩЕ СТОИТ

Вопрос «RAG или fine-tuning» задают неправильно. Это не альтернативы, а инструменты для разных болей. RAG (retrieval augmented generation) отвечает на вопрос «где модель возьмёт факты». Fine-tuning (дообучение) отвечает на вопрос «как модель себя ведёт». Путаница начинается там, где команда хочет, чтобы LLM «знала наш продукт», и с разбегу лезет дообучать модель на корпоративной вики. Через месяц вики поменялась — и дорогой чекпоинт устарел.

Базовое правило 2026 года: знания меняются — бери retrieval; поведение фиксировано — бери fine-tuning. Дальше разберём это по деньгам, срокам и граничным случаям.

КАК РАБОТАЕТ RAG НА ПАЛЬЦАХ

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

1. Документы режутся на чанки (обычно 300–800 токенов с перекрытием).
2. Каждый чанк прогоняется через модель эмбеддингов и превращается в вектор.
3. Векторы лежат в векторной базе (pgvector, Qdrant, Milvus, LanceDB).
4. На запрос считается эмбеддинг вопроса, ищутся ближайшие чанки, они летят в промпт LLM.

Минимальный рабочий скелет на pgvector — без магии, чистый SQL плюс вызов эмбеддинга:

-- расширение + таблица
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE docs (
  id bigserial PRIMARY KEY,
  chunk text,
  embedding vector(1536)
);

-- HNSW-индекс: быстрый поиск по косинусу
CREATE INDEX ON docs
  USING hnsw (embedding vector_cosine_ops);

-- топ-5 ближайших чанков к вектору запроса
SELECT chunk
FROM docs
ORDER BY embedding <=> $1
LIMIT 5;

Дальше эти пять чанков вставляются в системный промпт: «Отвечай только на основе контекста ниже». Всё. Обновился документ — переэмбеддил один чанк, а не переобучил модель. Именно поэтому RAG стал дефолтом для баз знаний, поддержки и внутренних ассистентов. Свежие релизы фреймворков и векторных движков удобно отслеживать в каталоге REDDYX — экосистема меняется буквально каждую неделю.

ЧТО РЕАЛЬНО ДАЁТ FINE-TUNING

Дообучение меняет веса. В 2026 почти никто не делает full fine-tuning на своих задачах — дорого и незачем. Стандарт де-факто это LoRA/QLoRA: обучается маленький адаптер поверх замороженной базовой модели, вес адаптера — десятки мегабайт вместо десятков гигабайт.

Fine-tuning оправдан, когда:

• Нужен жёсткий формат вывода. Всегда валидный JSON, конкретная структура отчёта, фиксированный тон бренда — модель после дообучения перестаёт «фантазировать» со схемой.
• Узкий доменный язык. Медкодирование, юридические формулировки, специфичный внутренний жаргон, который в промпт не объяснишь коротко.
• Классификация и рутинные задачи. Маленькая дообученная модель на 7–8B часто бьёт большую zero-shot по цене за запрос в разы.
• Сжатие промпта. Если каждый запрос тащит гигантскую инструкцию, дешевле «зашить» её в веса и сократить контекст.

Чего fine-tuning НЕ делает: он не заливает в модель факты надёжно. Модель может выучить стиль ответа про ваш продукт, но конкретные цифры, даты, артикулы она будет путать и галлюцинировать. Факты — территория RAG.

СРАВНЕНИЕ ПО ДЕНЬГАМ И СРОКАМ

Цифры ниже — усреднённые ориентиры по замерам сообщества на 2026 год, порядок величин, а не прайс конкретного вендора. Реальная стоимость гуляет от модели и региона.

Главная скрытая стоимость RAG — не эмбеддинги, а токены на каждый запрос: длинный контекст с пятью чанками платится снова и снова. Главная скрытая стоимость fine-tuning — не сам прогон, а инженерия датасета: чистые размеченные примеры собирать долго и дорого.

ГДЕ RAG ПРОИГРЫВАЕТ (И ЛЮДИ ЭТО ИГНОРИРУЮТ)

RAG не серебряная пуля. Типовые провалы 2026:

• Плохой retrieval — плохой ответ. Если поиск достал не те чанки, LLM уверенно ответит по мусору. Качество RAG на 70% определяется качеством ретривера, а не модели.
• Наивный top-k без реранкинга. Один векторный поиск часто мажет. Продакшн-схема — гибридный поиск (BM25 + вектора) плюс cross-encoder реранкер поверх.
• Чанкинг «в лоб». Разрезали таблицу пополам — потеряли смысл. Структуру документа надо уважать.
• Мультихоп-вопросы. «Сравни политику отпусков в филиале А и Б за прошлый год» требует нескольких проходов поиска, а не одного.

Если retrieval настроен криво, никакой fine-tuning это не спасёт — вы просто зашьёте устаревшие факты в веса.

ГИБРИД: КАК ДЕЛАЮТ ЗРЕЛЫЕ КОМАНДЫ

В 2026 спор «или-или» практически закрыт в пользу «и то, и другое, но по разным осям». Рабочая архитектура:

1. RAG отвечает за факты и свежесть — векторная база плюс гибридный поиск.
2. Лёгкий LoRA отвечает за формат и тон — модель стабильно выдаёт нужную структуру и не срывается в болтовню.
3. Опционально — дообученный ретривер/реранкер под доменные запросы, это часто даёт больше прироста, чем дообучение самой LLM.

Показательный момент: улучшать эмбеддинг-модель под свой домен обычно выгоднее, чем дообучать генеративную LLM. Ретривер маленький, обучается быстро, а качество всего пайплайна тянет вверх.

ЧЕК-ЛИСТ ВЫБОРА ЗА 30 СЕКУНД

Задай себе четыре вопроса:

1. Данные часто меняются? Да → RAG.
2. Проблема в фактах и галлюцинациях? Да → RAG.
3. Нужен жёсткий формат/стиль/жаргон? Да → fine-tuning.
4. Задача узкая и высокочастотная, важна цена за запрос? Да → маленькая дообученная модель.

Практический совет: всегда начинай с RAG. Он дешевле в запуске и быстрее показывает, работает ли идея вообще. К fine-tuning переходи, только когда упёрся в потолок формата или цены инференса — а не «на всякий случай». Инструменты и свежие open-source ретриверы под это удобно мониторить в каталоге REDDYX.

Если тема живая — экосистема RAG и дообучения меняется быстрее, чем успеваешь читать релиз-ноты: новые ретриверы, эмбеддинг-модели, дешёвые способы LoRA появляются почти ежедневно. Чтобы не копать это руками, залетай в Telegram-канал REDDYX AI — новые репозитории каждые 30-60 минут.