Reflections on AI Engineer Summit 2023

eugeneyan

eugeneyan

Начните здесь Статьи Выступления Прототипирование О себе

Reflections on AI Engineer Summit 2023

Размышления об AI Engineer Summit 2023

[ llm ai misc ] · 7 min read

[ llm ai misc ] · 7 мин чтения

I recently attended the first-ever AI Engineer Summit in San Francisco. There, I gave a talk on building blocks for LLM systems and also got to chat with folks on the edge of building and deploying LLM products. Here are some key takeaways:

Недавно я побывал на первом в истории AI Engineer Summit в Сан-Франциско. Там я выступил с докладом о строительных блоках для LLM-систем, а также пообщался с людьми, находящимися на переднем крае создания и развёртывания LLM-продуктов. Вот несколько ключевых выводов:

Evals and serving costs are the biggest challenges when deploying. This is based on the early results of Amplify Partners’ survey on AI Engineering. Out of over 800 responses so far, evals and serving costs came out tops as the biggest pain points in deployment. While it’s reassuring to know that I’m not the only one struggling with this, it also means I’ll have to invest in them instead of waiting to be a fast follower.

Evals и стоимость обслуживания — главные сложности при деплое. Это вывод по ранним результатам опроса об AI-инженерии от Amplify Partners. Из более чем 800 ответов на текущий момент именно evals и стоимость обслуживания вышли на первое место как главные болевые точки при развёртывании. С одной стороны, утешает, что не я один с этим мучаюсь; с другой — это значит, что мне придётся вкладываться в их решение, а не ждать, чтобы стать «быстрым последователем».

There is still no good way to do evals. The spectrum of eval techniques is wide, ranging from deterministic yet brittle assert statements to stochastic and expensive model grading via a 3P LLM, with little in between.

До сих пор нет хорошего способа делать evals. Спектр техник оценки широк: от детерминированных, но хрупких assert-проверок до стохастичной и дорогой оценки моделью через сторонний LLM, и почти ничего между ними.

Asserts check the output of LLMs for expected words or numbers. Thus, while they’re deterministic, they’re also somewhat brittle. In the Eval Driven Development workshop, they built an eval for an agent checking a page on Amazon for the cheapest book. Their eval expected “6.78” but the model returned “$6.78”, thus failing the test case.

Assert-проверки сверяют вывод LLM с ожидаемыми словами или числами. Поэтому, будучи детерминированными, они в то же время довольно хрупкие. На воркшопе по Eval Driven Development собрали eval для агента, проверяющего страницу на Amazon в поисках самой дешёвой книги. Их eval ожидал «6.78», а модель вернула «$6.78» — и тест-кейс провалился.

Another example is checking the tables used in generated SQL. I learned that LLMs, even the strong ones, sometimes ignore the list of tables provided and make up new tables in the generated SQL. A simple check is to assert that the tables in the generated SQL are limited to the list of tables provided.

Другой пример — проверка таблиц, используемых в сгенерированном SQL. Я узнал, что LLM, даже сильные, иногда игнорируют предоставленный список таблиц и выдумывают новые таблицы в сгенерированном SQL. Простая проверка — убедиться (assert), что таблицы в сгенерированном SQL ограничены предоставленным списком.

But aren’t LLM outputs too open-ended to adopt an assert-based approach? Here’s Bryan Bischof (Head of AI at Hex) at a panel discussion: “If you’re not able to find a simple way to eval the responses, you’re probably not trying hard enough”. I’d agree.

Но разве выводы LLM не слишком свободны по форме, чтобы применять подход на основе assert? Вот что сказал Bryan Bischof (Head of AI в Hex) на панельной дискуссии: «Если вы не можете найти простой способ оценить ответы, вы, вероятно, недостаточно стараетесь». Я согласен.

An alternative to asserts is using an LLM to grade outputs. However, from folks who’ve been doing this for months (e.g., AutoGPT team), this quickly gets expensive at scale. To address this, they’ve resorted to caching responses (e.g., VCR.py). Thus, if we only update an isolated component in the system, we just need to eval that component and use the cached response for the rest of the system.

