A16Z: нова архітектура для додатків великих моделей

Примітка редактора: вибух генеративного штучного інтелекту має потенціал підірвати багато галузей, однією з яких є галузь програмного забезпечення. Зростання великої мовної моделі (LLM) спричинило вибух пов’язаних програм. Технологічні гіганти та стартапи запустили різноманітні програми LLM. Тож які інструменти та шаблони проектування використовують ці програми? Ця стаття підсумовує. Стаття зі збірки.

Джерело зображення: створено Unbounded AI

Великі мовні моделі (LLM) — нові потужні примітиви для розробки програмного забезпечення. Але оскільки LLM є таким новим і поводиться так не так, як звичайні обчислювальні ресурси, не завжди очевидно, як використовувати LLM.

У цій статті ми поділимося еталонною архітектурою для нового стеку програм LLM. Архітектура демонструватиме найпоширеніші системи, інструменти та шаблони проектування, які ми бачили в стартапах зі штучним інтелектом і провідних технологічних компаніях. Цей стек технологій все ще відносно примітивний і може зазнати серйозних змін у міру розвитку базової технології, але ми сподіваємося, що він може стати корисною довідкою для розробників, які сьогодні працюють над розробкою LLM.

Ця робота заснована на розмовах із засновниками та інженерами стартапів зі штучним інтелектом. Зокрема, ми покладаємося на відгуки таких людей, як Тед Бенсон, Гаррісон Чейз, Бен Фіршман, Алі Годсі, Раза Хабіб, Андрей Карпаті, Грег Коган, Джеррі Лю, Мойн Надім, Дієго Оппенгеймер, Шрея Раджпал, Іон Стойка, Денніс Сю, Матей Захарія і Джаред Зонерайх. Спасибі за вашу допомогу!

Стек технологій LLM

Поточна версія стеку програм LLM виглядає так:

Сірі поля є ключовими компонентами, а ті, що мають стрілки, представляють різні потоки даних: чорна пунктирна лінія — це контекстні дані, надані розробником програми для обмеження результату, чорна суцільна лінія — підказка та кілька прикладів, переданих LLM , синя суцільна лінія — це запит користувача, червона суцільна лінія — результат, повернутий користувачеві

Нижче наведено список посилань на кожен елемент для швидкого ознайомлення:

загальні інструменти/системи для кожного ключового компонента стеку програм

Є багато способів розвитку з LLM, включаючи навчальні моделі з нуля, тонке налаштування моделей з відкритим кодом або використання керованих API. Технологічний стек, який ми тут представляємо, базується на контекстному навчанні, шаблоні проектування, який, як ми спостерігаємо, починає використовувати більшість розробників (і наразі це можливо лише з базовими моделями).

У наступному розділі коротко пояснюється цей шаблон проектування.

Шаблон дизайну: контекстне навчання

Основна ідея контекстного навчання полягає в тому, щоб використовувати готові LLM (тобто без будь-яких тонких налаштувань), а потім контролювати їх поведінку за допомогою розумних підказок і кондиціонування приватних «контекстних» даних.

Наприклад, скажімо, ви розробляєте чат-бота, щоб відповідати на запитання щодо серії юридичних документів. Найпростішим способом можна вставити всі документи в підказку ChatGPT або GPT-4, а потім поставити відповідні запитання. Це може працювати для дуже малих наборів даних, але це не масштабується. Найбільші моделі GPT-4 можуть обробляти лише близько 50 сторінок вхідного тексту, а продуктивність (вимірювана часом і точністю висновку) значно погіршується при наближенні до так званого ліміту контекстного вікна.

Контекстне навчання вирішує цю проблему за допомогою хитрого трюку: замість того, щоб надсилати всі документи кожного разу, коли вводиться підказка LLM, воно надсилає лише кілька найбільш релевантних. Хто допоможе вирішити, які документи найбільш актуальні? Ви здогадалися... LLM.

На дуже високому рівні цей робочий процес можна розбити на три етапи:

