Ми побудували Ferrari для ШІ аналітики. 81% часу на ній їздять за картоплею

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

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

А потім ми подивились у телеметрію.

81% запитів користувачів — це простий SELECT з однієї таблиці. Фільтр, сортування, максимум LIMIT. Ані віконних функцій, ані CTE, ані хитрих підзапитів, під які ми проєктували систему.

Перша реакція команди — щось між сміхом і образою. Друга — а давайте розберемося, про що ця цифра говорить насправді. Чи це провал «революції ШІ в аналітиці», чи навпаки — її найчесніший доказ? Про це й стаття. Спойлер: однозначної відповіді не буде, і це принципова позиція.

Що саме ми будували

Спершу контекст, бо без нього цифри висять у повітрі.

Наш продукт — аналітичний воркспейс з ШІ. Користувач підключає свої джерела даних: CRM, білінг, тікети, маркетингові платформи — через MCP-конектори. Далі ставить запитання людською мовою: українською, англійською, як зручно. LLM перекладає запитання в SQL, виконує його, повертає таблицю або графік.

Під капотом — все, що належить мати такій системі у 2026 році:

• семантичний шар з бібліотекою метрик, щоб «виторг» і «revenue» означали одне й те саме у всіх звітах;
• Python-виконавець для випадків, коли SQL не вистачає: прогнози, когортний аналіз, кастомна математика;
• роутинг між моделями, кешування, контроль вартості токенів — усе, чого вчить перший же місяць продакшену з LLM;
• валідація згенерованого SQL перед виконанням, бо модель, яка галюцинує назву колонки, — це не екзотика, а вівторок.

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

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

Звідки цифри і як ми рахували

Методологія проста і відтворювана — можете повторити на своїй системі.

Ми взяли SQL, який наш ШІ-аналітик згенерував за останні шість місяців: десятки тисяч запитів від реальних користувачів. Не демо, не внутрішні тести, не бенчмарки — продакшен. Кожен запит прогнали через класифікатор складності на основі AST: парсимо SQL і дивимось, що всередині.

Чотири категорії:

1. Простий SELECT — одна таблиця, WHERE, ORDER BY, LIMIT. Все.
2. SELECT + JOIN — дві-три таблиці, з’єднання за ключами.
3. Агрегації — GROUP BY, SUM/COUNT/AVG, HAVING. Те, що зазвичай і називають «аналітикою».
4. Складна аналітика — віконні функції, підзапити, CTE, self-join. Те, під що ми будували систему.

Розподіл вийшов такий:

81% — SELECT з однієї таблиці. Ще 11% — JOIN двох-трьох таблиць. На «серйозну» аналітику лишається 2%.

Вісім з десяти питань до нашої системи виглядають ось так:

Питання людською мовою → шість рядків SQL, які студент пише на першому місяці курсу.

Чесно? Коли бачиш це вперше — боляче. Ми будували машину для складних питань, а люди питають «скільки клієнтів купили у червні».

Які це запити наживо

Абстрактні відсотки — це нудно, тому ось реальні приклади з логів (перефразовані, щоб нікого не деанонімізувати):

Помічаєте патерн? Перші три запитання — це не «аналітика» у класичному розумінні. Це операційні питання: людині треба цифра прямо зараз, щоб ухвалити рішення або відповісти клієнту. Не дослідження — довідка.

І таких — вісім з десяти.

Може, юзери просто ще не розкуштували?

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

Ми чекали пів року. Дані кажуть — ні:

Частка простих запитів коливається між 79% і 84% — і нікуди не дінеться.

Жодного тренду вниз. І ми не просто чекали — ми активно намагались «розігнати» користувачів:

• додали підказки складних питань прямо в інтерфейс («а спробуйте порівняти когорти»);
• зробили бібліотеку готових метрик, щоб складне питання можна було поставити одним кліком;
• писали онбординг-листи з прикладами «просунутих» сценаріїв.

Ефект? Частка складних запитів зросла з 1,6% до 2,1%. У межах шуму.

Висновок, який довелось прийняти: прості питання — це не стадія онбордингу. Це і є основний сценарій використання. Крапка.

А тепер найцікавіше: хто питає

Розріз за ролями розставляє все на місця:

83% запитів — від людей, які ніколи в житті не відкривали SQL-консоль.

Сейлзи, маркетинг, менеджмент, support. Люди, для яких раніше «подивитись у дані» означало одне з двох: або тицьнути у застиглий дашборд, де потрібного розрізу немає, або написати аналітику і чекати. День. Два. Тиждень — якщо у аналітика спринт.

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

Тепер він ставить 15–20 запитань на день. Всі — «прості». І всі 15–20 раніше не існували.

І ось тут цифра 81% перестає бути простою.

Про що насправді говорить ця тенденція

Є два способи прочитати наші дані, і вони обидва правдиві. Саме тому я не дам вам готового висновку.

Прочитання песиміста. Ми (і пів індустрії разом з нами) будуємо дорогі LLM-системи, щоб виконувати роботу, з якою справляється SELECT за $0. Кожне таке питання коштує токени, інференс, семантичний шар, валідацію — щоб згенерувати те, що джун пише за 30 секунд. «Революція в аналітиці» на практиці — конвеєр тривіальних запитів. Дашборд із п’ятьма фільтрами закрив би 80% потреб дешевше і надійніше. Якщо ШІ і пришвидшує роботу, то не ту, яку ми собі уявляли, коли малювали архітектуру.

І в цьому прочитанні є неприємна правда про індустрію: ми любимо розповідати про agentic workflows і reasoning-моделі, а мовчазна більшість використання — це «покажи табличку».