Альтернатива assert-проверкам — использовать LLM для оценки выводов. Однако, по словам тех, кто занимается этим уже месяцами (например, команды AutoGPT), при масштабировании это быстро становится дорогим. Чтобы это решить, они стали кэшировать ответы (например, через VCR.py). Так что, если мы обновляем лишь отдельный компонент системы, нам нужно оценить только этот компонент, а для остального использовать закэшированный ответ.

There’s one exception that’s relatively straightforward to eval: Code generation. We check if the code runs and produces the expected output. (This may explain the relative success of coding assistants.) Thus, perhaps code is a good medium for eval. Then, the challenge becomes formulating expected responses as code.

Есть одно исключение, которое оценивать относительно просто: генерация кода. Мы проверяем, запускается ли код и выдаёт ли ожидаемый результат. (Возможно, это объясняет относительный успех ассистентов для кодинга.) Так что, пожалуй, код — хорошая среда для оценки. Тогда задача сводится к тому, чтобы сформулировать ожидаемые ответы в виде кода.

If we don’t have good automated evals, a useful mechanism is a periodic human eyeballing. Some LLM-based products do this weekly, on a sample of a few dozen queries, to get an intimate feel of how their product is improving or regressing week over week. This allowed them to quickly notice regressions with each model rollout and take corrective action.

Если хороших автоматических evals нет, полезным механизмом становится периодический просмотр человеком. Некоторые LLM-продукты делают это еженедельно, на выборке из нескольких десятков запросов, чтобы по-настоящему прочувствовать, как их продукт улучшается или деградирует от недели к неделе. Это позволяло им быстро замечать регрессии при каждом обновлении модели и принимать корректирующие меры.

Cost-effectiveness depends on the task. For complex tasks, LLMs are relatively cheap. For example, getting GPT-4 to write a data connector plugin would cost ~$10 and a few hours. In comparison, an average dev might take days or weeks. Counterintuitively, using LLMs to automate simple repetitive tasks, such as evals, is expensive. Thus, it makes better sense, at least for now, to use LLMs for complex work vs. basic, frequent tasks.

Экономическая эффективность зависит от задачи. Для сложных задач LLM относительно дёшевы. Например, заставить GPT-4 написать плагин-коннектор данных обойдётся примерно в $10 и несколько часов. Для сравнения: среднему разработчику на это может уйти дни или недели. Парадоксально, но использовать LLM для автоматизации простых повторяющихся задач, таких как evals, дорого. Поэтому, по крайней мере пока, разумнее применять LLM для сложной работы, а не для базовых, частых задач.

LLMs need to be backward compatible with existing systems. Just like ML was just a small part of a larger production system, LLMs will be too. We’ve learned this lesson before.

LLM должны быть обратно совместимы с существующими системами. Точно так же, как ML был лишь небольшой частью более крупной production-системы, LLM ими и останутся. Этот урок мы уже усвоили раньше.

From Hidden Technical Debt in Machine Learning Systems (source)

Из работы Hidden Technical Debt in Machine Learning Systems (источник)

Thus, we should think about integration sooner rather than later. JSON (OpenAI function calling) and XML (which Claude prefers) seem promising. Other tools include Guidance, Instructor, and TypeChat though the first of them doesn’t seem actively maintained.

Поэтому думать об интеграции стоит скорее раньше, чем позже. Перспективными выглядят JSON (function calling от OpenAI) и XML (который предпочитает Claude). Среди других инструментов — Guidance, Instructor и TypeChat, хотя первый из них, похоже, активно не поддерживается.

Guardrails and moderation were less of a concern than expected. Few people I interacted with were concerned about them. I think this is because most use cases focus on LLM strengths, such as creativity and analyzing complex information (e.g., marketing copy, reading docs and writing code), and less on weaknesses like factual consistency. This suggests that it may be easier to build around use cases that have lesser moderation concerns, at least for now. However, use cases in industries that have low error and risk tolerance, such as finance and healthcare, remain tricky.

Guardrails и модерация оказались менее острой проблемой, чем ожидалось. Мало кто из тех, с кем я общался, переживал по их поводу. Думаю, это потому, что большинство сценариев использования опираются на сильные стороны LLM — креативность и анализ сложной информации (например, маркетинговые тексты, чтение документации и написание кода) — и меньше на слабые, такие как фактологическая согласованность. Это наводит на мысль, что, по крайней мере пока, проще строить вокруг сценариев с меньшими рисками по части модерации. Однако сценарии в отраслях с низкой терпимостью к ошибкам и рискам, таких как финансы и здравоохранение, остаются непростыми.

