Почему ChatGPT не заменит ASO

Оглавление

1. Лимит символов
2. «ИИ разбирается в ASO»
3. Семантическое ядро
4. «Мы обучили агента»
5. Анализ итерации
6. «Семантическая плотность»
7. «Мы автоматизировали ASO»

Как насчет сыграть в лотерею?

Давайте прямо сейчас: «GPT, сделай мне метаданные для этого приложения…»

А на основании чего ты это сделал?

Ты собрал ядро? Выделил интенты? Классифицировал их так, как Apple описывала в патенте US 2013/0325892 A1? Проанализировал конкурентов? Учел ключи, по которым приложение уже ранжируется?

Ты понимаешь, какие слова ставишь под точное совпадение, а какие – под смысловое?

Вот исследование команды App Store про текстовую и поведенческую релевантность. А вот вакансия Apple, где они пишут гибридный лексико-семантический отбор кандидатов.

Что сделал ты?

Такой умный. Но такой тупой.

Увы, сейчас каждый второй доверяет генерацию ASO искусственному интеллекту. 10 секунд – и мета готова. Бонусом – уверенное объяснение, почему это должно сработать.

ИИ не остановит задачу словами «У меня нет данных». Не потому, что данные у него есть. А потому, что он заточен под возврат ответа.

Допустим, отправили ему в ответ ядро и получили новый противоположный оптимальный вариант с новым оправданием эффективности меты. Никаких расчетов, только решение и его оправдание. А вы воспримите это как «он умнее и знает лучше».

Но что именно он знает?

Откуда взялся этот ответ? Давайте разберем механику этой генерации. И почему GPT, Claude и им подобные никогда не заменят ASO.

1. Лимит символов

Специалист пишет:

Сделай подзаголовок до 30 символов. Используй самые важные ключи.

Чат присылает подзаголовок. Иногда он укладывается в лимит. Иногда нет.

После замечания модель пересчитывает, меняет одно слово и снова уверенно сообщает: «Теперь ровно столько-то».

Проблема не в том, что модель не знает арифметику, а в устройстве самой генерации.

GPT, Claude и другие текстовые модели формируют ответ частями своего словаря – токенами. Один токен может быть словом, частью слова, знаком или несколькими символами. Число токенов не переводится в точное число символов.

Но символы – полбеды. За лимит в 30 символов мы не вышли – уже хорошо.

Вес – суммарная ценность запросов, которые покрывает фраза. Допустим, у нас есть три варианта:

• проход мебели – вес 100
• калькулятор замера – вес 80
• шкаф – вес 30

Под лимит подходят варианты проход шкафа и другой мебели и калькулятор замера шкафа. Первый покрывает запросы с суммарным весом 130, второй – 110. Если запрос уже покрыт в заголовке, его повтор в подзаголовке может не дать нового покрытия.

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

Это не просто задача на написание текста.

Есть рюкзак фиксированной вместимости W и набор из n предметов, каждый со своим весом wi и ценностью vi. Нужно выбрать такой набор предметов, чтобы их суммарный вес не превышал W, а суммарная ценность была максимальной.

Это похоже на классическую задачу комбинаторной оптимизации. Представьте рюкзак вместимостью 30 единиц. Каждый предмет занимает место и имеет свою ценность. Все предметы не поместятся, поэтому надо выбрать самый выгодный набор. В метаданных вместо предметов – слова и фразы, вместо занимаемого места – символы, вместо ценности – покрытие запросов.

При небольшом числе вариантов программа проверяет все допустимые комбинации. При большом использует решатель ограничений, например CP-SAT. Ему передают лимиты, запрещенные сочетания, уже покрытые запросы и функцию, которую надо максимизировать. Он отбрасывает невозможные варианты и ищет лучший допустимый набор.

Чат сам по себе этого перебора не проводит. Он выдает один или несколько текстовых вариантов. Языковая модель здесь полезна как генератор формулировок. Все.

Такую механику — работу с весами, ограничениями и отбором допустимых комбинаций — мы разбираем в модуле «Автоматизация» курса ASO Engineering Academy, уже на основе данных вашего приложения.

