MLOps для додатків LLM: від прототипу до продакшену

Пілот працював три тижні без серйозних проблем. Асистент відповідав за 1-2 секунди, клієнти не скаржилися, результати з golden set виглядали обнадійливо. Потім хтось запропонував «невелике» оновлення моделі у постачальника та зміну кількох речень у системному промпті. Деплой відбувся в п’ятницю після обіду. У понеділок вранці з’ясувалося, що частка запитів, ескалованих до консультантів, зросла з 8 до 23 відсотків, а вартість токенів підскочила на 40 відсотків. Ніхто не знав, яка саме зміна це спричинила, бо обидві були впроваджені разом без розділення.

Це класичний сценарій, який ми в Cashcrown бачимо регулярно. LLMOps, тобто операційний шар для додатків LLM, існує саме для того, щоб таких п’ятниць більше не було.

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

Різниця не в якості моделі. Вона — у шарі, який нею керує.

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

Найбільша помилка, яку ми спостерігаємо, — це версіонування промпту окремо від моделі. Якщо промпт змінився на два речення, а модель оновилася з gpt-4o-2024-05-13 на новіший ідентифікатор, фактично маєш дві зміни одночасно. Коли щось піде не так, не знатимеш, що саме відкочувати.

Рішення просте: вся конфігурація отримує один номер версії. Змінюєш щось всередині — нова версія, нове запускання гейту, нове людське рішення. Артефакт версії містить:

• повний текст системного промпту та шаблонів (не посилання на файл, а вміст)
• точний ідентифікатор моделі (не latest, не загальна назва)
• параметри генерації: температура, top-p, ліміт токенів
• схему виводу, якщо використовуєш structured output
• версію бази знань або індексу RAG, з якою працює система
• правила маршрутизації, якщо модель обирається динамічно через inference router

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

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

Створення golden set починаємо з 80-150 реальних випадків із логів, а не з вигаданих прикладів. Важливо, щоб у наборі були складні, граничні випадки та ті, які історично викликали проблеми. Саме вони регресують першими після зміни промпту.

Для кожного випадку визначаємо критерії акцептації. Рідко це точне збігання тексту, частіше — набір фактів, які мають бути присутні, формат, якого потрібно дотримуватися, або список речей, яких не повинно бути у відповіді. Автоматична оцінка працює за схемою, регулярними виразами або LLM-as-judge, каліброваним на людських оцінках.

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

Методику створення golden set і підбору метрик детальніше описано в статті про як евалювати систему RAG. Правила ідентичні для агентських систем.

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

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

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

Canary спрямовує частину трафіку на нову версію, зазвичай 5-10 відсотків, і порівнює метрики якості та бізнес-показники в обох групах. Пороги переходу визначаємо заздалегідь: нова версія отримує весь трафік лише тоді, коли не погіршує ключові метрики протягом визначеного часового вікна. Рішення приймає людина, а не скрипт.

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

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

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

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

Затримка — це розподіл p50 і p95, а не середнє. Середнє приховує хвіст повільних відповідей, які псують досвід клієнтів із складними запитаннями. Observability у системі LLM означає логування кожного виклику з міткою часу, моделлю, кількістю токенів на вході та виході та номером версії артефакту.

Як обирати метрики та пороги алертів, щоб не потонути у хибних спрацьовуваннях, описано в окремому тексті про моніторинг якості агента AI.

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

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

Три сигнали для відкату визначаємо заздалегідь:

• показник ескалації перевищує поріг більше ніж на N відсоткових пунктів протягом M хвилин
• вартість на подію зростає вище ліміту протягом визначеного вікна
• затримка p95 перевищує поріг SLA протягом безперервного часу

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

Класичний DevOps контролює коректність коду: юніт-тести, інтеграційні тести, code review. MLOps для LLM контролює коректність поведінки моделі, яка не випливає безпосередньо з коду. Промпт синтаксично коректний, але може поводитися інакше після зміни одного речення. Тому поряд із тестами коду потрібен евалюаційний гейт на golden set, shadow і canary замість простого деплою, та безперервний моніторинг якості на продакшен-трафіку.

Починаємо з 80-150 випадків із реальних логів або звернень, а не з вигаданих прикладів. Важливіша за кількість — репрезентативність: набір має покривати основні класи запитань, граничні випадки та ті, які історично викликали проблеми. Кожен новий інцидент у продакшені — кандидат на додавання до golden set. Набір зростає разом із системою.

Так. Базова версія — це версіонування артефактів у git або простому реєстрі, скрипт-тест на golden set у CI, логи викликів у PostgreSQL або файлі JSONL та дашборд із кількома графіками. Комерційні платформи MLOps прискорюють процес, але не є обов’язковою умовою. Ключова — дисципліна процесу: гейт перед деплоєм, людське рішення, готовий відкат.

Фіксуй точний ідентифікатор версії моделі замість загальної назви або тегу latest. Якщо постачальник не надає ідентифікатора, періодично запускай golden set навіть без змін зі свого боку. Тихий дрейф з боку постачальника — одне з найчастіших джерел регресій, які ніхто не виявляє тижнями.

Для невеликих змін промпту, де змінюєш формат або тон, тесту регресії офлайн на golden set зазвичай достатньо. Shadow і canary резервуємо для зміни моделі, перебудови структури промпту або оновлення бази знань великого масштабу. Правило: чим більший обсяг зміни та чим важче передбачити побічні ефекти, тим більше виправданий дорогий shadow замість простої офлайн-перевірки.