• Попередня обробка/вбудовування даних: на цьому етапі зберігаються особисті дані (у цьому випадку юридичні документи) для подальшого пошуку. Загалом документи поділяються на фрагменти, передаються до моделі вбудовування та зберігаються в спеціальній базі даних, яка називається векторною базою даних.
• Оперативна побудова/вилучення: коли користувач надсилає запит (у цьому випадку юридичне питання), програма створює серію запитів, які потім надсилаються в мовну модель. Зібрані підказки часто поєднуються з жорстко закодованими розробником шаблонами підказок; приклади правильного результату називаються невеликими прикладами; будь-яка необхідна інформація отримується через зовнішній API; набір пов’язаних документів витягується з векторної бази даних.
• Виконання підказок/виведення підказок: після того, як підказки скомпільовано, вони надсилаються попередньо підготовленим LLM для висновку, включаючи власні API моделі, а також моделі з відкритим вихідним кодом або самонавчені моделі. На цьому етапі деякі розробники також додають операційні системи, такі як журналювання, кешування та перевірка.

Це може здатися великою роботою, але їх, як правило, легше реалізувати, ніж альтернативи: навчання LLM або налагодження самого LLM насправді важче. Для контекстного навчання вам не потрібна спеціальна команда інженерів машинного навчання. Вам також не потрібно розміщувати власну інфраструктуру або купувати дорогі виділені екземпляри від OpenAI. Ця модель ефективно зводить проблеми штучного інтелекту до проблем обробки даних, які більшість стартапів і великих корпорацій уже знають, як вирішити. Він також має тенденцію перевершувати тонке налаштування для відносно невеликих наборів даних, оскільки конкретна інформація повинна з’являтися принаймні приблизно 10 разів у навчальному наборі, перш ніж LLM можна буде точно налаштувати для запам’ятовування конкретної інформації, а контекстне навчання також може включати нову інформацію. майже в режимі реального часу.

Одне з найбільших питань у контекстному навчанні: що станеться, якщо ми просто змінимо базову модель, щоб збільшити вікно контексту? Це справді можливо, і це активна область дослідження. Але це пов’язано з деякими компромісами – в основному вартість і час висновку квадратично масштабуються з довжиною підказки. Сьогодні навіть лінійне масштабування (найкращий теоретичний результат) занадто дороге для багатьох застосувань. За нинішніх ставок API один запит GPT-4 на 10 000 сторінок коштував би сотні доларів. Таким чином, ми не передбачаємо масштабних змін у стеку на основі вікон розширеного контексту, але докладніше розглянемо це пізніше.

У решті цієї статті ми розглянемо цей стек технологій, використовуючи наведений вище робочий процес як керівництво.

Обробка/вбудовування даних

Частина обробки/вбудовування даних: передати дані у вбудовану модель через конвеєр даних для векторизації, а потім зберегти їх у векторній базі даних

Контекстні дані для програм LLM включають текстові документи, PDF-файли та навіть структуровані формати, такі як таблиці CSV або SQL. Рішення для завантаження та перетворення даних (ETL), які використовували розробники, яких ми опитали, дуже відрізнялися. Більшість використовує традиційні інструменти ETL, такі як Databricks або Airflow. Деякі також використовують переваги завантажувачів документів, вбудованих у структуру оркестровки, наприклад LangChain (на базі Unstructed) і LlamaIndex (на основі Llama Hub). Однак ми вважаємо, що ця частина технологічного стеку відносно недостатньо розроблена, і є можливість розробити рішення реплікації даних спеціально для додатків LLM.

Що стосується вбудовування, більшість розробників використовують OpenAI API, особливо модель text-embedding-ada-002. Ця модель проста у використанні (особливо якщо ви вже використовуєте інші OpenAI API), дає достатньо хороші результати та стає дешевшою. Деякі великі підприємства також вивчають Cohere, робота над продуктом якої більше зосереджена на вбудовуванні та має кращу продуктивність у деяких сценаріях. Для розробників, які віддають перевагу відкритому коду, стандартом є бібліотека Sentence Transformers від Hugging Face. Також можна створювати різні типи вбудовування залежно від варіанту використання; сьогодні це відносно нішева практика, але перспективна область досліджень.

