10.4LLM в аналитике и диагностике: модель предлагает, код считает, человек решает

Специалист выгружает из панели вебмастера запросы за квартал — сорок тысяч строк, — кладёт файл в окно модели и спрашивает: «Почему упал трафик?» Через минуту приходит ответ на полторы страницы: три причины, таблица, план действий. Звучит как работа опытного аналитика. Половина процентов в нём посчитана неверно, одна строка таблицы выдумана, а главная причина названа по данным, которых в файле не было.

И всё же именно здесь модель полезнее, чем где-либо ещё в SEO. Аналитика в SEO — это разбор больших таблиц: тысячи запросов, сотни страниц, недели, две поисковые системы, два типа устройств. Человек тратит на сводные таблицы часы и устаёт на третьем срезе. Модель за минуты раскладывает запросы по смыслу, находит, где сосредоточена потеря, и предлагает первую гипотезу. Разница между первым сценарием и вторым — не в модели, а в том, что ей дали и как проверили ответ.

Рабочее правило: модель предлагает, код считает, человек проверяет и решает. Что мерить и где данные врут сами по себе — глава об аналитике и метриках; как устроен запрос к модели — глава о промптинге; где модель в работе специалиста помогает, а где вредит вообще, — глава о LLM в рабочих процессах.

Подготовка данных: почему сырая выгрузка даёт мусорный анализ

Раздел о текущем состоянии панелей вебмастеров и языковых моделей, проверено на 25.10.2026; пересматривается раз в квартал.

Модель не говорит «эти данные непригодны». Ей дали таблицу — она её объясняет, и объясняет тем увереннее, чем меньше в таблице смысла. Сырая выгрузка из панели почти всегда собрана не для того вопроса, который вы задаёте: в ней смешаны системы, нет части запросов, строки слишком мелкие, а того, что случилось на сайте и в бизнесе, нет вовсе. Человек со стажем видит это за минуту по привычке. Модель не видит, если ей не сказать.

Первое ограничение — техническое, и оно разобрано в главе о промптинге: контекстное окно не бесконечно, середину длинного ввода модель замечает хуже, считать и фильтровать нужно до модели. Для выгрузок панелей из этого следует одно добавление. Сорок тысяч строк, вставленных в чат, модель прочтёт не целиком — и не скажет об этом: вывод будет сделан «по всему файлу». Режимов, в которых большой таблице можно доверять, два: подготовленная таблица на сотни строк или файл, над которым модель пишет и выполняет код, а не «читает» его. Второй сегодня есть у большинства массовых ассистентов, и для цифр это единственный режим, которому можно верить (подробно — в последнем разделе).

Подготовка — шесть операций, и каждая закрывает конкретный способ получить мусор.

1. Системы — раздельно. Яндекс и Google считают показы и позицию по-разному: Вебмастер учитывает показы только до 50-й позиции и показывает позицию как среднюю за день, Search Console — позицию самого верхнего результата сайта, усреднённую по показам. Сложенные в одну таблицу, эти числа ничего не значат, а сравнивать панели между собой бессмысленно (глава 11). Две системы — две таблицы и два вывода.
2. Контрольная сумма. Интерфейс панели показывает только верхнюю часть таблицы, у выгрузок есть дневные лимиты и предельная глубина истории, а редкие запросы Search Console скрыты в таблице, но входят в итог (глава 11; конкретные лимиты — в техническом справочнике, П1). Сумма строк меньше итога, и доля скрытого меняется от месяца к месяцу. Модель, которая сложила строки, «найдёт» падение, которое на деле — сдвиг доли скрытых запросов или другой предел выгрузки. Поэтому в таблицу кладут итог из отчёта и отдельную строку «скрытые запросы» как разницу итога и суммы строк, а сравниваемые периоды выгружают из одного отчёта одним способом.
3. Бренд — отдельной меткой. Зачем отделять брендовые запросы и почему небрендовые клики Search Console честнее считать как итог минус брендовые — в главе 11. Здесь модель полезна: по названию компании она за минуту составит список написаний, транслитов и опечаток, которые человек не придумает. Список утверждает человек, метку ставит код по утверждённому списку, а не модель «на глаз».
4. Агрегация. Строка «день × запрос × страница» слишком мелкая: в ней шум, нули и единицы. Для анализа — недели и группы страниц по разделам и шаблонам. Клики и показы складывают; кликабельность пересчитывают из сумм, а не усредняют; позицию усредняют с весом по показам. Среднее из средних — самая частая арифметическая ошибка и людей, и моделей.
5. Период — год к году. Те же недели прошлого года, выровненные по дням недели, с пометкой праздников и переносов. Месяц к месяцу сравнивают только для поиска аварий (глава 11). Без прошлого года модель объяснит сезон как угодно, кроме сезона. Если сайт младше года, сравнивать год к году не с чем: сезон проверяют по динамике спроса в Вордстате, и уверенность любого вывода на ступень ниже.
6. Контекст, которого нет в таблице. Журнал изменений сайта с датами — релизы, шаблоны, цены, телефоны, хостинг; события бизнеса — закрыли услугу, ушла бригада, кончилась реклама; динамика спроса по главным группам запросов. Чего нет на входе, модель додумает, и додуманное будет правдоподобным.

