LLMOps

Що змінюється насправді

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

Оцінювання — це і є набір тестів

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

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

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

Що має записувати прод

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

Чотири сигнали варті дашборда з першого тижня. Токени на запит — бо промпти ростуть тихо, і саме цей рядок стає рахунком. Затримка на девʼяносто пʼятому процентилі — бо в ній домінує довжина виводу, а хвіст і є тим, що відчуває користувач. Частка відмов і відступів, що зростає раніше за все інше, коли зсувається промпт чи модель. І частка відповідей, відхилених вашими власними запобіжниками — збої схеми, відсутні посилання, заблокований вміст, — це найближче до сигналу якості в реальному часі, що ви взагалі отримаєте.

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

Як це виявляється в реальній поставці

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

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

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

Де це вироджується

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

Коли це застосовувати

Пов’язані сторінки

• РозробкаПромпт-інженеріяПромпт-інженерія — це робота над інструкцією, за якою діє мовна модель. Промпт — це специфікація, а не замовляння. Фрази, якими обмінюються як трюками, працюють лише тому, що додають інформацію, якої модель інакше не мала; ті, що інформації не додають, не роблять нічого. На цій сторінці — з чого складається промпт, які прийоми справді змінюють результат, як зрозуміти, чи допомогла зміна, і чому недовірений текст у промпті — це межа безпеки, а не питання формулювання.
• РозробкаAI-агентиAI-агент — це цикл, у якому модель вирішує, що робити далі: викликає інструмент, читає результат і вирішує знову, доки не визнає задачу виконаною. Це одне проєктне рішення — керування, перенесене з вашого коду в модель, — купує здатність робити задачі, яких не можна описати заздалегідь, і коштує детермінованості, передбачуваного рахунку й обмеженого радіуса ураження. На цій сторінці — сам цикл, режими збою, які трапляються лише в ньому, і як зрозуміти, чи потрібен вам агент узагалі.
• РозробкаRAG-архітектураRetrieval-augmented generation (RAG) — це спосіб змусити модель відповідати про дані, на яких її не навчали: спершу знайти доречні фрагменти, покласти їх у промпт і вимагати, щоб відповідь походила саме з них. Тому RAG — це пошукова система з мовною моделлю на кінці, і тому майже кожна хибна відповідь є збоєм пошуку, а не генерації. На цій сторінці — обидва конвеєри, як вимірювати пошук окремо, і проблема прав доступу, що перетворює демо на інцидент.