Старт курса — 19 августа.

2. «ИИ разбирается в ASO»

Давайте узнаем, что он считает лучшими практиками ASO. Если веб-поиск отключен, модель отвечает из параметрической памяти – усредненных связей, полученных при обучении.

Давайте попробуем модель с интернетом.

Система находит статьи, чек-листы, пересказы пересказов и кейсы сервисов, которые продают собственное решение.

Гугл, заголовок – 50 символов. На этом идею оптимизации через чат можно закрывать.

Модели смешивают новые данные и старые, советы для США переносятся на Японию. Количество повторений одного асо-совета перевешивает одну качественную инженерную статью. В итоге ИИ красиво компилирует ASO-мифы.

Модель, конечно же, знает про отбор кандидатов, ранжирование, буквальное и смысловое соответствие. Но авторы ASO-статей обычно не строят поисковый индекс и не знают о настоящей механике поиска. Они наблюдают внешнюю реакцию закрытой системы и придумывают объяснение, почему что-то сработало. ИИ компилирует эти объяснения и выдает полнейший бред.

Разберем несколько заблуждений, которыми до сих пор оперируют эксперты.

1. Чем чаще слово встречается, тем приложение релевантнее

Это любят использовать в полном описании для повышения лексической плотности.

Есть приложение для почты. Слово email встречается в его названии и описании один раз.

Есть игра в бильярд. Слово email случайно встречается в ее описании три раза.

Согласно этой логике, поиск по числу вхождений поставит игру выше почтового приложения. Но ведь так не бывает.

Например в патенте Apple US9280595B2 используются связанные признаки: account, reply, message, filter, compose. Их связь с запросом определяется по корпусу документов приложений и по тому, какие приложения пользователи открывали или загружали после похожих запросов.

2. Точное вхождение ключа дает больший рост

Точное совпадение действительно может быть сильным сигналом. Но не для всех запросов и не на всех этапах поиска. В патенте Apple US9405832B2 запросы приложений разделяются на три типа:

• навигационный – человек ищет конкретное приложение;
• функциональный – человек ищет приложение, которое решает задачу;
• обзорный – человек… сам не знает что он хочет.

Для запроса Angry Birds точное совпадение с названием логично имеет большой вес: пользователь ищет конкретный продукт. Для запроса strategy game ключа в названии недостаточно. Разные намерения – разные стратегии поиска.

3. По низкочастотным ключам легче продвигаться

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

Низкая частота тоже не доказывает легкость. В отчете Apple 2026 года максимальный прирост после добавления текстовых оценок пришелся именно на редкие запросы. Причина не в том, что они «легкие», а в том, что по ним мало действий пользователей, поэтому поведенческий сигнал слабый или отсутствует. Системе сложнее понять качество результата по кликам и загрузкам, и ей нужен дополнительный текстовый сигнал.

То есть редкий запрос – это запрос с дефицитом наблюдений.

3. Семантическое ядро

Давайте соберем ядро, ибо без него смысла оптимизировать что-то нет.

Собери мне 200 релевантных ключевых слов для этого приложения. Добавь высокочастотные запросы и длинный хвост. Разбей по группам.

Через несколько секунд чат возвращает данные. Выглядят как семантическое ядро. Но это не ядро. Это список языковых ассоциаций вокруг описания приложения.

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

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

• какую модель векторных представлений использовали;
• как нормализовали запросы;
• сколько соседей строили для каждой точки;
• какой порог связи применили;

Иначе сегодня запрос попал в «планирование», завтра – в «продуктивность», а послезавтра модель создала новую группу. LLM здесь полезна, чтобы разобрать спорные намерения и дать понятные названия уже рассчитанным группам. Но основу ядра должен строить устойчивый конвейер данных.

4. «Мы обучили агента»

Повышаем градус!

Я загрузил двадцать книг, сто статей, прошлые отчеты. Теперь агент обучен моему ASO-подходу.

У любого инженера здесь один вопрос будет:

