Обучение LLM: от данных до внедрения

Основы LLM: задачи, токенизация и трансформеры

Зачем нужны LLM и что мы будем изучать в курсе

Большие языковые модели (LLM) — это нейросети, которые учатся работать с текстом так, чтобы продолжать его, отвечать на вопросы, следовать инструкциям и обобщать знания, «впитанные» из данных.

В этом курсе мы пройдём путь:

какие данные нужны и как их готовить

как модель обучается и почему ей требуется токенизация

почему архитектура трансформер стала стандартом для LLM

как доводить модель до нужного поведения (дообучение, выравнивание)

как оценивать качество и внедрять систему в продукт

Эта статья — фундамент: какие задачи решают LLM, как текст превращается в токены и как устроены трансформеры.

Какие задачи решают LLM

LLM полезны не потому, что «знают правильные ответы», а потому что хорошо моделируют текст и умеют использовать контекст.

Генерация и продолжение текста

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

продолжение текста в стиле исходного

написание писем, статей, кода

перефразирование и стилизация

суммаризация (сжатое изложение)

Ответы на вопросы и диалог

Диалоговые LLM обычно строятся так:

модель видит историю сообщений

генерирует ответ как продолжение «чата»

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

Извлечение смысла: эмбеддинги

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

Это применяют для:

семантического поиска

кластеризации документов

поиска дубликатов

подсказки контекста для генерации

Классификация и разметка

LLM могут:

определять тональность

назначать категории обращений в поддержку

извлекать поля из документов

Даже если задача выглядит как «классификация», часто её решают генеративно: модель генерирует метку или JSON-структуру.

Почему токенизация — центральная часть LLM

Компьютер не читает текст как люди. Прежде чем обучать модель, текст преобразуют в последовательность токенов.

Токен — это элемент словаря модели. Он может быть:

целым словом

частью слова

знаком пунктуации

пробелом или сочетанием символов

Токенизация нужна по трём причинам:

нейросеть работает с числами, поэтому текст надо превратить в идентификаторы токенов

словарь фиксированного размера упрощает обучение

разбиение на части слов помогает справляться с редкими словами и опечатками

!"Как текст превращается в токены и числовые идентификаторы"

Словарь (vocabulary) и id токенов

У каждой модели есть словарь — список всех токенов, которые она умеет различать. Каждому токену соответствует целое число — id.

Пайплайн выглядит так:

Текст разбивается на токены (строки).

Каждый токен заменяется на его id.

Модель работает с последовательностью id.

При генерации модель выдаёт id токенов, которые затем преобразуются обратно в текст.

Популярные алгоритмы токенизации

В современных LLM обычно используют токенизацию по подсловам.

BPE (Byte-Pair Encoding): постепенно объединяет частые пары символов/подслов в новые токены. Классическая работа для NLP: Neural Machine Translation of Rare Words with Subword Units.

WordPiece: близкий подход, известен по BERT; часто оптимизируется под задачу и набор данных.

Unigram (SentencePiece): вероятностная модель подслов; реализация популярна в SentencePiece.

Практический вывод:

чем богаче словарь, тем меньше токенов на текст, но больше память и вычисления на слой эмбеддингов

чем «мельче» токены, тем лучше покрытие редких слов, но длиннее последовательности

Специальные токены

Модели часто используют служебные токены:

начало и конец последовательности

разделители ролей в диалоге

маркер «паддинга» для выравнивания длины в батче

Конкретные названия зависят от семейства моделей и библиотеки.

Контекстное окно и стоимость токенов

Контекстное окно — максимальная длина последовательности токенов, с которой модель работает за один прогон.

Это важно, потому что:

длинные документы могут не помещаться целиком

стоимость инференса и обучения растёт с длиной последовательности

Для практики полезно уметь оценивать токены заранее. Например, для моделей OpenAI есть токенизатор tiktoken, а в экосистеме Hugging Face — быстрые токенизаторы и документация: Hugging Face Tokenizers.

Трансформеры: архитектура, которая сделала LLM возможными

Трансформер — архитектура нейросети, которая обрабатывает последовательность токенов, используя механизм внимания (attention). Она стала стандартом после статьи Attention Is All You Need.

Главная идея: модель на каждом шаге может «смотреть» на разные места в контексте и решать, какие токены важны прямо сейчас.

!"Упрощённая схема decoder-only трансформера для предсказания следующего токена"

Из чего состоит обработка текста в трансформере

В упрощённом виде обработка выглядит так:

Embedding-слой переводит id токенов в векторы (числовые представления).

Добавляется информация о позиции токена в последовательности (потому что внимание само по себе не «знает», где начало и конец).

Последовательно применяются несколько одинаковых трансформер-блоков.

На выходе получается распределение вероятностей следующего токена.

Что такое self-attention и зачем он нужен

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

Интуитивно:

токен «он» может «обратить внимание» на существительное, к которому относится

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

Технически внутри attention получаются веса, похожие на вероятности: они неотрицательные и в сумме дают 1. Часто это обеспечивается функцией softmax:

Пояснение элементов формулы:

— «оценка важности» i-го токена контекста для текущего токена

— экспонента, делает веса положительными и усиливает разницу

— сумма по всем токенам, нужна для нормировки

— итоговый вес внимания к i-му токену

Multi-head attention

Обычно attention делают многоголовым (multi-head): несколько «голов» внимания работают параллельно и могут специализироваться на разных типах связей.

Практическая интерпретация:

одна голова может лучше отслеживать согласование по числу/роду

другая — искать определение к существительному

третья — поддерживать тематическую связность

Feed-forward слой и остаточные связи

Внутри каждого трансформер-блока обычно есть:

feed-forward сеть: нелинейное преобразование каждого токена по отдельности

residual connections (остаточные связи): добавление входа блока к его выходу, чтобы обучение глубоких сетей было стабильнее

layer normalization: нормализация активаций для устойчивого обучения

Эти компоненты важны не меньше внимания: они помогают модели наращивать глубину и качество.

Encoder, decoder и почему многие LLM — decoder-only

Есть два популярных семейства трансформеров:

encoder-only (например, BERT-подобные): хороши для понимания текста, классификации, эмбеддингов

decoder-only (например, GPT-подобные): хороши для генерации

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

Как LLM генерирует текст

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

Типовые стратегии:

greedy decoding: брать самый вероятный токен

temperature: регулировать «смелость» распределения (выше — разнообразнее)

top-k: ограничить выбор k самыми вероятными токенами

top-p (nucleus): выбирать из минимального набора токенов, суммарная вероятность которых не меньше

Эти настройки сильно влияют на стиль и стабильность ответов.

Что важно запомнить перед следующими темами курса

LLM решают широкий класс задач, но их основа — предсказание следующего токена или получение эмбеддингов.

Токенизация определяет, как текст превращается в числа, и напрямую влияет на длину последовательности, стоимость и поведение модели.

Трансформер использует self-attention, чтобы учитывать контекст, а decoder-only с каузальной маской — стандарт для генеративных LLM.

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

Data for training: collection, cleaning, filtering, and deduplication

LLMs work by predicting the next token based on context. In the previous article, we discussed tokenization and transformers as the mechanism that turns sequences of token ids into predictions. This article focuses on what often matters even more in practice: the training data pipeline.

Good data is not just “a lot of text”. It is a system of decisions:

where text comes from and what you are allowed to use

how you remove noise that wastes tokens and compute

how you filter harmful, low-quality, or irrelevant content

how you remove duplicates to reduce memorization and evaluation leakage

!End-to-end view of a typical LLM data pipeline

What “training data” means for an LLM

For most decoder-only LLMs, training data is a very large set of text sequences. After tokenization, the model is trained to predict the next token. That means your dataset quality directly impacts:

capabilities: what domains the model can talk about and how well

style: helpfulness, verbosity, formality, structure

safety: propensity to output toxic content or personal data

cost: noisy text increases tokens and training time without adding useful signal

A practical mental model:

data coverage determines what the model can learn

data cleanliness determines how efficiently it learns

data filtering and deduplication determine how safely and reliably it behaves

Collection: where training text comes from

