Карликовые модели: зачем компании обучают крошечную LLM под одну узкую задачу

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

Показательный пример — кейс Checkr, платформы проверки кандидатов. По данным Predibase, где модель дообучали, GPT-4 давал 87–88% точности на лёгких случаях и около 82% на «грязных» данных, а дообученная открытая модель на 8 млрд параметров показала более 90% на самых сложных 2% случаев; стоимость при этом, по заявлению компании, снизилась в 5 раз. Прежде чем делать выводы, разберём механику, цифры и границу применимости — со ссылками на первоисточники и оговорками там, где источник заинтересован в результате.

Что считать «карликовой» моделью

Чёткой границы в индустрии нет, поэтому берём рабочее определение из позиционной статьи NVIDIA: малая языковая модель — это модель, которая помещается на обычное потребительское устройство и обслуживает запросы одного пользователя с приемлемой задержкой. По состоянию на 2025 год под это определение подпадает большинство моделей до 10 млрд параметров. Это позиция авторов статьи, а не отраслевой стандарт. Для практики удобнее запомнить порядок величины: семейство «7–8 млрд параметров и меньше».

Список актуальных малых моделей 2026 года быстро устаревает. По сводке Turing Post (вторичный источник — версии лучше сверять по карточкам разработчиков), в него входят Gemma 4, Phi-4, Qwen3, SmolLM3, Granite 4.1, Nemotron 3 Nano и другие. Для нас важнее не конкретное имя, а два приёма, с помощью которых такую модель «сжимают» под задачу.

Дообучение через LoRA. Базовые веса модели замораживают и обучают небольшие дополнительные матрицы. Идея проста: вместо того чтобы переписывать всю модель, вы учите её тонкой «надстройке». В оригинальной работе для GPT-3 175B это дало в 10 000 раз меньше обучаемых параметров и в 3 раза меньше памяти GPU по сравнению с полным дообучением. Оговорка важная: цифры относятся к GPT-3 и на малые модели напрямую не переносятся. Но направление понятно — LoRA делает дообучение доступным без кластера.

Дистилляция с объяснениями. Исследование Google (ACL Findings 2023) показало: T5 на 770 млн параметров обошла few-shot PaLM на 540 млрд на тесте ANLI, использовав 80% обучающих данных, если учить её не только правильным ответам, но и «рассуждениям» модели-учителя. Ограничения тоже ясны: речь о задачах класса NLI и о сравнении с few-shot PaLM 2023 года. Переносить вывод на современные флагманские модели нельзя, но сам приём — учить малую модель на объяснениях большой — остаётся рабочей идеей.

Чем дообучение отличается от дистилляции, RAG и промпта

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

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

RAG добавляет модели знания в момент запроса: система находит релевантные документы и подкладывает их в контекст. Модель по-прежнему не меняется, но получает информацию, которой у неё не было. Это лекарство от проблемы «модель не знает наших данных», но не от проблемы «модель отвечает не в том формате» и не от проблемы цены на большом объёме.

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

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

Цикл «сначала большая, потом маленькая»

Самая практичная схема из сравнительных разборов укладывается в короткую формулу: сначала большая модель, потом маленькая. В англоязычной литературе её называют «Start large, specialize small». Смысл в том, что на сильной универсальной модели вы быстро собираете прототип и по ходу видите, из чего вообще состоит ваша задача: какой формат ответа нужен, какие категории встречаются, на каких примерах прототип ломается.

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

Если вопрос упирается именно в оплату отдельного сервиса напрямую, у нас есть разбор, как оплатить ChatGPT в России в 2026 году, где этот сценарий описан подробно.

Зачем это нужно компаниям

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

Стоимость и задержка при большом объёме. Когда один и тот же запрос повторяется миллионы раз, разница в цене за вызов превращается в статью бюджета. В кейсе Checkr оценка самой компании — около $7 000 в месяц на GPT с RAG и около $12 000 без RAG; после перехода на дообученную малую модель, по заявлению компании, стоимость снизилась в 5 раз. По скорости цифры в источниках расходятся: Predibase заявляет «в 30 раз быстрее», а Computerworld приводит 15 секунд у GPT-4 против менее 0,15 секунды у дообученной модели, то есть примерно в 100 раз. Мы их не пересчитываем и не усредняем, а честно пишем: на порядок быстрее, по данным компании.

Приватность и локальный запуск. Малую модель можно держать на собственных серверах, и данные не уходят во внешний сервис. Для компаний с чувствительными данными это иногда важнее цены. Есть и менее очевидный довод — независимость от одного поставщика: если вся ваша логика завязана на единственный внешний аккаунт, его блокировка останавливает процесс. Что делать в такой ситуации, разбирали на РБК: аккаунт Claude заблокировали — что делать.