Кто за что отвечает. Подготовка — работа SEO-специалиста, и она занимает больше времени, чем сам анализ: это нормально, а не признак, что модель бесполезна. Журнал релизов ведёт разработка, события бизнеса и доступы к данным даёт владелец. Если журнала нет, первая находка любого разбора — что его надо завести. Что из данных клиента вообще можно отдавать внешней модели — глава об агентах, автоматизации и рисках. Шаблон подготовленной таблицы и порядок проверки — в библиотеке промптов (П3).

Разбор данных панели вебмастера: запросы, позиции, кликабельность

Раздел о текущем состоянии панелей вебмастеров и языковых моделей, проверено на 25.10.2026; пересматривается раз в квартал.

Владелец спрашивает: «По каким запросам мы недобираем?» Ответ лежит в панели — показы, клики, кликабельность и позиция по каждому запросу и странице, — но в виде, из которого его надо достать. Кликабельность (глава о разметке) читают только вместе с позицией и показами: высокая позиция с низкой кликабельностью значит одно, много показов на дальней позиции — другое, рост кликабельности при падении показов — третье.

Если у сайта сотня запросов, модель не нужна: таблицу на сотню строк человек прочтёт за полчаса и поймёт лучше. Модель окупается с тысяч строк, нескольких разделов и регулярного повторения одного и того же разбора.

Где модель сильнее человека

В разметке запросов по смыслу. Тысячу строк вида «ремонт ноутбука асус не включается после воды» модель за минуты раскладывает по осям: услуга, марка и модель устройства, симптом, район, срочность, интент по сетке главы 2, бренд. Человек на ту же работу тратит день и к вечеру начинает ошибаться. Модель ошибается иначе — систематически; где именно и почему, разобрано в главе о семантике и контенте с LLM. Поэтому разметку проверяют на контрольном наборе из главы о промптинге — 50–100 объектов с заметной долей трудных случаев, размеченных вручную, — и если расхождений больше, чем вы готовы терпеть, уточняют правила и размечают заново. Что дать модели, чтобы разметка совпала со структурой сайта, — в библиотеке промптов (П3).

После разметки работает код: суммы и средние по группам считает программа, а не текст ответа. Модель может этот код написать.

Четыре разбора, которые стоит делать

Своя кривая кликабельности по позициям. По своим данным, за квартал, отдельно по системам, устройствам и с отделённым брендом — брендовые запросы кликают в разы чаще и задирают кривую. Чужие усреднённые кривые не годятся: выдача с картами, рекламой и ответом нейросети над первым местом живёт по своим законам, и в каждой нише она своя. Запросы, у которых кликабельность заметно ниже вашей же кривой на той же позиции, — кандидаты на разбор: слабый сниппет или блок над результатом, который забирает клики. Модель предложит, что поправить в заголовке и описании, но выдачу она не видит: что стоит над вашим результатом, смотрят глазами. Кривую перестраивают раз в квартал: когда в выдаче появляется новый блок, она проседает целиком, и это само по себе находка.

Рядом с первой пятёркой. Запросы с большим числом показов на позициях примерно с шестой по пятнадцатую — классический список возможностей. Единица работы здесь — страница, а не запрос: модель группирует такие запросы по посадочным страницам, и выясняется, что сорок запросов «рядом с пятёркой» приходятся на шесть страниц. Это уже задача, которую можно поставить.

