Сергей Кирницкий Собственная языковая модель. Когда, зачем и в каком масштабе

1.1. Почему вопрос «своя LLM» встал сейчас

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

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

Параллельно с публичной волной шла другая, менее заметная. Открытые модели, которые пять лет назад существовали почти исключительно в виде исследовательских прототипов, достигли уровня, на котором их всерьёз можно использовать в продукте. Публикация Llama и технический отчёт DeepSeek V3 — два из множества сигналов, что экосистема созрела: базовая модель больше не является секретом крупнейших лабораторий, её можно взять как отправную точку, использовать напрямую или дообучать на собственных данных. Тогда мысль «построить свою» звучала фантастически; сейчас она для узкого круга компаний звучит обоснованно. Зрелость экосистемы означает, что у вопроса появилась техническая осуществимость — и именно отсюда у советов директоров возникла задача проверить, приложима ли она к ним.

К этим двум волнам добавляется третья — внешнее давление. Его редко называют так прямо, но оно формирует значительную часть повестки. Конкуренты объявляют собственные ИИ-стратегии; и даже если эти стратегии пока ничего не значат по существу, их само наличие превращается в аргумент на совете: у них есть — у нас нет. Деловые СМИ задают прямой вопрос об ИИ-стратегии, и отсутствие внятного ответа становится репутационным риском. Государственные регуляторы постепенно формируют собственные требования: ЦБ выпускает методические указания по применению моделей в финансовом секторе, Минздрав начинает обсуждать границы использования моделей в клинической практике, тема персональных данных по 152-ФЗ получает новое измерение из-за того, что модели обучаются на больших корпусах и плохо забывают попавшее в них. Для объектов критической информационной инфраструктуры (КИИ — категория объектов, отказ которых создаёт системные риски для страны) сам факт отправки данных во внешний API оказывается вопросом не удобства, а режима. В этой внешней рамке вопрос о собственной модели встаёт даже перед теми компаниями, которые изнутри его не задают; он приходит снаружи и требует ответа — независимо от того, готова компания его сформулировать или нет.

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

Отсюда и новизна самой постановки. Раньше, в предыдущие волны, решение о конкретной модели почти всегда делегировалось ML-команде или отделу аналитики: специалисты сами выбирали алгоритм, закупали лицензию, договаривались с вендором. Доходить до совета директоров такие решения практически не имели поводов. Современные LLM сдвинули эту границу. Сама модель стала точкой контроля над целым классом продуктов компании, её поведением в коммуникации, её доступом к внутренним данным. Решение о том, кто этой точкой владеет — сама компания или внешний поставщик, — перестало быть техническим. Оно стало стратегическим, и делегировать его команде ML больше нельзя, как нельзя делегировать решение о выходе на новый рынок или о смене ключевого поставщика. Именно поэтому вопрос оказался там, где раньше его не было, — в повестке высшего руководства. И именно поэтому от него нельзя отмолчаться: отказ от ответа здесь — тоже ответ, только принятый по умолчанию.

1.2. Ловушка «хочу свою модель»

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

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

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

Из аналогии следует и то, что означает «оценить, что действительно требуется». Если импульс звучит как «мы хотим свою модель», то зрелая реакция — разложить этот импульс на проверяемые элементы. Какие данные у компании есть, и что в них такого, чего нет в открытом интернете? Есть ли у неё команда, способная не просто обучить модель, а поддерживать её жизненный цикл годами? Какой временной горизонт компания готова выдерживать — полгода, два года, пять? Какая у неё оценка риска, что через год результат окажется хуже, чем внешняя модель, доступ к которой можно купить по подписке? Готов ли совет директоров к тому, что проект не закончится запуском, а перейдёт в режим постоянного обновления? Каждый из этих вопросов имеет свою предметную плоть. Собранные вместе, они заменяют общее «хочется» на конкретную картину, в которой «строить своё» либо обретает основание, либо распадается на составляющие и исчезает.