Прочитання оптиміста. А тепер питання на засипку: скільки з цих 81% запитів існувало б без ШІ? За нашими спостереженнями — майже жодного. Ці питання або не ставилися взагалі («і так приблизно знаю»), або вмирали у черзі до аналітика, або жили у застарілому Excel, який раз на тиждень вивантажував колега.

Сейлз не піде вчити SQL заради одного запиту. Ніколи. Вхідний квиток у «просто подивитись у дані» коштував: знати, що таке SELECT, WHERE і чому JOIN повертає дублі. Цей квиток був занадто дорогим для 83% людей у компанії — і вони жили на відчуттях.

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

Тобто ШІ не замінив складну аналітику. Він створив ринок для простої — той, якого раніше просто не існувало.

А що з тими 2%?

Окремо про складну аналітику, бо тут теж є чесна цифра.

На складних запитах LLM досі помиляється відчутно частіше. Простий SELECT наша система генерує правильно у понад 95% випадків. Складний запит з віконними функціями — суттєво рідше: модель плутає межі вікон, губить умови в підзапитах, вигадує оптимістичні JOIN. Саме тому в нас є валідація, самоперевірка і можливість подивитись згенерований SQL очима.

Іронія в тому, що 2% складних запитів ставлять якраз ті 17% технічних користувачів — які можуть прочитати SQL і помітити помилку. Нетехнічні користувачі ставлять питання, на яких модель майже не помиляється. Система виявилась самозбалансованою, хоча ми це не проєктували.

Висновок для тих, хто будує подібне: страшилка «LLM згенерує неправильний SQL і менеджер ухвалить рішення на хибних даних» на нашому обсязі виявилася перебільшеною — саме тому, що менеджери не ставлять питань, на яких модель ламається. Але валідацію все одно робіть.

Економіка питання

Тепер про гроші, бо «просто це чи складно» — питання друге, а «скільки це коштує» — перше.

Коли 81% запитів прості — це добра новина для юніт-економіки. Простий запит означає короткий промпт, короткий згенерований SQL і жодних ітерацій. Такі запити ми маршрутизуємо на дешевші моделі: різниця у вартості інференсу між флагманською і компактною моделлю — порядку, а якість на простих SELECT — однакова. Складні запити йдуть на важку модель, але їх 2%.

Груба арифметика виглядає так: середня вартість простого запиту в токенах у нас у 8–12 разів нижча за складний. У підсумку 81% трафіку генерує менше ніж третину витрат на інференс. Решту з’їдають складні запити, ретраї та контекст семантичного шару.

Мораль для тих, хто рахує ROI таких систем: не діліть витрати на кількість запитів рівномірно. Розподіл складності — це і розподіл вартості, і вони обидва нерівномірні до непристойності.

То пришвидшує ШІ роботу чи ні?

Чесна відповідь: залежить від того, чию роботу міряти.

Роботи аналітика — майже ні. Складні запити як вимагали людину, так і вимагають. 2% наших запитів — це та сама складна аналітика, і там LLM досі потребує нагляду. Аналітик у 2026 році не став непотрібним — він перестав бути диспетчером довідок.

Робота всіх інших — так, і суттєво. Година очікування перетворилася на 20 секунд. Питання, які вмирали, — почали ставитись. Помножте на 83% нетехнічних користувачів — і вважайте самі.

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

На нашому обсязі — виправдовує. На вас може бути інакше.

Що ми змінили у продукті після цих цифр

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

1. Роутинг за складністю. Класифікатор питання вирішує, яка модель його обробляє. Прості — на компактну модель, складні — на важку. Мінус відчутна частка рахунку за інференс.
2. Швидкість понад усе для простих запитів. Якщо 81% взаємодій — «покажи табличку», то час до таблички — головна метрика продукту. Ми зрізали latency простого сценарію вдвічі — і це дало більше задоволених користувачів, ніж будь-яка «розумна» фіча за рік.
3. Підказки стали простими. Ми прибрали з онбордингу «спробуйте когортний аналіз» і поставили «спробуйте: топ клієнтів за місяць». Конверсія в перший запит зросла.
4. Складне — за руку. Для тих самих 2% ми ведемо користувача через уточнення: система перепитує, що саме людина має на увазі, перш ніж генерувати важкий SQL. Менше помилок, менше ретраїв.

Узагальнення, якщо ви будуєте щось подібне: проєктуйте під розподіл запитів, який буде, а не під той, що у вашому пітчі. А буде — 80% простих. Тепер ви попереджені.

Замість висновку

Ми йшли будувати систему, яка відповідає на складні питання. А побудували систему, яка нарешті дозволила людям ставити прості.

Два роки тому я б сказав, що це провал. Сьогодні я думаю інакше: складні питання завжди мали кому поставити — для них були аналітики, SQL-консолі, дата-команди. А от прості питання десятиліттями не мали каналу — вони були занадто дрібними для тікета аналітику і занадто складними для дашборда.

ШІ не зробив складне простим. Він зробив просте — доступним. І, можливо, саме у цьому була справжня обіцянка, просто ми її не так прочитали.

А як у вас?

• Якщо у вас є text-to-SQL або ШІ-аналітик у проді — який у вас розподіл складності запитів? Цікаво, чи наші 81% — це закономірність чи особливість нашої аудиторії.
• Як ви рахуєте ROI таких систем: за складністю запитів чи за кількістю людей, які нарешті почали користуватися даними?
• І філософське: якщо 8 із 10 питань до даних — прості, може, проблема ніколи не була в інструментах, а у вхідному порозі?

Пишіть у коментарях — подискутуємо.