TL;DR
AI-пошук — це не «той самий Google, тільки з ботом». Це окремий пайплайн із пʼяти кроків: користувач пише запит → LLM розгортає його у 6–12 під-запитів (fan-out) → система шукає документи за семантичною схожістю, а не за ключовими словами → reranker обирає 3–8 джерел для цитування → модель синтезує відповідь і вказує, кого процитовано. Для бренду це означає одне: видимість тепер залежить не від позиції в SERP, а від того, чи готовий ваш контент бути витягнутим як окремий chunk із цитатою. Це не SEO, переписане новими буквами. Це нова дисципліна — AI Visibility.
Словник: 6 термінів, без яких далі читати немає сенсу
RAG (Retrieval-Augmented Generation) — підхід, за яким LLM перед відповіддю шукає документи у зовнішньому індексі та використовує їх як контекст.
Embeddings — числове подання тексту як вектора у багатовимірному просторі; дозволяє вимірювати семантичну схожість між запитом і документом.
Dense retrieval — пошук по векторах (embeddings), а не по ключових словах. Знаходить документи з тим самим змістом, навіть якщо вони не містять буквальних слів запиту.
Fan-out query — автоматичне розгортання одного запиту користувача у декілька паралельних під-запитів, які LLM виконує одночасно.
Citation density — частота, з якою бренд або джерело згадане у документах, що були видані як цитати у відповідях AI.
Grounding — процес «привʼязування» згенерованої відповіді до конкретних джерел, щоб модель могла показати, звідки взяла те чи інше твердження.
Чому AI-пошук — це не Google з обкладинкою?
У класичному Google між запитом і відповіддю стоїть індекс ключових слів і граф посилань. Користувач шукає — Google ранжує сторінки — користувач клікає. Видавець виграє, якщо потрапив у топ-10.
У AI-пошуку схема інша. Між запитом і відповіддю стоїть LLM, який читає документи, витягує з них фрагменти і синтезує нову відповідь власними словами. Видавець виграє не тоді, коли стоїть високо у видачі, а коли його текст обрано як джерело цитати всередині відповіді. Між цими двома моделями розриви фундаментальні: інші сигнали ранжування, інша одиниця контенту (chunk проти сторінки), інша метрика успіху (citation замість rank), інший формат, який «зчитується». Решта статті — про те, як цей пайплайн працює зсередини у пʼяти кроках.
Крок 1 — Користувач пише prompt, і він не дорівнює запиту в Google
Спершу варто прийняти базову відмінність. Запит у Google — це 2–4 слова: «купити цемент київ». Prompt у ChatGPT — це повне речення: «Порівняй цемент М500 і М400 для фундаменту приватного будинку, врахуй кліматичні умови Київщини». Це не той самий запит, переписаний довшими словами. Це інший жанр комунікації.
LLM очікує контекст, наміри і обмеження. Користувач часто пише так, ніби говорить зі співрозмовником. У відповідь модель розвʼязує не одне запитання, а цілу задачу: визначає, про що насправді запит, які додаткові факти потрібно дістати, в якому форматі повертати відповідь.
Для маркетолога це означає: ключовий запит, на який оптимізовано стару SEO-сторінку «цемент М500 ціна», у AI-пошуку не існує у тому ж вигляді. Натомість існує клас задач, у який цей запит входить.
Крок 2 — LLM розгортає prompt у fan-out queries
Прийнявши prompt, модель робить те, чого Google не робить публічно: розкладає його на декілька паралельних під-запитів. Це і є fan-out.
Один prompt «Порівняй цемент М500 і М400 для фундаменту…» розгорнеться у щось на кшталт:
- «Технічні характеристики цементу М500»
- «Технічні характеристики цементу М400»
- «Який цемент рекомендують для фундаменту приватного будинку»
- «Кліматичні умови Київщини: морозостійкість і вологість»
- «Норми ДБН для цементу у фундаменті»
- «Виробники цементу України»
- «Ціни на цемент Україна 2026»
- «Як обрати цемент: порівняльна методика»
Кожен з цих під-запитів виконується окремо, проти власного набору джерел. Якщо ваш бренд оптимізований лише під одну сторінку «цемент М500», ви можете бути присутні в одному з восьми ретривалів — і відсутні у решті семи. Кінцева відповідь читається з усіх восьми, і ваш бренд має шанс на цитування лише в тій частині, де ви були знайдені.
Висновок практичний: один prompt — багато retrieval-вікон. Покриття треба будувати під весь клас задачі, а не під «головний ключ».
Крок 3 — Retrieval: як LLM знаходить релевантні документи
Тут видно найбільший розрив зі старим SEO. Google в основі своїй знаходить документи за збігом слів і ваги посилань. LLM-пошук використовує dense retrieval: і запит, і документи переводяться в embeddings — числові вектори — після чого система шукає документи, чий вектор найближчий до вектора запиту.
Це означає, що документ може бути обраний, не містячи жодного слова з запиту. Якщо ви написали «бетонна суміш на основі портландцементу марки 500 для несної конструкції», система може видати вашу сторінку у відповідь на запит про «цемент М500 для фундаменту» — бо смисл вектора близький.
Це водночас і шанс, і пастка. Шанс — у тому, що оптимізація під семантичну тему (не під ключове слово) стає реальною механікою. Пастка — у тому, що контент, написаний «під ключі», без звʼязного сенсу, тепер працює гірше, бо вектор виходить розпорошений.
Окрема деталь: retrieval працює не зі сторінками, а з chunks — фрагментами тексту по 200–800 токенів. Тому одиниця оптимізації — не сторінка цілком, а самодостатній абзац або розділ, який можна витягнути окремо і він буде зрозумілим без контексту решти статті.
Крок 4 — Reranking і citation: як LLM обирає, кого процитувати
Перший retrieval повертає десятки кандидатів. На цьому етапі вступає reranker — окрема модель, яка перевпорядковує цих кандидатів за тоншими критеріями: точність відповідності, авторитет джерела, дата оновлення, наявність структури, чи фрагмент безпосередньо відповідає на під-запит.
Після reranking залишається невелика підмножина — зазвичай 3–8 chunks — які підуть у фінальну відповідь. Саме їх модель цитує. І саме сюди має потрапити ваш контент, щоб бренд згадали у відповіді AI.
Що штовхає чанк нагору в reranking? Поки що з публічних патентів (Google, OpenAI) і досліджень видно сім факторів: цитата починається з прямої відповіді на запит, фрагмент має структуру (заголовок, список, таблиця), бренд або автор має entity-record у Knowledge Graph або Wikidata, джерело має зовнішні цитування з авторитетних доменів, дата оновлення свіжа, схема даних (Article, FAQPage, HowTo) присутня, текст самодостатній (не потребує контексту попередніх абзаців).
Цей список — серцевина того, що називають Generative Engine Optimization: формулювати контент так, щоб він пройшов reranking, а не лише retrieval.
Крок 5 — Answer synthesis: чому AI каже «згідно з brandX»
Останній крок — генерація відповіді. LLM має 3–8 джерел і завдання користувача. Модель пише відповідь у власному регістрі, але при цьому привʼязує окремі твердження до конкретних джерел (grounding).
Залежно від платформи цей звʼязок видно по-різному: Perplexity показує суцільну нумерацію джерел і прямі цитати; ChatGPT (з увімкненим пошуком) виносить «джерела» у бічну панель; Gemini вбудовує посилання в текст; Google AI Overviews виводить інлайн-цитати з фірмовими картками.
Бренди, які потрапили на цей крок, отримують безкоштовну рекомендацію — поза рейтингом, поза рекламним аукціоном. Тут немає кліку у звичному сенсі: модель уже відповіла користувачу. Цінність — у самій згадці.
І це повертає нас до головного: у AI-пошуку ви не «ранкуєте». Ви або цитовані, або не існуєте у відповіді.
Чим відрізняються 4 платформи: ChatGPT, Perplexity, Gemini, AI Overviews
Не всі AI-пошуковики однакові. Розуміння їхньої механіки — основа стратегії пріоритетів.
| Параметр | ChatGPT (з Search) | Perplexity | Gemini | Google AI Overviews |
|---|---|---|---|---|
| Основа retrieval | Bing API + GPT-tooling | Власний індекс + Google | Власний індекс Google | Google Search index |
| Частота оновлення | Real-time для search-режиму | Real-time | Real-time + кешовані | Real-time (свіжі SERP) |
| Цитування у відповіді | Помірне, лінки знизу | Висока, нумеровані інлайн | Помірне, інлайн-лінки | Висока, інлайн-картки |
| Як видно бренд | Назва + URL у sources | Назва + URL у footnote | Назва + favicon | Назва + favicon + сніппет |
| Українська мова | Підтримує, якість росте | Підтримує, добре | Підтримує | Поступове розгортання UA |
| Аудиторія в UA (Q2 2026) | Найширша | Швидко росте у фахівців | Зростає через Android | Найвища пасивна охоплюваність |
Ця таблиця — не «куди йти першим». Це орієнтир. У AI Visibility роботі немає сенсу вибирати одну платформу: вони витягують з різних джерел, і присутність формується паралельно. Стратегія — мати контент, який ефективний у dense retrieval взагалі, а далі специфіка платформ грає роль вже у тонкому tuning.
Що з цього випливає для роботи маркетолога — 5 практичних висновків
Перший. Одиниця контенту — не сторінка, а chunk. Кожен заголовок другого рівня має читатися без решти статті. Якщо ваш H2 починається з «Як ми вже зазначали…» — він не буде витягнутий.
Другий. Семантичне покриття важливіше за щільність ключів. Стара SEO-логіка «вставити фразу 5 разів» у AI-пошуку працює проти вас, бо такий текст має «слабкий» вектор. Натомість виграє контент, який чітко тримається теми, дає визначення, відповідає на під-запити.
Третій. Структура — це ranking-сигнал. Списки, таблиці, нумеровані протоколи, FAQ-блоки — це формат, який reranker воліє. Це не косметика; це техніка.
Четвертий. Author entity і brand entity мають значення. LLM-системи перевіряють, чи відомий автор/бренд у графах сутностей (Wikidata, Knowledge Graph). Без author byline і базових entity-сигналів (Wikipedia, sameAs, JSON-LD Organization) ви відсутні з самого початку.
Пʼятий. AI Visibility — це окрема професія, а не «розширення» SEO. Багато з вищеперерахованого тільки виглядає як «новий SEO». Насправді це інший інструментарій (audit-системи, prompt-research замість keyword research, citation-tracking замість rank-tracking) і інша щотижнева робота. Це і є дисципліна, яку викладає AI Visibility School — і про яку ми ще багато разів повернемося у цьому блозі.
Окремо варто сказати про час дії цих висновків. Архітектура fan-out + dense retrieval + reranking — це не «тренд цього кварталу». Це базова механіка RAG-систем, описана у відкритих публікаціях (Karpukhin et al. 2020, Lewis et al. 2020) і впроваджена у всі чотири розглянуті платформи. Можуть змінитися ваги окремих сигналів, зʼявляться нові метрики (зараз активно тестується «authoritativeness» як окремий вектор), відкоригується частка real-time retrieval проти training corpus. Але загальний пайплайн — стабільний на горизонті 24–36 місяців. Тому інвестиція в структурний контент сьогодні — це не лотерея на короткий тренд, а будівництво активу під механіку, яка протримається кілька років.
FAQ
Чи LLM «гуглить» у момент відповіді?
Залежно від платформи. ChatGPT (із Search), Perplexity, Gemini і Google AI Overviews — так, виконують real-time retrieval. Класичний ChatGPT (без search-tool) відповідає лише з тренувального корпусу, який зафіксовано на даті cutoff. Для AI Visibility важливі обидва канали.
Як часто оновлюються джерела, які бачить LLM?
Real-time retrieval — миттєво для свіжих публікацій (сторінка індексується протягом годин-днів). Training corpus оновлюється з релізами моделей — це періодична фіксація. Новий контент має бути одночасно і проіндексованим у пошуку для real-time, і цитованим у мережі для потрапляння у наступні тренувальні корпуси.
Чому AI цитує не нас, хоча ми у топ-1 Google?
Тому що retrieval у AI-пошуку працює інакше. Високий rank у Google не гарантує, що ваш конкретний chunk пройде dense retrieval і reranking. Найчастіші причини: контент написаний під ключі, а не під сенс (слабкі embeddings); відсутність структури всередині сторінки; відсутність author/brand entity; chunk не самодостатній. Це предмет окремого аудиту — у статті AI Visibility Audit ми детально проходимо ці причини.
Чи це той самий «prompt engineering»?
Ні. Prompt engineering — це робота з боку користувача LLM. AI Visibility — це робота з боку бренду / контенту. У цій статті ми говорили винятково про другу сторону: як побудувати контент так, щоб LLM його обрала для цитати.
Що з цього робити просто зараз, без бюджету?
Три речі. По-перше, відкрити ChatGPT, Perplexity, Gemini, поставити 5–10 запитів, на які мав би відповідати ваш бренд, і записати, цитують вас чи ні. По-друге, переглянути будь-яку важливу сторінку власного сайту і чесно перевірити: чи кожен H2-блок читається без контексту? Чи є визначення термінів? Чи є структуровані списки і таблиці? По-третє, переконатися, що у JSON-LD сторінки є Article або Organization з author entity. Це нульовий-бюджетний baseline, з якого починається будь-яка робота.
Що читати далі
Якщо хочете побачити, які саме сигнали впливають на reranking — у деталях, з нумерацією, — є окрема стаття GEO vs AEO vs LLMO vs SGE vs AI Visibility — словник нової епохи. А коли будете готові перевірити власний сайт чи сайт клієнта — практичний протокол у статті AI Visibility Audit за 1 годину.