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

Ілюстрація того, як повинна змінитися робота програміста (prompt: Claude Opus 4.5, picture: IMAGEN 4

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

Ключова користь вайб-кодингу для мене – це не заміна людини-розробника, а поява завжди доступного розробника (а то й багатьох розробників) і не тільки розробника. Я почав таку розробку з того, що автоматизував завдання, яке регулярно повторюється – підготовка чернеток і перевірка текстів для телеграм-каналу. Залучення AI розв'язало дві проблеми – проблему чистого аркуша в написанні коментаря і проблему помилок і неточностей, які я міг допустити, побіжно читаючи новину, що коментується. Але перш за все використання LLM – це був Sonnet 3.5 на той момент, – дозволило мені розробити рішення, яке інакше не було б реалізовано ніколи.

Так і продовжувалося – за цей рік я обріс цілим набором дрібних і не дуже програм і сервісів, які розв’язують якісь рутинні завдання. Я, мабуть, кілька років мучився з додаванням новин для обговорення в Радіо-Т – там треба вказати посилання, після чого робот намагається завантажити новину і виділити текст, але в половині випадків він стикається з блокуванням роботів. На розробку розширення для Chrome, яке відправляє контент поточної сторінки з посиланням, картинкою і без зайвих тегів через API сервісу, пішло в підсумку менш як годину й з того часу цей процес більше не дратує. Подивившись в черговий раз на свій блог, я зрозумів, що тримати величезний IDE тільки для написання тексту в блозі мені огидно, і за пару днів, точніше за 8 годин розробки, у мене з'явився спеціальний редактор під MacOS, який просто пише тексти, вставляє картинки та публікує в блозі.

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

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

Ні, якщо ви подумали, що це ми так пристосували AI, то ні, в самому процесі обробки жоден AI не страждає. Але він неабияк попрацював у процесі розробки прототипу.

Перш за все, процес пошуку рішення почався з декількох deep research в декількох LLM і довгих чатах за результатами досліджень – що може бути оптимальним джерелом сигналів? Кілька гіпотез, що виникли, були оперативно перевірені тут же написаними AI скриптами й відкинуті, а одна здалася цікавою. Потім була перехресна перевірка (на цьому, та й на будь-якому етапі такого спілкування з LLM дуже важливо вказувати на необхідність критичного аналізу, а то вони норовлять вигукнути «Прекрасна ідея» і сенс перевірки пропадає), і ми зайнялися безпосередньо реалізацією.

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

В одному випадку початкова ідея «нумо шукати в потоці певні ключові слова» в результаті реалізувалася в компактну ML-модель, яка фільтрувала записи не регулярними виразами, а використовувала Random Forest, показуючи 97% точності. Все необхідне для складання датасетів, навчання моделі й бібліотеку для inference написав, звичайно, AI – моя робота полягала в генерації гіпотез і написанні промптів. Так, всі метаморфози ідеї від гіпотези до архітектури рішення теж обговорювалися з AI.

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

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

Я ж у підсумку так розійшовся, що частина прототипів почала писатися на Go – компільованій мові, на якій я сам не напишу ні рядка. Але, коли прототип на Python почав з'їдати по 300 мегабайтів пам'яті й довелося вибирати між незнанням мови (хоча я і на Python не писав, весь код писався AI) і перспективою розтягнути тест фільтра на пару днів, довелося довіритися машині.

Зрозуміло, я не втримався і показав частину написаного коду колезі по подкасту Радіо-Т Умпутуну, який вважається авторитетом у розробці на Go. Женя, зрозуміло, сказав, що так ніхто не пише, він би такий код не прийняв і взагалі все погано, але до цих заперечень я ще повернуся.

Про другий проєкт я можу розповісти більше, тим більше, що це абсолютно публічна річ, доступна з літа десяткам тисяч користувачів. Мова піде про чатбот, який працює вже кілька місяців на українському порталі dtkt.ua. Чатбот відповідає на питання про податковий і бухгалтерський облік, може дати рекомендації з питань звітності, непогано орієнтується в змінах законодавства. Технічно це RAG (Retrieval-Augmented Generation) бот, який використовує як джерело дані самого порталу, що включають закони, новини, відповіді на питання, підготовлені консультантами, інструкції, інструктивні листи податкової тощо.

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

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

Питання вибору основної моделі теж не вирішилося швидко. Хоча мені було легше, оскільки я не знав правильних відповідей, але ось консультанти посперечалися. У підсумку я згадав минуле, взяв набір з декількох десятків питань і відповідей (вже наявні консультації) і влаштував нормальний evaluation – кілька кандидатів-LLM відповіли на питання, а потім їхні відповіді порівняли з еталоном – консультант і ще одна LLM-суддя. Переконавшись, що оцінки суддів корелюють (збігатися вони не будуть, але те, що вище оцінювалося машиною, вище оцінювала і людина), я прогнав через тест вже 200 питань, відповіді на які оцінювалися тільки LLM. На мій подив, перемогла, обійшовши таких солідних суперників, як OpenAI o1, GPT-4o і Sonnet 3.5, модель Google Gemini 2.5 Pro, яка тоді тільки вийшла.

І тут у клієнта з'явилося бажання зробити не помічника консультанта, а повноцінний чат-бот. А я, хоч і нагадував кілька разів, в тому числі самому собі, що граю роль консультанта з AI, в результаті подумав, а чому б нам і не замахнутися, розумієте? І сів писати ТЗ на другу версію.

Результат виглядає як повноцінний чатбот на порталі, який доступний майже 100 тисячам підписників, правда, користуються, зрозуміло, кілька тисяч на тиждень. Технічно це кластер в Google Cloud, де використовується цілий комплекс LLM – питання користувача потрапляє у швидку модель, яка вирішує, наскільки воно складне (і чи треба взагалі відповідати, наприклад, попросити рецепт чізкейка не вийде) і обробляє його для кращого пошуку. Ми її додали, коли в закритому тесті туди зайшов один з тестерів, написав «Привіт» і через 50 секунд отримав відповідь, що в наданих документах відповіді на його питання не міститься.

Після швидкої моделі (практично пишаюся, що придумали router до запуску GPT5) оброблений запит потрапляє в пошук, який шукає у векторній базі, де складений контент порталу, і результати віддає в ще одну LLM для переранжування. Ми тестували в різних конфігураціях і в підсумку прийшли до того, що пошук збирає до 100 документів (схожих і відповідних ключовим словам), після переранжування залишається 25 кращих, які й відправляються разом з довгим промптомом у фінальну LLM для генерації відповіді.

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

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

Перед висновками й узагальненнями підкреслю – в цьому проєкті зайняті рівно три людини. Я – як менеджер продукту і керівник розробки, топменеджер порталу – як маркетолог (хтось же повинен був наполягати на запуску до січня з певними фічами) і замовник, і головний консультант як експерт з якості системи. Практично весь код написаний, перевірений, протестований і впроваджений (не хочу писати страшне «задеплоен») декількома LLM, головна з яких – Claude, в основному в Claude Code і найчастіше найпотужнішою й останньою версією.

Назвіть це вайб-кодингом, якщо хочете.

Треба, звичайно, сказати, що я не гуманітарій з неясним уявленням про інтернет-сервіси, яким заведено зображати «вайб-кодера». Все ж, свій перший сайт я зробив приблизно 26 років тому, копатися в скриптах на рівні «завантажив, не працює, написав команду, запрацювало, змінив в коді, зламалося, ще раз змінив, запрацювало як треба» я почав 25 років тому і якось весь цей час розбирався з проблемами що виникали й тими завданнями, що ставив собі сам. Багато спілкуючись з розробниками дуже серйозних речей (на кшталт пошуку в інтернеті для мільйонів людей), я, звичайно, не намагався давати поради з області тензорного аналізу, але на рівні застосування розроблених технологій намагався не плавати. І багато з того, що я чув або читав 10-15 років тому, я із задоволенням згадував і застосовував протягом цього року – хоча і повторюю регулярно «Не чекайте, що я вам тут зараз Google напишу».

Тому популярний аргумент «Він (тобто вайбкодер) поняття не має, що там в коді робиться» зі мною не проходить – я знаю, що там робиться принаймні в загальних рисах, причому набагато детальніше, ніж будь-який менеджер і керівник знає, що робиться в коді, написаному програмістом-людиною. Щобільше, на відміну від такого керівника, я можу цей код показати іншій LLM, повернутися до першої, довго тикати курсором і ставити питання «А що тут робиться?» і отримувати максимально докладні відповіді й жодного разу не образити геніального інтроверта-розробника і не дізнавшись, що я знецінюю роботу, при тому, що все одно не розберуся в ній ніколи.

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

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

Я нагадаю аргумент мого колеги з подкасту «Так не пишуть, це неможливо буде підтримувати». Але я і не збираюся це підтримувати. І запрошувати Женю (і кого завгодно ще) підтримувати теж не планую. Те, що код не відповідає чиїмось естетичним вимогам, не робить його неробочим. А те, що проєкт – принаймні, чатбот – активно розробляється більше пів року з регулярним додаванням нових можливостей і оптимізацією, абсолютно точно показує, що підтримувати й розвивати його можна. Просто підтримують його не люди, а AI. За цей час вийшло кілька версій у кожної з провідних LLM, кожну з них я використовував у розробці, і ситуації, коли якась із них заплуталася і я повертався до попереднього стану системи, практично зникли (на початку, особливо до переходу до розробки чат-бота, таке траплялося).

Ба більше – далеко не факт, що цей код взагалі треба підтримувати навіть силами AI. Не хочу зараз глибоко занурюватися в концепцію disposable code, але в більшості випадків може виявитися простіше не розбиратися в наявному коді, а просто переписати його новою версією LLM з нуля.

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

Важливий висновок – в описаних проєктах використання AI в розробці прискорило процес у рази. Я все ж мав відношення до програмних проєктів і точно знаю, що розробити систему від ТЗ до початку розгортання за місяць – це дуже серйозне завдання для команди з людей-розробників. Переведіть час у гроші й ви отримаєте бюджет на кілька місяців і кілька десятків тисяч доларів проти 200-250 доларів на підписку в Claude/OpenAI/Gemini плюс зарплата «оператора» – мені здається, «швидше в рази й дешевше на порядок» буде адекватним результатом порівняння.

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

Підсумки року у вайб-кодингу

Докладна стаття, яка вказує, що людство, обговорюючи питання безпеки та контролю AGI (Artificial General Intelligence, загальний штучний інтелект), коли і якщо такий виникне, упускає можливість появи «клаптикового» або розподіленого AGI, який буде утворений роєм агентів, які окремо не досягають рівня AGI, але разом демонструють розумну поведінку.

Такий собі набір агентів Смітів замість єдиної Матриці.

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

Але давайте тепер боятися розподілених агентів, звичайно.

Чи зможе людина контролювати AGI?

Колись я регулярно писав у блозі про нові браузери – згадуючи і надбудови над IE типу NetCaptor, і бета-версії Firebird (пам'ятаєте взагалі, що так спочатку називався Firefox?). За останні роки, в принципі, картина визначилася – є Chrome, на маках є ще Safari, для любителів залишився Firefox і є ще деяка кількість різних збірок на базі Chromium різного ступеня серйозності.

Мені завжди подобалося використовувати Safari, але дуже бракувало плагінів. Деяку кількість я останнім часом навіть написав сам, але займатися їх перенесенням на Safari не хотілося навіть за допомогою AI. Іноді я все ж намагався переходити на Safari – оскільки на iPad я використовую саме його, то можливості синхронізації місцями допомагали. Але потім все одно повертався на Chrome – іноді це відбувалося через плагіни, а іноді – через споживання пам'яті.

Довгий час я провів на Mac Studio M1 Max з 32 Gb RAM і він, дуже швидкий в момент покупки, в міру використання регулярно нагадував, що 32 ГБ – це зовсім небагато за нинішніх часів навіть для перегляду сайтів і ще пари стандартних процесів. А я людина недовірлива і легко уявляв собі, як могло б бути швидко, якби не цей гігабайт, позначений як swap браузера.

Деякий час тому я побачив Orion – браузер на основі WebKit, який підтримує плагіни і Chrome, і Firefox, і вирішив спробувати. Дійсно, дуже швидко, АЛЕ – в якийсь момент один з процесів браузера починає просто ЖРАТИ пам'ять. До того ж ряд плагінів, які я використовую, працювали, але не до кінця – наприклад, якось не завжди працював LanguageTool, а 1Password відмовлявся використовувати будь-яку авторизацію, крім введення пароля (тобто не розблоковувався через Apple Watch, наприклад).

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

Бажання вибрати найкращий браузер у мене все одно не зникло. Навіть після переходу на MacBook Pro з M4 Pro і 48 Gb RAM (якщо запитаєте, чому не більше, то відповім, що саме ця конфігурація була тут і зараз і за вигідною ціною) мені досі не подобається бачити процеси, що займають багато пам'яті. Тим більше, що мені є куди її витрачати – підключення трьох зовнішніх моніторів через Thunderbolt Hub і вирішення проблем з їх коректним відображенням займає і CPU, і пам'ять.

Ретельний аналіз всіх можливостей показав, що пам'ять люблять взагалі всі. І тому треба вибирати ті, що люблять її хоча б трохи менше. На подив, фіналістів виявилося двоє, обидва на базі Chromium – Brave і Microsoft Edge. Якщо коротко, то у Brave під девізом приватності та безпеки блокування трекерів і реклами вбудовано в ядро, а не реалізовано плагіном, що дозволяє не приховувати, що не треба, а просто не завантажувати ресурси браузера зайвими запитами. При цьому всі плагіни працюють точно так само, як і в Chrome, тому що це ж Chromium. А Edge краще оптимізований для слабких систем і активніше управляє ресурсами. Але, на жаль, блокувати рекламу і трекери доведеться розширенням, тож виграш на потужній машині може бути слабо відчутним.

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

Загалом, я вже кілька тижнів живу на Brave і, в принципі, цілком задоволений. Правда, деякі розробники сайтів все ж примудряються зробити щось абсолютно монструозне – наприклад, сайт колишнього Twitter постійно розпухав в пам'яті до 2 гігабайт. З ним довелося справлятися окремо – зробити з вкладки додаток, додати Control Plane for Twitter і вичистити частину фіч.

А ось повторити процес з iPadOS не вийшло. Я часто використовую iPad, причому разом з клавіатурою, і хочу мати там швидкий і зручний браузер. Я, звичайно, знаю, що можливості розробників на мобільних платформах Apple обмежені, але мене б цілком влаштував той самий інтерфейс, синхронізація з десктопним браузером і можна навіть без плагінів.

Не тут-то було. Так, якась синхронізація у Brave for iPad з десктопним Brave є. Але сам браузер, м'яко кажучи, працює дивно. Наприклад, у новій вкладці завжди показується тільки вибране – хоча на десктопі є вибір між вибраним і часто відвідуваними сайтами. При заході на сайт Brave for iPad завжди запитує мобільну версію, і побачити щось звичне можна тільки окремим запитом. Ні, способу налаштувати «Завжди запитувати десктопну версію» я не знайшов. Найдивніше і реально дратує – всі браузери при відкритті нової вкладки, якщо підключена клавіатура, ставлять фокус в поле введення адреси сайту. Всі, але не Brave – вам треба окремо ткнути пальцем в екран, щоб почати цю незвичайну операцію набору адреси сайту з клавіатури. І це чемпіон серед браузерів на iPad за непомітністю кнопки нової вкладки – у всіх цей «плюс» добре помітний і в нього легко влучити пальцем, а у Brave він дуже невеликий, сірий на світло-сірому тлі і приліплений до крайньої вкладки. З огляду на те, що всі крипто-AI-штуки вони якраз вліпили і треба ходити це все відключати, я з цікавістю почекаю пояснень, як обмеження Apple не дають зробити хороший браузер.

Загалом, не так вже й хотілося цієї синхронізації – не настільки, щоб мучитися з цими дивацтвами. Поживу далі на Safari на iPadOS. А на десктопі – так, я цілком задоволений вибором Brave. Особливо, якщо там відключити криптогаманці, інтеграцію і дивний AI.

Вибори браузерів

Я вже приблизно рік займаюся декількома AI-проєктами, в тому числі RAG-ботом (Retrieval-Augmented Generation), і весь час дізнаюся для себе щось нове. Чому б не поділитися?

Розробка RAG-чатбота вважається простим завданням – багато хмарних платформ, від OpenAI до Cloudflare, пропонують навіть готові рішення, де все можна налаштувати кліками у вебінтерфейсі. Та й для власної розробки немає особливих проблем – візьміть базу знань, розділіть її на невеликі фрагменти, однорідні за змістом (наприклад, питання-відповідь або розділ у великому документі), обчисліть для цих фрагментів векторне представлення (embeddings, у найпростішому випадку це дуже дешево робиться через запит до API, наприклад, OpenAI або Google), збережіть у спеціальному вигляді бази, яка називається «векторною», і чекайте на запитання користувача. Отримане питання теж перетворюєте в ембеддінг і тепер на запит з ним векторна база поверне вам результати, найбільш схожі (similar) на поставлене питання. Залишається сформулювати запит до LLM буквально такого змісту «Ти фахівець служби підтримки (або консультант, залежно від завдання), ось питання користувача, ось що ми знаємо на цю тему, сформулюй відповідь».

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

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

Причина цього дуже проста – хоча векторна схожість, на відміну від точного входження, і враховує семантику запиту, але все ж вона не може знайти результат, де всі або багато слів запиту представлені синонімами, наприклад. Тобто, якщо питання ставить простий користувач, а у вашій базі відповіді суперфахівців, сформульовані в абсолютно точних спеціальних термінах, пошук поверне щось випадкове – просто нічого схожого на питання «А як мені зробити так, щоб у мене швидко працював вай-фай» у вашій базі, де докладно пояснено, які канали Wi-Fi 2,4 GHz частіше зазнають впливу інтерференції в щільній міській забудові, може і не знайтися. Можливо, розумна LLM в результаті якось відповість без будь-яких підказок у промті, але досить часто, щоб виключити ймовірність галюцинацій, їй забороняють користуватися власними знаннями та використовувати тільки зміст контексту, а там випадкові результати.

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

Що можна зробити? Звичайно, є варіант зробити пошук гібридним. Тобто проіндексувати базу ще й з побудовою традиційного пошукового індексу і при пошуку за схожістю паралельно шукати за ключовими словами, об'єднуючи ці результати надалі. Але чи можна сам пошук за схожістю зробити кращим?

Виявляється, можна, і це досить нескладно з погляду логіки. Якщо у нас немає ідеального документа для пошуку, давайте його вигадаємо. Техніка HyDE (Hypothetical Document Embedding) працює саме так: перш ніж стукати в базу, ми просимо швидку LLM згенерувати гіпотетичну відповідь на питання користувача. Нам не потрібна фактична точність – нехай модель галюцинує, головне, щоб вона використовувала правильну термінологію і структуру. Замість питання «чому гальмує вай-фай» ми перетворюємо на вектор згенерований пасаж про «інтерференцію каналів і діапазон 2,4 ГГц». Векторний пошук, отримавши такий «м'ясний» контекст, знаходить реальні документи набагато точніше. Результат стає помітно кращим з двох причин. Така гіпотетична відповідь довша за питання, тому ви відсікаєте випадкові збіги у випадку коротких запитів. Плюс LLM набагато краще розуміє сенс питання, а не тільки схожість, і видає вам проєкт відповіді в тих термінах, які використовуються в документах бази. Цим ліквідується той самий розрив між лексикою користувача і документів.

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

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

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

Ось така цікава техніка. Чудово спрацювало в нашому випадку, коли з'ясувалося, що питання користувачів на бухгалтерські та податкові теми, звичайно, схожі на консультації професійних експертів, але зовсім не збігаються з текстами законів і постанов уряду. Ми в результаті додали й HyDE, і пошук за ключовими словами (і переранжування) – і в підсумковий промпт стали набагато частіше потрапляти нормативні документи, а підсумкова розмірковуюча модель стала генерувати приблизно на 25% кращі (за оцінками людей-експертів) (повні та правильні) відповіді.

Stay tuned, у мене ще багато неочевидних знахідок у запасі.

Гіпотетично, відповідь така…

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

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

Тепер TheInformation пише, що DeepSeek тренує наступну модель на Nvidia Blackwell – тобто чіпах вже наступного покоління, які постачати до Китаю навіть не планується.

Схема постачання, описана джерелами, заслуговує на окрему екранізацію. Створюються «фантомні дата-центри» в Південно-Східній Азії, закуповується легальне обладнання, проходить офіційний аудит від Nvidia або Dell. Після чого сервери розбирають до гвинтика і ввозять до Китаю як запчастини. Причому контрабандисти віддають перевагу системам з 8 чіпів, а не передовим стійкам NVL72 вагою в півтори тонни – логістика диктує архітектуру, у валізі стійку не вивезеш.

Тим часом DeepSeek робить ставку на метод sparse attention для зниження вартості інференсу. Саме архітектура Blackwell містить апаратне прискорення для таких обчислень, що дає двократний приріст продуктивності.

Ось так і виглядає реалізація кіберпанку.

Китайські пригоди GPU Nvidia

Натрапив на статтю в блозі Semrush про те, що золота ера SEO закінчується, AI в результатах пошуку Googel дає все більше відповідей без кліків на сайти, а AI-чати (ChatGPT або Claude) вважають за краще давати посилання на великі бренди. В результаті малий бізнес, який досі сподівався на пошукову оптимізацію і контент-маркетинг, отримує все менше трафіку і що далі робити – невідомо.

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

Можливо, спільність рекомендацій пов'язана, зокрема, і з відсутністю у Semrush готового сервісу, на який можна вказати пальцем і сказати «користуйтеся!». Але в цілому, я б назвав розвиток ситуації справедливим.

Чим, по суті, було пошукове просування для малого бізнесу останні, мабуть, 10 років, якщо не більше? Буквально два напрямки, обидва в міру сумнівні – розставляння посилань і контент-маркетинг. З посиланнями приблизно і так зрозуміло – те, що починалося з абсолютно добровільного обміну або цитування, давно виродилося в агресивну тактику закидання пропозиціями розмістити гостьовий пост, розмістити посилання десь в тексті, поміняти посилання в тексті 10-річної давнини та поставити там замість оригіналу посилання на інший сервіс «майже такий самий, але інший» – загалом, напевно знаєте, про що йдеться. Але що не так з контент-маркетингом?

Та приблизно все не так. Ось є сайт невеликого магазину або невеликої компанії. Контенту на ньому у звичайному випадку не те щоб багато – сторінки товарів, оплата/доставка, «Про нас», що ще може бути в магазині? Але тут приходить контент-маркетолог і розповідає, що не буде ніяких продажів без контент-маркетингу – тобто нових статей пару раз на тиждень на теми, пов'язані зі сферою магазину. Без цього, авторитетно пояснює маркетолог, не буде ні репутації магазину, як видатного у своїй ніші, ні пошукового трафіку, оскільки що тут індексувати пошуку?

Але поставте себе на місце власника магазину. Де він візьме матеріал на дві статті на тиждень? Про що писати? Хорошу статтю написати не дуже просто, навіть якщо у вас є матеріал. А у якої кількості магазинів і бізнесів взагалі є якийсь унікальний досвід, гідний статті? Ви знаєте, що виходить в результаті – численні статті-сміття «Топ-10 чого завгодно», де на першому місці наведено бездоганний продукт автора, а далі всілякі негідні конкуренти, або «Поради початківцям кому завгодно», хоч сантехнікам, хоч ядерним фізикам. Пройдіться по сайтах SaaS-продуктів – вони всі забиті регулярними статтями на абсолютно загальноосвітні теми, часто скопійовані або в інших, або з Вікіпедії. Це була епоха великого рерайту, що тут приховувати?

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

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

Майбутнє SEO

Сем Альтман оголосив всередині OpenAI режим «code red». Три роки тому рівно ту ж фразу використовували в Google, реагуючи на реліз ChatGPT. Тепер ролі помінялися: Google Gemini з його 650 млн користувачів та інтеграцією в пошук став реальною загрозою, змусивши піонера ринку перегрупуватися.

Заради утримання лідерства OpenAI ставить на паузу запуск реклами (про яку офіційно не оголошували, але активно тестували) і розробку AI-агентів. Фокус зміщується на поліпшення базового продукту: персоналізацію, генерацію зображень і, що примітно, боротьбу з overrefusals.

Треба ж, всього місяць минув, як я розповідаю, що Gemini мені замінив OpenAI, а Сем вже реагує. Втім, серйозно кажучи, Google – це дійсно загроза, оскільки моделі у Google гарні та він їх дуже грамотно розгортає, причому у формі, зрозумілій користувачам.

Я підозрюю, що ми ще побачимо OpenAI з антимонопольними заявами на адресу Google – мовляв, використовує становище на ринках пошуку та браузерів для просування свого AI.

OpenAI перегруповується через конкуренцію з Google

Ілля Суцкевер прийшов на подкаст до Дваркеша Пателя і повторив свою тезу про завершення епохи масштабування. За його словами, з 2020 по 2025 рр. індустрія жила за простим рецептом – більше даних, більше обчислювальних потужностей, передбачуваний результат. Тепер дані для pre-training закінчуються, і ми повертаємося в «епоху досліджень», тільки з великими комп'ютерами.

Ілля цікаво пояснює парадокс сучасних моделей, які блискуче проходять складні бенчмарки, але в реальному vibe coding чергують один і той же баг туди-сюди. Суцкевер пропонує витончену аналогію: студент, який 10000 годин тренувався на спортивне програмування, вивчив всі алгоритми, але узагальнює і застосовує абстрактні знання гірше за того, хто витратив 100 годин і просто має «it factor». Поточний RL по суті повторює першого студента – компанії черпають натхнення з бенчмарків для навчання моделей.

SSI (компанія Іллі) при цьому позиціюється як компанія без продукту, яка вибирає стратегію «прямого пострілу» (straight shot) до суперінтелекту, минаючи випуск проміжних продуктів. Мета SSI – створити не просто систему, яка «знає все», а систему, яка здатна навчитися будь-якій роботі так само швидко і якісно, як людина, а потім перевершити її. Як здається Суцкеверу, люди володіють якоюсь технологією навчання, яку ще не змогли реалізувати в моделях.

При цьому він вважає, що досягнення суперінтелекту може не вимагати великих бюджетів – зрештою, трансформери були розроблені на кластерах, що складаються з 8 до 64 GPU. Компанії більше грошей витрачають на інференс. Хоча це звучить іронічно, враховуючи 3 млрд інвестицій, вже отриманих SSI, але вже як є.

Повернення від швидкого масштабування AI до досліджень

Вихідні в соціальній мережі, раніше відомій як Twitter, пройшли під знаком нової функції – About this account.

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

Звичайно, у більшості акаунтів там нічого цікавого – країна, де вони реально знаходяться, національний AppStore або Google Play. Але відразу стали з'являтися цікаві результати. Наприклад, багато акаунтів, що просувають ідеї MAGA (Make America Great Again), чомусь знаходяться не в Америці:

Жителі Гази, які страждають від бомбардувань ізраїльської військової машини, вважають за краще робити це в Індонезії:

Що зовсім не дивно – більшість проросійських акаунтів знаходяться в Європі. Втім, багато з них мають позначку, що свідчить про підключення через VPN, що зрозуміло – адже пряме з'єднання з сервісом в рф заблоковано.

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

Джерело https://x.com/DrEliDavid/status/1992706976439238783/photo/1

Але, на жаль, низький поріг входу в інтернет – точніше, низький поріг входу буквально в усе завдяки інтернету, – зіграв і тут свою роль. Постійні читачі та слухачі мого подкасту, можливо, пам'ятають епізод, коли розбирав «аналітику» за профілями в LinkedIn, де авторка робила висновок, що компанія Notion має офіси в Росії й навіть в Ірані(!). Все через те, що якась кількість із сотень мільйонів користувачів цієї соцмережі вказали, ніби вони працюють в Notion (був навіть trader в Notion). А будь-який «аналітик» знає, що все написане в інтернеті – свята правда.

Український сегмент інтернету вважав за краще вхопитися за профіль Михайла Подоляка, політтехнолога і радника глави Офісу Президента України, який часто виступає з офіційними коментарями – у нього, розумієте, в профілі вказаний російський AppStore.

Що бачить середньостатистичний «аналітик» на цьому скриншоті? Що власник акаунта зареєструвався в соцмережі в лютому 2022 року з Росії. Адже інших дат тут немає, а Russian Federation – ось вона. Звідки з’являється ця інформація, такі «аналітики» не знають – і їх це абсолютно не хвилює.

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

Дивлячись на нього, наш аналітик явно вирішить, що я зареєструвався у 2007 році з США. Але це просто неможливо. Справа навіть не в тому, що вперше в США я побував у 2011 році. На цей смішний аргумент всезнайко мешканець соцмереж заявить, що все можна підробити, включаючи записи DHS (Department of Homeland Security, що контролює в'їзд до США), а ось скриншот із соцмережі – це істина з істин. Але у 2007 році у цієї соцмережі просто не було мобільних додатків – офіційні додатки Twitter з'явилися тільки у 2010 році. А запис про американський AppStore пояснюється набагато простіше – мій акаунт дійсно зареєстрований там і всі ці роки я його поповнюю за допомогою подарункових сертифікатів, причому останнім часом купую їх прямо на сайті Apple.

І я зовсім не виняток. Просто нормальний аналітик, який починає з вивчення фактів, а вже потім намагається зробити висновки, швидко натрапить на факт – AppStore в Україні запустився досить пізно, влітку 2012 року. Перші iPhone з'явилися в Україні восени 2007-го – пам'ятаєте, ті, які треба було розблоковувати, вставляти дивні сім-карти й так далі? Вже до 2011 року iPhone продавався повним ходом, часто з'являючись у продажу через тиждень після старту продажів у США, а iPad мені привезли практично відразу.

І, якщо просто пошукати в інтернеті, нескладно знайти численні статті «Як завести безплатний акаунт в AppStore», де детально описувалося, як вказати реальну адресу в США, відмовитися від прив'язки будь-якої карти та де купити gift card для поповнення рахунку.

У 2012 році, практично перед відкриттям AppStore, я навіть проводив опитування «Хто яким магазином користується?». Результати досі є в цьому самому блозі.

Опитування користувачів, травень 2012 року, показані тільки голоси користувачів з України

І це результати опитування в моїх акаунтах – тобто, загалом кажучи, сильно перекошена в бік гіків вибірка (до речі, чомусь більшість «аналітиків» не знають слова «вибірка», не кажучи вже про термін «генеральна сукупність»). А якщо хтось покопається в пам'яті, то легко згадає, що у всіх магазинах, які торгували iPhone в ті роки, до обов'язкових перехідників під наші розетки, були також рядки в прейскуранті «Реєстрація в магазині та встановлення додатків». Основна маса покупців, які не мали друзів-гіків, в результаті отримувала готовий телефон з якимось акаунтом та вже встановленими додатками, й взагалі не знала, як їх встановити самостійно. Чому б це Подоляку відрізнятися від них, він що, не народ? Гуманітарію-політтехнологу принесли готовий до використання телефон, переставили з попередньої люксової Nokia сім-карту і він почав по ньому дзвонити. А в лютому 2022 року знадобилося піти в Twitter – зареєструвався і почав писати.

Але навіщо вивчати факти, якщо можна розвести істерику в соцмережах і зібрати лайки?

Аналітика міленіалів

Google представила Gemini 3 – модель, яка, за їхніми словами, наближає компанію до AGI (Artificial general intelligence). З цього приводу в блозі цілий вибух матеріалів, оскільки Google починає впроваджувати її в усі свої продукти. Модель показує вражаючі результати на бенчмарках – 1501 Elo на LMArena, 91,9% на GPQA Diamond, 45,1% на ARC-AGI-2 в режимі Deep Think. Остання цифра особливо цікава, враховуючи, що цей бенчмарк створювався як перевірка на здатність до абстрактного мислення.

Я поки що бачив модель тільки в AI Studio, у звичайному Gemini її немає, хоча випуск, здається, вже почався. Будемо тестувати – треба сказати, що у мене Gemini замінив ChatGPT, а Deep Think дуже допоміг за тиждень використання.

Модель не відрізняється параметрами від попередньої версії – дата закінчення знань – січень 2025 року. Як і у 2.5 Pro, насправді вона навіть раніше, факти другої половини 2024 року їй невідомі. Розмір контексту – 1 млн токенів, 64K на вихід. А ось ціна в API дорожча – $2 на вхід до 200 тис. токенів, $4 – якщо промпт більше 200 тис., а видача $12 і $18 за млн токенів відповідно.

Зверніть увагу, що Flash моделі поки немає – попередню версію запускали інакше.

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

***

Разом з анонсом Gemini 3 Google представив Antigravity – це нова агентська платформа розробки, на додаток до Gemini CLI. Насправді Google зробив власну версію Cursor/Windsurf. Звичайно, на базі VS Code, з Gemini та агентами. Можна спробувати, тим більше, що там абсолютно безплатно. Але поки що цікавіше те, що там вже є Gemini 3 Pro. Причому з різним бюджетом на роздуми.

Gemini 3 – крок до загального штучного інтелекту?