Продвижение в нейросетях (GEO, AEO, AI SEO) в Беларуси сейчас переживает ту же детскую болезнь, через которую пятнадцать лет назад проходило классическое SEO: рынок наводнили наспех собранные парсеры и курсы по базовому промптингу, авторы которых путают работу RAG-ретривера с подбором ключевых слов.

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

Начинаешь проверять этот список доноров руками — и видишь чистую комедию:

1. На первых строчках в списке площадок для «гостевого посева» стоят сайты прямых конкурентов — других минских веб-студий и маркетинговых агентств. Представьте лицо владельца бизнеса, которому на полном серьёзе советуют пойти к прямому конкуренту и попросить разместить у него в блоге хвалебный обзор чужих услуг.

2. Следом в списке обязательных площадок идёт поддомен географического факультета БГУ и государственные образовательные порталы. Наивный парсер без классификации сущностей увидел в запросе аббревиатуру GEO, связал её с географией и геодезией и отправил B2B-компанию закупать пиар у деканата геофака.

Ровно та же лексическая коллизия происходит в самом Google AI Mode, когда в региональном индексе .by не хватает размеченных сущностей. Задаёшь поисковику вопрос про специалистов по продвижению в нейросетях в Беларуси, а его ретривер дробит фразу на простые слова «эксперт», «нейросети», «маркетинг» и собирает ответ из блоков «Преподаватели курса» на лендингах онлайн-школ. В итоге в список рекомендаций попадают лекторы, которые учат маркетологов писать промпты для картинок и собирать чат-ботов, но ни разу в жизни не настраивали граф Schema.org под генеративную выдачу.

Чтобы поисковые модели (Google AI Overviews, Google AI Mode, ChatGPT Search, Perplexity и Яндекс.Нейро) не путали продвижение в ответах ИИ с географическим факультетом и курсами по промптингу, на инженерном уровне приходится решать три конкретные задачи:

Во-первых, жёстко разводить сущности в микроразметке (Organization, Person, Service) и связывать их через двусторонний sameAs с независимыми реестрами. Например, для закрепления связки автора и агентства с темой GEO и AI SEO я выпустил 18-страничный инженерный регламент отдельной книгой с международным номером ISBN 978-5-0071-2992-3. Для краулера карточка в библиографической базе и крупных книжных каталогах — это верифицированный узел графа знаний, который не спутаешь с лендингом вебинара.

Во-вторых, в тексте посадочных страниц и профилей автора нужно явно связывать русскую формулировку «продвижение в нейросетях» с каноническими терминами GEO (Generative Engine Optimization), AEO (Answer Engine Optimization) и AI SEO. Тогда при веерном поиске (Query Fan-out) чанк проходит и по русскоязычному коммерческому запросу заказчика, и по техническим подзапросам самой модели.

В-третьих, при аудите видимости нельзя опираться на одиночный прогон промпта в веб-чате. Из-за ненулевой температуры генерации выдача плавает от запроса к запросу, а сырые сноски без фильтрации по типу площадки (Entity Type Classification) превращают отчёт в мусор. Поэтому в открытом стандарте FastUp GAS мы сразу заложили серию повторных прогонов, раздельный расчёт заметности в выдаче (NVI) и точности фактов о бренде (CBK), плюс жёсткий штраф -1 балл за галлюцинации и смешение сущностей.

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

Мы внутри агентства гоняем собственного агента поверх боевой CRM. У него около 40 кастомных инструментов: чтение таблиц, выборка лидов, проверка оплат, парсинг логов активности. Когда выбирали постоянную модель под рутинные запросы команды, я устроил прямое A/B-сравнение трёх вариантов на базе DeepSeek: v4-pro, v4-flash:hight и reasoning-версии.

На простых запросах разницы не было никакой. Задачу вроде «посчитай количество входящих лидов и сумму оплат за прошлую неделю» все три модели решили как под копирку: вызвали нужный тулз, забрали данные, отдали абсолютно одинаковые цифры. На таких операциях flash-модель кажется идеальной: отвечает мгновенно, стоит копейки.

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

