CPT против RAG на Qwen 3.5 4B: сравнение точности, производительности и затрат

Сравнение continued pretraining (CPT) модели Qwen 3.5 4B с RAG на той же базовой модели проверяет простую гипотезу: даёт ли встраивание знаний в веса выигрыш в точности и скорости против рассуждения по внешнему контексту. Короткий ответ придётся начать с факта, который многих разочарует: в исходном сообщении об этом эксперименте нет ни методологии, ни чисел. Есть цель и ссылка на разбор результатов, но сами результаты не раскрыты.

Поэтому конкретных цифр по Qwen 3.5 4B здесь не будет. Придумывать их бессмысленно, а переносить замеры с других моделей и других корпусов на этот кейс - значит врать читателю. Что можно сделать полезного: разобрать, какие метрики в таком сравнении вообще имеют смысл, где CPT выигрывает по определению, где RAG дешевле и надёжнее, и как поставить собственный тест за несколько часов.

Главный вывод, который стоит держать в голове: CPT и RAG отвечают на разные вопросы. Первый меняет то, что модель знает. Второй меняет то, на что она смотрит в момент ответа. На Qwen 3.5 4B это различие проявляется особенно резко, потому что модель маленькая, и любая лишняя нагрузка на контекст бьёт по качеству заметнее, чем у крупных собратьев.

Что такое CPT и RAG: краткое напоминание

CPT (continued pretraining, продолжение предобучения) - это доучивание модели на целевом корпусе тем же способом, каким её учили изначально: предсказанием следующего токена. Веса меняются, знания домена оседают в матрицах внимания и MLP-слоях. От SFT (supervised fine-tuning) CPT отличается задачей: SFT показывает модели формат ответа на парах «инструкция - ответ», а CPT подтягивает распределение языка к конкретной предметной области. На практике их обычно совмещают: сначала domain-adaptive pretraining, потом инструкционное дообучение.

RAG (retrieval-augmented generation) устроен иначе. Модель не трогают вообще. Документы режут на чанки, считают эмбеддинги, складывают в векторный индекс. На запросе система ищет top-k релевантных фрагментов, подставляет их в промпт и просит модель ответить, опираясь на этот контекст. Знания живут в индексе, а не в весах.

Разница в архитектуре определяет всё остальное. Обновить знания в RAG - переиндексировать документы, это минуты или часы. Обновить знания в CPT - переобучить модель. Зато CPT не платит за поиск на каждом запросе и не зависит от того, нашёл ли retriever нужный чанк.

Эксперимент: CPT vs RAG на Qwen 3.5 4B

Дизайн такого эксперимента выглядит логично: взять Qwen 3.5 4B, часть доменного корпуса отдать ей через continued pretraining, ту же часть положить в индекс для RAG на базовой версии модели, после чего прогнать оба варианта на одном наборе вопросов. Такой подход отделяет эффект знаний от эффекта архитектуры: модель одна, параметров 4 миллиарда, меняется только способ доставки информации.

Что известно точно: конкретные цифры и методология в исходном сообщении не раскрыты. Ни по точности, ни по latency, ни по потреблению VRAM данных нет. Заявлена только цель - измерить выгоду от встраивания знаний в веса по сравнению с рассуждением по внешнему контексту. Любая таблица с процентами в этом месте была бы выдумкой, поэтому её не будет.

Методология и метрики

Чтобы такое сравнение что-то доказывало, нужно зафиксировать шесть вещей.

• Базовая модель и её версия. Qwen 3.5 4B в разных квантизациях ведёт себя по-разному. Сравнивать CPT на fp16 с RAG на Q4 - значит измерять не эффект подхода, а эффект точности весов.
• Корпус. Один и тот же набор документов должен уйти и в обучение, и в индекс. Иначе сравниваются разные знания, а не разные методы.
• Разделение train/test по документам, а не по вопросам. Если вопрос из теста опирается на документ, который модель видела при обучении, замер смещён в пользу CPT.
• Тестовый набор с эталонными ответами и указанием источника. Несколько десятков вопросов хватает, чтобы увидеть разницу, если разметка честная и в наборе есть ловушки на галлюцинации.
• Метрики качества отдельно для поиска и отдельно для генерации. Для RAG это accuracy или F1 ответа плюс recall@k поиска. Для CPT retrieval-метрик нет по определению. Если не разделить эти слои, непонятно, где потеря: в индексе или в модели.
• Метрики производительности. Время до первого токена, скорость генерации в токенах в секунду, занятая VRAM, число входных токенов на запрос.

