Создавать или покупать — не бинарный вопрос. Путей пять: API передовой модели, модель с открытыми весами на управляемом эндпоинте, дообученная модель с открытыми весами, модель, обученная с нуля, и вариант, о котором большинство команд забывает, — не решать задачу через LLM вовсе. Выбор между ними определяют всего три призмы: стоимость при прогнозируемом объёме, потолок возможностей, которого требует задача, и регуляторная экспозиция. Для большинства организаций практический ответ таков: начать с покупки, с первого дня построить слой абстракции и вернуться к вопросу собственной разработки только тогда, когда появятся реальные данные об использовании.
Пять путей, а не два
Привычная постановка спора приводит к плохим решениям, потому что скрывает три промежуточных варианта, — а именно в них и сосредоточена основная ценность.
| Путь | Что это значит на практике | Когда он уместен |
|---|---|---|
| API передовой модели | Вызовы к коммерческому провайдеру, никакой собственной инфраструктуры | Широкая задача, умеренный объём, команда без глубокой ML-экспертизы |
| Управляемая модель с открытыми весами | Открытые веса на эндпоинте инфраструктурного провайдера | Нужен контроль версий и предсказуемая стоимость |
| Дообученная открытая модель | Дополнительное обучение на ваших данных под узкую задачу | Узкая повторяющаяся задача, заметно больше десяти тысяч размеченных примеров |
| Модель с нуля | Полный цикл обучения, выделенная исследовательская команда | Почти никогда. Только если сама модель и есть продукт |
| Вообще без LLM | Правила, поиск, классическая статистическая модель | Когда задача детерминирована и полностью специфицируема |
Три призмы, которые решают
Стоимость при прогнозируемом объёме. Не сегодняшний объём, а тот, который вы планируете через год. Быстрый расчёт: единицы работы в месяц, умноженные на стоимость единицы на пути покупки, против фиксированных инженерных и инфраструктурных затрат на пути разработки. Метод мы разбираем в статье о совокупной стоимости владения LLM-функцией.
Потолок возможностей. Если задача требует многошагового рассуждения, редкого языка или широкого знания о мире, небольшая дообученная модель не дотянет, сколько её ни обучай. Если задача — классификация по семи категориям, передовая модель означает расточительство.
Регуляторная экспозиция. Когда данные обязаны оставаться внутри юрисдикции или закрытой сети, пути покупки сужаются мгновенно. Это единственная призма, способная полностью исключить целый путь, — поэтому проверять её нужно первой, а не последней. Связь между типами данных и разрешениями изложена в статье о классификации корпоративных данных до того, как они попадут в LLM.
Когда дообучение действительно окупается
Дообучение — тот путь, который большинство команд выбирает слишком рано. Он становится оправданным, когда все перечисленные условия выполняются вместе, а не некоторые из них:
- Задача узкая, повторяющаяся и хорошо определённая и не меняется каждый квартал.
- У вас есть многие тысячи качественно размеченных примеров из собственного продакшена, а не из общего корпуса.
- Стоимость или задержка API действительно стала связывающим ограничением, а не теоретическим опасением.
- Кто-то в команде будет поддерживать модель, измерять дрейф и переобучать её, когда распределение сместится.
Если хотя бы одно условие отсутствует, дообучение добавляет постоянные затраты на сопровождение, ничего не возвращая. Работающий сценарий обратный: оставаться на API, систематически собирать продакшен-данные и вернуться к вопросу примерно через девяносто дней реального использования, когда вместо оценок появятся цифры.
Слой абстракции: единственное решение, которое нужно принять сразу
Выбирать путь в первый день не обязательно, но обязательно решить не связывать себе руки. Тонкий слой абстракции между вашим кодом и провайдером модели — самая дешёвая страховка в проекте:
| Что содержит слой | Почему это важно |
|---|---|
| Единый интерфейс для вызовов модели | Смена провайдера превращается в правку одного файла, а не в переписывание |
| Маршрутизация по типу задачи | Позволяет отправлять дешёвые задачи дешёвой модели, не трогая логику |
| Единообразное логирование входа, выхода и стоимости | Без него через три месяца не на чем будет принимать решение |
| Валидация вывода | Позволяет менять модели, не меняя контракт вывода |
Затраты, которых нет в таблице
Сравнение «создавать или покупать», сделанное в таблице, обычно взвешивает цену лицензии против стоимости вычислений и упускает три затраты, которые на деле определяют исход: время выхода на рынок, альтернативную стоимость команды, которая строит вместо того, чтобы продавать, и сопровождение на горизонте лет. Публикации к 2026 году сообщают, что организации, создававшие собственную ИИ-возможность, не проверив её сначала против готового варианта, теряли значительное время, прежде чем обнаружить, что направление было выбрано неверно.
С другой стороны, покупать бесконечно означает попасть в зависимость от одного поставщика и лишить организацию способности улучшать то, что делает её особенной. Практический баланс почти всегда гибридный: купить фундамент и построить над ним слой, где живёт конкурентное преимущество, — данные, поиск, бизнес-правила и интерфейс, — а не саму модель.
Рекомендуемая последовательность
- Определите единицу работы и критерий успеха до выбора какой-либо технологии.
- Проверьте регуляторную призму. Если она исключает пути, всё остальное теряет смысл.
- Проведите проверку концепции на готовом решении, даже если убеждены, что будете строить сами. Это дёшево и создаёт точку отсчёта.
- Постройте слой абстракции и логирование в первый же день.
- Вернитесь к решению через девяносто дней с реальной стоимостью единицы, долей успеха и распределением задач.
Именно такое сопровождение — от определения единицы работы до выбора пути — и входит в наши направления экспертизы.
Часто задаваемые вопросы
В чём практическая разница между дообучением и поиском по базе знаний?
Поиск добавляет актуальную информацию в промпт во время выполнения; дообучение меняет поведение самой модели. Для организационного знания, которое меняется, поиск почти всегда правильный выбор. Дообучение подходит для смены стиля, формата или под узкую задачу, но не для внедрения фактов.
Сколько размеченных примеров реально требует дообучение?
Принятый порядок величины — многие тысячи качественных примеров на узкую задачу. Определяющий фактор не количество, а качество и репрезентативность: тысяча чистых примеров из вашего продакшена стоит больше десятков тысяч синтетических.
Не добавляет ли слой абстракции лишней сложности?
Тонкий слой, который только унифицирует вызов, логирование и валидацию, стоит нескольких дней разработки. Стоимость его отсутствия проявляется в день, когда нужно сменить провайдера, направить дешёвые задачи дешёвой модели или объяснить, откуда взялся счёт.
Когда вообще оправдано обучать модель с нуля?
Почти никогда, если только сама модель не является продаваемым продуктом или у вас нет уникальных по объёму собственных данных в области, которую общие модели не покрывают. Для большинства организаций затраты превышают выгоду на порядки.
Как понять, что пора переходить от покупки к разработке?
Когда одновременно выполняются три условия: месячная стоимость покупки превысила годовые инженерные и эксплуатационные затраты альтернативы, задача стабилизировалась и перестала меняться, а продакшен-данных достаточно, чтобы обучать и измерять. Двух из трёх недостаточно.