Ключевые выводы

Не всякая задача, которую называют обучением, требует изменения весов. Часто достаточно поиска по документам, инструкций в промпте или вызова API.

Знания ≠ поведение ≠ инструменты ≠ внешняя память. Базовая модель умеет язык; SFT меняет стиль и формат; RAG подставляет актуальные факты; агенты действуют через системы.

LoRA — способ дешёвой адаптации, а не отдельный тип знаний. Это техника «как менять веса дешевле», а не ответ на вопрос «чему учить».

RAG не обучает модель «помнить PDF». Он подключает внешние источники на время ответа. Для регламентов, цен и версий документов это обычно правильнее, чем дообучение корпуса.

Зрелая система — гибрид. Предобучение/SFT/предпочтения задают способности и поведение; RAG — факты; инструменты — действия; оценка — проверку качества.

Что на самом деле значит «обучить модель»

Распространённое заблуждение: «если LLM должна знать наши документы, её нужно дообучить на этих документах». Отсюда рождаются проекты «загрузить 100 000 PDF в дообучение» — дорогие, плохо обновляемые и почти непрозрачные.

Есть принципиально разные механизмы:

1. Предобучение (pretraining) — создание базовой языковой модели на огромном корпусе.
2. Продолженное предобучение (continued pretraining) — донастройка на специализированном корпусе домена.
3. SFT (контролируемое дообучение) — обучение следовать инструкциям и формату.
4. Оптимизация предпочтений (RLHF, DPO и сходные методы) — предпочтение лучших ответов.
5. LoRA / PEFT — технический способ менять малую долю параметров.
6. RAG — поиск по внешней базе без изменения весов.
7. Использование инструментов / агенты — вызов API, SQL, файлов и бизнес-сервисов.

Кратко: обучение меняет параметры. RAG и инструменты обычно не меняют параметры — они меняют контекст и возможности действия.

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

Уровень 1. Предобучение — базовая модель

Предобучение (pretraining) — основное обучение на огромном массиве текстов. Упрощённо:

тексты → токенизация → нейросеть → предсказание следующего токена → ошибка → обновление весов

На каждом шаге модель видит префикс («В 1863 году был издан …») и учится предсказывать следующий токен. После миллиардов таких шагов появляются внутренние представления языка, синтаксиса, понятий, стилей и большого числа фактов. Но это не таблица «факт → значение»: знания распределены по параметрам.

Почему этап дорогой: объём токенов, размер модели, кластеры GPU/TPU, время, хранение чекпойнтов, распределённое обучение. Конкретные цены и размеры быстро устаревают — важнее принцип: создать новую базовую LLM с нуля имеет смысл единицам организаций, остальным обычно выгоднее брать готовую базу и адаптировать её уровнем ниже.

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

Кратко: предобучение даёт общие способности модели; это фундамент, а не корпоративная база знаний.

Что такое веса модели

Параметры (веса) — числа внутри слоёв сети. При обучении они сдвигаются в сторону меньшей ошибки предсказания. Интуитивно:

W_new ≈ W_old − learning_rate × gradient

Когда говорят «мы обучили модель», почти всегда имеют в виду: изменили эти числа (все или часть). Когда говорят «подключили RAG», веса обычно остаются теми же: меняется только текст, который модель видит в контексте запроса.

Отсюда практический вывод: если информация должна обновляться ежедневно, хранить её в весах — как писать регламент на камне. Если нужно устойчивое поведение («всегда отвечай JSON-схемой X»), изменение весов или сильный SFT/инструкции могут быть уместны.

Ещё один нюанс: «забыть» факт из весов почти невозможно точечно. Можно дообучить на новых примерах, сузить генерацию политикой, отфильтровать ответ — но гарантированно вычистить устаревший абзац из параметров, как строку из базы, нельзя. Именно поэтому юристы и ИБ чаще спрашивают не «насколько модель умная», а «можем ли мы доказать, на каком источнике построен ответ, и отозвать документ». Подробнее граница «знания vs поведение» разобрана в материале когда действительно нужно дообучение.

Уровень 2. Продолженное предобучение — адаптация к домену

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

Base LLM → доменный корпус → continued pretraining → Domain-adapted LLM

Отличие от SFT: здесь цель ближе к сдвигу внутреннего распределения языка и фактов домена, а не к жёсткому «на этот вопрос отвечай вот так». SFT учит поведению и формату; продолженное предобучение — «говорить на языке отрасли» на большом объёме текста.