Common data sources

Typical sources used in LLM pretraining or domain adaptation:

Web crawls: large-scale public web snapshots such as Common Crawl

Curated web datasets: for example, C4 derived from Common Crawl (described in Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer)

Large mixed corpora: for example, The Pile

Code: public repositories, permissively licensed code dumps, internal code (if allowed)

Licensed text: books, news, academic corpora under explicit contracts

Internal enterprise text: documentation, tickets, knowledge bases (usually for fine-tuning or RAG, not for broad pretraining)

Synthetic data: model-generated text for specific skills, usually for instruction tuning and augmentation

Legal and policy constraints you must decide early

These constraints shape everything downstream:

Copyright and licensing: you need a clear policy on what is allowed and how it is attributed or restricted

Terms of service: many websites explicitly restrict automated scraping or reuse

Privacy: personal data can appear in web text and internal corpora

Jurisdiction: data protection rules differ by region and use case

If you are building a commercial system, involve legal and security teams before large-scale collection.

Data provenance and documentation

Track where each document came from and what happened to it:

source name and snapshot date

URL or identifier

extraction method (HTML parsing, API export, PDF OCR)

applied filters and their versions

dedup keys or hashes

This makes failures debuggable and improves reproducibility.

Ingestion and normalization: making raw text usable

Raw text is messy. Before “quality filtering”, you usually need consistent structure.

Text extraction and boilerplate removal

Common issues:

navigation menus and repeated headers

cookie banners and popups captured in HTML

“related articles” blocks that repeat across pages

code blocks and tables mixed with prose

Typical approaches:

HTML parsing to keep only main content

heuristics to remove short repeated lines

template detection for domains that produce many near-identical pages

Unicode and encoding normalization

You want consistent text representation:

normalize Unicode (avoid visually identical but different code points)

standardize newlines and whitespace

remove control characters

This reduces accidental duplicates and tokenizer weirdness.

Document segmentation

Decide what a “document” is:

a full web page

an article body

a section or paragraph chunk

Smaller chunks can help training stability and reduce wasted context, but overly small chunks can remove long-range structure that transformers can learn.

Language identification

Most large crawls are multilingual. If your target model is English-only or mostly English, you need language ID.

A common baseline is fastText language identification: fastText language identification.

Cleaning: removing obvious noise

Cleaning is about eliminating text that is clearly not useful for modeling language.

Examples of “cleaning rules”:

drop extremely short documents

drop documents dominated by non-letter characters

drop pages that look like error messages, login pages, or empty templates

remove embedded base64 blobs and minified scripts

remove repeated lines within a document

A useful principle:

cleaning is mostly deterministic and aims to remove obvious garbage

filtering is more judgment-based and aims to improve usefulness and safety

Filtering: improving quality and safety

Filtering is where you encode what “good” means for your model.

Quality filtering signals

Common signals used in practice:

length-based heuristics: too short is often low value, too long may be logs or dumps

character distribution: excessive punctuation, digits, or strange symbols

stopword and word frequency patterns: extremely low natural-language density

classifier-based quality: a model predicts “high quality web text” versus spam

perplexity-based filtering: a small reference language model flags text that looks unnatural or corrupted

Important trade-off:

aggressive filtering can remove minority dialects, informal writing, and domain-specific language

weak filtering can keep spam that wastes tokens and can degrade model behavior

Safety filtering signals

Safety filtering usually targets:

explicit sexual content

hate and harassment

self-harm instructions

illegal instructions

personal data

For detecting and redacting personal data, teams often use dedicated PII tooling such as Microsoft Presidio.

Be careful: automated safety filters have false positives and false negatives. You need an error budget and a review process.

Domain and audience filtering

If you are training a domain model, define inclusion and exclusion rules:

allowlist trusted domains or document types

require specific metadata tags

enforce reading level or formality

This is often more effective than trying to “fix” a broad web corpus at the end.

Deduplication: why it matters and how it is done

Deduplication removes repeated or near-repeated text. It matters for three reasons:

training efficiency: duplicates waste compute and increase effective sampling of the same content

memorization and privacy risk: repeats can increase the chance a model outputs memorized spans

evaluation leakage: if benchmarks or their solutions appear in training data, offline metrics become unreliable

Research has shown that training data can be extracted verbatim from LLMs under certain conditions: Extracting Training Data from Large Language Models.

Exact deduplication

Exact dedup is the simplest:

normalize text (whitespace, Unicode)

compute a hash per document

remove identical hashes

Pros:

fast and straightforward

Cons:

misses near-duplicates like “same article with minor edits”

Near-duplicate deduplication

Near-duplicate methods catch “almost the same” documents:

compute fingerprints from token or character n-grams

use similarity estimates to cluster documents

keep one representative per cluster

This is important for web data where many sites republish the same content.

!Exact duplicates vs near duplicates vs overlap duplicates

Document-level vs span-level dedup

Two different goals:

document-level dedup: remove repeated documents

span-level dedup: remove repeated passages inside different documents

Span-level dedup is harder but can be valuable when long boilerplate or copied paragraphs appear widely.

Deduplication and splits

A common failure mode:

you deduplicate only within training data

but validation and test sets still contain near-duplicates of training

Better practice:

deduplicate before splitting, or

deduplicate across splits so that evaluation is genuinely out-of-sample

Putting it together: a practical pipeline

A pragmatic end-to-end pipeline for a first production-grade dataset:

Collect raw documents with provenance metadata.

Extract main text and normalize encoding.

Run language ID and keep target languages.

Apply cleaning rules to remove obvious garbage.

Apply quality filters tuned to your model goals.

Apply safety filters and PII handling consistent with your policy.

Deduplicate exact and near-duplicates.

Create train, validation, and test splits with leakage checks.

Export to sharded files and record dataset versioning.

Tooling note: for iterating quickly on datasets and sharing artifacts, many teams use Hugging Face Datasets as a format and library, even if final training uses custom dataloaders.

Common pitfalls and how to avoid them

Over-filtering that damages coverage

Symptoms:

model becomes overly formal, refuses benign topics, or fails on informal user language

Mitigations:

measure what you removed by sampling filtered-out documents

keep a controlled amount of informal text

evaluate on realistic user prompts, not only benchmarks

Under-filtering that damages behavior

Symptoms:

model outputs spam-like completions, unsafe content, or nonsense

Mitigations:

add a learned quality classifier

add domain allowlists for key use cases

tighten cleaning rules for known garbage patterns

Hidden duplicates that inflate metrics

Symptoms:

offline evaluation looks great, but real-world performance disappoints

Mitigations:

deduplicate across train and evaluation

scan training data for benchmark artifacts

maintain a “do not train on” list for eval sets and internal test prompts

What to carry forward

Transformers learn from tokens, but your dataset determines which tokens exist and how often they appear.

Cleaning removes obvious noise, filtering encodes your definition of quality and safety, and deduplication protects efficiency and evaluation integrity.

Treat the dataset as a versioned product with provenance, policies, and measurable trade-offs.

Предобучение модели: цели, гиперпараметры и распределённое обучение

В прошлых статьях курса мы разобрали, что такое LLM (токены, трансформеры) и из чего они учатся (сбор, очистка, фильтрация и дедупликация данных). Теперь соберём картину целиком: как именно происходит предобучение (pretraining), какие цели оптимизируются, какие гиперпараметры чаще всего определяют успех, и почему без распределённого обучения современные LLM почти невозможны.

Что такое предобучение и чем оно отличается от дообучения

Предобучение — это обучение модели на большом массиве текстов (обычно без ручной разметки), чтобы она научилась хорошо предсказывать продолжение текста и приобрела общие знания о языке и мире.

Отличия от последующих этапов:

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

Инструкционное дообучение (instruction tuning) учит отвечать в нужном формате и стиле на примеры “вопрос → ответ”.

Выравнивание (alignment) добавляет предпочтения людей и требования безопасности (часто через методы на основе человеческой обратной связи).

В этой статье фокус — именно предобучение decoder-only трансформера (GPT-подобной модели), о котором мы говорили в статье про трансформеры.

Цель предобучения: предсказание следующего токена