Последний пункт объясняет половину расхождений между такими тестами. RAG подставляет в промпт несколько тысяч токенов контекста, и это напрямую бьёт по prefill и по KV-cache. CPT-версия отвечает с коротким промптом. Почему одна и та же модель показывает разные цифры в зависимости от квантизации, длины контекста и условий запуска, подробно разобрано в материале о том, действительно ли DeepSeek отстал от Qwen и GLM или так только выглядит. Пример честной методики, где зафиксировано число прогонов и прозрачно посчитаны ошибки, есть в тесте 35B-моделей на 120 прогонах.

Результаты: точность и производительность

В доступных материалах результатов эксперимента нет: ни метрик, ни условий запуска, ни размера корпуса. Называть конкретные проценты превосходства CPT или RAG по Qwen 3.5 4B нечем.

Что может сделать читатель, который ждёт конкретики:

1. Вернуться к первоисточнику через пару недель. Разборы такого формата часто дополняют после вопросов в комментариях, когда автору приходится раскрывать методологию.
2. Поставить свой тест. Qwen 3.5 4B помещается на потребительскую GPU, а простой RAG-пайплайн собирается за вечер на десятке скриптов.
3. Сравнивать режимы по одной метрике за раз. Сначала точность на фактологических вопросах, потом latency и VRAM. Одновременный замер всего даёт кашу.

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

Когда CPT оправдан, а когда лучше RAG

Сценарии для CPT

CPT имеет смысл, когда знания стабильны, а требования к инференсу жёсткие.

• Закрытая предметная область. Медицинские заключения, юридические тексты, внутренний сленг компании, узкая инженерная терминология. Модель должна говорить на языке домена без подсказок в промпте.
• Знания не меняются месяцами. Стандарты, кодексы, учебные материалы, методики. Переобучение раз в год дешевле постоянной поддержки индекса.
• Автономная работа. Офлайн-инференс, edge-устройства, изолированные контуры без доступа к внешней базе. Если сети нет, RAG физически некуда развернуть.
• Низкая задержка и предсказуемая стоимость. Короткий промпт ускоряет prefill и снижает плату за входные токены на каждом запросе.
• Единый формат ответа. Когда модель отвечает по жёсткому шаблону, доменное дообучение убирает половину инструкций из промпта.

Цена вопроса: CPT требует большого чистого корпуса, GPU-времени и обязательной проверки на забывание общих способностей. Обновление знаний означает новую тренировку, а не правку одного документа в индексе.

Сценарии для RAG

RAG остаётся практичнее в ситуациях, где важнее актуальность и прозрачность, а не скорость ответа.

• Данные меняются постоянно. Новости, цены, тикеты поддержки, релизы, обновляемые регламенты. Переиндексация занимает минуты, переобучение - дни.
• Нужна ссылка на источник. Юридические заключения, аудит, медицина, любая сфера, где ответ без указания документа бесполезен.
• Разные права доступа. Один индекс, но разные пользователи видят разные чанки. В веса такое разграничение не зашить.
• Ограниченный бюджет на обучение. RAG не требует GPU-часов на тренировку, только на инференс.
• Быстрый старт. Пайплайн собирается за часы, и его качество можно улучшать итеративно, не переобучая модель.

Слабое место RAG известно: качество вытягивает не генератор, а поиск. Ошибки чанкинга, слабый эмбеддер и неудачный top-k дают уверенный неверный ответ. Как ужать русскоязычный dense-эмбеддер для поиска и не потерять качество, разобрано в материале о том, как сократить русский retriever до 24 млн параметров. Сложные многосоставные вопросы, где поиск нужно вести итеративно, разобраны на примере многошагового семантического поиска в Amazon Bedrock.

Между двумя крайностями есть гибридные схемы. LoRA или PEFT обучают небольшую надстройку над весами и дают часть пользы CPT при заметно меньших затратах. Дальше такую модель сочетают с RAG: дообучение отвечает за стиль, формат и доменную лексику, а поиск закрывает актуальные факты и ссылки. Третий путь - сжимать саму базу знаний под конкретный класс запросов, чтобы не гонять полный индекс на каждый вопрос; пример такого подхода разобран в разборе сжатия базы знаний для аналитических задач на AWS.

Затраты на подготовку данных и железа

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

