Как разработчику быстро углубиться в тему LLM? Часть 1

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

1. Токенизация и эмбеддинги
2. Механизмы внимания
3. Архитектуры трансформеров
4. Популярные архитектуры LLM
5. Проблемы и решения при работе с LLM
6. Обучение моделей
7. Эффективный инференс и деплой

Звучит, как план, правда? ☺️

1. Токенизация и эмбеддинги

Современные большие языковые модели работают на основе векторных представлений и механизма внимания, заложенного в архитектуру трансформеров. Первым шагом в обработке текста является токенизация — разбиение входной строки на токены, которые могут представлять собой слова, части слов или отдельные символы. Компиляторщиков и разработчиков средств анализа кода этот термин может слегка смутить, т.к. в NLP токенами не всегда принято считать то, что является ими в формальных языках. На практике широко используется subword-токенизация, например Byte-Pair Encoding: так, слово unhappiness может быть преобразовано в последовательность «un», «happi» и «ness». Такой подход уменьшает размер словаря и позволяет эффективно работать с редкими или ранее невстречавшимися словами.

Каждый токен получает уникальный идентификатор, по которому модель извлекает его вектор из матрицы эмбеддингов. Эмбеддинг — это высокоразмерный числовой вектор, отображающий семантику токена. После токенизации каждый элемент текста фактически превращается в набор чисел, отражающих его смысловые связи. Чем ближе по смыслу токену друг к другу, тем меньшее расстояние между ними в векторном пространстве. Например, вектор для слова apple окажется ближе к fruit, чем к car.

У моделей типа GPT-3 таблица эмбеддингов может быть очень большой: при словаре ~50 000 токенов и размерности эмбеддинга ~12 288 получается матрица порядка 50 000 × 12 288. Однако в современных крупных MoE-моделях, за счет sparse-архитектуры, эти оценки кратно меньше: 2k для 30B, 4k для 235B, например.

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

Познакомиться с этой темой ближе позволит статья «Глубокое погружение в токенизацию», для более глубокого погружения можно упороться в видеолекции (первая, вторая) от ФКН ВШЭ, или от Стэндфорда (выборочно, из первых 6 лекций), если «глубинное обучение» режет слух, и хочется привычного «deep learning».

Для специализированных задач типа анализа исходного кода, существуют отдельные модели эмбеддингов. Так, jina-embeddings-v2-base-code поддерживает английский язык и около 30 языков программирования, способна обрабатывать последовательности до 8192 токенов и оптимизирована для семантического поиска по коду. В таких моделях принципы токенизации и построения эмбеддингов остаются теми же, но словарь и обучающие данные адаптированы к структурам и паттернам программного кода.

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

• code2vec / code2seq: Path-Attention поверх AST
• GraphCodeBERT: Transformer поверх DFG + элементы GNN
• CuBERT: Transformer поверх фич CFG
• Devign: GNN поверх AST+CFG+DFG
• Code T5 / Code T5+: Transformer поверх AST-токенов

Ну и куда же без изучения тематической awesome-подборки, на правах домашнего задания 🤓

Часть 2.

#LLM #гайд