Перейти к содержанию
Публикация AiManual

Kimi, Qwen, DeepSeek и Grok как редакторы текста: как измерить, сколько модель меняет в статье

Препринт 2026 года показал, что модели меняют смысл текста даже при просьбе править только грамматику. Разбираем рабочую методику: жёсткий промпт со списком доп

Коротко

Что будет в материале

  1. 01

    Почему модели переписывают текст, даже когда просят только исправить грамматику

  2. 02

    Жёсткий промпт: как запретить модели молчаливые правки

  3. 03

    Как посчитать, сколько модель изменила: diff и доля изменённых слов и знаков на Python

  4. 04

    Методика прогона: одна статья на 3-5 тыс. знаков через несколько моделей

Препринт 2026 года исследователей из Berkeley, Google DeepMind и других организаций показал: ИИ-модели меняют смысл текста, даже когда их просят исправить только грамматику. Практический разбор на Habr проверяет это на Kimi AI, Qwen, DeepSeek и Grok.

На практике всё так же. Нейросеть, которой дали статью на редактуру, переписывает её, хотя просили только править. Генератор тянется к гладкому тексту и по дороге меняет формулировки, порядок фраз и иногда акценты.

Контроль сводится к двум действиям: жёсткий промпт с закрытым списком допустимых правок и сравнение версий через diff. Дальше - рабочая методика для Kimi, Qwen, DeepSeek и Grok: шаблон промпта, скрипт на Python для доли изменённых слов и знаков, проверка на молчаливые правки и посторонние вставки.

Почему модели переписывают текст, даже когда просят только исправить грамматику

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

Что именно ломается: смысл, стиль или факты

Нежелательные правки удобно делить на группы, потому что ловить их в diff придётся по-разному:

  • Синонимическая замена. «Осуществлять» становится «делать», «в связи с» превращается в «из-за». Словарный смысл близок, авторский оттенок теряется.
  • Перестановка. Фрагменты предложения или целые абзацы меняются местами. Логика может сохраниться, структура текста - нет.
  • Добавление связок. В текст приходят «таким образом», «в свою очередь», «при этом», которых там не было.
  • Смена акцентов. Оценочное слово заменяется нейтральным или наоборот. Читатель получает другую интонацию.
  • Правка фактов. Число, имя или дата приводятся к виду, который модель считает более вероятным.

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

Похожий сбой разобран в материале о локальной Qwen3.5-0.8B для очистки диктовки: универсальный чат-LLM меняет смысл там, где от него ждут только расстановки знаков.

Почему рейтинги моделей здесь не помощники

Соблазн простой: взять верхушку рейтинга и не мучиться. С редактурой это не работает. Публичные рейтинги сравнивают Kimi AI, Qwen и DeepSeek на русском по диалогам, длинным текстам и голосам людей, а правку чужой статьи не проверяют. Высокое место в таблице ничего не говорит о том, как модель обойдётся с вашим текстом.

Примеры на 2026 год. Kimi K3 держится в первой двадцатке русского среза Arena на 27 августа 2026. Qwen3 235B A22B набрала 1076 очков в llmarena.ru на 18 апреля 2026, DeepSeek V3.2 заняла там 4-е место со 1133 очками. Grok 4.7 стоит 13-м в народном рейтинге AI-Stat. Сводка мест по GEN202 и AI-Stat между таблицами не переносится: у них разные участники, задачи и даты.

Отдельные тесты меряют своё. DeepSeek на русском в мае 2025 года была первой в PingPong Ильи Гусева, но этот тест оценивает ролевые диалоги. Qwen3.5-27B лидирует в столбце длинных текстов MERA Reason, это тоже не редактура. Ближе всего к задаче задание из теста bothub: при вычитке Kimi K3 не стала приписывать автору опечатки издания, но текст там был английский.

История с бенчмарками повторяется: разбор просадки китайских моделей на новых тестах показывает, насколько результат зависит от того, что именно измеряли. Переносить место из таблицы на редактуру нельзя.

Жёсткий промпт: как запретить модели молчаливые правки

Жёсткий промпт нужен не для вежливости, а для сужения пространства решений. Он перечисляет, что можно менять, что нельзя и в каком виде вернуть результат. Всё, что осталось за списком, модель делать не должна.

Перечень допустимых правок и запрет на остальное