Какие числовые параметры модели изменились после загрузки файлов?

Если никакие – модель не обучали.

Модель состоит из миллиардов числовых коэффициентов. Настоящее обучение меняет эти веса.

Инструкции, контекст, RAG и внешняя память меняют вход модели. Дообучение меняет ее веса. При конфликте правил, нехватке данных или длинной цепочке действий модель может выполнить инструкцию частично или понять ее иначе.

Но дообучение не создает свежие данные.

Настоящее дообучение использует пары:

вход → правильный выход

Например:

запрос + описание приложения

→ тип поискового намерения

или:

признаки пары «запрос – приложение»

→ экспертная оценка текстовой релевантности

Модель учится уменьшать ошибку на таких примерах. Затем ее проверяют на отдельной выборке, которую она не видела при обучении. Именно так дообучение описано в технической документации OpenAI.

Apple в исследовании App Store сделала то же самое. Эксперты размечали пары «запрос – приложение» по единой шкале текстовой релевантности. Разметку разделили на обучение и проверку. На обучающей части дообучили предметную модель с 3 миллиардами параметров. На отложенной части сравнили ее с универсальной моделью с 30 миллиардами параметров. F1 выросла с 0,382 до 0,800.

Затем Apple создала миллионы дополнительных оценок пар «запрос – приложение», добавила их в обучение отдельного ранжировщика, проверила качество через NDCG и провела мировой A/B-тест.

5. Анализ итерации

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

Позиция в один случайный день может быть выбросом. Нужны сопоставимые окна до и после, медиана, контрольная группа. Если строим регрессию по видимости или логарифму позиции, смотрим коэффициент детерминации R² – какую долю разброса результата объясняет модель, – а также скорректированный R², остатки, доверительные интервалы и устойчивость коэффициентов. Отдельно анализируем функциональные, навигационные и обзорные запросы, новые появления в выдаче и реальные подъемы позиций. Смешивать это нельзя.

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

6. «Семантическая плотность»

Ладно, ИИ сказал, все плохо, переделывай. Давайте проработаем полное описание. И попросим чтобы нам сделали описание под поиск на естественном языке, чтобы не только лексическую плотность увеличить, но и семантическую.

Запрос один, текст тот же, а показатели разные. Что именно посчитал ИИ?

Число повторов – это лексическая плотность. Но текст может быть плотным и при этом нерелевантным запросу, намерению, локали и корпусу приложений. Поэтому отдельно измеряют смысловое покрытие.

В книге «Поиск на основе искусственного интеллекта» есть наглядный пример.

Для запроса the cat in the hat три документа сначала ранжируют по простому числу совпавших слов. Документ, где много раз повторяются служебные слова the и in, получает 14 баллов и выходит первым. Документ, который действительно посвящен книге The Cat in the Hat, получает 12.

Математика здесь не ошиблась. Ошибка в функции: больше повторов – выше оценка.

В ASO то же самое: описание можно набить словами best, free, app, получить высокую «плотность» и почти не добавить различающего сигнала.

TF считает, сколько раз термин встретился в тексте. IDF снижает вес слов, которые встречаются почти у всех документов корпуса.

TF(t,d) = число вхождений терма t в документ d.

Повторы не должны давать линейный рост: второе, третье и десятое вхождение добавляют все меньше.

Для IDF нужен корпус: изменился корпус – изменился вес терма.

IDF(t) = log((N + 1) / (df(t) + 1)) + 1.

Для лексического ранжирования часто используют BM25. Он учитывает частоту и редкость терма, длину документа и насыщение повторов.

BM25(q,d) = Σ IDF(t) · f(t,d)(k1+1) / [f(t,d) + k1(1-b+b·|d|/avgdl)].

TF-IDF и BM25 хорошо ловят точные слова. Для смысловых связей используют векторные представления.TF-IDF и BM25 хорошо ловят точные слова. Для смысловых связей используют векторные представления.

Запрос и текст переводят в векторы и измеряют их близость, например косинусом:

sim(q,s) = cosine(E(q), E(s)).

