Как мы считаем

Прирост информации

Читатель приходит к тексту с вопросами: что именно должно произойти, где, когда, сколько, при каких условиях и зачем. Прирост информации — доля этих вопросов, на которые текст отвечает. При 100% читателю больше нечего спросить, а у формы с пустыми полями прирост близок к 0%. Модель в вашем браузере оценивает эту долю по шкале от 0 до 10 и показывает её с шагом 5%.

Идея восходит к Клоду Шеннону, который измерял информацию в битах: один бит — это ответ на один вопрос «да или нет» (Shannon, 1948). Баг-репорт «большой экспорт падает» заставляет разработчика гадать, 12 300 строк или 11 000, задавая один вопрос «да или нет» за другим; «экспорт больше 10 000 строк падает» отвечает на них все сразу. Уоррен Уивер описал три уровня коммуникации: доходят ли символы, несут ли они задуманный смысл и меняют ли они действия получателя (Weaver, 1949). Slopcheck работает на втором и третьем уровнях.

Прирост информации в SEO

В SEO под приростом информации (information gain) понимают то, что страница добавляет к страницам, которые читатель уже видел. У Google есть патент на такую оценку, «Contextual estimation of link information gain» (US 11,354,342 B2, выдан 7 июня 2022 года). Патент не доказывает, что оценка используется в ранжировании; в публичных рекомендациях Google спрашивает, содержит ли контент «оригинальную информацию, репортажи, исследования или анализ» (в оригинале “original information, reporting, research, or analysis”, Google Search Central). Slopcheck измеряет ту часть, которую 1 текст показывает сам по себе, без сравнения с другими страницами: долю вопросов читателя, на которые он отвечает, от 0 до 100%.

Что исключает утверждение

Рудольф Карнап и Иегошуа Бар-Хиллел описали смысловую сторону информации: утверждение несёт тем больше информации, чем больше возможных состояний мира оно исключает (Carnap и Bar-Hillel, 1952). «Экспорт падает для заказов больше 500 строк в Chrome 128» исключает гораздо больше, чем «экспорт иногда падает». Самая сильная форма — названный порог: «3.1.4 работает, 3.2.0 падает» говорит разработчику, какой релиз открыть.

Истинность утверждения — отдельный вопрос (Stanford Encyclopedia of Philosophy): Slopcheck не проверяет факты, и «заказы больше 500 строк» получают одну и ту же оценку, будь реальный порог 500 или 5000.

Что важно читателю

Рональд Говард показал в 1966 году, что информация стоит столько, сколько она меняет в решении (Howard, 1966). Для разработчика «Chrome 128» решает, какой из 3 браузеров тестировать; «экспорт важен» не решает ничего. На странице продукта «4 € за пользователя в месяц, первые 30 дней бесплатно» меняет решение о покупке, а «бесшовный опыт» не меняет. В баг-репорте следующий шаг разработчика меняют версия, шаги и порог.

Слоп

Слоп — доля текста в словах, которая не отвечает ни на один вопрос читателя. Мы выделяем 4 вида: пустые предложения, которые подошли бы любому тексту; очевидные, которые не исключают ничего из того, что допускал читатель; нерелевантные, которые не меняют ни одного решения; и отсылки в никуда вроде «как обсуждали» или «так же, как там». Повторы уже сказанного тоже считаются; в результатах проверки Slopcheck подсвечивает каждое предложение-слоп.

Если смотреть на текст как на разговор, слоп нарушает 2 максимы, которые описал Пол Грайс: сообщай столько информации, сколько требуется, и не больше, и говори по делу (Grice, 1975). Повторы — это то, что Шеннон называл избыточностью: часть сообщения, которую читатель мог бы предсказать по остальному тексту.

Стиль не считается слопом: «мы починили экспорт в CSV» и «проблема с экспортом в CSV была устранена» получают одинаковую оценку.

Как связаны два числа

