Від промпту до продукту: як перетворити LLM на справжні застосунки
Практична методологія побудови застосунків на LLM: евали, запобіжники, бюджети затримки та вартості, людина в контурі й розуміння того, що не варто автоматизувати.
Автор Vitor Lima
Промпт, що працює в пісочниці, — це демо, а не продукт. Саме в розриві між ними тихо помирає більшість ШІ-проєктів. Побудова застосунків на LLM, які витримують реальних користувачів, значно менше залежить від хитрих промптів, ніж підказують демонстрації, і значно більше — від звичайної інженерної дисципліни. Ми випустили достатньо таких продуктів — Youp, MadaiOps, а тепер Linea, — щоб мати думку про те, що насправді закриває цей розрив. І нічого гламурного в цьому немає.
Пастка в тому, що перша версія здається завершеною. Ви вставляєте хитрий промпт, модель повертає щось вражаюче, і виникає спокуса загорнути це в інтерфейс і назвати запуском. Потім приходять реальні користувачі з вхідними даними, яких ви навіть не уявляли, модель упевнено робить щось хибне, і ви виявляєте, що не маєте способу зрозуміти, чи ваше виправлення покращило чи погіршило ситуацію. Ця стаття — про той каркас, що перетворює вражаюче демо на щось, що можна запустити у продакшн і спокійно спати вночі.
Починайте з евалів, а не з промптів
Найбільш важільна річ, яку ви можете побудувати на ранньому етапі, — це набір для оцінювання. Не бенчмарк, не таблиця лідерів — а тека з реальними вхідними даними, поєднаними з тим, як виглядає хороший результат. Двадцять прикладів кращі за нуль, а п'ятдесят ретельно відібраних — кращі за тисячу зішкрябаних з мережі.
Причина проста. Щойно у вас з'являються евали, інженерія промптів перестає бути справою відчуттів. Ви змінюєте рядок, запускаєте набір, спостерігаєте, як рухається число. Без них кожне налаштування — це забобон. Ми бачили, як команди тиждень покращували промпт лише для того, щоб отримати регрес на кейсах, які вирішили ще місяці тому, бо ніщо не вимірювало ті кейси, на які вони не дивилися.
Кілька думок, яких ми твердо дотримуємося:
- Оцінюйте за результатами, а не за формулюваннями. Для будь-чого структурованого — вилучення, класифікація, маршрутизація — робіть твердження щодо розпарсеного результату, а не щодо схожості рядків. Для відкритого тексту цілком годиться LLM-як-суддя з чіткою рубрикою, але спершу перевірте суддю на кількох людських розмітках, інакше ви просто вимірюєте смак однієї моделі.
- Ведіть файл регресій. Кожен збій у продакшні стає постійним тестовим кейсом. Саме так ваш набір евалів лишається чесним — він росте рівно в тих напрямках, у які тисне реальність.
- Версіонуйте евали разом із промптами. Промпт без свого набору евалів — це неперевірена зміна коду.
Якщо ви побудуєте лише одну річ із цієї статті, побудуйте це. Усе, що йде далі, залежить від здатності відповісти: чи стало від цього краще?
Запобіжники дешевші за вибачення
Моделі збоять так, як звичайне програмне забезпечення не збоїть. Вони вигадають API, якого не існує, погодяться з хибним припущенням користувача або видадуть цілком коректний на вигляд JSON із галюцинованим полем. Запобіжники — це шар, що ловить це, перш ніж воно дійде до користувача чи, ще гірше, до кроку виконання.
Мисліть у трьох позиціях.
- Вхідні запобіжники відхиляють або очищують дані перед запуском моделі: скринінг на ін'єкції промптів, редагування персональних даних, фільтрація нерелевантного.
- Вихідні запобіжники валідують те, що повертається: валідація схеми, перевірки прив'язки до джерел, фільтри політик.
- Запобіжники дій стоять між моделлю і будь-чим, що має побічні ефекти.
Саме третій — там, де живе справжній ризик. У Linea, наших агентах автоматизації робочих процесів, модель може пропонувати дії — викликати API, перемістити запис, надіслати повідомлення. Пропозиція та виконання навмисно розділені на окремі кроки. Кожна значуща дія проходить через типізований контракт і перевірку політики, перш ніж будь-що запуститься, а деструктивні чи незворотні дії потребують явного шлюзу підтвердження. Агент, що пропонує неправильну річ, — це UX-проблема, над якою можна ітерувати. Агент, що робить неправильну річ, — це інцидент. Тримайте ці два режими збою по різні боки жорсткого кордону.
Наша позиція: валідуйте структурований вихід за схемою і повторюйте запит у разі невдачі, замість того щоб довіряти моделі бути послідовною. І ніколи не дозволяйте, щоб сирий вихід моделі був тим, що запускає незворотну дію. Завжди ставте детерміновану перевірку посередині.
Плануйте затримку й вартість як функціональність
Затримка та вартість — це не те, що ви вимірюєте наприкінці. Це обмеження, під які ви проєктуєте від самого початку, бо вони змінюють архітектуру, а не лише рахунок.
Встановлюйте явні бюджети для кожної дії, зверненої до користувача: цільову затримку p95 і стелю вартості за виклик. Щойно це записано, проєктні рішення стають простішими. Кілька патернів, до яких ми звертаємося раз за разом:
- Підбирайте розмір моделі під кожен крок. Більшість конвеєрів мають один-два кроки, які справді потребують фронтирної моделі, і кілька таких, з якими чудово впорається менша й швидша. Маршрутизація простої класифікації до дешевої моделі та резервування дорогої для складного кроку міркування — це найвіддачливіша доступна оптимізація, і вона зазвичай ще й покращує затримку.
- Стрімте перший токен. Для всього діалогового відчутна затримка визначається переважно часом до першого токена. Стрімлена відповідь, що займає чотири секунди, відчувається краще, ніж блокуюча, що займає дві.
- Кешуйте агресивно. Кешування промптів для стабільного системного контексту, звичайне кешування результатів для повторюваних вхідних даних. Значуща частка продакшн-трафіку — це майже дублікати.
Компроміс, який варто тримати в голові: більші моделі зменшують ваші інженерні зусилля, але назавжди підвищують граничну вартість і затримку. Дешевші моделі перекладають роботу на вас — більше уваги до промптів, більше запобіжників, більше евалів, — але ця робота є разовою витратою проти постійної економії. Для будь-чого з обсягом вкладайтеся в інженерію.
Тримайте людину в контурі, свідомо
"Людина в контурі" звучить так часто, що вже перестало щось означати. Зроблене добре, це не резервний варіант на випадок збою ШІ — це спроєктований розподіл праці. Питання не в тому, чи залучати людину, а в тому, де судження людини варте більше за затримку, яку воно додає.
Патерн, що послужив нам найкраще, — це ескалація за порогом упевненості. Система обробляє впевнену більшість автоматично й маршрутизує невпевнену меншість до людини, додаючи міркування моделі, щоб людина ухвалювала рішення за секунди, а не за хвилини. У MadaiOps операції із замовленнями в межах нормальних параметрів проходять наскрізь; будь-що аномальне випливає до оператора з контекстом, а не виконується мовчки. Рецензент не няньчить машину. Він витрачає свою увагу лише там, де вона рідкісна й цінна.
Ще одне правило: інструментуйте виправлення людини й повертайте їх у ваш набір евалів і ваші промпти. Система з людиною в контурі, що не вчиться на своїх людях, просто платить двічі за ту саму роботу.
Знайте, чого не варто автоматизувати
Найважче судження в цій дисципліні — стриманість. Не кожне завдання варто передавати моделі, і зрілість полягає в тому, щоб знати, які залишити в спокої.
Наш приблизний тест: автоматизуйте там, де ціна помилки низька, або де помилку легко виявити й скасувати. Складання чернеток, підсумовування, вилучення, класифікація, маршрутизація — хороші кандидати. Хибну чернетку редагують; хибний підсумок ловлять під час читання. Будьте значно обережнішими там, де помилки дорогі, важко виявні або незворотні: будь-що, що рухає гроші, надсилає безповоротне повідомлення чи ухвалює юридичне або медичне рішення. Там модель належить до допоміжної ролі — випливання варіантів, складання чернеток на перегляд — а не за кермом.
Межа, якої ми тримаємося: якщо ви не можете описати, як саме ловитимете модель на помилці, ви не готові автоматизувати цей крок. Здатність виявляти збій — це справжня передумова, більша, ніж точність. Крок із точністю 95%, який ви можете повністю перевірити, безпечніше випускати, ніж крок із точністю 99%, який ви перевірити не можете.
Форма роботи
Перетворення промпту на продукт — це переважно негламурна частина: евали, щоб можна було вимірювати; запобіжники, щоб збої лишалися стриманими; бюджети, щоб усе лишалося швидким і доступним; люди, розміщені там, де судження має значення; і дисципліна лишити деякі речі неавтоматизованими. Модель — це, мабуть, двадцять відсотків системи. Решта вісімдесят — це інженерія, що робить її подеколишню геніальність безпечною для покладання.
Хороша новина в тому, що це знайома робота. Вона винагороджує ті самі інстинкти, що роблять хорошим будь-яке програмне забезпечення: виміряй, перш ніж змінювати; обмеж радіус ураження; поважай час своїх користувачів. Модель нова. Ремесло — ні.