Для большинства LLM базовая постановка такая: модель получает контекст токенов и должна предсказать следующий токен.

Если у нас есть последовательность токенов , то модель учится оценивать вероятность каждого следующего токена:

Расшифровка обозначений:

— токен на позиции .

— все предыдущие токены (контекст).

— вероятность, которую выдаёт модель.

Функция потерь: кросс-энтропия

Во время обучения модель выдаёт распределение вероятностей по словарю токенов, а мы “штрафуем” модель, если истинный следующий токен получил низкую вероятность.

Чаще всего используют среднюю отрицательную лог-вероятность (эквивалент кросс-энтропии для классификации следующего токена):

Пояснение каждого элемента:

— итоговая потеря (loss), число, которое мы минимизируем.

— длина обучающей последовательности в токенах.

— суммируем вклад ошибки по всем позициям.

— логарифм вероятности истинного токена: если вероятность близка к 1, логарифм почти 0 (штраф маленький), если вероятность мала — штраф большой.

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

Перплексия как интерпретация качества

Часто качество предобучения на валидации измеряют перплексией (perplexity). Интуитивно это “насколько модель удивляется тексту”: ниже — лучше. Перплексия напрямую связана с loss, поэтому в инженерной практике важно помнить: улучшать loss на валидации обычно значит улучшать языковое моделирование, но это ещё не гарантирует хорошее следование инструкциям.

Классические примеры предобучения LLM описаны в работах:

Language Models are Few-Shot Learners

LLaMA: Open and Efficient Foundation Language Models

Что именно подаётся в модель: последовательности, “чанки” и маска

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

токенизируют документы

собирают длинный поток токенов

режут его на отрезки фиксированной длины (например, 2048 или 4096 токенов)

У decoder-only трансформера применяется каузальная маска (мы обсуждали её в статье про трансформеры): позиция не может использовать будущие токены .

Практическая деталь: многие пайплайны “склеивают” документы в общий поток токенов, чтобы меньше тратить места на паддинг. Но тогда нужно аккуратно ставить разделители (специальные токены конца документа), иначе модель будет учиться странным переходам между несвязанными текстами.

Ключевые гиперпараметры предобучения

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

Размер модели и форма трансформера

Архитектурные параметры обычно задают:

число слоёв (depth)

размер скрытого состояния (hidden size)

число голов внимания (attention heads)

размер MLP внутри блока (часто кратен hidden size)

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

Длина контекста и длина обучающих последовательностей

Длина последовательности (sequence length) влияет на всё:

стоимость обучения и инференса

способность учиться на длинных зависимостях

требования к памяти GPU

Важно не путать:

контекстное окно модели как архитектурное ограничение

длину последовательностей в предобучении как выбор даталоадера и бюджета

Модель можно архитектурно поддерживать 8192 токена, но предобучать в основном на 2048 — это будет дешевле, но длинный контекст может работать хуже.

Размер батча и накопление градиента

Batch size в LLM почти всегда обсуждают как глобальный батч — суммарное число токенов, обработанных всеми GPU до одного шага оптимизатора.

Чтобы получить большой глобальный батч без переполнения памяти, используют накопление градиента (gradient accumulation):

делаем несколько “микро-батчей”

считаем градиенты

суммируем их

обновляем веса один раз

Это даёт эффект большого батча при ограниченной памяти.

Оптимизатор и weight decay

Стандарт де-факто для LLM — AdamW: Adam с корректной реализацией weight decay.

learning rate (скорость обучения) — ключевой параметр: слишком большой ломает стабильность, слишком маленький делает обучение медленным.

weight decay — регуляризация, которая помогает обобщению (но её важно аккуратно настраивать и часто не применять к некоторым параметрам вроде нормализаций).

План learning rate: warmup и decay

Обычно learning rate меняют по расписанию:

warmup: в начале обучения learning rate постепенно растёт (помогает избежать “взрыва” градиентов в первые шаги)

затем learning rate постепенно уменьшается (decay), например по cosine schedule

!Типичное расписание learning rate: рост на warmup и затем плавное уменьшение

Стабилизация обучения: clipping, dropout, нормализации

Чтобы обучение больших трансформеров было стабильным, часто используют:

gradient clipping: ограничение нормы градиента, чтобы редкие “всплески” не разрушали веса

dropout: не всегда агрессивно используют в больших LLM, но он может помогать обобщению в некоторых режимах

инициализации и нормализации: детали реализации (например, где стоит LayerNorm и какие масштабы инициализации) сильно влияют на стабильность

Mixed precision: FP16 и BF16

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

FP16 (float16): быстрее и экономнее, но может быть менее стабильным

BF16 (bfloat16): часто стабильнее, если доступен на вашем железе

Смысл простой: часть вычислений делается в 16-битной точности, но критичные места (например, некоторые накопления) остаются в более высокой точности, чтобы не потерять численную устойчивость.

Как оценивать прогресс предобучения

Во время предобучения важно иметь минимальный, но надёжный набор метрик.

Обычно отслеживают:

train loss: показывает, учится ли модель вообще

validation loss / perplexity: главный сигнал обобщения

скорость: tokens/sec, шагов/час

стабильность: есть ли NaN, скачки loss, “дивергенция”

Практически важно держать отдельный, чистый валидационный набор:

из источников, похожих на тренировочные

без утечек (что связано с дедупликацией из предыдущей статьи)

Почему распределённое обучение необходимо

Современные LLM слишком велики для одной GPU:

веса модели могут занимать десятки гигабайт

состояния оптимизатора (например, Adam хранит дополнительные тензоры) часто в несколько раз больше весов

активации для обратного прохода занимают огромную память, особенно при длинном контексте

Поэтому обучение почти всегда распределяют.

Основные виды параллелизма

Есть три базовых способа распараллелить обучение, и на практике их часто комбинируют.

Data parallelism

Data parallelism: копии модели на разных GPU получают разные батчи данных.

каждая GPU считает градиенты

затем градиенты усредняются (all-reduce)

веса обновляются синхронно

Плюсы: просто и эффективно.

Минусы: каждая GPU хранит полную копию модели и состояний оптимизатора (память быстро заканчивается).

Model parallelism (tensor parallelism)

Tensor parallelism (часто называют model parallelism): один слой модели “режется” по устройствам. Например, матрицы линейных преобразований в attention и MLP делят по столбцам или строкам.

Плюсы: можно обучать модели, которые не помещаются целиком на одну GPU.

Минусы: больше коммуникаций между GPU.

Практический референс: Megatron-LM.

Pipeline parallelism

Pipeline parallelism: слои модели распределяют по устройствам как конвейер.

GPU1 считает первые слои

GPU2 — следующие

и так далее

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

Минусы: появляются “пузыри” конвейера (часть устройств простаивает), сложнее отлаживать.

!Три основных вида параллелизма: data, tensor и pipeline

Шардинг состояний и экономия памяти

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

Популярный подход — ZeRO (Zero Redundancy Optimizer):

часть данных, которые обычно дублируются на каждой GPU, хранится “разделённо”

при необходимости куски собираются для вычислений

Практический референс: DeepSpeed и описание ZeRO в статье ZeRO: Memory Optimizations Toward Training Trillion Parameter Models.

Также распространён подход в PyTorch: Fully Sharded Data Parallel (FSDP).

Как собрать это в рабочую конфигурацию

Типовая “производственная” конфигурация предобучения выглядит так:

data parallelism для масштабирования по числу GPU

tensor parallelism, если модель крупная и не помещается целиком

шардинг состояний оптимизатора (ZeRO/FSDP), чтобы уложиться в память

gradient accumulation, чтобы получить нужный глобальный батч

mixed precision (BF16/FP16), чтобы ускорить обучение

Важно: это не набор “галочек”, а система взаимосвязанных решений. Например, увеличение длины последовательности почти всегда заставляет менять микро-батч, accumulation и стратегию параллелизма.

Частые сбои и как их диагностировать

Loss “взорвался” или появились NaN

Типовые причины:

слишком большой learning rate или слишком короткий warmup

проблемы mixed precision (особенно FP16)