Старшие модели (pro и reasoner) честно пошли по цепочке: запросили список проектов, циклом собрали задачи, сверили логи и сошлись на одном результате. А вот flash-модель в базу вообще не пошла. Она просто взяла контекст из обсуждения в чате получасовой давности и выдала ответ в духе «я уже отвечал на этот вопрос выше, вот сводка».

Внешне ответ выглядел убедительно: ровный текст, знакомые фамилии, аккуратные списки. Если не смотреть лог вызова функций (tool calls trace), никогда не поймёшь, что модель схалтурила. Но за полчаса в базе сменились статусы двух сделок и добавился десяток комментариев. В итоге агент выдал устаревшие данные с железобетонной уверенностью.

При этом у старших моделей вылезла своя проблема. Reasoning-модель на первой попытке банально улетела в таймаут API: пока она размышляла над логикой выборки и последовательно дёргала методы, соединение разорвалось. Пришлось поднимать таймаут ожидания до двух минут. Дорогая модель умнее, но требует совсем других сетевых настроек.

Для себя я вынес простое правило: дешёвые flash-модели отлично справляются с одиночными операциями, где есть ровно один понятный вызов функции. Но если в промпте заложена цепочка из нескольких шагов с зависимостями, доверять им нельзя. Либо сразу пускать задачу через старшую модель с увеличенным таймаутом, либо на уровне бэкенда проверять трейс и отбрасывать ответ, если модель не сделала обязательные вызовы API.

Я вот тут думал, что просто обалденно: когда-то ведь говорили, что нейронка не заменит девопсов. Да, возможно, для каких-то крупных enterprise-решений, где банковская система, возможно, и не заменит (пока что). Но, будем честны, сколько из нас работает с обычным хостингом и сколько в банке? Сколько девопсов реально работает в крупных корпорациях?

Сейчас началась просто гонка искусственного интеллекта. Каждый хочет сделать модель лучше, мощнее, быстрее, скажем так, меряются бенчмарками. Хотя по факту для большинства задач с лихвой хватает текущих моделей. Для 80% людей за глаза хватит и обычного DeepSeek: спросить, как варить пельмени, или просто поныть. Зайдите на YouTube. Сколько человек там реально занимаются исследованиями? Большинство видосов — это приколы всякие с нейросетями. Ну серьёзно, блин. Для планирования с лихвой хватило бы Opus 5, а для обычного кода — Sonnet 5 просто с головой. И я бы пользовался моделью предыдущего поколения типа Opus 4.8, если бы она стоила в 2 раз дешевле.

Тут вышла модель Gemini 3.8 Flash, и я решил её проверить. Если бы не вышла 3.8, я бы запустил Sonnet 5, потому что она постабильнее и даже ее хватило бы. А Gemini 3.7 хоть и быстрая, но сильно галлюцинирует и делает часто то, что не нужно, слишком независимая.

Сегодня днём я как раз переносил на новый хостинг 10 сайтов, с одной ISP-панели на другую. Шесть сайтов перевелись нормально, это обычные вордпрессовские сайты. А вот четыре уже сразу легли. На одном был Laravel, на другом админка со своей базой, ещё на одном кастомные таблицы, где база при импорте вообще не перенеслась. Техподдержка хостинга мне бы это по-любому не сделала: там принципиально разные проекты и нужен был доступ к старому хостингу. Сколько бы заняло времени это через техподдержку?

Я дал доступ — всего лишь логин и пароль к хостингу. Всего лишь. Сделал буквально два промпта. И за 70 минут в одной сессии Gemini просто поднял все сайты: пересобрал данные в Laravel, поменял адреса где нужно, докачал базы, которых не хватало. Причём для этого всего хватило модели Gemini Flash 3.8, не говоря уже о каком-нибудь Opus 5 или более мощных моделях.

Единственное, кого пока не заменит нейросеть, — это 1С-ников. И то не потому, что там суперсложные проекты, огромный легаси-код или суперсложная бизнес-логика. Уже сейчас нейросеть кушает за раз огромные проекты. Единственное, что пока спасает 1С-ников, — это то, что нельзя подключить Claude Code напрямую к написанию кода 1С. И то, в принципе, реально же задавать промпт и руками копировать-вставить. Но как только придумают, как интегрировать искусственный интеллект в 1С, — 1С-ники тоже заметят последсвия ИИ.