Предсказуемый формат ответа. Для автоматизации критично, чтобы модель всегда отвечала в одном и том же виде. В кейсе PayPal дообученная модель выдавала 100% валидного JSON — для интеграции в процессы это ценнее, чем красивый текст.

Кейс PayPal: проверка расшифровок разговоров. Это препринт июня 2026 года. Модель на 8 млрд параметров дообучили методом LoRA (2,05% обучаемых параметров) всего на 219 примерах, чтобы проверять расшифровки разговоров на соответствие процедурам. На 53 незнакомых расшифровках результат такой: 100% валидного JSON, 83,0% общей точности по проверке экспертов, около 2 секунд на запрос и $0,013 за оценку против $0,025–0,055 у API. Авторы добавили слой жёстких правил поверх модели. Здесь стоит помнить об ограничениях: тест маленький (доверительный интервал около ±10%), а цены API взяты из 2024 года.

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

Как это делают на практике

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

Шаг 1. Прототип на сильной универсальной модели. Фиксируем задачу, формат ответа и типичные ошибки. На этом шаге выясняется, достаточно ли вообще промпта и RAG — об этом отдельный раздел ниже.

Шаг 2. Размеченные примеры из реальных данных. Берём настоящие запросы и правильные ответы, подтверждённые экспертом. Отдельно собираем набор «трудных» случаев: в кейсе PayPal добавление всего 20 трудных негативных примеров подняло точность в проблемном поле до 100%. Это важнее, чем наращивание объёма очевидных примеров.

Шаг 3. Дообучение с остановкой по валидации. Малая выборка легко приводит к переобучению. В том же кейсе PayPal при обучении на 188 примерах кривая валидации пошла вверх на шаге 60 — классический признак. Поэтому обучение нужно останавливать по метрике на отложенных данных, а не по числу эпох.

Шаг 4. Жёсткие проверки поверх модели. Там, где правило однозначно, не нужно полагаться на модель: проверка формата, допустимых значений, обязательных полей. Авторы PayPal добавили такой слой — и сами признают, что правила на регулярных выражениях хрупки, поэтому их нужно поддерживать.

Шаг 5. Слепая проверка на ранее не виденных данных с экспертной оценкой. Модель не должна встречать эти данные при обучении, а оценивает результат человек-эксперт, а не другая модель. Именно так построен тест PayPal на 53 расшифровках — и его главный недостаток в том, что выборка мала. Чем больше слепой набор, тем надёжнее вывод.

Как посчитать окупаемость, не обманывая себя

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

Для иллюстрации возьмём опубликованные в кейсе PayPal цены за одну оценку: $0,013 у дообученной малой модели против $0,025–0,055 у API. Это чистая арифметика, а не прогноз для вашей компании. При 100 000 оценках в месяц малая модель обойдётся примерно в $1 300, а API — примерно в $2 500–5 500, то есть разница составит порядка $1 200–4 200 в месяц. При 10 000 оценок в месяц те же цены дают разницу в $120–420, и всё может не окупиться, потому что на разметку и экспертную проверку у вас уйдёт больше.

Три оговорки, без которых такая арифметика вводит в заблуждение. Во-первых, цены API в препринте взяты из 2024 года, и сегодня они могут быть другими, поэтому пересчитывать нужно по актуальным тарифам. Во-вторых, цена за вызов обычно не включает работу людей: сбор и разметку выборки, экспертную проверку, поддержку жёстких правил. В-третьих, цифры вендоров, как в случае Checkr, лучше считать верхней границей выгоды, а не ожидаемым результатом. Хорошая практика — прикинуть окупаемость на трёх сценариях (пессимистичном, базовом и оптимистичном) и принимать решение, ориентируясь на пессимистичный.

Что мониторить после запуска

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

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

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

Малая против большой модели

Таблицу стоит читать как карту компромиссов, а не как рейтинг. Цифры в столбце «Стоимость» — из конкретных кейсов с их ограничениями: у Checkr они от вендора, у PayPal — из препринта с ценами 2024 года. Строка «Основной риск» важнее остальных: малая модель выигрывает, пока вход похож на то, чему её учили, и ломается, когда этого сходства нет. Большая, наоборот, переносит новизну лучше, но платит за это ценой и скоростью на рутине.

Где малые модели проваливаются

Самое полезное в кейсе PayPal — не победные цифры, а подробный разбор ошибок, который авторы привели сами. Модель ни разу не предсказала значение «Fail» в поле Disposition. Причина — перекос обучающей выборки: 67% исходов в ней были правильными, и модель научилась почти всегда выбирать «безопасный» ответ. Ошибки пришлись именно на это поле (точность 90,6%), а когда добавили 20 трудных негативных примеров, точность в нём дошла до 100%.