Показы без кликов по смыслу. Страница показывается по запросам, на которые она не отвечает: коммерческий запрос ведёт на статью, общий — на узкую страницу модели устройства. Это расхождение запроса с посадочной — следующий раздел.

Хвост. Для диагностики хвост ниже порога показов отсекают до модели. Для семантики — наоборот: это редкие запросы, которые человек не читает, а модель читает охотно: новые формулировки, марки, симптомы, «с выездом», «за час». Хвост панели — ваш собственный спрос, а не чужая частотность, и для сбора семантики он стоит рядом с выдачей конкурентов и своими заявками. Как из этого строить структуру — глава о семантике и контенте с LLM.

Где Яндекс и Google расходятся настолько, что меняют вывод

Как каждая панель считает позицию и показы, сказано в разделе о подготовке данных; Вебмастер, кроме средней позиции показа, отдельно даёт среднюю позицию клика — место в момент перехода. Почему средняя позиция Search Console «ухудшается» от прироста редких запросов, разобрано в главе 11. Вывод для разбора: среднюю позицию по сайту во времени сравнивают только по фиксированному списку запросов, в Google это обязательно, в Яндексе — желательно. Разница в глубине истории тоже есть, но для год к году хватает обеих панелей; для двух лет назад — ни одной, и выгрузки копят сами (глава о тестировании).

Граница разбора

Панель знает, что произошло в выдаче, и не знает, позвонил ли человек. Запрос с высокой кликабельностью и нулём заявок — не успех: трафик ≠ результат, и строка «заявки по группе запросов» приходит из CRM, а не из панели. Отвечает за разбор SEO-специалист, за данные CRM — бизнес. Состав выдачи, действия конкурентов и обновления алгоритмов — зона неопределённости: разбор показывает, что она изменилась, но не даёт ею управлять.

Поиск каннибализации и расхождений запроса с посадочной страницей

По запросу «замена матрицы ноутбука» за квартал показывались три адреса сайта: страница услуги, страница одной модели ноутбука и статья «Сколько стоит заменить экран». Позиция прыгала от пятой до двадцать второй. Это каннибализация запросов — понятие из главы о дубликатах: несколько страниц претендуют на один запрос и мешают друг другу. Там же — таблица «тип дубликата → способ лечения». На сотнях страниц такие случаи руками не найти — их находят по данным.

Что считает код

Из таблицы «запрос × страница × неделя» программа выбирает запросы, по которым за период показывалось больше одного адреса, и для каждого считает три вещи: долю показов главного адреса, число смен главного адреса от недели к неделе и разброс позиции. Рабочий порог из практики: если главный адрес собирает меньше примерно четырёх пятых показов дольше месяца и адреса сменяют друг друга, запрос — кандидат. Это оценка практики, а не правило поисковых систем; на сайте с малым числом показов порог шире.

Что делает модель

Сортирует кандидатов по типам, потому что две страницы в данных — не всегда беда.

• Настоящая каннибализация. Две страницы под один интент, сменяют друг друга, ни одна не держит позицию.
• Норма. Брендовые запросы, по которым показываются главная и контакты; две страницы в выдаче одновременно, обе в первой десятке и без смен, — это двойное присутствие, а не вред; разные интенты, которые выдача показывает вместе.
• Расхождение с посадочной. Адрес один, но не тот: коммерческий запрос получает статья, общий — страница узкой модели, запрос без района — районная страница. Здесь нужна карта «группа запросов → целевая страница»: расхождение — это когда фактическая посадочная не совпадает с целевой. Если карты нет, модель составит её черновик по структуре сайта (глава 5), а утвердит человек.

Тексты страниц модели для этого не нужны. Достаточно адреса, типа страницы, заголовка, первого экрана в двух-трёх фразах и целевой группы запросов: так в окно помещаются сотни страниц, и модель сравнивает обещание страницы с запросом, а не пересказывает тексты. У данных здесь есть слепое пятно: панель показывает только страницы, которые получали показы. Если целевая страница ни разу не появилась по своему запросу, в таблице её нет, и каннибализацией это не выглядит — это страница, застрявшая на одном из четырёх этапов из главы 1, и искать обрыв надо там.

