Архитектура LLM. Часть 1

Долго не появлялся на своем же канале. Но не без причины – много работал!

В частности, работал с несколькими ИИ стартапами. Делюсь своими практическими наблюдениями по архитектуре LLM.

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

Зачем нужен такой анализ? — чтобы знать, из чего модель состоит, какие элементы являются наиболее ценными и как их можно охранять!

Если у вас был похожий опыт – обязательно делитесь, обсудим!

Архитектура LLM.

1️⃣ Программный код. Включает следующие элементы:

➖ Базовая логика работы – инструкции по сборке, запуску и взаимодействию с моделью.

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

➖Архитектура модели. Это как чертёж нейросети. Своего рода "структура мозга ИИ", в которой указано, как информация обрабатывается внутри. Она определяет (1) из каких слоёв состоит модель (входной, скрытые, выходной), (2) в каком порядке и как они соединены, (3) какие применяются функции и приёмы (например, внимание, нормализация, пулы), (4) сколько параметров у каждого слоя и как они взаимодействуют.

Может быть указана как в коде, так и в конфигурационном файле.

➖Интерфейс/API. Способ дать команду ИИ (способ взаимодействия).

➖Логика инференса / постобработки – алгоритм отбора «наилучшего» ответа, нормализация значений, фильтрация (например, токсичных ответов).

2️⃣ Конфигурация модели или конфигурационный файл (json).

Это описание архитектуры модели и настроек обучения. Например, 12 слоёв, в каждом 768 нейронов, использование attention, применение GELU-активации.

3️⃣ Токенизатор (json). Это, по сути, словарь со всеми словами, которые знает модель и их переводом в токены.

4️⃣ Веса модели (машинный, бинарный, нечитабельный файл с миллиардами весов). Хранятся в формате .bin, .pt, .ckpt, .h5. Просто миллиарды значений по типу [0.122, -0.987, ...]

5️⃣ Сопутствующие элементы.

➖Обучающие данные (training data). Не входят напрямую в модель.

➖Служебные файлы для запуска/развёртывания (окружение запуска, скрипты запуска, endpoint-конфиги).

➖Метаданные модели (model metadata). Служебная информация о модели: кто автор, версия, дата сборки и т. д

➖Контрольные выборки / тесты (evaluation sets). Наборы данных, на которых проверяется качество модели.

➖Инструкции по способу обучения модели на данных.

Архитектура LLM. Часть 2. Юридический аспект

Из описания выше можно заключить, что ядро любой LLM – это программа + базы данных.

И вроде бы дальше все понятно. С ПО – согласен, но с базами давайте разбираться.

В России наиболее релевантным режимом охраны для таких баз является право изготовителя базы данных (как объекта смежного права).

Есть небольшие вопросы по применимости этого правового режима. Но в России таких вопросов намного меньше. Во многом – благодаря позиции СИПа по доктрине побочного продукта / spin off (подробнее о деле ВКонтакте v. Дабл Дата можете почитать у Романа Бузько).

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

Так, в большом количестве юрисдикций попросту нет такой же охраны баз данных, как у нас по смежному праву. А где есть (например, sui gerenis в ЕС), охраноспособность таких баз данных под вопросом, в том числе из-за доктрины spin off (со ссылками на практику можно почитать здесь).

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

Поэтому в индустрии этому предпочитают комбинацию (наряду с ПО):
🔘 ноу-хау
➕ механизмы договорного права
➕ технические ограничения

❇️ P.s Я здесь написал про LLM, но это слишком узкий пример (так как мало кто занимается разработкой LLM, особенно в России).

Но указанная логика применима и к узкоспециализированным ИИ системам, о чем я расскажу в следующем посте.

Архитектура LLM. Часть 3. Узкоспециализированные ИИ системы

Вообще создание узкоспециализированных ИИ систем на базе чужих LLM моделей (GPT, deepseek, gemini и др.) – очень распространенная практика.

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

Не даром закон ЕС об ИИ прямо разграничил регулирование моделей и систем (подробнее в нашем обзоре).

Бизнесово существуют разные способы структурирования:

1⃣ Prompt Engineering (поверхностный уровень). Компания создаёт систему промптов, шаблонов, инструкций, которые направляют ответы модели, добавляют контекст.

Это сложно назвать системой поверх модели. Скорее просто вам помогают с промптами.

2⃣ Fine-tuning (дообучение). Компания берёт готовую базовую модель и дотренивает её на своих данных (юридических, медицинских, финансовых и т.д). Веса модели слегка меняются → модель адаптируется к узкой задаче.

3⃣ Adapter (лёгкая настройка). Добавляется маленький модуль (адаптер) поверх модели, который был обучен на узких данных. Адаптер "живёт" внутри модели, но параметры самой модели не переписываются, но поверх них подгружаются веса адаптера, которые влияют на результат.