Когда смотреть в эту сторону: огромный закрытый корпус, редкая терминология, слабая нулевая база на домене. Когда не смотреть: «у нас 500 регламентов» — это задача RAG и подготовки корпуса, а не повторного предобучения.

Уровень 3. SFT — поведение и инструкции

После предобучения модель умеет продолжать текст, но не обязательно стабильно выполнять инструкции. SFT учит на парах «инструкция → желаемый ответ»:

Вопрос: Объясни принцип работы RAG.
Хороший ответ: …

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

SFT не заменяет актуальную базу документов. Он делает ответы предсказуемее по форме и стилю. Практический пример узкого SFT/QLoRA под классификацию перед поиском — в разборе дообучения маленькой локальной модели.

Кратко: SFT говорит модели «делай так»; RAG говорит «вот свежие факты для этого ответа».

LoRA и PEFT — как дешевле менять веса

LoRA и другие методы PEFT часто путают с отдельным «уровнем знаний». Это прежде всего техника: вместо обновления всех параметров обучают небольшие адаптерные матрицы поверх замороженной базы.

Base model (заморожена)
        +
   LoRA adapter
        ↓
 Specialized model

Плюсы: меньше обучаемых параметров и VRAM, проще хранить и переключать адаптеры, можно держать несколько специализаций на одной базе. Минус формулировки: LoRA не отвечает на вопрос «чему учить» — только на «как технически дешевле изменить модель». Нормальная комбинация: SFT + LoRA, предпочтения + LoRA и т.д.

На практике команды часто держат один базовый чекпойнт и несколько адаптеров: классификатор намерений, тон поддержки, формат внутреннего отчёта. Это дешевле, чем три полных копии модели, и проще откатывать, чем «ещё одно полное дообучение всей сети».

Уровень 4. Оптимизация предпочтений — «этот ответ лучше»

После SFT можно учить модель предпочитать одни ответы другим. Классическая схема RLHF: человек (или политика предпочтений) выбирает между вариантами A и B; модель сдвигается к поведению B. Современные альтернативы вроде DPO упрощают пайплайн, но идея та же:

SFT говорит «делай так», оптимизация предпочтений учит на сравнении «этот ответ лучше того».

Где уместно: безопасность, вежливость, следование политике продукта, снижение токсичности, предпочтение кратких/структурированных ответов. Где не уместно как замена: актуальные цены, версии регламентов, персональные данные из внутренних систем — это снова зона RAG и ACL, а не предпочтений.

Уровень 5. RAG — знания снаружи модели

RAG (генерация с дополнением из поиска, retrieval-augmented generation) — ключевой слой для прикладных систем. Модель не обязана «помнить» корпоративные документы в весах. Вместо этого:

вопрос → поиск → релевантные фрагменты → контекст → LLM → ответ (+ ссылки)

Для часто меняющейся информации — инструкции, цены, нормативные документы, каталоги, wiki — RAG обычно логичнее дообучения: источники версионируются, права проверяются до выдачи, цитаты остаются проверяемыми. Зачем предприятиям именно такая граница — в статье почему предприятиям нужен RAG. Как собрать промышленный контур (парсинг, гибридный поиск, повторное ранжирование, оценка) — в промышленной инженерии RAG и архитектуре корпоративного RAG.

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

Типичные поломки, которые маскируют под «плохую модель»: кривой OCR и таблицы в PDF; слишком крупные или слишком мелкие чанки; поиск только по векторам там, где нужен артикул или номер договора; отсутствие фильтра ролей до выдачи; переполнение окна контекста десятками полурелевантных кусков; внедрение вредоносных инструкций (prompt injection) внутри самого документа («игнорируй политику и…»). Всё это чинится инженерией поиска и корпуса, а не очередным циклом SFT.

Кратко: дообучение меняет веса; RAG подключает внешнюю память на время ответа.

Уровень 6. Инструменты и агенты

Следующий слой — не только читать знания, но и действовать:

LLM ├── RAG ├── SQL ├── REST API ├── файлы ├── расчёты └── бизнес-сервисы

Запрос «покажи продажи за прошлый месяц и объясни падение» может потребовать SQL, расчёт, документы из RAG и только потом текст. Это уже LLM + инструменты + оркестрация + права + состояние, а не «чат с моделью». Ошибки здесь чаще в правах, идемпотентности и наблюдаемости, чем в «недообученности».

