ШІ у всьому: коли ярлики стали дурнішими за функції

Коли ярлики випереджають функції

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

• Жорстко закодований рушій правил з новою маркетинговою фразою.
• Виклик API постачальника, де ви не контролюєте поведінку моделі, зберігання даних або ритм релізів.
• Локально розміщена модель з рахунком за GPU і проблемою черг.
• Функція, що раніше була детермінованою, а тепер має оцінку впевненості і знизування плечима.

Ярлики важливі, тому що вони змінюють прийняття рішень. Коли щось позначено «ШІ», команди приймають режим невдач, яких ніколи б не допустили в інших випадках: недетермінованість, часткова коректність, раптові регресії через upstream-зміни та вихід, який неможливо легко пояснити аудиторам чи клієнтам.

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

Ось операційна позиція, що зберігає вам роботу: розглядайте «ШІ» як деталь реалізації, а не категорію продукту. Вимагайте тієї ж суворості, яку вимагаєте від будь-якої критичної залежності: явні SLO, тестовані критерії прийнятності, плани відкату, граничні витрати та заходи безпеки.

Цитата, яку варто мати під рукою, бо вона завжди правда: «Надія — не стратегія.» — Rick Page.

Чому ярлик небезпечний

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

Більшість «ШІ-функцій» провалюються з нудних причин:

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

Жарт №1: Ми називали це «підсилено ШІ» до першого інциденту, коли воно стало «тимчасово правилове для стабільності».

Що означає «реальна функція» в продакшні

Реальна функція має:

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

«ШІ» не усуває цих потреб. Воно їх множить. Тепер у вас є стохастичний компонент з тонкими режимами відмов: він повертає щось, але не те, що потрібно, і робить це впевнено. Це не 500‑й. Це тиха корупція даних у людській мові.

Факти та історичний контекст, що важливі в оперуванні

Багато хто вважає сучасний момент «ШІ у всьому» безпрецедентним. Це не так. Технологія відносно нова; хайп — класичний. Кілька конкретних фактів допоможуть вам аргументовано виступати в кімнатах, де люблять слогани:

1. Термін «штучний інтелект» з’явився в 1956 році на семінарі в Dartmouth. Брендинг був амбітним з самого початку, задовго до того, як існували продакшн-системи, щоб його оцінити.
2. ШІ переживав кілька «зим» (особливо в 1970‑х і кінці 1980‑х/на початку 1990‑х), коли фінансування зникало після невиправданих обіцянок. Хайп циклічний; операційний борг — постійний.
3. Експертні системи панували в підприємницькому ШІ у 1980‑х: правила, бази знань і крихке супроводження. Сьогоднішнє «prompt engineering як бізнес-логіка» тривожливо схоже — тільки більше токенів і менше гарантій.
4. Відродження backpropagation у 1986 році (Rumelhart, Hinton, Williams) нагадує, що прориви можуть чекати, поки комп’ютерна потужність і дані зроблять їх практичними. Практичність — це обмеження ops, а не філософії.
5. Момент ImageNet у 2012 році (глибинне навчання перевершило попередні методи зору) був не лише про алгоритми, але й про GPU та датасети. Ваша «ШІ‑функція» — ймовірно історія ланцюга постачання: чіпи, пропускна здатність, зберігання й аптайм постачальників.
6. Трансформери (2017) зробили великі мовні моделі масштабованими, але також поставили витрати на інференс і затримку в перший ряд продуктового компромісу. Якщо ви не можете витримати p99, у вас немає функції.
7. Продуктивність моделі не монотонна з часом. Розгорнуті моделі можуть погіршуватися через зміну поведінки користувачів, мовні зсуви, сезонність або дрейф upstream‑пайплайнів. Звичайне програмне забезпечення рідко «гниє» так.
8. Регулювання «ШІ» пришвидшується у багатьох юрисдикціях, отже походження, пояснюваність і аудиторські сліди — більше не «корпоративні додатки»; це необхідні умови для середовищ з керованим ризиком.

