Дообучение в 2026 году: эксперимент с LoRA и QLoRA и измеримыми результатами

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

Методы параметрической эффективности, такие как LoRA и QLoRA, уменьшают количество обучаемых параметров и могут снизить требования к памяти. Результат всё равно зависит от базовой модели, длины последовательности, данных, гиперпараметров, оборудования и задачи. Успешный процесс обучения не означает готовность системы к эксплуатации.

Это изменяет доступность экспериментов; это не устанавливает, что дообучение превосходит использование промптов или извлечение данных для конкретной рабочей нагрузки.

Эта статья предоставляет рабочий процесс принятия решений и экспериментов. Пейзаж провайдеров был проверен 4 августа 2026 года в соответствии с уведомлением OpenAI о снятии с поддержки, документацией Vertex AI по настройке и Hugging Face PEFT.

Когда эксперимент по дообучению обоснован

Мы кратко рассмотрели этот вопрос в материале «Промпты, RAG или дообучение»; ниже приведён более подробный анализ.

1. Согласованность формата и структуры

Если вам требуются выходные данные в строго определённом формате, сравните варианты только с промптами, ограниченным декодированием и дообучением; дообучение не обязательно превосходит ни один из базовых вариантов.

Пример: каждый вывод должен состоять ровно из пяти пунктов, каждый из которых начинается с глагола и выдержан в определённом тоне. Сравните подход только на основе промпта, ограниченным декодированием (constrained decoding), где это применимо, и дообученную модель на одних и тех же тестовых случаях; не существует универсального улучшения с 95% до 99%.

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

2. Согласованность стиля и тона

Если базовый вариант с промптом, прошедший проверку, не соответствует определённому гайдлайну по тону на репрезентативных взаимодействиях, дообучение является одним из возможных решений.

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

3. Специализированная предметная область или DSL

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

Пример: компания использует собственный внутренний язык запросов к данным. Базовая модель никогда с ним не сталкивалась. Промпты с примерами помогают, но этого недостаточно — модель продолжает допускать синтаксические ошибки.

Размеченный корпус DSL может повысить показатели парсинга и семантической корректности. Сравнивайте эти показатели с подходом на основе промптов, генерацией с грамматическими ограничениями и извлечением спецификации DSL; фиксированный рецепт из 5000 примеров не является доказательством эффективности.

4. Меньшая модель при сопоставимом качестве

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

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

5. Поведенческая безопасность

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

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

6. Повторяющиеся примеры в запросах

Если повторяющиеся примеры занимают значительный объем контекста или требуют больших затрат, сравните кэширование запросов, выборку только релевантных примеров и дообучение. Более короткий запрос после дообучения полезен лишь в том случае, если качество на отложенной выборке и безопасность остаются приемлемыми, а совокупная стоимость жизненного цикла снижается.

Когда дообучение теряет эффективность

Не менее важно: когда не следует применять дообучение.

1. Знания, которые меняются

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

2. Недостаточно данных

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

3. Базовая модель улучшается быстрее, чем вы успеваете за ней

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

Если у вас нет четкого плана поддержки, дообучение превращается в технический долг.

4. Вы не выполнили работу по запросам и RAG

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

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

5. У вас отсутствуют оценки

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

Сначала создайте систему оценки. Затем приступайте к тонкой настройке.

Ландшафт тонкой настройки в 2026 году

Краткая карта доступных решений:

Хостинговые сервисы

Доступность хостинга зависит от поставщика и типа аккаунта (данные проверены 04.08.2026):

• Собственный сервис тонкой настройки OpenAI сворачивается. Новые организации не могут создавать задания; для неактивных организаций действуют ограничения согласно задокументированному правилу 60 дней; оставшиеся активные клиенты потеряют возможность создания новых заданий 06.01.2027 согласно официальному уведомлению об отказе от поддержки. Инференс уже настроенных моделей продолжается только до момента вывода из эксплуатации соответствующей базовой модели.
• Тонкая настройка Google Vertex AI. По-прежнему поддерживает настройку для семейства Gemini.

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

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

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

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

Самостоятельный хостинг тонкой настройки

Вы предоставляете GPU, код и инфраструктуру.

• Модели с открытым исходным кодом: семейства моделей включают Llama, Qwen, Mistral, DeepSeek, Phi и Gemma. Лицензии и условия использования различаются в зависимости от модели и версии; перед началом обучения или распространением ознакомьтесь с точными условиями для конкретного артефакта.
• Инструменты: Hugging Face TRL, Axolotl, Unsloth и LLaMA-Factory являются подходящими кандидатами. Зафиксируйте выбранную версию и убедитесь в её поддержке моделей, токенизаторов, квантования, распределённого обучения и экспорта.
• Вычислительные ресурсы: зависят от размера модели, квантования, длины последовательности, стратегии батча, оптимизатора и конфигурации распределённого обучения. Запросите dated-квоту или оцените возможности вашего собственного оборудования.