З точки зору системи, найважливішою частиною конвеєра попередньої обробки є база даних векторів. Векторна база даних відповідає за ефективне зберігання, порівняння та отримання до мільярдів вбудованих даних (таких як векторів). Найпоширенішим варіантом, який ми бачимо на ринку, є шишка. Це за замовчуванням, його легко розпочати, оскільки він повністю розміщений у хмарі та має багато функцій, які потрібні великим підприємствам у виробництві (наприклад, хороша продуктивність у масштабі, єдиний вхід і час безвідмовної роботи SLA).

Однак існує також велика кількість векторних баз даних. Відомі з них:

• Системи з відкритим вихідним кодом, такі як Weaviate, Vespa та Qdrant: ці системи зазвичай мають чудову одновузлову продуктивність і можуть бути налаштовані для конкретних програм, що робить їх популярними серед досвідчених команд AI, які люблять розробляти спеціальні платформи.
• Faiss та ін. Нативні бібліотеки керування векторами: ці бібліотеки мають великий досвід розробників і їх легко запустити для невеликих програм і експериментів із розробкою. Але вони не обов’язково можуть замінити повні бази даних у великому масштабі.
• Розширення OLTP, як-от pgvector: чудово підходить для розробників, які бачать діри в кожній формі бази даних і намагаються підключитися до Postgres, або для підприємств, які купують більшу частину своєї інфраструктури даних у одного хмарного постачальника. Гарне рішення для підтримки векторів. Незрозуміло, чи має сенс тісно пов’язувати векторні та скалярні робочі навантаження в довгостроковій перспективі.

У майбутньому більшість компаній із відкритим кодом векторних баз даних розробляють хмарні продукти. Наше дослідження показує, що досягнення надійної продуктивності в хмарі є дуже складною проблемою в широкому просторі проектування можливих варіантів використання. Таким чином, набір варіантів може не змінитися різко в короткостроковій перспективі, але це може в довгостроковій перспективі. Ключове питання полягає в тому, чи будуть векторні бази даних консолідовані навколо однієї чи двох популярних систем, подібних до баз даних OLTP і OLAP.

Також залишається відкритим питання про те, як розвиватимуться бази даних вбудовування та векторні бази даних із розширенням вікна контексту, доступного для більшості моделей. Можна легко стверджувати, що вбудовування стає менш важливим, оскільки контекстні дані можна вставляти безпосередньо в підказку. Однак відгуки експертів з цієї теми свідчать про протилежне — що вбудовані конвеєри з часом можуть стати більш важливими. Великі контекстні вікна дійсно є потужними інструментами, але також потребують значних обчислювальних витрат. Тому вкрай важливо ефективно використовувати це вікно. Можливо, ми почнемо спостерігати, як різні типи моделей вбудовування стають популярними, навчаючись безпосередньо на кореляції моделей, а також з’являться векторні бази даних, розроблені для того, щоб уможливити та використовувати це.

Оперативна збірка та отримання

Оперативно будуємо та отримуємо

Стратегії, які спонукають до LLM і включають контекстні дані, стають все більш складними, а також використовуються як джерело диференціації продукту, і їх роль зростає. Більшість розробників починають нові проекти, експериментуючи з простими підказками, які або містять прямі інструкції (нульові підказки), або вихідні дані, які можуть містити деякі приклади (кілька підказок). Ці підказки, як правило, дають хороші результати, але не досягають рівня точності, необхідного для виробничих розгортань.

Наступний рівень трюків натяків полягає в тому, щоб базувати відповіді моделі на якомусь джерелі правди та надавати зовнішній контекст, на якому модель не навчалася. У Cue Engineering Guide міститься не менше десятка (!) більш просунутих стратегій підказок, включаючи ланцюжки думок, самоузгоджені, генеративні знання, дерева думок, спрямовані стимули тощо. Ці стратегії можна комбінувати для підтримки різних випадків використання LLM, таких як запитання та відповіді на документи, чат-боти тощо.

Тут на допомогу приходять фреймворки оркестровки, такі як LangChain і LlamaIndex. Ці фреймворки абстрагуються від багатьох деталей ланцюжка підказок; взаємодії із зовнішніми API (включно з визначенням, коли потрібен виклик API); отримання контекстних даних із векторної бази даних; і збереження пам’яті між викликами в кількох LLM. Вони також надають шаблони для багатьох поширених програм, згаданих вище. Його виходом є підказка або серія підказок, наданих мовній моделі. Ці фреймворки широко використовуються любителями, а також стартапами, які прагнуть розробляти програми, лідером з яких є LangChain.