Слоп не несёт информации, поэтому чем больше в тексте слопа, тем ниже потолок прироста: текст, в котором 60% слопа, получает не больше примерно 50%, а текст, в котором слопа 95% или больше, получает не больше 10%. Полные 100% показываются, только если в тексте нет ни одного предложения-слопа; иначе прирост останавливается на 95%. Длина не цель: баг-репорт из 50 слов может получить 90%.

Баг-репорты, задачи и страницы продуктов

Мы записали 27 вопросов, с которыми читатель приходит к тексту: 7 для любого текста, 8 для баг-репортов, 7 для задач и 5 для страниц продуктов. Баг-репорт отвечает: какая версия, какие шаги, что ожидалось и что произошло, всегда или иногда и с какого релиза. Задача отвечает: что, где, зачем, как проверить, что она сделана, и чего не трогать; хорошие критерии приёмки выглядят так: «34 настройки, 4 вкладки, тексты не меняем». Страница продукта отвечает: для кого, что делает, чем это подтверждено, сколько стоит и какой следующий шаг. Модель усвоила эти различия на 2424 примерах, оценённых языковой моделью, поэтому перед проверкой не нужно выбирать жанр текста.

5 версий за 4 дня

Версия 1 от 19 октября 2026 года считала служебные слова, слова-паразиты и конкретные детали на 100 слов. Версия 2 добавила редкость слов по частотным спискам, которые мы посчитали примерно по 600 000 слов текста Википедии на каждый язык; на 55 веб-страницах, оценённых двумя языковыми моделями, она оказалась шумом (AUROC от 0,45 до 0,49), и мы от неё отказались. Версия 3 судила по конкретике на 100 слов; на 37 новых страницах, отложенных для теста, её вердикт «слишком мало конкретики» был верен в 1 случае из 9, поэтому он стал лишь подсказкой.

Версия 4 использовала каталог примерно из 1000 шаблонов на 5 языках и на тех же 37 страницах отделяла раздутые страницы от плотных (AUROC 0,75; мы видели эти результаты во время разработки, так что цифра оптимистична). На реальных баг-репортах она работала на уровне случайного угадывания (от 0,47 до 0,52). Эта неудача заставила нас перейти от подсчёта слов к подсчёту открытых вопросов читателя и к версии 5 (s2) 22 октября; 24 октября мы переобучили её для 12 языков сайта и русского (s3).

Чему нас научили баг-трекеры

Мы взяли 1355 отчётов из Mozilla Bugzilla за 2023–2025 годы. Отчёты, закрытые как неполные или «works for me», или те, у автора которых запросили больше информации, были длиннее отчётов, исправленных без такого запроса (медиана 165 слов против 124), и конкретнее: внешние пользователи заполняют полный шаблон, который встречается в 38% отчётов «works for me» и в 14% исправленных, а инженеры пишут короткие заметки в расчёте на общий контекст. Исход показывал, кто написал отчёт, поэтому дальше мы сравнивали отчёты одного и того же автора.

В Apache Jira мы собрали 11 129 баг-репортов из 165 проектов, заведённых с 2022 года, и сравнили исправленные с закрытыми как «Cannot Reproduce» или «Incomplete». Метод определила одна находка: языковая модель прочитала 240 таких отчётов, 120 пар одного автора, не зная ни исхода, ни автора. На вопрос, указаны ли версия или окружение, она чаще находила их в плохо принятых отчётах (63% против 50%). На вопрос, чего ещё не хватает разработчику, она для тех же отчётов чаще называла версию или окружение (48% против 33%). Упомянуть деталь и ответить на вопрос не одно и то же.

Правила из ручной проверки

Мы оценили 35 текстов вручную, большинство по шкале от 0 до 10: 0 ставится пустой форме, 5–6 тексту, по которому можно работать после пары вопросов, 9 оставляет один открытый вопрос, а 10 значит, что добавить нечего. На 28 из этих текстов наш первый каталог вопросов задал 86 вопросов; мы разметили 35 из них: 26 как справедливые и 9 как лишние. В итоге получилось письменное руководство из 37 правил и 33 тестовых случаев.