численная нестабильность при больших последовательностях

Типовые действия:

уменьшить peak learning rate

увеличить warmup

включить/усилить gradient clipping

попробовать BF16 вместо FP16

Модель учится, но качество на валидации не улучшается

Причины часто лежат не только в оптимизации, но и в данных:

сильные дубликаты, переобучение на повторяющиеся куски

домены данных не совпадают с валидацией

слишком агрессивная фильтрация “вычистила” полезные примеры

Это связывает предобучение напрямую с темой предыдущей статьи про подготовку данных.

Обучение медленное

Частые узкие места:

даталоадер не успевает подавать данные

слишком много коммуникаций между GPU из-за выбранной схемы параллелизма

неоптимальные ядра attention/MLP

На практике команды отдельно профилируют:

время на CPU-пайплайн данных

время forward/backward

время коммуникаций

Что нужно запомнить перед следующими темами курса

Предобучение LLM почти всегда сводится к задаче предсказания следующего токена и оптимизации кросс-энтропии.

Ключевые гиперпараметры — длина последовательности, глобальный батч, learning rate и его расписание, mixed precision и стабилизация (например, clipping).

Масштабирование до современных моделей требует распределённого обучения: data parallelism, tensor/pipeline parallelism и шардинг состояний оптимизатора.

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

Дообучение под задачу: SFT, PEFT/LoRA и инструктивные датасеты

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

отвечать по инструкции

соблюдать формат (JSON, таблица, шаги)

придерживаться тона (деловой, дружелюбный)

работать в вашем домене (поддержка, финансы, медицина)

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

SFT: supervised fine-tuning, обучение на примерах «вход → правильный ответ»

PEFT: parameter-efficient fine-tuning, дообучение малым числом параметров (включая LoRA)

инструктивные датасеты: откуда берутся, как устроены, какие ошибки в них самые дорогие

Статья опирается на предыдущие темы курса:

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

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

Картина целиком: где SFT и LoRA находятся в жизненном цикле LLM

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

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

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

Выравнивание (не тема этой статьи): усиление предпочтений людей и безопасного поведения, например через RLHF.

Внедрение: инференс, RAG, мониторинг, обновления.

!Контекстная схема, показывающая место SFT и PEFT/LoRA в общем процессе

Что такое SFT и какую проблему оно решает

SFT (supervised fine-tuning) — это дообучение модели на наборе примеров, где для каждого входа задан желаемый ответ.

Типы задач, которые обычно закрывают SFT:

следование инструкциям: «сделай X»

форматирование: «верни JSON по схеме», «сделай план», «ответь списком»

диалог: учёт ролей и истории сообщений

доменная адаптация: терминология, шаблоны ответов, политика компании

Почему SFT работает, хотя цель обучения «та же самая»

На уровне оптимизации SFT почти всегда остаётся обучением «предсказать следующий токен», как и предобучение. Разница в другом:

меняется распределение данных: теперь модель видит много пар «инструкция → хороший ответ»

меняется формат контекста: появляются роли, разделители, системные правила

усиливается сигнал качества: ответы обычно короче, более целевые, с меньшим количеством мусора, чем веб-корпус

Практическая интерпретация:

предобучение учит «как устроен язык и мир»

SFT учит «как отвечать пользователю так, как мы хотим»

Что именно считается ошибкой в SFT

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

вход (prompt) подаётся как контекст

loss считается по токенам ответа (completion)

Это важно: если считать loss по токенам входа, модель будет «учиться повторять промпт», что часто ухудшает поведение.

Форматы инструктивных данных: от простых пар до чатов

Инструктивные датасеты встречаются в двух основных формах.

Формат «инструкция → ответ»

Минимальная структура:

instruction: что сделать

input: дополнительный контекст (опционально)

output: правильный ответ

Пример строки JSONL:

Плюсы:

просто собирать и валидировать

удобно для задач суммаризации, извлечения, перефразирования

Минусы:

хуже моделирует реальные диалоги

сложнее обучать правила поведения, которые зависят от истории сообщений

Чат-формат: роли и история

Для диалоговых моделей чаще используют сообщения с ролями:

system: правила и стиль ассистента

user: запрос пользователя

assistant: ответ

Важная инженерная деталь: как именно роли кодируются в токены, зависит от семейства модели и её chat template. Для моделей в экосистеме Hugging Face это часто делается через tokenizer.apply_chat_template.

Типовой риск:

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

Откуда берутся инструктивные датасеты

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

Человеческая разметка

Сильные стороны:

высокая точность и полезность

можно задавать сложные политики: стиль, безопасность, формат

Слабые стороны:

дорого

трудно покрыть весь хвост редких кейсов

Один из известных примеров подхода «инструкции + человеческие предпочтения» описан в статье Training language models to follow instructions with human feedback.

Логи продукта и служебные базы знаний

Сильные стороны:

соответствуют реальным запросам пользователей

хорошо закрывают доменные сценарии

Слабые стороны:

приватность и PII

возможны «плохие ответы» в истории, которые нельзя напрямую превращать в эталон

Связь с темой данных из прошлой статьи:

нужна агрессивная работа с PII

нужна дедупликация и контроль утечек в оценку

Синтетические данные (генерация другой моделью)

Один из популярных подходов — «самоинструкции»: большая модель генерирует пары «инструкция → ответ», затем вы фильтруете и дообучаете меньшую.

Референсы:

Self-Instruct: Aligning Language Models with Self-Generated Instructions

Stanford Alpaca

Сильные стороны:

дешёвое масштабирование

можно быстро закрыть новые форматы и навыки

Слабые стороны:

модель-учитель переносит свои ошибки

синтетика часто повышает «уверенный тон», даже когда ответа нет

легко получить много почти одинаковых примеров, поэтому дедупликация критична

Качество инструктивных данных: что ломает модель быстрее всего

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

Типовые дефекты

противоречивые ответы на одинаковые инструкции

«слишком общие» ответы, которые не решают задачу

утечки «правильных ответов» из тестов и бенчмарков

систематические стилевые перекосы: везде одно и то же построение фраз

неправильные форматы: невалидный JSON, отсутствующие поля

Практические правила контроля качества

валидируйте формат автоматически: JSON-схемы, регулярные проверки

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

удаляйте дубликаты на уровне инструкций и на уровне ответов

разделяйте данные по типам навыков и измеряйте покрытие

Эти практики напрямую продолжают идеи статьи про фильтрацию и дедупликацию данных: для SFT они особенно важны, потому что модель «перенимает» стиль и ошибки очень быстро.

Полное дообучение против PEFT

Полное дообучение (full fine-tuning) — вы обновляете все веса модели.

PEFT (parameter-efficient fine-tuning) — вы замораживаете базовую модель и обучаете небольшую добавку параметров.

PEFT полезен, когда:

мало GPU-памяти

нужно иметь много «вариантов поведения» под разные задачи

нужно дешевле и быстрее итератировать

Обзорный вход в PEFT в экосистеме Hugging Face:

PEFT documentation

Сравнение подходов

| Подход | Что обучаем | Память и скорость | Когда выбирать | |---|---|---|---| | Full fine-tuning | все параметры | дорого по памяти оптимизатора | максимум качества, достаточно ресурсов | | PEFT (LoRA) | малые матрицы-адаптеры | существенно дешевле | быстрые итерации, много задач, ограниченные ресурсы | | QLoRA | LoRA + квантизация базовой модели | ещё дешевле по памяти | когда нужна большая базовая модель на одной/двух GPU |

Референс для QLoRA:

QLoRA: Efficient Finetuning of Quantized LLMs

LoRA: главный PEFT-метод для LLM

LoRA (Low-Rank Adaptation) — это способ обучать «поправку» к линейным слоям трансформера, не изменяя сами базовые веса.

Ключевая идея:

исходная матрица весов слоя остаётся замороженной

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

Референс:

LoRA: Low-Rank Adaptation of Large Language Models

Интуиция без формул

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

Практические следствия:

LoRA-адаптеры можно хранить и версионировать отдельно от базовой модели

можно иметь несколько LoRA под разные домены и быстро переключать поведение