Здесь E – конкретная версия модели. Другая модель, язык, нормализация и разбиение текста дадут другое число.

Модель и порог калибруют на размеченных парах «запрос – приложение», а затем проверяют точность, полноту, F1 и NDCG.

В исследовании Apple специализированная модель с 3 миллиардами параметров получила F1 0,800, а универсальная модель с 30 миллиардами – 0,382.

Чего нет у GPT

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

Поэтому точный процент – не измерение. Это число, похожее на измерение.

Инструмент векторизации даст настоящий косинус, но без калибровки это останется геометрической близостью универсальной модели, а не измеренной релевантностью запросов стора.

7. «Мы автоматизировали ASO»

Седьмая ошибка – автоматизация ASO без всех специфических контуров, о которых я говорил. В итоге получается не система, а чат, которому дали больше материалов. Как интерфейс к инструментам модель полезна. Как самостоятельный расчетный контур – нет.

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

Отсюда главный вопрос: как собрать такой контур под свое приложение, агентство или продуктовую команду?

Ответ – ASO Engineering Academy.

ASO Engineering Academy – это программа для специалистов, которые уже делают ASO и хотят глубже понимать поисковые механизмы, принимать решения на данных и правильно автоматизировать работу.

Я руковожу ASO-отделом, работал с локализацией продуктов на рынки Юго-Восточной Азии, программирую на Python (продвинутый уровень, Минцифры), сертифицированный разработчик поискового движка Algolia, изучал векторный поиск и векторные представления в Google и инжиниринг релевантности у специалистов Spotify, Reddit, Google и OpenSearch.

Поэтому я могу связать три слоя, которые редко соединяются в одной ASO-программе:

• что специалист делает с приложением;
• как поисковая система обрабатывает запрос и ранжирует документы;
• как эту работу перевести в код, в профессиональный автоматизированный процесс.

На курсе вас ждут 5 модулей:

Первый модуль дает фундамент, которого обычно не хватает даже опытным ASO-специалистам, а именно техническую модель поиска в магазинах приложений.

Мы разбираем, как приложение превращается в индексируемый документ, как система обрабатывает запрос, определяет намерение, ищет точные и смысловые совпадения, формирует набор кандидатов и выставляет итоговый порядок с учетом текстовых, поведенческих и продуктовых сигналов.

Во втором модуле теорию превращаем в практику. Я передаю свой подход к ASO, шаблоны, скрипты и чек-листы, чтобы вы собрали стратегию на данных своего приложения.

В третьем модуле вы проектируете собственную агентскую систему и пишете программы на основе моих пайплайнов. Я передаю архитектурные шаблоны, каркасы программ и механики, которые вы докрутите под свои задачи с помощью вайбкодинга. Покажу, как использовать этот вайбкодинг. Погрузимся в математику и машинное обучение. И я не даю лишнего, не углубляюсь туда, куда не надо. И опыт показывает, что участники академии без опыта разработки создают крутые и работающие вещи.

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

Пятый модуль посвящен новому слою поиска – ответам Perplexity, ChatGPT, DeepSeek и других генеративных систем. Мы разберем, как такие сервисы формируют поисковые запросы, выбирают источники, извлекают фрагменты, ранжируют материалы и создают ответ пользователю.

Что участник получает в итоге

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

Для специалиста это новый уровень квалификации, умение оптимизировать приложения под поиск на естественном языке. Для агентства – снижение часов, рост числа проектов на одного сотрудника и собственная технология внутри компании. Для продуктовой команды – контроль над данными.

Закрытый клуб

После обучения вы переходите в закрытый клуб специалистов по ASO, SEO, OSINT, программированию и инженерии релевантности. Там мы разбираем новые исследования и патенты, изменения App Store и Google Play, результаты экспериментов, обновленные шаблоны и методы работы с веб- и AI-поиском.

Новые лекции и материалы выходят только для участников клуба. При чем, стараюсь делать хотя бы раз в месяц новую лекцию.

Если хотите перестать делать ASO по чек-листам и построить собственную систему – первый модуль открыт бесплатно.