Примеры правил: утверждение без ограничения означает «всегда и везде», поэтому отсутствие версии ничего не стоит, если в тексте нет слов «иногда» или «после обновления»; запрет учитывается, только если закрывает путь, который подразумевает задача; противоречащие друг другу требования стоят дороже всего. В одном тесте те же факты, переписанные с явной ссылкой и названным объектом, поднялись с 1 до 9–10 из 10. В другом отчёт с ручной оценкой 10 был закрыт как «Cannot Reproduce»: исход в трекере — это сигнал, а не вердикт.

Языковые модели как оценщики и как учитель

Мы превратили 37 правил в руководство по оценке для больших языковых моделей и сравнили 5 моделей на 27 текстах с числовыми ручными оценками. Правила выведены из этих же текстов, поэтому сравнение показывает, насколько точно каждая модель следует правилам, а не как она справляется с новыми текстами: две лучшие отклонились от ручной оценки не больше чем на 1 балл в 22 текстах из 27 (ранговая корреляция до 0,94), самая слабая — в 12 из 27.

Затем одна из двух оценила по предложениям 2424 текста: 600 публичных задач и баг-репортов из Apache Jira, 384 текста с одними и теми же фактами, которые языковые модели написали в 4 стилях, 600 текстов, которые та же модель написала для обучения на немецком, польском, чешском, хорватском и русском, и 840 текстов, по 120 на словацком, словенском, болгарском, французском, итальянском, испанском и нидерландском, которые языковые модели написали, не видя правил. Это 18 420 размеченных предложений, 21,4% из них слоп. На этой разметке обучилась небольшая модель в вашем браузере. При кросс-валидации она согласуется с учителем с ранговой корреляцией 0,85, а на текстах, на которых не обучалась, находит предложения-слоп учителя с AUROC 0,92. На 25 текстах с ручной оценкой она согласуется с ручными оценками с ранговой корреляцией 0,81, но правила поверх неё выведены из тех же текстов, поэтому честнее судить по отложенным тестам ниже.

Когда вы проверяете текст, его не читает ни одна языковая модель. Вызов модели отправил бы текст третьей стороне, мог бы дать другой ответ на тот же текст и стоил бы денег за каждую проверку; небольшая модель работает на фиксированных весах объёмом около 350 КБ.

Прогнозы записаны заранее

Для 5 экспериментов мы записывали прогнозы в файл до запуска теста; у файла для теста шаблонов 20 октября 2026 года контрольная сумма MD5 начинается с ff01ce1a. Мы предсказывали, что простая версия текста обойдёт версию в стиле ассистента в 85–95% пар; так вышло в 79%. Мы предсказывали, что отклонённые отчёты Bugzilla окажутся короче; они оказались длиннее, с медианой 165 слов против 124. На парах Jira одного автора не сбылись 3 из 4 прогнозов. После промаха с Bugzilla во всех следующих сравнениях мы брали отчёты одного и того же автора.

Что не сработало

Редкость слов (AUROC от 0,45 до 0,49). Доля служебных слов и слов-паразитов: на отложенных страницах она дала AUROC всего 0,31, хуже случайного угадывания. Вердикт «слишком мало конкретики», который был верен 1 раз из 9. Подсчёт смысловых единиц или чек-лист полноты из 5 пунктов: они совпадали с прочтением всего текста с ранговой корреляцией всего от 0,18 до 0,26. 8 индикаторов по образцу сигналов поисковых систем, отвергнутые на этапе проектирования. Сравнение страницы с первыми 3–10 результатами поиска, для которого нужен платный поисковый API. Широкие версии явных правил, которые сработали на 33 отчётах Jira; каждое проверенное нами срабатывание оказалось ложной тревогой. Языковая модель во время проверки: она ближе всего подошла к ручным оценкам, но отправляла бы ваш текст третьей стороне.