Фреймворк прийняття рішень: що випускати, що забороняти, що вимірювати

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

Не «як додати ШІ». Формулювання проблеми має бути зрозумілим без букв Ш і І. Приклад:

• Добре: «Зменшити середній час до вирішення, підсумовуючи хронологію інцидентів з логів і тікетів.»
• Погано: «Додати AI‑асистента в NOC.»

Якщо ви не можете записати критерії успіху як тест — ви збираєтесь випустити демо. Демо — окей. Їх місце в пісочницях з жорсткими вимикачами.

Визначте клас функції: детермінована, ймовірнісна або консультативна

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

• Детермінована функція: один і той самий вхід дає той самий вихід. Можна кешувати. Можна логічно міркувати. Чудово.
• Ймовірнісна функція: виходи варіюються, впевненість важлива, коректність — статистична. Потрібні скоринг, моніторинг і запобіжні заходи.
• Консультативна функція: система підказує; людина або детермінований шлюз приймає рішення. Тут має бути більшість «ШІ у всьому», поки не доведено безпеку.

Зробіть це вимірюваним: випускайте з «метрикою результату» і «метрикою шкоди»

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

• Приклади метрик результату: коефіцієнт відмови (support deflection), час до завершення (workflow), підвищення конверсії (commerce), зекономлений час на тікет (ops).
• Приклади метрик шкоди: неправильні повернення грошей, невірно маршрутизовані високосерйозні тікети, порушення політик, витік PII, відтік клієнтів через абсурдні відповіді.

Потім додайте обмеження:

• Бюджет латентності: цілі p50/p95/p99.
• Бюджет помилок: пороги доступності і коректності.
• Бюджет витрат: витрати на запит і місячний ліміт з оповіщеннями.

Архітектуруйте для відмов, а не на відчуттях

«ШІ у всьому» часто означає «нова мережна залежність у всьому». Ось як виникають каскадні відмови. Ставтесь до ШІ‑компонента як до ненадійного upstream:

• Таймаути з розумними значеннями (коротші, ніж ви думаєте).
• Перемикачі (circuit breakers) для скидання навантаження.
• Режим фолбеку, що зберігає основну функціональність.
• Браслети (bulkheads): ізолюйте ШІ‑функцію, щоб вона не виснажувала решту системи.
• Можливість відтворення запитів для офлайн‑оцінки та післяінцидентного аналізу.

Жарт №2: Наша «ШІ‑доріжня карта» була настільки амбітною, що нам довелося додати новий рівень до таксономії інцидентів: «Sev‑2, але філософський».

Не плутайте «кмітливість» з «надійністю»

Команди люблять кмітливі рішення. Користувачі люблять надійність. Керівники люблять квартальні показники. Ваше завдання — доставляти все три, ставлячи надійність попереду новизни. Найпростіший шлях: вимагайте від кожної ШІ‑функції недетермінованого фолбеку, який забезпечує мінімальний UX. Якщо фолбек принижує користувача — добре, тепер ви знаєте, що таке «мінімум» насправді.

Три корпоративні міні-історії з передової

Міні-історія №1: Інцидент через невірне припущення

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

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

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

Операції втрутились заднім числом. Логи показували, що система «здоровa». Латентність нормальна. Рівень помилок нормальний. Інцидент — це коректність, що згнила. Коли вибірково проаналізували помилки маршрутизації, провал став очевидний, але це зайняло дні, бо не було зворотного каналу «ground truth» і базового порівняння. Виправлення було не гламурним: змусити агентів підтверджувати маршрути (advisory mode), зберігати промарковані результати, періодично перевчати і оцінювати щотижня, і додати тривоги за дрейф розподілу міток.

Реальний урок: ймовірнісні системи потребують явної телеметрії коректності. «Немає помилок в логах» — нічого не значить, коли система ввічливо помиляється.

Міні-історія №2: Оптимізація, що бумерангом повернулась

