Малые языковые модели: когда SLM лучше большой нейросети

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

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

Размер, лицензии и ограничения конкретной модели проверяйте по её официальной model card. Общие свойства LLM раскрыты в статье про большие языковые модели.

Опишите узкую задачу

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

• Рабочее действие: ограничить сценарий и ошибки.
• Сохраняемый артефакт: набор реальных запросов.
• Контрольная ситуация: модель извлекает номер заказа из письма.
• Показатель решения: точность по обязательным полям.

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

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

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

Постройте базовую линию

Этап «Постройте базовую линию» рассматривает текущий ручной процесс или большая модель. Меньшая модель выигрывает только тогда, когда проходит критерий качества на узкой задаче. Сбой возникает, когда непонятно, что именно улучшила SLM; поэтому сначала готовят таблица baseline, а затем выполняют «сохранить результаты сравнения».

• Рабочее действие: сохранить результаты сравнения.
• Сохраняемый артефакт: таблица baseline.
• Контрольная ситуация: оператор и LLM проходят те же сто писем.
• Показатель решения: разница качества и времени.

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

За этот участок отвечает аналитик. В журнале он связывает объект «текущий ручной процесс или большая модель» с артефактом «таблица baseline», записывает версию входных данных, условия запуска и принятое решение. Если показатель «разница качества и времени» улучшается ценой нового риска «непонятно, что именно улучшила SLM», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «сохранить результаты сравнения» должен воспроизводиться на примере «оператор и LLM проходят те же сто писем».

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

Проверьте память

Для раздела «Проверьте память» рабочая граница — веса, контекст и служебные буферы. Риск формулируется как «учитывают только размер файла». Меньшая модель выигрывает только тогда, когда проходит критерий качества на узкой задаче. Проверяемый ход — замерить пик на длинном входе, результат фиксируется в артефакте «профиль RAM и VRAM».

• Рабочее действие: замерить пик на длинном входе.
• Сохраняемый артефакт: профиль RAM и VRAM.
• Контрольная ситуация: квантованная модель помещается, но контекст вызывает сбой.
• Показатель решения: максимальное потребление памяти.

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

За этот участок отвечает инженер платформы. В журнале он связывает объект «веса, контекст и служебные буферы» с артефактом «профиль RAM и VRAM», записывает версию входных данных, условия запуска и принятое решение. Если показатель «максимальное потребление памяти» улучшается ценой нового риска «учитывают только размер файла», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «замерить пик на длинном входе» должен воспроизводиться на примере «квантованная модель помещается, но контекст вызывает сбой».

Разберите пример отдельно: квантованная модель помещается, но контекст вызывает сбой. Полезно попросить второго специалиста повторить шаг «замерить пик на длинном входе» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «веса, контекст и служебные буферы» владелец «инженер платформы» сверяет артефакт «профиль RAM и VRAM» с метрикой «максимальное потребление памяти».

Измерьте задержку

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

• Рабочее действие: считать p50 и p95.
• Сохраняемый артефакт: нагрузочный отчёт.
• Контрольная ситуация: короткая классификация не должна ждать длинную генерацию.
• Показатель решения: p95 задержки.

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

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

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

Проверьте критичные ошибки

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

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

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

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

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

Сравните формат

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

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

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

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

Разберите пример отдельно: вместо категории появляется абзац. Полезно попросить второго специалиста повторить шаг «валидировать схему автоматически» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «JSON, метка, короткий ответ или отказ» владелец «инженер интеграции» сверяет артефакт «журнал невалидных ответов» с метрикой «доля ответов по схеме».

Проверьте язык домена

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

• Рабочее действие: собрать словарь и трудные примеры.
• Сохраняемый артефакт: срез по терминам.
• Контрольная ситуация: модель различает возврат и отмену оплаты.
• Показатель решения: точность на доменном наборе.

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

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

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

Посчитайте стоимость

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

• Рабочее действие: разделить постоянные и переменные расходы.
• Сохраняемый артефакт: модель затрат.
• Контрольная ситуация: сервер окупается только при достаточной нагрузке.
• Показатель решения: стоимость тысячи запросов.

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

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

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

Определите маршрут эскалации

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

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

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

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

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

Зафиксируйте обновление

Свяжите пункт «Зафиксируйте обновление» с решением человека о контуре «версия весов, промпта и набора тестов». Меньшая модель выигрывает только тогда, когда проходит критерий качества на узкой задаче. Без шага «прогонять регрессию до релиза» и артефакта «отчёт сравнения версий» нельзя исключить ошибку «смена модели незаметно меняет поведение».

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

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

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

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

Матрица приёмки

Что изучить дальше

• локальная нейросеть
• большие языковые модели
• нейросеть для текста
• few-shot prompting
• контекстное окно
• системный промпт
• аудит ИИ-систем

Чек-лист запуска