У модели здесь одна систематическая ошибка, и она важнее остальных: интент она определяет по словам запроса, а поисковая система — по выдаче. «Замена проводки» и «цена замены проводки» для модели — два интента, а выдача у них одна и та же; пример разобран в главе о дубликатах. Поэтому список модели — список кандидатов, а не решений. Двадцать самых ценных кандидатов человек проверяет по выдаче, и только после этого применяется правило «один интент — одна страница» с его исключением для неразделимых в выдаче интентов (глава 4 и глава о семантике и контенте с LLM).

Чего делать нельзя: склеивать и перенаправлять страницы пачкой по списку модели. Объединение страниц с разной выдачей теряет интент, под который не осталось страницы, а перенаправление без переноса содержимого теряет запросы вместе со страницей (глава 4). Решение о склейке принимает SEO-специалист после проверки выдачи, содержимое переносит тот, кто отвечает за тексты, перенаправления ставит разработка.

Для интернет-магазина картина другая: категория, страница фильтра и карточка товара по одному запросу — состояние по умолчанию, а не авария, и доля «многоадресных» запросов там в разы выше. Порог и порядок разбора у магазина свои — это тема модуля Б о магазинах, который выйдет отдельно; до него — глава о других типах проектов. Принцип «кандидат по данным, решение по выдаче» не меняется.

Диагностика аномалий и падений: первичная гипотеза за минуты вместо часов

Понедельник, трафик из поиска за неделю на треть ниже. Раньше первые часы уходили на сводные таблицы — срезы, прошлый год, журнал релизов. Это механическая работа, и именно её модель делает за минуты. Порядок самой диагностики от этого не меняется: он задан деревом причин в главе о санкциях и потере трафика — от ненастоящего падения или взлома и сезонности к изменениям на сайте, аварии, смене выдачи, конкуренту, обновлению, атаке и санкции. Модель ускоряет каждый шаг, но не переставляет их.

Что модель делает быстро

Раскладывает потерю. Код считает, какая доля падения приходится на каждую систему, устройство, раздел, тип страниц, группу запросов, бренд и небренд. Обычно потеря сосредоточена: девять десятых в одном разделе или в одной системе, и половина ветвей дерева отпадает сразу.

Применяет таблицу главы 16 «что видно → что это значит» к десяткам групп сразу и совмещает даты — начало падения с журналом изменений, публичными датами обновлений Google и спросом. Совпадение даты — не причина, но первый кандидат.

Ранжирует гипотезы. Хороший ответ модели — не «причина», а список: гипотеза, какие данные её подтверждают, какая проверка её опровергнет и сколько эта проверка стоит. Без последней части список бесполезен.

Где модель ошибается

Она находит историю в любых данных, включая шум. Первый вопрос к ней поэтому не «почему упало», а «вышло ли падение за обычный коридор» — граница шума из главы 16. Она не видит выдачу, конкурентов, телефон, который не берут, и цену, которую подняли без записи в журнал. И у неё есть своё удобное объяснение — обновление алгоритма: оно правдоподобно для любых данных, звучит профессионально и не требует проверки. Для модели это то же, что санкция для владельца сайта.

Отсюда правила. Гипотеза модели — гипотеза, третий из четырёх уровней уверенности главы о том, как читать утечки и заявления, и в отчёте так и называется. Быстрые проверки — код страницы, выдача глазами, статусы в панелях — человек делает в тот же день. Дорогие действия проверяют по правилам главы о тестировании. Правило главы 16 действует целиком: при падении не снимать ссылки и не переписывать тексты, пока не проверена сезонность, — если только сообщение о нарушении прямо не называет причину. И свои ошибки проверяют раньше, чем ищут атаку.

Пример: два падения — за десять минут и мимо