Ритейл‑платформа додала LLM‑функцію «покращувач описів товарів». Вона брала текст від постачальника і приводила в консистентний вигляд. Початкова версія працювала асинхронно і писала результати в кеш. Було повільно, але безпечно: якщо job падав — старий текст залишався. Потім маркетинг захотів це «в реальному часі» в редакторі продукту, щоб люди могли спостерігати за «магією».

План оптимізації виглядав розумно: кешувати промпти й повторно використовувати результати; збільшити паралелізм; зменшити таймаути, щоб UI не зависав. Додали ще одну модель як фолбек. Виміряли p50 і оголосили перемогу.

Що вони пропустили — це p99 під час піку використання редактора. Коли паралелізм підскочив, upstream API почав лімітити. Система отримала таймаути. Повторні спроби підсилювали навантаження. Фолбек‑модель включалась і повертала інший стиль. Користувачі почали зберігати чернетки з непослідовним тоном і, гірше, інколи з «галюцинаціями» щодо технічних специфікацій. Система не була «падінням», вона була «химерною».

Витрати зросли, бо шторм ретраїв підняв використання токенів. Фінанси помітили це раніше за інженерів. Результат ідеальний: гірший UX, вищі витрати і беклог у підтримці через скарги постачальників на некоректні правки.

Виправлення — класична дисципліна SRE: обмежити паралелізм, впровадити jittered exponential backoff з жорсткими бюджетами ретраїв, повернути генерацію в асинхронний режим з явним UX «чернетка готова», і додати шар валідації, що перевіряє вихід за структурними атрибутами товару (розміри, матеріали) перед прийняттям. Також почали моніторити відповіді rate-limit як перший клас SLI.

Міні-історія №3: Нудна, але правильна практика, що врятувала ситуацію

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

Вони створили фіксований тестовий набір запитів з очікуваними цитатами. Кожна зміна моделі або промпта повинна була пройти: відповідь має містити цитати; цитати мають відповідати затвердженим документам; у виводі не повинно бути PII; затримка — у межах бюджету. Також реалізували логування запитів з редагуванням і зберігали ID витягнутих документів разом з відповіддю для аудиту.

Через два місяці upstream‑постачальник моделі змінив поведінку. Не «відключення», а інше форматування виходу і трохи інша схильність до узагальнення. Стенд це помітив того ж дня, бо впала кількість цитат. Команда заморозила реліз, зафіксувала версію моделі де можливо і перейшла в режим фолбеку («Ось документи; без синтезованої відповіді»), поки не перевірила все заново.

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

Плейбук швидкої діагностики: знайдіть вузьке місце за хвилини

Це версія «он‑кол в 2:00 ночі». Вам не потрібна філософія ШІ. Потрібен винуватець.

Перш за все: модель, мережа чи ваша система?

1. Перевірте видимі користувачу симптоми: повільно, неправильно чи падає? Повільно і падіння простіше, ніж «неправильно».
2. Перевірте здоров’я залежностей: ліміти LLM API, таймаути, DNS, TLS, вихідний egress, статус постачальника (якщо є).
3. Перевірте власне насичення ресурсів: CPU, пам’ять, завантаження GPU, глибина черги, пул потоків, пул з’єднань.

По‑друге: визначте домінантну стадію

Більшість ШІ‑функцій — це пайплайн:

• Розбір запиту + аутентифікація
• Побудова промпта або витяг фіч
• Ретрієвал (векторний пошук / звернення до БД)
• Інференс (віддалений API або локальна модель)
• Пост‑обробка (валідація, форматування, перевірки політик)
• Запис/кешування

Заміряйте час кожної стадії. Якщо не можете — додайте інструментування до того, як додаватимете ще «ШІ».

По‑третє: зупиніть кровотечу

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

По‑четверте: вирішіть, чи маєте інцидент коректності

Якщо користувачі повідомляють «він дає погані відповіді», ставтесь до цього як до корупції даних: виберіть вибірку, відтворіть, знайдіть спільну закономірність і зупиніть реліз. Інциденти коректності не з’являються в графіках CPU.