LangChain все ще є відносно новим проектом (на даний момент у версії 0.0.201), але ми вже починаємо спостерігати, як програми, розроблені з його допомогою, надходять у виробництво. Деякі розробники, особливо перші користувачі LLM, вважають за краще перейти на необроблений Python у виробництві, щоб усунути додаткові залежності. Але ми очікуємо, що цей підхід «зроби сам» зменшиться для більшості випадків використання, як це сталося з традиційними стеками веб-програм.

Уважні читачі помітять дивний на вигляд запис у вікні макета: ChatGPT. За звичайних обставин ChatGPT — це програма, а не інструмент розробника. Але до нього також можна отримати доступ як до API. І, якщо придивитися уважніше, він виконує деякі з тих самих функцій, що й інші фреймворки оркестровки, наприклад: абстрагування від потреби в спеціальних підказках; підтримка стану; отримання контекстних даних через плагіни, API або інші джерела. Хоча ChatGPT не є прямим конкурентом інших перелічених тут інструментів, його можна вважати альтернативним рішенням і в кінцевому підсумку стати життєздатною та легкою альтернативою швидкому створенню.

Виконання підказки/міркування

Виконання підказки/міркування

Сьогодні OpenAI є лідером у сфері мовних моделей. Майже кожен розробник, з яким ми опитали, запустив нову програму LLM за допомогою OpenAI API, зазвичай вони використовують модель gpt-4 або gpt-4-32k. Це забезпечує найкращий сценарій використання для продуктивності програми та простий у використанні, оскільки він може використовувати широкий спектр доменів введення та зазвичай не потребує тонкого налаштування чи самостійного розміщення.

Щойно проект знаходиться у виробництві та починає масштабуватися, у гру може вступити більш широкий спектр опцій. Деякі поширені запитання, які ми чуємо, включають:

• Перейдіть на gpt-3.5-turbo: це приблизно в 50 разів дешевше, ніж GPT-4, і значно швидше. Багатьом програмам не потрібна точність рівня GPT-4, але вона потрібна для висновків із низькою затримкою та рентабельної підтримки безкоштовних користувачів. *Експериментували з іншими пропрієтарними постачальниками (особливо з моделлю Claude від Anthropic): Claude пропонує швидкий висновок, точність рівня GPT-3.5, більше можливостей налаштування для великих клієнтів і контекстні вікна до 100 Кб (хоча ми виявили, що точність зменшується зі збільшенням довжини вхідних даних) .
• Класифікуйте часткові запити для моделей з відкритим вихідним кодом: це особливо ефективно для великих випадків використання B2C, таких як пошук або чат, де складність запитів сильно відрізняється, а безкоштовні користувачі потребують дешевого обслуговування:

1. Зазвичай це має найбільший сенс у поєднанні з тонким налаштуванням базової моделі з відкритим кодом. Ми не будемо заглиблюватися в цей набір інструментів у цій статті, але такі платформи, як Databricks, Anyscale, Mosaic, Modal і RunPod, все частіше використовуються командами інженерів.

2. Моделі з відкритим вихідним кодом можуть використовувати кілька варіантів висновків, включаючи простий інтерфейс API Hugging Face і Replicate; необроблені обчислювальні ресурси від основних хмарних постачальників; і хмарні продукти (упевнена хмара) з більш чіткими параметрами, подібними до перелічених вище.

Наразі модель з відкритим кодом відстає від пропрієтарних продуктів, але розрив починає скорочуватися. Модель LLaMa від Meta встановила нові стандарти точності з відкритим кодом і породила низку варіантів. Оскільки LLaMa має ліцензію лише на дослідницьке використання, багато нових постачальників почали навчати альтернативні базові моделі (наприклад, Together, Mosaic, Falcon, Mistral). Meta все ще обговорює, чи запускати справжню версію LLaMa 2 з відкритим кодом.

