ORES/uk

ORES (/ɔɹz/) — це вебсервіс та API, що надають машинне навчання як послугу для проєктів Вікімедіа, і підтримуються Командою платформи оцінювання (Scoring Platform team). Система розроблена для автоматизації критичноважливої вікіроботи: наприклад, виявлення та усунення вандалізму. Наразі ORES генерує два загальні типи оцінок, які лежать у контекстах «якість редагування» і «якісь статті».

ORES є сервісом бекенду, і не дає прямого способу використовувати оцінки. Якщо ви б хотіли використовувати оцінки ORES, ознайомтеся з нашим списком інструментів, які використовують оцінки ORES. Якщо ORES іще не підтримує вашу вікі, див. нашу послідовність кроків для запиту підтримки.

Шукаєте відповіді на свої запитання про ORES? Перегляньте ЧаПи ORES.

Якість редагування
Один з найбільш критичних моментів, коли йдеться про відкриті проєкти Вікімедіа, це розгляд потенційно шкідливого внеску («редагувань»). Також є потреба визначати дописувачів з добрими намірами (які можуть ненавмисне спричиняти шкоду) і пропонувати їм допомогу. Ці моделі мають на меті полегшити роботу з фільтрування стрічки Спеціальна:Нові_редагування. Ми пропонуємо два рівні підтримки для моделей передбачення якості редагувань: базовий та розширений.

Базова підтримка
Припускаючи, що більшість шкідливих редагувань будуть відкинуті, а редагування, що не шкодять, такими не будуть, ми можемо використати як основу історію редагувань (і відкинутих редагувань) з вікі. Ця модель налаштовується легко, але вона потерпає від того, що багато редагувань відкидають з інших причин, що не стосуються шкоди і вандалізму. Щоб зарадити цьому, ми створюємо модель, що базується на поганих словах.


 * — передбачає, чи редагування буде в результаті відкинуте

Розширена підтримка
Замість робити припущення, ми можемо попросити редакторів натренувати ORES розрізняти, які редагування справді є шкідливими, а які схожі на добрі наміри. Це вимагає додаткової роботи з боку волонтерів у спільноті, але це дозволяє набагато точніші й тонші передбачення з огляду на якість редагування. Багато інструментів працюватимуть лише тоді, коли для вікі є розширена підтримка. Many tools will only function when advanced support is available for a target wiki.


 * — передбачає, чи редагування спричиняє шкоду чи ні
 * — передбачає, чи редагування було збережене з добрими намірами

Якість статті
Якість статей Вікіпедії є ключовою турботою вікіпедистів. Нові сторінки мають бути розглянуті й перевірені, щоб у вікі точно не залишилися спам, вандалізм та нападки. Якість статей, які виживають первинний розгляд, деякі вікіпедисти періодично оцінюють, але це дуже працезатратна діяльність, й оцінки часто застарілі. New pages must be reviewed and curated to ensure that spam, vandalism, and attack articles do not remain in the wiki. For articles that survive the initial curation, some of the Wikipedians periodically evaluate the quality of articles, but this is highly labor intensive and the assessments are often out of date.

New article evaluation
Чим швидше вилучать дуже проблемні види статей-чернеток, тим краще. Нагляд за новоствореними сторінками може означати величезний обсяг роботи. Подібно до проблеми протидії вандалізму в редагуваннях, машинні передбачення можуть допомогти кураторам зосередитися перш за все на найбільш проблемних нових сторінках. На основі коментарів, які адміни залишають при вилученні сторінок (див. таблицю журналів), ми можемо натренувати модель, яка передбачатиме, які сторінки треба швидко вилучити. Див. список причин для швидкого вилучення в англійській Вікіпедії на en:WP:CSD. Для англійської моделі ми використали G3 «вандалізм», G10 «напад» та G11 «спам». Curating new page creations can be a lot of work. Like the problem of counter-vandalism in edits, machine predictions can help curators focus on the most problematic new pages first. Based on comments left by admins when they delete pages (see the logging table), we can train a model to predict which pages will need quick deletion. See en:WP:CSD for a list of quick deletion reasons for English Wikipedia. For the English model, we used G3 "vandalism", G10 "attack", and G11 "spam".


 * — передбачає, чи стаття має бути швидко вилучена (spam, vandalism, attack або OK)