Практичні завдання з командами: докази замість відчуттів

Ці завдання орієнтовані на Linux‑сервери, що запускають сервіс, пов’язаний зі ШІ (RAG‑пайплайн, векторний пошук, шлюз моделі або локальний сервер інференсу). Для кожного: команда, що означає вивід, і яке рішення приймати.

Завдання 1: Підтвердити базове здоров’я сервісу і рівень помилок (systemd + логи)

cr0x@server:~$ systemctl status ai-gateway --no-pager
● ai-gateway.service - AI Gateway
     Loaded: loaded (/etc/systemd/system/ai-gateway.service; enabled)
     Active: active (running) since Mon 2026-01-22 08:11:02 UTC; 3h 12min ago
   Main PID: 2147 (ai-gateway)
      Tasks: 38
     Memory: 612.3M
        CPU: 1h 44min

Значення: Процес запущено; видимі пам’ять і CPU. Це не доводить коректності або здоров’я upstream.

Рішення: Якщо не active/running — перезапустіть і розбирайтеся з crash loop. Якщо працює — переходьте до перевірки латентності і залежностей.

cr0x@server:~$ journalctl -u ai-gateway -n 50 --no-pager
Jan 22 11:12:55 server ai-gateway[2147]: WARN upstream timeout model=vendor-llm request_id=9c2a...
Jan 22 11:12:55 server ai-gateway[2147]: WARN retrying attempt=2 backoff_ms=400
Jan 22 11:12:56 server ai-gateway[2147]: ERROR upstream rate_limited model=vendor-llm status=429

Значення: Ви не «впали». Вас тротлять і ви отримуєте таймаути. Ретраї погіршують ситуацію.

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

Завдання 2: Виміряти p50/p95/p99 латентність на краю (nginx access logs)

cr0x@server:~$ awk '{print $NF}' /var/log/nginx/access.log | tail -n 2000 | sort -n | awk 'NR==1000{p50=$1} NR==1900{p95=$1} NR==1980{p99=$1} END{print "p50="p50,"p95="p95,"p99="p99}'
p50=0.842 p95=6.913 p99=18.402

Значення: Медіана виглядає нормально; хвіст латентності жахливий. Зазвичай це contention upstream, rate limiting або черги.

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

Завдання 3: Перевірити DNS і TLS, чи не вони — ваша «ШІ‑проблема»

cr0x@server:~$ dig +time=2 +tries=1 api.vendor-llm.internal A | sed -n '1,12p'
; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 api.vendor-llm.internal A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4812
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
api.vendor-llm.internal. 30 IN A 10.20.30.40

Значення: DNS тут резолвиться швидко і правильно.

Рішення: Якщо DNS повільний або падає — налаштуйте резолвери/кешування перш ніж звинувачувати модель. Якщо в порядку — тестуйте доступність і TLS.

cr0x@server:~$ openssl s_client -connect api.vendor-llm.internal:443 -servername api.vendor-llm.internal -brief < /dev/null
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = api.vendor-llm.internal
Verification: OK

Значення: TLS‑рукостискання вдається; сертифікат перевіряється. Якщо це падає періодично — можлива ротація PKI або проблема з MTU.

Рішення: Якщо хендшейк повільний/падає — досліджуйте шлях мережі, проксі або розгортання сертифікатів.

Завдання 4: Перевірити ліміти і мікс помилок upstream (curl)

cr0x@server:~$ curl -s -D - -o /dev/null -m 10 https://api.vendor-llm.internal/v1/models
HTTP/2 200
date: Mon, 22 Jan 2026 11:18:02 GMT
x-ratelimit-limit-requests: 3000
x-ratelimit-remaining-requests: 12
x-ratelimit-reset-seconds: 23

Значення: Ви близько до обриву. Залишилось небагато запитів; скидання скоро.