Коли (не якщо) LLM з відкритим вихідним кодом досягне рівня точності, порівнянного з GPT-3.5, ми очікуємо, що текст також матиме власний момент стабільного розповсюдження з широкомасштабним експериментуванням, обміном і тонким налаштуванням моделей, які перейдуть у виробництво. Такі хостингові компанії, як Replicate, почали додавати інструменти, щоб зробити ці моделі більш доступними для розробників програмного забезпечення. Розробники все більше вірять, що менші, точно налаштовані моделі можуть досягти найсучаснішої точності для вузького діапазону випадків використання.

Більшість розробників, які ми опитали, не мали глибокого розуміння операційних інструментів LLM. Кешування є відносно поширеним (часто на основі Redis), оскільки це покращує час відповіді програми та зменшує витрати. Досить широко використовуються такі інструменти, як Weights & Biases з MLflow (перенесений із традиційного машинного навчання) або Layer with Helicone (створений для LLM). Ці інструменти можуть записувати, відстежувати та оцінювати результат LLM, часто з метою покращення конструкції наконечників, налаштування трубопроводів або вибору моделей. Також розробляється багато нових інструментів для перевірки виходу LLM (наприклад, Guardrails) або виявлення атак ін’єкції підказок (наприклад, Rebuff). Більшість із цих операційних інструментів заохочують своїх власних клієнтів Python виконувати виклики LLM, тому буде цікаво побачити, як ці рішення співіснують з часом.

Нарешті, статичну частину програми LLM (тобто все, крім моделі) також потрібно десь розмістити. Безумовно, найпоширенішими рішеннями, які ми бачили, є стандартні варіанти, такі як Vercel або основні хмарні постачальники. Проте з’являються дві нові категорії. Такі стартапи, як Steamship, надають наскрізний хостинг для програм LLM, включаючи оркестровку (LangChain), мультитенантний контекст даних, асинхронні завдання, векторне зберігання та керування ключами. Такі компанії, як Anyscale і Modal, дозволяють розробникам розміщувати моделі та код Python в одному місці.

А як щодо проксі?

Одним із найважливіших компонентів, відсутніх у цій еталонній архітектурі, є структура агента штучного інтелекту. AutoGPT описували як «експериментальну спробу з відкритим вихідним кодом повністю автоматизувати GPT-4», і цієї весни він став репозиторієм Github, який найшвидше розвивається в історії, і майже кожен проект або стартап зі штучним інтелектом сьогодні містить певну форму агента. .

Більшість розробників, з якими ми спілкувалися, були в захваті від потенціалу проксі. Модель контекстного навчання, яку ми описуємо в цій статті, може ефективно вирішувати проблеми галюцинацій і свіжості даних, таким чином краще підтримуючи завдання створення контенту. З іншого боку, агенти надають абсолютно новий набір можливостей для додатків штучного інтелекту: вирішення складних проблем, дія на зовнішній світ і навчання на досвіді після розгортання. Це досягається за допомогою поєднання передових міркувань/планування, використання інструментів і пам’яті/рекурсії/саморефлексії.

Таким чином, агенти мають потенціал стати центральною частиною архітектури програми LLM (або навіть взяти на себе весь стек технологій, якщо ви вірите в рекурсивне самовдосконалення). Існуючі фреймворки, такі як LangChain, уже включають частину концепції проксі. Є лише одна проблема: проксі ще не працюють. Більшість фреймворків агентів сьогодні все ще знаходяться на стадії підтвердження концепції, пропонуючи неймовірні демонстрації, але не виконуючи завдання надійно та повторювано. Ми уважно спостерігаємо за тим, як розвиватиметься проксі найближчим часом.

Погляд у майбутнє

Попередньо підготовлені моделі штучного інтелекту являють собою найбільш значну зміну в архітектурі програмного забезпечення з часів Інтернету. Вони дозволяють окремим розробникам створювати неймовірні додатки штучного інтелекту за кілька днів, перевершуючи навіть керовані проекти машинного навчання, розробка яких займала місяці великими командами.

Інструменти та шаблони, які ми тут перелічуємо, можуть бути відправною точкою для інтеграції LLM, а не кінцевим станом. Ми також оновлюємо, коли відбуваються критичні зміни (скажімо, перехід до навчання моделі) і публікуємо нові еталонні архітектури, де це має сенс.