Няма да кажа, че бях пълноценен отричащ задълбочено обучение, но упорито се сдържах, за да избегна шума на LLM. Въпреки че намирам почти всички ML изследвания за интересни, наистина съм влюбен в изследванията на ML системите, посветени на практическото внедряване на ML модели. И изглеждаше, че генеративният AI се рекламира повече като забавна играчка, за да „видите какво може да направи“, отколкото нещо осъществимо за пускане в производство.

Както обикновено, публикациите в LinkedIn започнаха да валят. Въпреки това, едва наскоро, когато същите тези публикации започнаха да преминават от „Леле, вижте този отговор“ на „Леле, вижте това приложение, което създадох“, разбрах, че вече не мога да държа главата си в пясъка. Разбрах, че по-рано, отколкото очаквах, тези приложения ще бъдат част от работата на ML системите, от която толкова се интересувам. Така че прекарах известно време в опити да разбера какво прави разработката на тези модели различна от типичните ML модели.

Как изглежда традиционният жизнен цикъл на ML?

През годините е имало много различни формати, които изследователите са използвали, за да опишат стъпките, през които преминават екипите, за да изградят ML модел. Въпреки че няма да описвам подробно тези стъпки, моля, вижте диаграмата по-долу.

Можем да видим на диаграмата два основни тръбопровода, които работят за пускане на ML модели в производство (и един контролиран от версията слой, който помага за тяхното управление). Първият тръбопровод за разработка е мястото, където учените по данни и изследователските екипи работят за разработването на модела. Във втория етап инженерите и разработчиците на ML работят, за да вземат модела си на последния етап от разработката и да го превърнат в нещо, което може да се използва за правене на прогнози в реалния свят.

Как изглежда жизненият цикъл на LLM?

Въпреки че LLMs се опитват да изработят своя собствена фраза в MLOps (LLMOps), важно е да запомните, че те все още са системи за машинно обучение. Това означава, че дори и да използват различни инструменти или фрази, те пак следват повечето от същия жизнен цикъл и най-добри практики.

Разделих жизнения цикъл на LLM на три фази, които се виждат на чертежа по-долу. В следващите раздели ще дам преглед на високо ниво на всяка фаза и как тя се отнася обратно към традиционния жизнен цикъл на ML.

Модели на основата

Отляво можем да видим най-известния аспект на тези нови LLM системи, основните модели. Основните модели са големи предварително обучени езикови модели, способни да разбират и генерират текст на естествен език. Тази способност за добро изпълнение на общи езикови задачи позволява на тези модели да служат като отправна точка за различни NLP задачи, като езиков превод, обобщаване на текст и отговаряне на въпроси.

Основните модели са най-значимото отклонение от традиционния жизнен цикъл на ML. API достъпът до базовите модели улесни екипите да използват НЛП в своите операции, независимо от индустрията или размера. Те могат да внедрят само API като техен производствен модел – пропускайки по-голямата част от работния процес на жизнения цикъл на ML – ако просто търсят възможности за общи езикови задачи.

Това е стандартен път, който виждаме, че организациите се спускат като първа итерация на пускането на LLM в производство. Това обаче вече не е забележително, тъй като всяка компания може да създаде OpenAI акаунт. Вместо това потребителите търсят персонализирани изживявания въз основа на конкретния случай на употреба за модела, с който взаимодействат. За да направят това, ML екипите трябва да използват много от своите съществуващи техники за разработване на ML модел, за да настроят фино и подобрят модела си въз основа на конкретния случай на употреба.

Забележка: Много модели на основата имат характер със затворен код поради липсата на прозрачност и достъпност на кода и данните, използвани за тяхното обучение. Потвърждаването на точността и пристрастията на модела е трудно без достъп до този код и данни. Това може да доведе до непредвидени последици и да увековечи съществуващите отклонения в данните.

развитие

Фазата на разработка е мястото, където практикуващите ML изграждат и подобряват тези модели на ML, специфични за случая на използване. Както можем да видим от диаграмите по-горе, той съществува както в традиционния жизнен цикъл, така и в LLM. Въпреки това, една ключова разлика е, че в момента има по-малко стъпки за развитие на LLM. Например, екипите не трябва да избират и тестват различни архитектури на модели. Въпреки че разработването на LLM модели несъмнено ще продължи да напредва, работният процес в момента е рационализиран в три основни стъпки:

Дефиниране на случая на използване

Въпреки че не е изрично изброено в диаграмата по-горе, първата стъпка към изграждането на всеки полезен ML модел за производство, LLM или не, е да дефинирате и разберете вашия случай на употреба. Екипите ще трябва да прекарат време със заинтересованите страни от бизнеса и продукта, за да разберат целта на модела, който пускат в производство.

Подреждане на данни и фина настройка на модела

Екипите за наука за данни трябва да подготвят и изчистват данни, специфични за случая на употреба, за да изградят LLM, специфични за случая на употреба. Тези данни ще бъдат използвани за обучение/фина настройка на разбирането на езика на модела на основата към изискванията на техните задачи.

Почистването и обработката на данни е нещо, с което екипите за наука за данни са свикнали, тъй като е част от техния традиционен жизнен цикъл на машинно обучение. Въпреки това, едно предимство от използването на LLM модели пред традиционните ML техники е, че те вече имат солидно разбиране на езика поради всички данни, върху които са били обучени първоначално. Като използват данни само за фина настройка върху съществуващ голям модел, от екипите не се изисква да подготвят и почистват толкова много данни.

Качествено валидиране с подкани