Рішення: Додайте client‑side throttling і черги. Якщо не можете — вмикайте кешування або деградуйте граціозно.

Завдання 5: Подивитись, чи ваша власна черга — вузьке місце (Linux socket backlog + app metrics proxy)

cr0x@server:~$ ss -lntp | awk 'NR==1 || /:8080/'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 512    4096   0.0.0.0:8080      0.0.0.0:*     users:(("ai-gateway",pid=2147,fd=12))

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

Рішення: Якщо Recv-Q зростає під час інцидентів — профілюйте пули потоків, паузи GC або очікування downstream.

Завдання 6: Визначити насичення CPU і тиск у черзі виконання

cr0x@server:~$ uptime
 11:19:44 up  3:22,  2 users,  load average: 18.42, 16.90, 15.77

Значення: Середні навантаження високі. На сервері з малою кількістю ядер ви CPU‑наповнені або заблоковані на I/O з багатьма runnable задачами.

Рішення: Перевірте кількість ядер, потім використайте vmstat/top, щоб вирішити, CPU це чи I/O wait.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  0      0  48212  21032 611204    0    0    10    24 1520 4820 78 12 10  0  0
15  0      0  47680  21032 611420    0    0    12    16 1602 5011 81 11  8  0  0

Значення: Високий r з низьким wa свідчить про тиск на CPU, а не про очікування диску.

Рішення: Шкальте назовні, зменшуйте паралелізм або оптимізуйте гарячі шляхи (побудова промптів, парсинг JSON, криптографія, компресія).

Завдання 7: Знайти ресурсомісткий процес і його потоки (top)

cr0x@server:~$ top -b -n 1 | sed -n '1,20p'
top - 11:20:31 up  3:23,  2 users,  load average: 19.02, 17.10, 15.92
Tasks: 238 total,  15 running, 223 sleeping,   0 stopped,   0 zombie
%Cpu(s): 84.5 us, 11.2 sy,  0.0 ni,  4.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  15928.0 total,    121.4 free,   1912.5 used,  13894.1 buff/cache
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2147 app      20   0 3248216 612340  48212 R  720.1   3.8  105:12.33 ai-gateway

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

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

Завдання 8: Перевірити тиск пам’яті і чи відбувається свопінг

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15928        1897         118          42       13912       13640
Swap:              0           0           0

Значення: Низький «free» сам по собі не проблема; «available» в межах норми. Свопу немає.

Рішення: Пам’ять ймовірно не вузьке місце. Якщо падає available або з’являються OOM — налаштуйте кеші або ліміти.

Завдання 9: Якщо ви хостите моделі, перевірте завантаження GPU і запас пам’яті

cr0x@server:~$ nvidia-smi
Wed Jan 22 11:22:06 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4   |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|  0  NVIDIA A10G                    On   | 00000000:00:1E.0 Off |                    0 |
|  0%   61C    P0              142W / 150W|  22340MiB / 24564MiB |     98%      Default |
+-----------------------------------------+----------------------+----------------------+

Значення: GPU завантажений під зав’язку і пам’ять майже повна. Хвостова латентність підскочить при чергуванні.

Рішення: Зменшіть розміри батчів, збільшіть кількість реплік, перейдіть на меншу модель або передавайте пікове навантаження зовнішньому провайдеру.

Завдання 10: Підтвердити латентність диска і насичення (векторні індекси часто це ускладнюють)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-41-generic (server)  01/22/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          32.10    0.00    6.22    9.84    0.00   51.84

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1        842.0  91320.0     12.0    1.4   14.82   108.4    112.0   1840.0    3.11   8.92   92.6

Значення: Високе читання і велике r_await з ~93% util свідчать, що сховище — вузьке місце (часто сканування індексу для витягів або компакти).

Рішення: Оптимізуйте векторний пошук (параметри HNSW, кешування), збільшіть ОЗП для гарячого індексу, перемістіть індекси на швидший NVMe або розділіть шарди.

Завдання 11: Перевірити вільне місце в файловій системі та інодіни (мовчазний вбивця)

