Це частина поточної серії: дивіться першу публікацію тут .
Принцип ІІ: безпечне завантаження підказок (якщо вам справді потрібно)
Чи хотіли б ви, щоб ваш чат-бот почав обговорювати тексти Тейлор Свіфт замість надання технічної підтримки? Ось що зробив наш чат-бот, коли ми порушили наведений вище принцип. Якщо ви хочете де-Swift у своїй програмі та зробити свою архітектуру ШІ безпечнішою, продовжуйте читати. (Вибачте, шанувальники Тейлора!)
Де зберігати підказки
Чи зберігаєте ви свої підказки разом із рештою коду? Або завантажити їх з іншого джерела? Можливо, поєднання обох? Нижче наведено основу для обдумування цього рішення.
Варіант А – зберігати підказки в Git
Перше запитання, яке вам слід поставити: чи є безпосередня причина зберігати підказки окремо від вашого коду? Якщо ні, залиште підказки в Git з рештою кодової бази, де вони належать. Це найпростіша та найбезпечніша установка для обслуговування. Це параметр за замовчуванням.
Повертаючись до принципу №1: підказки – це код . Зберігати частини вашої кодової бази поза Git можливо, а іноді й необхідно, але не тривіально. Не приймайте рішення перемістити підказки легковажно.
Варіант Б. Завантажте підказки з платформи, керованої версіями
Що робити, якщо деякі з ваших підказок потрібно відредагувати неінженерам? Це може статися, якщо потрібен глибокий досвід у певній галузі. Або якщо підказку потрібно змінювати дуже часто, і ви не можете чекати на інженерний відділ.
У цьому випадку вам потрібно буде завантажити підказку під час виконання з джерела, контрольованого версією. Я бачив успішне використання Confluence та Google Docs для цієї мети. Також доступно багато інших керованих версіями платформ, доступних через API.
Плануючи логіку швидкого завантаження, не недооцінюйте кількість зусиль, які потрібно витратити на додавання цієї інтеграції. Щоб мати впевненість у своїй програмі, вам потрібно буде впоратися з різноманітними умовами та сценаріями помилок. Необхідно налаштувати та підтримувати дозволи на доступ, а також розширити автоматизоване тестування та додатковий моніторинг, щоб виявляти помилки якомога раніше.
Ось кілька сценаріїв, які вам потрібно спланувати:
- Програма не може завантажити підказки під час виконання. Ви вбиваєте розгортання? Перейти до резервної версії підказки?
- Синтаксис запиту стає недійсним після зміни та повертає непридатні структури даних. Автоматизованим тестам не вдалося виявити проблему, оскільки підказки не завантажувалися під час виконання тесту. Яку додаткову інфраструктуру тестування та моніторинг потрібно додати, щоб виявити це та мінімізувати вплив на клієнтів?
- Підказку потрібно терміново відкотити. Чи потрібне для цього розгортання нового коду? Або ви створюєте окремий інтерфейс користувача для швидкого розгортання?
- Синтаксис, доданий до документа такими платформами, як Confluence, може проникнути в підказку середовища виконання, негативно вплинувши на його продуктивність. Переконайтеся, що ви відфільтруєте пух за допомогою таких інструментів, як Beautiful Soup.
Всі ці проблеми вирішувані на 100%. Але легко потрапити в шаблон мислення, що завантаження підказки з Google Doc є тривіальною операцією, яка не вплине глибоко на архітектуру програми. Як я показав вище, завантаження зовнішньої підказки є серйозною справою, до якої потрібно підходити обережно щодо високонадійних програм.
Варіант C. Завантажте підказки з платформи, що не контролюється версією
Це погана ідея, і ви про це пошкодуєте. Джерело істини для підказок має контролюватися версіями, мати відповідний API та засоби контролю доступу. Це не місце для зрізання кутів.
Варіант D – гібридний підхід
Гібридний підхід поєднує зберігання деяких підказок безпосередньо у вашій кодовій базі та завантаження інших із зовнішніх джерел, контрольованих версіями. Хоча підтримувати єдине розташування для всіх підказок часто простіше та надійніше, є сценарії, коли гібридна стратегія може запропонувати переваги.
Розгляньте можливість застосування гібридного підходу за таких умов, як:
- Змішане використання : деякі підказки вимагають частих оновлень експертами домену, що не займається кодуванням, що робить зовнішнє завантаження практичним, тоді як інші змінюються лише інженерами.
- Управління ризиками : критичні підказки (наприклад, огорожі) мають зберігатися в головному сховищі для максимальної надійності. Менш критичні підказки, особливо ті, що піддаються частим коригуванням, можуть безпечно існувати зовні.
- Гнучкість оцінювання : підказками, призначеними для оцінювання в стилі ML, можна керувати ззовні, щоб спростити їх інтеграцію з інфраструктурою оцінювання.
Підказки огородження
Підказки Guardrail (також відомі як підказки цензури) спеціалізуються на перевірці відповідей, перш ніж вони досягнуть користувачів, забезпечуючи відповідні, безпечні та сумісні виходи. Огородження служать захисним механізмом, особливо в програмах, де взаємодія користувача несе значні юридичні чи етичні ризики. Вони забезпечують другу лінію захисту, ловлячи невідповідні вихідні дані, які прослизають.
Не завантажуйте підказки із зовнішнього документа - це створює значний непотрібний ризик. Або зберігайте їх у Git разом зі своїм кодом, або скористайтеся спеціальним стороннім інструментом, таким як Fiddle Guardrails . Логіка огородження змінюється нечасто, тому цей підхід не сповільнить вас.
Використання огорож є окремим принципом, який буде обговорено більш детально в наступній публікації. Це чудовий шаблон, який покращує безпеку вашої програми та допомагає вам краще спати вночі. Тільки не завантажуйте їх із Google Docs.
Завантаження підказок для легшого оцінювання
Команди часто завантажують підказки ззовні, щоб інтегрувати їх із механізмами оцінювання, такими як ML Flow . Основне припущення, яке лежить в основі цієї практики, полягає в тому, що підказки схожі на моделі ML і потребують відокремленої статистичної оцінки. Ви підключаєте підказку, вимірюєте результат F1 на виході (або будь-який інший показник, який вам подобається) і повторюєте.
Цей підхід іноді дійсний, наприклад, для підказок класифікації, призначених для роботи як моделі ML. Але більшість підказок принципово відрізняються: як зазначено в Принципі №1: Підказки LLM є кодом . Типові підказки більше схожі на логіку програми, ніж на моделі ML. Вони більше підходять для оцінки типу Pass-Fail разом із навколишнім кодом, а не підходу статистичного оцінювання.
Механізми зовнішнього оцінювання не допоможуть вам із більшістю підказок. Натомість вам слід використовувати автоматизовані тести на основі ШІ, подібні до традиційних модульних тестів. Це буде в центрі уваги наступних публікацій.
Розглянемо такі практики:
- Лише ті підказки, функціональні можливості яких явно імітують моделі машинного навчання (наприклад, завдання класифікації чи оцінки), повинні проходити зовнішню оцінку.
- Підтримуйте більшість підказок бізнес-логіки в основній кодовій базі, використовуючи традиційні автоматизовані підходи до тестування, схожі на модульне тестування, а не методи перевірки ML.
- Якщо зовнішнє оцінювання виправдане, ізолюйте лише ті підказки, коли це можливо.
Кейс-стаді
Головною проблемою завантаження підказок є доступність. Що робити, якщо підказка не завантажується, коли ви очікуєте.
Це те, що сталося з нами у прикладі Тейлор Свіфт. Жоден із запитів для програми технічної підтримки не завантажується внаслідок проблеми з обліковими даними Confluence, включно із запитом на огорожу. Це якимось чином не викликало жодних помилок виконання, і бот почав відповідати без будь-яких інструкцій або введення (оскільки рядок форматування введення був частиною підказки). І з чим хоче говорити LLM OpenAI за відсутності вхідних даних? Виявляється, слова пісні «I Want to Break Free» гурту Queen і різні пісні Тейлор Свіфт. На щастя, це було виявлено та виправлено майже негайно, і користувачам сподобалося обговорення музики — принаймні так я собі кажу.
Чому стався цей інцидент? Було допущено дві помилки:
- Перевірки успішного завантаження підказок не проводилися. Під час швидкого завантаження мала виникнути помилка, оскільки програма не могла працювати без завантажених підказок.
- Підказку поручня було завантажено ззовні разом з рештою підказок. Це одна підказка, яку не слід завантажувати таким чином. Його слід було зберігати в Git як останню лінію захисту.
Після інциденту підказку огорожі було повторно переміщено до Git і додано логіку винятків, щоб запобігти розгортанню, якщо підказку не вдалося завантажити або вона була недійсною. Ви можете врятувати себе від посмертного розтину, дотримуючись цих рекомендацій заздалегідь.
Висновок
У цій публікації я розглянув ключові міркування щодо оперативного зберігання та завантаження в програмах ШІ. За замовчуванням підказки зберігаються разом із кодом у репозиторіях із керуванням версіями. Відхиляйтеся від цього, лише якщо є вагомі причини, наприклад часте редагування неінженерами або особливі вимоги до оцінювання.
Якщо підказки потрібно завантажувати ззовні, вибирайте надійні та суворо контрольовані джерела, додаючи тестування та моніторинг стійкості. З огляду на їхню критичну роль у безпеці додатків, підказки щодо огорожі мають залишатися у вашій кодовій базі, щоб уникнути серйозних ризиків для надійності.
Більшість підказок за своєю природою ближчі до коду, ніж до моделей ML, тому використовуйте інструменти стилю ML лише там, де вони вам потрібні. Не зберігайте всі ваші підказки ззовні лише для того, щоб спростити інтеграцію з інструментом оцінки для кількох із них.
Якщо вам сподобалася ця публікація, стежте за серією, щоб дізнатися більше.