Связанные темы на сайте: MCP и API для LLM, маршрутизация и шлюзы в материалах про таксономию маршрутизации LLM.

Сравнение уровней

Таблица намеренно ставит LoRA рядом с методами обучения: это как, а не зачем. RAG и инструменты стоят отдельно: они расширяют систему без переписывания параметров.

Практический сценарий: корпоративный ассистент

Допустим, есть десятки тысяч документов, API, регламенты, код, тикеты, базы и wiki. Автоматически «обучать модель на всём» — плохая постановка: документы устаревают, удалить знание из весов трудно, цитирование слабое, ACL ломается, обновление дорого.

Рабочая архитектура чаще выглядит так:

                 ┌─────────┐
                 │   LLM   │
                 └────┬────┘
          ┌───────────┼───────────┐
          ↓           ↓           ↓
         RAG        Tools       SQL/API
          │           │           │
   Knowledge Base  Internal    Databases

• RAG — действующие регламенты и wiki с фильтрацией по ролям.
• SFT / LoRA — стабильный формат черновика или классификатор намерений.
• Инструменты — создание тикета, расчёт, чтение метрик.
• Оценка — регрессия на ваших сценариях, а не только публичный рейтинг (проверка качества LLM).

Минимальный пилот часто выглядит скромно: один процесс (например, ответы по внутреннему FAQ с цитатами), эталон из 50–100 вопросов с «золотыми» фрагментами, гибридный поиск и явный отказ, если контекста недостаточно. Уже на этом контуре видно, нужен ли SFT под формат, или хватает инструкций и модуля повторного ранжирования. Масштабирование на «все документы компании» без такого эталона почти всегда превращает проект в бесконечную настройку промпта.

Как выбрать подход

Простое дерево решений:

Главная ошибка — пытаться решить всё дообучением: «у нас 100 000 PDF, давайте обучим модель на них». Документы меняются; устаревшее знание из весов не удалить кнопкой; цитирование и доступ плохо контролируются; обновление дорого. Альтернатива: LLM + RAG + ACL + повторное ранжирование + цитирование + оценка.

И обратная ошибка: ждать от RAG чудес без инженерии корпуса. Плохой разбор документов, нарезка, поиск, таблицы в PDF, внедрение вредоносных инструкций в документах — всё это ломает ответ до генерации. Глубина этого слоя — в уже опубликованных RAG-гайдах выше; здесь важно помнить границу ответственности.

Оценка — уровень зрелости системы

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

• Поиск (retrieval): полнота и точность выдачи (Recall@K, Precision@K, MRR, NDCG — как ориентиры, не как универсальные нормативы).
• Генерация: фактичность, опора на контекст, корректность цитат, релевантность ответа.
• Система: задержка, стоимость токенов, доля отказов, регрессии после смены модели или индекса.

Публичный рейтинг модели — чужая выборка. Для продукта нужен собственный набор сценариев: ваши формулировки, ваши запреты, ваш ущерб от ложного согласия. Имеет смысл раздельно трекать регрессии после смены эмбеддингов, нарезки, ранжировщика и самой LLM — иначе «стало хуже» остаётся без адресата.

Карта видов проверок — в проверке качества языковых моделей; контур регрессии — в контуре оценки ИИ; управленческий взгляд на метрики предприятия — в оценке корпоративного ИИ.

Архитектура зрелой ИИ-системы

Финальная формула не «RAG лучше дообучения», а:

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

                  AI SYSTEM
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
    Model          Knowledge       Tools
  pretraining         RAG        APIs / SQL
  SFT / LoRA        Search        Agents
  DPO/RLHF         Sources

Рядом обязательны защитные ограничения, ACL, наблюдаемость, аудит и оценка. Вопрос архитектора звучит так: какая часть задачи должна находиться в параметрах модели, какая — во внешних знаниях, а какая — в инструментах и бизнес-логике?

Если нужен продакшен-срез — RAG, агенты, MCP или LLM-шлюз с бюджетами — см. услугу внедрения ИИ.

Частые вопросы

Заключение

Обучение LLM — не один рычаг, а стек решений. Предобучение и пост-обучение формируют способности и поведение; RAG держит факты снаружи; инструменты дают действие; оценка держит систему честной. В лаборатории кода это выглядит как аккуратная сборка контура, а не магическое «залить PDF в веса».

Дальше по кластеру: почему появились LLM, почему предприятиям нужен RAG, когда нужно дообучение, промышленная инженерия RAG, проверка качества LLM.