Именно в этом задача книги — не отговорить руководителя и не подтолкнуть его, а помочь отличить обоснованное стратегическое решение от импульсивного. Ни один из этих двух путей не универсален: для какой-то компании «своя LLM» — действительно верный ответ, а для другой — дорогостоящая демонстрация, которая закончится тихим сворачиванием проекта через полтора года. Книга не берётся назначить, кто в какой группе, а даёт читателю собственный инструмент распознавания. В итоге решение остаётся за читателем; меняется лишь то, на чём это решение основывается. Разница между импульсом и стратегией — не в смелости, а в наличии картины поля перед глазами.

1.3. На какой вопрос отвечает книга

В этой книге нет универсального ответа «делайте X». Это не уклонение автора от ответственности и не уступка разнообразию мнений. Просто универсального ответа на вопрос «нужна ли нам своя LLM» объективно не существует: ситуации компаний настолько различны, что любой единый совет обязательно кого-то обманет — либо читателя, которому он не подходит, либо самого себя, если будет признан верным независимо от контекста. Книга, которая утверждает обратное, полезна разве что в качестве мотивационного текста — но не как инструмент управленческого решения.

Пространство возможных ответов, впрочем, не бесконечно. Оно раскладывается на пять устойчивых рекомендаций, и именно между ними проходит реальный выбор. Первая рекомендация — «ничего не делайте, используйте RAG или внешние API»: работать с готовыми моделями через интерфейсы доступа, настраивать промпты, выстраивать внешнюю память для точного извлечения знаний, применять лёгкие методы адаптации. Вторая — Малая (сценарий S) — простая специализированная модель, собственная, но небольшая, обученная под одну узкую задачу. Третья — Адаптированная (сценарий A) — продолженное предобучение на открытой базе, когда за точку отсчёта берётся модель класса Llama или DeepSeek и дообучается на собственных данных компании. Четвёртая — Собственная (сценарий B) — предобучение средней модели с нуля, проект уровня серьёзной исследовательской лаборатории. Пятая — Фронтир (сценарий C) — лидирующий класс моделей, сопоставимых с GPT-4/5, Claude, Gemini, — уровень, на котором в мире работает лишь очень узкий круг организаций. Эти имена и короткие пояснения — всё, что нужно знать о модели пяти рекомендаций сейчас. Подробное содержание каждой, различия в масштабе, требованиях и рисках раскрываются в Главе 6; способ определить, какая из пяти — ваша, — в Главе 10.

Такая архитектура — не случайная. Методика выбора, которую книга доводит до практического инструмента в Главе 10, состоит из набора диагностических вопросов и оценочной карты. Ответить на эти вопросы формально, за пятнадцать минут, можно и без остальной книги — получится анкета, которую можно сдать начальнику. Проблема в том, что за каждым из вопросов стоит предметная реальность, которую необходимо увидеть, чтобы ответ имел смысл. Нельзя всерьёз оценить, достаточно ли у компании данных, не понимая, что именно считается «данными» для обучения модели и чем они отличаются от того, что компания привыкла называть своим информационным активом. Нельзя оценить, готова ли команда, не представляя, какие роли вообще в такой команде должны быть, какой у них рынок и насколько опасен уход одного ключевого специалиста. Нельзя оценить ресурсы, не зная, что уровни масштаба принципиально разные: между Малой моделью и Фронтиром — не разница в цене подписки, а смена индустриальной категории. Нельзя оценить риски, не видя, как именно устроены типовые неудачи подобных проектов, и чем в них оборачивается каждая сэкономленная статья бюджета. Поэтому книга построена последовательно: в Главе 2 очерчивается предмет — что именно мы называем «своей LLM» и чем она отличается от соседних вариантов; в Главах 3 и 4 раскрывается её устройство и процесс создания; в Главах 5 и 6 — основания для разработки и четыре сценария масштаба; в Главах 7 и 8 — данные и команда; в Главе 9 — риски, на которые стоит смотреть трезво. К Главе 10 читатель приходит с готовой картиной поля — и только тогда оценочная карта перестаёт быть анкетой и становится инструментом.