Как мы проверяем метод

Мы отложили для теста 24 брифа на английском и немецком, каждый в 4 версиях, написанных языковыми моделями. Простая версия получает оценку выше раздутой во всех 24 парах и выше версии в стиле ассистента в 83% пар. Для каждого из 7 языков, добавленных 24 октября, мы отложили ещё по 6 брифов в 4 версиях: простая версия обходит раздутую в каждой паре, а версию в стиле ассистента — в 100% пар на словацком и словенском, в 92% на итальянском и нидерландском, в 83% на болгарском и французском и в 58% на испанском.

На 120 отложенных парах отчётов Jira одного автора исправленный отчёт получает более высокую оценку примерно в 60% пар. Языковая модель, которая читает те же 240 отчётов вслепую, не зная ни исхода, ни автора, достигает 64%. Английские и немецкие брифы и пары Jira не участвовали в обучении, но по ним мы выбирали между вариантами явных правил, поэтому на новых текстах результаты могут быть немного ниже. Будет ли отчёт исправлен или закрыт как «Cannot Reproduce», зависит и от самого бага: он может быть уже исправлен в более новой версии, проявляться только в одном окружении или происходить из ошибки конфигурации, поэтому 100% на этом тесте недостижимы.

Как вычисляется оценка

По всему тексту модель считывает 182 сигнала, например числа, версии, условия, пороги, имена, цитируемые сообщения, расплывчатые слова, ничем не подкреплённые утверждения, повторы и пустые заголовки шаблонов, а также слова и пары слов, захешированные в 16 384 ячейки; вторая модель с 68 сигналами и теми же захешированными словами решает для каждого предложения, слоп ли оно. Модель текста — линейная регрессия на этих сигналах, модель предложений — логистическая регрессия; обе обучены на 2424 оценённых текстах. Поверх модели действуют 3 правила из ручной проверки. Время старта позже дедлайна стоит 25 баллов. Задача, которая начинается с «разбить на 4 вкладки» и нигде не говорит, что разбивать, получает не больше 20%. Шаблон с пустыми заголовками получает не больше 10%. Веса занимают около 350 КБ и загружаются вместе со страницей, а текст из 3000 знаков проверяется меньше чем за 100 миллисекунд.

Предложения и языки

Мы делим текст на предложения по точкам, вопросительным и восклицательным знакам, многоточиям и переносам строк, но не внутри «v8.1», «1.200» или веб-адреса и не после даты вроде «7. Juni». Поддерживаются 12 языков сайта (английский, польский, чешский, словацкий, хорватский, словенский, болгарский, немецкий, французский, итальянский, испанский и нидерландский) и русский. Язык определяется автоматически: верно в 99,6% случаев на наших прежних тестовых наборах и в 97,1% на коротких текстах на новых языках. Списки слоп-фраз для 11 языков сайта, кроме английского, мы составили сами: для немецкого, польского, чешского и хорватского открытых списков мы не нашли. Бесплатная проверка принимает от 80 до 3000 знаков, а это 97,5% собранных нами баг-репортов из Jira, не считая блоков кода. Известное смещение: сам язык сдвигает оценку на несколько баллов. При тех же сигналах тексты на испанском, французском, чешском и итальянском получают на 5–8 баллов меньше, чем на английском, а на немецком, нидерландском и русском примерно на 4 балла больше, поэтому сравнивайте оценки в пределах одного языка.

Чего мы не измеряем

Slopcheck не измеряет, кто написал текст, правдив ли он и как он будет ранжироваться в Google или Bing. На выборке из открытого бенчмарка RAID на английском признаки текста, основанные на правилах, находили не больше 28% текстов, написанных ИИ, при 5% ложных срабатываний. Поэтому мы не предлагаем определение авторства. Заметка из 2 строк может быть совершенно точной для команды с общим контекстом: оценка видит только текст.

