Wikidata і Google Knowledge Graph: шар сутностей за Knowledge Panels та AI-відповідями

Більшість людей, які запитують нас про "потрапити в Google Knowledge Panel" або "правильно відображатися в ChatGPT", думають, що йдеться про контент. Ні. Вони запитують про сутності (entities) — чи розпізнають машини, що керують пошуком і ШІ, їхню компанію, засновника чи продукт як окрему річ у світі, з'єднану зі стабільною ідентичністю та відомим набором фактів.

Цей шар розпізнавання має назву. Навіть кілька назв — і більшість людей вживають їх як синоніми, хоча вони означають дуже різні речі. Wikipedia — це не Wikidata. Wikidata — це не Google Knowledge Graph. І жодна з них не гарантує Knowledge Panel.

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

Три різні речі — чітко визначені

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

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

Wikidata — це структурована база даних. Не текст — це факти у машиночитаному форматі. Де Wikipedia має статтю про Ейфелеву вежу, Wikidata має елемент — запис з ідентифікатором (Q243) і списком тверджень: це екземпляр "вежі", розташована в Парижі, спроєктована Густавом Ейфелем, висота — 330 метрів тощо. Кожен із цих фактів — пара "властивість — значення", в ідеалі підкріплена джерелом. Wikidata — сестринський проєкт Wikipedia, яким керує та сама Wikimedia Foundation, але це принципово інша річ — і, що важливо, вона має нижчу планку для включення. Детальніше про це нижче.

Google Knowledge Graph — власна приватна база даних Google, яка зберігає сутності та зв'язки між ними. Запущена у 2012 році з гаслом "things, not strings" — Google перестав сприймати "Apple" як п'ятилітерний рядок і почав розглядати його як сутність: фрукт, компанія або лейбл звукозапису, кожна зі своїми фактами й зв'язками. Knowledge Graph живить Knowledge Panel (блок праворуч у результатах пошуку) і забезпечує розуміння сутностей у всіх продуктах Google. Він спирається на Wikipedia і Wikidata серед багатьох інших джерел — але Google ним керує і ви не можете редагувати його безпосередньо.

Ось ця взаємозалежність в одному реченні: Wikipedia і Wikidata — це відкриті, публічні, редаговані джерела, які Google завантажує у свій власний пропрієтарний Knowledge Graph і потім використовує (на власний розсуд) для відображення Knowledge Panel і формування відповідей ШІ.

Плутання цих трьох систем призводить до передбачуваних помилок. Люди намагаються "редагувати свій Knowledge Panel" безпосередньо — це неможливо: можна лише підтвердити права на нього та запропонувати правки. Люди думають, що елемент Wikidata автоматично створить статтю у Вікіпедії — ні, це окремі процеси з окремими планками. І люди вважають, що будь-яке з цих дій гарантує panel — ні, Google завжди приймає остаточне рішення.

Як структуровані дані живлять Google та великі мовні моделі

Щоб зрозуміти, чому Wikidata б'є вище свого класу, потрібно зрозуміти, як вона побудована — адже саме структура і є тим, чого хочуть машини.

Кожен елемент Wikidata має QID — унікальний ідентифікатор на кшталт Q95 (Google), Q312 (Apple Inc.) або Q42 (Douglas Adams). QID — це постійна адреса сутності. Вона не змінюється навіть якщо мітка змінюється, і вона не залежить від мови — Q42 — це Douglas Adams незалежно від того, чи інтерфейс англійською, японською чи арабською. Це найважливіше, що надає Wikidata: стабільний, однозначний ідентифікатор для речі.

Поверх QID розташовані твердження (statements), побудовані з властивостей (properties) і значень (values). Властивості самі мають ідентифікатори (P31 — "є екземпляром", P159 — "місцезнаходження штаб-квартири", P1448 — "офіційна назва", P856 — "офіційний сайт"). Тобто факт "Apple Inc. має штаб-квартиру в Купертіно" зберігається як Q312 → P159 → Q190080 (Купертіно). Машинам не потрібно розбирати речення — вони зчитують трійку.

Це важливо для двох споживачів:

• Google. Knowledge Graph — це сам по собі граф сутностей і трійок. Формат Wikidata майже прямо відповідає йому, тому Google завантажує Wikidata у великих масштабах, і добре побудований елемент Wikidata — один із найчистіших сигналів, які можна надіслати про ідентичність, тип і ключові атрибути сутності. Google також спирається на Wikidata для розмежування (disambiguation) — щоб відрізнити вашу компанію від п'яти інших компаній із схожою назвою.
• Великі мовні моделі. Коли велика мовна модель відповідає на питання "хто заснував [компанію]" або "де знаходиться штаб-квартира [компанії]", вона спирається на закономірності у своїх навчальних даних. Wikipedia — найважче зважене текстове джерело в більшості навчальних корпусів, а Wikidata дедалі більше з'являється в структурованих наборах даних, що використовуються для прив'язки, пошуку й запитів до баз знань. Стала, добре посилена сутність набагато більш імовірно буде представлена правильно — і набагато менш імовірно буде сплутана з однойменною сутністю — ніж та, що існує лише як розрізнені, неструктуровані згадки по відкритому вебу.

Ось чесна версія "видимості для ШІ", і це фундамент entity-based SEO та роботи з Knowledge Graph: ви не вводите контент у ChatGPT або Gemini. Цього не може ніхто. Що можна зробити — це побудувати чисту, машиночитану, добре підкріплену інфраструктуру, яка підвищує ймовірність точного опису вашої сутності машинами. Ми детальніше писали про цю відмінність у нашій роботі з AI visibility — важіль — це якість джерел і структуровані дані, а не маніпуляція промптами.

Нижча планка значущості у Wikidata

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

Wikipedia вимагає значущості (notability) — суб'єкт повинен бути достатньо відомим, щоб незалежні джерела детально висвітлили його. Wikidata вимагає значно меншого: приблизно верифікованого існування й ідентифікованості, плюс або посилання на наявну сторінку Wikimedia, або посилання на серйозне зовнішнє джерело, або структурна необхідність для опису інших елементів.

Прочитайте ще раз, адже різниця тут — це і є весь сенс. Wikipedia запитує: "Чи достатньо важливий цей суб'єкт, щоб про нього писав світ?" Wikidata запитує: "Чи можемо ми підтвердити, що ця річ існує, і вказати на джерело, яке це підтверджує?" Це абсолютно різні пороги.

На практиці це означає, що компанія середнього розміру, якій відмовили б у Вікіпедії — недостатньо незалежних поглибленостей — часто може мати цілком законний елемент Wikidata, якщо її існування та ключові факти можна верифікувати через авторитетні посилання: запис у реєстрі компаній, регуляторне подання, авторитетний запис, усталені зовнішні бази даних. Елемент не зробить компанію відомою і не сфабрикує значущість. Але він дає сутності QID, стабільну ідентичність і набір машиночитаних фактів, які може читати Knowledge Graph і великі мовні моделі.

Кілька чесних застережень, щоб ніхто не трактував це надміру:

• "Нижча планка" — не "відсутність планки". У Wikidata є правила значущості, і елементи для незначущих суб'єктів без серйозних посилань видаляються. Не можна створити елемент для консультанта-одинака з нульовим зовнішнім слідом і очікувати, що він виживе.
• Wikidata — не рекламний майданчик. Це фактична база даних. Там немає місця для маркетингових формулювань — і не повинно бути.
• Елемент Wikidata сам по собі є слабшим сигналом, ніж стаття у Вікіпедії. Це фундамент, а не фінішна лінія.

Але для великого кола компаній і осіб, які реальні й верифіковані, але ще не мають значущості за стандартами Wikipedia, Wikidata — це крок на рівні сутностей, що реально досяжний уже сьогодні. Саме тому ми так часто рекомендуємо починати з нього.

Анатомія Google Knowledge Panel

Коли з'являється Knowledge Panel, його поля збираються з кількох джерел. Жодне єдине джерело не "володіє" панеллю. Розуміння того, яке поле звідки зазвичай надходить, допомагає зрозуміти, що варто виправити — і де Wikidata справді має важелі впливу.

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

Два висновки. По-перше, панель — це композит: покращення одного джерела покращує один фрагмент. Якщо опис хибний — це зазвичай проблема вступу у Вікіпедії; якщо адреса хибна — це проблема Google Business Profile; якщо неправильна дата заснування або тип сутності — це найчастіше проблема Wikidata. По-друге, чи з'явиться панель взагалі — це рішення Google, яке визначається передусім тим, чи впевнений Google у реальності, самостійності та достатній значущості сутності. Wikidata і Wikipedia підвищують цю впевненість. Але не зобов'язують до результату.

Основи entity SEO: sameAs, schema та авторитетні записи

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

Практичні будівельні блоки:

