LLMOps

Чеклист готовності до прода

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

1. 1.Версійність

   1. 1.1Версію моделі зафіксовано явно. Жодних аліасів, що слідують за останнім релізом постачальника.
   2. 1.2Промпт у контролі версій поруч із кодом, що його надсилає, і має ідентифікатор версії.
   3. 1.3Індекс пошуку має версію, і ця версія є частиною того, що розгортається.
   4. 1.4Зміна будь-чого з чотирьох — це розгортання: з переглядом, оголошенням і попередньою комбінацією, яку досі можна розгорнути.

2. 2.Оцінювання

   1. 2.1Є набір оцінювання з тридцяти-пʼятдесяти випадків, зміщений у бік вводів, які ламають.
   2. 2.2Він проганяється на кожну зміну промпту, моделі чи пошуку й показує частки, а не «пройшло / не пройшло».
   3. 2.3Детерміновані перевірки використовують скрізь, де задача це дозволяє: мітки, схеми, арифметика, наявність цитат.
   4. 2.4Будь-яку модель-суддю калібрують за людськими оцінками, перш ніж їй довіряти, і фіксують, як будь-яку іншу модель.
   5. 2.5Відкладену частину набору дивляться лише перед релізом, щоб підгін не зʼїв її непомітно.

3. 3.Трасування

   1. 3.1Кожен виклик записує версію промпту, відрендерений промпт, модель та її версію.
   2. 3.2Кожен виклик записує ідентифікатори знайдених фрагментів і кожен виклик інструмента з аргументами й результатом.
   3. 3.3Кожен виклик записує токени на вході й виході, затримку та підсумкову відповідь у тому вигляді, який побачив користувач.
   4. 3.4Кожна показана користувачу відповідь несе ідентифікатор сліду, який інтерфейс може повернути назад.

4. 4.Запобіжники

   1. 4.1Відповідь валідують за схемою, перш ніж будь-який код на неї зреагує.
   2. 4.2Посилання перевіряють на існування й на те, чи справді вони підтверджують твердження, до показу відповіді.
   3. 4.3Визначено поведінку на випадок, коли постачальник недоступний, обмежує частоту або гальмує.
   4. 4.4Тайм-аути й повтори з відступом є на кожному виклику, а пакетний трафік не може заморити інтерактивний шлях.

5. 5.Дашборди з першого тижня

   1. 5.1Токени на запит — бо промпти ростуть тихо, і саме цей рядок стає рахунком.
   2. 5.2Затримка на девʼяносто пʼятому процентилі — бо в ній домінує довжина виводу, а хвіст і є тим, що відчуває користувач.
   3. 5.3Частка відмов і відступів, що зростає раніше за все інше, коли зсувається промпт чи модель.
   4. 5.4Частка відповідей, відхилених вашими запобіжниками, — найближче до сигналу якості в реальному часі.

6. 6.Цикл покращення

   1. 6.1Зворотний звʼязок від користувачів несе ідентифікатор сліду, тож оцінка відкривається просто на причину.
   2. 6.2Хтось переглядає негативні оцінки за тиждень і класифікує кожну: пошук, промпт, модель чи все гаразд.
   3. 6.3Справжні збої переносять у набір оцінювання, тож він дорожчає в міру того, як системою більше користуються.
   4. 6.4Одна названа людина володіє числом якості й має право блокувати реліз на цьому числі.

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

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

Одиниця розгортання — це чотири речі

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

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

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

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

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

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

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

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

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

Вартість і затримка під справжнім трафіком

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

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

Пʼять інцидентів — і який рядок спіймав би кожен

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

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

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

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

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

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

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