Стоимость: (количество обучающих токенов ÷ измеренная пропускная способность) × стоимость оборудования, плюс расходы на хранение, неудачные запуски, оценку, инженерные работы и время рецензентов.

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

Лёгкие варианты

Для ограниченных экспериментов:

• Unsloth на поддерживаемом GPU. Проверьте его текущую матрицу совместимости моделей и оборудования, а также запас свободной памяти.
• MLX на Apple Silicon. Подходит для экспериментов с небольшими моделями, если модель и объём памяти соответствуют требованиям.
• Хостинговые ноутбуки. Полезны для экспериментов, но перед использованием необходимо проверить ограничения сессий, объём хранилища, конфиденциальность, доступность и цены.

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

Практический рабочий процесс

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

Шаг 1: Проверка необходимости

Перед любой работой с данными убедитесь в следующем:

• Создали ли вы простейший релевантный промпт, вариант вывода с ограничениями, метод retrieval или инструментальный базовый уровень?
• Есть ли результаты оценки, подтверждающие недостаточность текущего подхода?
• Можете ли вы чётко сформулировать, что именно должна улучшать тонкая настройка?

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

Шаг 2: Создание набора для оценки

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

• Сформируйте достаточно репрезентативный независимый набор, охватывающий целевое поведение и критические сценарии; обоснуйте его объём исходя из ожидаемых уровней ошибок и рисков принятия решений.
• Определите метрики: что считается успехом? Соответствие формату, соответствие тону, точность и т. д.
• Базовый уровень: запустите оценку на базовой модели. Зафиксируйте текущий результат.

Это понадобится вам, чтобы понять, помогло ли дообучение.

Шаг 3: Подготовка и контроль данных

Основная часть работы. Качество обучающих данных определяет качество результата дообучения.

Источники:

• Существующие качественные выходные данные вашей команды.
• Отфильтрованные предыдущие взаимодействия с клиентами.
• Сгенерированные примеры (используйте мощную модель и тщательное составление запросов).
• Данные конкретных клиентов (если это уместно; соблюдайте требования разрешений и защиты персональных данных).

Формат:

Типичный формат для дообучения чат-моделей:

{
  "messages": [
    {"role": "system", "content": "..."},
    {"role": "user", "content": "..."},
    {"role": "assistant", "content": "..."}
  ]
}

Один пример на строку в формате JSONL.

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

Качество важнее количества.

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

Разнообразие.

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

Данные для отказов.

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

Разделение на обучающую и тестовую выборки.

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

Шаг 4: Запуск зафиксированного эксперимента по обучению

Для хостинговых сервисов с открытыми весами (Together, Fireworks и аналогичных) процесс выглядит следующим образом: загрузите JSONL-датасет в формате чата, запустите задачу LoRA для выбранной базовой модели, дождитесь получения адаптера или конечной точки (endpoint), готовой к развертыванию. Точные поля SDK различаются у разных поставщиков; следуйте их текущей документации по дообучению.

# Универсальный хостинговый процесс; это не пример API конкретного вендора.
# Сначала проверьте актуальные поля, поддерживаемые базовые модели, тарифы и условия хранения данных.
загрузите проверенный JSONL → запустите задачу LoRA → оцените отложенную выборку → разверните адаптер

Для самостоятельного хостинга (с использованием Axolotl) — путь, который рекомендуется в данной статье для новых проектов:

base_model: Qwen/Qwen3-8B
load_in_4bit: true

adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_modules:
  - q_proj
  - v_proj
  - k_proj
  - o_proj

datasets:
  - path: ./data/train.jsonl
    type: chat_template

num_epochs: 3
micro_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 0.0002
warmup_steps: 100

output_dir: ./output

Выполните: accelerate launch -m axolotl.cli.train config.yaml

Записывайте характеристики оборудования, драйверы, дайджест контейнера/образа, файл блокировки пакетов (package lock), хэш датасета, токены, пропускную способность, затраченное время, контрольные точки и стоимость. Не пытайтесь выводить параметры времени выполнения на основе этого наброска.

Гиперпараметры, которые следует фиксировать и намеренно варьировать: количество эпох или шагов, расписание изменения скорости обучения (learning-rate schedule), оптимизатор, эффективный размер батча, длина последовательности и упаковка данных, ранг/альфа/dropout адаптера и целевые модули, точность/квантование, период разгона (warmup), частота сохранения контрольных точек и оценки, а также начальное значение генератора случайных чисел (seed). Начните с поддерживаемого рецепта для конкретной модели и зафиксированной версии библиотеки, выполните профилирование на небольшом объеме данных, затем изменяйте по одной гипотезе за раз, оценивая результаты на отложенных данных и метриках безопасности. Не используйте иллюстративные значения YAML в качестве значений по умолчанию.

