Спочатку лад у знаннях, потім ШІ: Юрій Руднєв

Кейс: внутрішня ШІ-система для маркетингу шести брендів в естетичній медицині. Чому пошуку по документах виявилось мало і чому головним результатом стали не афіші.

З чого все почалося

Швидко поправити афішу семінару. Або зробити нову, коли дизайнер зайнятий. Написати рекламні тексти під Facebook та Instagram. Підготувати матеріали до події.

Це не проєкти. Це фонові задачі, які виникають раптово, «на вчора», і підступно регулярно. Кожна окремо займає небагато. Разом вони з’їдають місяць.

Вхідні дані такі: маркетинговий відділ невеликий, у портфелі шість брендів, дизайн і SMM частково на аутсорсі. Обсяг креативу не пропорційний розміру команди, і наймання цього не вирішує, бо потік нерівний. Три тижні тихо, потім чотири події за десять днів.

Тому я пішов найочевиднішим шляхом.

Спроба перша: просто попросити в ШІ

Виходило швидко. І щоразу трохи не те.

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

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

Два банери за одним брифом: ліворуч версія без системи з домальованим текстом на тюбику, праворуч версія з системою із затвердженим пакшотом — Один бриф, дві версії. Ліворуч без системи, праворуч із нею.

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

Що забрати собі: якщо ШІ дає результат, який треба щоразу поправляти в тому самому місці, проблема не в промпті. Проблема в тому, що модель не знає ваших обмежень, а ви їх ніде не записали.

Спроба друга: підвантажити документи

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

Це класичний RAG, retrieval-augmented generation: модель дістає потрібні фрагменти з вашої бази знань замість того, щоб покладатися тільки на себе.

Стало краще. Головного не вирішило.

Бо RAG відповідає рівно на одне питання: де знайти інформацію. А в роботі питання інші.

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

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

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

Що саме побудовано

Технічно це проєкт у ChatGPT. Жодної власної розробки, жодного рядка коду. Інструкції, структуровані джерела й правила поверх звичайної моделі. Збірка інструкцій на момент публікації займає 7912 знаків із доступних 8000, і це окрема дисципліна: кожне нове правило треба або вмістити, або виміняти на старе.

Архітектура складається з чотирьох шарів.

Схема системи з чотирьох рівнів: креативне ядро, шість брендових модулів, джерела і права, контроль claims

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

Брендові модулі. Шість брендів, у кожного власні правила, затверджена мова, доказова база й активи. Головна вимога до цього шару звучить як заборона: логіка одного бренду не переноситься на сусідній. Усереднений «тон портфеля» був би зручним і абсолютно непридатним.

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

Контроль. Реєстр claims, тобто перелік того, що взагалі дозволено стверджувати. І бібліотека рішень: правила, зібрані з реальних кейсів, а не придумані наперед.

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

Найцінніше в системі це заборони

Ось теза, до якої я йшов найдовше.

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

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

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

І кожна заборона з’явилася не з теорії.

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

Зараз таких правил кілька десятків, і кожне має свою неприємну історію.

Правило коштує двох помилок

Це єдине місце в системі, яким я справді задоволений.

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

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

Поріг у дві незалежні помилки відсіює шум і водночас не дає системі забути справжню проблему.

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

Що система робить сьогодні

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

Тепер цифри, і тут я буду обережний.

Базовий замір зроблено 19 липня 2026 року на вибірці з 12 достатньо повних творчих задач і 42 з лишком підтверджених циклів правок. Вибірка мала, це не дослідження.

Перше, що з неї видно: з першого разу приймається від 25 до 33 відсотків результатів. Тобто дві третини роботи все одно повертаються на доопрацювання. Підсумкова прийнятність після циклу правок близько 83 відсотків.

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

Третє, чого в цифрах немає. Немає ROI. Немає впливу на продажі. Немає економії в хвилинах, бо я не знімав таймстемпи й вигадувати їх не буду. Помилки в claims не зникли, вони стали передбачуваними. Дизайнера й копірайтера система не замінила.

Головний висновок звучить неефектно: креативний директор на ШІ не скасовує рев’ю. Він перетворює хаотичні правки на керований процес. Якщо вам обіцяють більше, попросіть вибірку.

Що я переоцінив: складність наростає непомітно

Обов’язковий блок про те, що пішло не так. У цьому проєкті це не збій системи, а моя власна помилка в тому, як я її будував.

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

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

Жоден із цих кроків не був помилковим. Помилковою була сума.

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

Що забрати собі: рецензент, який пропонує щось додати, завжди має рацію в межах свого зауваження. Обмеження на загальний обсяг має тримати не він, а ви. Ліміт у 8000 знаків виявився не перешкодою, а найкориснішим елементом конструкції.

Чого я досі не зробив: не виміряв час. Немає цифри «скільки займала афіша до і після». Її вже не буде за минулий період, і це втрачені дані.

Побічний продукт виявився головним

Тепер те, заради чого писався весь текст.

Поки я будував це під афіші, зібралося дещо інше. Структурована база знань про весь портфель: продукти, показання, затверджена мова, доказова частина, історія рішень команди.

Те, що раніше жило в буклетах, у чатах і в голові, яка вже давно не здатна тримати таку купу інформації.

І виявилось, що афіші це найменше з того, для чого воно згодиться.

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

Велосипед я не винаходив. Те саме давно роблять у розробці й у дизайн-системах, тільки називають інакше. По суті цим займаються Unilever зі своїми цифровими двійниками упаковок і Morgan Stanley з внутрішньою базою для радників. Різниця між ними й мною лише в бюджеті й кількості людей. Логіка та сама: спершу навести лад у знаннях, і тільки потім просити ШІ щось із ними робити.

Що я з цього зрозумів

Задача звучала як «прискорити виробництво креативу». Результат виявився інфраструктурним.

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

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

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

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

Далі: Сайт без розробника: як ШІ забрав виконання і не забрав відповідальність