Будуйте системи, ставте цілі: ШІ в SEO і продуктах

Більшість розмов про штучний інтелект починається з вибору моделі: яка розумніша, яка дешевша, яка краще пише код або працює з великим контекстом. Я пропоную починати з іншого запитання: яку систему ми будуємо і який результат вона має давати?

Матеріал підготовлено за мотивами мого виступу на конференції AI SEO Day від WebPromo Experts 19 серпня 2026 року.

Титульний слайд ставить ціль перед моделлю. Це не каталог ШІ-продуктів, а підхід до роботи, де вхідні дані, правила, перевірка, зворотний зв’язок і відповідальність підпорядковані вимірюваному результату.

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

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

Не обов’язково складну. Іноді достатньо скрипту, кількох файлів із правилами та зрозумілої перевірки результату. Важливіше інше: система має звільняти час для завдань, які справді потребують людини, - стратегії, перевірки гіпотез, розуміння продукту й ухвалення рішень.

Нижче - мій практичний підхід до таких систем: від мети й контексту до агентної роботи, перекладів і SEO-аналітики.

Система починається не з моделі, а з мети

Система - це не набір модних інструментів і не кілька агентів, яким дали красиві ролі. Це сукупність взаємопов’язаних елементів, організованих для досягнення спільної мети.

Найпростіша робоча система має кілька обов’язкових частин:

1. мету;
2. вхідні дані;
3. процес перетворення;
4. перевірку;
5. результат;
6. зворотний зв’язок.

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

Хороша мета достатньо мала, щоб її можна було перевірити

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

У цьому сенсі SMART - не просто картинка з підручника. Мета має бути конкретною, вимірюваною, досяжною, релевантною й обмеженою в часі. Формулювання «автоматизувати роботу з контентом» майже нічого не дає. Формулювання «отримувати X грошей від контенту за Y часу за такого-то обсягу публікацій» уже змушує проєктувати реальний процес.

Поки мету не визначено, неможливо відповісти навіть на базові запитання:

• який результат має створювати система;
• які джерела вважати канонічними;
• що виконувати кодом, а що - LLM;
• як перевіряти результат;
• що робити в разі невпевненості;
• хто ухвалює фінальне рішення.

Система не обов’язково має бути складною

Один із моїх особистих експериментів почався з дуже простої думки: якщо я все одно витрачаю час на свої інтереси, чи можна хоча б частину цього часу монетизувати?

Раз на тиждень ми з друзями граємо в онлайн-гру. Я записую ці сесії, а далі локальна система шукає активні моменти за звуком і відео, нарізає короткі кліпи, приводить їх до потрібного формату й надсилає в Gemini API. Модель оцінює фрагмент і пропонує опис та заголовок. Після автоматичної внутрішньої перевірки придатні ролики публікуються в YouTube Shorts. Коли їх накопичується достатньо, система збирає довге відео й теж завантажує його на канал.

У підсумку канал отримує тисячі переглядів на день, а монетизація компенсує час, який я й так провів би у грі.

Тут LLM - лише одна деталь. Нарізанням і перекодуванням займається FFmpeg, критерії відбору задані окремо, публікація - окремий етап. Є вхід, процес, перевірка й вимірюваний вихід. Саме це робить рішення системою, а не вдалим промптом.

Щоб побудувати систему, потрібно розбиратися в предметі

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

Припустімо, я хочу створити власний комікс. Сюжет і команда «згенеруй мені сторінку» - лише початок. Мені потрібно розуміти, із чого взагалі складається комікс: як побудований сюжет, яким буде візуальний стиль, як виглядають герої, які деталі мають зберігатися між сценами, який контекст передавати моделі під час генерації наступної сторінки. Без цього вийде не система, а набір випадкових картинок.

Те саме в SEO. Якщо ви не розумієте, що й чому має відбуватися із сайтом, то не зможете ні поставити моделі правильне завдання, ні помітити помилку, ні перевірити результат.