Список делайте закрытым. Открытые формулировки вроде «улучши читаемость» или «поправь стиль» модель трактует широко. Рабочий каркас:

Роль: корректор русского текста. Ты не автор и не редактор.
Можно менять только:
1) орфографию;
2) пунктуацию;
3) согласование, падежи и предлоги;
4) явные опечатки и разорванные слова;
5) повторяющиеся пробелы и лишние переносы строк.
Запрещено:
- менять смысл, факты, числа, имена и даты;
- заменять слова на синонимы;
- переставлять предложения и абзацы;
- добавлять связки, пояснения и «улучшения»;
- сокращать или дописывать текст.
Если правка не входит в список выше, не делай её.
Сохраняй длину абзацев и порядок фрагментов.
Верни ответ двумя блоками.
БЛОК 1: исправленный текст целиком, без комментариев внутри.
БЛОК 2: таблица правок с колонками «было», «стало», «категория».
Если правок нет, напиши: правок нет.

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

Формат ответа: текст плюс список «было → стало»

Два блока в ответе нужны для машинной сверки. Текст идёт отдельно, список правок отдельно. Тогда вы выгружаете первый блок в файл, считаете diff и сравниваете число фактических правок с числом заявленных пар.

Список «было → стало» нужен не для красоты. Это основной способ увидеть молчаливые правки: изменения, которые модель внесла в текст, но не указала. Таблица удобнее списка, потому что из неё проще вытащить пары регуляркой или разбором строк. Конкретная модель может «забыть» часть правок в отчёте, и это нормальный результат теста, а не сбой скрипта.

Как посчитать, сколько модель изменила: diff и доля изменённых слов и знаков на Python

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

  1. Сохраните исходник в src.txt, ответ модели в out.txt. Ответ берите из первого блока, без таблицы правок.
  2. Нормализуйте пробелы: повторные пробелы, табы и переводы строк не должны попадать в счёт знаков.
  3. Разбейте текст на слова и на символы. Это две разные метрики.
  4. Посчитайте diff через difflib.SequenceMatcher и долю несовпавших единиц.
  5. Отдельно посчитайте число блоков правок через get_opcodes, чтобы сверить его со списком «было → стало».
import re
import difflib

def words(text):
    return re.findall(r'\w+', text.lower(), flags=re.UNICODE)

def chars(text):
    return re.sub(r'\s+', ' ', text).strip()

def changed_share(a, b):
    sm = difflib.SequenceMatcher(a=a, b=b, autojunk=False)
    same = sum(block.size for block in sm.get_matching_blocks())
    return 1 - same / max(len(a), 1)

src = open('src.txt', encoding='utf-8').read()
out = open('out.txt', encoding='utf-8').read()

print('слова:', round(changed_share(words(src), words(out)), 3))
print('знаки:', round(changed_share(list(chars(src)), list(chars(out))), 3))

Почему две метрики, а не одна. Правка пунктуации почти не двигает счёт слов: запятая не слово. Замена союза или перестановка слов в предложении почти не двигает счёт знаков. Если смотреть только на слова, вы пропустите пунктуационную чистку. Если только на знаки, не увидите синонимическую замену той же длины.

Числа читайте как проценты: 0.08 по словам значит, что модель тронула примерно 8% слов. Для статьи на 4 тыс. знаков это заметный объём. Для сравнения моделей хватает одной статьи, но лучше взять две-три разных по жанру: инструкцию, аналитический текст и новость.

Где пословный подсчёт врёт: перестановка абзацев

SequenceMatcher ищет общие блоки в порядке следования. Если модель поменяла два абзаца местами, слова остались те же, а diff покажет крупные замены: старый порядок не совпадает с новым. Доля изменённых слов вырастет, хотя ни одного нового слова не появилось.

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

import zlib

def compressed_len(text):
    return len(zlib.compress(text.encode('utf-8'), 9))

def ncd(a, b):
    ca, cb, cab = compressed_len(a), compressed_len(b), compressed_len(a + b)
    return (cab - min(ca, cb)) / max(ca, cb)

print(round(ncd(src, out), 4))

Значение около нуля означает почти одинаковые тексты, рост к единице - сильное расхождение. Точного порога «нормальной редактуры» у этой метрики нет, и zlib не скажет, что именно поменялось.

Проверка на иероглифы и посторонние вставки

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

import unicodedata