(Alternatively, it could be a blind-spot that devs are overlooking. Similarly, most folks I spoke to were finetuning on 3P LLM outputs despite it being against the terms of service.)

(С другой стороны, это может быть слепым пятном, которое разработчики упускают из виду. Похожим образом большинство людей, с кем я говорил, файнтюнили модели на выводах сторонних LLM, несмотря на то что это противоречит условиям использования.)

That said, in Shreya’s talk on Guardrails, it seems that the vision for Guardrails has expanded beyond the initial RAIL spec to include guards based on ML, DL classifiers, and self-reflection. She also spoke at length on the need to have guardrails on correctness which included embedding similarity, NLI, and self-reflection. Maybe this is based on chats with users and market demand?

Тем не менее, в докладе Shreya о Guardrails прозвучало, что видение Guardrails расширилось за рамки первоначальной спецификации RAIL и теперь включает «защиты» на основе ML- и DL-классификаторов и самопроверки (self-reflection). Она также подробно говорила о необходимости guardrails для контроля корректности, что включало схожесть эмбеддингов, NLI и self-reflection. Возможно, это основано на общении с пользователями и спросе на рынке?

There was surprisingly little discussion on caching to save costs. The only mention was at AutoGPT’s workshop, where they discussed using VCR.py to cache responses for evals. I wonder if it’s because the inputs to most LLM workloads are so unique that the benefits of caching are negligible, or if (semantic) caching is too unreliable to work in production.

На удивление мало обсуждали кэширование ради экономии затрат. Единственное упоминание было на воркшопе AutoGPT, где говорили об использовании VCR.py для кэширования ответов под evals. Интересно, в чём причина: то ли входные данные большинства LLM-нагрузок настолько уникальны, что выгода от кэширования ничтожна, то ли (семантическое) кэширование слишком ненадёжно, чтобы работать в проде.

Personally, I’m counting on caching to save ≥ 50% of LLM costs for large-scale systems. These systems, such as recsys, search, and customer support, likely have repetitive inputs and outputs that can benefit from caching. We just need to find smart ways to build caches for them—even something as naive as exact match can go a long way.

Лично я рассчитываю, что кэширование сэкономит ≥ 50% затрат на LLM в крупномасштабных системах. У таких систем — рекомендательные системы, поиск, поддержка клиентов — вероятно, есть повторяющиеся входы и выходы, которым кэширование пойдёт на пользу. Нужно лишь найти умные способы строить для них кэши — даже что-то столь наивное, как точное совпадение, способно дать многое.

Retrieval-augmented generation (RAG) isn’t going away soon. There were three talks and an entire workshop dedicated to RAG databases and techniques. From the conversations and questions, it seems most teams are leaning heavily into RAG, at least for the short-to-medium term. Questions included how to combine metadata filters with vector search, how to effectively chunk/augment documents, how to eval, access control, etc.

Retrieval-augmented generation (RAG) в ближайшее время никуда не денется. RAG-базам данных и техникам были посвящены три доклада и целый воркшоп. Из разговоров и вопросов видно, что большинство команд активно делают ставку на RAG, по крайней мере на кратко- и среднесрочную перспективу. Среди вопросов: как сочетать фильтры по метаданным с векторным поиском, как эффективно чанковать/обогащать документы, как делать evals, контроль доступа и так далее.

Everyone can code now. With Replit making code assistance available to everyone and GitHub Copilot achieving ≥ 100M ARR, coding assistants are here to stay. It’s getting easier to start coding—education systems would jump on this opportunity to teach the next generation how to interact with machines and data.

Теперь кодить может каждый. С тем, что Replit сделал помощь в коде доступной всем, а GitHub Copilot достиг ≥ 100M ARR, ассистенты для кодинга пришли надолго. Начать программировать становится всё проще — системы образования ухватятся за эту возможность, чтобы научить следующее поколение взаимодействовать с машинами и данными.