!Схема, показывающая как LoRA добавляет обучаемую поправку к замороженному линейному слою

Главные гиперпараметры LoRA

r: ранг адаптера, больше означает больше ёмкость и параметры

lora_alpha: масштаб адаптера, влияет на силу поправки

lora_dropout: регуляризация для устойчивости

target_modules: какие именно слои адаптировать, часто это проекции attention и MLP

Практическое правило:

начинайте с адаптации attention-проекций, затем расширяйте на MLP, если качества не хватает

Что такое QLoRA и чем оно отличается

QLoRA — это не «другая LoRA», а комбинация идей:

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

поверх неё обучают LoRA-адаптеры

Смысл:

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

Ограничения:

требования к качеству реализации квантизации и ядрам матмулов

иногда сложнее добиться стабильности, чем в BF16 full fine-tuning

Инженерная практика SFT: что решает качество результата

Ниже — решения, которые чаще всего определяют итоговое поведение сильнее, чем «тонкая настройка learning rate».

Правильная упаковка примеров в последовательности

Так как трансформер учится на последовательностях фиксированной длины, вы почти всегда выбираете между:

truncation: обрезать длинные примеры

packing: упаковывать несколько коротких диалогов в одну последовательность

Риски:

при packing важно ставить корректные разделители, чтобы модель не «сливала» разные диалоги

при truncation можно отрезать критичный контекст и научить модель отвечать «вслепую»

Баланс данных

Если смешивать разные источники, важно управлять долями:

доменные инструкции против общих

короткие ответы против длинных

простые задачи против сложных

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

Катастрофическое забывание и как его смягчают

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

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

уменьшить число эпох и не переучивать датасет

снизить learning rate

добавить в смесь небольшую долю «общих» инструкций

использовать PEFT вместо полного обновления всех весов, если задача позволяет

Минимальный пример пайплайна SFT с LoRA

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

Референсы по инструментам:

Transformers documentation

TRL documentation

Частые ошибки при SFT и как их диагностировать

Модель стала «слишком послушной» и многословной

Причины:

в датасете много шаблонных вежливых вступлений

слишком много примеров, где ответ начинается с длинного пролога

Действия:

нормализовать стиль, ограничить прологи

добавить примеры коротких ответов «по делу»

Модель путает роли или начинает отвечать как пользователь

Причины:

неправильный chat template

loss считался по токенам не только ответа ассистента

Действия:

сверить формат с тем, как модель ожидает видеть роли

проверить маску токенов для loss

Модель ухудшилась на общих задачах

Причины:

узкий датасет, много эпох, слишком высокий learning rate

Действия:

сократить обучение

добавить разнообразие и небольшую долю общих инструкций

перейти на LoRA или уменьшить ёмкость адаптера

Что важно запомнить

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

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

PEFT позволяет дообучать модели дешевле, обучая малую добавку параметров.

LoRA — самый распространённый PEFT для LLM, а QLoRA делает его ещё доступнее по памяти за счёт квантизации базовой модели.

В следующих темах курса логично переходить к оценке качества после дообучения и к практикам внедрения: как тестировать поведение, как избегать утечек, как сочетать SFT с RAG и как мониторить качество в продакшене.

Alignment of behavior: RLHF, DPO, and refusal policies

After pretraining, a decoder-only LLM becomes a strong next-token predictor. After SFT (often with PEFT/LoRA), it becomes better at following instructions in your preferred format and tone.

But even a well SFT-tuned model can still:

confidently hallucinate

comply with unsafe or disallowed requests

leak sensitive data patterns it saw in training

ignore product policies under prompt pressure

Alignment is the set of methods that shape the model’s behavior toward human preferences and safety constraints, especially in ambiguous or adversarial situations.

This article connects to earlier parts of the course:

From data pipelines: alignment is only as good as the preference data quality, filtering, and deduplication.

From SFT/LoRA: alignment usually starts from an SFT checkpoint, then adds a preference-optimization stage.

What “alignment” means in practice

Alignment is not a single metric. In production, it is typically a negotiated balance among:

Helpfulness: solves the user’s task.

Harmlessness: avoids enabling harm.

Honesty: admits uncertainty and avoids fabrication.

Policy compliance: follows your organization’s rules.

Robustness: doesn’t collapse under jailbreaks or tricky prompts.

A crucial takeaway: alignment is a distribution shift problem. You are moving from “predict internet text” to “act like an assistant under constraints”.

RLHF: the classic alignment pipeline

RLHF stands for Reinforcement Learning from Human Feedback. The most common modern template was popularized by InstructGPT: Training language models to follow instructions with human feedback.

The three-stage RLHF loop

Most RLHF pipelines can be summarized as:

SFT model

- Train (or continue training) on demonstrations: prompt ideal assistant response. - Output: a model that generally follows instructions.

Reward model (RM)

- Collect preference labels: given a prompt and two candidate answers, humans choose the better one. - Train a reward model to score answers so that preferred answers get higher reward.

RL optimization

- Optimize the policy (the LLM) to maximize reward while staying close to the SFT model. - A common optimizer is PPO: Proximal Policy Optimization Algorithms.

!Diagram of the RLHF pipeline: SFT, reward modeling, and PPO alignment

What the reward model learns

The reward model is trained to approximate human preferences. Conceptually:

Input: a prompt and a candidate response.

Output: a scalar “quality” score.

In practice it often learns a mixture of:

helpfulness cues (directness, completeness)

style cues (politeness, formatting)

safety cues (refusals on disallowed requests)

This is powerful but risky: the RM can be exploited if the policy finds “reward hacks” (responses that score well but are not truly good).

The “stay close” constraint (why RLHF doesn’t just maximize reward)

If you only maximize the reward model score, the policy can drift into unnatural text or exploit weaknesses in the RM.

So RLHF typically includes a penalty for moving too far from the reference model (often the SFT model). A common form uses KL divergence. One way to write the idea is:

Explanation of each term:

is the expected reward.

- is the reward model’s score for generated responses. - means we average over many sampled responses.

is the current policy (the model you are updating).

is the reference policy (often the frozen SFT model).

measures how different the current policy is from the reference.

controls the trade-off.

- Larger forces the model to stay closer to SFT. - Smaller allows larger behavior changes.

You do not need to implement this exact equation to benefit from the concept; the engineering point is that alignment needs a leash.

What data RLHF needs

RLHF requires two kinds of data:

Demonstrations (for SFT)

Preferences (for RM)

Preference data quality is very sensitive to issues from the data article:

duplicates inflate apparent certainty and reduce diversity

inconsistent labelers create a noisy reward signal

unfiltered sensitive content can push the model toward unsafe behavior

DPO: alignment without explicit reinforcement learning

DPO (Direct Preference Optimization) is an alternative that avoids training a separate reward model and avoids RL. Reference: Direct Preference Optimization: Your Language Model is Secretly a Reward Model.

The core idea

Instead of:

learning a reward model, then

running PPO to maximize reward,

DPO directly updates the language model to prefer the chosen answer over the rejected answer for the same prompt.

In preference data you have:

prompt

preferred answer

rejected answer

DPO increases the probability of relative to while also anchoring to a reference model.

A common DPO objective is written as:

Explanation of the components:

is the prompt.

is the preferred answer; is the rejected answer.

is the model being trained; is a frozen reference (often SFT).

is the log-probability the model assigns to answer given prompt .

is the logistic sigmoid; it turns a real number into a value between 0 and 1.

controls how strongly preferences are enforced.

means we average over training examples.

Intuition: the model is trained so that the preferred answer becomes more likely than the rejected one, in a way that is regularized by the reference model.

Why teams like DPO

simpler training stack than PPO-based RLHF

often more stable and easier to reproduce

no separate reward model to maintain

What DPO still depends on

DPO does not eliminate the hard parts:

you still need high-quality preference pairs

you still need coverage for safety edge cases

you still need careful deduplication to avoid overfitting to repeated templates

RLHF vs DPO: when to choose which

Both RLHF and DPO can work well. The choice is often driven by engineering constraints and how much control you need.