Existing article assessment
Якість статей, які виживають первинний розгляд, у деяких великих Вікіпедіях періодично оцінюють з використанням шкали, яка значною мірою відповідає шкалі оцінювання англійської Вікіпедії 1.0 («articlequality»). Мати ці оцінки дуже корисно, бо це допомагає нам виміряти прогрес і визначити упущені можливості (наприклад, популярні статті низької якості). Однак доволі складно робити так, щоб ці оцінки завжди були свіжими, тому покриття статей оцінками непослідовне. Тут приходить на допомогу модель машинного навчання. Натренувавши модель відтворювати оцінювання якості статей, яке проводять люди, ми можемо автоматично оцінити кожну статтю й кожну версію з допомогою комп'ютера. Ця модель використовується, щоб допомогти вікіпроєктам сортувати за нагальністю роботу з повторного оцінювання і досліджувати, які саме редагування призводять до покращення якості статей. Having these assessments is very useful because it helps us gauge our progress and identify missed opportunities (e.g., popular articles that are low quality). However, keeping these assessments up to date is challenging, so coverage is inconsistent. This is where the  machine learning model comes in handy. By training a model to replicate the article quality assessments that humans perform, we can automatically assess every article and every revision with a computer. This model has been used to help WikiProjects triage re-assessment work and to explore the editing dynamics that lead to article quality improvements.

Модель articlequality базує свої передбачення на структурних характеристиках статті. Наприклад, скільки у статті розділів? чи є картка? скільки приміток на джерела? Чи використовують примітки шаблон cite? Модель articlequality не оцінює якість тексту або наявність проблем викладу (скажімо, чи не просувається одна точка зору). Але схоже, багато структурних характеристик статей значно корелюють із гарним письмом і тоном, тому моделі дуже добре працюють на практиці. E.g. How many sections are there? Is there an infobox? How many references? And do the references use a cite template? The articlequality model doesn't evaluate the quality of the writing or whether or not there's a tone problem (e.g. a point of view being pushed). However, many of the structural characteristics of articles seem to correlate strongly with good writing and tone, so the models work very well in practice.


 * — передбачає (подібну до Wikipedia 1.0) оцінку статті чи чернетки за якістю

Маршрутизація тем


Модель ORES для тем статей застосовує інтуїтивну низхідну таксономію для будь-якої статті у Вікіпедії — навіть для нових чернеток статей. Ця маршрутизація тем корисна для нагляду за новими статтями, створення робочих списків, формування нових Вікіпроєктів та аналізування прогалин контенту.

Тематичні моделі ORES тренуються з використанням вкладання слів (en:word embedding) у реальному контенті. Для кожної мови вивчається і застосовується мовноспецифічне вкладання. Оскільки ця стратегія моделювання залежить від теми статті, передбачення теми можуть відрізнятися між мовами залежно від тем, присутніх у тексті тієї чи іншої статті.

New article evaluation


Найбільша складність при розгляді нових статей полягає у тому, щоб знайти когось знайомого з темою, щоб оцінити значущість, релевантність та правильність. Наша модель  розроблена для спрямування новостворених статей залежно від їхньої передбаченої тематичної природи до зацікавлених рецензентів. Модель тренується і тестується на першій версії статей і таким чином годиться лише для нових чернеток статей.


 * – передбачає тему нової чернетки статті

Мапування тематичної приналежності


Тематична пов'язаність статей є важливою концепцією для організації роботи у Вікіпедії. Тематичні робочі групи стали звичною стратегією управління продукуванням і патрулюванням вмісту Вікіпедії. Однак високорівнева ієрархія ще не доступна або ж не піддається автоматичним запитам з багатьох причин. Як наслідок, будь-хто, хто хоче організувати роботу навколо якоїсь теми або зробити робочий список, мусить виконати значну ручну роботу з виявлення відповідних статей. Завдяки нашій моделі, ці запити можна робити автоматично.


 * – передбачає тему статті

Таблиця підтримки
Таблиця підтримки ORES повідомляє статус підтримки ORES за вікі і доступними моделями. Якщо ви не бачите у списку своєї вікі або моделі, яку б хотіли використовувати, ви можете подати запит на підтримку. If you don't see your wiki listed, or support for the model you'd like to use, you can request support.

Використання API
ORES пропонує сервіс RESTful API для динамічного отримання інформації з оцінками версій. '''Див. більше інформації про те, як використовувати API, на https://ores.wikimedia.org.'''

Якщо ви робите запити до сервісу про велику кількість версій, рекомендовано згруповувати їх по 50 версій в одному запиті, як описано нижче. Прийнятно подавати до 4 паралельних запитів. Для ще більшого числа запитів, ви можете запускати ORES локально

Приклад запиту: |wp10&revids=34854345|485104318 http://ores.wmflabs.org/v3/scores/enwiki/?modelsdraftquality|wp10&revids34854345|485104318

Приклад запиту: https://ores.wikimedia.org/v3/scores/wikidatawiki/421063984/damaging

Використання EventStream
Оцінки ORES також надаються у вигляді EventStream на https://stream.wikimedia.org/v2/stream/revision-score

Локальне використання
Щоб запустити ORES локально, ви можете встановити ORES так:

Після цього ви зможете запустити його так:

Ви мажете побачити такий вивід: