Reflections on AI Engineer Summit 2023
Юджин Ян делится впечатлениями от первого AI Engineer Summit в Сан-Франциско, где он выступил с докладом о строительных блоках для LLM-систем. Главными болевыми точками деплоя, по данным опроса Amplify Partners (более 800 ответов), названы оценки качества (evals) и стоимость обслуживания моделей; при этом хорошего способа делать evals по-прежнему нет — от хрупких assert-проверок до дорогой оценки через сторонний LLM. Автор отмечает, что для сложных задач LLM относительно дёшевы (плагин-коннектор от GPT-4 обойдётся ~$10), а вот автоматизация простых частых задач выходит дорого. RAG никуда не уходит в ближайшее время, 2024-й может стать годом мультимодальности (OpenAI показала GPT-4V), а текст видится «соединительной тканью» между модальностями. Также обсуждаются кэширование ради экономии ≥50% затрат, выбор между файнтюнингом со self-hosting и вызовом API, а также невероятная работоспособность инженеров из Сан-Франциско. GitHub Copilot достиг ≥100M ARR, и кодинг-ассистенты пришли надолго.
Размышления об AI Engineer Summit 2023
Недавно я побывал на первом в истории AI Engineer Summit в Сан-Франциско. Там я выступил с докладом о строительных блоках для LLM-систем, а также пообщался с людьми, находящимися на переднем крае создания и развёртывания LLM-продуктов. Вот несколько ключевых выводов:
Evals и стоимость обслуживания — главные сложности при деплое. Это вывод по ранним результатам опроса об AI-инженерии от Amplify Partners. Из более чем 800 ответов на текущий момент именно evals и стоимость обслуживания вышли на первое место как главные болевые точки при развёртывании. С одной стороны, утешает, что не я один с этим мучаюсь; с другой — это значит, что мне придётся вкладываться в их решение, а не ждать, чтобы стать «быстрым последователем».
До сих пор нет хорошего способа делать evals. Спектр техник оценки широк: от детерминированных, но хрупких assert-проверок до стохастичной и дорогой оценки моделью через сторонний LLM, и почти ничего между ними.
Assert-проверки сверяют вывод LLM с ожидаемыми словами или числами. Поэтому, будучи детерминированными, они в то же время довольно хрупкие. На воркшопе по Eval Driven Development собрали eval для агента, проверяющего страницу на Amazon в поисках самой дешёвой книги. Их eval ожидал «6.78», а модель вернула «$6.78» — и тест-кейс провалился.
Другой пример — проверка таблиц, используемых в сгенерированном SQL. Я узнал, что LLM, даже сильные, иногда игнорируют предоставленный список таблиц и выдумывают новые таблицы в сгенерированном SQL. Простая проверка — убедиться (assert), что таблицы в сгенерированном SQL ограничены предоставленным списком.
Но разве выводы LLM не слишком свободны по форме, чтобы применять подход на основе assert? Вот что сказал Bryan Bischof (Head of AI в Hex) на панельной дискуссии: «Если вы не можете найти простой способ оценить ответы, вы, вероятно, недостаточно стараетесь». Я согласен.
Альтернатива assert-проверкам — использовать LLM для оценки выводов. Однако, по словам тех, кто занимается этим уже месяцами (например, команды AutoGPT), при масштабировании это быстро становится дорогим. Чтобы это решить, они стали кэшировать ответы (например, через VCR.py). Так что, если мы обновляем лишь отдельный компонент системы, нам нужно оценить только этот компонент, а для остального использовать закэшированный ответ.
Есть одно исключение, которое оценивать относительно просто: генерация кода. Мы проверяем, запускается ли код и выдаёт ли ожидаемый результат. (Возможно, это объясняет относительный успех ассистентов для кодинга.) Так что, пожалуй, код — хорошая среда для оценки. Тогда задача сводится к тому, чтобы сформулировать ожидаемые ответы в виде кода.
Если хороших автоматических evals нет, полезным механизмом становится периодический просмотр человеком. Некоторые LLM-продукты делают это еженедельно, на выборке из нескольких десятков запросов, чтобы по-настоящему прочувствовать, как их продукт улучшается или деградирует от недели к неделе. Это позволяло им быстро замечать регрессии при каждом обновлении модели и принимать корректирующие меры.
Экономическая эффективность зависит от задачи. Для сложных задач LLM относительно дёшевы. Например, заставить GPT-4 написать плагин-коннектор данных обойдётся примерно в $10 и несколько часов. Для сравнения: среднему разработчику на это может уйти дни или недели. Парадоксально, но использовать LLM для автоматизации простых повторяющихся задач, таких как evals, дорого. Поэтому, по крайней мере пока, разумнее применять LLM для сложной работы, а не для базовых, частых задач.
LLM должны быть обратно совместимы с существующими системами. Точно так же, как ML был лишь небольшой частью более крупной production-системы, LLM ими и останутся. Этот урок мы уже усвоили раньше.
Из работы Hidden Technical Debt in Machine Learning Systems (источник)
Поэтому думать об интеграции стоит скорее раньше, чем позже. Перспективными выглядят JSON (function calling от OpenAI) и XML (который предпочитает Claude). Среди других инструментов — Guidance, Instructor и TypeChat, хотя первый из них, похоже, активно не поддерживается.
Guardrails и модерация оказались менее острой проблемой, чем ожидалось. Мало кто из тех, с кем я общался, переживал по их поводу. Думаю, это потому, что большинство сценариев использования опираются на сильные стороны LLM — креативность и анализ сложной информации (например, маркетинговые тексты, чтение документации и написание кода) — и меньше на слабые, такие как фактологическая согласованность. Это наводит на мысль, что, по крайней мере пока, проще строить вокруг сценариев с меньшими рисками по части модерации. Однако сценарии в отраслях с низкой терпимостью к ошибкам и рискам, таких как финансы и здравоохранение, остаются непростыми.
(С другой стороны, это может быть слепым пятном, которое разработчики упускают из виду. Похожим образом большинство людей, с кем я говорил, файнтюнили модели на выводах сторонних LLM, несмотря на то что это противоречит условиям использования.)
Тем не менее, в докладе Shreya о Guardrails прозвучало, что видение Guardrails расширилось за рамки первоначальной спецификации RAIL и теперь включает «защиты» на основе ML- и DL-классификаторов и самопроверки (self-reflection). Она также подробно говорила о необходимости guardrails для контроля корректности, что включало схожесть эмбеддингов, NLI и self-reflection. Возможно, это основано на общении с пользователями и спросе на рынке?
На удивление мало обсуждали кэширование ради экономии затрат. Единственное упоминание было на воркшопе AutoGPT, где говорили об использовании VCR.py для кэширования ответов под evals. Интересно, в чём причина: то ли входные данные большинства LLM-нагрузок настолько уникальны, что выгода от кэширования ничтожна, то ли (семантическое) кэширование слишком ненадёжно, чтобы работать в проде.
Лично я рассчитываю, что кэширование сэкономит ≥ 50% затрат на LLM в крупномасштабных системах. У таких систем — рекомендательные системы, поиск, поддержка клиентов — вероятно, есть повторяющиеся входы и выходы, которым кэширование пойдёт на пользу. Нужно лишь найти умные способы строить для них кэши — даже что-то столь наивное, как точное совпадение, способно дать многое.
Retrieval-augmented generation (RAG) в ближайшее время никуда не денется. RAG-базам данных и техникам были посвящены три доклада и целый воркшоп. Из разговоров и вопросов видно, что большинство команд активно делают ставку на RAG, по крайней мере на кратко- и среднесрочную перспективу. Среди вопросов: как сочетать фильтры по метаданным с векторным поиском, как эффективно чанковать/обогащать документы, как делать evals, контроль доступа и так далее.
Теперь кодить может каждый. С тем, что Replit сделал помощь в коде доступной всем, а GitHub Copilot достиг ≥ 100M ARR, ассистенты для кодинга пришли надолго. Начать программировать становится всё проще — системы образования ухватятся за эту возможность, чтобы научить следующее поколение взаимодействовать с машинами и данными.
2024-й может стать годом мультимодальности. OpenAI продемонстрировала, как GPT-4V преобразует изображения в текст, а затем использует этот текст для генерации новых изображений. В их докладе был слайд о том, что текст, вероятно, станет «соединительной тканью», связывающей мультимодальность.
Мир всё ещё разбирается с LLM, поэтому пока неясно, «взлетят» ли большие мультимодальные модели (LMM). Тем не менее текст как общая среда выглядит логично — он гибок и может использоваться для компоновки структурированных данных, кода, логов и так далее.
Файнтюнить и хостить у себя или вызывать API? Большинство людей, с кем я говорил, видят в файнтюнинге и self-hosting небольших специализированных моделей способ повысить производительность и снизить стоимость. Я придерживаюсь того же мнения. Тем не менее некоторые из нас задавались вопросом, не станут ли сторонние LLM просто улучшаться со временем, как SSD, — настолько производительными и дешёвыми, что использовать что-либо ещё не будет иметь смысла. Буду внимательно следить, как это сложится. 👀
У инженеров из Сан-Франциско невероятная работоспособность. Я был на воскресном воркшопе в 9 утра в неприметном коворкинге: к 9 утра места были заняты наполовину, а к 9:15 не хватало стульев. На воркшопах в понедельник в 8:45 на площадке конференции к 8:20 зал был заполнен наполовину, а к 9:00 остались только стоячие места.
Вопросы, которые они задавали, тоже были потрясающими. Было очевидно, что у них уже сложился дизайн-документ в голове, и они спрашивали о компромиссах, evals, стоимости, рисках и так далее. Энергетика была на порядок выше, чем на других конференциях, где я бывал. Эти участники бежали, как зайцы, спасающиеся от волков, — а не как волки, лениво гонящиеся за обедом. При этом выборка может быть нерепрезентативной: организаторы вручную отобрали 500 участников из более чем десятикратного числа заявок.
В целом — одна из лучших конференций, на которых я был за последнее время. Не могу дождаться следующей.
• • •
Промпт для OG-картинки: yellow lego block, alien technology style, dark grey background –ar 16:9
Если это было полезно, пожалуйста, цитируйте эту заметку так:
Yan, Ziyou. (Oct 2023). Reflections on AI Engineer Summit 2023. eugeneyan.com. https://eugeneyan.com/writing/aieng-reflections/.
или
@article{yan2023aieng, title = {Reflections on AI Engineer Summit 2023}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2023}, month = {Oct}, url = {https://eugeneyan.com/writing/aieng-reflections/} }
Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.