Б.2 Распределённый тренинг

Что это

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

Зачем

Обучить GPT-4 на одной видеокарте невозможно - не хватит памяти. Распределённый тренинг решает две проблемы: как разместить модель (она не влезает на один GPU) и как ускорить обучение (сотни GPU работают параллельно).

Ключевые технологии

FSDP (Fully Sharded Data Parallel), DeepSpeed (библиотека Microsoft), ZeRO-3 (разделение параметров, градиентов и оптимизатора), параллелизм по данным (data parallelism), по слоям (pipeline parallelism), по тензорам (tensor parallelism), многомашинные кластеры (multi-node).

Для кого

Для тех, кто собирается обучать большие модели с нуля (единицы). 99% инженеров этого не делают, но понимать принципы полезно, чтобы оценивать затраты и сроки.

Проблема, которую решает распределённый тренинг

Модель на 70 миллиардов параметров в 16-битной точности весит 140 гигабайт. Это больше, чем память даже самой дорогой видеокарты (H100 - 80 GB). Один GPU не может ни загрузить веса, ни тем более обучать модель. Нужно распределять модель между несколькими GPU.

Три типа параллелизма

Параллелизм по данным - копия модели на каждом GPU, каждый обрабатывает свою порцию данных, потом градиенты усредняются. Параллелизм по слоям - слои модели распределены по разным GPU (например, GPU1 отвечает за слои 1–10, GPU2 за 11–20). Тензорный параллелизм - один слой разрезается на части и считается на разных GPU одновременно. В реальных тренировках используют комбинацию всех трёх.

ZeRO и DeepSpeed

Microsoft придумала ZeRO - метод, который не копирует модель целиком на каждый GPU, а распределяет веса, градиенты и состояние оптимизатора между устройствами. ZeRO-3 - максимальный уровень, где всё распределено. DeepSpeed - библиотека, которая реализует ZeRO и добавляет ещё десятки оптимизаций.

Когда это нужно вам

Если вы не Google, OpenAI или Яндекс - вы почти наверняка не будете тренировать модель с нуля. Но распределённый тренинг нужен для дообучения больших моделей (70B+), когда даже одна эпоха на одном GPU заняла бы месяцы. Для 7–13 миллиардных моделей хватит одного GPU с достаточной памятью.

Итак, мы можем сжать модель и даже обучить её на кластере.

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

Нужен механизм, который позволит модели «заглядывать» во внешние знания на лету.

Это RAG (Retrieval-Augmented Generation) - экзамен по открытой книге. 80% промышленных LLM-приложений строятся именно вокруг RAG. Разберём, как нарезать документы, искать похожие и не давать модели галлюцинировать.

Б.3 Системы RAG (Retrieval-Augmented Generation)

Что это

Архитектура, при которой модель сначала ищет релевантную информацию во внешней базе знаний (векторной БД), а затем генерирует ответ на основе найденного.

Зачем

LLM знает только то, что было в обучающих данных (устарело, нет частной информации). RAG позволяет модели отвечать на вопросы по вашим документам, базе знаний, внутренней документации - без дообучения.

Ключевые компоненты

Разбивка документов на чанки (chunking), эмбеддинг-модели, векторные базы данных (Chroma, pgvector, Pinecone), ранжирование результатов (reranking), гибридный поиск (векторный + ключевые слова), Graph RAG (учёт связей между сущностями).

Для кого:

Для 80% промышленных LLM-приложений - чат-боты по документам, поддержка клиентов, аналитика по внутренним данным.

Что такое RAG и зачем он нужен

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

Основные компоненты

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

Гибридный поиск

Чистый векторный поиск хорош для поиска по смыслу («документы про кофе»), но плох для точных терминов («договор №АС-12/45»). Гибридный поиск добавляет к векторам классический текстовый поиск по ключевым словам (BM25) и объединяет результаты. Это стандарт для серьёзных RAG-систем.

Проблемы и решения

Если поиск нашёл не те документы, модель даст неверный ответ. Если документы есть, но модель их неправильно интерпретирует - тоже проблема. Поэтому добавляют reranking: после поиска отбирается не 10 лучших чанков, а 50, но затем специальная модель-кросс-энкодер переранжирует их, оставляя самые релевантные. И всегда ставят порог уверенности: если максимальное сходство ниже 0.7, модель должна сказать «не знаю».

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

Промпт - это не просто «вопрос», это код на естественном языке. И у него есть свои синтаксис, отладка и лучшие практики. Без хорошего промпта даже самая умная модель с RAG будет выдавать неструктурированный, непредсказуемый мусор. А в продакшене нам нужны JSON, конкретные поля, единый тон общения. Переходим к промпт-инжинирингу - от анатомии промпта до структурированных выходов.