Що лишається і що змінюється

Модуль 1Урок 4 з 38Безкоштовний модуль

Перехід до LLMOps не означає викинути все, що працювало в MLOps і DevOps. Версіонування, CI/CD, моніторинг, governance і incident response лишаються — змінюється предмет, який версіонують, що саме тестують у конвеєрі і які ризики потрапляють у risk register. Команда, яка бачить лише «нове», повторює старі помилки без сліду аудиту; команда, яка бачить лише «те саме», ігнорує інʼєкцію в підказку і оцінювання вільного тексту.

Що лишається з MLOps і DevOps

Version control для артефактів, code review, поступове розгортання, спостережуваність (logs, метрики, traces), access control і політики даних — все це переноситься. Модель або endpoint провайдера теж має версію; зміни не повинні летіти в продакшн без перевірки. Governance: хто схвалює реліз, де зберігаються секрети, як відповідати на інцидент — залишається організаційним каркасом, навіть якщо «модель» тепер API за subscription.

Порада

Тримайте єдиний changelog релізів: версія підказки, версія моделі укладань, версія індексу документів, версія API моделі. Користувач бачить одну «поведінку», але операційно це composition — без журналу неможливо відкотити регресію.

Що змінюється: підказка як артефакт

Підказка — це не «коментар у ноутбуці», а production config: system instructions, шаблони, приклади, політики формату відповіді. Її зміни так само можуть зламати продукт, як зміна SQL-схеми. Потрібні diff, review, тести на наборі для оцінювання та канаркове розгортання перед повним викатом. Без цього «хтось підправив підказку в пʼятницю» стає причиною понеділкового інциденту на рівні з поганим розгортанням.

Приклад

Команда додала в системну підказку одне речення «будь максимально стислим» — середня довжина відповіді впала, але зникли обовʼязкові disclaimer для regulated domain. Класичний unit test код не спіймав би; спрацювало лише оцінювання на compliance-наборі.

Конвеєри пошуку контексту і оцінювання вільного тексту

RAG додає ланцюжок ingest → фрагментація → укладання → index → пошук контексту → rerank — кожен крок версіонується і може деградувати. Оцінювання для LLM — не accuracy на 0/1 мітках, а rubrics: достовірність, relevance, toxicity, format compliance, порівняння з golden answers або LLM-суддя з обережністю. Моніторинг у продакшені збирає вибірки для людського review і сигнали на падіння метрик — аналог model performance dashboards, але для тексту.

Увага

Нові ризики: інʼєкція в підказку (користувач або документ змушує модель ігнорувати політики), витік PII у підказці або логах, over-reliance на generated code без review. Вони мають бути в threat model поруч із класичними OWASP-ризиками API.

Баланс простий: процеси залишаються, обʼєкти управління розширюються. Команда LLMOps успадковує дисципліну релізів і постмортемів, але додає бібліотеку оцінювання, політики redaction PII, тести на шкідливі підказки і контракти між пошуком контексту та generation. Це еволюція, не революція з чистого аркуша.

Що запамʼятати

Versioning, CI, моніторинг, governance — лишаються. Нове — підказка і пошук контексту як first-class артефакти, оцінювання вільного тексту та розширений threat model (injection, PII).

Перевірка

3 питання

Кілька питань за матеріалом уроку. Спроб — скільки завгодно.

1.Що з переліченого лишається актуальним у LLMOps?
2.Чому підказку треба трактувати як production артефакт?
3.Який новий ризик згадано окремо від класичних API-загроз?