Орієнтація на життєвий цикл проекту LLM
Виконавче резюме
Великі мовні моделі (LLM) революціонізують роботу ШІ в багатьох сферах. Цей посібник допоможе вам зрозуміти основні етапи створення проекту LLM, використовуючи чат-бота для підтримки клієнтів як приклад. Ми зосередимося на:
- Визначенні проблеми: Що саме ми хочемо, щоб чат-бот робив?
- Виборі правильного моделі: Як обрати найкращу модель LLM для наших потреб.
- Налаштуванні моделі: Підготовка моделі до конкретного використання.
- Розгортанні чат-бота: Як запустити чат-бот у реальному світі.
Протягом цього процесу ми розглянемо важливі моменти, які варто враховувати, та поширені помилки, яких треба уникати.
Діаграма підкреслює безперервний характер життєвого циклу, показуючи, як моніторинг та розгортання повертаються до визначення варіанту використання для подальшого удосконалення.
Визначення варіанту використання: Обсяг і цілі
Першим кроком є визначення чіткого варіанту використання та метрик успіху. Для нашого прикладу ми побудуємо чат-бота для підтримки клієнтів, який оброблятиме типові запити та ескалуватиме складніші.
Метрики успіху
- Зменшити навантаження на підтримку на ~30%
- Поліпшити час відповіді на 40%
- Підтримувати рівень задоволеності клієнтів понад 4.5/5
- Тримати рівень ескалації нижче 15%
Розгляд обсягу
Основні функції: Обробка статусу замовлення, повернення товарів, базова діагностика
Обмеження:
- Повинен розуміти різні варіанти формулювання запитів
- Повинен розпізнавати, коли потрібно ескалувати
- Повинен дотримуватися нормативів конфіденційності даних
- Повинен працювати в межах визначених вимог щодо латентності (<2с час відповіді)
Чітке визначення обсягу допомагає обмежити простір задачі, що є важливим для керування складністю.
Вибір відповідної моделі
Для вибору моделі нам потрібно врахувати кілька факторів:
Технічна архітектура
Використовуючи універсальну архітектуру Transformerencoder-decoder як приклад, ми можемо знайти специфічні адаптації або варіанти більш загальної моделі, такі як:
- Моделі тільки енкодера (наприклад, BERT— Bidirectional Encoder Representations from Transformers): Використовується лише частина енкодера Transformer, оскільки задача зазвичай полягає у розумінні введених даних, а не в генеруванні результату (наприклад, класифікація тексту, розпізнавання іменованих сутностей).
- Моделі тільки декодера (наприклад, GPT— Generative Pre-trained Transformer): Використовується лише частина декодера, оскільки мета полягає в прогнозуванні майбутніх токенів на основі попередніх, що підходить для генерації тексту, автозаповнення або інших завдань генерації послідовностей.
- Моделі енкодер-декодер (наприклад, T5X — Text-To-Text Transfer Transformer, BART): Енкодер стискає введення в латентне подання, і декодер потім відновлює це подання в бажаний результат. Така архітектура корисна для завдань, де потрібно перетворити введення в результат з іншою репрезентацією, наприклад, машинний переклад.
- Autoencoders на основі Transformer: Енкодер стискає введення в латентне подання, а декодер відновлює оригінальне введення з цього подання. Основна відмінність полягає в тому, що вхід і вихід є однаковим типом даних, а завдання полягає в реконструкції, а не в перетворенні чи генерації. Типове використання — виявлення аномалій, де поріг помилки реконструкції використовується як індикатор аномалії (наприклад,...
Орієнтація на життєвий цикл проекту LLM
Виконавче резюме
Великі мовні моделі (LLM) революціонізують роботу ШІ в багатьох сферах. Цей посібник допоможе вам зрозуміти основні етапи створення проекту LLM, використовуючи чат-бота для підтримки клієнтів як приклад. Ми зосередимося на:
- Визначенні проблеми: Що саме ми хочемо, щоб чат-бот робив?
- Виборі правильного моделі: Як обрати найкращу модель LLM для наших потреб.
- Налаштуванні моделі: Підготовка моделі до конкретного використання.
- Розгортанні чат-бота: Як запустити чат-бот у реальному світі.
Протягом цього процесу ми розглянемо важливі моменти, які варто враховувати, та поширені помилки, яких треба уникати.
Діаграма підкреслює безперервний характер життєвого циклу, показуючи, як моніторинг та розгортання повертаються до визначення варіанту використання для подальшого удосконалення.
Визначення варіанту використання: Обсяг і цілі
Першим кроком є визначення чіткого варіанту використання та метрик успіху. Для нашого прикладу ми побудуємо чат-бота для підтримки клієнтів, який оброблятиме типові запити та ескалуватиме складніші.
Метрики успіху
- Зменшити навантаження на підтримку на ~30%
- Поліпшити час відповіді на 40%
- Підтримувати рівень задоволеності клієнтів понад 4.5/5
- Тримати рівень ескалації нижче 15%
Розгляд обсягу
Основні функції: Обробка статусу замовлення, повернення товарів, базова діагностика
Обмеження:
- Повинен розуміти різні варіанти формулювання запитів
- Повинен розпізнавати, коли потрібно ескалувати
- Повинен дотримуватися нормативів конфіденційності даних
- Повинен працювати в межах визначених вимог щодо латентності (<2с час відповіді)
Чітке визначення обсягу допомагає обмежити простір задачі, що є важливим для керування складністю.
Вибір відповідної моделі
Для вибору моделі нам потрібно врахувати кілька факторів:
Технічна архітектура
Використовуючи універсальну архітектуру Transformerencoder-decoder як приклад, ми можемо знайти специфічні адаптації або варіанти більш загальної моделі, такі як:
- Моделі тільки енкодера (наприклад, BERT— Bidirectional Encoder Representations from Transformers): Використовується лише частина енкодера Transformer, оскільки задача зазвичай полягає у розумінні введених даних, а не в генеруванні результату (наприклад, класифікація тексту, розпізнавання іменованих сутностей).
- Моделі тільки декодера (наприклад, GPT— Generative Pre-trained Transformer): Використовується лише частина декодера, оскільки мета полягає в прогнозуванні майбутніх токенів на основі попередніх, що підходить для генерації тексту, автозаповнення або інших завдань генерації послідовностей.
- Моделі енкодер-декодер (наприклад, T5X — Text-To-Text Transfer Transformer, BART): Енкодер стискає введення в латентне подання, і декодер потім відновлює це подання в бажаний результат. Така архітектура корисна для завдань, де потрібно перетворити введення в результат з іншою репрезентацією, наприклад, машинний переклад.
- Autoencoders на основі Transformer: Енкодер стискає введення в латентне подання, а декодер відновлює оригінальне введення з цього подання. Основна відмінність полягає в тому, що вхід і вихід є однаковим типом даних, а завдання полягає в реконструкції, а не в перетворенні чи генерації. Типове використання — виявлення аномалій, де поріг помилки реконструкції використовується як індикатор аномалії (наприклад,...
Перевірка деталей замовлення: Я перевірю, чи збігається номер замовлення з існуючим замовленням у системі, щоб забезпечити точність наданої інформації.\n\n3.
Перевірка статусу замовлення: Коли замовлення знайдено, я перевірю його поточний статус (наприклад, обробка, відправлено, доставлено тощо).\n\n4.
Надання оновленої інформації: Виходячи з отриманого статусу, я надам вам найактуальнішу інформацію про ваше замовлення.\n\n
Оскільки я не маю прямого доступу до бази даних замовлень, ви зазвичай отримуватимете статус на основі останнього оновлення системи.
Якщо у вас є доступ до певного сервісу або вебсайту, де ви можете перевірити статус замовлення безпосередньо, вам варто скористатися цим.
В іншому випадку найкращим варіантом буде звернутися до служби підтримки компанії, в якій ви здійснили покупку, для отримання допомоги."
```
Поява інструментів автоматизованої оптимізації підказок (APO) — таких як AdalFlow чи Promptify — спрощує процес створення підказок. Ця сфера швидко розвивається, тому завжди варто перевіряти нові розробки та інструменти.
Якщо ми вичерпали потенціал створення підказок для покращення продуктивності моделі, ми можемо перейти до тонкої налаштування, процес, який все ж вимагає значних витрат часу і ресурсів.
Тонка настройка
Тонка настройка моделі є важливою для покращення її продуктивності на спеціалізованих задачах. Існує кілька методів для цього, від простої тонкої настройки інструкцій, де ми надаємо моделі приклади відповідних пар запитань і відповідей, до ефективної тонкої настройки параметрів (PEFT), яка адаптує великі моделі за допомогою меншої кількості тренованих параметрів. LoRA(Low-Rank Adaptation) є популярним методом PEFT, який допомагає моделі засвоювати нові знання, уникаючи катастрофічного забування — коли модель втрачає раніше засвоєну інформацію під час вивчення нових завдань.
Тонка настройка доступна для нашої моделі GPT-4o. Нам просто потрібно бути обережними з витратами, пов'язаними з цим процесом. Розглядайте тонку настройку, коли оптимізація підказок досягне своїх меж:
Коли здійснювати тонку настройку:
- Постійне недопрацювання в конкретних областях
- Великий обсяг спеціалізованих знань
- Потреба в швидшому виведенні з використанням індивідуальних підказок
Вимоги:
- Високоякісні тренувальні дані (зазвичай 1000+ прикладів)
- Обчислювальні ресурси для тренування
- Бюджет на супутні витрати
Для ще більшого покращення моделі нам може знадобитися використовувати методи, такі як Reinforcement Learning from Human Feedback (RLHF), щоб краще узгоджувати відповіді з людськими очікуваннями.
Узгодження з людським відгуком
RLHF має на меті забезпечити, щоб модель працювала в корисний і безпечний спосіб. Застосування RLHF до моделі, такої як GPT-4, включає створення наборів даних, тренування моделі винагороди та використання підкріплювального навчання. Через обмеження API та відсутність прямого доступу до моделі, RLHF для GPT-4, що розміщений на OpenAI, наразі неможливий. У цьому випадку практичніше використовувати створення підказок, тонку настройку інструкцій або подібні підходи для кращого узгодження моделі з потребами користувачів.
Хоча це не тренує модель динамічно для кращого узгодження з уподобаннями користувача (як RLHF), оцінка MLflow може бути життєздатною альтернативою, коли RLHF неможливий, особливо з закритими моделями, такими як GPT-4.
Це дозволяє нам проводити статичні оцінки за допомогою визначених людьми метрик (включаючи метрики культурної чутливості), щоб оцінити якість виходу моделі.
Зверніть увагу, що людська участь має бути присутня на всіх етапах життєвого циклу (Людина в циклі), а не тільки на етапі RLHF. Людська експертиза важлива для анотації даних, оцінки моделі та ітераційного вдосконалення.
Узгодження та оцінка
- Реалізуйте автоматизовані метрики оцінки
- Використовуйте MLflow для систематичного відстеження продуктивності
- Розгляньте RLHF, коли це можливо для покращеного узгодження
Інтеграція додатка та розгортання
Реалізація
Останнім кроком є розгортання моделі та інтеграція її в наш додаток. Ми оптимізуємо модель для інференсу і надаємо її для взаємодії з клієнтами.
# Припустимо, ми оптимізували модель для ефективного інференсу
from langchain.chains import LLMChain
# Визначимо додаток, який використовує LLM
llm_chain = LLMChain(llm=llm, prompt=prompt)
question = "Як я можу повернути товар?"
response = llm_chain.run(question)
print(response)
Щоб допомогти вам з поверненням товару, ось кроки, які потрібно виконати:
1. **Перевірте політику повернення**: Переконайтеся, що товар підлягає поверненню, ознайомившись з політикою повернення на нашому вебсайті. Зверніть увагу на терміни для повернення і будь-які специфічні умови.
2. **Увійдіть у свій обліковий запис**: Перейдіть на наш сайт і увійдіть в обліковий запис, з якого було здійснено покупку.
3. **Перейдіть до історії замовлень**: Перейдіть до історії замовлень, щоб знайти замовлення, що містить товар, який ви хочете повернути.
4. **Виберіть товар**: Клацніть на замовлення, щоб переглянути деталі, і виберіть товар, який хочете повернути.
5. **Ініціюйте повернення**: Дотримуйтесь інструкцій, щоб ініціювати повернення. Зазвичай це включає вибір причини повернення та підтвердження запиту на повернення.
6. **Роздрукуйте етикетку для повернення**: Коли ваш запит на повернення буде схвалено, ви зможете роздрукувати етикетку для повернення товару.
7. **Упакуйте товар**: Обережно упакуйте товар у його оригінальну упаковку, якщо це можливо. Включіть всі аксесуари та документацію, що йшли в комплекті.
8. **Відправте товар**: Прикріпіть етикетку для повернення до пакунка і залиште його в зазначеному місці для передачі на доставку.
9. **Слідкуйте за поверненням**: Стежте за поверненням за допомогою номеру відстеження, наданого разом з етикеткою для повернення.
Якщо у вас виникли питання під час цього процесу або потрібна додаткова допомога, будь ласка, дайте знати!
Доповнення і побудова додатка
Щоб покращити відповіді моделі і додати функціональність, таку як пошук даних або їх вилучення, ми доповнюємо модель за допомогою інструментів, таких як Retrieval Augmented Generation (RAG). Тут ми використовуємо найпростіші документи (кожен з одним реченням для ілюстрації):
from langchain.chains import StuffDocumentsChain
from langchain.schema import Document
# Додаємо можливості пошуку для кращих відповідей
docs = [Document(page_content="Замовлення можна повернути протягом 30 днів."),
Document(page_content="Повернення коштів обробляються протягом 7 робочих днів.")]
qa_chain = StuffDocumentsChain(llm_chain=LLMChain(llm=llm, prompt=prompt))
answer = qa_chain({'input_documents': docs, 'question': "Скільки часу у мене є для повернення товару?"})
print(answer)
..."Звісно! Ось підтвердження і роз'яснення про процес повернення і повернення коштів:
1. **Політика повернення**: Ви зазначили, що замовлення можна повернути протягом 30 днів.
Це зазвичай означає, що у вас є до 30 днів з моменту отримання товару, щоб повернути його.
Завжди добре перевірити, чи є специфічні умови або виключення для певних товарів.
2. **Обробка повернень**: Повернення коштів обробляються протягом 7 робочих днів після того, як повернений товар буде отримано та перевірено.
Цей часовий проміжок може трохи змінюватися залежно від способу оплати або додаткового часу обробки, який потрібен вашому банку або постачальнику кредитної картки.
Якщо у вас є конкретні питання або потрібна допомога щодо повернення або відшкодування, будь ласка, дайте знати. Я можу надати більш детальну інформацію або перевірити статус вашого замовлення, якщо потрібно."
- Отримання даних: Код отримує відповідні документи (в цьому випадку два) з колекції на основі запиту.
- Доповнення: Отримані документи використовуються для доповнення процесу генерації відповіді моделі.
- Генерація: Модель генерує відповідь на основі як оригінального запиту, так і отриманих документів.
В той час як налаштування моделі фокусується на оптимізації попередньо існуючих моделей для специфічних завдань, RAG інтегрує зовнішні знання для доповнення процесу генерації контенту, надаючи додатковий контекст з отриманих документів.
Моніторинг та обслуговування
Безперервний моніторинг: Додайте етап для постійного моніторингу продуктивності моделі в реальному використанні, включаючи відстеження ключових метрик, виявлення та виправлення дрейфу і визначення областей для покращення. Детекція дрейфу для LLM — це коли ми спостерігаємо зміни у вхідних даних або поведінці моделі, що призводять до зниження продуктивності з часом. Ми розглянемо дрейф детальніше в наступній статті.
Звертайте увагу на ці важливі показники:
- Скільки часу займає отримання відповіді? (Затримка відповіді)
- Як часто нам потрібно втручатися та допомагати? (Рівень ескалації)
- Чи задоволені користувачі чат-ботом? (Задоволеність користувачів)
- Як часто чат-бот робить помилки? (Рівень помилок)
Налаштуйте автоматичні попередження, якщо:
- Чат-бот аварійно зупиняється або перестає працювати. (Системні помилки)
- Чат-бот починає сповільнюватися або стає менш точним. (Зниження продуктивності)
- Спостерігаються незвичні поведінкові патерни. (Незвичайна поведінка)
Регулярне обслуговування: Включіть положення щодо регулярних оновлень моделі, повторного навчання та обслуговування для забезпечення сталої продуктивності та вирішення нових проблем.
Міркування з безпеки
І наостанок:
- Реалізуйте обмеження частоти: обмежте, як часто люди можуть використовувати модель: це допоможе запобігти зловживанню.
- Валідація введених даних: ретельно перевіряйте введення користувачів. Переконайтеся, що вони є дійсними та безпечними.
- Слідкуйте за ін'єкцією запитів: остерігайтеся спроб обдурити модель. Будьте насторожі до шкідливих введених даних.
- Регулярні перевірки безпеки: регулярно проводьте перевірки безпеки моделі.
Висновок
Створення успішного додатка на основі LLM вимагає ретельного планування та уваги до деталей. LLM сприяють розвитку багатьох захоплюючих AI проєктів сьогодні, тому розуміння того, як їх ефективно створювати, є вирішальним.
- Почніть з простого: не намагайтеся зробити все відразу.
- Відстежуйте все: вимірюйте, як добре працює модель.
- Прислухайтеся до користувачів: звертайте увагу на їх відгуки та робіть корективи.
Пам'ятайте, це не одноразова справа. Після запуску ми будемо продовжувати вчитися та вдосконалюватися. Використовуйте те, що ми вивчимо, щоб уточнити наші цілі, вибрати кращі моделі та зробити наш додаток ще кращим. Робота з LLM — це постійний шлях навчання та вдосконалення.
Примітка: Завжди перевіряйте останні найкращі практики та інструменти, оскільки ця сфера швидко розвивається.
Перекладено з: The LLM Project Lifecycle: A Practical Guide