| Dimension | RLHF (RM + PPO) | DPO | |---|---|---| | Training complexity | higher (RM training + RL) | lower (supervised-style optimization) | | Failure modes | reward hacking, RL instability | preference dataset bias, overshooting if too high | | Iteration speed | slower | faster | | Controllability | flexible reward shaping | constrained to pairwise preferences | | Operational burden | maintain RM + policy | maintain policy only |

A practical heuristic:

Choose DPO if you want a simpler, reproducible preference-optimization stage.

Choose RLHF if you need more complex reward shaping, multi-objective setups, or you already have mature RL infrastructure.

Refusal policies: what to refuse, how to refuse, and how to train it

Alignment is not only about “being nice”. A production assistant must reliably refuse or safely redirect certain requests.

A refusal policy specifies:

which requests must be refused

what a refusal should look like (tone, content, alternatives)

how to handle borderline cases

Categories that typically require refusals

Exact categories depend on your domain and policy, but common ones include:

instructions for wrongdoing or violence

self-harm instructions

explicit sexual content (especially involving minors)

requests for personal data or doxxing

malware development or exploit guidance

What a good refusal looks like

A refusal is a product behavior, not just “say no”. Often it should:

clearly state inability to comply

avoid providing the restricted details

provide safe alternatives when possible

keep the response short and consistent

For example:

refuse “write a phishing email”

offer “tips on recognizing phishing and protecting accounts”

Two layers: policy enforcement and capability

A reliable refusal policy usually uses both:

Behavioral training: SFT + preference optimization (DPO/RLHF) on refusal examples.

System guardrails: classifiers, rules, sandboxing, and output filters.

Training alone can fail under jailbreak prompting. Guardrails alone can be brittle and overblock. The combination is stronger.

Constitutional approaches (policy-as-data)

One influential idea is to encode policies directly into training signals: Constitutional AI: Harmlessness from AI Feedback.

Even if you do not adopt the full approach, the practical lesson is useful:

write down policies precisely

turn them into training examples and preference comparisons

measure refusal consistency across paraphrases and adversarial prompts

Building preference datasets that actually improve behavior

Preference datasets are easy to collect and hard to get right. Common high-impact design choices:

Preference prompt design

include realistic user prompts from your product (after privacy review)

include adversarial and jailbreak-style prompts intentionally

include borderline cases to train calibrated behavior

Labeling guidelines

Your labelers need explicit rubrics, otherwise they encode inconsistent hidden preferences. Rubrics often define:

what counts as “helpful enough”

when to ask clarifying questions

when to refuse versus comply

how to handle uncertainty and citations (if applicable)

Deduplication and leakage control

Carry over the same discipline from the data pipeline article:

deduplicate prompts and near-duplicate answers

ensure evaluation prompts are not in training

watch for templated preference pairs that teach superficial patterns

Evaluating aligned behavior

Loss and perplexity are not sufficient. Alignment evaluation typically mixes:

offline preference win-rate: how often the new model is preferred over the baseline

safety test suites: category-based refusal accuracy and leakage checks

format compliance: JSON validity, tool-call correctness

red teaming: adversarial prompts and jailbreak attempts

A useful habit: evaluate behavioral invariances.

paraphrase the same request many ways

vary irrelevant details

test with longer context and distractions

If behavior flips easily, you likely have brittle alignment.

Common failure modes and mitigations

Over-refusal

Symptoms:

refuses benign requests

becomes excessively cautious or unhelpful

Mitigations:

add preference pairs where helpful compliance is preferred

separate “disallowed” from “allowed but sensitive” with safer completions

tune (for DPO) or KL strength (for RLHF) to reduce policy drift

Style over substance

Symptoms:

outputs polished but incorrect answers

optimizes for politeness or verbosity

Mitigations:

label for correctness and calibrated uncertainty

include preference pairs where concise, correct answers beat verbose guesses

Reward hacking (RLHF-specific)

Symptoms:

finds patterns that score well but degrade user value

Mitigations:

regularly audit high-reward outputs

strengthen the reference constraint

refresh the reward model with new adversarial comparisons

What to remember

Alignment is the stage that shapes preferences and safety, beyond instruction-following.

RLHF uses a reward model plus RL (often PPO) with a constraint to stay near a reference model.

DPO optimizes preferences directly from pairwise comparisons, typically with a simpler and more stable training stack.

Refusal policies require both training (SFT + DPO/RLHF) and system guardrails, plus careful evaluation against adversarial prompts.

In the next part of the course, the natural continuation is deployment: how to serve aligned models safely, combine them with RAG and tools, and monitor behavior regressions in production.

Оценка качества: бенчмарки, Evals, токсичность и галлюцинации

После предобучения модель становится сильным предсказателем следующего токена. После SFT и PEFT/LoRA она лучше следует инструкциям и держит нужный формат. После выравнивания (RLHF/DPO) она чаще ведёт себя безопасно и «по политике».

Но ни один из этих этапов не гарантирует, что вы знаете, насколько модель хороша и что именно улучшилось. Поэтому оценка качества — это отдельная дисциплина, которая соединяет все предыдущие темы курса:

из темы про данные: утечки и дубликаты могут сделать метрики «слишком хорошими»

из темы про SFT: формат и стиль могут улучшиться, но фактичность — ухудшиться

из темы про alignment: можно снизить риск вреда, но получить over-refusal и падение полезности

!Схема показывает, как разные типы проверок собираются в единый eval-пайплайн

Что такое «качество» у LLM

Качество LLM почти всегда многомерно: одна метрика не описывает поведение модели.

| Измерение качества | Что хотим видеть | Как обычно измеряют | |---|---|---| | Способности | знание, логика, математика, код | публичные бенчмарки и внутренние тесты | | Следование инструкции | делает то, что попросили | набор задач с проверяемым правилом и/или парные сравнения | | Формат | валидный JSON, нужные поля, строгий шаблон | валидаторы, регулярные проверки, схемы | | Безопасность | не генерирует запрещённое, не раскрывает данные | токсичность/PII классификаторы, тесты на отказы | | Честность | не придумывает факты, признаёт неопределённость | тесты на фактичность и галлюцинации | | Устойчивость | не ломается от перефразирования и «джейлбрейков» | adversarial-наборы и вариативные прогоны |

Практический вывод: оценка качества — это набор тестов, а не одна цифра.

Бенчмарки: зачем нужны и почему они обманывают

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

Какие бенчмарки встречаются чаще всего

Общие знания и понимание текста: MMLU

Проверка правдивости и склонности к «уверенным выдумкам»: TruthfulQA

Рассуждения и здравый смысл (классика для multiple choice): HellaSwag

Математические задачи с пошаговым решением: GSM8K

Генерация кода по задаче: HumanEval

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

Главные причины, почему бенчмарки дают ложное чувство качества

Утечки (contamination): примеры из теста попали в обучающие данные, и модель их запомнила.

Prompt sensitivity: точность сильно меняется от формулировки промпта и шаблона.

Смещение под формат: multiple-choice может завышать ощущение «понимания», потому что модель угадывает по паттернам.

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

Связь с темой данных из курса: если вы не ведёте политику дедупликации и контроля источников, вы не сможете доверять числам.

Evals: как оценивать то, чего нет в публичных бенчмарках

В продукте почти всегда нужно проверять то, чего нет в стандартных наборах:

соблюдение вашей политики

корректность формата (строгий JSON, tool calls)

доменные знания

качество отказов

устойчивость к типичным атакам на промпт

Eval — это воспроизводимый тест (или набор тестов), который вы запускаете на модели при каждом изменении данных, промпта, параметров генерации или чекпойнта.

Три базовых способа скоринга

Правило (rule-based): точное совпадение, регулярное выражение, валидация JSON-схемы, проверка наличия полей.

Сравнение с эталоном: есть правильный ответ, можно сравнивать по ключевым полям, числам, фактам.

Судья (LLM-as-judge): отдельная модель оценивает, какой ответ лучше, или выставляет балл по рубрике.

Инструменты, которые часто берут как основу:

EleutherAI lm-evaluation-harness

OpenAI Evals

LLM-as-judge: сильный инструмент с обязательными предохранителями