Сервисный центр по ремонту ноутбуков, три пункта приёма в Москве, сайт около 1 400 страниц, из них 380 — страницы ремонта конкретных моделей. В сентябре небрендовые клики из поиска за две недели упали с 2 600 до 1 760 в неделю, на 32 %. Подготовка таблицы и журнала релизов заняла у нас сорок минут. Модель в режиме выполнения кода разложила потерю за десять: 93 % падения пришлось на раздел моделей, где клики упали с 1 100 до 320 в неделю, в обеих системах одинаково; остальной сайт потерял 4 %, ровно как год назад в те же недели. Число страниц раздела с показами упало примерно с 370 до 90, у оставшихся показы и позиции прежние, спрос год к году ровный — значит, страницы уходили из индекса. Падение началось через шесть дней после релиза нового шаблона страницы модели. Гипотеза модели: шаблон закрыл страницы от индексации.

Проверка руками заняла пятнадцать минут: в шаблон вместе с релизом уехал запрет индексации с тестового сервера, и стоял он на всех 380 страницах. Разработка убрала его на следующий день, через четыре недели раздел вернулся к 1 000 кликов в неделю, 91 % прежнего. Весной похожий разбор на этом же проекте занял у нас полдня. Но сэкономлены не часы: минус треть в целом по сайту на второй неделе легко принять за шум или начало сезонного спада и подождать ещё одно обновление базы. Разложение по разделам показало, что это не шум, в первый же день — а каждая неделя ожидания стоила бы ещё части раздела, выпавшей из индекса.

Второе падение — на проекте, который мы взяли на аудит позже. Компания бурит скважины на воду в Подмосковье, четыре буровые установки, сезон с апреля по октябрь, средний чек около 210 тысяч рублей. В июле клики из Яндекса оказались на 31 % ниже тех же недель прошлого года, заявки из поиска — 33 против 46. Специалист клиента вставил в чат выгрузки за июнь и июль и спросил о причине. Модель ответила уверенно: средняя позиция ухудшилась с 5,6 до 9,3, сайт потерял позиции по всему ядру, это совпало с обновлением алгоритма в начале июля — модель назвала дату, — вероятная причина — слабые тексты страниц услуг. За две недели переписали четырнадцать страниц, копирайтер обошёлся в 56 тысяч рублей.

Расчёт кодом показал другое. Июньский файл выгрузили из одного отчёта — около 650 строк, июльский из другого — около 1 150: добавилось пятьсот редких запросов на дальних позициях с одним-двумя показами. Модель посчитала простое среднее по строкам. Средняя позиция с весом по показам по сорока главным запросам против тех же недель прошлого года — 4,1 против 4,3, показы по ним — минус 3 %. Упала кликабельность: с 8,2 до 5,1 %. В выдаче по главным запросам над результатами появились блок агрегатора услуг и расширенный блок карт — та же смена выдачи и та же ошибка «лечить тексты», что в кейсе с кондиционерами из главы 16, только с моделью в роли уверенного советчика. Названной даты обновления не нашлось ни в одном публичном источнике — модель её сочинила. Хуже всего обошлось переписывание: из трёх страниц копирайтер убрал таблицы цен по глубине бурения как «тонкие», и на следующем обновлении они просели с третьего-четвёртого места на седьмое. Вернули их откатом через месяц.

Решение, которое принял бизнес: тексты откатить, деньги перенести в карточку на картах и профиль на агрегаторе — туда, куда ушли клики; в отчётах позицию считать только с весом по показам и только кодом; гипотезу модели не превращать в работы на сайте, пока человек не прошёл первые шаги дерева. В августе заявок из поиска и карт вместе было 41 против 44 годом раньше.

Приоритизация задач по данным

После аудита у проекта сто сорок задач. Подрядчик предлагает делать по порядку, разработка — начать с того, что проще, владелец — с того, что видно ему. Список, отсортированный по чьему-то вкусу, съедает полгода и не двигает заявки. Приоритет считается: ожидаемый эффект в заявках или деньгах, умноженный на уверенность в нём и делённый на стоимость работы. Дешёвое и обратимое идёт раньше дорогого и необратимого при равном эффекте.