4⃣ Custom pipeline (надстройка над моделью). Тут есть несколько вариантов, в том числе RAG построен на этом, но базово: сама модель вообще не трогается (ни веса, ни архитектура), вокруг неё строится система управления запросами:

🔹 подготавливает промпт,

🔹 решает, когда вызвать модель,

🔹 обрабатывает её ответ (проверяет, фильтрует, дополняет данными)

Иногда используется сразу несколько моделей + классические алгоритмы.

Что это означает?

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

Поэтому описание выше по отношению к LLM применимо и тут.

Digital Digest Q2: новый бренд — неизменное качество

Мы с командой традиционно раз в квартал выпускаем дайджест с главными изменениями в регулировании цифры.

Выпускаем наш очередной дайджест за 2 квартал, и в этот раз – под новым брендом!

Как вы могли слышать, в августе SEAMLESS Legal (преемник CMS Russia) завершила реструктуризацию.

Группа партнёров и советников в Москве продолжила работу в России и за её пределами под брендом SL LEGAL (писали, например, тут).

Я также продолжаю свою работу в SL LEGAL в качестве старшего юриста и со-руководителя практики интеллектуальной собственности и цифрового права.

И мне особенно приятно представить наш первый дайджест под новым брендом. Скачать его можно по ссылке.

Архитектура LLM. Часть 4. Альтернативная квалификация.

В противовес описанной выше правовой квалификации существует альтернативная.

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

У обеих позиций есть свои плюсы и минусы (некоторые из них мы обсудили в комментариях к одному из постов).

⭕ Один из основных недостатков, это историческое понимание данных (в составе ПО). Традиционно к данным относились встроенные константы и параметры, структуры данных, метаданные и др. Масштабные и сложные файлы весов LLM "небесшовно" вписываются в это устоявшееся определение.

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

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

✅ Веса модели отличаются от классических баз данных.

✅ Веса модели могут быть интерпретированы как масштабные конфигурационные данные или "параметры программы", т.е описаны как составной элемент программы, без которой она не будет работать и теряет свой смысл.

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

В будущем, если/когда на рынке сформируется устойчивый самостоятельный оборот весов моделей как независимого актива, это, безусловно, может потребовать точечных изменений в законодательстве de lege ferenda.

Но в текущих реалиях такие изменения выглядели бы преждевременными. Пока квалификация LLM как единого программного комплекса остается наиболее практичной и удобной.

База знаний по регулированию ИИ

Мы с командой раз в квартал выпускаем дайджест по цифровому праву.

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

И я подумал, а почему бы не поделиться этой базой с вами. В удобном виде, только ИИ.

Если чего-то не хватает - напишите мне. Ведь чем полнее база, тем ценнее она для всех нас!

Персональные данные и Искусственный интеллект

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

Но вот тут хотел сделать исключение, и поделиться с вами презентацией с моего сегодняшнего выступления в МГИМО по ПД.

Решил сделать исключение, потому что рассказываю там о ПД при использовании ИИ, так что приемлемо😁

На самом деле содержание презентации может разниться в зависимости от того, кого мы защищаем и чьи интересы отстаиваем.

Я не вижу смысла рассказывать об этом со стороны поставщика модели ИИ (мало кому актуально), поэтому пишу с т.з. пользователя (скорее компании, но в части может быть применимо и для физ. лиц).

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

Вот к таким выводам я пришел в завершение презентации:

1️⃣ Поставщики ИИ систем (моделей) могут собирать персональные данные.

2️⃣ Поставщики ИИ моделей зачастую могут и будут использовать запросы и результаты генераций для обучения модели.

3️⃣ Есть инструменты, которые уменьшают реальный риск компрометации данных.

4️⃣ Но факт остается фактом – в определенных случаях персональные данные все-таки можно извлечь из ИИ.

5️⃣ Поэтому важно проверять свое использование ИИ систем (моделей) и соответствие требованиям законодательства.

6️⃣ И внедрять механизмы минимизации рисков.

Нейроюрист

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

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

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

1⃣ Анализ документов

Нейроюрист для анализа документов использует RAG (см. картинку выше) - так же, как, например, NotebookLM. Это даёт мне возможность искать нужную информацию по одному или нескольким документам, не боясь галлюцинаций.

В любом другом случае я бы просто продолжил использовать NotebookLM. Но появление Нейроюриста влияет на один из факторов моего выбора ИИ – риски. Зарубежные решения вызывают у меня больше вопросов, а с отечественными, кажется, можно договориться (они даже онпрем вариант предусматривают).

2⃣ Поиск по практике

Тот же RAG позволяет Нейроюристу при ответе на вопросы ссылаться на судебную практику, а также учитывать иерархию источников российского права.