Вопросы

Как проверить текст на ИИ-слоп?

Вставьте его в поле на главной странице: от 80 до 3000 знаков, бесплатно до 5 текстов в день. Вы получите прирост информации, долю слопа и предложения-слоп, отмеченные в тексте.

Мой текст где-то хранится или куда-то отправляется?

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

Какие тексты можно проверить?

Статьи, страницы продуктов, посты, задачи, пользовательские истории и баг-репорты на 12 языках сайта (английском, польском, чешском, словацком, хорватском, словенском, болгарском, немецком, французском, итальянском, испанском и нидерландском) и русском, от 80 до 3000 знаков.

Как написать хороший баг-репорт?

Опишите, как воспроизвести проблему: какие шаги, какая версия, какое устройство и с какого порога начинается сбой. В исследовании 180 воспроизводимых баг-репортов для Android в 92,2% не хватало хотя бы 1 шага (Johnson et al., 2022). «Экспорт падает для заказов больше 500 строк в Chrome 128» исключает гораздо больше, чем «экспорт иногда падает». Вставьте отчёт в проверку и посмотрите, какие предложения не отвечают ни на один из этих вопросов.

Slopcheck — это детектор ИИ?

Нет. Slopcheck оценивает, сколько текст сообщает читателю. Он не говорит, кто или что его написал: сгенерированный текст с реальными фактами может получить высокую оценку, а написанный вручную текст без фактов получит низкую.

Чем он отличается от проверок, которые ищут признаки ИИ?

Инструменты, которые считают длинные тире, «delve» или «tapestry», смотрят на поверхность текста. Slopcheck смотрит на то, что получает читатель: текст может избежать всех признаков и всё равно не ответить ни на один вопрос читателя.

Что такое паспорт текста?

Запись об одном конкретном тексте: его хеш, прирост информации, слоп, версия метода и дата проверки, на странице с собственной ссылкой. Любой, у кого есть текст, может вставить его туда и проверить, совпадает ли он: если отличается хотя бы 1 знак, отличается и хеш. Каждая правка сохраняется как новая версия со своими оценками.

Нужен ли плагин или SDK, чтобы работать с API?

Нет. На тарифе «Команда» проверка — это один HTTP-запрос с текстом. Её можно встроить в шаг CI, в хук перед публикацией в CMS или в поле вашего трекера задач.

Источники

1. C. E. Shannon (1948). A Mathematical Theory of Communication. Bell System Technical Journal
2. C. E. Shannon, W. Weaver (1949). The Mathematical Theory of Communication. University of Illinois Press
3. Google LLC (2022). Contextual estimation of link information gain. Патент США 11,354,342 B2
4. Google Search Central. Creating helpful, reliable, people-first content
5. R. Carnap, Y. Bar-Hillel (1952). An Outline of a Theory of Semantic Information. MIT Research Laboratory of Electronics
6. S. Sequoiah-Grayson, L. Floridi. Semantic Conceptions of Information. Stanford Encyclopedia of Philosophy
7. R. A. Howard (1966). Information Value Theory. IEEE Transactions on Systems Science and Cybernetics
8. H. P. Grice (1975). Logic and Conversation; краткое изложение максим в статье “Implicature”, Stanford Encyclopedia of Philosophy
9. J. Johnson et al. (2022). An Empirical Investigation into the Reproduction of Bug Reports for Android Apps. SANER 2022, раздел IV-C
10. Apache Software Foundation. Трекер задач Jira: публичные баг-репорты и задачи за 2022–2026 годы
11. Mozilla. Bugzilla: публичные баг-репорты за 2023–2025 годы
12. L. Dugan et al. (2024). “RAID: A Shared Benchmark for Robust Evaluation of Machine-Generated Text Detectors”. ACL 2024