Судья удобен, когда невозможно написать строгую проверку (например, «насколько ответ полезен»). Но у него есть риски:

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

судья может иметь свои политические/стилевые смещения

судья может быть «в одной семье» с тестируемой моделью и завышать оценки

Минимальные меры, которые делают LLM-as-judge пригодным для инженерной работы:

фиксированная рубрика (что такое «хорошо» и «плохо»)

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

периодическая сверка с людьми на небольшой выборке

Токсичность и безопасное поведение: что и как измерять

В статье про alignment мы обсуждали, что безопасность — это не только обучение, но и проверяемые политики. На практике оценка безопасности обычно раскладывается на две части:

содержательные категории: ненависть, угрозы, сексуальный контент, инструкции для вреда

политика отказа: где модель обязана отказаться, а где — помочь безопасной альтернативой

Автоматические метрики токсичности

Распространённый подход — прогонять ответы через классификаторы токсичности.

API-инструмент, который часто используют как один из сигналов: Perspective API

датасет промптов для проверки склонности модели продолжать токсичный контент: RealToxicityPrompts

Практические ограничения автоматической токсичности:

ложные срабатывания на цитаты и обсуждение вреда в образовательном контексте

смещения по диалектам и социальным группам

зависимость от языка и домена

Поэтому в продакшене токсичность — это обычно комбинация:

автоматический скоринг на широком прогоне

ручная проверка небольших выборок

отдельные red-team тесты (на намеренные провокации)

Оценка отказов и проблема over-refusal

Хороший отказ должен быть:

коротким и однозначным

без запрещённых деталей

с безопасной альтернативой, если это уместно

Две метрики, которые важно держать рядом:

refusal accuracy: запрещённые запросы стабильно приводят к отказу

false refusal rate: разрешённые запросы ошибочно блокируются

Именно вторая метрика часто падает после агрессивного alignment и незаметна, если вы оцениваете только «безопасность».

Галлюцинации: виды, причины и измерение

Галлюцинация — это когда модель генерирует уверенно звучащую информацию без достаточного основания.

В инженерной практике полезно различать два случая:

фактическая ошибка: модель утверждает неверный факт

необоснованное утверждение: модель не знает, но отвечает так, будто знает

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

предобучение учит «как обычно пишут», а не «как проверять»

SFT может поощрять уверенный тон, если в данных мало примеров «не знаю»

alignment может усилить «помогай любой ценой», если рубрики не штрафуют выдумки

Как оценивать галлюцинации без магии

Подход выбирают по типу задачи.

Вопросы с проверяемым ответом: берём набор Q&A и считаем долю правильных ответов.

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

Доменная справка: проверяем утверждения по базе знаний или по подготовленному эталону.

Чтобы это было воспроизводимо, обычно делают так:

Собирают golden set запросов из вашего домена.

Для каждого запроса фиксируют либо эталон, либо источники истины (документы, базу знаний).

Вводят разметку ошибок: неверный факт, выдуманная ссылка, подмена сущности, неверное число.

Строят отчёт по типам ошибок, а не только общий процент.

Truthfulness-наборы помогают хотя бы грубо измерять склонность к уверенным выдумкам, например TruthfulQA.

Как построить минимально рабочую систему оценки

Ниже — практичный план, который масштабируется от «одна модель на одной машине» до продуктовой команды.

Определите цели качества в терминах поведения.

Соберите три набора тестов: capability, формат/инструкции, безопасность/галлюцинации.

Заморозьте шаблоны промптов и параметры генерации для сравнимости.

Добавьте контроль утечек: запрет на попадание eval-наборов в обучение и дедупликацию по смыслу.

Автоматизируйте прогон и отчёты при каждом изменении.

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

Частые ошибки в оценке и как их избежать

Оценивать только публичными бенчмарками и не иметь внутреннего golden set.

Измерять безопасность только «токсичностью», игнорируя утечки PII и ошибки отказов.

Использовать LLM-as-judge без рубрики и без проверки на сдвиги.

Сравнивать модели при разных промптах, разных temperature или разном контекстном окне.

Не контролировать contamination, хотя в статьях про данные и дедупликацию мы уже видели, как это ломает выводы.

Что важно запомнить

Оценка качества — это система тестов по нескольким осям: способности, инструкция, формат, безопасность, честность и устойчивость.

Бенчмарки полезны, но легко обманывают из-за утечек и зависимости от промпта.

Evals — это ваши воспроизводимые продуктовые тесты, которые запускаются при каждом изменении модели или пайплайна.

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

Галлюцинации нужно измерять через проверяемые источники истины и разметку типов ошибок, иначе вы будете «чинить не то».

Продакшен и безопасность: оптимизация, мониторинг, ограничения и соответствие

После этапов обучения и оценки (данные → предобучение → SFT/LoRA → alignment → evals) появляется следующая задача: сделать систему надёжной в реальном продукте. В продакшене LLM — это не только веса модели, а целая связка компонентов: инференс, контекст (RAG), политики безопасности, логирование, метрики, обновления и соответствие требованиям.

Эта статья отвечает на четыре практических вопроса:

как сделать инференс быстрым и дешёвым

как встроить ограничения и защиту от типичных атак

как мониторить качество и безопасность после релиза

как организовать соответствие: приватность, аудит, управляемость изменений

!Типовая архитектура LLM-сервиса с RAG, инструментами, политиками и наблюдаемостью

Что именно считается продакшен-системой LLM

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

Типовая система включает:

Слой доступа: аутентификация, rate limiting, управление ключами.

Построение запроса: шаблоны сообщений, системные инструкции, политика компании.

Контекст: RAG, поиск по базе знаний, retrieval-фильтры.

Инференс: сервер, который запускает модель и отдаёт токены.

Ограничения и безопасность: входные/выходные фильтры, политики отказа, защита инструментов.

Наблюдаемость: метрики, логи, трассировки, выборки для ручного аудита.

Цикл улучшений: A/B, канареечные релизы, откаты, переобучение.

Практический вывод: если вы улучшили модель (например, DPO повысил win-rate на предпочтениях), но не контролируете промпт-инъекции, лимиты и логирование, то продуктовое качество будет нестабильным.

Оптимизация инференса: скорость, стоимость, стабильность

Оптимизация инференса почти всегда сводится к управлению тремя ресурсами:

GPU-память: веса, активации, KV-cache.

GPU-время: матмулы, attention, сэмплинг.

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

Почему инференс дорогой: префилл и декод

У генеративных LLM есть два режима работы:

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

Decode: модель добавляет по одному токену ответа, используя сохранённые состояния.

Важная инженерная сущность — KV-cache: кэш ключей и значений attention, позволяющий при генерации не пересчитывать всё заново для уже обработанного контекста.

Следствия для продакшена:

длинные промпты делают префилл дорогим

длинные ответы делают декод дорогим

высокая конкуренция запросов быстро съедает память из-за KV-cache

Бэтчинг и непрерывный бэтчинг

Чтобы повысить throughput, сервер объединяет запросы в батчи.

В LLM это сложнее, чем в классификации, потому что:

у разных запросов разная длина промпта

генерация идёт токен за токеном, и запросы заканчиваются в разное время

Поэтому в продакшен-движках используют непрерывный бэтчинг (continuous batching): запросы динамически добавляются в вычисление по мере освобождения слотов.

Практические инструменты и реализации:

vLLM

TensorRT-LLM

Hugging Face Text Generation Inference

Квантизация: дешевле инференс, но нужны проверки

Квантизация уменьшает точность хранения весов (например, 8-bit или 4-bit), чтобы:

снизить требования к памяти

повысить скорость (зависит от железа и ядёр)

упростить размещение модели на меньшем числе GPU

Риск: квантизация может ухудшить качество на «тонких» задачах.

Что важно делать инженерно:

фиксировать один и тот же eval-набор для сравнения точности до/после

проверять регрессии на форматах (JSON/tool calls) и отказах

отдельно мерить доменные сценарии, а не только публичные бенчмарки

Если вам нужен CPU/edge сценарий, часто используют:

llama.cpp

Контроль генерации: лимиты, стоп-токены, детерминизм