Отсюда и позиция автора. Он не принимает решение за читателя и не ведёт его к заранее заготовленному выводу. Роль, которую автор на себя берёт, — показать устройство поля: где проходит экономика, где риски, где границы возможного. Всё, что читатель должен вынести из книги, — ясное видение того, из каких материалов и при каких условиях складывается каждый из пяти ответов, и чем они отличаются друг от друга. Окончательное решение — всегда за читателем, и оно будет лучшим, если принимается с полным пониманием предмета. Книга рассчитана не на инструкцию, которую можно выполнять по пунктам, а на карту, по которой человек сам прокладывает маршрут под собственные обстоятельства. Пять возможных ответов — это пять островов на этой карте; и каждый остров ещё предстоит сделать узнаваемым, чтобы ошибиться, определяя свой, стало существенно труднее.

Остаётся сказать ещё об одном свойстве этого разговора. На вопрос «нужна ли нам своя LLM» серьёзно отвечает не тот, кто отвечает быстро, а тот, кто отвечает после того, как увидел предмет целиком. Темп чтения этой книги — не темп сводки для совещания; скорее темп разговора с опытным коллегой, которому не нужно продавать свою позицию и который не спешит. Если в конце такого разговора руководитель приходит к ответу «нам это не нужно», это не провал книги, а её успех. Если приходит к ответу «нам нужна Малая, и вот почему» — тоже успех. Книга считает себя полезной в обоих случаях, при условии, что ответ получен не из импульса, а из картины. Всё остальное — частные варианты одной и той же задачи: увидеть поле и принять решение, глядя на него, а не от него отвернувшись.

Слова «своя LLM» звучат понятно ровно до того момента, когда за них приходит счёт. На совещании фраза объединяет людей: все кивают, будто речь идёт об одном и том же. В договоре подряда, в техническом задании, в спецификации на закупку видимая общность рассыпается. Одни имеют в виду закрытый контур с чужой моделью внутри, другие — дообучение на своих данных, третьи — модель, созданную с нуля. Эта глава делает одно: отделяет «свою LLM» от всего, что на неё похоже, и показывает четыре готовых пути, каждый из которых в большинстве случаев правильнее собственного проекта.

2.1. Что мы называем «своей LLM»

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

Хороший способ думать об этом — дом. Можно построить его с нуля, можно перестроить из купленного вчерне, но в обоих случаях документы оформлены на тебя. Арендованная квартира — пусть с отдельным входом, своим замком и разрешением переклеить обои — домом в этом смысле не становится. Разница незаметна день в день и становится очевидной в тот момент, когда арендодатель меняет правила.

Владение весами достигается одним из двух путей. Первый — предобучение с нуля (pretraining): модель начинается с набора случайных чисел и проходит через гигантский корпус текстов, постепенно превращаясь в то, что мы называем языковой моделью. Это самый тяжёлый режим. Компания начинает с пустоты и создаёт модель целиком. Характерен этот путь для сценариев B (Собственная) и C (Фронтир), подробно разворачиваемых в Главе 6. Порядки величин, которые здесь появляются, — триллионы токенов обучающих данных, сотни или тысячи GPU, многомесячные прогоны обучения; детализация этих цифр — предмет Глав 6—7. Для нас пока важно одно: предобучение с нуля — это режим создания модели из ничего, и он даёт полное, ничем не обременённое право собственности на результат.

Второй путь — продолженное предобучение (continued pretraining): берётся уже существующая модель — открытая, как Llama или DeepSeek, или собственная предыдущая версия — и дообучается на новых данных. Результат этого процесса — новые веса, отличающиеся от исходных, и именно они становятся собственностью компании. Ресурсов требуется кратно меньше, чем для предобучения с нуля — в разы меньше данных, в разы меньше вычислений, — но статус актива получается тот же: новые веса полностью принадлежат компании. Этот режим характерен для сценария A (Адаптированная) и отчасти для S (Малая). И именно поэтому А — полноценная «своя LLM» наравне с B и C: их отличает масштаб и дороговизна, а не статус актива на выходе. Разница между арендой и собственностью здесь важнее, чем разница между большим домом и малым.