Эффект оценивают по данным, а не по ощущению. Для задач на страницах — так: показы группы запросов × разница между кликабельностью на целевой позиции по своей кривой и текущей × доля кликов, которые в этой группе становятся заявками (по CRM). Пример с того же сервиса ремонта ноутбуков. Страница «замена матрицы» — 9 400 показов в месяц на пятом месте, кликабельность 4 %; на третьем своя кривая даёт около 9 %. Это около 470 кликов в месяц, при конверсии группы 3 % — около 14 заявок. Статья о том, как выбрать ноутбук, — 40 тысяч показов и тот же сдвиг на две позиции, потенциал около 1 600 кликов, но интент «выбрать способ» даёт заявку с пятисот визитов, то есть три-четыре заявки. По трафику статья впереди втрое с лишним, по заявкам позади вчетверо. Трафик ≠ результат, и сортировка по потенциальному трафику — самая частая ошибка приоритизации, в том числе у моделей, если им не дать колонку конверсии.

Роль модели здесь — сборка, а не решение. Она сводит находки всех разборов в один список, склеивает задачи по страницам, грубо оценивает трудоёмкость, пишет обоснование каждой строки и проставляет уровень уверенности. Формулу считает код. Чего модель не знает и что приносит бизнес: сколько стоит час разработки, какую услугу владелец собирается закрыть, загружены ли мастера — продвигать услугу, на которую нет людей, бессмысленно при любом потенциале. Строки «высокий / средний / низкий» без чисел в такой список не попадают: это не приоритет, а мнение.

Самое слабое звено расчёта — целевая позиция. Модель охотно ставит каждой странице третье место, и список превращается в обещание. Честнее брать сдвиг на две-три позиции от текущей и тот же сдвиг применять ко всем задачам: ошибка тогда одинакова для всех строк и не меняет порядок. Уверенность проставляется по уровням главы 27: разрыв кликабельности измерен — факт; что правка сниппета его закроет — гипотеза, и у такой задачи вес ниже, чем у исправления, которое возвращает страницу в индекс. Список пересчитывают раз в квартал, а не при каждом новом отчёте: приоритет, который меняется каждую неделю, — это не план, а реакция на шум.

Два фильтра стоят перед формулой. Обновлять десять лучших страниц раньше, чем писать новую: у страницы с показами эффект считается, у ненаписанной — угадывается. И техническая ошибка ≠ проблема: краулер выдаст двести ошибок, модель охотно превратит их в двести задач, но в список попадает ошибка, которая касается страниц со спросом или ломает один из четырёх этапов из главы 1; остальные ждут квартальной проверки. Задачи на стороне владельца — цены, фотографии работ, ответ на заявки — стоят в том же списке, с его именем и ценой задержки.

Автоматическая отчётность и её пределы

Соблазн понятен: данные собираются сами, графики строятся сами, модель пишет комментарий, и отчёт уходит клиенту первого числа без участия человека. Автоматизируется действительно многое. Дашборд — сводный отчёт на одном экране с ключевыми метриками в виде графиков и таблиц, который обновляется из источников данных автоматически, — например, расходы, заявки, CPA и выручка по каналам. Сбор выгрузок, год к году, контрольные суммы, сигнал, когда метрика вышла за коридор, черновик комментария — всё это машина делает лучше и дешевле человека. Как часто нужен автоматический технический контроль на малом и на большом сайте — в главе об агентах, автоматизации и рисках.

Пределы начинаются там, где начинается отчёт. Каким он должен быть — раз в месяц и от заявки до денег, с позициями и трафиком в приложении, — разобрано в главе 31. Модель, которой дали панели и счётчик, напишет отчёт о позициях и трафике — красиво и с выводами, — потому что заявок и денег у неё нет. Строка результата приходит из CRM заказчика, и если доступа нет, в отчёте так и пишут: результат не измеряется.

Второй предел — в комментарии. Модель объясняет каждое колебание, и каждое объяснение звучит одинаково уверенно. Честный отчёт ставит уровень уверенности при каждом объяснении и говорит «не знаем, проверяем вот это» там, где не знают. Числа в тексте комментария берутся только из посчитанной таблицы — подстановкой, а не пересказом. Комментарий — черновик: его вычитывает и подписывает человек, и отвечает перед клиентом тот, кто подписал, а не модель. Плохую новость клиенту сообщает человек, словами главы 31, а не абзацем в автоматической рассылке.

Где модель уверенно врёт: типовые галлюцинации на числовых данных

Раздел о текущем состоянии языковых моделей, проверено на 25.10.2026; пересматривается раз в квартал.