2024 may be the year of multimodal. OpenAI demoed GPT-4V converting images to text, and then using that text to generate new images. Their talk included a slide on how text will likely be the “connective tissue” that binds multi-modality.

2024-й может стать годом мультимодальности. OpenAI продемонстрировала, как GPT-4V преобразует изображения в текст, а затем использует этот текст для генерации новых изображений. В их докладе был слайд о том, что текст, вероятно, станет «соединительной тканью», связывающей мультимодальность.

The world is still figuring out LLMs so it’s unclear if large multimodal models (LMMs) will take off yet. Nonetheless, text as the common medium makes sense—it’s flexible and can be used to compose structured data, code, logs, etc.

Мир всё ещё разбирается с LLM, поэтому пока неясно, «взлетят» ли большие мультимодальные модели (LMM). Тем не менее текст как общая среда выглядит логично — он гибок и может использоваться для компоновки структурированных данных, кода, логов и так далее.

To finetune and self-host, or call APIs? Most folks I spoke to see finetuning and self-hosting small, specialized models as the way to improve performance and reduce cost. I’m of the same opinion. Nonetheless, some of us wondered if 3rd-party LLMs will just improve over time like SSDs did, becoming so performant and cheap that it doesn’t make sense to use anything else. I’ll be watching closely how this plays out. 👀

Файнтюнить и хостить у себя или вызывать API? Большинство людей, с кем я говорил, видят в файнтюнинге и self-hosting небольших специализированных моделей способ повысить производительность и снизить стоимость. Я придерживаюсь того же мнения. Тем не менее некоторые из нас задавались вопросом, не станут ли сторонние LLM просто улучшаться со временем, как SSD, — настолько производительными и дешёвыми, что использовать что-либо ещё не будет иметь смысла. Буду внимательно следить, как это сложится. 👀

SF engineers have incredible work ethic. I attended a Sunday 9 am workshop at an obscure co-working space: At 9 am the seats were half taken, and by 9.15 there weren’t enough chairs. For the Monday 8.45 workshops at the conference venue, by 8.20 it was half filled, and by 9.00 it was standing room only.

У инженеров из Сан-Франциско невероятная работоспособность. Я был на воскресном воркшопе в 9 утра в неприметном коворкинге: к 9 утра места были заняты наполовину, а к 9:15 не хватало стульев. На воркшопах в понедельник в 8:45 на площадке конференции к 8:20 зал был заполнен наполовину, а к 9:00 остались только стоячие места.

The questions they asked were amazing too. It was apparent that they already had a design doc in their heads and were asking questions about trade-offs, evals, cost, risk, etc. The energy was an order of magnitude above other conferences I’ve attended. These attendees were sprinting like rabbits running from wolves, not the wolves chasing what’s merely lunch. That said, this may not be a representative sample as the organized hand-picked 500 attendees over 10x as many applicants.

Вопросы, которые они задавали, тоже были потрясающими. Было очевидно, что у них уже сложился дизайн-документ в голове, и они спрашивали о компромиссах, evals, стоимости, рисках и так далее. Энергетика была на порядок выше, чем на других конференциях, где я бывал. Эти участники бежали, как зайцы, спасающиеся от волков, — а не как волки, лениво гонящиеся за обедом. При этом выборка может быть нерепрезентативной: организаторы вручную отобрали 500 участников из более чем десятикратного числа заявок.

Overall, one of the best conferences I’ve attended in a while. Can’t wait for the next one.

В целом — одна из лучших конференций, на которых я был за последнее время. Не могу дождаться следующей.

• • •

• • •

OG image prompt: yellow lego block, alien technology style, dark grey background –ar 16:9

Промпт для OG-картинки: yellow lego block, alien technology style, dark grey background –ar 16:9

If you found this useful, please cite this write-up as:

Если это было полезно, пожалуйста, цитируйте эту заметку так:

Yan, Ziyou. (Oct 2023). Reflections on AI Engineer Summit 2023. eugeneyan.com. https://eugeneyan.com/writing/aieng-reflections/.

Yan, Ziyou. (Oct 2023). Reflections on AI Engineer Summit 2023. eugeneyan.com. https://eugeneyan.com/writing/aieng-reflections/.

or

или

@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/} }

@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/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.