Там много нюансов и встречаются ошибки. Но я использую этот инструмент не для того, чтобы ИИ сделал работу за меня, а чтобы он дал мне возможность "подумать об него".

И в то время как другие модели, скорее всего, не найдут практику и сгаллюцинируют ответ, здесь у меня есть реальная возможность её найти (хоть и с необходимостью перепроверки).

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

Попробуйте сами — там 20 бесплатных запросов в месяц.

Обучение ИИ на охраняемых материалах. Часть 1. Введение

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

Вот, не закрываю.

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

➡Через обучающий датасет (который создается на основании чужого IP и, скорее всего, не удаляется после обучения модели, ибо существует дрифт данных и концепции, про который можно почитать тут).

➡Через саму модель, которая в своих параметрах может «сохранять» чужие объекты или их охраняемые элементы.

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

С моделью, как будто, всё должно быть проще, но отнюдь. Вот что об этом пишут в материале Бюро авторского права США и в исследовании по заказу Европейского парламента (обобщил на свой лад):

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

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

Как и в случае с файлами (например, MP3 или JPEG), произведение не обязательно должно быть напрямую «видимым» в весах модели — достаточно, чтобы его можно было извлечь и воспроизвести с помощью техники (в данном случае, запуска модели).

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

Обучение ИИ на охраняемых материалах. Часть 2. Аргументы ПРОТИВ

Мы остановились на том, что ИИ модель и обучающий датасет могут нарушать права на чужую IP.

Что в этой части можно сказать?

В России по поводу обучения ИИ и его правомерности "мало что сказано и сделано".

Поэтому для понимания вопроса и возможных развилок приходится обращаться к зарубежному опыту. Обычно в этом плане выделяют США, Европу и Японию:

1⃣ В США есть fair use (исключение, допускающее использование чужого IP без согласия правообладателя), и оно может покрывать обучение ИИ.

2⃣ В Европе есть своя версия исключений - Text and Data Mining.

3⃣ В Японии обучение считается Non-Enjoyment use и не подпадает под монополию правообладателя (то есть не является использованием в юридическом понимании).

Но, как говорится, есть нюанс. А юристам важно знать нюансы.

✳ Fair use (США)

Fair use - это (упрощенно) американская версия исключений из монополии правообладателя.

У Fair use есть критерии (факторы), а у них - подкритерии. Одним из подкритериев является критерий трансформативности (видоизменяет ли новое произведение первое с новым выражением, смыслом или посылом).

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

По мнению Бюро авторского права США, обучение модели GenAI на больших и разнообразных наборах данных часто является трансформативным.

Но тут же Бюро оговаривается.

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

В общем в США все не так однозначно. Идем дальше.

✳ Text and Data Mining (Европа)

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

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

Иными словами, они указывают, что деятельность GenAI - это не только анализ, но и последующее воспроизведение, которое не покрывается исключением TDM.

Европейский парламент обращает внимание, что это последовательная позиция и в 2014, и в 2016 годах об GenAI даже не думали.

Ведомство интеллектуальной собственности ЕС в этой части отмечает:

Основная точка зрения в юридической литературе заключается в том, что TDM может включать процесс обучения ИИ, но не генерацию выходных данных

На самом деле этим проблемы TDM не ограничиваются. Есть еще странный opt-out, непонятный законный доступ, вопросы к скоупу TDM по субъектному составу. Но главный тут вывод - в Европе все также неоднозначно.

Остается Япония, но ее я не смог уместить в пост, так что расскажу об этом в другой раз. Тем более что есть более интересный способ послушать мои (и не только) аргументы - AI: БАТТЛ "АВТОРЫ vs ИИ".

Жду Вас!

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

Сегодня ваш ждет мегапост.

Мы с командой подготовили обзор про генеративный ИИ и авторское право (постом выше).

Отдельные вопросы по этой теме заслуживают целую диссертацию или самостоятельных статей, а пока их нет - можете почитать этот обзор😁

Сделки M&A с ИИ-активами

Мы с Настей Нерчинской подготовили статью о том, как структурировать сделки M&A при приобретении ИИ-бизнесов по российскому праву.

Направление только развивается и ряд вопросов остаются открытыми. Но рынок не спит и требует правовой определенности. Мы постарались структурировать то, что есть de lege lata (сейчас).

В статье разобрали:

1️⃣ Что из себя представляет ИИ-решение как объект сделки M&A

2️⃣ Три типа ИИ-бизнесов (создатели, адаптеры, интеграторы) и чем они отличаются

3️⃣ Квалификация ИИ-активов (модели, обучающего датасета) по российскому праву

4️⃣ Почему "стандартного" due diligence в ИИ-сделке не будет достаточно

5️⃣ Что точно стоит проверить в сделке M&A по покупке ИИ-бизнеса

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

А значит не время, видимо, отдыхать. Улыбаемся и машем Мониторим и актуализируем😁