cr0x@server:~$ df -h /var/lib/vector
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  900G  874G   26G  98% /var/lib/vector

Значення: Ви на 98% заповнення. Багато БД і побудовників індексів поводяться жахливо поруч із повними дисками.

Рішення: Звільніть місце негайно; зупиніть компакти; розширте том; введіть політики збереження.

cr0x@server:~$ df -i /var/lib/vector
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/nvme0n1p2  58982400 58611210   371190  99% /var/lib/vector

Значення: Іноди вичерпані. Може бути вільне місце, але створення файлів вже неможливе.

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

Завдання 12: Перевірити, чи кеш справді працює (приклад Redis)

cr0x@server:~$ redis-cli INFO stats | egrep 'keyspace_hits|keyspace_misses|evicted_keys'
keyspace_hits:1829441
keyspace_misses:921332
evicted_keys:44120

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

Рішення: Збільшіть розмір кешу, виправте TTL, нормалізуйте ключі і кешуйте результати витягів (не лише фінальні відповіді).

Завдання 13: Виявити шторм ретраїв через логи запитів (grep + counts)

cr0x@server:~$ grep -c "retrying attempt" /var/log/ai-gateway/app.log
18422

Значення: Ретраї часті; під час інциденту це число різко зростатиме.

Рішення: Впровадьте бюджет ретраїв на запит, додавайте jitter і уникайте ретраїв на 429 без інструкцій з Retry-After.

Завдання 14: Перевірити, чи вибухає використання токенів (proxy витрат)

cr0x@server:~$ awk '/tokens_in=/{for(i=1;i<=NF;i++) if($i ~ /tokens_in=/){split($i,a,"="); in+=a[2]} if($i ~ /tokens_out=/){split($i,b,"="); out+=b[2]}} END{print "tokens_in="in, "tokens_out="out}' /var/log/ai-gateway/app.log
tokens_in=9284410 tokens_out=16422033

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

Рішення: Обмежте max tokens, вимагайте лаконічних форматів і вводьте стоп‑послідовності або структурований вихід.

Завдання 15: Перевірити латентність запитів до векторної БД (приклад PostgreSQL + pgvector)

cr0x@server:~$ psql -d rag -c "EXPLAIN (ANALYZE, BUFFERS) SELECT id FROM docs ORDER BY embedding <-> '[0.1,0.2,0.3]' LIMIT 5;"
                                                    QUERY PLAN
------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.42..1.05 rows=5 width=8) (actual time=42.118..42.140 rows=5 loops=1)
   Buffers: shared hit=120 read=980
   ->  Index Scan using docs_embedding_hnsw on docs  (cost=0.42..1200.00 rows=10000 width=8) (actual time=42.116..42.136 rows=5 loops=1)
 Planning Time: 0.312 ms
 Execution Time: 42.202 ms

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

Рішення: Збільште shared buffers, прогрійте індекс, покращіть локальність (менше шардів на вузол) або налаштуйте параметри індексу для торгу точністю на користь швидкості.

Завдання 16: Підтвердити, що kernel/мережевий шлях не втрачає пакети (ss + retrans)

cr0x@server:~$ ss -ti dst api.vendor-llm.internal | sed -n '1,20p'
ESTAB 0 0 10.0.1.10:51244 10.20.30.40:https users:(("ai-gateway",pid=2147,fd=33))
	 cubic wscale:7,7 rto:204 rtt:32.1/4.0 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 bytes_acked:128394 segs_out:402 segs_in:377 send 3.6Mbps lastsnd:12 lastrcv:10 lastack:10 pacing_rate 7.2Mbps retrans:4/210

Значення: Існують ретрансляції. Якщо retrans зростає під час інцидентів — «повільність моделі» може бути наслідком втрат пакетів.

Рішення: Досліджуйте мережеве перевантаження, невідповідність MTU, таблиці станів фаєрволу або вичерпання NAT.

Типові помилки: симптоми → корінь → виправлення