Шаг 5: Оценка

Запустите набор тестов оценки (eval suite) на дообученной модели.

• Улучшился ли показатель по сравнению с базовой моделью?
• Насколько?
• Не произошло ли регрессии (снижения качества) общих возможностей, безопасности или обработки крайних случаев?

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

Шаг 6: Тестирование в теневом режиме, канареечное развертывание и откат

Перед полным развертыванием проведите A/B-тестирование:

• Начните с теневого режима (shadow mode), где это возможно, затем определите размер канареечной группы, исходя из потенциального ущерба, объема трафика, статистической мощности и скорости отката.
• Сравните метрики: показатели качества, обратную связь от пользователей и косвенные сигналы.

Примите решение после достижения заранее объявленного размера выборки и времени наблюдения: расширить охват, внести доработки или выполнить откат.

Шаг 7: Развертывание с путем отката

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

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

Шаг 8: Мониторинг (постоянный)

Дообученная модель находится в производстве. Мониторьте:

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

Шаг 9: Поддерживающие действия по триггеру

Дообучение — это не «загрузили один раз и забыли».

• Обновление базовой модели: периодически проводите повторное дообучение на новой базовой версии.
• Сдвиг данных: обновляйте обучающие данные, чтобы они отражали текущие закономерности.
• Расширение набора оценок: повторно проверяйте соответствие по мере появления новых тестовых случаев.

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

Практический пример

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

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

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

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

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

Поддерживающие действия: переоценивайте при изменении распределения заявок, политики бренда, базовой модели или реестра ошибок. Измеряйте трудозатраты за цикл, а не обещайте конкретный день.

Мы намеренно не приводим точные проценты «до» и «после»: они отражали бы показатели нашего сценария, а не ваши, и оценки соответствия голоса не переносятся между наборами данных. Когда мы опубликуем результаты собственного измеренного запуска, к ним будут приложены набор оценок и протокол судейства.

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

Распространённые режимы сбоев

Несколько типичных паттернов:

Сбой 1: Переобучение. Метрики обучения улучшаются, в то время как метрики на отложенной выборке или при изменённых входных данных ухудшаются. Диагностика утечек данных, дублирования, ёмкости модели, количества шагов, регуляризации и покрытия срезов; конкретные меры зависят от результатов эксперимента.

Сбой 2: Катастрофическое забывание. Интенсивное обучение на узких задачах ухудшает общие способности модели. Модель хорошо справляется с вашей задачей, но хуже — с остальными. Решение: снизьте скорость обучения, уменьшите количество эпох или включите разнообразные данные, не относящиеся к целевой задаче.

Сбой 3: Несоответствие форматов данных. Данные для обучения оформлены иначе, чем данные, с которыми модель работает в продакшене. При дообучении модель усваивает неверное распределение. Решение: убедитесь, что форматы данных для обучения и вывода строго совпадают.

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

Сбой 5: Хаос гиперпараметров. Подбор гиперпараметров без методологии. Результаты иногда улучшаются, иногда ухудшаются, но вы не получаете новых знаний. Решение: изменяйте по одному параметру за раз, оценивайте результат и делайте выводы.

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

Сбой 7: Недостаточное внимание к безопасности. Дообучение может изменить поведение модели в части отказов и других аспектов безопасности как в положительную, так и в отрицательную сторону. Оценивайте срезы с недостаточными отказами, избыточными отказами, джейлбрейками и легитимными запросами; обучающие примеры не заменяют детерминированные механизмы контроля.

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

Шаблоны экспериментов, а не скопированные рецепты

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

Стратегический вопрос

Помимо технических аспектов, дообучение — это стратегический вопрос:

• Стоит ли инвестировать в эту возможность на долгосрочную перспективу или использовать передовые модели для всех задач?
• Готовы ли вы поддерживать дообученную модель неограниченно долго?
• Оправдывает ли прирост качества возросшую сложность поддержки?

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

Развертывайте выборочно, поддерживайте осознанно

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

«ИИ недостаточно хорош» не является обучаемой целью. Назовите неудавшуюся задачу и сегмент, постройте соответствующую базовую линию, получите права на данные, определите критерии приемки и регрессии, а затем проверьте, добавляет ли дообучение ценность. Устойчивые преимущества можно утверждать только после многократного подтверждения на отложенных выборках, тестов безопасности, обслуживания и поддержки в развернутой системе.