Сьогодні більшість наших клієнтів у захваті від великих мовних моделей (LLM) і думають, як генеративний ШІ може змінити їхній бізнес. Однак впровадження таких рішень і моделей у звичайні операції є непростим завданням. У цій публікації ми обговорюємо, як реалізувати генеративні додатки штучного інтелекту за допомогою принципів MLOps, що веде до операцій базової моделі (FMOps). Крім того, ми детально зануримося в найпоширеніший варіант використання генеративного штучного інтелекту для додатків перетворення тексту в текст і операцій LLM (LLMOps), підмножини FMOps. Наступний малюнок ілюструє теми, які ми обговорюємо.
Зокрема, ми коротко представляємо принципи MLOps і зосереджуємося на основних відмінностях порівняно з FMOps і LLMOps щодо процесів, людей, вибору та оцінки моделі, конфіденційності даних і розгортання моделі. Це стосується клієнтів, які використовують їх із коробки, створюють базові моделі з нуля або налаштовують їх. Наш підхід однаково стосується як відкритих, так і власних моделей.
Резюме операційної роботи ML
Як визначено в дописі Основна дорожня карта MLOps для підприємств із Amazon SageMaker, ML та операції (MLOps) — це поєднання людей, процесів і технологій для ефективного виробництва рішень машинного навчання (ML). Щоб досягти цього, поєднання команд і персонажів має співпрацювати, як показано на малюнку нижче.
Ці команди такі:
- Команда розширеної аналітики (озеро даних і мережа даних) – Інженери з обробки даних відповідають за підготовку та прийом даних із багатьох джерел, створення конвеєрів ETL (вилучення, перетворення та завантаження) для контролю та каталогізації даних, а також за підготовку необхідних історичних даних для випадків використання ML. Ці власники даних зосереджені на наданні доступу до своїх даних кільком бізнес-підрозділам або командам.
- Команда Data Science – Науковці даних повинні зосередитися на створенні найкращої моделі на основі попередньо визначених ключових показників ефективності (KPI), що працюють у блокнотах. Після завершення фази дослідження спеціалісти з обробки даних мають співпрацювати з інженерами ML, щоб створити автоматизацію для побудови (конвеєрів ML) і розгортання моделей у виробництві за допомогою конвеєрів CI/CD.
- Ділова команда – Власник продукту несе відповідальність за визначення бізнес-обґрунтування, вимог і KPI, які будуть використовуватися для оцінки ефективності моделі. Споживачі ML – це інші зацікавлені сторони бізнесу, які використовують результати висновків (прогнози) для прийняття рішень.
- Команда платформи – Архітектори несуть відповідальність за загальну хмарну архітектуру бізнесу та за те, як всі різні служби поєднані разом. Безпека МСП переглядає архітектуру на основі політики безпеки бізнесу та потреб. Інженери MLOps несуть відповідальність за забезпечення безпечного середовища для спеціалістів із обробки даних та інженерів ML для створення сценаріїв використання ML. Зокрема, вони відповідають за стандартизацію конвеєрів CI/CD, ролей користувачів і сервісів, а також створення контейнерів, споживання моделі, тестування та методологію розгортання на основі вимог бізнесу та безпеки.
- Команда ризиків і відповідності – У більш обмежувальних середовищах аудитори відповідають за оцінку даних, коду та артефактів моделі та переконаються, що бізнес відповідає нормам, таким як конфіденційність даних.
Зауважте, що одна особа може охоплювати кілька осіб залежно від масштабу та зрілості MLOps бізнесу.
Ці персонажі потребують спеціального середовища для виконання різних процесів, як показано на наступному малюнку.
Середовища такі:
- Адміністрування платформи – Середовище адміністрування платформи – це місце, де команда платформи має доступ для створення облікових записів AWS і зв’язування потрібних користувачів і даних
- дані – Рівень даних, часто відомий як озеро даних або сітка даних, – це середовище, яке використовують інженери даних, власники та зацікавлені сторони для підготовки, взаємодії та візуалізації даних.
- Експериментація – Науковці даних використовують пісочницю або експериментальне середовище для тестування нових бібліотек і методів машинного навчання, щоб довести, що їх підтвердження концепції може вирішити бізнес-проблеми
- Побудова моделі, тестування моделі, розгортання моделі – Середовище побудови, тестування та розгортання моделі є рівнем MLOps, де науковці з даних та інженери ML співпрацюють, щоб автоматизувати та перенести дослідження у виробництво.
- Управління ML – Остання частина головоломки – це середовище керування машинним навчанням, де всі артефакти моделі та коду зберігаються, переглядаються та перевіряються відповідними особами
Наступна діаграма ілюструє еталонну архітектуру, яка вже обговорювалася в Основна дорожня карта MLOps для підприємств із Amazon SageMaker.
Кожна бізнес-підрозділ має кожен власний набір облікових записів розробки (автоматичне навчання та створення моделі), попереднього виробництва (автоматичне тестування) і виробництва (розгортання та обслуговування моделі) для створення сценаріїв використання машинного навчання, які отримують дані з централізованого або децентралізованого озера даних або даних. сітки відповідно. Усі виготовлені моделі та автоматизований код зберігаються в централізованому обліковому записі інструментів за допомогою можливостей реєстру моделей. Код інфраструктури для всіх цих облікових записів містить версії в спільному обліковому записі служби (обліковий запис розширеного керування аналітикою), який команда платформи може абстрагувати, створювати шаблони, підтримувати та повторно використовувати для адаптації до платформи MLOps кожної нової команди.
Визначення генеративного ШІ та відмінності від MLO
У класичному ML попередня комбінація людей, процесів і технологій може допомогти вам у створенні сценаріїв використання ML. Однак у генеративному штучному інтелекті характер варіантів використання вимагає або розширення цих можливостей, або нових можливостей. Одним із цих нових понять є фундаментальна модель (FM). Вони називаються так тому, що їх можна використовувати для створення широкого спектру інших моделей ШІ, як показано на наступному малюнку.
FM пройшли навчання на основі терабайтів даних і мають сотні мільярдів параметрів, щоб мати можливість передбачити наступну найкращу відповідь на основі трьох основних категорій генеративних випадків використання ШІ:
- Перетворення тексту в текст – Магістратури (LLM) пройшли підготовку на основі немаркованих даних (таких як вільний текст) і здатні передбачити наступне найкраще слово чи послідовність слів (абзаци чи довгі есе). Основні випадки використання пов’язані з людиноподібними чат-ботами, узагальненням або створенням іншого вмісту, наприклад програмного коду.
- Перетворення тексту в зображення – Дані з мітками, наприклад пари , використовувався для навчання FM, які здатні передбачити найкращу комбінацію пікселів. Прикладами використання є створення дизайну одягу або уявні персоналізовані зображення.
- Перетворення тексту в аудіо або відео – Для навчання FM можна використовувати як позначені, так і немарковані дані. Одним з головних прикладів використання генеративного ШІ є композиція музики.
Для виробництва цих генеративних випадків використання штучного інтелекту нам потрібно запозичити та розширити домен MLOps, щоб включити наступне:
- Операції FM (FMOps) – Це може створювати генеративні рішення штучного інтелекту, включаючи будь-які варіанти використання
- LLM операції (LLMOps) – Це підмножина FMOps, зосереджена на виробництві рішень на основі LLM, таких як текст у текст
Наступний малюнок ілюструє збіг цих випадків використання.
Порівняно з класичними ML і MLOps, FMOps і LLMOps відкладаються на основі чотирьох основних категорій, які ми розглядаємо в наступних розділах: люди та процеси, вибір і адаптація FM, оцінка та моніторинг FM, конфіденційність даних і розгортання моделі, а також технологічні потреби. Про моніторинг ми розповімо в окремій публікації.
Операціоналізаційний шлях для генеративного типу користувача ШІ
Щоб спростити опис процесів, нам потрібно класифікувати основні генеративні типи користувачів ШІ, як показано на малюнку нижче.
Нижче наведено типи користувачів:
- Провайдери – Користувачі, які створюють FM з нуля та надають їх як продукт іншим користувачам (точній настройці та споживачу). Вони мають глибокий досвід наскрізного машинного навчання та обробки природної мови (NLP) і навичок науки про дані, а також значні команди маркувальників і редакторів даних.
- Тонке налаштування – Користувачі, які перенавчають (точніше налаштовують) FM від постачальників відповідно до індивідуальних вимог. Вони організовують розгортання моделі як послуги для використання споживачами. Цим користувачам потрібен потужний наскрізний досвід машинного навчання та науки про дані, а також знання розгортання моделей і висновків. Потрібні також глибокі знання предметної області для налаштування, включаючи швидке проектування.
- Споживачі – Користувачі, які взаємодіють із генеративними службами штучного інтелекту від провайдерів або програм тонкого налаштування за допомогою текстових підказок або візуального інтерфейсу для виконання бажаних дій. Не потрібен досвід ML, але переважно розробники додатків або кінцеві користувачі мають розуміння можливостей сервісу. Для кращих результатів необхідна лише швидка інженерна робота.
Згідно з визначенням і необхідним досвідом ML, MLOps потрібен здебільшого постачальникам і тонким налаштуванням, тоді як споживачі можуть використовувати принципи виробництва додатків, такі як DevOps і AppDev, для створення генеративних додатків ШІ. Крім того, ми спостерігали рух серед типів користувачів, де постачальники могли стати тонкими налаштуваннями для підтримки сценаріїв використання на основі певної вертикалі (наприклад, фінансовий сектор), або споживачі могли стати тонкими налаштуваннями для досягнення більш точних результатів. Але давайте розглянемо основні процеси для кожного типу користувачів.
Подорож споживачів
Наступний малюнок ілюструє шлях споживача.
Як згадувалося раніше, споживачі повинні вибирати, тестувати та використовувати FM, взаємодіючи з ним, надаючи певні вхідні дані, інакше відомі як підказок. Підказки в контексті комп’ютерного програмування та штучного інтелекту стосуються вхідних даних, які надаються моделі чи системі для створення відповіді. Це може бути у формі тексту, команди або запитання, які система використовує для обробки та створення вихідних даних. Вихідні дані, створені FM, можуть потім використовуватися кінцевими користувачами, які також повинні мати можливість оцінювати ці результати для покращення майбутніх відповідей моделі.
Окрім цих фундаментальних процесів, ми помітили, що споживачі висловлюють бажання налаштувати модель, використовуючи функціональні можливості, які пропонують засоби тонкого налаштування. Візьмемо, наприклад, веб-сайт, який створює зображення. Тут кінцеві користувачі можуть створювати приватні облікові записи, завантажувати особисті фотографії та згодом генерувати вміст, пов’язаний із цими зображеннями (наприклад, генерувати зображення, на якому зображений кінцевий користувач на мотоциклі з мечем або знаходиться в екзотичному місці). У цьому сценарії генеративна програма штучного інтелекту, розроблена споживачем, повинна взаємодіяти з серверною частиною тонкого налаштування через API, щоб надати ці функції кінцевим користувачам.
Однак перш ніж ми заглибимося в це, давайте спершу зосередимося на шляху вибору моделі, тестування, використання, взаємодії вводу та виводу та рейтингу, як показано на наступному малюнку.
Крок 1. Зрозумійте основні можливості FM
Існує багато параметрів, які необхідно враховувати під час вибору моделей фундаменту, залежно від варіанту використання, наявних даних, нормативних актів тощо. Хороший контрольний список, хоча і не вичерпний, може бути таким:
- Власний або відкритий код FM – Запатентовані моделі часто мають фінансові витрати, але зазвичай вони пропонують кращу продуктивність (з точки зору якості згенерованого тексту чи зображення), часто розробляються та підтримуються спеціальними командами постачальників моделей, які забезпечують оптимальну продуктивність і надійність. З іншого боку, ми також спостерігаємо впровадження моделей з відкритим вихідним кодом, які, окрім того, що вони безкоштовні, пропонують додаткові переваги, оскільки є доступними та гнучкими (наприклад, кожна модель з відкритим кодом може точно налаштовуватися). Прикладом запатентованої моделі є модель Claude від Anthropic, а прикладом високопродуктивної моделі з відкритим кодом є Falcon-40B станом на липень 2023 року.
- Комерційна ліцензія – Міркування щодо ліцензування мають вирішальне значення при виборі FM. Важливо зазначити, що деякі моделі є відкритими, але їх не можна використовувати в комерційних цілях через ліцензійні обмеження або умови. Відмінності можуть бути незначними: нещодавно випущений xgen-7b-8k-база модель, наприклад, має відкритий вихідний код і придатна для комерційного використання (ліцензія Apache-2.0), тоді як інструкція, налаштована версія моделі xgen-7b-8k-inst випускається лише для дослідницьких цілей. Вибираючи FM для комерційного застосування, важливо перевірити ліцензійну угоду, зрозуміти її обмеження та переконатися, що вона відповідає запланованому використанню проекту.
- параметри – Ще одним ключовим фактором є кількість параметрів, які складаються з ваг і зміщень у нейронній мережі. Більше параметрів зазвичай означає складнішу та потенційно потужнішу модель, оскільки вона може фіксувати складніші моделі та кореляції в даних. Однак компроміс полягає в тому, що він вимагає більше обчислювальних ресурсів і, отже, коштує більше для запуску. Крім того, ми бачимо тенденцію до менших моделей, особливо в просторі з відкритим вихідним кодом (моделі від 7 до 40 мільярдів), які добре працюють, особливо після точного налаштування.
- швидкість – На швидкість моделі впливає її розмір. Великі моделі, як правило, обробляють дані повільніше (більша затримка) через підвищену обчислювальну складність. Тому вкрай важливо збалансувати потребу в моделі з високою прогностичною потужністю (часто більші моделі) з практичними вимогами до швидкості, особливо в програмах, як-от чат-боти, які вимагають відповідей у реальному або майже реальному часі.
- Розмір контекстного вікна (кількість токенів) – Контекстне вікно, визначене максимальною кількістю токенів, які можна ввести або вивести за підказку, має вирішальне значення для визначення того, скільки контексту модель може розглядати одночасно (лексема приблизно перекладається як 0.75 слова для англійської мови). Моделі з більшими контекстними вікнами можуть розуміти та генерувати довші послідовності тексту, що може бути корисним для завдань, пов’язаних із довшими розмовами чи документами.
- Набір тренінгових даних – Також важливо розуміти, на яких даних тренувався FM. Деякі моделі можна навчати на різноманітних текстових наборах даних, таких як Інтернет-дані, сценарії кодування, інструкції чи відгуки людини. Інших також можна навчати мультимодальним наборам даних, як-от поєднання текстових і графічних даних. Це може вплинути на придатність моделі для різних завдань. Крім того, організація може мати проблеми з авторським правом залежно від точних джерел, на яких навчалася модель, тому необхідно уважно перевірити набір навчальних даних.
- Якість – Якість FM може змінюватися залежно від його типу (пропрієтарний чи відкритий), розміру та того, на чому він навчався. Якість залежить від контексту, тобто те, що вважається високоякісним для однієї програми, може не бути для іншої. Наприклад, модель, навчена на Інтернет-даних, може вважатися високоякісною для створення розмовного тексту, але меншою для технічних або спеціалізованих завдань.
- Тонке налаштування – Можливість точного налаштування FM шляхом коригування вагових коефіцієнтів або шарів моделі може бути вирішальним фактором. Тонке налаштування дозволяє моделі краще адаптуватися до конкретного контексту програми, підвищуючи ефективність виконання конкретного завдання. Однак для точного налаштування потрібні додаткові обчислювальні ресурси та технічний досвід, і не всі моделі підтримують цю функцію. Моделі з відкритим кодом (загалом) завжди можна тонко налаштовувати, оскільки артефакти моделі доступні для завантаження, а користувачі можуть розширювати та використовувати їх за бажанням. Власні моделі іноді можуть пропонувати можливість тонкого налаштування.
- Існуючі навички клієнтів – На вибір FM також можуть вплинути навички та знання клієнта або команди розробників. Якщо в команді організації немає експертів зі штучного інтелекту та ML, для них краще підійде служба API. Крім того, якщо команда має великий досвід роботи з конкретним FM, можливо, було б ефективніше продовжувати використовувати його, а не витрачати час і ресурси на навчання та адаптацію до нового.
Нижче наведено приклад двох коротких списків, один для пропрієтарних моделей і один для моделей з відкритим кодом. Ви можете скласти подібні таблиці на основі ваших конкретних потреб, щоб отримати швидкий огляд доступних варіантів. Зауважте, що продуктивність і параметри цих моделей швидко змінюються і можуть бути застарілими до моменту читання, тоді як інші можливості можуть бути важливими для конкретних клієнтів, наприклад підтримувана мова.
Нижче наведено приклад відомих власних FM, доступних в AWS (липень 2023 р.).
Нижче наведено приклад відомого FM з відкритим кодом, доступного в AWS (липень 2023 р.).
Після того, як ви склали огляд із 10–20 потенційних моделей-кандидатів, необхідно ще більше уточнити цей список. У цьому розділі ми пропонуємо швидкий механізм, який дасть дві або три життєздатні остаточні моделі як кандидатів для наступного раунду.
Наступна діаграма ілюструє початковий процес відбору.
Як правило, інженери підказок, які є експертами у створенні високоякісних підказок, які дозволяють моделям штучного інтелекту розуміти та обробляти дані користувача, експериментують із різними методами для виконання того самого завдання (наприклад, підсумовування) на моделі. Ми пропонуємо, щоб ці підказки не створювалися на льоту, а систематично витягувалися з каталогу підказок. Цей каталог підказок є центральним місцем для зберігання підказок, щоб уникнути реплікацій, увімкнути контроль версій і надати спільний доступ до підказок у команді, щоб забезпечити узгодженість між різними тестувальниками підказок на різних етапах розробки, які ми представляємо в наступному розділі. Цей каталог підказок є аналогом репозиторію Git для магазину функцій. Розробник генеративного штучного інтелекту, який потенційно може бути тією самою особою, що і розробник підказок, потім повинен оцінити результат, щоб визначити, чи підійде він для програми генеративного штучного інтелекту, яку вони хочуть розробити.
Крок 2. Перевірте та оцініть топ FM
Після того, як короткий список буде скорочено приблизно до трьох FM, ми рекомендуємо етап оцінки для подальшого тестування можливостей FM і придатності для випадку використання. Залежно від наявності та характеру даних оцінки ми пропонуємо різні методи, як показано на малюнку нижче.
Спосіб використання в першу чергу залежить від того, чи позначені у вас тестові дані чи ні.
Якщо у вас є дані з мітками, ви можете використовувати їх для оцінки моделі, як ми робимо з традиційними моделями ML (введіть кілька зразків і порівняйте результати з мітками). Залежно від того, чи мають тестові дані окремі мітки (наприклад, позитивний, негативний чи нейтральний аналіз настрою) чи є неструктурованим текстом (наприклад, резюмування), ми пропонуємо різні методи оцінювання:
- Показники точності – У разі дискретних виходів (таких як аналіз настроїв) ми можемо використовувати стандартні показники точності, такі як точність, запам’ятовування та оцінка F1
- Показники подібності – Якщо вихідні дані є неструктурованими (наприклад, зведення), ми пропонуємо такі показники схожості, як ROUGE та косинусну подібність
Деякі випадки використання не піддаються одній вірній відповіді (наприклад, «Створіть коротку дитячу історію для моєї 5-річної доньки»). У таких випадках стає складніше оцінити моделі, оскільки у вас немає позначених тестових даних. Ми пропонуємо два підходи залежно від важливості людського перегляду моделі порівняно з автоматизованим оцінюванням:
- Людина в петлі (HIL) – У цьому випадку команда оперативних тестувальників перевірить відповіді моделі. Залежно від того, наскільки критичною є програма, оперативні тестери можуть переглянути 100% результатів моделі або лише зразок.
- Оцінка на основі LLM – У цьому сценарії оперативні тестери замінюються LLM, в ідеалі потужнішим (хоча, можливо, повільнішим і найдорожчим), ніж ті, що тестуються. LLM перегляне всі відповіді, згенеровані моделлю, і оцінить їх. Цей метод може призвести до нижчої якості, але це дешевший і швидший варіант оцінки, який може дати хорошу початкову оцінку продуктивності моделей.
Наприклад, ми можемо використати наступний приклад підказки для LLM, який містить вхідний запит, відповідь LLM та інструкції: «Ми хотіли б попросити ваш відгук про продуктивність помічника ШІ у відповідь на запитання користувача, яке відображається вище . Будь ласка, оцініть корисність, актуальність, точність, рівень деталізації відповіді помічника. Асистент отримує загальну оцінку за шкалою від 1 до 10, де вищий бал означає кращу загальну продуктивність».
Цей запит буде надіслано іншому LLM (EvalLLM) для оцінки. Нижче наведено приклад, коли відповідь моделі Falcon-40B було оцінено EvalLLM (у цьому випадку Claude). Ми використовуємо питання «А що, якби Суецький канал ніколи не був побудований?» Відповідь така:
Питання: що, якби Суецький канал ніколи не був побудований?
сокіл-40б-інструкт
Якби Суецький канал ніколи не був побудований, кораблям довелося б подорожувати навколо Африки, щоб перейти між Середземним і Червоним морями. Це збільшило б час і відстань до подорожі, зробивши її менш ефективною та дорожчою. Крім того, без Суецького каналу багато країн Близького Сходу та Північної Африки були б набагато менш пов’язані з рештою світу, що перешкоджає економічному та культурному розвитку.
Огляд (оцінка: 9/10)
Відповідь помічника дуже актуальна, точна та докладна. Він дає чудову відповідь на гіпотетичне запитання користувача про неіснування Суецького каналу. Асистент правильно вказує на наслідки для морських подорожей та економічний і культурний вплив на Близький Схід і Північну Африку. Однак для більш комплексної відповіді можна було б детальніше розкрити геополітичні наслідки або вплив на моделі глобальної торгівлі.
На наступному малюнку показано приклад процесу наскрізного оцінювання.
На основі цього прикладу, щоб виконати оцінку, нам потрібно надати зразки підказок, які ми зберігаємо в каталозі підказок, і оцінку з мітками або без міток набір даних на основі наших конкретних програм. Наприклад, за допомогою позначеного набору оціночних даних ми можемо надавати підказки (введення та запит), наприклад «Дайте мені повне ім’я прем’єр-міністра Великобританії у 2023 році», а також результати та відповіді, наприклад «Ріші Сунак». З набором даних без міток ми надаємо лише запитання чи інструкцію, наприклад «Створіть вихідний код для веб-сайту роздрібної торгівлі». Ми називаємо комбінацію оперативного каталогу та набору даних оцінки оцінка швидкого каталогу. Причина, по якій ми розрізняємо каталог підказок і каталог підказок оцінки, полягає в тому, що останній призначений для конкретного випадку використання замість загальних підказок і інструкцій (наприклад, відповіді на запитання), які містить каталог підказок.
За допомогою цього каталогу оціночних підказок наступним кроком є передача оціночних підказок найкращим FM. Результатом є набір даних результату оцінки, який містить підказки, результати кожного FM та вихідні дані з мітками разом із оцінкою (якщо вона існує). У випадку немаркованого каталогу підказок для оцінювання є додатковий крок для HIL або LLM, щоб переглянути результати та надати оцінку та відгук (як ми описали раніше). Кінцевим результатом будуть зведені результати, які об’єднують оцінки всіх вихідних даних (обчислюють середню точність або людську оцінку) і дозволяють користувачам порівнювати якість моделей.
Після збору результатів оцінки ми пропонуємо вибрати модель за кількома параметрами. Зазвичай вони зводяться до таких факторів, як точність, швидкість і вартість. На наступному малюнку показано приклад.
Кожна модель матиме сильні сторони та певні компроміси за цими параметрами. Залежно від варіанту використання, ми повинні призначити різні пріоритети цим вимірам. У попередньому прикладі ми вирішили віддати пріоритет вартості як найважливішому фактору, потім точності, а потім швидкості. Незважаючи на те, що він повільніший і не такий ефективний, як FM1, він залишається досить ефективним і значно дешевшим у розміщенні. Отже, ми можемо вибрати FM2 як найкращий вибір.
Крок 3. Розробіть генеративну серверну та інтерфейсну програму AI
На даний момент розробники генеративного штучного інтелекту вибрали правильний FM для конкретної програми за допомогою оперативних інженерів і тестувальників. Наступний крок — розпочати розробку генеративної програми ШІ. Ми розділили розробку генеративної програми штучного інтелекту на два рівні: серверний і зовнішній, як показано на малюнку нижче.
На сервері розробники генеративного штучного інтелекту включають вибраний FM у рішення та працюють разом з інженерами підказок, щоб створити автоматизацію для перетворення введення кінцевого користувача у відповідні підказки FM. Тестувальники підказок створюють необхідні записи до каталогу підказок для автоматичного або ручного (HIL або LLM) тестування. Потім розробники генеративного штучного інтелекту створюють ланцюжок підказок і механізм додатків для отримання кінцевого результату. У цьому контексті ланцюжок підказок є технікою для створення більш динамічних і контекстно-залежних програм LLM. Він працює, розбиваючи складне завдання на низку менших, більш керованих підзавдань. Наприклад, якщо ми задаємо LLM питання «Де народився прем’єр-міністр Великої Британії та як далеко це місце від Лондона», завдання можна розбити на окремі підказки, де підказка може бути побудована на основі відповіді попередньої оперативної оцінки, наприклад «Хто є прем’єр-міністром Великобританії», «Яке місце їхнього народження» та «Як далеко це місце від Лондона?» Щоб забезпечити певну якість введення та виведення, розробникам генеративного штучного інтелекту також необхідно створити механізм для моніторингу та фільтрації вхідних даних кінцевого користувача та вихідних даних додатків. Якщо, наприклад, програма LLM має уникати токсичних запитів і відповідей, вони можуть застосувати детектор токсичності для введення та виведення та відфільтрувати їх. Нарешті, вони повинні забезпечити механізм рейтингу, який підтримуватиме розширення каталогу підказок для оцінювання хорошими та поганими прикладами. Більш детальне представлення цих механізмів буде представлено в наступних публікаціях.
Щоб надати функціональні можливості генеративному кінцевому користувачеві ШІ, необхідна розробка зовнішнього веб-сайту, який взаємодіє з серверною частиною. Таким чином, особи DevOps і AppDevs (розробники додатків у хмарі) повинні дотримуватися найкращих практик розробки, щоб реалізувати функціональні можливості введення/виведення та оцінювання.
На додаток до цієї базової функціональності, інтерфейс і бекенд повинні включати функцію створення особистих облікових записів користувачів, завантаження даних, ініціювання тонкого налаштування як чорного ящика та використання персоналізованої моделі замість базової FM. Виробництво генеративної програми ШІ подібне до звичайної програми. На наступному малюнку зображено приклад архітектури.
У цій архітектурі розробники генеративного штучного інтелекту, розробники підказок і DevOps або AppDevs створюють і тестують програму вручну, розгортаючи її через CI/CD у середовищі розробки (generative AI App Dev на попередньому малюнку), використовуючи спеціальні сховища коду та об’єднуючи з гілка розробників. На цьому етапі розробники генеративного штучного інтелекту використовуватимуть відповідний FM, викликаючи API, як це було надано постачальниками FM тонкого налаштування. Потім, щоб широко протестувати програму, їм потрібно просунути код до тестової гілки, яка ініціює розгортання через CI/CD у попередньому середовищі (generative AI App Pre-prod). У цьому середовищі підказкові тестери повинні спробувати велику кількість швидких комбінацій і переглянути результати. Комбінацію підказок, виходів і перегляду потрібно перемістити в каталог підказок оцінювання, щоб автоматизувати процес тестування в майбутньому. Після цього масштабного тестування останнім кроком є просування генеративної програми AI до виробництва через CI/CD шляхом злиття з основною гілкою (generative AI App Prod). Зауважте, що всі дані, включно з каталогом підказок, оціночними даними та результатами, даними та метаданими кінцевого користувача, а також точно налаштованими метаданими моделі, потрібно зберігати в озері даних або шарі сітки даних. Конвеєри та репозиторії CI/CD потрібно зберігати в окремому обліковому записі інструментів (подібному до описаного для MLOps).
Подорож провайдерів
Провайдери FM повинні навчати FM, наприклад, моделі глибокого навчання. Для них необхідний наскрізний життєвий цикл і інфраструктура MLOps. Необхідні доповнення для підготовки історичних даних, оцінки моделі та моніторингу. Наступний малюнок ілюструє їхню подорож.
У класичному машинному обігу історичні дані найчастіше створюються шляхом передачі реальних даних через конвеєри ETL. Наприклад, у сценарії використання передбачення відтоку автоматизація оновлює таблицю бази даних на основі нового статусу клієнта, який автоматично відтікає/не відтікає. У випадку FM, їм потрібні мільярди позначених або немаркованих точок даних. У випадках використання перетворення тексту в зображення команда спеціалістів із розмітки даних повинна розмітити пари вручну. Це дорогий захід, який потребує великої кількості людських ресурсів. Amazon SageMaker Ground Truth Plus може надати команду етикетувальників для виконання цієї діяльності за вас. У деяких випадках використання цей процес можна також частково автоматизувати, наприклад, за допомогою CLIP-подібних моделей. У випадку LLM, наприклад, тексту в текст, дані не позначені. Однак їх потрібно підготувати та відповідати формату існуючих історичних даних без міток. Тому редактори даних необхідні для виконання необхідної підготовки даних і забезпечення узгодженості.
З підготовленими історичними даними наступним кроком є навчання та виробництво моделі. Зауважте, що можна використовувати ті самі методи оцінки, які ми описали для споживачів.
Подорож тонких налаштувань
Метою тонкого налаштування є адаптація існуючого FM до конкретного контексту. Наприклад, FM-модель може підсумовувати текст загального призначення, але не точно фінансовий звіт, або не може генерувати вихідний код для непоширеної мови програмування. У таких випадках фахівцям з тонкого налаштування потрібно позначити дані, точно налаштувати модель, запустивши навчальну роботу, розгорнути модель, протестувати її на основі процесів споживача та контролювати модель. Наступна діаграма ілюструє цей процес.
На даний момент існує два механізми тонкого налаштування:
- Тонка настройка – Використовуючи FM і позначені дані, навчальна робота перераховує ваги та зміщення рівнів моделі глибокого навчання. Цей процес може бути трудомістким і вимагає репрезентативної кількості даних, але може генерувати точні результати.
- Точне налаштування параметрів (PEFT) – Замість того, щоб перераховувати всі ваги та зміщення, дослідники показали, що, додаючи додаткові невеликі шари до моделей глибокого навчання, вони можуть досягти задовільних результатів (наприклад, Лора). PEFT вимагає меншої обчислювальної потужності, ніж глибоке тонке налаштування та навчальна робота з меншою кількістю вхідних даних. Недоліком є потенційно менша точність.
Наступна діаграма ілюструє ці механізми.
Тепер, коли ми визначили два основні методи тонкого налаштування, наступним кроком є визначення того, як ми можемо розгорнути та використовувати ФМ із відкритим вихідним кодом і пропрієтарний FM.
За допомогою FM з відкритим вихідним кодом спеціалісти з точного налаштування можуть завантажити артефакт моделі та вихідний код з Інтернету, наприклад, за допомогою Hugging Face Model Hub. Це дає вам можливість глибоко налаштувати модель, зберегти її в локальному реєстрі моделі та розгорнути в Amazon SageMaker кінцева точка. Для цього процесу потрібне підключення до Інтернету. Щоб підтримувати більш безпечне середовище (наприклад, для клієнтів у фінансовому секторі), ви можете завантажити модель на місці, запустити всі необхідні перевірки безпеки та завантажити їх у локальний сегмент облікового запису AWS. Тоді настроювачі використовують FM з локального відра без підключення до Інтернету. Це забезпечує конфіденційність даних, і дані не переміщуються через Інтернет. Наступна діаграма ілюструє цей метод.
З пропрієтарними FM процес розгортання відрізняється, оскільки налагоджувачі не мають доступу до артефакту моделі чи вихідного коду. Моделі зберігаються у власних облікових записах AWS постачальника FM і реєстрах моделей. Щоб розгорнути таку модель на кінцевій точці SageMaker, спеціалісти з тонкого налаштування можуть запросити лише пакет моделі, який буде розгорнуто безпосередньо на кінцевій точці. Цей процес вимагає використання даних клієнтів у власних облікових записах провайдерів FM, що викликає питання щодо використання конфіденційних даних клієнтів у віддаленому обліковому записі для точного налаштування, а також розміщення моделей у реєстрі моделей, який спільно використовується кількома клієнтами. . Це призводить до проблеми з кількома орендарями, яка стає складнішою, якщо власним FM-провайдерам потрібно обслуговувати ці моделі. Якщо тонкі налаштування використовують Amazon Bedrock, ці проблеми вирішено — дані не передаються через Інтернет, а FM-провайдери не мають доступу до даних тонкого налаштування. Ті самі проблеми стосуються моделей з відкритим вихідним кодом, якщо спеціалісти з тонкого налаштування хочуть обслуговувати моделі від кількох клієнтів, як, наприклад, у прикладі, який ми наводили раніше з веб-сайтом, на який тисячі клієнтів завантажуватимуть персоналізовані зображення. Однак ці сценарії можна вважати контрольованими, оскільки задіяно лише тонке налаштування. Наступна діаграма ілюструє цей метод.
З технологічної точки зору архітектура, яку має підтримувати тонке налаштування, схожа на архітектуру MLOps (див. наступний малюнок). Точне налаштування потрібно проводити в розробнику шляхом створення конвеєрів ML, наприклад за допомогою Трубопроводи Amazon SageMaker; виконання попередньої обробки, тонкого налаштування (навчальна робота) і постобробки; і надсилання точно налаштованих моделей до локального реєстру моделей у випадку FM з відкритим вихідним кодом (в іншому випадку нова модель буде збережена у власному середовищі надання FM). Потім, під час підготовки до виробництва, нам потрібно протестувати модель, як ми описуємо, для сценарію споживачів. Нарешті, модель буде обслуговуватися та контролюватись у виробництві. Зауважте, що для поточного (точно налаштованого) FM потрібні кінцеві точки екземпляра GPU. Якщо нам потрібно розгорнути кожну налаштовану модель на окремій кінцевій точці, це може збільшити вартість у випадку сотень моделей. Тому нам потрібно використовувати мультимодельні кінцеві точки та вирішити проблему з кількома орендарями.
Спеціалісти з тонкого налаштування адаптують модель FM на основі конкретного контексту, щоб використовувати її для своїх бізнес-цілей. Це означає, що більшу частину часу спеціалісти з тонкого налаштування також є споживачами, яким необхідно підтримувати всі рівні, як ми описали в попередніх розділах, включаючи розробку генеративних додатків штучного інтелекту, озеро даних і мережу даних, а також MLOps.
Наступний малюнок ілюструє повний життєвий цикл тонкого налаштування FM, який потрібно налаштувати для генеративного кінцевого користувача ШІ.
Наступний малюнок ілюструє основні кроки.
Основні кроки:
- Кінцевий користувач створює особистий обліковий запис і завантажує особисті дані.
- Дані зберігаються в озері даних і попередньо обробляються відповідно до формату, який очікує FM.
- Це запускає тонкий конвеєр ML, який додає модель до реєстру моделей,
- З цього моменту модель або розгортається у виробництві з мінімальним тестуванням, або модель проштовхує широке тестування за допомогою HIL і ручних воріт для затвердження.
- Досконала модель доступна для кінцевих користувачів.
Оскільки ця інфраструктура є складною для некорпоративних клієнтів, AWS випустила Amazon Bedrock, щоб розвантажити зусилля зі створення таких архітектур і наблизити налаштовані FM до виробництва.
Персонажі FMOps і LLMOps і диференціатори процесів
На основі попередніх типів подорожей користувача (споживач, виробник і тонке налаштування) потрібні нові персони з певними навичками, як показано на малюнку нижче.
Нові персонажі такі:
- Маркери та редактори даних – Ці користувачі позначають дані, наприклад пари або підготувати немарковані дані, наприклад довільний текст, і розширити команду розширеної аналітики та середовища озера даних.
- Тонке налаштування – Ці користувачі мають глибокі знання про FM і знають, як їх налаштувати, розширюючи групу наукових даних, яка зосередиться на класичному ML.
- Generative AI розробники – Вони мають глибокі знання щодо вибору FM, зв’язування підказок і додатків, а також фільтрації вхідних і вихідних даних. Вони належать до нової команди — команди генеративних програм ШІ.
- Підкажіть інженери – Ці користувачі розробляють вхідні та вихідні підказки, щоб адаптувати рішення до контексту та протестувати та створити початкову версію каталогу підказок. Їхня команда — команда генеративних додатків ШІ.
- Підкажіть тестери – Вони тестують у масштабі генеративне рішення штучного інтелекту (бекенд і зовнішній інтерфейс) і передають свої результати для розширення швидкого каталогу та набору даних оцінки. Їхня команда — команда генеративних додатків ШІ.
- AppDev і DevOps – Вони розробляють інтерфейс (наприклад, веб-сайт) генеративної програми ШІ. Їхня команда — команда генеративних додатків ШІ.
- Генеративні кінцеві користувачі ШІ – Ці користувачі використовують генеративні програми штучного інтелекту як чорні скриньки, обмінюються даними та оцінюють якість результату.
Розширену версію карти процесу MLOps для включення генеративного ШІ можна проілюструвати наступним малюнком.
Новий прикладний рівень — це середовище, де генеративні розробники штучного інтелекту, інженери швидкої обробки та тестувальники, а також AppDevs створили серверну та зовнішню частину програм генеративного штучного інтелекту. Кінцеві користувачі генеративного ШІ взаємодіють із передньою частиною додатків генеративного ШІ через Інтернет (наприклад, веб-інтерфейс користувача). З іншого боку, розмічники даних і редактори повинні попередньо обробляти дані без доступу до серверної частини озера даних або сітки даних. Тому веб-інтерфейс (веб-сайт) з редактором необхідний для безпечної взаємодії з даними. SageMaker Ground Truth надає цю функцію з коробки.
Висновок
MLOs може допомогти нам ефективно створювати моделі ML. Однак для введення в дію генеративних програм штучного інтелекту потрібні додаткові навички, процеси та технології, що призведе до FMOps і LLMOps. У цій публікації ми визначили основні концепції FMOps і LLMOps і описали ключові відмінності порівняно з можливостями MLOps з точки зору людей, процесів, технологій, вибору моделі FM та оцінки. Крім того, ми проілюстрували процес мислення розробника генеративного ШІ та життєвий цикл розробки генеративної програми ШІ.
У майбутньому ми зосередимося на наданні рішень для обговорюваної області та надамо більш детальну інформацію про те, як інтегрувати FM-моніторинг (наприклад, токсичність, упередження та галюцинації) і архітектурні шаблони сторонніх або приватних джерел даних, як-от Доповнена генерація пошуку (RAG) у FMOps/LLMOps.
Щоб дізнатися більше, див Основна дорожня карта MLOps для підприємств із Amazon SageMaker і випробувати наскрізне рішення в Впровадження практик MLOps за допомогою попередньо навчених моделей Amazon SageMaker JumpStart.
Якщо у вас є коментарі чи запитання, залиште їх у розділі коментарів.
Про авторів
Доктор Сократіс Картакіс є старшим фахівцем з машинного навчання та операційним процесом, архітектором рішень для Amazon Web Services. Sokratis зосереджується на тому, щоб дозволити корпоративним клієнтам індустріалізувати свої рішення машинного навчання (ML), використовуючи сервіси AWS і формуючи свою операційну модель, тобто основу MLOps, і дорожню карту трансформації, використовуючи найкращі практики розробки. Він присвятив понад 15 років винаходу, розробці, керівництву та впровадженню інноваційних наскрізних рішень ML та Інтернету речей (IoT) у сферах енергетики, роздрібної торгівлі, охорони здоров’я, фінансів/банківської справи, автоспорту тощо. Сократіс любить проводити вільний час із родиною та друзями або кататися на мотоциклах.
Хайко Хоц є старшим архітектором рішень для штучного інтелекту та машинного навчання з особливою увагою до обробки природної мови, великих мовних моделей і генеративного штучного інтелекту. До цієї посади він був керівником відділу обробки даних у відділі обслуговування клієнтів Amazon в ЄС. Heiko допомагає нашим клієнтам досягти успіху на шляху штучного інтелекту/ML на AWS і співпрацює з організаціями в багатьох галузях, зокрема страхування, фінансові послуги, медіа та розваги, охорона здоров’я, комунальні послуги та виробництво. У вільний час Хейко якомога більше подорожує.
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
- PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
- ПлатонЕСГ. Автомобільні / електромобілі, вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
- PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
- ChartPrime. Розвивайте свою торгову гру за допомогою ChartPrime. Доступ тут.
- BlockOffsets. Модернізація екологічної компенсаційної власності. Доступ тут.
- джерело: https://aws.amazon.com/blogs/machine-learning/fmops-llmops-operationalize-generative-ai-and-differences-with-mlops/
- : має
- :є
- : ні
- :де
- $UP
- 1
- 10
- 100
- 2023
- 23
- 7
- 75
- a
- здатність
- Здатний
- МЕНЮ
- вище
- РЕЗЮМЕ
- доступ
- доступною
- доступ до
- рахунки
- Рахунки
- точність
- точний
- точно
- Achieve
- дії
- діяльність
- пристосовувати
- адаптація
- додавати
- додати
- доповнення
- Додатковий
- Додатково
- доповнення
- Додає
- адміністрація
- Прийняття
- просунутий
- Африка
- після
- Угода
- AI
- ШІ та машинне навчання
- AI помічник
- Моделі AI
- Послуги ШІ
- випадки використання ai
- AI / ML
- мета
- Вирівнює
- ВСІ
- дозволяти
- дозволяє
- по
- вже
- Також
- хоча
- завжди
- Amazon
- Amazon SageMaker
- Amazon SageMaker JumpStart
- Amazon Web Services
- серед
- кількість
- an
- аналіз
- аналітика
- та
- та інфраструктури
- Інший
- відповідь
- Відповіді
- будь-який
- API
- Інтерфейси
- додаток
- додаток
- Розробка додатка
- застосування
- Застосовувати
- підхід
- підходи
- відповідний
- твердження
- приблизно
- архітектори
- архітектурний
- архітектура
- ЕСТЬ
- навколо
- AS
- Оцінювання
- Помічник
- At
- аудит
- Аудитори
- збільшено
- автоматизувати
- Автоматизований
- автоматичний
- автоматично
- Автоматизація
- наявність
- доступний
- середній
- уникнути
- AWS
- Backend
- поганий
- Balance
- заснований
- основний
- BE
- оскільки
- ставати
- стає
- було
- перед тим
- буття
- еталонний тест
- Переваги
- КРАЩЕ
- Краще
- між
- зміщення
- упередження
- Мільярд
- мільярди
- Black
- народжений
- запозичувати
- обидва
- боти
- Box
- коробки
- Філія
- Розрив
- коротко
- Приведення
- Зламаний
- будувати
- Створюємо
- побудований
- бізнес
- але
- by
- обчислювати
- call
- званий
- покликання
- CAN
- кандидат
- кандидатів
- можливості
- можливості
- захоплення
- випадок
- випадків
- каталог
- категорії
- центральний
- централізована
- певний
- виклик
- проблеми
- складні
- зміна
- chatbots
- більш дешевий
- Перевірки
- вибір
- Вибираючи
- classic
- тісно
- ближче
- одяг
- хмара
- код
- Кодування
- співпрацювати
- поєднання
- комбінації
- об'єднувати
- Приходити
- коментарі
- комерційний
- комерційно
- загальний
- порівняти
- порівняний
- повний
- завершення
- комплекс
- складність
- дотримання
- поступливий
- склад
- всеосяжний
- обчислювальна потужність
- комп'ютер
- сконцентрувати
- концепція
- поняття
- Турбота
- Умови
- Проводити
- проводиться
- підключений
- зв'язку
- Отже
- Вважати
- міркування
- вважається
- споживати
- споживач
- Споживачі
- споживання
- Контейнер
- містить
- зміст
- контент-створення
- контекст
- продовжувати
- контроль
- діалоговий
- розмови
- авторське право
- Відповідний
- Коштувати
- дорого
- витрати
- може
- країни
- обкладинка
- покритий
- створювати
- створений
- створює
- створення
- створення
- критичний
- вирішальне значення
- культурний
- Поточний
- виготовлений на замовлення
- клієнт
- дані про клієнтів
- Контакти
- Клієнти
- дані
- Озеро даних
- точки даних
- Підготовка даних
- конфіденційність даних
- наука про дані
- Database
- набори даних
- Децентралізований
- Вирішивши
- рішення
- присвячених
- глибокий
- глибоке занурення
- глибоке навчання
- певний
- визначаючи
- визначення
- Визначення
- доставляти
- заглиблюватися
- Попит
- Залежно
- залежить
- із зображенням
- розгортання
- розгорнути
- розгортання
- розгортання
- описувати
- описаний
- description
- дизайн
- призначений
- проектування
- бажання
- бажаний
- докладно
- деталі
- Визначати
- визначення
- DEV
- розвивати
- розвиненою
- Розробник
- розробників
- розвивається
- розробка
- команда розвитку
- Відмінності
- різний
- диференціювати
- розміри
- безпосередньо
- обговорювати
- обговорювалися
- displayed
- відстань
- занурення
- Різне
- do
- документація
- Ні
- домен
- домени
- Не знаю
- вниз
- скачати
- управляти
- два
- динамічний
- e
- кожен
- Раніше
- Схід
- легко
- Економічний
- редактор
- Ефективний
- ефективний
- продуктивно
- зусилля
- або
- розроблений
- обраний
- включіть
- дозволяє
- кінець
- кінець в кінець
- Кінцева точка
- енергія
- інженер
- Машинобудування
- Інженери
- англійська
- підвищувати
- забезпечувати
- гарантує
- підприємство
- підприємств
- розваги
- Навколишнє середовище
- середовищах
- однаково
- особливо
- істотний
- і т.д.
- EU
- оцінювати
- оцінюється
- оцінка
- Навіть
- Кожен
- приклад
- Приклади
- відмінно
- збуджений
- Здійснювати
- існуючий
- існує
- Екзотичний
- чекає
- дорогий
- досвід
- експеримент
- експертиза
- experts
- експлуатація
- продовжити
- розширення
- розширення
- обширний
- Великий досвід
- широко
- витяг
- f1
- Face
- фактор
- фактори
- Знайомство
- сім'я
- далеко
- швидше
- особливість
- зворотний зв'язок
- годування
- Рисунок
- фільтрувати
- фільтрація
- остаточний
- в кінці кінців
- фінансовий
- фінансовий звіт
- Фінансовий сектор
- фінансові послуги
- Перший
- відповідати
- Гнучкість
- гнучкий
- Сфокусувати
- увагу
- фокусується
- фокусування
- стежити
- потім
- після
- слідує
- для
- Для споживачів
- форма
- формат
- фонд
- чотири
- Безкоштовна
- друзі
- від
- перед
- передня частина
- Frontend
- Повний
- функціональність
- фундаментальний
- далі
- Крім того
- майбутнє
- Гейтс
- калібр
- Загальне
- Головна мета
- в цілому
- породжувати
- генерується
- генерує
- породжує
- покоління
- генеративний
- Генеративний ШІ
- геополітичний
- отримати
- Git
- даний
- дає
- Глобальний
- світової торгівлі
- добре
- управління
- GPU
- Земля
- було
- рука
- Запрягання
- Мати
- має
- he
- голова
- здоров'я
- охорона здоров'я
- допомога
- допомагає
- тут
- Високий
- високоякісний
- вище
- дуже
- його
- історичний
- тримати
- господар
- відбувся
- Як
- How To
- Однак
- HTML
- HTTPS
- людина
- Сотні
- i
- в ідеалі
- if
- ілюструє
- зображення
- зображень
- уявний
- Impact
- здійснювати
- реалізації
- наслідки
- значення
- важливо
- поліпшення
- in
- включати
- includes
- У тому числі
- включати
- Augmenter
- збільшений
- вказує
- індикатори
- індивідуальний
- промисловості
- вплив
- під впливом
- Інфраструктура
- початковий
- інноваційний
- вхід
- витрати
- екземпляр
- замість
- інструкції
- страхування
- інтегрувати
- призначених
- взаємодіяти
- взаємодіючих
- взаємодія
- взаємодіє
- інтерфейс
- інтернет
- internet connection
- Інтернет речей
- в
- вводити
- інвестування
- залучений
- за участю
- КАТО
- IT
- ЙОГО
- робота
- подорож
- Подорожі
- липень
- просто
- ключ
- ключовий фактор
- Дитина
- Знати
- знання
- відомий
- етикетка
- етикетки
- озеро
- мова
- великий
- більше
- останній
- Затримка
- шар
- шарів
- провідний
- Веде за собою
- УЧИТЬСЯ
- вивчення
- Залишати
- позичити
- менше
- рівень
- використання
- libraries
- ліцензія
- ліцензування
- Життєвий цикл
- як
- Сподобалося
- недоліки
- LINK
- LLM
- загрузка
- місцевий
- розташований
- розташування
- Лондон
- Довго
- довше
- знизити
- машина
- навчання за допомогою машини
- made
- головний
- підтримувати
- Більшість
- Робить
- керований
- обов'язковий
- керівництво
- вручну
- виробництво
- багато
- карта
- масивний
- зрілість
- максимальний
- Може..
- me
- сенс
- засоби
- механізм
- механізми
- Медіа
- Середземне море
- згаданий
- злиття
- сітці
- метадані
- метод
- Методологія
- методика
- Метрика
- Середній
- середній Схід
- може бути
- мінімальний
- ML
- MLOps
- модель
- Моделі
- монітор
- контрольований
- моніторинг
- більше
- більш ефективний
- найбільш
- в основному
- Автоспорт
- рухатися
- переїхав
- руху
- багато
- множинний
- музика
- повинен
- my
- ім'я
- Природний
- Обробка природних мов
- природа
- Переміщення
- необхідно
- Необхідність
- необхідний
- потреби
- негативний
- мережу
- нейронної мережі
- Нейтральний
- ніколи
- Нові
- нещодавно
- наступний
- nlp
- немає
- нормальний
- На північ
- Помітний
- номер
- спостерігати
- of
- пропонувати
- запропонований
- часто
- on
- На борту
- ONE
- ті,
- тільки
- відкрити
- з відкритим вихідним кодом
- операційний
- операції
- оптимальний
- варіант
- Опції
- or
- організація
- організації
- Інше
- інші
- інакше
- наші
- з
- Результат
- вихід
- над
- загальний
- огляд
- власний
- власник
- Власники
- пакет
- пар
- параметри
- моделі
- Люди
- для
- Виконувати
- продуктивність
- виконанні
- може бути
- людина
- персонал
- Персоналізовані
- перспектива
- фаза
- фотографії
- частина
- трубопровід
- місце
- платформа
- plato
- Інформація про дані Платона
- PlatoData
- будь ласка
- точка
- точок
- Політика
- позитивний
- володіти
- це можливо
- пошта
- Пости
- потенціал
- потенційно
- влада
- потужний
- Практичний
- практики
- Точність
- передбачати
- прогноз
- Прогнози
- підготовка
- Готувати
- підготовлений
- підготовка
- представлений
- попередній
- раніше
- Prime
- прем'єр-міністр
- Принципи
- попередній
- Пріоритетність
- недоторканність приватного життя
- приватний
- Проблема
- процес
- процеси
- обробка
- Вироблений
- виробник
- Product
- Production
- Програмування
- проект
- сприяти
- доказ
- доказ концепції
- пропонувати
- власником
- Доведіть
- забезпечувати
- за умови
- Постачальник
- провайдери
- забезпечує
- забезпечення
- мета
- цілей
- штовхає
- головоломка
- якість
- питання
- питань
- Швидко
- піднімається
- діапазон
- ранжування
- швидко
- ставка
- швидше
- рейтинг
- читання
- реального часу
- причина
- отримати
- рекомендувати
- червоний
- Знижений
- удосконалювати
- про
- реєстри
- реєстру
- правила
- пов'язаний
- випущений
- актуальність
- доречний
- надійність
- залишається
- віддалений
- замінити
- звітом
- Сховище
- подання
- представник
- запросити
- запитів
- вимагається
- Вимога
- Вимагається
- дослідження
- Дослідники
- ресурси
- відповідно
- відповідь
- відповіді
- відповідальний
- REST
- Обмеження
- Обмежувальний
- результат
- результати
- роздрібна торгівля
- знову використовувати
- огляд
- відгуки
- верхова їзда
- право
- Дорожня карта
- Роль
- ролі
- грубо
- круглий
- прогін
- біг
- мудрець
- то ж
- sandbox
- шкала
- Масштабування
- сценарій
- сценарії
- наука
- Вчені
- рахунок
- подряпати
- scripts
- SEA
- розділ
- розділам
- сектор
- безпечний
- безпечно
- безпеку
- політики безпеки
- побачити
- пошук
- обраний
- вибирає
- вибір
- відправка
- старший
- посланий
- настрій
- окремий
- Послідовність
- Серія
- служити
- обслуговування
- Послуги
- виступаючої
- комплект
- кілька
- формуючи
- Поділитись
- загальні
- судів
- Короткий
- Повинен
- показаний
- Шоу
- сторона
- значний
- істотно
- аналогічний
- спростити
- Розмір
- навички
- невеликий
- менше
- МСП
- So
- рішення
- Рішення
- ВИРІШИТИ
- деякі
- Source
- вихідні
- Джерела
- Простір
- спеціальний
- спеціаліст
- спеціалізований
- конкретний
- конкретно
- швидкість
- витрачати
- відпрацьований
- Стажування
- етапи
- зацікавлених сторін
- standard
- стандартизації
- старт
- Статус
- Крок
- заходи
- зберігати
- зберігати
- зберігання
- Історія
- сильні сторони
- сильний
- Згодом
- успішний
- такі
- пропонувати
- придатність
- підходящий
- підсумовувати
- РЕЗЮМЕ
- підтримка
- Підтриманий
- передбачуваний
- Переконайтеся
- SWIFT
- система
- таблиця
- Приймати
- Завдання
- завдання
- команда
- команди
- технічний
- методи
- Технології
- Технологія
- terms
- тест
- перевірений
- тестерів
- Тестування
- ніж
- Що
- Команда
- Майбутнє
- Джерело
- Великобританія
- світ
- їх
- Їх
- самі
- потім
- Там.
- отже
- Ці
- вони
- речі
- Мислення
- третя сторона
- це
- ті
- хоча?
- думка
- тисячі
- три
- час
- до
- разом
- знак
- Жетони
- топ
- теми
- до
- торгувати
- традиційний
- поїзд
- навчений
- Навчання
- Перетворення
- Перетворення
- подорожувати
- мандри
- Trend
- викликати
- правда
- Правда
- намагатися
- два
- тип
- Типи
- типово
- ui
- Uk
- розуміти
- розуміння
- блок
- одиниць
- Updates
- Завантаження
- us
- корисний
- Використання
- використання
- використання випадку
- використовуваний
- користувач
- користувачі
- використовує
- використання
- комунальні послуги
- використовувати
- різний
- перевірити
- версія
- Проти
- вертикальний
- через
- viable
- візуалізувати
- vs
- хотіти
- було
- we
- Web
- веб-сервіси
- веб-сайт
- ДОБРЕ
- Що
- Що таке
- коли
- в той час як
- Чи
- який
- в той час як
- ВООЗ
- широкий
- Широкий діапазон
- волі
- вікно
- windows
- з
- в
- без
- слово
- слова
- Work
- працювати разом
- працював
- робочий
- працює
- світ
- б
- років
- вихід
- Ти
- вашу
- зефірнет