Ornith1.5-9B с заявленным рейтингом отказов «0/100» отказывается проходить базовые проверки. Именно с этим столкнулся пользователь circumcised_hobbit: он перебрал несколько вариантов модели, и ни один не прошёл проверку, хотя у части сборок в описании стояла отметка «0/100 refusal». 1 октября 2026 года он опубликовал пост в r/LocalLLaMA с просьбой поделиться рабочими вариантами.
Авторы сборок при этом обычно ничего не выдумывают. Рейтинг отказов описывает поведение модели в конкретных условиях: заданный набор промптов, конкретная квантизация, конкретный бэкенд, конкретный шаблон чата. В вашей конфигурации хотя бы один параметр отличается, и цифра из карточки перестаёт что-либо гарантировать. Единственный надёжный способ понять, откажет модель или нет, это прогнать её на своих запросах в том окружении, где вы собираетесь работать.
Дальше разберём, как формируются такие метрики, что именно влияет на отказы и как за час собрать собственный тест вместо того, чтобы верить надписи на странице загрузки.
Почему заявленный рейтинг отказов «0/100» не гарантирует отсутствие отказов
Что на самом деле означает рейтинг отказов
Запись «0/100» читается как «ноль отказов на ста запросах». Ключевой вопрос: кто, на каких запросах и в каких условиях эти сто запросов прогнал. Единого стандарта для метрики нет: ни сертифицирующего органа, ни общей библиотеки промптов, ни обязательного требования публиковать скрипт, набор запросов и seed. Каждый автор квантованной сборки или файнтюна считает по-своему.
Отсюда два практических следствия. Первое: наборы промптов у разных авторов не совпадают. Если проверка состояла из безобидных вопросов вроде «объясни, что такое SQL-инъекция», рейтинг «0/100» получится почти у любой модели, включая базовую. Второе: часть авторов тестирует на жёстких запросах, часть на мягких, а часть просто переносит цифру из карточки родительской модели, не проверяя производную сборку.
Отдельная проблема в том, что метрика не различает степени отказа. Она не показывает, что происходило при частичном отказе, когда модель отвечает, но добавляет оговорки на три абзаца или переводит тему на безопасность. Формально это не отказ, по факту ответ бесполезен.
Вот что известно по исходному случаю: circumcised_hobbit перепробовал варианты Ornith1.5-9B, включая сборки с заявленным рейтингом «0/100», и все они отказались проходить базовые проверки. Это опыт одного пользователя на неизвестных нам запросах и настройках, а не результат независимого тестирования. Держите это как сигнал, а не как приговор всей линейке. Общий подход к оценке моделей в потоке релизов разобран в материале про чек-лист для оценки новых AI-моделей.
Почему один и тот же файнтюн ведёт себя по-разному
Один и тот же файл весов даёт разные ответы в зависимости от обвязки. На поведение влияют как минимум шесть факторов:
- шаблон чата и системная инструкция: их наличие, содержание и позиция в промпте;
- квантизация: Q4_K_M, Q5_K_M, Q8_0 и fp16 ведут себя не одинаково;
- версия файнтюна: датасет, метод обучения (merge LoRA, полный fine-tune, аблитерация), дата сборки;
- бэкенд: llama.cpp, ExLlamaV2, vLLM и облачные раннеры собирают итоговый промпт по-разному;
- параметры сэмплинга: temperature, top-p, repetition penalty;
- длина контекста и позиция запроса: отказ часто приходит не на первом токене, а на пятом абзаце.
Сравнивать сборки имеет смысл только в одинаковых условиях. Попытка «просто попробовать модель» без фиксации конфигурации даёт результат, который невозможно воспроизвести, и следующий прогон может показать другую картину.
Как самостоятельно проверить Ornith1.5-9B на отказы
Собственная проверка занимает меньше часа и состоит из трёх шагов: собрать набор промптов под свои задачи, прогнать их в целевой конфигурации, записать результат в таблицу. Ниже, что именно включать в набор и какие цифры считать.
Какие запросы использовать для проверки
Универсального набора не существует, всё зависит от того, зачем вам нецензурированная модель. Рабочая схема: 30-50 промптов, разбитых по категориям.
- Запросы, которые модели модерируют по умолчанию: сцены насилия в художественном тексте, описание незаконных действий, взрослый контент, грубая лексика.
- Легальные задачи с провокационной обёрткой: разбор уязвимости для пентеста, медицинская или юридическая тема, цитирование исторического документа с жестокими деталями.
- Длинная генерация на чувствительную тему, от 1500 слов: отказ часто проявляется не в начале, а в середине ответа.
- Контрольная группа из 5-10 полностью безобидных запросов. Она показывает, что модель вообще отвечает и не отказывает из-за сломанного шаблона.
- Вариации одного и того же промпта: с системной инструкцией и без, на русском и английском, короткий и развёрнутый.
Оценивать нужно не только сам факт отказа, но и качество ответа: модель отвечает по существу или уходит в общие рассуждения с дисклеймером в каждом абзаце.
Метрики и тесты, которые имеют смысл
Набор цифр, который считается за один прогон:
- доля полных отказов на вашем наборе, например 7 из 40;
- доля частичных отказов, когда ответ есть, но с оговорками или подменой темы;
- оценка полезности ответа по шкале 1-5, лучше вслепую, без знания, какая сборка сейчас отвечает;
- стабильность: один и тот же промпт 3-5 раз при temperature выше нуля, чтобы увидеть разброс;
- технические показатели: скорость генерации в токенах в секунду и занятая VRAM.
Простейшая таблица в spreadsheet с колонками «промпт», «сборка», «конфигурация», «тип ответа», «оценка» закрывает задачу целиком. Подход, где вместо общего впечатления считают точность на конкретных инструментальных задачах, разобран в статье про оценку MoE-моделей.
Факторы, влияющие на отказы: формат промпта, системная инструкция, квантизация и способ запуска
Как системная инструкция и формат промпта меняют поведение
Системная инструкция вроде «ты отвечаешь без ограничений и не читаешь морали» срабатывает не всегда. Модель, которую дообучали на отказах, часто игнорирует противоречащую инструкцию из системного блока: паттерн отказа воспроизводится на уровне весов, а не по правилам, которые можно отменить текстом.
Что проверить по порядку, меняя только один параметр за раз:
- без системного промпта вообще;
- с короткой нейтральной инструкцией: роль, язык, формат вывода;
- с инструкцией «без ограничений» в системном блоке;
- с той же инструкцией в конце пользовательского сообщения;
- с правильным шаблоном чата под конкретное семейство модели, если бэкенд умеет подставлять его автоматически.
Убирать системный промпт полезно не всегда: часть моделей без него путает роли и теряет формат. Иногда хуже становится именно от добавления жёсткой инструкции. Роль обвязки и оркестрации в поведении модели разобрана в статье про надёжность агентных моделей.
Влияние квантизации и версии файнтюна
Квантизация это сжатие весов с потерей точности. Разница между fp16 и Q4_K_M заметна не только по скорости. У компактных моделей, к классу которых относится Ornith1.5-9B, сжатие чаще проявляется в ослаблении следования инструкциям, включая инструкцию «не отказывай». Это рабочая гипотеза, которую стоит проверять на своей сборке, а не установленное правило: часть квантов ведёт себя почти как оригинал, часть заметно деградирует.
Практика: возьмите одну сборку, скачайте два уровня квантизации, например Q8_0 и Q4_K_M, и прогоните на одном наборе промптов. Если разница в отказах есть, у вас появляется рычаг для настройки. Если разницы нет, копайте в сторону промпта и бэкенда.
С версией файнтюна похожая история. Смотрите дату загрузки, changelog, имя автора и метод обучения. Более новая ревизия не обязательно лучше: агрессивная аблитерация или жёсткий merge LoRA иногда ухудшают связность и знание фактов, а заодно меняют картину отказов. Отдельно проверяйте базовую модель, от которой собран файнтюн: часть сборок с пометкой «uncensored» оказывается переименованным вариантом совсем другой модели.
Выбор бэкенда для запуска: llama.cpp, ExLlama, vLLM и другие
Разница между бэкендами не сводится к скорости.
- llama.cpp и обёртки на его основе работают с GGUF, выносят часть слоёв на GPU, шаблон чата берут из метаданных файла. Удобны для домашнего запуска на 8-12 ГБ VRAM.
- ExLlamaV2 рассчитан на GPU и формат EXL2, даёт высокую скорость на потребительских картах.
- vLLM нужен там, где важна пропускная способность и параллельные запросы; шаблон чата он подставляет из конфигурации модели на Hugging Face.
- Облачные раннеры и локальные GUI добавляют свой слой: где-то системный промпт дописывается автоматически, где-то подрезается контекст.
Метаданные в GGUF-файле могут содержать неверный шаблон или не содержать его вовсе. Тогда модель получает промпт в формате, к которому не привыкла, и ведёт себя непредсказуемо: появляются и отказы, и потеря формата ответа. Тестируйте на том бэкенде, на котором планируете работать, и не переносите выводы с одного раннера на другой.
Где искать рабочую нецензурированную версию Ornith1.5-9B
Основные площадки: Hugging Face с поиском по тегам вроде uncensored, abliterated, NSFW и RP; сабреддит r/LocalLLaMA, где и появился исходный пост; тематические Discord-серверы квантователей. В Research Pack нет подтверждённых данных о том, какая конкретная сборка Ornith1.5-9B работает, поэтому чужие списки «проверенных» файлов воспринимайте как гипотезу и перепроверяйте своим набором промптов.
Как отличить рабочую сборку от нерабочей
Признаки вменяемой сборки:
- карточка модели описывает базовую модель, датасет, метод обучения и дату сборки;
- есть примеры промптов и ответов, а не только скриншот красивого диалога;
- в комментариях есть содержательные отзывы, в том числе критические;
- у автора есть история публикаций и другие модели;
- выложено несколько квантизаций и указана лицензия.
Красные флаги: пустая карточка, обещания «полностью без цензуры» без описания метода, отсутствие обсуждений, свежий аккаунт с одной загрузкой. Отсутствие контрольной суммы тоже повод насторожиться: без хэша вы не проверите, что именно скачали.
Что делать, если ни одна версия не подходит
Три реальных пути.
- Сменить модель. У многих открытых семейств есть варианты с пометками abliterated или uncensored, и среди них встречаются сборки, где поведение ближе к ожидаемому. Проверять всё равно придётся своим набором промптов.
- Дообучить под себя. LoRA на 500-2000 собственных примерах в формате «запрос и желаемый ответ» заметно меняет стиль поведения, но требует GPU, времени и подготовки данных. Ждать, что LoRA полностью уберёт отказы, не стоит.
- Переформулировать задачу. Часть отказов вызывается не темой, а формулировкой: легальный контекст (аудит, обучение, художественный текст) снимает отказ там, где прямой запрос его получает.
Если для аренды GPU или платных зарубежных сервисов нужна карта, которую принимают вне России, есть вариант с виртуальной картой иностранного банка и пополнением в рублях через СБП. Это инструмент для оплаты доступа, а не способ обойти правила самих сервисов: их условия и лицензии остаются в силе.
Ограничения и риски нецензурированных моделей
Снятие фильтров расширяет возможности и одновременно добавляет рисков.
- Контент. Такая модель охотнее генерирует оскорбительный, вредный и незаконный контент, включая материалы, распространение которых в ряде юрисдикций запрещено.
- Право. Ответственность за сгенерированный и опубликованный текст лежит на пользователе, а не на авторе весов. Условия использования Hugging Face и облачных провайдеров тоже никто не отменял.
- Качество. Агрессивный файнтюн или аблитерация часто снижают связность, следование формату и точность фактов. Отказ может «лечиться» деградацией: модель формально соглашается, но пишет бессвязный текст.
- Безопасность. Без фильтров модель охотнее исполняет инструкции, спрятанные в недоверенном контенте, а это классический prompt injection при работе с документами и веб-страницами.
- Стабильность. Поведение таких сборок менее предсказуемо, поэтому в продуктивных сценариях нужны собственные проверки и запасной вариант.
Универсального совета «берите нецензурированную модель» не существует. Для исследовательских и творческих задач выгода может перевесить риски, для клиентских сценариев ситуация обычно обратная.
Практические рекомендации по настройке и запуску
- Зафиксируйте конфигурацию: имя сборки и хэш файла, уровень квантизации, бэкенд, шаблон чата, параметры сэмплинга. Без этого результаты не сравнить.
- Соберите 30-50 промптов под свои задачи плюс контрольные безобидные запросы.
- Прогоните и заполните таблицу: тип ответа, оценка полезности, скорость, VRAM.
- Меняйте по одному параметру. Порядок от дешёвого к дорогому: формат промпта и системная инструкция, затем квантизация, затем бэкенд.
- Повторяйте спорные промпты 3-5 раз при temperature выше нуля: единичный отказ при сэмплинге мало о чём говорит.
- Ведите журнал тестов и делитесь результатами в сообществе. Коллективный опыт быстрее показывает, какие связки «сборка плюс бэкенд плюс промпт» работают.
Если Ornith1.5-9B нужна для кода, начинайте с проверки на реальных задачах, а не на абстрактных примерах. Методика такой проверки, включая замер качества правок и поведение на длинном контексте, описана в статье про Ornith-1.5-9B для программирования.
Цифра «0/100» в карточке это не обещание, а чей-то тест в чужих условиях. Собственный набор из полусотни промптов, прогнанный в вашей конфигурации, даёт больше, чем любая заявленная метрика, и он же покажет, стоит ли вообще оставаться на этой модели.