Галлюцинация — понятие из главы о текстовых факторах, свойство генерации, а не случайный сбой. На числах она опаснее, чем в тексте: выдуманный факт о компании заметит владелец, выдуманный процент в таблице не заметит никто. Типовых ошибок шесть.

• Арифметика. Суммы, разности, проценты изменений, посчитанные «в уме», текстом ответа.
• Агрегирование. Среднее из средних: кликабельность, усреднённая по строкам, позиция без веса по показам — второе падение из примера выше.
• Выдуманные строки. Запрос, которого нет в таблице, страница с правдоподобным адресом, дата обновления, которой не было.
• Перепутанные столбцы. Показы прочитаны как клики, позиция — как кликабельность; запятая — то разделитель тысяч, то десятичная дробь; даты день-месяц и месяц-день.
• Молча потерянные строки. Модель прочла часть файла, а вывод сделала по всему.
• Сглаживание под историю. То, что не вписывается в выбранное объяснение, пропадает из ответа.

Это не только наблюдение практики. В работе Wolff и Hulsebos (arXiv, май 2025, версия от ноября 2025) точность моделей на агрегатах — средних, разностях, корреляциях — была заметно ниже, чем на поиске одного значения, и падала с ростом таблицы; дубликаты роняли её заметно, пропуски — по-разному, и дубликаты модели отмечали редко. В работе Yang и соавторов (arXiv, 30 июня 2026) ссылки на значения и строки, которых в таблице нет, и пропуск нужных строк нашлись у всех проверенных моделей, причём часть таких ошибок сидела в ответах с верным итогом. Проверялись конкретные модели на конкретных наборах, и проценты на ваш проект не переносятся. Переносится направление: чем больше таблица и чем больше в ней агрегатов, тем меньше стоит верить цифре из текста ответа.

Контроль поэтому — не «проверить ответ», а изменить режим. Числа считает код: модель пишет и выполняет программу над файлом, или код запускает специалист. Каждая цифра в выводе ведёт к ячейке, из которой взята. Итог таблицы сверяется с итогом панели. Три-пять ключевых цифр пересчитываются независимо. Если модель приводит строку, её ищут в файле. С правильностью уверенность и аккуратность оформления не связаны: самый красивый ответ во втором примере был неверным.

Мифы

• «Дайте модели доступ к панелям — она сама найдёт причину падения». Она быстро найдёт, где сосредоточена потеря. Почему — гипотеза: модель не видит выдачу, конкурентов, телефон и цены. Граница влияния модели та же, что у данных: она объясняет то, что в них есть, и сочиняет то, чего нет.
• «Чем больше данных загрузить, тем точнее анализ». Сорок тысяч сырых строк хуже пятисот подготовленных: окно не вмещает или теряет середину, смешанные системы и скрытые запросы дают ложные падения. Точность приходит из подготовки, а не из объёма.
• «Модель показала расчёт по шагам — значит, цифры верны». Шаги, написанные текстом, — тоже текст. Верен только расчёт, который выполнила программа, и только если входная таблица верна.
• «Две страницы по одному запросу — каннибализация». Иногда это двойное присутствие в выдаче, брендовый запрос или два интента, которые выдача показывает вместе. Каннибализацию подтверждает выдача, а не число адресов в выгрузке.
• «Модель заменит аналитика». Она заменяет часы сводных таблиц. Подготовку данных, проверку гипотезы, решение и подпись под отчётом она не заменяет — и чем быстрее модель отвечает, тем дороже обходится человек, который перестал проверять.
• «Отчёт, написанный моделью, объективнее, чем написанный подрядчиком». Он ровно так же зависит от того, какие данные в него положили. Дайте модели позиции и трафик без заявок — получите объективный отчёт о позициях и трафике.

Что запомнить

Модель предлагает, код считает, человек проверяет и решает. По каждой задаче — кто что делает:

Если в цепочке нет кода, цифре из ответа модели верят как гипотезе. Если нет человека, гипотезе верят как факту — и платят за это переписанными текстами, снятыми ссылками и потерянными неделями. Выдача, конкуренты и алгоритмы остаются неопределённостью при любом инструменте: модель быстрее показывает, что они изменились, но не делает их управляемыми.

Опора этой главы в ядре книги — глава об аналитике и метриках (что мерить и где данные врут) и глава о санкциях и потере трафика (порядок диагностики падения).