Подобно на всички традиционни ML модели, тези модели трябва да бъдат тествани и валидирани, преди да могат да взаимодействат със света в производството. В традиционните жизнени цикли на ML модели това се прави с помощта на добре установени исторически показатели и показатели. Както ще разгледаме в бъдеща публикация, това е различно с LLM.

Вместо това екипите трябва да разберат достатъчно случая на употреба, за да създадат реалистични тестове и състезателни подкани за оценка на модела. След това те могат да използват показатели, създадени за количествено определяне на основните качества на текста (като тон или контекст) спрямо примерни отговори, предоставени за всяка подкана. Освен това екипите могат да изберат да оценят качествено представянето на модела въз основа на тяхното разбиране на човешкия език и случаи на употреба.

Схема на приложението

Последният блок в нашата диаграма на жизнения цикъл на LLM е схемата на приложението. Позовавайки се на начина, по който вашият LLM се внедрява и взаимодейства с него в производството, това е подобно на процеса на производство, през който преминават ML инженерите и разработчиците, когато традиционно внедряват ML модели.

На практика това често се изгражда с бърза оркестрация, където множество подкани са верижно свързани заедно. Преди да навлезем в схемите на приложения, където си взаимодействат множество подкани, нека да разгледаме как би изглеждало това за приложение с подкана от един потребител — като „чатбот“.

Процесът на конструиране на единична подкана е по-сложен в производството, отколкото просто да се вземе въведеното от потребителя. Една концепция за LLMs, която е различна от традиционните ML модели, е, че освен фината настройка на модела, инженерите за подсказки са в състояние да „настроят фино“ входовете на потребителите към приложението по време на извода с шаблон за подкана.

Шаблон за подкана

Инженерите на подкана пишат шаблон на подкана като допълнителна стъпка от „фина настройка“ на модела. Традиционно мислим за фина настройка като добавяне на параметрични знания към модела. Това е знанието, което моделът научава по време на обучение и се съхранява в теглата (или параметрите) на модела.

От друга страна, шаблоните за подкана работят като знание за източника, добавено към модела. Това е знание, добавено по време на извод чрез входове към модела. Те предоставят допълнителна информация в допълнение към заявките за въвеждане на потребители по време на извод. Тази информация обикновено включва допълнителна основна информация, контекст и правила за отговорите на модела. За по-задълбочено потапяне в шаблоните за подкани вижте тази статия.

Бърза оркестрация

Бързото оркестриране се отнася до интерактивното свързване на подкани заедно. Някои приложения, като chatbots, може да са достатъчно прости от гледна точка на приложение, за да работят с едно основно подканяне. В производството обаче много случаи на използване на LLM всъщност са много по-сложни.

„Тази статия“ върши страхотна работа, представяйки LangChain — популярен промпт оркестратор — като използва метафората за печене на торта. Можете да помолите чатбот да ви предостави съставките за тортата, но това всъщност не е много полезно за вашата крайна цел за готова торта. Вместо това моделите трябва да могат да използват тази подкана във връзка с други подкани и действия, за да получат крайния резултат, който търсят.

Можем също да видим по-долу пример за по-„реален свят“, предоставен от статията за извличане на информация от генерирани SQL заявки. За тези, които се интересуват, можете също да видите пример от реалния свят, използващ Arthur, написан от един от нашите ML инженери, който създал чатбот за взаимодействие с нашата документация.

Забележка: В традиционните модели на машинно обучение е имало натиск в общността да признае тръбопроводите за данни като логическа единица на работата на машинното обучение, а не самия модел. Едно нещо, което намирам за интересно за моделите на LLM в производството сравнително е, че изглежда ще има натиск да се разглежда бързата оркестрация като логическа единица на работата по LLM.

Това би направило верижното свързване на подкани на практика по-подобно на това при инженеринг на данни, организиращ ETL тръбопроводи. Бързото инженерство и дизайнерите на приложения ще трябва да отделят повече време и усилия, за да определят как ще изглеждат тези диаграми и как резултатите ще бъдат валидирани и наблюдавани.

Потребителски отзиви

Измерването на производителността на генеративните модели в производството може да бъде дори по-голямо предизвикателство от вече споменатото предизвикателство за валидиране на модела по време на разработката. Екипите трябва да се ориентират в практическите ограничения, като например невъзможността за мащабиране на човешки маркери за генериране на общи показатели. Един подход, който се оказа успешен за екипите, е проследяването на обратната връзка от потребителите.

Тази обратна връзка предоставя ценна представа за това колко добре се представя техният модел, позволявайки на екипите непрекъснато да прецизират и подобряват производителността на модела. Конкретните използвани техники ще зависят от естеството на обратната връзка и желаните резултати за конкретния модел.

Заключение и поглед напред

В заключение, въпреки че LLM получават свой собствен луксозен пакет от нови инструменти и длъжности, те все още се коренят в най-добрите практики и техники, които ML общността използва от години.

  • Основни модели: служат като отправна точка за екипите за разработване на силни базови НЛП модели
  • Развитие: все същата необходимост от фина настройка и оценка на модели за конкретна крайна задача, дори ако има нови техники и длъжности
  • Схема на приложението: процес за пускане на LLM в производство, който все още трябва да бъде валидиран и наблюдаван, дори ако зависи от нови инструменти/подкани

LLM със сигурност намират своето място в производствените системи близо до вас — и то бързо. Надяваме се, че това беше информативен първи поглед върху това как те се вписват в рамките, които екипите вече използват за своите традиционни подходи за машинно обучение. Ние сме заети в Arthur да помагаме на хората да изграждат с LLMs, така че очаквайте скоро още свързано съдържание.

Това беше публикация, първоначално публикувана в блога Arthur.