1) Симптом: «Воно запущене, але користувачі кажуть відповіді стали гірші»

Корінь: Дрейф в розподілі входів, зміни в корпусі для витягування або зміна поведінки upstream‑моделі; відсутній моніторинг коректності.

Виправлення: Побудуйте фіксований набір оцінювання; відстежуйте якість відповідей людськими мітками або proxy‑метриками; додайте детекцію дрейфу тем запитів і змін розподілу витягнутих документів; додавайте безпечний фолбек (лише витяг).

2) Симптом: p50 в порядку, p99 — жахливий

Корінь: Чергування під навантаженням, ліміти, насичення GPU або повільні операції витягування I/O.

Виправлення: Обмежте паралелізм; додайте backpressure; пріоритезуйте запити; попередньо обчислюйте ембедінги; перемістіть витяг у пам’ять; керуйте таймаутами і відмовляйтеся від запізнілих задач.

3) Симптом: Витрати зросли, хоча трафік не зріс

Корінь: Шторм ретраїв, роздуті промпти, кеш‑промахи або багатослівні відповіді.

Виправлення: Бюджети ретраїв; ліміти на розмір промптів; обмеження довжини генерації; нормалізація ключів кешу; кешування проміжних результатів витягування.

4) Симптом: Випадкові 429 і таймаути, особливо в пікові моменти

Корінь: Лімітування постачальника або насичення вашого пулу з’єднань.

Виправлення: Токен‑бакет лімітування на клієнті; поважайте Retry-After; реалізуйте черги; стратегія multi‑provider з узгодженою поведінкою.

5) Симптом: «Security каже ні» і ви застигли на місяці

Корінь: Відсутність класифікації даних, нечіткі політики зберігання і промпти з чутливим вмістом.

Виправлення: Редакція перед відправленням; allowlists для витягування; шифрування; чіткі політики зберігання; очищення логів; threat model з урахуванням prompt injection і витоку даних.

6) Симптом: Чудове демо, жахливе прийняття

Корінь: Функція не інтегрована у робочий процес; затримка занадто велика; результати недостовірні; немає undo.

Виправлення: Режим advisory; inline‑цитати; швидкий UX «підтвердити/відредагувати»; показуйте впевненість і джерела; зберігайте існуючий робочий процес.

7) Симптом: Система «зависає» під навантаженням і потім відновлюється

Корінь: Head‑of‑line blocking, синхронізовані ретраї або паузи GC через великі промпти/логування.

Виправлення: Розділіть черги за пріоритетом; jittered backoff; стрімінг відповідей де можливо; обмежте розміри payload; зменшіть синхронне логування.

8) Симптом: Юридичні/комплаєнс ескалації після релізу

Корінь: Нетерміноване генерування без перевірок політик; виходи, що створюють зобов’язання або регульовані поради.

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

Чеклісти / покроковий план

Покроково: випустіть «ШІ‑функцію», не перетворюючи он‑коли на перформанс

1. Напишіть проблему без згадки ШІ. Якщо не можете — зупиніться. Ви будуєте театр.
2. Виберіть клас функції: детермінована, ймовірнісна або консультативна. За замовчуванням — консультативна.
3. Визначте SLO: доступність, латентність (p95/p99) і проксі‑метрика коректності. Занотуйте письмово.
4. Визначте бюджети: макс витрати на запит, місячний ліміт і поріг «вимкнення».
5. Спроєктуйте фолбеки: кешована відповідь, лише витяг, правила або «функція вимкнена». Переконайтесь, що основні потоки працюють.
6. Додайте запобіжні заходи: валідація входів, max prompt size, max tokens, таймаути, circuit breakers і rate limits.
7. Інструментуйте по стадіях: побудова промпта, витяг, інференс, пост‑обробка, запис. Потрібен розклад латентності.
8. Побудуйте стенд оцінки: фіксовані тестові запити, очікувані цитати, red team промпти, пороги регресій.
9. Проводьте поетапний реліз: внутрішні користувачі → невелика когорта → більші когорти. Слідкуйте за p99 і коректністю.
10. Проведіть game day: симулюйте upstream 429, сповільнення, погані відповіді і дрейф. Тренуйтеся вимикати фолбеки.
11. Оперейшналізуйте change management: версіонування промптів, фіксація моделей де можливо, версії корпусів, документування релізів.
12. Встановіть відповідальність: хто затверджує зміни промптів/моделей, хто відповідає за on‑call runbook, хто за бюджетні тривоги.