Є показова історія з консультаційної практики. Керівник отримав доступ до агентного інструмента й попросив проаналізувати становище великого інтернет-магазину. Інструмент почав збирати дані й малювати переконливі графіки, з яких випливало, що все погано, хоча реальні гроші свідчили про протилежне.

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

Тому правильна позиція - не «я замінюю себе моделлю», а «я стаю оператором LLM у своїй професійній сфері». Модель дає швидкість і допомагає бути уважнішим. Відповідальність за мету, метод і перевірку залишається у фахівця.

Проєктуйте систему так, щоб її частини можна було змінювати

Жодна система не залишається оптимальною назавжди. Змінюються моделі, сервіси, ціни й обмеження. Тому компоненти мають бути замінними.

Наприклад, я зібрав особистий процес вивчення нової теми. Спочатку обираю книжки, потім за допомогою LLM роблю короткий конспект і розумію, чи справді джерело мені потрібне. Оскільки мені не завжди зручно читати очима, вибраний матеріал перетворюється на аудіоверсію. Спочатку я сам збирав цей етап, але якість була посередньою. Коли з’явився ElevenReader, я замінив один компонент - а вся решта системи залишилася незмінною.

Це важливий принцип і для SEO-автоматизації. Якщо весь процес тримається на одному конкретному чаті, зміна моделі змушує збирати роботу заново. Якщо ж окремо описано мету, вхід, правила, перевірки й формат результату, модель залишається замінним виконавцем.

Забудьте про магічні промпти: головне - контекст

Кілька років тому основною навичкою вважалося проєктування промптів: як сформулювати запит, які слова додати, як змусити модель міркувати «правильно». Тепер сильні моделі досить добре розуміють звичайну мову. Запит можна навіть надиктувати.

Питання перемістилося в інше місце: що модель узагалі бачить?

Результат дедалі менше залежить від магічного формулювання й дедалі більше - від джерел, меж, правил та історії рішень. Тому замість проєктування промптів я волію говорити про проєктування контексту.

У попередньому виступі я показував, як збирати проєктні знання й дані для окремих SEO-завдань. Тут наступний рівень: як перетворити накопичений контекст на систему, що переживає зміну чатів і моделей.

Де брати робочий контекст

Контекст SEO-фахівця зазвичай уже існує, просто розкиданий у різних місцях:

• у базі знань або Confluence лежать аудити, гіпотези, тести й, що особливо важливо, висновки про те, що спрацювало, а що ні;
• у Jira або іншому таск-трекері є опис завдання, причина його появи, обговорення й посилання на реалізацію;
• у збережених листуваннях залишаються рішення, які так і не потрапили до формальної документації;
• у транскрипціях дзвінків міститься те, що команда проговорила, але більше ніде не зафіксувала.

Особливо важливий не сам факт виконання роботи, а її результат. Якщо ми переклали сто тисяч описів, контекст не повинен закінчуватися повідомленням «переклад готовий». У ньому слід записати, скільки сторінок переіндексувалося, що сталося з позиціями й трафіком, які помилки знайшли та які правила змінили після перевірки.

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

Формат теж має значення. LLM зручно працювати з легкими текстовими форматами: Markdown для документів, CSV для таблиць, JSONL для масових операцій. Такий контекст легко читати людині, версіонувати й переносити між інструментами.

Чому глобальна пам’ять підходить не всім

Вбудована пам’ять зручна, коли у вас один продукт і стабільний контекст. Але SEO-фахівець або агенція може одночасно працювати з десятками сайтів. Тоді факти, правила й обмеження різних проєктів починають змішуватися. У пам’яті залишаються застарілі відомості, а побачити й перевірити все, що модель вважає відомим, складно.

Я надаю перевагу явній структурі папок і каскаду файлів правил. На верхньому рівні містяться спільні принципи роботи. Нижче - окремі папки для особистих і робочих напрямів, компаній, сайтів, проєктів та завдань. Кожен рівень додає лише свої правила.

Цей підхід має три переваги:

• контекст ізольований і не перетікає між сайтами;
• правила видимі - їх можна відкрити й перевірити;
• зміни версіонуються разом із проєктом.