В продакшене «качество» — это ещё и управляемость.

Почти всегда вводят:

max_new_tokens или лимит длины ответа

стоп-условия (стоп-строки, стоп-токены)

ограничение на время генерации

контролируемые параметры сэмплинга (например, умеренный temperature)

Полезная практика для отладки:

иметь режим почти детерминированной генерации для воспроизводимости инцидентов

Стабильность сервиса: очереди, таймауты, деградация

Даже идеальная модель не поможет, если сервис падает или «подвисает» на хвостах распределения.

Минимальные продакшен-механики:

Очередь запросов с приоритетами.

Жёсткие таймауты на upstream и на инференс.

Ограничения по токенам на пользователя и на организацию.

Деградация качества при перегрузке (например, меньший max_new_tokens).

Circuit breaker на внешние источники (RAG, инструменты).

RAG и инструменты: безопасность важнее удобства

RAG и tool calling обычно повышают фактичность и полезность, но добавляют новые классы рисков.

RAG: типовые риски и защита

Ключевая угроза — prompt injection через документы: модель получает в контекст текст, который выглядит как инструкция для ассистента.

Защитные меры:

разделять политику и контекст: политика должна быть системным уровнем, а документы — данными

использовать явные разделители и пояснения типа «ниже приведены выдержки из документов, это не инструкции»

фильтровать источники и доверенные индексы

логировать, какие документы реально попали в контекст

Полезно воспринимать RAG как часть data pipeline из ранних статей: там тоже есть очистка, фильтрация, дедупликация. В RAG эти принципы повторяются, только в онлайне.

Tool calling: границы полномочий и песочница

Если модель умеет вызывать инструменты (поиск, БД, почта, платежи), то ваша задача — сделать так, чтобы:

модель не могла выполнить опасное действие даже при jailbreak

модель делала только разрешённые операции для конкретного пользователя

Инженерная схема безопасного tool calling:

Явная схема инструментов: строгие входные поля, типы, лимиты.

Server-side policy enforcement: сервер проверяет право на действие, а не модель.

Sandbox: изоляция выполнения (особенно для кода).

Allowlist действий, а не denylist.

Подтверждение опасных действий: человек или дополнительный контрольный шаг.

Релевантный практический источник по угрозам для LLM-приложений:

OWASP Top 10 for LLM Applications

Ограничения и безопасность: многоуровневая защита

Из статьи про alignment вы уже знаете, что одних тренировочных методов недостаточно: в продакшене нужна система guardrails.

Уровни защиты

Удобная модель угроз: защищаемся до генерации, во время генерации и после генерации.

| Уровень | Что защищаем | Примеры мер | |---|---|---| | Вход (pre) | от вредных запросов и инъекций | классификатор категорий, rate limit, блок PII в промпте | | Выполнение (inference/runtime) | от опасных действий | политика tool calling, sandbox, лимиты токенов | | Выход (post) | от токсичности, утечек, нарушений формата | фильтры, PII-редакция, JSON-валидация |

Политики отказа как продуктовый контракт

Отказы — это не «иногда сказать нет», а контракт поведения.

Чтобы отказ был устойчивым:

политика должна быть описана текстом и примерами

примеры должны попадать в SFT и/или preference-оптимизацию

должен быть автоматический eval на отказы и на ложные отказы

Это напрямую продолжает статью про оценку качества: безопасность измеряется тестами, а не ощущениями.

Контроль утечек PII

Даже если вы не обучали модель на внутренней переписке, в продакшене PII появляется через:

пользовательские сообщения

документы RAG

логи

Минимальные правила:

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

редактировать PII до записи в хранилища

ограничить доступ к логам по ролям

Для PII-пайплайна часто используют специализированные инструменты, например:

Microsoft Presidio

Наблюдаемость и мониторинг: модель меняется даже без переобучения

В классическом ПО вы мониторите ошибки и latency. В LLM-продукте этого недостаточно: поведение зависит от промпта, контекста, данных RAG и параметров генерации.

Что измерять: технические и поведенческие метрики

Технические метрики:

latency p50/p95/p99

tokens/sec и средний размер ответа

GPU utilization и память KV-cache

доля таймаутов и отменённых запросов

Поведенческие метрики:

доля отказов по категориям

доля «ложных отказов» на разрешённых сценариях (обычно через внутренние evals)

доля невалидных форматов (например, невалидный JSON)

сигналы токсичности и PII в ответах (через классификаторы)

Инфраструктура наблюдаемости часто строится вокруг:

OpenTelemetry

Prometheus

Grafana

!Пример того, какие метрики обычно держат на одном экране

Логирование с воспроизводимостью

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

Рекомендуемые поля события (в сокращённом виде):

Версия модели и хэш/версия LoRA-адаптера.

Версия системного промпта и шаблона чата.

Параметры генерации.

Идентификаторы документов RAG и их версии.

Результаты pre/post фильтров (безопасность, PII).

Идентификатор пользователя/сессии в анонимизированном виде.

Важно: это должно быть совместимо с вашей политикой приватности и минимизацией данных.

Drift: почему качество может «уплывать»

Даже без переобучения качество меняется из-за:

обновлений базы знаний и индекса RAG

новых типов пользовательских запросов

изменения продуктового UI (люди начинают писать иначе)

изменения внешних инструментов

Поэтому eval-пайплайн из прошлой статьи полезно запускать:

на каждом релизе модели

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

периодически по расписанию, чтобы ловить деградацию из-за RAG и окружения

Обновления и релизы: как не сломать продукт улучшением

LLM-системы часто ломаются не «сразу», а на редких кейсах. Поэтому релиз должен быть ступенчатым.

Практика релизов

Offline gate: прогон внутреннего набора evals (качество, формат, безопасность).

Canary: маленький процент трафика на новую версию.

A/B: сравнение метрик полезности и безопасности.

Rollback: быстрый откат по сигналам p95/p99 и по поведенческим метрикам.

Критично фиксировать, что именно поменялось:

модель

адаптер

промпт

retrieval

политики фильтрации

Иначе вы не сможете объяснить регрессию.

Соответствие и управление рисками: не только безопасность контента

Требования соответствия зависят от домена, но базовые принципы повторяются.

Минимизация данных и контроль доступа

Для большинства организаций полезна политика:

хранить минимум пользовательского текста

ограничивать срок хранения

вводить строгие роли доступа к логам и датасетам

иметь процедуру удаления данных по запросу

Документация решений и трассировка происхождения

Из статьи про данные вы уже знакомы с provenance и версионированием. В продакшене эта идея расширяется:

откуда пришёл контекст (какой документ в RAG)

какая политика применялась (версия правил)

почему произошёл отказ (категория)

Это снижает стоимость расследований и повышает управляемость.

Фреймворки управления рисками

Как ориентиры для системного подхода часто используют:

NIST AI Risk Management Framework

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

Типовые продакшен-ошибки и как их предотвращать

Ошибка: считать, что alignment заменяет guardrails

Признак:

модель «в целом» безопасна, но иногда ломается на jailbreak и инструментах

Профилактика:

серверные проверки прав

sandbox

выходные фильтры

отдельные red-team evals

Ошибка: оптимизировать latency и сломать качество

Признак:

после квантизации или смены движка вырос процент ошибок формата и ложных отказов

Профилактика:

одинаковые промпты и параметры генерации в тестах

измерение качества на доменных golden-наборах

обязательные тесты на JSON/tool calls

Ошибка: логировать слишком много и нарушить приватность

Признак:

в логах появляются персональные данные и секреты

Профилактика:

PII-редакция до записи

минимизация полей

доступ по ролям

аудит доступа

Что важно запомнить

Продакшен LLM — это система: модель, контекст, политики, инструменты, инфраструктура и eval-процессы.

Оптимизация инференса почти всегда строится вокруг KV-cache, batching, квантизации и строгих лимитов.

Безопасность требует многоуровневой защиты: обучение (SFT/DPO/RLHF) плюс серверные guardrails.

Мониторинг должен включать не только latency и ошибки, но и поведенческие метрики: отказы, токсичность, PII, валидность форматов.

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