def is_cjk(ch):
    name = unicodedata.name(ch, '')
    return name.startswith(('CJK', 'HIRAGANA', 'KATAKANA', 'HANGUL'))

extra = sorted({ch for ch in out if ch not in set(src) and not ch.isspace()})
print('посторонние символы:', extra)
print('иероглифы:', sorted({ch for ch in out if is_cjk(ch)}))

Чек-лист после каждого прогона:

  • символы вне алфавита исходника: иероглифы, арабская вязь, эмодзи;
  • фрагменты, которых не было во входе: заголовки, подписи, markdown-разметка, служебные пометки;
  • соответствие списка «было → стало» фактическому diff;
  • сохранность чисел, имён и дат, их проще сверить поиском по исходнику.

Методика прогона: одна статья на 3-5 тыс. знаков через несколько моделей

Прогон нужен один и тот же для всех моделей, иначе числа не сравнить. Ниже протокол, который повторяется на своей статье.

Что зафиксировать до прогона

  • Одна статья объёмом 3-5 тыс. знаков. Этого хватает на несколько десятков правок и не упирается в лимиты.
  • Один и тот же промпт, скопированный целиком, без правок под конкретную модель.
  • Новый диалог на каждую модель: старый контекст меняет поведение.
  • Ограничение режима рассуждения. Если у модели есть переключатель reasoning, поставьте минимальный уровень и запишите, какой именно.
  • Сырые ответы сохраните как есть, до ручной чистки.
  • Дата, версия модели, версия промпта. Пороги и версии устаревают за месяцы, без пометки результат через полгода не воспроизвести.

Сверка diff со списком правок

Правило простое: каждая правка из diff должна быть в списке «было → стало», и наоборот. Расхождение в любую сторону означает, что отчёт неполный.

Считайте два числа: количество непустых блоков замены, вставки и удаления из get_opcodes и количество строк в таблице правок. Разница - молчаливые правки. Отдельно проверьте, что заявленная пара действительно встречается в исходнике и в ответе, иначе модель придумала правку, которой не было.

Доступ к моделям для прогона:

МодельРазработчикДоступЧто учесть
Kimi AIMoonshot AIAPIподключение из программы, не из одного окна чата
QwenAlibabaAPI, Alibaba Cloud Model StudioQwen3.5-397B-A17B открыта, 201 язык и диалект
DeepSeekDeepSeekсвой APIоплата с пополняемого баланса
GrokxAIAPI xAIgrok-4.7, окно 500 тыс. токенов, в документации издатель назван SpaceXSI

Все четыре модели доступны через API, то есть из программы, а не из одного окна чата. Окно контекста - это сколько текста влезает в один запрос. Считают его в токенах, минимальных кусочках текста: слово, число или знак препинания. По токенам же выставляют счёт за API, поэтому длинная статья вместе с инструкцией и ответом стоит денег. Обзор моделей и их доступности стоит сверить с документацией перед прогоном.

Окно в 500 тыс. токенов у grok-4.7 для статьи на 4 тыс. знаков избыточно, но полезно, если вы сравниваете сразу несколько версий в одном запросе. Для редактуры важнее не размер окна, а стабильность формата ответа. Что происходит с контекстом и стоимостью инференса при росте входа, разобрано в материале о DeepSeek, окне контекста и KV-cache.

Регистрацию и оплату из России проверьте на сайте каждой модели до прогона. Скучный пункт, который срывает половину тестов.

Как выбрать модель для редактуры по результатам

Гладкий результат обманчив. Модель, которая переписала половину статьи, часто выглядит лучше той, что поправила десять запятых. Для редактуры критерий другой: сколько текста тронуто и всё ли заявлено.

Эталон берётся у живого редактора. Дайте ту же статью человеку, попросите только вычитку, посчитайте долю изменённых слов и знаков тем же скриптом. Получится ориентир для этой статьи и этого жанра.

Дальше сравнение: модель, чья доля близка к редакторской и у которой нет молчаливых правок, ближе к задаче. Модель с вдвое большей долей меняет больше, чем нужно. Модель с близкой долей, но с расхождением между diff и списком правок опаснее: она врёт в отчёте.

Пороги не переносите на другие тексты. Статья с большим числом опечаток даст высокую долю у любой модели, чистый текст - низкую. Версии моделей обновляются, поведение меняется, и старый результат перестаёт что-то значить. Методику перепрогоняйте, а не цитируйте прошлые числа.

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

Подписаться на канал