• Структуровані дані schema.org на вашому власному сайті. Розмітка головної сторінки або сторінки "Про нас" за допомогою схем Organization або Person (у JSON-LD) напряму повідомляє Google, яку сутність представляє сайт: її назву, логотип, дату заснування та ключових людей. Це єдина частина шару сутностей, яку ви повністю контролюєте — на власній інфраструктурі.
• Властивість sameAs. Усередині цієї розмітки schema sameAs — це масив URL-адрес, що вказують на інші авторитетні представлення тієї самої сутності: ваша стаття у Вікіпедії, ваш елемент Wikidata, ваші верифіковані профілі у соцмережах, ваш запис у Crunchbase або галузевій базі даних. sameAs — це, по суті, ваше повідомлення Google: "всі ці посилання стосуються одного й того самого". Це з'єднувальна тканина між вашим власним сайтом і відкритим графом сутностей.
• Авторитетні записи. Це формальні, інституційні ідентифікатори, що підтримуються бібліотеками, органами зі стандартів і реєстрами. Вони є зовнішнім підтвердженням того, що визнана установа каталогізувала вашу сутність. Найпоширеніші:

Wikidata — це місце, де багато з них сходяться разом: добре побудований елемент містить посилання на VIAF, ISNI, ORCID, LEI, GRID/ROR та інші через спеціальні властивості. Це перетворює елемент Wikidata на хаб — єдине місце, де машина може підтвердити, що "цей QID" = "цей LEI" = "цей ORCID" = "ця стаття у Вікіпедії". Кожен збіжний ідентифікатор — ще один голос на підтвердження того, що сутність реальна й унікальна.

Не потрібні всі ці ідентифікатори. Науково-дослідний інститут повинен мати GRID/ROR; публічна компанія — LEI; індивідуальний науковець — ORCID. Суть не в тому, щоб колекціонувати значки, а в тому, щоб ідентифікатори, на які ви законно маєте право, були наявні й консистентні, — і тоді весь граф погоджується сам із собою.

Типові провали

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

• Елементи-сироти. Елемент існує, але ніщо на нього не посилається і він сам ні на що не посилається. Це запис, що плаває в порожнечі, без жодних зв'язків. Knowledge Graph — це граф: сутності отримують значення через свої зв'язки. Елемент без вхідних або вихідних посилань на інші сутності майже невидимий для систем, що споживають Wikidata.
• Відсутні посилання на джерела. Твердження без джерел — слабкі й схильні до видалення. "Штаб-квартира: Берлін" без посилання — це твердження; "Штаб-квартира: Берлін" із посиланням на реєстр компаній — це факт. Елементи без посилань помічаються, а твердження без джерел видаляються або ігноруються обережними споживачами downstream.
• Відсутнє англійське посилання на сайт (або взагалі жодного sitelink). Sitelink з'єднує елемент Wikidata зі статтею у Вікіпедії певною мовою. Багато цінних інтеграцій і значна частина впевненості Google спираються на зв'язок з англійською версією. Елемент без sitelink на жодну редакцію Wikipedia є більш тонким і важчим для систем для довіри до нього. (Саме тому елемент Wikidata не є замінником статті у Вікіпедії, коли її можна отримати.)
• Неоднозначні або дублюючі сутності. Два елементи для однієї компанії. Засновник, сплутаний зі спортсменом-тезкою. Продукт, об'єднаний із елементом компанії, або розділений, коли не слід. Дублікати й неоднозначність руйнують розпізнавання сутностей — саме ту проблему, яку й покликана вирішити система QID. Об'єднання дублікатів і розмежування сутностей, що конфліктують, — часто найбільш цінна робота з очищення наявного елемента.

Жодна з цих проблем не є екзотичною. Це різниця між елементом, який існує, і елементом, який працює — і виявлення цих помилок становить основну частину ретельної роботи з Wikidata.

Реалістичні терміни і що чистий елемент може і не може запустити

Управляємо очікуваннями чесно, бо саме звідси йде більшість розчарувань.

Створення добре побудованого елемента Wikidata само по собі не є повільним — елемент може бути опублікованим за день. Час займає поширення downstream, і цей графік не підконтрольний нікому, крім Google.