Перед початком завдання я свідомо вибираю скоуп: відкрити агенту всю робочу папку, один сайт або лише каталог конкретного завдання. Що вужче завдання, то менше нерелевантного контексту й то нижчий ризик змішування даних.

Стан завдання має жити у файлах, а не в чаті

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

Тому для кожного завдання я використовую чотири файли:

TASK.md дає змогу відразу перевірити, чи правильно модель зрозуміла запит. PLAN.md показує, чи не збирається вона, наприклад, розраховувати фінансові показники без доступу до вихідних даних. KNOWLEDGE.md зберігає «граблі»: непрацюючий спосіб підключення, особливість API, пастку в даних або причину вибору одного рішення замість іншого. RESULT.md фіксує не обіцянку моделі, а фактично отриманий і перевірений результат.

Індекси роблять кожне наступне завдання дешевшим

Коли завдань стає багато, самих папок недостатньо. Після завершення завдання його стислий зміст варто додавати до індексу - наприклад, до CSV-таблиці. На початку нової роботи агент спершу знаходить схожі завдання, а потім підтягує їхні результати й накопичені знання.

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

В ідеалі завдання має читатися «з холодного старту»: інша модель, інша машина, нульова пам’ять про розмову - але з файлів зрозуміло, навіщо робота почалася, де зупинилася і як перевірити результат.

Агент - це цикл, а оркестратор - механізм, який його запускає

Між чатом і агентом є принципова різниця. У чаті людина ставить запитання, отримує відповідь і повторює цикл вручну. Агенту задають мету, дають план, дані й інструменти, після чого він виконує кроки, перевіряє проміжний результат і за потреби повторює окремі дії.

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

Тому погіршення результату не завжди означає, що «модель стала дурнішою». Змінитися міг оркестратор, його налаштування, спосіб збирання контексту або набір допоміжних моделей. Важливо бачити не лише фінальну відповідь, а й те, які кроки виконувалися, яке завдання отримав субагент і що саме він повернув.

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

Перетворюйте повторювану роботу на робочий сценарій

Коли те саме завдання виконано кілька разів, із його історії можна зібрати робочий сценарій - відтворюваний опис процесу.

Хороший робочий сценарій містить:

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

Припустімо, ви регулярно збираєте семантичне ядро. Замість нового чату щоразу можна зберігати робочу послідовність, формати файлів і скрипти, які використовувалися раніше. Для нової тематики змінюється вхід, а перевірений каркас залишається.

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

Кейс: масовий переклад без режиму міркування

Один із практичних прикладів - переклад великого каталогу. На вході було 408 418 описів. Після фільтрації залишився 160 551 товар, а дедуплікація скоротила обсяг приблизно до 125 600 унікальних текстів.

Наївний варіант - підготувати таблицю, надіслати її в batch inference і забрати відповіді. Але тоді значна частина ручної роботи йде на підготовку й пересилання файлів, а головне - у процесі немає належного контролю якості.

У робочій системі ролі розподілено:

1. код вивантажує каталог, фільтрує записи й дедуплікує тексти;
2. DeepSeek перекладає унікальні тексти з вимкненим режимом міркування;
3. результати кешуються в JSONL разом із версією промпта;
4. детерміновані перевірки знаходять формальні помилки;
5. прості проблеми виправляються автоматично;
6. спірні тексти потрапляють у чергу ручної перевірки;
7. додатково випадкову вибірку перевіряють носії мови;
8. системна помилка призводить до виправлення правила й повторного прогону зачеплених записів.

Чому режим міркування тут погіршував результат

Переклад не потребує багатокрокового висновку. Йому потрібні точні правила, інформація про тематику, хороший глосарій і збереження початкового змісту. Модель із режимом міркування витрачала токени на зайві роздуми, намагалася поліпшувати стиль і додавала інтерпретацію там, де потрібне було акуратне перенесення тексту.

Після вимкнення режиму міркування у цьому кейсі:

• кількість токенів на виклик зменшилася на 80,7%;
• вартість перекладу одного слова знизилася у 3,5 раза;
• оцінка якості носіями мови зросла на 3,2%;
• повний прогін став приблизно в 35 разів швидшим.

Це хороший приклад того, чому не існує «найкращої моделі взагалі». Для конкретного завдання важливі достатня якість, швидкість, вартість і керованість. Дорожчий режим із міркуванням може виявитися гіршим за простий, якщо система потребує не висновку, а точного повторюваного перетворення.

Кейс: огляд сайту з логів, краулінгу й бізнес-даних

Інший типовий сценарій - зрозуміти, де у великого сайту реальні SEO-проблеми й у якій послідовності їх виправляти.

Для цього можна зібрати в одному процесі кілька джерел:

• серверні логи;
• дані Google Search Console із BigQuery;
• результати краулінгу сайту;
• цільову модель або набір SEO-правил;
• за потреби - дані про продажі та інші бізнес-пріоритети.

Логи й Search Console можна зберігати в ClickHouse, результати Screaming Frog - експортувати в таблиці, а потім звести все за URL локальними Python-скриптами. Для кожної сторінки зіставляються фактична поведінка Googlebot, трафік, статус сторінки й цільовий стан.

На виході отримуємо не абстрактне «проаналізуй мій сайт», а три результати, які можна перевірити:

1. карту розбіжностей між реальним і цільовим станом;
2. пріоритети - що виправляти насамперед;
3. конкретні завдання для сайту.

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

Рахувати має код, а не мовна модель

У моїх правилах прямо записано: навіть невеликі розрахунки потрібно виконувати кодом. LLM може написати Python-скрипт, пояснити його результат і допомогти знайти логічну помилку. Але самі числа має отримувати відтворюваний процес.

Причина проста: до коду можна повернутися. Можна побачити формулу, вхідні дані, проміжні значення й повторити обчислення. Якщо модель просто повідомляє, що щось порахувала «на своєму боці», перевірити хід роботи набагато складніше.

Важливо розрізняти обчислення й інтерпретацію:

• код рахує, фільтрує, об’єднує й перевіряє формальні умови;
• модель допомагає написати цей код, пояснює результат і шукає можливі причини;
• фахівець визначає, чи відповідає висновок реальності й чи можна на його основі діяти.

Джерелом даних теж має бути база, аналітична система або інше канонічне джерело - але не відповідь ChatGPT. В одному відомому мені випадку компанія готувалася до інвестиційного раунду, зібрала дані в керівників, а під час презентації з’ясувалося, що частина показників не сходиться. Один із учасників просто запитав потрібні відсотки у ChatGPT, і модель їх вигадала. Переконливе число не стає фактом лише тому, що добре виглядає на слайді.

Три правила, які захищають від більшості проблем

1. Завжди починайте з плану

API може обірватися, інструмент - не виконати частину кроків, а модель усе одно повідомить, що завдання готове. План дає змогу перевірити не впевненість відповіді, а фактичне виконання кожного пункту.

Особливо важливо звіряти наявність файлів, повноту даних і результати перевірок. Фраза «готово» сама по собі нічого не доводить.

2. Використовуйте окремого критика

Після виконання складного завдання корисно відкрити окремий контекст і попросити критика перевірити результат за початковим планом: що пропущено, які припущення не доведено, де бракує перевірки.

Критик не знімає відповідальності з людини, але допомагає шукати інший клас помилок. Фінальне рішення все одно має ухвалювати той, хто розуміє предмет і відповідає за наслідки.

3. Обмежуйте контекст відповідно до завдання

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

Не делегуйте свій інтелект

Модель може мати більше знань, ніж будь-яка окрема людина. Але знання й досвід - різні речі. Досвід означає розуміння конкретного проєкту: чому рішення було ухвалено, які обмеження приховані в даних, де красивий результат не відповідає реальності та які запитання потрібно поставити до запуску.

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

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

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

Модель може змінюватися. Ваша система - залишається вашою.

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