Чекліст: що заборонити в продакшні за замовчуванням

• Невизначені ретраї до upstream LLM‑провайдера.
• «Best effort» таймаути (все, що довше за терпіння користувача).
• Випуск без плану відкату або режиму фолбеку.
• Логування сирих промптів/відповідей з даними клієнтів.
• Дозвіл генерованого тексту прямо викликати незворотні дії (повернення коштів, видалення, зміни акаунта) без детермінованого шлюзу.
• «Одна модель для всього» без оцінки по кейсам використання.

Чекліст: сигнали, на які варто ставити алерти

• p99 латентності по стадіях пайплайна (витяг проти інференсу проти пост‑процесу).
• Кількість 429 і 5xx від upstream постачальників.
• Рівень викидання кешу і відношення попадань/промахів.
• Використання токенів на запит (in/out), плюс дисперсія.
• Глибина черги і час у черзі.
• Проксі коректності: частка цитат, відмови валідації, «палец вниз» від користувачів, рівень ескалацій.
• Індикатори дрейфу: розподіл тем запитів, зміни відстаней ембедінгів, зміни розподілу документів для витягування.

FAQ

1) Чи завжди «ШІ у всьому» — погано?

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

2) У чому найбільша відмінність між класичним софтом і ШІ‑функціями з операційної точки зору?

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

3) Хостити моделі самим чи використовувати провайдера?

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

4) Що вимірювати в першу чергу, якщо нічого немає?

Розбивку латентності по стадіях, мікс помилок upstream (429/5xx/таймаути), використання токенів на запит, відношення попадань кешу і одну проксі‑метрику коректності (зворотний зв’язок користувача або % валідації).

5) Як запобігти тому, щоб «зміни промптів» стали непереглянутими продакшн‑змінами?

Версіонуйте промпти як код. Потрібен огляд. Прогоняйте набір оцінювання в CI. Логируйте версію промпта на запит. Редагування промпта — це реліз.

6) Який найпростіший безпечний фолбек для функції на базі LLM?

Лише витяг: повертайте топ‑документи/фрагменти з посиланнями/заголовками (внутрішньо) і дозволяйте користувачам читати. Менш «магічно», але значно надійніше.

7) Як боротись з галюцинаціями, не прикидаючись, що їх немає?

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

8) Чи справді кешування відповідей LLM допомагає?

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

9) Яка найпоширеніша пастка з витратами?

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

10) Як пояснити надійність ШІ керівникам, які хочуть бейдж?

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

Висновок: наступні кроки на цей тиждень

«ШІ у всьому» — це не стратегія. Це ярлик. Ваше завдання — перетворити ярлики на системи, що поводяться під тиском.

1. Виберіть одну ШІ‑функцію і запишіть її метрику результату, метрику шкоди, бюджет латентності і бюджет витрат на одній сторінці.
2. Додайте режим фолбеку, що зберігає робочий процес, коли модель повільна, неправильно працює або обмежена лімітом.
3. Інструментуйте латентність по стадіях, щоб ви могли відповісти «куди пішов час?» без здогадок.
4. Побудуйте маленький стенд оцінки (20–50 репрезентативних запитів) і запускайте його перед кожною зміною промпта/моделі/корпусу.
5. Налаштуйте алерти на 429, ретраї, використання токенів, викидання кешу і p99 по стадіях. Не тому, що алерти — це весело, а тому, що сюрпризи дорогі.

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