Запустить SLM на цеховой стойке — задача не про выбор модели, а про готовность данных и production‑метрик. Playbook: аудит журналов ОТК и телеметрии → пайплайн fine‑tuning → оценка качества на доменном holdout → интеграция в MES/1С с fallback → TCO‑расчёт. Каждый шаг с конкретными цифрами и точками go/no‑go. Без ML‑отдела, за 6–10 недель, с прозрачной экономикой. Вы уже разобрались, что edge‑модель окупается — триггеры, рублёвый калькулятор и стоп‑лист собраны в статье «Малые LLM на производстве: когда edge‑модель дешевле облака». Теперь вопрос: как дойти от сырых записей в MES до стабильной модели на цеховом сервере, которую можно встроить в контур и забыть про ручную проверку 70% операций? Ответ — в пяти шагах этого playbook. Шаг 1: Аудит производственных данных IT‑директор завода обычно знает, где лежат данные: MES‑система, SCADA, журналы в 1С, Excel на участках. Для fine‑tuning нужен иной срез — не «есть ли данные», а «можно ли извлечь правильный ответ». Инвентаризация запускается по трём направлениям: 1. Количество размеченных примеров. Сколько записей содержат одновременно входную информацию и целевую метку? Например: - акты ОТК с полями «описание дефекта» и «решение» — кандидат на классификацию, - телеметрия с комментариями оператора о причине аномалии — кандидат на объяснение, - шаблоны отчётов с заполненными полями — кандидат на extraction. 2. Схема разметки и её стабильность. Один и тот же дефект всегда называется одинаково, или три инженера используют три разных формулировки? Если разметка разнобойная, нужны правила нормализации (утверждённый справочник дефектов) и повторная переразметка. 3. Чистые текстовые/JSON‑поля. Мультимодальные данные (текст + изображение) без единого токенизатора SLM пока не возьмёт. Если задача требует анализа снимков, нужна отдельная модель компьютерного зрения, не SLM. Метрики go/no‑go на этом шаге • Наличие хотя бы 300 размеченных примеров — нижняя граница для первого baseline. Меньше — оценивайте стоимость ручной разметки. • Отсутствие PII в текстах. Имена операторов, табельные номера, паспортные данные — стоп‑сигнал. Данные необходимо анонимизировать до начала fine‑tuning. • Баланс классов. Если брак встречается в 0,1% записей, модель не научится его ловить без oversampling или генерации синтетических примеров. Такие кейсы требуют отдельного проекта, выходящего за рамки этого playbook. Результат шага — таблица доступных датасетов, их объём, качество разметки и стоимость доведения до приемлемого состояния. Это и есть ваш входной бюджет данных. Шаг 2: Pipeline подготовки данных для fine‑tuning От инвентаризации переходите к pipeline. Сбор: экспортируйте отобранные записи в машиночитаемый формат. Итоговый артефакт — JSONL‑файл, где каждая строка содержит поля `instruction`, `input` и `output`. Для классификации дефектов: instruction = «Определи вид дефекта по описанию», input = текст из журнала ОТК, output = метка класса. Для extraction — `output` будет валидным JSON с нужными полями (артикул, партия, масса). Дедупликация и очистка: удалите точные дубликаты, а также вычислите near‑duplicates (например, описание «трещина корпуса 2 мм» и «трещина корпуса ~2 мм»). Это предотвратит утечку данных между train и holdout. Train/val/holdout split (80/10/10): если данные привязаны к датам, train формируйте из более старых периодов, а holdout — из последних недель перед проектом. Принцип: модель не должна видеть будущие данные во время обучения. Нарушение этого правила — главная причина ложных высоких метрик и провала в production. Baseline‑обучение: запустите LoRA‑fine‑tuning небольшой модели (3–7B параметров, например Qwen2.5‑3B или RuGPT3.5) на подготовленных данных. Это занимает 2–4 дня работы data‑инженера с арендованным GPU. Если готового специалиста нет, разумно привлечь подрядчика именно на фазу настройки пайплайна — дальше модель может поддерживать DevOps. Стоп‑лист данных — что не подходит без серьёзной предобработки • Несбалансированные классы (0,1% брака) без стратегии oversampling. • Временнóй дрейф меток: старые классификации не соответствуют сегодняшним стандартам (производство изменилось, брак классифицируют иначе). • Противоречивая разметка от разных экспертов без утверждённого единого справочника. • Логи с персонализированной информацией без анонимизации. • Данные на разных языках вперемешку без указания языка. Если ваши данные попадают в этот список, вернитесь к шагу аудита — потребуются дополнительные ресурсы. FAQ, который встаёт на этом этапе: сколько примеров реально нужно? Для классификации дефектов — 500–2000, для structured extraction — 2000–10 000, для генерации отчётов — от 3000. Оптимальный объём можно уточнить итеративно: обучитесь на 200 примерах, оцените качество, потом на 500, потом на 1000, пока прирост accuracy не станет меньше 0,5 процентных пункта. Выбор конкретной архитектуры модели на этом этапе вторичен. Подробный разбор open‑weight вариантов с учётом российского парка GPU — в статье «Open‑weight модели on‑prem в 2026». Шаг 3: Eval‑метрики для производственной модели Публичные бенчмарки (MMLU, MATH) не показывают, ловит ли модель трещины корпуса или путает партию сырья. Оценка строится на вашем доменном holdout. Минимальный набор метрик для production: Метрика | Цель (go) | Зачем Task‑specific accuracy | > 90% | Основная точность классификации/извлечения JSON‑compliance rate | > 98% | Доля ответов, валидных по JSON‑схеме (для extraction) Latency p95 на edge‑сервере | < 100 мс | Вписывается в такт линии или процесс оператора Hallucination rate (FACT) | < 5% | Для задач с объяснением аномалий — фактическая верность Recall для minority классов | > 70% | Ловит редкие, но критичные дефекты Проводите замеры на изолированном holdout‑датасете, который модель не видела ни при обучении, ни при валидации. Если через 2–3 итерации fine‑tuning метрики не достигают порогов, у вас три опции: • увеличить обучающую выборку, • перейти на модель чуть большего размера (например, 7B вместо 3B), • спроектировать гибрид: SLM выполняет первичное решение, а сложные кейсы передаёт на верификацию облачному LLM или инженеру. Важно: никогда не смешивайте train и holdout данные из одного временного окна. Так вы получите завышенные оценки accuracy и рискуете пропустить ошибки в production. Шаг 4: Интеграция в производственный контур и мониторинг Обученная модель — это артефакт. Её нужно встроить. Edge‑деплой: сервер с GPU (NVIDIA RTX 4090 или Jetson AGX) размещается непосредственно в цехе, в изолированном сегменте сети. Модель обслуживается через REST API (FastAPI или аналог) с JSON‑схемой ответа. Критично: API должен возвращать результат за один вызов, без состояния. Интеграционная схема: SLM → JSON‑output → HTTP‑запрос в MES/1С → бизнес‑логика. Если модель не уверена (confidence логита ниже порога, или JSON не прошёл валидацию), срабатывает fallback: • запрос уходит облачному LLM (при разрешённом канале), • или помещается в очередь на ручную валидацию оператором ОТК. Такая двухконтурная архитектура гарантирует, что даже при резком дрейфе данных брак не уйдёт в цех. Production‑мониторинг. Без него модель деградирует через 4–8 недель после запуска, потому что производственные условия меняются: новый SKU, другое сырьё, модификация линии. Внедрите три элемента: 1. Дрифт‑трекер по эмбеддингам. Раз в неделю вычисляйте среднее расстояние между эмбеддингами запросов из production и из train‑выборки. Резкий скачок — сигнал к переобучению. 2. Автоматический замер ключевых метрик. Отбирайте случайную выборку новых запросов, прогоняйте через модель и сравнивайте с эталонными решениями (если есть) или старыми разметками. 3. Touchless rate. Доля запросов, обработанных без human‑review. Целевой порог для зрелого деплоя — > 70%. Падение до 50% означает, что модель перестала справляться без вмешательства. Организуйте петлю обратной связи: запросы, отправленные на ручную проверку, впоследствии попадают в обучающий датасет для следующей итерации fine‑tuning. За 2–3 цикла модель учится на реальных кейсах. Шаг 5: TCO‑расчёт и break‑even для вашего процесса Ключевой вопрос ЛПР: когда edge‑SLM обходится дешевле облачного API или аренды GPU в VPC провайдера. Ниже — сравнение в рублях, исходя из реалий 2026 года для среднеразмерной производственной линии (10 000 запросов в день, средняя длина запроса 250 токенов). Статья затрат | On‑prem (сервер с RTX 4090) | VPC‑аренда GPU (A100) | Облачный API (YandexGPT/GigaChat) Капитальные затраты | Сервер + GPU ~ 250 000 руб. | — | — Амортизация в месяц (3 года) | 7 000 руб. | — | — Электричество/охлаждение | 5 000 руб. | — | — DevOps/MLOps (20 ч/мес × 2 500 руб.) | 50 000 руб. | 50 000 руб. | 10 000 руб. (мониторинг интеграции) Аренда/инференс | — | 70 000 руб. (фикс) | 37 500 руб. (оплата по токенам) Итого операционных в месяц | 62 000 руб. | 120 000 руб. | 47 500 руб. *Допущения:* стоимость облачного API — 0,5 руб./1000 токенов; аренда A100 у Selectel — около 70 000 руб./мес; тариф DevOps‑специалиста — 2500 руб./час. Цены актуальны на 2026 год. При 10 000 запросов/день облачный API дешевле операционных расходов on‑prem. Перелом наступает на уровне ~15 000 запросов/день — собственный сервер начинает экономить 10–15% по сравнению с API, а при 30 000 запросов/день разрыв достигает 50% и более. Для завода, на котором SLM обслуживает несколько участков, это стандартный объём. Добавьте единоразовые затраты на размеченные данные: разметка 2000 примеров силами отдела качества или аутсорс — 200–400 тыс. руб. С учётом этой инвестиции горизонт окупаемости полного проекта — 8–18 месяцев. Подробный калькулятор с триггерами по latency, токенам и изолированной сети — в материале «Малые LLM на производстве: когда edge‑модель дешевле облака». Чеклист go/no‑go: 10 контрольных точек Перед запуском пилота последовательно проверьте эти пункты — каждый даёт объективную оценку готовности именно вашего процесса. 1. Latency‑бюджет < 100 мс? Обязателен edge‑GPU. 100–500 мс — допускается VPC‑деплой, риск конкуренции за ресурсы. > 500 мс — облачный API приемлем. 2. Объём запросов > 5 000/день? При небольших объёмах облачный API выгоднее; если менее 500 запросов/день, SLM не оправдывает затраты на инфраструктуру. 3. Сеть изолирована и нет стабильного канала в интернет? Тогда только on‑prem (локальный сервер). Даже 4G‑роутер с разрывами исключает облачное решение для inline‑задач. 4. Имеется как минимум 500 размеченных примеров? Нет — оцените стоимость разметки: сможете ли вы вложить 200–400 тыс. руб. и получить готовность за 2–3 недели. 5. Есть fallback‑сценарий? Если нет, ошибка модели может остановить приёмку или пропустить брак. Определите ручную петлю или второй контур верификации до деплоя. 6. Данные чистые, без PII и без критического дрейфа меток? Заложите неделю на анонимизацию и нормализацию справочников. 7. В штате или по контракту доступен DevOps‑инженер, готовый обслуживать REST API и мониторинг? Это необходимо с первого дня production. 8. Выделен физический сервер с GPU в цехе (RTX 4090/Jetson) или бюджет на его аренду? Без GPU latency не уложится в заданные рамки. 9. Интеграция с MES/1С проработана: есть API или очередь сообщений? Без этого SLM останется изолированным скриптом. 10. Проектная окупаемость при текущем объёме запросов наступает за < 18 месяцев? Если нет, пересмотрите масштаб внедрения или отложите до увеличения потребности. Если по всем пунктам ответ «да» — переходите к запуску пилота. План: 2 недели на аудит и подготовку данных, 2 недели на fine‑tuning и eval, 2 недели на интеграцию и тестирование в контуре, и ещё 2 недели на пилотный мониторинг. Итого 8 недель до минимального production‑ready варианта. Матрица пригодности производственных задач Задача | Подходит SLM? | Комментарий Классификация дефектов по тексту | ✓ | 500–2000 примеров, высокая точность, низкая latency. Объяснение аномалий телеметрии | ✓ | Узкая доменная лексика, SLM справляется с генерацией кратких отчётов. Hallucination rate под контролем через holdout. Structured extraction (артикулы, партии) | ✓ | Чёткая JSON‑схема, требования compliance >98%. Генерация отчётов ОТК по шаблону | ✓ | Требует 3000+ примеров, но даёт стабильное качество. Сложный multi‑step reasoning (например, анализ цепочки брака по трём цехам) | ✗ | SLM не хватает глубины рассуждения, целесообразно отдавать облачному LLM. Мультимодальный анализ (изображение + текст) | ✗ | Нужны специализированные VLM‑модели, не SLM. Эта матрица помогает отсеять задачи, где SLM не даст результата, и сфокусировать ресурсы на быстрых победах. Что дальше Вы прошли пять шагов: аудит → данные → метрики → интеграция → экономика. Итог — работающая edge‑модель, встроенная в производственный контур, с прозрачным мониторингом и понятным TCO. Внедрение такого проекта без ML‑отдела реально: основные узкие места — разметка данных и первый пайплайн fine‑tuning — закрываются партнёрским участием, а поддержка и сопровождение укладываются в компетенции сильного DevOps‑инженера. Остались вопросы по выбору триггеров окупаемости? Читайте «Малые LLM на производстве: когда edge‑модель дешевле облака». Нужен подробный гайд по выбору open‑weight модели под ваше железо — вам в статью «Open‑weight модели on‑prem в 2026». Первый production‑ready edge‑SLM на вашей линии — это 8–10 недель работы команды из одного‑двух человек и набора чётких метрик. Начните с аудита данных сегодня же. Ключевые факты • Подготовка данных и разметка занимают до 60% времени проекта внедрения edge‑SLM. • Для классификации дефектов достаточно 500–2000 размеченных примеров, для extraction — от 2000. • Break‑even on‑prem против облачного API наступает при объёме ~15 000 запросов/день. • Дрейф данных на производстве без мониторинга приводит к деградации модели через 4–8 недель. • Сквозной пайплайн от сырых журналов до production‑мониторинга реально выстроить за 6–10 недель.