В этом материале
Карточки LFM выделяют ограниченные текстовые задачи и прямо не рекомендуют программирование и глубокие задачи знаний.
LFM2.5 и LFM2 являются небольшими гибридными моделями с явно указанными границами задач. Их полезно проверять для узких текстовых решений, но карточки не обосновывают роль общего авторитета программирования или знаний.
Прочитайте область конкретной версии
Карточка LFM2.5-1.2B-Instruct описывает текстовую модель инструкций и не рекомендует программирование и задачи глубоких знаний. Карточка ранней LFM2 указывает похожую границу своего поколения.
Официальный каталог разделяет модели и форматы. Отчёт LFM2 объясняет гибрид коротких свёрток и attention. Более позднее дообучение способно менять поведение без изменения общей архитектурной семьи.
Для выбранной LFM2.5 карточка указывает 16 слоёв: 10 блоков double-gated convolution и 6 блоков GQA.
Используйте действительно узкую задачу
Подготовьте вымышленный классификатор обращений с явными метками и всей необходимой информацией во входе. Модель определяет запрос статуса, просьбу уточнения либо текст за пределами заданной области.
Предусмотрите неопределённость неоднозначных сообщений. Не просите угадывать недокументированное поведение продукта или отвечать на программирование только из-за похожего на код термина. Требуется классификация переданного текста, а не воспроизведение внешних знаний модели.
Сделайте границу решения наблюдаемой
| Случай | Требуемое поведение |
|---|---|
| Ясный запрос статуса | Выбрать объявленную метку статуса |
| Явное уточнение | Выбрать метку уточнения |
| Смешанный неоднозначный запрос | Выполнить правило неопределённости |
| Неизвестное утверждение продукта | Не придумывать дополнительные факты |
| Посторонний текст | Оставить вне таксономии |
Обеим версиям дайте одинаковые определения. Правка запроса, уточняющая спорную категорию, должна оцениваться отдельно от замены LFM2 на LFM2.5. Иначе полезность новой постановки будет незаметно приписана новой модели.
Изучите собственный путь вывода модели
Карточка LFM2.5 описывает соглашения инструментов и чата. Для текстовой классификации сохраните понятный интерфейс инструкций и исключите случайную трактовку обычного ответа как предложения вызова.
Фиксируйте точные checkpoint и формат. Ошибку загрузки артефакта учитывайте отдельной проверкой совместимости. При успешной загрузке с лишним текстом разделяйте оформление и неправильный класс. Эти результаты требуют разных способов исправления процесса.
Ограничьте утверждение улучшения
Храните набор входов, эталонные метки, версии запроса и принятые результаты. Сравнивайте пары перепутанных классов и неопределённые решения вместо единственной суммарной цифры. Сохраняйте все случаи, включая отсутствие пользы от обновления.
Итог обосновывает версию для проверенного узкого процесса. Он не устанавливает общих кодовых способностей, надёжной фактической экспертизы или результатов систем поиска и мультимодальности, отсутствовавших в задаче. Соблюдение области карточки помогает найти реальную ограниченную роль небольшой модели. Сохраняйте такие границы при переносе результата на другие обращения, языки и новые определения классов.