Генерація alt-текстів AI: де ламається індексація
Зображення в каталозі — самостійна точка входу з пошуку за картинками, і воно губиться тихо. Порожній alt-атрибут, той самий опис на тисячі позицій або підпис, зібраний підстановкою за назвою розділу, — і знімок випадає з видачі, хоча сторінка формально проіндексована.
Причина майже завжди організаційна: описи збирають разово й вручну. Поки каталог невеликий, команда встигає пройти альбоми повністю, але на тисячах позицій розмітка розходиться з асортиментом.
У частини карток залишається порожній alt, у частини — заглушка вигляду «фото товару», і пошуковик їх не розрізняє.
Шаблонні описи картинок ламають інакше. Підстановка «{категорія} купити» формально заповнює атрибут, але не описує вміст і повторюється у сотень сторінок: пошук не розуміє, що на знімку, а розділ загалом виглядає малозмістовним. Найбільше страждають категорії, де розрізняються ракурс, комплектація або колір.
Автоматичний опис зображень знімає залежність від ручних проходів. Система дивиться на сам знімок і будує підпис за вмістом — що за предмет і як він показаний, — а не за назвою розділу.
Унікальність і відповідність вмісту перевіряються до запису в розмітку, тому дублі й порожні значення не накопичуються між вивантаженнями.
Нижче розбираємо, як генерація alt-текстів AI закриває ці точки і що потрібно, щоб індексація зображень у каталозі трималася без ручної підтримки.
Вимірюваний ефект: охоплення індексації, швидкість, зняті відмови
Ефект від генерації alt-текстів вимірюється не числом описаних картинок, а тим, що змінилося в індексі та в темпі роботи контент-команди.
До впровадження фіксуємо базову лінію: частка сторінок каталогу в індексі, охоплення зображень у пошуку, кількість помилок розмітки, час викладки однієї позиції. Ті самі вимірювання повторюємо на тій самій вибірці після запуску — інакше «стало краще» залишається думкою.
Що перевіряємо після впровадження:
- Частка проіндексованих сторінок із зображеннями — зростає за рахунок карток, які раніше випадали з видачі через порожній або шаблонний alt.
- Охоплення зображень у пошуку — картинки знаходяться за смисловими запитами, а не лише за іменем файлу.
- Швидкість наповнення каталогу — викладка позиції не чекає ручного опису: підписи приходять разом із завантаженням.
- Клас помилок розмітки — зникають дублі alt, підписи вигляду «image_01» і порожні значення, залишаються поодинокі правки.
- Автоматизація описів — частка правок людиною падає до вибіркової перевірки, а не повного переписування.
Орієнтир щодо якості беремо з рекомендацій Google Search Central: alt описує вміст і функцію зображення мовою сторінки. Вибірково перевіряємо частину генерацій вручну й рахуємо частку правок — за нею видно, чи тримає система планку без постійної участі редактора.
Пакетний, потоковий і ручний режими опису зображень
Три режими — не конкуруючі системи, а точки входу в один набір правил опису. Різниться лише те, як зображення потрапляє на обробку і хто підтверджує результат: пакетний прохід по всьому каталогу, поштучний опис у момент завантаження або вичитка людиною.
Вибір режиму визначається потоком публікацій і тим, наскільки критична точність на конкретному розділі каталогу.
Перемикання між режимами не потребує міграції: описи прив’язані до ідентифікатора зображення в спільному сховищі.
Тому каталог можна один раз прогнати пакетом, далі досипати новинки потоком, а спірні формулювання на важливих сторінках доопрацювати вручну — без повторної обробки вже готового.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Пакетна обробка зображень | Масове наповнення: каталог на тисячі позицій, перенесення зі старої системи, разовий прохід по архіву | Працює за знімком каталогу — позиції, додані після запуску, чекають наступного проходу |
| Потоковий опис при завантаженні | Регулярний потік публікацій: картки, новини, оголошення з’являються поштучно | Тримає чергу й додає затримку до публікації; при пікових заливках потрібен резервний пакетний прохід |
| Ручна перевірка описів | Ключові сторінки, товари з тонкими відмінностями, чутлива лексика | Пропускна здатність обмежена людьми — на великих обсягах не масштабується |
На практиці робочий варіант — змішаний: пакет закриває вже накопичений каталог, потік підхоплює нове, ручна перевірка залишається фільтром для сторінок, які приносять трафік. Опишіть свій потік публікацій і обсяг архіву — повернемося з оцінкою та схемою режимів під нього.
Етапи впровадження: від аудиту розмітки до передачі регламентів
Впровадження йде від факту, а не від моделі: спочатку вимірюємо те, що вже розмічено, і лише потім налаштовуємо систему.
На каталозі в тисячі позицій 30-40% зображень зазвичай ідуть із порожнім атрибутом або службовим іменем файлу — і поки це не виміряно, генерація alt-текстів AI-системою працює по шуму.
-
Аудит розмітки. Вивантажуємо зображення разом з оточенням — заголовок, категорія, сусідній текст — і розкладаємо за групами: порожній атрибут, службове ім’я, дубль, осмислений опис. На виході — таблиця часток і список сторінок, де розмітка заважає і індексації, і доступності.
-
Проєктування схеми описів. Визначаємо джерела фактів для кожної групи сторінок: властивості картки, категорія, вміст блоку. Фіксуємо структуру опису — що йде першим, що обов’язкове, що варіюється, щоб сусідні картки не отримували однакові тексти.
-
Налаштування мови описів. Задаємо довжину, відмінки, стоп-слова, правила для зображень без корисного контексту. Для декоративних елементів окремо прописуємо порожній атрибут — інакше в розмітку йде сміття.
-
Перевірка якості описів. Прогоняємо контрольну вибірку й дивимося частку тих, що пройшли правила, частку унікальних, число спрацювань фільтрів. Розходження розбираємо вручну й повертаємо в налаштування, поки результат не стабілізується.
-
Пробний запуск на обмеженій групі сторінок. Знімаємо метрики: частка зображень з описом, коректність вставки в розмітку, час обробки вивантаження. Охоплення розширюємо лише після стійкого результату.
-
Передача регламентів. Віддаємо інструкцію команді замовника: як додавати нові правила, що робити з новими типами сторінок, як перевіряти вивантаження і куди дивитися при розходженні. Далі систему ведуть усередині, без зовнішньої підтримки на кожному кроці.
Документація, схеми розмітки й регламенти передачі
Після запуску в замовника залишаються не лише робочий сервіс і доступи, а й комплект документації, за яким систему можна розвивати без нас. Фіксуємо не «як натиснути кнопку», а як влаштовані рішення: чому опис формується саме так і де проходять межі автоматики.
- Документація по системі. Шлях зображення від завантаження до запису опису, склад компонентів, точки відмови й поведінка при недоступності зовнішніх сервісів.
- Схема розмітки зображень. Типи сторінок і сутностей, зв’язки зображення з товаром або матеріалом, обов’язкові поля й ознаки конфлікту.
- Правила формування описів. Довжина, структура, тон, обробка торгових марок, дублів і повторюваних картинок.
- Інструкція для редакторів. Як розбирати чергу на перевірку, де перевизначити згенерований текст, як позначити помилку — з прикладами правильних і неправильних описів.
- Регламент оновлення описів. Тригери перегенерації: зміна асортименту, новий шаблон сторінок, масова заміна зображень.
- Конфігурації й словники. Стоп-листи, тематичні словники, пороги впевненості й правила винятків за розділами каталогу.
- Карта відповідальних. Хто погоджує правки правил, хто приймає нові типи сторінок, як знання передається новому співробітнику.
Усе зберігається в репозиторії поруч із кодом і версіонується: зміна правил проходить погодження, історія правок зберігається. Нова команда входить у роботу за документами, а не за листуванням у чатах.
Кейс: каталог інтернет-магазину — охоплення індексації зросло втричі
Що було до впровадження
Розбираємо кейс автоматизації описів у каталозі інтернет-магазину: близько 6 200 позицій, і в 4 800 карток атрибут alt був порожнім або містив ім’я файлу вигляду IMG_0421 — для пошуку такі зображення не існували.
Контент-менеджер заповнював усе вручну: 3-4 хвилини на картку, 40-60 позицій на тиждень, тобто каталог не закрився б і за рік.
Що змінили
Задачу розбили на три шари. Розпізнавання визначає, що на знімку: категорія товару, колір, матеріал, ракурс. Складання опису йде за шаблонами з підстановкою атрибутів картки, тому alt збігається з вмістом сторінки, а не перетворюється на набір ключових слів.
Черга завдань дозаповнює нові позиції при вивантаженні каталогу, а вимірювання ведемо за звітами Google Search Console — видно, які сторінки реально потрапили в індекс.
Метрики до і після
| Показник | До | Через місяць |
|---|---|---|
| Карток із заповненим alt | 22% | 96% |
| Сторінок каталогу в індексі | 1 240 | 3 700 |
| Час на один опис | 3-4 хв | 20 сек |
| Частка ручної вичитки | 100% | 8% |
Які обмеження виявилися
Досвід впровадження показав і межі застосовності. Інфографіка із вшитим текстом — розмірні сітки, склад, умови доставки — залишилася на ручному розборі: модель бачить картинку, але не сенс таблиці всередині неї.
Групові знімки з кількома товарами описуються за першим планом, під них шаблони доналаштовували окремо. І головне: самі по собі alt не замінюють роботу над текстами — зростання охоплення індексації дала зв’язка «опис + атрибути + перелінковка».
Чим AI-опис відрізняється від шаблонної підстановки назв
Шаблонна підстановка збирає рядок із полів каталогу: назва, категорія, бренд, іноді колір. Інженерно це операція над текстом — однаковий вхід дає однаковий вихід, передбачуваність повна.
Поки в каталозі однотипні знімки з промовистими назвами, цього достатньо: опис формально заповнений і не заважає.
Ламається все на галереї з 8–12 кадрів одного товару. Шаблон видає той самий рядок для всіх, і сторінка отримує десяток дублів, що різняться суфіксом.
Пошукові системи бачать повтори й не отримують сигналу про те, що в конкретному кадрі: загальний план, упаковка, комплект, деталь вузла.
Другий клас помилок — нерелевантність. Підстановка не знає, що на фото: якщо в назві «крісло офісне», а в кадрі механізм гойдання, alt-текст описує не те, що видно. Це б’є і по пошуку, і по людях, які користуються екранним диктором.
AI-опис зображення йде від кадру: модель зіставляє побачене з контекстом сторінки й категорії та формулює рядок під конкретний знімок. Частка унікальних описів за галереєю зростає з одиниць до майже повного покриття, а збіги залишаються там, де кадри справді ідентичні.
Порівняння підходів зводиться до двох вимірювань: частка унікальних описів після нормалізації та частка рядків, що збігаються з вмістом кадру при вибірковій перевірці. Перший рахується скриптом, другий — ручною розміткою вибірки. На однотипних каталогах розрив мінімальний, на складних — кратний.
Технічні сумніви: якість, дублі, поведінка при збоях
Точність описів перевіряється не на десятку прикладів, а на вибірці: текст звіряється з вмістом кадру й призначенням сторінки, розходження фіксуються як дефект розмітки.
Для кожного класу зображень задано закритий набір того, що в опис потрапляти зобов’язане — об’єкт, дія, контекст, — і того, що заборонено: здогадки про людей, бренди, цифри. Усе, що виходить за ці рамки, йде на ручну перевірку, а не в розмітку.
Повторювані описи гасяться до запису: формулювання нормалізується й порівнюється з уже виданими в межах розділу, при високому збігу перезбирається заново.
Якщо унікальність не досягається за відведені спроби, зображення йде на розбір оператору — каталог не наповнюється однотипними рядками.
Система може вигадати те, чого немає на зображенні?
Може, тому опис будується лише на розпізнаному вмісті, без вільного домислювання. Кожна відповідь супроводжується оцінкою надійності: нижче порога — автоматичний запис не виконується, завдання потрапляє в чергу ручної розмітки.
На прийманні перевіряємо випадкову вибірку, частка розходжень — вимірюваний показник якості, а не обіцянка.
Що відбувається, якщо джерело зображень або сторінка недоступні?
Завдання залишається в черзі й повторюється з наростаючою паузою, запис не виконується, поки не отримано і кадр, і контекст сторінки. Поточний опис у розмітці не затирається: поки нове не згенеровано й не перевірено, на сайті залишається попередній текст. Збій одного потоку не блокує інші — черга розбирається частинами.
Які зображення система не бере?
Декоративні елементи, фони, розділювачі — їм за правилами належить порожній опис. Схеми, щільні колажі й скриншоти з дрібним текстом розпізнаються ненадійно, тому йдуть на ручну розмітку.
Такі обмеження проговорюються заздалегідь — ви розумієте, яка частка каталогу обробляється автоматично, а яка потребує оператора.
Обговоримо задачу: що підготувати до розмови
Щоб обговорення задачі зайняло одну розмову, а не три, корисно заздалегідь зібрати вступні. Вони визначають архітектуру генерації alt-текстів: звідки система бере зображення, на підставі яких полів будує опис і як результат потрапляє в розмітку каталогу. Нижче — перелік, який знімає більшість питань на старті.
- Джерела даних каталогу: вивантаження товарів у файлі, звернення до інтерфейсу картки або вибірка з бази. Важливо, які поля доступні — назва, категорія, атрибути, виробник.
- Сховище зображень: де лежать файли, як формуються постійні адреси, чи доступні картинки без авторизації.
- Поточна розмітка: як зараз заповнюється атрибут опису зображення, чи є шаблон і у чиїй зоні він перебуває — тема сайту, компонент картки або система керування контентом.
- Типи зображень: основне фото товару, галерея, інфографіка, промо-банери. Для кожного потрібен свій формат опису.
- Обсяги й частота: скільки позицій у каталозі зараз і як швидко з’являються нові.
- Мови й вимоги до стилю: одна мова чи кілька, обмеження за довжиною, чи потрібні входження за категоріями.
- Режим роботи: разова обробка всього каталогу, генерація при завантаженні товару або обидва сценарії разом.
- Критерії приймання: хто перевіряє якість і за якою метрикою — частка описів, прийнятих без правок, і покриття каталогу.
Після обговорення повернемося з оцінкою та планом робіт: схема генерації, порядок виведення описів у розмітку, склад етапів і строки. Якщо частина вступних недоступна — не критично, зберемо самі на етапі розбору. Наступний крок — короткий дзвінок за переліченими пунктами й письмовий план з оцінкою.
