Transcription
Это будет полное резюме книги "AI Engineering" от Чипвина. 800 страниц высококачественного контента об этой востребованной области с зарплатами от 300 тысяч долларов и выше. Мы поговорим об основополагающих моделях, промпт-инжиниринге, дообучении, RAG, агентах, как построить систему, улучшении инференса и многом другом.
Также, просто дисклеймер: это книга объемом 800 страниц, поэтому это лишь обзор. Я не могу охватить все в книге, но обещаю дать вам все, что нужно для старта. Это ваше несправедливое преимущество.
Если вы новичок, меня зовут Дев, и несколько лет назад я бросил медицинский университет. Все, что я знал, это основы биологии. Перенесемся в сегодняшний день, и я попал в такие компании, как Amazon и Google. Я также помог тысячам людей получить работу инженера по ИИ, о чем вы можете прочитать по ссылке в описании.
Давайте на секунду выйдем из контекста. Если вы смотрите это видео, вы, вероятно, задаете себе вопросы вроде: "Что именно такое инженерия ИИ? И чем она отличается от обычного машинного обучения? Нужен ли мне докторская степень, или я могу войти в эту область с моими текущими навыками? И стоит ли это вообще того? Может ли это действительно привести к высокооплачиваемой работе, или это просто хайп?"
Я отвечу на все три этих вопроса в этом разделе. И вот лучшая часть. Вам не нужна докторская степень. Вам не нужно публиковать статьи. И вам не нужно 10 лет математической теории. Инженерия ИИ — это прикладная, а не теоретическая область. Это создание, внедрение и масштабирование реальных систем. Вот почему такие компании, как Amazon, Google и OpenAI, платят 200 тысяч, 300 тысяч, даже 500 тысяч долларов людям, которые могут их создавать.
И поверьте мне, я был на вашем месте. Я не начинал как какой-то гениальный исследователь. Я начал с нуля, имея только знания в области биологии, но все равно попал в Amazon и Google, потому что сосредоточился на инженерной стороне ИИ.
Давайте используем аналогию, чтобы это лучше запомнилось. Представьте, что два человека входят на кухню. Первый — пищевой технолог. Он может рассказать вам молекулярный состав каждого ингредиента, химические реакции при каждой температуре и пищевую ценность. Это исследование ИИ. Второй человек — шеф-повар. Он может не знать точную молекулярную массу каждого белка, но он знает, как смешивать ингредиенты, управлять духовкой и подать блюдо, которое заставит людей сказать: "Вау, это инженерия ИИ".
Большинство людей думают, что им нужно быть пищевым технологом. Заучивать сотни уравнений и зацикливаться на теории, но потом они застревают. Они тратят месяцы, пытаясь наверстать математику, прежде чем даже начать создавать проект. Но правда в том, что компании не хотят, чтобы вы просто знали науку. Они хотят, чтобы вы подавали блюдо. И когда я смотрю на людей, которые так и не смогли пробиться в эту область, это почти всегда потому, что они застряли в ловушке пищевого технолога. Они бесконечно учатся, но никогда не выпускают проекты.
Тем временем инженеры, которые создают всего два или три солидных проекта, именно они получают шестизначные предложения о работе. Итак, мой друг, вот определение, которое вы должны запечатлеть в своем мозгу. Инженерия ИИ — это дисциплина проектирования, создания и развертывания систем ИИ, которые работают для реальных пользователей в масштабе.
Вот почему это такая огромная возможность прямо сейчас. Мы еще на ранних этапах, и спрос на людей, которые могут превращать модели в реальные продукты, намного превышает предложение. Эта область взрывается, потому что так много компаний хотят интегрировать ИИ, но у них нет внутренней экспертизы для этого. Вот где вы вступаете в игру.
Если вы освоите концепции этого видео, вы будете опережать 99% людей, потому что, мой друг, вы будете знать, как превратить теорию в реальность. Вот практический вывод из первой части этого видео. Запишите это где-нибудь, где вы будете видеть это каждый день, например, на столе или на доске. Инженеры ИИ не просто изучают модели, они создают системы. Примите этот образ мышления. Сосредоточьтесь на проектах, которые вы можете выпустить и которые решают реальные проблемы. Это образ мышления, которому я учу в своей программе, ссылка на которую находится в описании. И именно поэтому у нас есть невероятные истории успеха.
Итак, если инженерия ИИ — это создание систем, то следующий естественный вопрос: "Из какого сырья мы на самом деле строим? Что питает все эти агенты, RAG-системы и дообученные модели, о которых мы слышим?" Ответ — основополагающие модели. Это GPT и подобные модели мира.
Но вот ловушка, в которую попадает большинство людей. Они думают, что все основополагающие модели одинаковы. Или, что еще хуже, они просто говорят: "Я просто буду использовать GPT4". Готово. Если вы так сделаете, вы быстро столкнетесь с проблемами стоимости, задержки или, что еще хуже, вы выпустите продукт, который невозможно поддерживать.
В этом разделе мы разберем, что такое основополагающие модели на самом деле, почему они важны и какие практические различия вам нужно понимать как инженеру. К концу вы будете знать, как выбрать правильную модель для задачи, и это одно само по себе может сделать или сломать вашу карьеру. Давайте приступим.
Давайте представим это с помощью метафоры, которая запомнится. Представьте, что вы строите автомобиль. Выбранный вами двигатель определяет производительность автомобиля. Ferrari может дать вам огромную мощность, но ужасный расход топлива. Двигатель Prius медленнее, но невероятно эффективен. Ни один из них не лучше универсально. Это зависит от сценария использования.
Основополагающие модели — это те двигатели. GPT4 — это как Ferrari. Он невероятно мощный, но обычно дорогой и избыточный. Модель Llama от Meta может быть вашим двигателем Prius. Она дешевле, быстрее, но вам нужно тщательно ее настраивать.
Теперь давайте свяжем эту метафору с тремя основными столпами основополагающих моделей. Большие модели, как правило, работают лучше, но они медленнее и дороже. Маленькие модели могут быть молниеносно быстрыми и дешевыми в хостинге, но им требуется более тщательная инженерия для достижения сопоставимой производительности.
Второй столп — обучающие данные. Некоторые модели обучаются на всем интернете, а другие — на тщательно отобранных наборах данных. Это обучение определяет, что модель знает и какие у нее есть слепые пятна. Например, модель, ориентированная на финансы, может превзойти GPT4 в отчетах о фондовом рынке, даже если это меньшая модель.
Наконец, третий столп включает ограничения развертывания. Как инженер, вы должны спросить: "Мне нужно, чтобы эта модель работала на облачном кластере, или она должна работать локально на устройстве?"
Давайте сделаем это реальным с историей одного из инженеров, которого я курировал. Для получения более подробной информации просто проверьте ссылку в описании. Он создавал внутренний помощник для отдела кадров своей компании. Опять же, ничего особенного, просто ответы на базовые вопросы HR и IT. Его первой мыслью было использовать GPT4. Это работало, но каждый запрос стоил два-три цента, а у них было бесчисленное количество сотрудников. Ежемесячный счет был плохим. Вместо этого он переключился на открытую версию модели Llama от Meta, дообучил ее, и внезапно стоимость модели упала до менее чем 500 долларов в месяц. Тот же эффект, но за долю стоимости.
Вот главный вывод. Основополагающие модели не универсальны. Это инструменты, и ваша задача — настраивать и выбирать мудро. Вот почему компании отчаянно нуждаются в инженерах ИИ прямо сейчас. Не потому, что им нужен кто-то, кто будет задавать вопросы ChatGPT, а потому, что им нужен кто-то, кто знает, когда использовать GPT4, когда использовать меньшую, дообученную модель, и как объединить все это в надежную систему.
Позвольте мне задать вам вопрос. Как вы на самом деле узнаете, хорошо ли работает система ИИ? Звучит очевидно, верно? Просто протестируйте ее. Посмотрите, выглядят ли ответы хорошо. Но вот ловушка. "Выглядеть хорошо" — это не то же самое, что "работать правильно". Фактически, плохая оценка — это причина номер один, по которой большинство проектов ИИ терпят неудачу в компаниях.
Подумайте об этом. Если вы не можете правильно измерить успех, вы либо выпустите сломанную систему, которая потеряет доверие пользователей, либо убьете проект слишком рано, потому что думаете, что он не работает, но на самом деле вы просто неправильно измеряли прогресс. И вот хорошие новости. Методы оценки — это не ракетостроение. Как только вы поймете несколько ключевых фреймворков, вы мгновенно опередите большинство инженеров.
Давайте представим это с другой метафорой. Оценка эссе по английскому языку. Представьте, что вы оцениваете 100 эссе. Если вы просто просматриваете их и говорите: "Эй, это кажется хорошим. Хм, это требует улучшения." Вы, по сути, угадываете. Это субъективная оценка.
Теперь представьте, что вы создаете рубрику. Грамматика стоит 30 баллов. Ясность — 40 баллов и так далее. Внезапно у вас появляется система. Люди знают, чего ожидать, и вы знаете, что измерять. Это именно тот скачок, который вам нужно сделать. Переход от "выглядит правильно" к "у нас есть метрики, которые говорят нам, что это работает хорошо".
Вот трехслойная структура, которую используют инженеры ИИ. Во-первых, внутренние метрики, такие как перплексия, которые говорят нам, насколько хорошо модель предсказала следующее слово. Проблема в том, что это часто не коррелирует с удовлетворенностью пользователей. Модель может иметь отличную перплексию, но все равно давать бесполезные ответы.
Во-вторых, у нас есть метрики, специфичные для задачи. Это шаг вперед. Они разработаны вокруг фактической работы. Для бота поддержки клиентов вы можете измерить разрешение с первого раза. Это измеряет, как часто проблема пользователя решается в первом же ответе. Важно, правда?
Наконец, у нас есть обратная связь от людей и пользователей. В конце концов, метрики — это всего лишь прокси. Важен человеческий опыт. Вот почему компании также отслеживают CSAT, который измеряет удовлетворенность клиентов, NPS, индекс потребительской лояльности, или просто сырую обратную связь "большой палец вверх, большой палец вниз" непосредственно в продукте.
Теперь расскажу вам короткую историю. Один из моих клиентов, и его история есть по ссылке в описании, если вы хотите узнать больше, создал медицинский чат-бот для ответов на вопросы. Он оценил его, задав несколько вопросов сам. Выглядело неплохо, поэтому он добавил его в свое портфолио. Через месяц он снова тестировал систему, и она рекомендовала неправильную дозировку критически важного лекарства, что могло быть опасно, если бы пользователь слепо доверился ей. Проблема была в том, что у него не было надлежащего конвейера оценки. Как только он добавил рубрику с категориями, такими как точность, безопасность и ясность, производительность бота значительно улучшилась.
И вот почему это важно для вас. Когда вы идете на собеседование и говорите: "Я не просто создал чат-бот. Я создал конвейер оценки, который измерял точность, безопасность и удовлетворенность пользователей, и итерировал до тех пор, пока метрики не улучшились на 30%." Это тот язык, который заставляет менеджеров по найму говорить: "Вы приняты."
На этом этапе вы можете подумать: "Хорошо, я понял. Основополагающие модели — это двигатель, но как мне на самом деле управлять моделью?" Вот где вступает в игру промпт-инжиниринг. И давайте будем честны, промпт-инжиниринг — это не просто ввод лучших вопросов. Это дисциплина проектирования инструкций, которые формируют поведение модели.
И вот в чем дело: стать действительно хорошим в промпт-инжиниринге — это самый быстрый способ выглядеть как 10-кратный инженер в этой области. Потому что разница между наивным промптом и хорошо спроектированным может буквально означать разницу между системой, которая терпит неудачу в 70% случаев, и той, которая надежно работает в продакшене.
Давайте представим это с историей. У меня был студент, который создал бота поддержки клиентов для стартапа. Его первая версия использовала наивный простой промпт. "Отвечай на вопросы клиентов о нашей политике возврата." Это работало примерно в 50% случаев, но в остальных случаях он выдумывал правила, которых даже не существовало, например, обещал возврат через 6 месяцев, когда компания разрешала только 30 дней. Пользователи были в ярости. Основатель был готов свернуть проект.
Итак, он шаг за шагом перепроектировал промпт. Вот точная структура, которую он использовал, и вы можете применить ее к любому проекту.
Первое — назначение роли. Не просто говорите "отвечай на вопросы". Скажите модели, кто она. Вот пример. Что-то вроде: "Ты старший инженер, наставляющий стажера. Объясни этот фрагмент кода ясно с примерами."
Второе — используйте ограничения. Дайте модели жесткие правила поведения. Вот пример. "Если ответ не найден в предоставленной политике, ответьте: "Я не знаю. Пожалуйста, свяжитесь со службой поддержки клиентов." Это одно правило устранило около половины галлюцинаций, происходивших в этом проекте.
Третье — форматирование. Модели непредсказуемы. Принудительно придайте некоторую структуру их выводам. Вот пример. "Ответьте в формате JSON, содержащем два поля: 'ответ' и 'уверенность'." Это делает его машиночитаемым, что критически важно для построения конвейеров.
Наконец, используйте примеры с несколькими выстрелами. Дайте модели несколько примеров правильного вывода. Если ваша система суммирует электронные письма, то дайте модели два-три примера пар вход-выход в промпте.
Теперь вернемся к моему студенту. Как только он объединил назначение роли, ограничения и примеры, бот превратился из хаоса с 50% точностью почти в 90% точность. Проект перешел от почти мертвого к фактически развернутому внутри компании.
И вот почему это важно на рынке труда. Любой может сказать: "Я играл с ChatGPT." Но когда вы можете сказать: "Я разработал промпты, которые сократили галлюцинации на 40% и увеличили точность на 25% на тестовом наборе", вы мгновенно звучите как инженер ИИ, а не просто любитель. Компании хотят такого уровня строгости, потому что если их бот обещает возврат средств, которые они не могут предоставить, это не просто плохой пользовательский интерфейс, это судебный иск. Промпт-инжиниринг критически важен для управления рисками.
Давайте ответим на главный вопрос. Если основополагающие модели так много знают, зачем нам вообще нужны RAG или агенты ИИ? Ответ прост. Модели блестящи, но они не всеведущи. Они галлюцинируют, они забывают, и они понятия не имеют, что происходит после окончания данных обучения.
Вот где вступает в игру RAG, или генерация с дополненным поиском. Вместе с агентами ИИ это секретное оружие, которое делает системы ИИ действительно полезными в реальном мире. RAG внедряет факты в модель, а агенты внедряют действия. Объедините их, и у вас будут системы, которые не просто говорят, а на самом деле делают вещи.
К концу этого раздела вы поймете, как работают RAG и агенты, почему компании отчаянно нуждаются в инженерах, которые могут их создавать, и как они могут дать вам несправедливое преимущество на этом рынке труда.
Давайте представим это с примером. Представьте, что вы создаете чат-бот, скажем, для юридической фирмы. Из коробки GPT4 потрясающий. Он знает общие юридические концепции, известные судебные дела, даже малоизвестные латинские термины. Но вот в чем загвоздка. Если вы спросите его о конкретных контрактах фирмы, он ошибается. Спросите его о новых правилах, принятых в прошлом месяце, и он понятия не имеет.
Без RAG система похожа на адвоката, который изучил все учебники, но никогда не открывал дела клиента. Без агентов это похоже на адвоката, который дает советы, но никогда на самом деле не подает документы и не ищет ничего.
Вот как мы это исправляем как инженеры. Во-первых, с помощью RAG. Вот основная идея. Прежде чем модель даст ответ, извлеките соответствующую информацию из базы данных. Вставьте ее в промпт модели и позвольте модели сгенерировать свой ответ на основе этих фактов.
Вот почему это так важно. Во-первых, это делает ответы фактическими. Больше никаких галлюцинаций. Во-вторых, это позволяет динамически обновлять знания. Просто обновите базу данных. И в-третьих, это, как правило, дешевле, чем дообучение.
Во-вторых, агенты. Вот основная идея. Вместо того, чтобы просто отвечать на вопрос, модель решает, когда предпринять действие, например, вызвать API, записать в базу данных или использовать какой-либо инструмент, например, интернет. Архитектура выглядит примерно так. Сначала есть запрос пользователя, который LLM должна интерпретировать, затем выбрать инструмент и затем выполнить какое-либо действие. Инструмент возвращает какой-либо результат, и модель генерирует ответ.
Вот почему это так важно, даже важнее, чем RAG. Ну, во-первых, это расширяет возможности модели за пределы ввода текста и вывода текста. Плюс, это позволяет вам связывать рассуждения с выполнением. Например, вы можете попросить модель найти пять самых популярных репозиториев на GitHub, а затем суммировать их мне простым английским языком. Полезно, правда?
Наконец, все становится безумно, когда мы объединяем RAG с агентами. Когда вы объединяете эти два понятия, вы получаете системы, которые имеют обновленные конкретные знания и могут предпринимать действия. Вот пример конвейера, который объединяет RAG и агентов.
Сначала пользователь может сказать: "Забронируй мне рейс в соответствии с политикой командировок моей компании." RAG-часть системы может извлечь документ с политикой компании. Этот документ будет внедрен в промпт модели. Наконец, агентская часть системы фактически вызовет API бронирования компании и забронирует рейс пользователя.
Вот почему технологические компании одержимы инженерами ИИ, потому что внезапно ИИ — это не просто чат-бот. Это второй пилот для работы. Один из моих студентов, чья программа есть в описании, создал RAG-проект для юридической фирмы. Это не было ничего особенного, просто базовый поиск и генерация, но он продемонстрировал его на собеседовании, и менеджер по найму был поражен. Это сократило время исследования с 2 часов до 10 минут. Этот единственный проект принес ему три предложения о работе.
Вот урок. Одних основополагающих моделей недостаточно. Реальное преимущество приходит, когда вы, инженер, учитываете RAG и агентов. И когда вы можете написать в своем резюме: "Создал RAG-конвейер, используя встраивания и векторный поиск, чтобы сократить галлюцинации на 60%." или "Развернул агентскую структуру, которая автоматизировала решение заявок, сократив расходы на 30%." Это заставляет рекрутеров обращать внимание.
На этом этапе вы можете спросить: "Хорошо, RAG дает мне факты, агент дает мне действия, но что, если мне нужно, чтобы сама модель вела себя по-другому?" Вот где вступает в игру дообучение. Вместо того, чтобы просто задавать вопросы основополагающей модели, вы обучаете ее на своих собственных данных, чтобы она адаптировалась к вашим конкретным потребностям.
Но вот правда. Большинство новичков не осознают, что дообучение — это не всегда первый шаг. Это дорого, и если сделать его неправильно, это может привести к тому, что ваша модель будет работать еще хуже. Настоящий навык инженера ИИ — это знание, когда дообучение вообще является правильным шагом и как сделать это хорошо.
Давайте представим это с реальной историей. Допустим, компания хочет создать бота поддержки клиентов для интернет-магазина. Их первой идеей может быть дообучение GPT4 на 50 000 транскриптов чатов. Звучит неплохо, правда? Пользовательские знания, ответы, специфичные для домена. Но вот что может на самом деле произойти. Дообученная модель может запомнить плохие привычки от сотрудников службы поддержки клиентов. Те же транскрипты, которые использовались для дообучения модели, например, слишком частое извинение или предоставление противоречивых ответов о возврате средств. Это может сделать дообученную модель еще хуже, чем базовая модель. Компания может потерять 10 000 долларов только на вычислениях при таком проекте. И это происходит все время, потому что люди пропускают основной фреймворк принятия решений.
Вот ментальная модель, которую вам нужно освоить. Во-первых, когда не следует дообучать. Ну, если проблему можно решить с помощью RAG, это просто. Не дообучайте. Примеры включают каталоги продукции, документы о политике, юридические дела, RAG обычно лучше для этих случаев.
Во-вторых, вы должны понять, когда дообучение может быть правильным вариантом, например, когда вам нужен стиль или форматирование, чтобы быть ультра-последовательным, например, всегда отвечать в JSON или использовать тон голоса компании, или когда вам нужны специализированные навыки, встроенные непосредственно в модель, например, классификация медицинских изображений или генерация кода на нишевом языке. Но когда вам нужна эффективность, меньшая модель иногда может превзойти большую, если она правильно дообучена.
Теперь, если вам понравилось это видео, и вы хотите узнать новую стратегию, которую эксперты называют вторым невидимым резюме, которое поможет вам устроиться на работу как можно быстрее, посмотрите это видео прямо здесь. Это следующий большой сдвиг в найме ИИ/МО, и вы не хотите его пропустить. Серьезно, это одно из самых ценных видео на всем канале. Увидимся там.