Скритата цена на шумните уеб данни: Защо извличането на съдържание е по-важно от всякога

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

Според последни изследвания, около 70% от HTML кода на една типична уеб страница е шаблонно съдържание — навигационни менюта, реклами, странични ленти, бисквитки, линкове във футъра. Същинското съдържание, което ви интересува? Това са едва 30% от страницата. И ето къде е уловката: тези 30% определят всичко.

Качеството на данните е истинската защитна стена

Общността по машинно обучение се фокусира върху архитектурата на моделите, броя параметри и режимите на обучение. Но растящ брой изследвания показват, че непривлекателната работа по подготовка на данните може би е истинският разграничител.

През 2025 г. екипът на Ma et al. (AICC) проведе показателен експеримент. Те създадоха две тренировъчни колекции от идентични Common Crawl данни. Единствената променлива беше методът за извличане — един използваше традиционни евристики, другият — подход с невронна мрежа. Всичко останало беше еднакво.

Моделът, трениран с по-чисти данни, извлечени чрез невронна мрежа, надмина конкурента си с 1.08 процентни пункта в 13 бенчмарка. Още по-впечатляващо — тази единствена промяна им позволи да надминат модели, тренирани с FineWeb и RefinedWeb — две колекции, известни със сложните си процеси за филтриране.

Това откритие би трябвало да накара всеки ML екип да се замисли. Докато всички се надпреварват да обучават по-големи модели или да експериментират с нови архитектури, най-големите подобрения може би идват от обикновеното премахване на боклука.

Проблемът по време на генериране

Качеството на данните има значение и извън обучението. Изследване на Shi et al. (ICML 2023) показа, че дори един нерелевантен пасаж може напълно да обърка отговора на модела. Когато системата ви за извличане тегли шумно съдържание, не просто хабяте изчислителни ресурси — вие активно влошавате качеството на отговорите.

Това създава притеснителен сценарий за production системите. RAG (Retrieval-Augmented Generation) обещава да базира отговорите на съответстваща информация, но ако извличането включва странични реклами и известия за бисквитки, вие инжектирате отрова в контекстния прозорец.

Числата са красноречиви, когато погледнем как различните екстрактори запазват структурираното съдържание. Методите, базирани на евристики като Trafilatura, показват степени на прилика едва 0.13 за кодови блокове и 0.61 за математически формули в сравнение с 0.91 и 0.94 при методите с невронни мрежи. Когато документацията ви съдържа примери с код или технически означения, тези грешки при извличане се превръщат в корупция на тренировъчните данни.

Архитектурният въпрос: Encoder спрямо Decoder

Съвременните методи за извличане спадат към две категории: базирани на структура и базирани на съдържание.

Екстракторите, базирани на структура (Trafilatura, Readability, Boilerpipe) анализират HTML чрез повърхностни сигнали — позиция в DOM дървото, видове тагове, плътност на текста. Те са бързи и не изискват ML ресурси, но бъркат елементи, които изглеждат подобно. Навигационна таблица и таблица с данни имат идентични структурни характеристики, така че тези методи неизбежно класифицират грешно.

Екстракторите, базирани на четене подават действителното съдържание към трансформър модели. Dripper, текущият лидер, използва decoder архитектура, която генерира етикети токен по токен. Този подход постига отлична точност, но има фундаментален проблем с ефективността: всеки токен изисква прочитане на целия модел от паметта. Скоростта се ограничава от пропускателната способност на паметта, а не от изчисленията.

Тук един нов подход, наречен Pulpie, прави интересна архитектурна заявка. Вместо decoder, който генерира етикети последователно, Pulpie използва encoder, който етикетира всеки HTML блок с едно преминаване напред. Това премества тясното място от пропускателна способност на паметта към чисти изчисления — проблем, който се мащабира много по-лесно.

Резултатите са впечатляващи. На NVIDIA L4 GPU, малкият модел на Pulpie обработва 13.7 страници в секунда спрямо 0.68 страници в секунда при Dripper. Това е 20 пъти по-висока производителност. Преведено в реални разходи: почистването на един милиард страници струва приблизително $7,900 с Pulpie срещу $159,000 с Dripper.

Какво означава това за вашия AI стек

За стартъпи и разработчици, които работят върху AI приложения, това изследване носи практически последици:

Първо, прегледайте вашия pipeline за извличане. Ако все още използвате екстрактори на базата на евристики за тренировъчни данни или RAG системи, оставяте измерима производителност на масата. Маргиналната цена на по-доброто извличане вече е малка част от това, което беше дори преди година.

Второ, помислете къде извличането се вписва в архитектурата ви. Много екипи третират уеб съдържанието като решен проблем — вземи страницата, махни HTML-а, готово. Но тъй като моделите стават по-сложни, качеството на техните входове има значение. Вашата система за извличане е толкова добра, колкото е нейният слой за екстракция.

Трето, обмислете open-source решенията. Pulpie се присъединява към растяща екосистема от open-source модели за извличане. Дните, в които се нуждаехте от скъпи proprietetary API-та за качествено извличане, отминават.

По-голямата картина

Ставаме свидетели на тиха промяна в мисленето на ML общността относно качеството на данните. С години предположението беше, че повече данни надделяват над по-чисти данни. Увеличи мащаба на колекцията, приложи базово филтриране, тренирай по-дълго — накрая сигналът ще надделее над шума.

Но тъй като моделите достигат по-високи нива на способности, това предположение се пропуква. Когато тренирате със стотици милиарди токени, дори малки нива на корупция се натрупват в значителни щети. И когато контекстните прозорци при генериране са ограничени, всеки шумен токен е един полезен токен по-малко.

Иронията е, че уеб екстракцията — непривлекателната работа по идентифициране на основното съдържание сред HTML — може би е една от интервенциите с най-голям ефект в целия ви ML pipeline. Следващият пробив в производителността на вашия модел може би няма да дойде от нова архитектура. Може би ще дойде от това да чете уеб по-внимателно.

Чистите данни не са привлекателни. Но те са това, което отделя добрия модел от великия.