Пользователь Reddit под ником random-tomato открыл в r/LocalLLaMA обсуждение с жалобой: новые модели, включая Qwen3.8 27B и DeepSeek V4 Flash, выдают «ужасный, звучащий как Claude» стиль письма, который он не выносит. Для технических текстов такой стиль работает плохо, и автор поста прямо просит совета по более старым моделям, которые писали суше. Обсуждение доступно в ветке Older models for technical writing?
Готового списка старых моделей в этом обсуждении нет: вопрос остался открытым, а впечатление о стиле Qwen3.8 27B и DeepSeek V4 Flash - субъективная оценка одного пользователя, не результат измерений. Полезное там другое: описание симптома и объяснение, откуда берётся узнаваемый «ассистентский» тон. Прямой ответ на главный вопрос выглядит так: модель под техническое письмо выбирают не по дате релиза и не по месту в рейтинге кода, а по поведению на ваших собственных промптах, где проверяются длина предложений, количество оговорок и устойчивость к штампам.
Дальше разберём конкретную фразу из поста, механику гомогенизации стиля, критерии отбора модели для документации, приёмы промптинга и границы fine-tuning, continued pretraining и retrieval.
Что именно раздражает в «клаудовском» стиле
Претензия random-tomato сформулирована резко, но по существу: разные новые модели стали звучать похоже, и этот общий голос мешает читать технический текст. Однородность проявляется в распределении длины предложений, структуре абзацев и в конкретных словах, которые модель выбирает для перехода между мыслями. В разборе однотипности AI-текста приводятся характерные обороты: «delve into», «it's worth noting», «at its core», «in conclusion». Это не приговор конкретной модели, а опознавательные знаки общего корпуса и общего пайплайна обучения.
В техническом тексте такой голос читается как шум. Инструкция обрастает оговорками, совет превращается в перечисление условий, а действие, которое читатель должен выполнить, теряется в середине абзаца. Для runbook это уже не стилистическая придирка: если шаг описан как «вероятно, стоит проверить», дежурный инженер не поймёт, обязателен он или нет.
Пример с probe-тестами: разбор фразы
Автор поста приводит фразу, которую считает образцом неудобоваримого стиля:
A probe that asks what a language model memorised reports a null when the model answers at chance, and that null is evidence of absence only if the probe could have shown the fact. Two separate conditions have to hold, and checking the first does not establish the second.
Смысл здесь простой. Проба проверяет, что модель запомнила. Если модель отвечает на уровне случайного угадывания, проба возвращает null. Такой null доказывает отсутствие знания только при одном условии: проба в принципе могла это знание выявить. Проверка первого условия не гарантирует второго.
Что делает исходный вариант тяжёлым для чтения:
- Три условия упакованы в одно предложение на 40 с лишним слов, и читатель держит их в голове одновременно.
- Конструкция «null is evidence of absence only if» требует распутать двойное отрицание прежде, чем станет ясен вывод.
- Финальная фраза «Two separate conditions have to hold, and checking the first does not establish the second» пересказывает то, что уже сказано, и добавляет рефлексию вместо нового факта.
Сухой технический вариант строится иначе: утверждение, условие, вывод, каждое отдельным предложением. Читатель получает вывод в конце, а не выкапывает его из середины. Оценка исходной фразы как «неудобоваримой» принадлежит автору поста, и здесь она используется как иллюстрация, а не как объективная характеристика текста.
Почему новые модели пишут одинаково
Объяснение, которое даёт обсуждение, опирается на три связанных механизма. Это не измерения и не официальные заявления разработчиков, а разумная реконструкция того, как устроено обучение языковых моделей.
Пересечение корпусов и предсказание следующего токена
LLM обучены предсказывать статистически наиболее вероятный следующий токен. Обучающие корпуса конкурирующих моделей существенно пересекаются, поэтому распределения вероятностей выучивают похожие паттерны: одинаковые связки слов, одинаковые ритмы абзацев, одинаковые способы переходить от тезиса к примеру. Модель звучит как усреднённый голос своего корпуса, а корпуса у крупных игроков во многом одни и те же.
Отсюда и узнаваемость: если вы читаете технический текст, сгенерированный разными моделями, вы замечаете не разницу в знаниях, а совпадение манеры. Об этом же говорится в разборе однородности AI-письма: сходство проявляется именно в токенах переходов, а не только в лексике.
Роль alignment-тюнинга
Второй слой - пост-тренировочное выравнивание (post-training alignment fine-tuning), которое дополнительно сдвигает вывод к тону «полезного ассистента». Модель учится быть аккуратной, предупреждать о нюансах и смягчать утверждения. Для чата это часто плюс: пользователь не получает категоричных советов там, где они неуместны. Для технической документации тот же сдвиг оборачивается лишними «однако» и «в зависимости от контекста».
Практический вывод: «клаудовский» стиль не баг одной модели и не следствие одного релиза. Это результат общего рецепта обучения, поэтому смена версии сама по себе редко убирает манеру.
Чем такой стиль мешает технической документации
Цена стиля видна на конкретных жанрах: инструкция, runbook, описание API, заметка об инциденте. Осторожные оговорки размывают инструкцию, потому что читатель перестаёт различать обязательный шаг и рекомендацию. Однородные по длине предложения создают ровный шум: глаз не находит главное, приходится перечитывать абзац целиком. Рефлексивные конструкции вроде «два отдельных условия должны выполняться» повышают когнитивную нагрузку без прироста смысла.
Отдельная проблема - подмена фактов общими советами. В разборе адаптации модели под домен описан показательный случай с вымышленной платёжной системой: ассистент на базе стандартной фундаментальной модели отвечает «Please verify your Wi-Fi settings and ensure the authentication server is reachable», упуская протокол двухфазной фиксации, джиттер-бэкофф и обязательный токен идемпотентности из runbook. Формат ответа при этом аккуратный, тон вежливый, а пользы ноль.
Так канцелярит в текстах нейросетей превращается в операционный риск. LLM для написания инструкций оценивают не по тому, насколько гладко звучит абзац, а по тому, можно ли по этому абзацу выполнить действие и не пропустить обязательный шаг. LLM для технической документации должна держать структуру и терминологию, а не демонстрировать осторожность.
Критерии выбора модели для письма, а не для кода или чата
Бенчмарки кода и общие рейтинги чата не показывают, как модель пишет документацию. Код оценивают по прохождению тестов, чат - по субъективному предпочтению оценщиков, а техническое письмо требует третьего набора свойств. Вот что имеет смысл проверять.
- Управляемость тона. Реагирует ли модель на запрет конкретных оборотов. Если после явного «без вводных фраз» текст не меняется, промптом вы её не вытянете.
- Поведение на длинных структурированных инструкциях. Держит ли нумерацию шагов, не переставляет ли порядок, не склеивает ли два действия в одно.
- Склонность к осторожным формулировкам. Посчитайте, сколько раз на 500 слов появляются «однако», «в зависимости от», «стоит учитывать». Число само по себе показательно.
- Стабильность длины предложений. Если все предложения в абзаце по 25-30 слов, текст будет тяжёлым независимо от содержания.
- Отсутствие ассистентских вставок. «Надеюсь, это поможет», «дайте знать, если нужно дополнить» в документации лишние.
- Точность терминов. Сохраняет ли модель названия параметров, флагов и эндпоинтов без синонимических замен.
Как проверять модель на техническое письмо
Нужен свой небольшой набор задач, один и тот же для всех кандидатов, с одинаковыми промптами и одинаковыми настройками генерации. Три задачи закрывают основные жанры:
- Инструкция на 300 слов: установка утилиты с двумя ветками развития событий (успех и ошибка прав доступа).
- Runbook с условиями: что делать при таймауте, что при повторной ошибке авторизации, какой шаг обязателен всегда.
- Описание API на три эндпоинта: метод, параметры, коды ответа, один пример запроса.
Каждый прогон повторяют хотя бы дважды, чтобы увидеть разброс, и оценивают по списку критериев выше. Это не бенчмарк и не повод публиковать рейтинг: это практическая проверка на ваших данных, которая отвечает на ваш вопрос. Общая логика такой проверки разобрана в материале о том, как оценивать новые AI-модели без шума вокруг релизов.
Какие открытые и локальные модели рассматривать
Честный ответ: в обсуждении нет списка старых моделей, пригодных для технического письма. Автор поста сам просит совета, и ветка не даёт закрытого перечня. Любой готовый список здесь будет субъективным, потому что стиль зависит от промпта, жанра и конкретной сборки модели.
Почему готового списка нет
Причин три. Впечатление о стиле у каждого своё, и то, что один читатель называет сухим текстом, другой считает рубленым. Поведение модели меняется от системного промпта и квантизации сильнее, чем от разницы между соседними поколениями. И наконец, «старая» не значит «лучше»: предыдущие версии чаще ошибаются в фактах и хуже держат длинный контекст, поэтому выигрыш в тоне может обернуться проигрышем в точности.
Как собрать свой шорт-лист
Рабочий алгоритм выглядит так. Сначала определите жанр, под который выбираете модель: инструкция, runbook, API-референс. Затем подготовьте 3-5 тестовых промптов из предыдущего раздела. После этого прогоните кандидатов локально на одинаковых настройках и сравните по чек-листу, а не по первому впечатлению. В шорт-лист разумно включать модели предыдущих поколений, которые меньше затронуты новым alignment-пайплайном, и открытые сборки, где вы контролируете системный промпт и версию файла.
Для локального запуска считайте требования к VRAM заранее. Разбор того, как архитектура, контекстное окно, KV-cache и стоимость инференса влияют на выбор между локальной моделью и API, есть в материале про DeepSeek, Qwen и GLM в 2026 году. Открытые модели для документации стоит оценивать по тем же критериям, что и облачные: тон, структура, оговорки.
Промпт-инжиниринг: как убрать «клаудовский» стиль без смены модели
Самый быстрый способ - явные ограничения в промпте. Работают конкретные запреты на конкретные обороты, лимит длины предложения, задание регистра и требование структуры. В разборе подходов к настройке стиля отмечается, что этот путь быстрый, бесплатный и реально полезен для устранения очевидных признаков: он убирает слова-заполнители, задаёт общий тон и держит лимиты длины.
Пример промпта для технического текста
Ты редактор технической документации. Пиши сухо и по делу. Запрещены обороты: «важно отметить», «стоит учитывать», «в целом», «надеюсь, это поможет», «в заключение». Максимум 20 слов в предложении. Один абзац - одна мысль. Каждый шаг инструкции начинается с глагола в повелительном наклонении. Если условие не проверено, пиши «не проверено» вместо оговорки. Не пересказывай задание в начале ответа. Не добавляй итоговый абзац с выводами.
Шаблон адаптируют под жанр: для runbook добавляют требование помечать обязательные шаги, для API-референса - фиксированный порядок полей. Промпт для технического текста полезно хранить в репозитории рядом с самой документацией, чтобы правки обсуждались как код.
Границы метода
Промпт не меняет распределение модели, он управляет выводом в момент генерации. Очевидные штампы он снимает, но идиосинкразические особенности конкретного автора не воспроизводит: ритм, любимые конструкции, способ строить аргумент остаются за пределами досягаемости. Если нужен устойчивый авторский стиль, а не разовая правка, придётся смотреть в сторону обучения.
Fine-tuning и continued pretraining: когда они оправданы
Fine-tuning - единственный из трёх подходов, который меняет саму модель, а не только направляет её вывод во время генерации: веса сдвигаются под ваши образцы. Это же делает метод дорогим. Нужны данные, вычислительное время и готовность перепроверять качество на прежних задачах, потому что дообучение узкой задаче может ухудшить остальные навыки.
Сколько данных нужно
Ориентир из обсуждения: не менее 10 000 слов собственного текста, организованных по категориям, перед попыткой обучать модель на своём стиле. Цифра взята из цитируемого гайда по настройке стиля и служит порогом входа, а не гарантией результата. Практически важнее не объём, а однородность: если в выборке смешаны инструкции, маркетинговые тексты и переписка, модель выучит смесь.
Чем continued pretraining отличается от fine-tuning
Continued pretraining возобновляет текстовую обучающую задачу на новом тексте, то есть модель продолжает учиться предсказывать текст в вашем домене. Fine-tuning меняет обучаемые веса с помощью демонстраций: вы показываете пары «запрос - правильный ответ». Разница в том, что continued pretraining подтягивает лексику и формат домена, а fine-tuning задаёт поведение на конкретных типах задач.
Оба метода требуют осторожности. Дообучение может ухудшить навыки, не связанные с целевой задачей; механика этого эффекта разобрана в статье про катастрофическое забывание при дообучении, где сравниваются SFT, continued pre-training и RL. Если задача узкая, например очистка диктовки, иногда дешевле и надёжнее взять компактную модель и обучить её под один сценарий: пример такого подхода разобран в материале про локальную 0.8B-модель.
Роль RAG и retrieval в техническом письме
Retrieval подтягивает в контекст нужные фрагменты: определения, примеры, связи между сущностями. Веса при этом не меняются. В разборе доменной адаптации сформулирован простой тест: если корректный фрагмент runbook в промпте исправляет ответ, retrieval - полезная базовая линия, с которой стоит сравнивать любые методы обучения.
Стиль retrieval не лечит. Он решает проблему фактуры: убирает выдуманные параметры, подставляет актуальные коды ошибок, напоминает про обязательный токен идемпотентности. Манера письма, длина предложений и осторожные обороты остаются такими же, как у модели без retrieval. Для LLM для технической документации это значит, что retrieval и промпт-ограничения закрывают разные задачи и применяются вместе.
Практический вывод: как выбрать модель под свою документацию
Порядок действий, который экономит время и не требует верить чужим впечатлениям:
- Определите жанр и объём: инструкция, runbook, API-референс.
- Соберите 3-5 тестовых промптов и зафиксируйте настройки генерации.
- Прогоните кандидатов, включая модели предыдущих поколений, и оцените по шести критериям: тон, структура, оговорки, длина предложений, ассистентские вставки, точность терминов.
- Добавьте промпт с запретами и лимитами, затем повторите прогон: часто этого достаточно, чтобы снять узнаваемый стиль.
- Retrieval подключите, если проблемы в фактах, а не в тоне.
- Fine-tuning или continued pretraining рассматривайте только при устойчивой потребности и наличии подготовленных данных.
Жалоба random-tomato полезна как сигнал: одинаковый голос у разных моделей стал заметен пользователям, которые пишут технические тексты каждый день. Но ориентироваться стоит на собственные прогоны на своих промптах. Впечатления пользователей Reddit указывают, что проверять, а не дают готовый ответ, какую модель скачать.