Железо. Полный fine-tune модели на 4 млрд параметров в fp16 с оптимизатором Adam требует памяти под веса (около 8 ГБ), градиенты (ещё около 8 ГБ), два состояния оптимизатора в fp32 (порядка 32 ГБ) и активации. Суммарно это уже больше 50 ГБ VRAM, то есть одна потребительская карта не подходит: нужны ускорители класса 80 ГБ или несколько GPU с шардингом. LoRA обучает единицы процентов параметров, поэтому градиенты и состояния оптимизатора считаются только для них, и задача укладывается в 12-24 ГБ в зависимости от ранга, длины последовательности и размера батча. Точные цифры зависят от реализации: Unsloth, обычный Hugging Face Trainer и FSDP дают разный расход.

RAG обучения не требует вовсе. Инференс Qwen 3.5 4B в fp16 занимает около 8 ГБ под веса, в 4-битной квантизации - примерно 2,5-3 ГБ. Дальше начинается KV-cache, и вот он растёт линейно с длиной контекста и размером батча: две матрицы на каждый слой, умноженные на число KV-голов, размер головы, длину последовательности и батч. Именно поэтому RAG с десятком подставленных чанков может съесть больше памяти, чем сама модель.

Время. Планировать CPT на 4B стоит в днях на нескольких GPU, а не в часах: срок зависит от объёма корпуса, длины последовательности и пропускной способности железа. LoRA укладывается в часы. Сборка RAG-пайплайна занимает от нескольких часов до пары дней, а дальше вы платите только за запросы. Стоимость инференса различается принципиально: CPT отвечает коротким промптом, RAG платит за длинный контекст на каждом обращении, плюс время на сам поиск. Поиск по векторному индексу обычно быстрее генерации, но prefill длинного контекста заметно отодвигает первый токен.

Ограничения и риски CPT и RAG

CPT:

• Катастрофическое забывание. Обучение на узком домене ухудшает общие способности модели. Лечится смешиванием доменного корпуса с общим, но пропорцию нужно подбирать и проверять на общих задачах.
• Переобучение на маленьком корпусе. Модель начинает воспроизводить шаблоны и галлюцинировать увереннее, чем до обучения.
• Невозможно забыть факт. Если в корпус попали устаревшие данные или персональная информация, удалить их без переобучения нельзя.
• Веса как носитель закрытых данных. Модель становится источником утечки, её нельзя передавать наружу.
• Сложная валидация. Проверить, что именно выучила модель и на каких примерах, напрямую не получится.

RAG:

• Промах поиска. Если нужного чанка нет в top-k, модель либо откажется отвечать, либо достроит ответ из общего знания. Второе опаснее именно потому, что выглядит правдоподобно.
• Галлюцинации при нерелевантном контексте. Мусор в промпте мешает сильнее, чем отсутствие контекста: модель пытается опереться на то, что подсунули.
• Деградация на длинной истории. Качество падает, когда контекст перегружен, а диалог накапливает десятки реплик.
• Стоимость и задержка на каждом запросе. Длинный промпт оплачивается постоянно, а не один раз при обучении.
• Зависимость от инженерных деталей. Чанкинг, эмбеддер и реранкер влияют на результат сильнее, чем выбор LLM-генератора.

Оба подхода требуют честного тестирования отказов. Умение сказать «в документе этого нет» стоит дороже, чем ещё пара процентов точности на вопросах, где ответ вообще существует.

Вывод: что выбрать для вашей задачи

Рабочий алгоритм выглядит так.

1. Данные меняются чаще, чем раз в квартал? RAG. Переиндексация дешевле переобучения.
2. Нужны ссылки на источник и разграничение доступа? RAG. В веса это не зашить.
3. Нужна работа без сети и минимальная задержка? CPT или LoRA.
4. Корпус стабильный, большой и есть GPU-часы? CPT, возможно с последующим SFT.
5. Бюджета на обучение нет, но есть векторная база? RAG плюс LoRA для стиля и формата.
6. Нужно и то и другое? Гибрид: доменное дообучение отвечает за язык и формат, поиск закрывает актуальные факты.

Что касается самого эксперимента на Qwen 3.5 4B, без опубликованной методологии и метрик опираться на него в продакшн-решении нельзя. Проверять гипотезу придётся самому: один корпус, один тестовый набор, разделение замеров на поиск и генерацию, отдельный учёт времени до первого токена и занятой VRAM. Такой тест стоит нескольких дней работы и снимает вопрос «что выбрать» по вашим данным, а не по чужим графикам без подписей.

Подписаться на канал