Осталось отделить своё от похожего. Частый случай терминологической путаницы — приватное развёртывание чужой модели. Компания поднимает Llama или DeepSeek внутри своего контура, получает полный контроль над инфраструктурой и данными, может работать с моделью в закрытом режиме и применять к ней лёгкие методы настройки. Всё это серьёзная инженерная работа, и для многих задач её более чем достаточно. Но веса остаются чужими. Лицензия исходной модели продолжает действовать, право на глубокую модификацию ограничено её условиями, лицензировать третьим сторонам эти веса нельзя. Это не своя LLM — это приватная эксплуатация чужой.

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

2.2. Четыре альтернативы — и когда они лучше

С противоположной стороны от своей LLM стоят не «менее амбициозные варианты», а четыре зрелых рабочих пути, у каждого — своя область, где он просто лучше. Полка с готовым здесь — не синоним дёшево-и-сердито. Это признание, что в подавляющем большинстве случаев готовое решение даёт нужное качество быстрее, дешевле и с меньшим риском, чем самодельное. Развёрнутый разбор каждого из них — отдельный жанр; здесь — ровно столько, чтобы увидеть границу. Объединяет их одна черта: веса в них остаются не у компании.

Первый путь — RAG (Retrieval-Augmented Generation): подход, при котором ответы модели дополняются поиском по своим документам, а сама модель остаётся нетронутой. Вокруг неё выстраивается инфраструктура индексации и поиска по корпоративным данным, и при каждом запросе нужные фрагменты подставляются в контекст. RAG часто оказывается правильным ответом в двух типичных ситуациях. Первая — данные быстро меняются, и переобучать под каждое обновление бессмысленно: каталог продуктов, техническая документация, внутренняя база знаний, живущая своей жизнью. Вторая — данные чувствительны, и «вшивать» их в веса модели просто нельзя по правовым причинам или из соображений безопасности. Когда руководитель формулирует задачу словами «нам нужна модель, знающая наши документы», правильный ответ в большинстве случаев — RAG.

Второй путь — prompt engineering: искусство составления входных запросов, которое даёт результат быстро и без инфраструктурных затрат. Ни обучения, ни дообучения, ни отдельного контура — только хорошо продуманные инструкции и примеры, подаваемые готовой модели. Этот путь в крупных компаниях недооценён по любопытной причине: он «слишком простой». Он не создаёт ощущения серьёзной работы, не вписывается в крупный бюджет, не требует команды. Между тем грамотно настроенный промпт часто решает задачу, под которую казалось необходимым дообучение. Классификация входящих обращений, первичная разметка документов, маршрутизация запросов — задачи, под которые в компании уже успели обсуждать свою LLM, нередко снимаются точной постановкой и десятком хороших примеров. Правило здесь простое: прежде чем переходить к более тяжёлым методам, стоит убедиться, что лёгкий исчерпан.

Третий путь — LoRA (Low-Rank Adaptation): метод лёгкой и дешёвой адаптации открытой модели под узкую задачу. Технически это надстройка — к исходной модели добавляются небольшие «дельты», которые подстраиваются под конкретные данные, а сами основные веса остаются нетронутыми. Результат получается быстро и обходится в разы дешевле полноценного дообучения. Масштаб тут характерный: надстройка весит десятки мегабайт против сотен гигабайт исходной модели — это и делает её технически лёгкой и экономически соблазнительной. Формально это не своя LLM: исходные веса компании не принадлежат, права определяются лицензией базовой модели, без неё LoRA-надстройка не работает. Но для множества задач этого уровня адаптации достаточно, чтобы модель начала вести себя ближе к домену компании — и ближе, чем покрывает голый prompt engineering.

Четвёртый путь — внешние API: использование моделей через интернет без владения какими бы то ни было весами. Это, как правило, самый быстрый способ получить качество. OpenAI, Anthropic, Google и другие поставщики дают доступ к моделям лидирующего класса без капитальных затрат на инфраструктуру и команду. Для очень многих компаний именно это и есть правильный ответ — отсюда и берётся первая из пяти возможных рекомендаций книги: «ничего не делайте, используйте RAG или внешние API».