Информационна печалба и slop: как ги измерваме

Информационна печалба

Читателят идва при текста с въпроси: какво точно трябва да се случи, къде, кога, колко, при какви условия и защо. Информационната печалба е делът на тези въпроси, на които текстът отговаря. При 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 EUR на потребител на месец, първите 30 дни безплатно“ променя решението за покупка; „безпроблемно изживяване“ не го променя. В доклада за грешка версията, стъпките и прагът са това, което променя следващата стъпка на разработчика.

Slop

Slop е делът от текста, измерен в думи, който не отговаря на нито един въпрос на читателя. Различаваме 4 вида: празни изречения, които пасват на всеки текст, очевидни, които не изключват нищо от онова, което читателят е допускал, неуместни, които не променят никое решение, и неразрешими, като „както обсъдихме“ или „същото като там“. Повторенията на вече казаното в текста също се броят. В резултата всяко изречение slop е маркирано.

От гледна точка на разговора slop нарушава 2 от максимите, описани от Пол Грайс: бъди толкова информативен, колкото е нужно, и не повече, и казвай само относимото (Grice, 1975). Повторенията са това, което Шанън нарича излишък: частта от съобщението, която читателят може да предвиди от останалото.

Стилът не е slop: „поправихме експорта в CSV“ и „проблемът с експорта в CSV е отстранен“ се броят еднакво.

Как са свързани двете числа

Slop не носи информация, затова колкото по-голяма част от текста е slop, толкова по-нисък е таванът на печалбата му: текст с 60% slop получава най-много около 50%, а текст с 95% slop или повече получава най-много 10%. Пълни 100% се показват само когато нито едно изречение не е slop; иначе печалбата спира на 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% от тях slop. Малкият модел във вашия браузър се е учил от тези етикети. При кръстосана валидация той съвпада с учителя при рангова корелация 0,85, а върху текстове, от които не се е учил, намира изреченията slop на учителя с AUROC 0,92. Върху 25 ръчно оценени текста той съвпада с ръчните оценки при рангова корелация 0,81, но правилата над него идват от същите текстове, затова отделените тестове по-долу са по-честната мярка.

Нито един езиков модел не чете текста ви, когато го проверявате. Едно извикване на модел би изпратило текста на трета страна, може да даде различен отговор за същия текст и би струвало пари при всяка проверка; малкият модел работи с около 350 KB фиксирани тегла.

Предсказания, записани предварително

При 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 сигнала и същите хеширани думи решава за всяко изречение дали е slop. Моделът за текста е линейна регресия върху тези сигнали, а моделът за изреченията е логистична регресия, и двата обучени върху 2424-те оценени текста. Над модела се прилагат 3 правила от ръчния преглед. Начален час след крайния срок струва 25 точки. Задача, която започва с „разделете на 4 раздела“ и никъде не казва какво да се раздели, получава най-много 20%. Шаблон с празни заглавия получава най-много 10%. Теглата заемат около 350 KB и се зареждат със страницата, а текст от 3000 знака се проверява за под 100 милисекунди.

Изречения и езици

Разделяме текста на изречения при точки, въпросителни и удивителни знаци, многоточия и нови редове, но не вътре в „v8.1“, „1.200“ или уеб адрес и не след дата като „7. Juni“. Поддържат се 12 езика: английски, полски, чешки, словашки, хърватски, словенски, български, немски, френски, италиански, испански и нидерландски. Езикът се разпознава автоматично с точност 99,6% на предишните ни тестови набори и 97,1% при кратки текстове на новите езици. Списъците с фрази slop за 11-те езика освен английския съставихме сами; за немски, полски, чешки и хърватски не намерихме отворени списъци. Безплатните проверки приемат от 80 до 3000 знака, което покрива 97,5% от събраните доклади за грешки от Jira, без блоковете с код. Известно изкривяване: само езикът измества оценката с няколко точки. При едни и същи сигнали текстовете на испански, френски, чешки и италиански получават с 5 до 8 точки по-малко от английските, а немските и нидерландските около 4 точки повече, затова сравнявайте оценките в рамките на един език.

Какво не измерваме

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

Въпроси

Как да проверя текст за AI slop?

Поставете го в полето на началната страница: от 80 до 3000 знака, до 5 текста на ден безплатно. Получавате информационната печалба, дела на slop и маркираните в текста изречения slop.

Съхранява ли се текстът ми и изпраща ли се някъде?

Не. Проверката се извършва във вашия браузър: текстът не се изпраща до нас и не се съхранява. Връзката към резултата пази текста в частта от адреса след знака #, която браузърите не изпращат до сървърите.

Какви текстове мога да проверя?

Статии, продуктови страници, публикации, задачи, потребителски истории и доклади за грешки на 12 езика: английски, полски, чешки, словашки, хърватски, словенски, български, немски, френски, италиански, испански и нидерландски, от 80 до 3000 знака.

Как да напиша добър бъг репорт?

Посочете как се възпроизвежда проблемът: какви стъпки, коя версия, кое устройство и от какъв праг нататък започва да се проваля. Изследване на 180 възпроизводими доклада за грешки в Android показва, че в 92,2% от тях липсва поне 1 стъпка (Johnson et al., 2022). „Експортът се проваля при поръчки над 500 реда в Chrome 128“ изключва много повече от „експортът понякога се проваля“. Поставете доклада в проверката, за да видите кои изречения не отговарят на нито един от тези въпроси.

Slopcheck детектор за ИИ ли е?

Не. Slopcheck оценява колко казва текстът на читателя си. Той не казва кой или какво го е написал: генериран текст с реални факти може да получи висока оценка, а написан на ръка текст без факти получава ниска.

С какво се различава от проверките, които търсят признаци на ИИ?

Инструментите, които броят дълги тирета, „delve“ или „tapestry“, гледат повърхността на текста. Slopcheck гледа какво получава читателят: текстът може да избегне всеки такъв признак и пак да не отговори на нито един въпрос на читателя.

Какво е паспорт на текста?

Запис на един точен текст: неговият хеш, информационна печалба, slop, версията на метода и датата на проверката, на страница със собствена връзка. Всеки, който има текста, може да го постави там и да види дали съвпада: ако се различава дори с 1 знак, хешът е различен. Всяка редакция се запазва като нова версия със свои оценки.

Нужен ли ми е плъгин или SDK, за да използвам API?

Не. В плана „Екип“ проверката е една HTTP заявка с текста. Тя се вписва в стъпка на CI, в hook преди публикуване в CMS или в поле на вашия тракер на задачи.

Източници

Проверете текста си

Поставете статия, продуктова страница, задача или доклад за грешка и вижте информационната печалба и slop в него.

Проверете текст безплатно

Как смятаме