• Створення елемента: від кількох годин до дня для належно структурованого, підкріпленого посиланнями елемента.
• Індексування та завантаження Google: зазвичай тижні. Google повторно завантажує Wikidata за власним розкладом.
• Видимий ефект на Knowledge Panel (якщо він взагалі з'явиться): від тижнів до місяців, і лише якщо Google вирішить, що сутність заслуговує на панель.

Що чистий елемент Wikidata може зробити:

• Встановити стабільний QID і машиночитану ідентичність для сутності.
• Покращити розмежування — знизити ймовірність плутанини з однойменною сутністю.
• Надати точні структуровані факти (тип сутності, засновники, штаб-квартира, офіційний сайт, ідентифікатори), які можуть читати Google і великі мовні моделі.
• Зміцнити мережу sameAs, пов'язавши schema вашого власного сайту з авторитетним зовнішнім хабом.
• Зробити дані-скафолдинг майбутньої статті у Вікіпедії чистішим.

Що чистий елемент Wikidata не може зробити:

• Гарантувати Knowledge Panel. Google завжди приймає остаточне рішення, і багато цілком нормальних сутностей ніколи не отримують панелі.
• Створити значущість (notability). Він фіксує верифіковані факти; він не робить вас важливими і не замінить незалежне висвітлення, якого вимагає стаття у Вікіпедії.
• Вводити або контролювати вивід ШІ. Він підвищує ймовірність точного представлення. Він не дозволяє диктувати, що скаже модель.
• Перевизначати дані Google Business Profile. Ваша адреса, години роботи та відгуки надходять з іншого місця.
• Вижити, якщо він рекламний або без посилань на джерела. Wikidata — це фактична база даних з активними редакторами й ботами; сміттєвий елемент буде прибрано.

Якщо агенція запевняє вас, що елемент Wikidata гарантує Knowledge Panel або контролює те, як ChatGPT описує вас, — це та ж пуста обіцянка, про яку ми попереджаємо всюди. Чесний пітч — імовірнісний: чиста інфраструктура сутностей підвищує шанси на точне, відповідне представлення. Це не перемикач, який можна просто увімкнути.

Коли Wikidata — правильний перший крок

Wikidata — правильний перший крок — до спроби отримати повноцінну статтю у Вікіпедії — у впізнаваних ситуаціях:

• Суб'єкт реальний і верифікований, але ще не має значущості (notability) за стандартами Wikipedia. Найпоширеніший випадок. Є запис у реєстрі компаній, регуляторний слід, можливо якесь галузеве висвітлення, але не 3–5 незалежних поглиблених матеріалів, яких потребує стаття у Вікіпедії. Wikidata дає сутності законну машиночитану ідентичність зараз, поки ви нарощуєте базу джерел для Wikipedia пізніше.
• Є проблема плутанини сутностей. Google або велика мовна модель плутає вас з однойменною компанією, особою або продуктом. Чистий, розмежований елемент із правильними ідентифікаторами часто є найбільш прямим виправленням.
• Ви хочете закласти entity-SEO фундамент перед більшим просуванням. Розмітка schema, sameAs і чистий хаб Wikidata — це основа, поверх якої повинна лягти стаття у Вікіпедії; не замінник, а шар, що робить все інше більш зв'язаним.
• Ви не впевнені, чи взагалі відповідаєте критеріям Wikipedia. Для цього саме й існує аудит значущості для Wikipedia. Якщо аудит покаже, що джерела підтримують статтю — чудово, переходьте до створення сторінки у Вікіпедії, зі Wikidata як частиною того самого робочого потоку. Якщо джерел бракує, Wikidata — це досяжний крок, який усе одно рухає шар сутностей вперед, поки ви закриваєте прогалину в висвітленні.

Логіка послідовності проста. Wikidata має нижчу планку й швидший шлях до законного результату, тому саме там мають починати верифіковані, але ще не відомі суб'єкти. Wikipedia має вищу планку й сильніший сигнал, тому там ви працюєте коли джерела справді є. Спроба отримати Wikipedia першою, не маючи відповідних джерел, витрачає тижні й ризикує видаленням, яке ускладнить наступну спробу. Побудова Wikidata першою коштує небагато, допомагає в будь-якому разі і ніколи не шкодить справі у Вікіпедії.

Це не хак, не ярлик до слави і не гарантована панель. Це шар сутностей — негламурний, структурований, добре підкріплений посиланнями фундамент, що дозволяє машинам точно описувати вас. Для багатьох компаній і осіб правильна побудова цього шару — водночас і найбільш досяжний, і найбільш недооцінений крок у всій розмові про видимість для ШІ.

Не впевнені, чи ваша сутність має починати з Wikidata або одразу йти за статтею у Вікіпедії? Напишіть нам на team@wikibusines.com — ми надішлемо чесну оцінку того, який крок насправді підходить для вашої ситуації.