Для краткого описания действий локального AI-агента начните с компактной instruct-модели, которая хорошо понимает код и технические тексты. Универсального победителя для этой задачи нет: подходящий SLM выбирают по точности коротких описаний, соблюдению заданного формата, скорости на целевой машине и устойчивости к разным языкам программирования.
Модуль не должен пересказывать весь файл или выполнять полноценный code review. Его задача уже: получить diff, фрагмент кода, цель шага и результат работы инструмента, после чего выдать одну короткую фразу для action log. На практике полезнее модель, которая стабильно пишет «добавлена проверка токена перед запросом к API», чем модель с высоким рейтингом в длинном диалоге, но склонная додумывать причины изменений.
При выборе проверяйте не один удачный ответ, а серию вызовов. Зафиксируйте prompt, ограничение длины, параметры генерации, квантизацию, потребление RAM и VRAM, задержку первого токена, показатели prefill и decode, а затем прогоните одинаковый набор изменений на нескольких кандидатах.
Короткий ответ: выбирайте не обычный суммаризатор, а компактную code-capable instruct-модель
Для этой задачи лучше всего подходит класс компактных instruct-моделей с обучением на коде, diff и технической документации. Instruct-настройка помогает соблюдать инструкции и выдавать ответ в фиксированном виде, а code-capable обучение снижает риск, что модель примет имя функции или комментарий за смысл изменения.
Универсальная текстовая модель тоже может справиться с простыми правками. При сложных изменениях она чаще описывает намерение слишком общо, путает причину и результат или добавляет детали, которых нет во входе. Поэтому общий рейтинг, размер контекстного окна и красивый ответ в чате нельзя использовать как единственные критерии.
В доступных материалах нет подтвержденного рейтинга SLM для code summarization. Корректная стратегия выглядит так: выбрать несколько компактных instruct-кандидатов, добавить один-два code-oriented варианта, проверить их в нужной квантизации и оставить модель с приемлемым числом смысловых ошибок на собственном наборе примеров.
Что должно получаться на выходе
Сначала зафиксируйте назначение сообщения. Если оно попадет в историю действий агента, читателю нужно быстро увидеть объект изменения и результат. Причины, архитектурные рассуждения и пересказ каждой строки здесь мешают.
- Одна фраза: «добавлена проверка токена перед запросом к API».
- Одна фраза: «обновлена конфигурация подключения к базе данных».
- Структурированные поля: изменение, цель, результат.
- Короткое сообщение об ошибке, если шаг завершился неудачно.
Для интерфейса журнала можно задать такой формат:
{"summary":"добавлена проверка токена перед запросом к API","result":"успешно"}Ограничение в одно предложение или 20-40 токенов часто полезнее свободного ответа. Конкретный предел зависит от интерфейса и длины русских формулировок, поэтому его нужно проверить на реальных примерах. Модель не обязана находить все дефекты, объяснять архитектуру, писать код или выдавать полный review.
Почему размер важен, но не определяет качество в одиночку
Меньшая модель обычно требует меньше памяти, быстрее отвечает на коротком входе и проще запускается на клиентском ПК. Это особенно удобно, если агент вызывает модуль описания после каждого изменения файла. При этом сокращение числа параметров уменьшает запас для понимания неоднозначных diff, редкого синтаксиса и связи между несколькими файлами.
Качество маленького SLM сильнее зависит от состава обучающих данных, instruction-тюнинга, шаблона prompt и качества переданного контекста. Модель на сотнях миллионов параметров может уверенно обрабатывать типовые изменения, если задача узкая и формат ответа строго задан. Та же модель начнет пропускать смысл при многофайловой правке, где причина изменения находится за пределами переданного фрагмента.
Размер весов нужно сопоставлять с форматом запуска. Один и тот же кандидат в полной точности, 8-битном и 4-битном вариантах даст разное потребление памяти и может по-разному соблюдать формат. Итоговое решение принимайте по паре «качество описания плюс задержка», а не по числу параметров в карточке модели.
Чем описание действий агента отличается от обычного суммирования кода
Обычный суммаризатор отвечает на вопрос «о чем этот код». Модуль в AI-агенте отвечает на вопрос «что изменилось на этом шаге и каким оказался результат». Разница определяет и входные данные, и требования к модели.
Агент может получить цель, составить план, вызвать инструмент, изменить файлы, запустить тесты и исправить ошибку. Planning превращает понимание задачи в последовательность действий. Reasoning помогает понять контекст и сделать вывод. SLM для журнала не должен повторять весь цикл рассуждения: он получает технический след конкретного шага и переводит его в короткое сообщение.
Вход: код, diff, инструмент и результат шага
Минимальный вход состоит из измененного фрагмента или diff и инструкции по формату ответа. Такой вариант подходит для очевидных правок: добавления проверки, переименования переменной, обновления параметра или изменения теста.
Расширенный вход полезен, когда одного кода недостаточно:
- цель шага, например «добавить авторизацию к запросам»;
- название инструмента, например редактор файла, shell-команда или тестовый раннер;
- diff с несколькими строками окружения;
- связанные файлы, если изменение затрагивает импорт или конфигурацию;
- результат выполнения, включая успешный тест или текст ошибки.
Лишний контекст увеличивает задержку и дает маленькой модели больше возможностей для отвлечения. Передавайте историю диалога только тогда, когда без нее нельзя определить смысл изменения. Для простого переименования длинная переписка агента не принесет пользы.
Planning и Reasoning: что именно должен делать модуль
В агентном сценарии система сначала понимает задачу, затем строит план и вызывает инструменты. Например, цель «исправить обработку авторизации» может привести к поиску обработчика, изменению middleware, запуску тестов и повторной правке после ошибки.
Основной агент выполняет Planning и принимает решения. SLM получает результат конкретного действия: измененный файл, выполненную команду или вывод теста. Его роль ближе к нормализатору технического журнала, чем к самостоятельному планировщику.
Одна цепочка может включать 5-15 шагов до следующего запроса пользователя. Поэтому проверяйте устойчивость серии: формулировки должны оставаться краткими, не менять факты и не накапливать выдуманные детали. Удачный ответ на первом шаге еще не доказывает пригодность модели для action log.
Что не нужно требовать от SLM
- Находить все баги в измененном коде.
- Проектировать архитектуру приложения.
- Самостоятельно строить сложный план работы.
- Объяснять каждую строку и каждую зависимость.
- Определять скрытую мотивацию автора правки.
- Подтверждать результат, если во входе нет данных о запуске тестов или команды.
Чем уже контракт, тем ниже требования к размеру модели. Если модулю нужно одновременно интерпретировать многофайловую историю, оценивать риски и предлагать следующий шаг, это уже другая задача для более крупной модели.
Какие классы моделей стоит пробовать в первую очередь
Кандидатов удобно разделить по специализации. Такой подход помогает сравнивать ожидаемое поведение, не привязываясь к рекламному названию или одному публичному показателю.
Компактные instruct-модели общего назначения с хорошим пониманием кода
Это отправная точка для агента, который работает с кодом, shell-командами, конфигурациями, документацией и сообщениями об ошибках. Универсальная модель может лучше справляться с русскими комментариями и смешанным техническим контекстом.
Проверяйте три риска. Модель может описывать изменение слишком общо, пропускать важный объект или приписывать правке несуществующий эффект. Для простых diff это допустимый кандидат, для сложных изменений потребуется более строгий тестовый набор.
При сравнении новых моделей полезно заранее фиксировать критерии: качество короткого ответа, контекст, скорость, API, поддержку нужного рантайма и требования к VRAM. Практический чек-лист для такой проверки собран в статье о системной оценке новых AI-моделей.
Небольшие code-oriented модели
Модели, обученные на программном коде и связанных технических данных, обычно лучше распознают синтаксис, структуру diff, импорты, тесты и конфигурационные файлы. Для короткого описания это полезная специализация: модель видит, что изменение касается проверки, маршрута, зависимости или параметра сборки.
Ориентация на генерацию кода сама по себе не гарантирует хорошую интерпретацию изменений. Модель может продолжить фрагмент или предложить исправление вместо описания уже сделанного шага. Instruct-настройка и жесткий prompt здесь важнее, чем одно наличие слова «code» в описании.
Материал о локальной модели Qwen3.5-0.8B показывает, почему узкая fine-tune-задача иногда полезнее универсального чат-сценария. Это пример подхода к выбору и проверке компактной модели, а не готовое подтверждение, что она лучше всех описывает код.
Модели, дополнительно адаптированные под короткие технические ответы
Для рабочего пайплайна перспективен instruction-tuning на собственных парах «действие агента - эталонное описание». В датасет можно включить diff, цель, инструмент, результат и правильную короткую формулировку.
Разметка должна быть единообразной. Для одной и той же операции используйте одинаковый уровень детализации, не смешивайте описание причины с описанием результата и явно отмечайте неуспешные шаги. Примеры должны покрывать несколько языков, операции удаления и переименования, конфигурацию и ошибки запуска.
Дообучение не гарантирует автоматического прироста качества. Маленький и однообразный датасет может закрепить шаблонные фразы, а противоречивые эталоны ухудшат соблюдение формата. Перед обучением сравните базовую instruct-модель с несколькими примерами few-shot: иногда строгого prompt достаточно.
Квантизированные версии как способ вписать модель в локальные ограничения
Квантизация уменьшает размер весов и требования к памяти. Благодаря этому SLM проще разместить на клиентской машине, где одновременно работают агент, редактор кода и тестовые процессы.
Цена экономии зависит от модели и рантайма. Снижение точности может проявиться в пропусках редких конструкций, нестабильной длине ответа, ошибках JSON или добавлении лишних пояснений. Сравнивайте полную и квантизированную версии на одинаковых входах, если память позволяет провести оба запуска.
Проверяйте файл весов, поддерживаемый формат, размер KV-cache, требования к RAM и VRAM, а также совместимость с выбранным локальным рантаймом. Один и тот же уровень квантизации на разных устройствах не дает одинаковой задержки.
Какой контекст передавать модели, чтобы короткий ответ оставался точным
Маленькая модель часто ошибается из-за плохой упаковки входа. Уберите нерелевантную историю, разделите цель и фактический diff, явно сообщите результат инструмента и задайте один формат ответа.
Минимальный prompt для одного действия
Для типовой правки подойдет инструкция с четырьмя ограничениями: описать выполненное действие, назвать измененный объект, указать результат и не добавлять сведений, которых нет во входе.
Задача: опиши одно выполненное действие агента.
Правила:
1. Напиши одно предложение длиной не более 25 слов.
2. Назови измененный объект и результат.
3. Не приписывай причины и эффекты, которых нет во входе.
4. Верни JSON с полем summary.
Цель: добавить проверку токена перед запросом к API.
Инструмент: изменение файла клиента API.
Diff:
- response = client.get(url)
+ response = client.get(url, headers=auth_headers)
Результат: тесты пройдены.Такой prompt отделяет намерение от факта. Если цель не совпадает с фактическим diff, модель должна описать изменение, а не подгонять ответ под желаемый результат. Ограничение длины снижает вероятность перехода к code review.
Практические приемы управления форматом и длиной ответа разобраны в материале о формулировках, которые меняют поведение LLM. Для SLM особенно полезны явные поля и запрет на домыслы.
Когда нужен diff, а когда - полный фрагмент
Diff обычно лучше полного файла, если нужно описать локальное изменение. В нем видны добавленные и удаленные строки, а несколько строк окружения помогают определить функцию или блок.
- Добавление проверки: diff и имя функции обычно достаточны.
- Переименование: передайте все затронутые строки и список файлов, иначе модель может описать только первый участок.
- Удаление кода: укажите удаленный блок, если его смысл неочевиден по соседним строкам.
- Новый файл: нужен полный короткий фрагмент или сводка созданных сущностей.
- Конфигурация: добавьте имя сервиса, среды и измененный параметр.
- Исправление ошибки: передайте сообщение ошибки и результат повторного запуска.
Для крупной функции полный фрагмент может превысить полезный объем контекста. В таком случае передавайте diff, сигнатуру функции, связанные импорты и краткую цель шага. Историю всех предыдущих действий оставляйте основному агенту.
Жесткий формат против свободного текста
Одно предложение проще для самой маленькой модели. Маркированные поля удобнее читать человеку. JSON подходит для интерфейса, фильтрации, аналитики и последующей маршрутизации, но требует проверки валидности.
| Формат | Плюс | Риск |
|---|---|---|
| Одно предложение | Минимальная нагрузка на модель | Сложнее извлекать отдельные поля |
| Поля «изменение», «результат» | Хорошая читаемость и предсказуемая структура | Модель может менять названия полей |
| JSON | Удобен для программной обработки | Возможны лишний текст, незакрытые кавычки и неверный тип значения |
Для SLM с ограниченным запасом качества начните с одного поля summary. Добавляйте result и files, когда модель стабильно соблюдает базовый контракт. После генерации проверяйте JSON парсером, а не регулярным выражением.
Локальный запуск: размер модели, память и задержка важнее громкого названия
Клиентский запуск оценивают на конкретной связке модели, квантизации, рантайма и оборудования. Значение из чужой конфигурации нельзя переносить на другой ПК без повторной проверки.
Что измерять на клиентской машине
- Пиковое потребление памяти: отдельно фиксируйте RAM, VRAM и общий расход во время загрузки и генерации.
- Время до первого токена: оно показывает, насколько быстро пользователь увидит начало сообщения.
- Скорость decode: измеряйте генерацию после обработки входа, обычно в токенах в секунду.
- Скорость prefill: фиксируйте время обработки diff и дополнительного контекста.
- Длина входа: один и тот же SLM может вести себя по-разному на коротком и расширенном prompt.
- Нарушения формата: считайте лишние пояснения, неверный JSON и превышение лимита слов.
- Поведение в серии: запускайте 20-50 последовательных запросов с разными действиями, чтобы увидеть накопление ошибок и скачки задержки.
Для журнала после каждого шага важна задержка полного ответа, а не пиковая скорость на одном запросе. При последовательных вызовах агент может ждать завершения SLM, поэтому несколько лишних секунд на каждый шаг быстро превращаются в заметную паузу.
Как читать показатели prefill, decode и concurrency
Prefill показывает, как быстро рантайм обрабатывает входной контекст. Decode описывает скорость генерации новых токенов. Concurrency означает число одновременных сессий или слотов, которые система обслуживает без полной остановки остальных запросов.
Для масштаба можно встретить высокопроизводительные конфигурации с 16 слотами одновременности, контекстом до 900K токенов, prefill около 680-705 токенов в секунду и decode около 20-24 токенов в секунду. Эти числа показывают, какие параметры измеряют при развертывании, но не задают требования для маленького SLM-модуля. Краткое описание diff обычно требует гораздо меньшего контекста.
При одном локальном пользователе concurrency может почти не влиять на выбор. Для команды или сервера с несколькими агентами этот показатель становится частью расчета. Сравнивайте его вместе с потреблением памяти: дополнительные слоты увеличивают нагрузку на KV-cache.
Чек-лист сравнения качества, контекста, скорости, стоимости и требований к VRAM есть в практическом разборе оценки AI-моделей. Для локального SLM список метрик нужно сократить до тех, которые влияют на ваш агентский цикл.
Почему максимальное окно контекста не должно быть главным критерием
Короткое сообщение о локальной правке редко требует огромного окна. Большой лимит контекста полезен для сложных агентных цепочек, но сам по себе не делает модель точнее на одном diff.
Избыточный контекст может ухудшить результат: модель начнет смешивать старую и новую версию файла, учитывать нерелевантные сообщения или повторять промежуточные планы. Для SLM важнее точный небольшой пакет: цель, diff, инструмент и результат.
Проверяйте несколько размеров входа: короткий diff, diff с окружением, два связанных файла и расширенный агентный лог. Если качество падает уже на втором варианте, большое заявленное окно не дает практического преимущества.
Как оценивать качество SLM без лишней романтики
Соберите закрытый набор реальных типов действий агента и прогоняйте всех кандидатов с одинаковыми prompt, параметрами генерации, ограничением длины и форматом входа. Оценка должна отделять правдоподобную фразу от точного описания фактического изменения.
Набор тестов: от простой правки до цепочки действий
В тестовый набор включите короткие и неоднозначные примеры. Каждый пример должен содержать входные данные и эталонное описание, составленное до запуска моделей.
- Добавление функции или метода.
- Исправление ошибки в условии или обработчике исключений.
- Изменение конфигурации подключения.
- Обновление зависимости и файла блокировки.
- Переименование переменной, функции или публичного метода.
- Удаление устаревшего кода.
- Изменение тестов.
- Правка нескольких связанных файлов.
- Неуспешный запуск команды и последующее исправление.
- Цепочка из 5-15 действий с отдельным описанием каждого шага.
Не публикуйте весь закрытый набор вместе с промптом, если он отражает внутренний код. Для сравнения достаточно обезличить имена и сохранить структуру изменений, ошибки и ожидаемый результат.
Критерии точности и полноты
Оценщик должен проверить факты, а не стиль фразы. Для каждого ответа отметьте следующие признаки:
- назван правильный файл, функция, параметр или другой объект;
- описано фактическое изменение, а не предполагаемая задача;
- отражен результат, если он присутствует во входе;
- не перепутаны способ реализации и эффект;
- не пропущен критичный смысл, например удаление проверки;
- нет выдуманных функций, файлов, причин, тестов и результатов;
- соблюдены длина и заданный формат.
Ответ «обновлена логика API» может звучать правдоподобно, но быть слишком общим. Ответ «добавлена проверка токена перед запросом к API» сохраняет проверяемый объект и смысл правки. Если токен во входе не упоминается, его появление считается галлюцинацией.
Устойчивость к языкам и нестандартному синтаксису
Проверяйте стек, который реально использует агент. В набор стоит включить Python, JavaScript или TypeScript, Go либо другой основной язык проекта, а затем shell, SQL, YAML, JSON и Dockerfile.
Добавьте комментарии на русском и английском, длинные идентификаторы, вложенные конструкции, неполный код и фрагменты с синтаксическими ошибками. Отдельные примеры должны содержать удаление строк, изменение отступов, перемещение блока и правку только комментария.
Мультиязычность касается двух уровней. Модель должна распознавать разные языки программирования и выдавать описание на русском. Если технические термины в проекте остаются на английском, заранее определите, нужно ли переводить их или сохранять исходные названия.
Нестандартный синтаксис, шаблоны генерации и конфигурационные DSL требуют отдельной проверки. Ошибка на редком формате может быть приемлема для локального журнала, если такой код редко встречается. Для критичного пайплайна нужен fallback.
Формальная оценка для рабочего пайплайна
Результаты удобно заносить в таблицу. Проценты относятся только к вашему набору, prompt, версии модели, квантизации и оборудованию. Их нельзя превращать в универсальный benchmark.
| Метрика | Что считать | Зачем нужна |
|---|---|---|
| Точность | Доля ответов без фактических ошибок | Показывает, можно ли доверять описанию без ручной правки |
| Полнота | Доля ответов, где отражен критичный смысл изменения | Отделяет точную фразу от слишком общего пересказа |
| Галлюцинации | Функции, файлы, причины и результаты, которых нет во входе | Показывает риск ложных записей в журнале |
| Соблюдение формата | Валидный JSON, нужные поля, лимит длины | Определяет пригодность для автоматической обработки |
| Средняя длина | Число токенов или слов в ответе | Помогает контролировать интерфейс и стоимость вычислений |
| Задержка | Время до первого токена и до полного ответа | Показывает влияние SLM на скорость агента |
Для спорных примеров храните причину оценки. Ошибки полезно разделять на пропуск смысла, неверный факт, лишнюю деталь и нарушение структуры. Такая классификация показывает, что именно нужно менять: модель, prompt, контекст или правила маршрутизации.
Практический алгоритм выбора: от требований к конкретному SLM
Выбор можно свести к короткому циклу: определить контракт, собрать примеры, отобрать классы моделей, проверить локальный запуск и сравнить результаты в одинаковых условиях.
Если приоритет - минимальная задержка
Берите самую компактную модель, которая не искажает действие и стабильно соблюдает формат. Для каждого кандидата задайте одинаковый лимит ответа и измерьте полное время после 20-50 последовательных вызовов.
Шаблоны можно использовать для очевидных операций: «файл переименован», «зависимость обновлена», «тесты завершились с ошибкой». SLM оставьте для случаев, где нужно связать diff с целью шага. Такая комбинация сокращает число генераций и сохраняет единый стиль журнала.
Если приоритет - точность на сложных изменениях
Для неоднозначного diff, нескольких файлов и результата, который зависит от тестов, выбирайте более крупную code-capable instruct-модель или передавайте расширенный контекст. Дополнительная память оправдана, если маленький кандидат регулярно пропускает критичный эффект.
Предел сложности нужно определить измерением. Если модель правильно описывает отдельные файлы, но путается при изменении импорта, конфигурации и теста в одной цепочке, проблема уже выходит за пределы локального суммаризатора.
Модель крупнее не отменяет проверку фактов. Она тоже может выдумать причину или принять цель агента за выполненный результат. Сохраняйте тот же формат оценки и тот же лимит длины.
Если ресурсов мало, но качество должно быть предсказуемым
Используйте двухэтапную схему:
- Шаблон или правило обрабатывает очевидные операции с надежным сигналом, например переименование файла.
- Компактный локальный SLM описывает типовые изменения, где требуется понимание diff.
- Более крупная локальная модель или внешняя LLM получает сложные случаи, если политика работы с кодом разрешает передачу данных.
Маршрутизация по confidence требует осторожности. Самооценка модели не доказывает точность, поэтому порог нужно проверять на размеченных примерах. В качестве сигналов можно использовать неуверенный ответ, нарушение JSON, слишком общую формулировку, несколько файлов во входе или наличие ошибки выполнения.
Кэширование повторяющихся описаний снижает число вызовов. Ключом может служить нормализованный тип действия, хеш diff и результат команды. Кэш нельзя применять вслепую: изменение цели или версии файла должно создавать новую запись.
Итог: какой вариант считать удачным выбором
Удачный SLM для краткого описания действий агента - компактная code-capable instruct-модель, которая на вашей клиентской машине стабильно передает смысл изменения, соблюдает короткий формат и не добавляет неподтвержденные детали.
Когда SLM подходит для задачи
- Действия агента короткие и имеют понятный результат.
- Вход можно свести к цели, diff, инструменту и статусу выполнения.
- Ответ ограничен одной фразой или несколькими заранее заданными полями.
- Нужно вести локальный action log без отправки кода во внешний API.
- Основные языки, конфигурации и типы ошибок входят в тестовый набор.
- Допустимое число ошибок заранее определено для рабочего процесса.
В таком сценарии сверхмалый SLM может закрыть задачу быстрее и дешевле по ресурсам, чем крупная LLM. Решение подтверждается серией одинаковых тестов, а не размером модели или общим впечатлением от чата.
Когда лучше выбрать модель крупнее
Модель крупнее нужна при длинном контексте, неоднозначной цели, нескольких связанных файлах и требованиях объяснять причины изменений. Она пригодится и тогда, когда журнал должен связывать 5-15 шагов в единую историю, а не описывать каждый diff отдельно.
При жестких ограничениях устройства используйте fallback: шаблоны для простых операций, локальный SLM для типовых изменений и более крупную модель для неуверенных случаев. Такой маршрут дает понятный контроль над задержкой, памятью и риском ошибок.
Начните с code-capable instruct-класса, протестируйте несколько квантизированных вариантов на собственном наборе примеров и выберите самый маленький кандидат, который выдерживает нужные языки, форматы и последовательность вызовов. Хорошая модель для этого сценария определяется не максимальным контекстом и не громким названием, а короткими точными описаниями реальных действий агента.