Що читає AI‑асистент, коли читає вашу сторінку

Система пошуку ніколи не читає вашу сторінку. Вона читає лише окремі уривки — кілька, відібраних за схожістю до питання — і решта вмісту сторінки може так само не існувати для цієї відповіді. Це не деталізація реалізації окремого продукту. Це те, чим є retrieval-augmented generation, і так було з моменту paper that named it у 2020 році: отримати уривки, потім писати на їх основі.

Отже, цікаве питання щодо сторінки не в тому, наскільки вона хороша. Питання — які уривки отримає retriever, у якій послідовності, і чи серед них є той, що містить вашу відповідь.

Ми створили Vectorscope для відповіді на це для однієї URL‑адреси за раз, і він запускає реальний конвеєр — той самий chunker, та сама embedding model, той самий passage cap, який застосовується у платному продукті. Демонстрація спрощеної версії лише підкреслить конвеєр, який вона демонструє.

Шість сторінок і число, яке виявилось не важливим

Ми обробили шість сторінок: посібник постачальника щодо податкової форми, три довідкові та документаційні сторінки, дуже довгу статтю в енциклопедії та нашу власну сторінку Vectorscope. Кожне число нижче отримане інструментом 19 серпня 2026 р., за використанням розгорнутого конвеєра — voyage-4-lite embeddings з 1 024 вимірами та обмеженням у 26 проходжень на сторінку.

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

Вона вражає лише один раз, і вражає сильно. Стаття Wikipedia про трансформери містить 14 163 слова; retriever (модуль пошуку) отримав 26 фрагментів, що містять 47 275 символів, і залишив 53 903 символи непрочитаними — 53,3 % сторінки. Понад половина найчастіше посилаємого пояснення архітектури за кожною моделлю, згаданою тут, з точки зору одного проходу пошуку, відсутня.

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

Що відрізнялося: наскільки сторінка повторює себе

Дивіться на останню колонку. Самоподібність — це середня косинусна схожість між власними фрагментами сторінки — наскільки схожі частини однієї сторінки між собою. Шість сторінок мають значення від 0.698 до 0.854, і порядок не відповідає їх кількості слів.

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

Високе значення означає, що сторінка багаторазово повторює одну думку. Це приводить до незручної частини.

Ми протестували його на собі і зайшли останніми

Наша власна сторінка Vectorscope отримала 0,854 — найвищий результат, з великим відривом, серед шести сторінок, які ми не вибирали, щоб підкреслити себе. Її 1 556 слів перетворилося на шість уривків у трьох групах, одна з яких містить один уривок, інша — чотири. Простими словами: сторінка формулює один аргумент, повторюючи його різними формулюваннями.

Гірше, 1 994 з її 10 235 витягнутих символів — 19 % — класифіковано як допоміжний вміст, а не основний: навігація, елементи керування, смужка мікросхем вгорі. У посібнику W‑9 аналогічна цифра склала 434 символи з 29 270, що становить 1,5 %.

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

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

Chunking — це крок, який ніхто не бачить і за який всіх оцінюють.

Fixed-length chunking розрізає кожні N символів. Це типово у більшості конвеєрів, тому що його легко реалізувати, і він розрізає посеред речень, відокремлює заголовок від відповіді під ним і створює уривки, які починаються з половини слова. Це швидко, дешево, повторювано і причина, чому багато сторінок погано повертаються за питаннями, на які вони відповідають ідеально.

Heading-aware chunking використовує структуру H2 і H3 сторінки як лінії розрізу, тому уривок приходить разом із заголовком, який його називає. Це найбільше поліпшення, яке доступне більшості сторінок, і має наслідок, який часто пропускають: текст вашого заголовка тепер виконує роботу пошуку. Розділ "Overview" нічого не додає до уривка під ним. Розділ "How much does it cost?" додає саме питання.

Semantic chunking порівнює сусідні блоки і розрізає там, де змінюється значення, незалежно від наявності заголовка. Це створює уривки, які можуть існувати самостійно, і вимагає проходу embedding (вбудовування) над сторінкою перед будь‑яким пошуком.

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

Чого він не може сказати

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

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

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

Він не може сказати, чи вас процитували у відповіді сьогодні. Це вимірювання протягом часу, за вашими підказками, і це інший інструмент.

Він може показати точно ті уривки, які retriever отримує з одного URL — це частина ланцюжка, яку всі вгадують.

Якщо ви будуєте пошук, а не контент

Ту саму сторінку можна використати як референс‑реалізацію, вказавши будь‑яку URL:

• Запустіть сторінку, яку вже індексуєте, і порівняйте межі фрагментів зі своїм chunker‑ом.
• Порівняйте коефіцієнти вилучення на тій самій URL. Якщо ваші нижчі, ваш екстрактор відкидає основний текст, а не шаблон.
• Задайте сторінці питання, відповідь на яке вам відома, і перевірте, чи верхній фрагмент містить її.
• Запустіть сторінку, яка надто довга. Фрагменти за межами ліміту — це ті, до яких ваш власний top‑k ніколи не дійде.

Джерела та де читати далі

• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — стаття, назву якої взято для патерну.
• Cosine similarity — міра, що стоїть за кожним твердженням про те, що два фрагменти стосуються одного й того ж.
• Google Search Central про AI features and your site та SEO Starter Guide, одну з шести сторінок, зазначених вище.
• Вступ Google до структурованих даних (introduction to structured data) і schema.org для машиночитабельної частини.
• llms.txt — конвенція, яку ми дотримуємося у /llms.txt, що описує цей інструмент у єдиному форматі, який модель не повинна парсити.
• OpenAI's embeddings guide, якщо вам нове поняття word embedding.

Наша власна methodology page містить усі формули, які використовує продукт, і те, що кожне число може заявити.