Урок тут технический: если в данных редкий класс — именно тот, ради которого затевалась проверка, — малая модель его «проглотит», пока вы специально не дадите ей достаточно примеров. Второй урок статистический: на 53 тестовых случаях доверительный интервал около ±10%, поэтому любые «83,0%» нужно читать как «примерно 73–93%». И третий — о переобучении: на 188 примерах кривая валидации пошла вверх уже на шаге 60.

Границу применимости обозначает и NVIDIA: где нужен общий диалог, естественный выбор — гетерогенные системы, в которых малые модели берут повторяющиеся задачи, а большая остаётся для сложных. Добавьте к этому оговорку про дистилляцию: результат на T5 относится к задачам класса NLI и к сравнению с few-shot PaLM 2023 года, поэтому «малая обошла большую» не стоит читать как универсальную закономерность.

Когда обучать ничего не нужно

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

Промпты для подготовки узкой задачи

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

Prompt: Help me write a one-page specification for this narrow task: [describe task]. Include the input format, the exact output format, the allowed values, and three examples of correct and incorrect outputs. — компактная спецификация задачи, которую можно отдать и разметчикам, и инженерам.

Prompt: Write a labeling guideline for annotators working on this task: [describe task]. Cover ambiguous cases and tell them what to do when they are unsure. — инструкция для разметчиков с разбором неоднозначных случаев.

Prompt: Generate 20 hard negative examples for this classification task: [describe task and classes]. Each should look like a typical case of one class but actually belong to another. — набор трудных негативов для проверки модели.

Prompt: Create a test set of 30 edge-case inputs for this task: [describe task]. Mark which ones are most likely to confuse a small model and explain why. — проверочный набор с пограничными ситуациями.

Prompt: Design a strict JSON schema for the output of this task: [describe task]. Specify required fields, allowed enum values, and validation rules. — схема ответа, по которой можно ставить жёсткие проверки.

Prompt: Analyze this labeled dataset summary: [paste class counts]. Point out class imbalance and suggest how to rebalance it without inventing data. — поиск перекоса классов в выборке.

Prompt: Compare the outputs of two models on the same inputs: [paste outputs]. Classify each disagreement as formatting, factual, or judgment, and tell me which ones need an expert review. — разбор расхождений между двумя моделями.

Prompt: Suggest deterministic validation rules that could run on top of a model's output for this task: [describe task]. For each rule, say how it could become brittle. — жёсткие правила поверх модели и честный список их слабых мест.

Prompt: Prepare a blind evaluation plan for this task: [describe task]. Specify the sample size, how experts should grade, and how to report uncertainty. — план слепой проверки с оценкой неопределённости.

Prompt: Estimate whether switching to a small fine-tuned model would pay off for this task: [volume per month, current cost per call, required latency]. List the assumptions I need to verify with real measurements. — прикидка окупаемости с явным списком допущений.

Частые ошибки

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

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

• Оценивать на данных, которые модель уже видела. Любая цифра точности без слепой проверки на новых данных — повод для недоверия.

• Сравнивать стоимость по ценам прошлых лет. Цены API меняются быстро, и сравнение с 2024 годом в 2026-м легко даёт ложный вывод.

• Верить вендорскому кейсу без пересчёта. Цифры Predibase стоит сверять с независимыми источниками и держать в голове возможную необъективность, о которой предупреждает даже ZenML.

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

Частые вопросы

Сколько примеров нужно для дообучения?
Универсальной цифры нет. В кейсе PayPal модель дообучили на 219 примерах, но это одна задача с жёстким форматом; в исследовании по дистилляции использовали 80% обучающих данных от того, что нужно обычному методу. Практический ориентир — начинать с небольшого, но качественно размеченного набора вместе с отдельным списком трудных случаев и расширять его по результатам слепой проверки.

Можно ли обойтись RAG?
Часто да. RAG решает проблему нехватки знаний, но не проблему формата и не проблему цены на большом объёме. Если модель ошибается из-за того, что не знает ваших данных, начните с RAG; если проблема в стоимости, задержке или нестабильном формате — тогда имеет смысл думать о дообучении.

На каком железе запускать?
Жёстких требований нет, и они зависят от конкретной модели и настроек. По определению NVIDIA, малая модель — это такая, которая помещается на потребительское устройство для обслуживания одного пользователя; LoRA, в свою очередь, снижает требования к памяти при дообучении по сравнению с полным обучением. Точные требования смотрите в карточке выбранной модели и проверяйте на своих данных.

Чем малая модель хуже большой?
Широтой и устойчивостью к новому. Она хороша, пока вход похож на обучающие данные, и ломается на непохожем. Кроме того, малая модель чувствительна к перекосам выборки, как показал кейс PayPal, а ошибки при малом тесте трудно отличить от случайности.