AI Engineer 2023 Keynote - Building Blocks for LLM Systems

Start Here Writing Speaking Prototyping About

AI Engineer 2023 Keynote - Building Blocks for LLM Systems

Доклад на AI Engineer 2023 — Строительные блоки для систем на основе LLM

[ llm ai engineering production ] · 17 min read

[ llm ai engineering production ] · 17 мин. чтения

I was invited to give a talk at the inaugural AI Engineer Summit in San Francisco. It’s largely a combination of my recent writing on design patterns for LLM systems and evals for abstractive summarization, albeit heavily truncated (each speaker only had 18 minutes!). Here are the slides and talking points for my talk.

Меня пригласили выступить с докладом на первом AI Engineer Summit в Сан-Франциско. В основном это комбинация моих недавних статей о паттернах проектирования LLM-систем и оценках для абстрактной суммаризации, хотя и сильно сокращённая (каждому спикеру давали всего 18 минут!). Ниже — слайды и тезисы моего выступления.

You may also be interested in the slides that didn’t make the final cut.

Возможно, вам также будет интересно посмотреть слайды, которые не вошли в финальную версию.

• • •

Thank you for the warm welcome! I’m Eugene Yan, and today, I would like to talk to you about building blocks for LLM systems and products.

Спасибо за тёплый приём! Меня зовут Eugene Yan, и сегодня я хотел бы поговорить с вами о строительных блоках для систем и продуктов на основе LLM.

Like many of you, I’m trying to figuring out how to effectively use LLMs… in production.

Как и многие из вас, я пытаюсь разобраться, как эффективно использовать LLM… в продакшене.

So, a few months ago, to clarify my thinking, I wrote about some patterns for building LLM systems and products. And the community seemed to like it. There’s Jason asking for this to be a seminar—so here you go Jason.

Поэтому несколько месяцев назад, чтобы упорядочить свои мысли, я написал о некоторых паттернах для создания LLM-систем и продуктов. И сообществу это понравилось. Вот Jason просит сделать из этого семинар — так что, пожалуйста, Jason.

(Note: Jason’s talk was right before mine.)

(Примечание: доклад Jason был прямо перед моим.)

Today, I’m going to focus on four of these patterns: Evaluations, Retrieval-Augmented Generation, Guardrails, and Collecting Feedback. I might not have time for collecting feedback, but we’ll see how it goes.

Сегодня я сосредоточусь на четырёх из этих паттернов: оценки (Evaluations), генерация с дополнением извлечением (RAG), защитные ограничения (Guardrails) и сбор обратной связи (Collecting Feedback). На сбор обратной связи времени может не хватить, но посмотрим.

Okay, let’s start with evals, or what I consider the foundation.

Итак, начнём с оценок — того, что я считаю фундаментом.

Why do we need evals?

Зачем нам нужны оценки?

Well, evals help us understand if our prompt engineering, retrieval augmentation, or finetuning is on the right track. Consider it eval-driven development, where your evals guide how you build your system and product.

Оценки помогают понять, движемся ли мы в правильном направлении с промпт-инжинирингом, дополнением извлечением или файнтюнингом. Можно назвать это разработкой на основе оценок (eval-driven development), где оценки направляют процесс построения системы и продукта.

We can also think of evals as the test cases, where we run these tests before deploying updates to users.

Можно также думать об оценках как о тест-кейсах, которые мы прогоняем перед выкаткой обновлений пользователям.

And finally, if managers at OpenAI take the time to write evals or give feedback on them, you know that evals are pretty important.

И наконец, если менеджеры в OpenAI находят время писать оценки или давать по ним обратную связь, значит, оценки действительно важны.

But building evals is hard. Here are some things I’ve seen folks trip on.

Но создавать оценки сложно. Вот несколько подводных камней, на которых я видел, как люди спотыкаются.

First, we don’t have a consistent approach to evaluating LLMs.

Во-первых, у нас нет единого подхода к оценке LLM.

If we look at more conventional machine learning: For regression we have mean squared error, for classification we have precision & recall, and for ranking we have NDCG. These metrics are fairly straightforward and there’s typically one main way to compute them.

Если посмотреть на более традиционное машинное обучение: для регрессии у нас есть среднеквадратичная ошибка, для классификации — precision и recall, для ранжирования — NDCG. Эти метрики довольно просты, и обычно есть один основной способ их вычислить.

What about for LLMs? Well, we have benchmarks where given a prompt and multiple choice options, we evaluate the model’s ability to get it right. MMLU is an example that’s widely used, where it assess LLMs on knowledge and reasoning on college level tasks such as math, computer science, and US history.

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

But there’s no consistent way to run MMLU. As Arvind and Sayash recently noted, evaluating LLMs is a minefield. They rightly pointed out that it’s unclear if we’re evaluating the LLM or if we’re evaluating the prompts evaluating the LLM.

Но единого способа проводить MMLU не существует. Как недавно отметили Arvind и Sayash, оценка LLM — это минное поле. Они справедливо указали, что неясно, оцениваем ли мы саму LLM или промпты, с помощью которых мы её оцениваем.

On that very same day, Anthropic noted the same thing. They noted out that the simple multiple choice question may not be as simple as it seems.

В тот же самый день Anthropic отметили то же самое. Они указали, что простой вопрос с множественным выбором может оказаться не таким простым, как кажется.

For example, simple formatting changes—such as using different parentheses—can lead to significant changes in accuracy. Also, the lack of consistency across implementations makes it hard to compare models based on these academic benchmarks.

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

Speaking of academic benchmarks, we may have already outgrown some of them. For example, let’s consider the task of summarization.

Говоря об академических бенчмарках, возможно, мы уже переросли некоторые из них. Рассмотрим, например, задачу суммаризации.

On the top, we see the human evaluation scores on the reference summaries for the CNN/Daily Mail dataset. And on the bottom, we see the scores for the automated summaries geverated by various models. You don’t have to compare all the numbers, but the point is that the gold references score poorer than the automated summaries.

Вверху мы видим человеческие оценки эталонных саммари для датасета CNN/Daily Mail. А внизу — оценки автоматических саммари, сгенерированных различными моделями. Необязательно сравнивать все числа, но суть в том, что эталонные саммари получают более низкие оценки, чем автоматические.

We see the same thing on the XSUM dataset, which stands for extreme summarization. Here, the reference summaries have lower human evaluation scores than InstructGPT.

То же самое мы видим на датасете XSUM, что означает «экстремальная суммаризация». Здесь эталонные саммари получают более низкие человеческие оценки, чем InstructGPT.

And finally, with these benchmarks being so easily available, we sometimes forget to ask ourselves if they’re a fit for our task. If we think about it, does MMLU really apply to the tasks we care about? Maybe, if we’re building a bot to answer college level example questions. But most of us are not doing that. Here’s Linus reminding us that we should measure on our specific tasks and not just rely on academic evals.

И наконец, поскольку эти бенчмарки так легко доступны, мы иногда забываем задать себе вопрос: подходят ли они для нашей задачи. Если подумать, действительно ли MMLU применим к задачам, которые нас интересуют? Может быть, если мы делаем бота для ответов на экзаменационные вопросы университетского уровня. Но большинство из нас этим не занимается. Вот Linus напоминает нам, что измерять нужно на своих конкретных задачах, а не полагаться только на академические оценки.

(Note: Linus’ talk was right after mine.)

(Примечание: доклад Linus был сразу после моего.)

As an industry, we’re still figuring out how to do evals effectively. Nonetheless, I think there are some tenets emerging.

Как индустрия, мы всё ещё выясняем, как эффективно проводить оценки. Тем не менее, я думаю, что некоторые принципы уже формируются.

First, we should build evals for our specific task. And it’s okay to start small. How small? Well, Teknium, who finetunes and releases a lot of open models, handcrafts an eval set of 40 questions for his domain expert task. 40 evals, that’s all it takes, and it can go very far.

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

Second, try to simplify the task and eval as much as possible. Although LLMs are flexible, I think we’ll have better success with evals if we try to make our task more narrow.

Во-вторых, старайтесь максимально упростить задачу и оценку. Хотя LLM гибки, я думаю, мы добьёмся лучших результатов с оценками, если постараемся сделать задачу более узкой.

For example, if our task is content moderation, we can compute precision and recall on its ability to detect toxicity or bias. Or if it’s slightly broader, such as writing SQL, we can try to run the SQL to see if it executes and returns the expected result. Or if we’re extracting JSON, we can check if the extracted JSON keys and values match what we expect. Fortunately, these are fairly straightforward to evaluate because we have expected answers.

Например, если наша задача — модерация контента, мы можем вычислить precision и recall по способности определять токсичность или предвзятость. Или, если задача немного шире, например генерация SQL, можно попробовать выполнить SQL и проверить, выполняется ли он и возвращает ли ожидаемый результат. Или если мы извлекаем JSON, можно проверить, совпадают ли извлечённые ключи и значения с ожидаемыми. К счастью, такие задачи довольно легко оценивать, потому что у нас есть ожидаемые ответы.

But, if our task is open-ended—such as dialogue—we may have to rely on a strong LLM to evaluate the output. Nonetheless, this can be expensive, even for a small set of 60 samples.

Но если задача открытая — например, диалог — возможно, придётся полагаться на сильную LLM для оценки результатов. Тем не менее это может быть дорого, даже для небольшого набора из 60 примеров.

Finally, even if you have automated evals, don’t discount the value of eyeballing the output. Here’s Jonathan from Mosaic: “I don’t really believe that any of these eval metrics capture what we care about”. Instead, they had was a prompt to suggest games for a 3-year old and a 7-year old and they found it more valuable to see how the output changed over time.

И наконец, даже если у вас есть автоматические оценки, не недооценивайте пользу визуального просмотра результатов. Вот что говорит Jonathan из Mosaic: «Я не верю, что какие-либо из этих метрик оценки отражают то, что нас на самом деле волнует». Вместо этого у них был промпт с предложением игр для трёхлетнего и семилетнего ребёнка, и им было полезнее наблюдать, как результаты менялись со временем.

Next, let’s get into retrieval augmented generation, or what I consider the data.

Далее перейдём к генерации с дополнением извлечением (RAG) — к тому, что я считаю данными.

I don’t think I need to convince this audience here on the need for RAG, but very briefly, RAG is helpful as it lets us add relevant and up-to-date knowledge into our model as input context. This way, we don’t have to rely solely on the model’s knowledge.

Думаю, эту аудиторию не нужно убеждать в необходимости RAG, но если кратко: RAG полезен тем, что позволяет добавлять релевантные и актуальные знания в контекст модели. Таким образом, нам не нужно полагаться исключительно на знания модели.

It’s also more practical, being cheaper than continuous finetuning to add knowledge.

Это также более практично и дешевле, чем постоянный файнтюнинг для добавления знаний.

But, retrieving the right documents is hard. Nonetheless, since we already have great speakers, Jerry and Anton, sharing about this topic tomorrow, so I won’t go into the challenges of retrieval here. Instead, I would like to focus on the LLM side of things, and discuss some challenges that remain even if we have retrieval augmented generation.

Но извлекать правильные документы сложно. Тем не менее, поскольку у нас уже есть отличные спикеры — Jerry и Anton — которые будут говорить об этом завтра, я не буду углубляться в проблемы извлечения. Вместо этого я хотел бы сосредоточиться на стороне LLM и обсудить некоторые проблемы, которые остаются даже при наличии RAG.

The first of which is that LLMs can’t really see the all the documents that we retrieve.

Первая из них — LLM не могут по-настоящему видеть все извлечённые документы.

Here’s an experiment from a recent paper. The task is retrieval-augmented question & answer. The questions were based on historical queries on Google Search while the answers were human-annotated answers from Wikipedia.

Вот эксперимент из недавней статьи. Задача — вопросно-ответная система с дополнением извлечением. Вопросы основаны на реальных запросах в Google Search, а ответы — это аннотированные людьми ответы из Wikipedia.

As part of the context, they provided 20 documents that were at most 100 tokens long. So the context is max 2,000 tokens. One of these tokens contained the answer, and the rest were distractors that were relevant, but don’t contain the answer.

В качестве контекста предоставлялось 20 документов длиной не более 100 токенов каждый. Итого контекст — максимум 2 000 токенов. Один из документов содержал ответ, остальные были отвлекающими: релевантными, но не содержащими ответа.

The question they had was: How would the position of the document containing the answer affect question-answering accuracy?

Вопрос, который они задали: как позиция документа с ответом влияет на точность ответа на вопрос?

Here’s what they found.

Вот что они обнаружили.

If the answer is in the first retrieved document, accuracy was the highest.

Если ответ находится в первом извлечённом документе, точность максимальна.

When the answer is in the last document, accuracy is decent.

Когда ответ в последнем документе, точность приемлемая.

But when the answer is in the middle, accuracy plunges, to the extent that it’s even worse than without having retrieval augmentation.

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

The key takeaway here is this: We shouldn’t neglect retrieval just because context window sizes are increasing. Getting the most relevant documents to rank highly, in the top 1 - 3 positions, still matters.

Ключевой вывод: не стоит пренебрегать качеством извлечения только потому, что размеры контекстных окон растут. Важно, чтобы наиболее релевантные документы оказывались в топ-1–3 позициях.

Also, even if the answer is in the context, and in the top position, accuracy is only 75%. Thus, even with perfect retrieval, we can still expect some errors.

Кроме того, даже если ответ есть в контексте и находится на первой позиции, точность составляет всего 75%. Таким образом, даже при идеальном извлечении мы всё равно можем ожидать ошибки.

Another gotcha is that LLMs can’t really tell if the retrieved documents are irrelevant.

Ещё один подводный камень — LLM не могут по-настоящему определить, что извлечённые документы нерелевантны.

Here’s an example I tried with GPT-4: I gave it a list of the top 20 sci-fi movies, and we can think of these as movies I’ve watched. Then, I asked it if I would like Twilight. For folks not familiar with Twilight, it’s a romantic fantasy between a girl and a vampire, and some werewolves as well. I think that’s about right, because I’ve not watched it myself.

Вот пример, который я попробовал с GPT-4: я дал ему список из 20 лучших фантастических фильмов — можно считать, что это фильмы, которые я смотрел. Затем я спросил, понравится ли мне «Сумерки». Для тех, кто не знаком с «Сумерками» — это романтическое фэнтези о девушке и вампире, и ещё там есть оборотни. Думаю, примерно так, потому что сам я его не смотрел.

I also have this instruction where, if it thinks I won’t like Twilight, it should respond with “Not Applicable”. In recommender systems, it’s important for us to do this so we don’t make bad recommendations.

У меня также была инструкция: если модель считает, что мне не понравятся «Сумерки», она должна ответить «Не применимо». В рекомендательных системах важно уметь это делать, чтобы не давать плохих рекомендаций.

How do you think it responded?

Как вы думаете, что она ответила?

So here’s what happened. First, it notes that Twilight is a different genre and not quite sci-fi, which is great!

Вот что произошло. Сначала модель отмечает, что «Сумерки» — это другой жанр и не совсем фантастика, что отлично!

But then, it suggests ET because of inter-species relationships, and I’m not quite sure how I feel about that. <audience laughs>

Но затем она рекомендует «Инопланетянина» из-за межвидовых отношений, и я не совсем уверен, как к этому относиться. <зал смеётся>

(Note: This was not intended to be funny and was thus a pleasant surprise 😊)

(Примечание: это не задумывалось как шутка, так что смех зала стал приятным сюрпризом 😊)

I mean, how would you feel if you got this as a movie recommendation? The point is, these LLMs are so finetuned to be helpful that they try their best to give an answer. Sometimes, it’s hard for them to decide on queries that are in the fuzzy area of relevant vs. not relevant.

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

So how do we best address these limitations with RAG?

Так как же лучше всего справляться с этими ограничениями RAG?

First, I think there are a lot of good ideas in the field of information retrieval. Search and recommendations have been focused on showing the most relevant documents and items for decades. I think that the humble BM25, together with boosting queries, can go a long way. Also, there’s a lot that we can learn about ranking and filtering items from the field of recommender systems. Also, retrieval evaluation metrics.

Во-первых, я думаю, в области информационного поиска есть множество хороших идей. Поиск и рекомендации десятилетиями были нацелены на показ наиболее релевантных документов и элементов. Я считаю, что скромный BM25 вместе с бустингом запросов может очень многое. Также из области рекомендательных систем можно многое почерпнуть о ранжировании и фильтрации элементов. И метрики оценки качества извлечения тоже полезны.

I think it also helps to use a threshold to exclude irrelevant documents. In the Twilight and sci-fi movie example, I bet we could do something simple like checking item embedding distance between them and only if they’re close enough do we move to the next step.

Также, я думаю, полезно использовать порог для исключения нерелевантных документов. В примере с «Сумерками» и фантастическими фильмами, уверен, можно было бы сделать что-то простое — например, проверить расстояние между эмбеддингами и переходить к следующему шагу, только если они достаточно близки.

Next in the list, we have guardrails, the mediator between our backend systems and the frontend UX.

Следующий пункт — защитные ограничения (guardrails), посредник между нашими бэкенд-системами и фронтенд-интерфейсом.

A key concern is to make sure what we deploy is safe. What do we mean by safe? Well, we can look at OpenAI’s moderation API to look at what they compute. There’s hate, harassment, self-harm, violence, all that good stuff.

Ключевая задача — убедиться, что то, что мы развёртываем, безопасно. Что мы имеем в виду под «безопасно»? Можно посмотреть на API модерации OpenAI и изучить, что они отслеживают. Там есть ненависть, преследование, самоповреждение, насилие и прочее в том же духе.

Another thing we also want to guardrail against is that of factual inconsistency, also known as hallucinations. Returning non-factual content, such as inaccuracy summaries, can lead to trustbusting experiences.

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

Fortunately or unfortunately, the field of summarization has been trying to address this for a very long time, so we can take a leaf from their playbook.

К счастью — или к сожалению — область суммаризации пытается решить эту проблему уже очень давно, так что мы можем позаимствовать кое-что из их наработок.

One approach to assessing factual inconsistency is via the natural language inference task.

Один из подходов к оценке фактической несогласованности — задача вывода на естественном языке (NLI).

The task of NLI is where, given a premise and a hypothesis, we classify if the hypothesis is true or false. For example, given the premise “John likes all fruits”, the hypothesis that “John likes apples” is true and thus entailment.

Задача NLI состоит в том, что, имея посылку и гипотезу, мы классифицируем гипотезу как истинную или ложную. Например, имея посылку «Джон любит все фрукты», гипотеза «Джон любит яблоки» истинна и, следовательно, является следствием (entailment).

And because there’s not enough info to confirm that “John eats apples daily”, it’s neutral.

А поскольку информации недостаточно, чтобы подтвердить, что «Джон ест яблоки каждый день», это нейтральное утверждение.

And finally, the hypothesis that “John dislikes apples” is clearly false because of the premise, and is thus a contradiction.

И наконец, гипотеза «Джон не любит яблоки» явно ложна исходя из посылки и, следовательно, является противоречием.

Do you see how we can apply this to the task of summarization? In summarization, the document is the premise and the summary is the hypothesis.

Видите, как это можно применить к задаче суммаризации? В суммаризации документ — это посылка, а саммари — гипотеза.

And when doing this, it helps to apply it at the sentence-level instead of the entire document. In this example here, the last sentence in the summary is incorrect. If we run the NLI task with the entire document and summary, it classifies the entire summary as correct. But, if we run it at the sentence-level, an NLI model correctly identifies that the last sentence in the summary is incorrect.

И при этом полезно применять проверку на уровне предложений, а не всего документа. В этом примере последнее предложение в саммари некорректно. Если мы прогоняем задачу NLI по всему документу и саммари целиком, модель классифицирует всё саммари как корректное. Но если прогонять на уровне предложений, модель NLI правильно определяет, что последнее предложение в саммари ошибочно.

They also included a helpful ablation study, where they varied the granularity of the document: As the granularity got finer and finer, from document to paragraph to sentence, the accuracy of detecting factual inconsistency increases.

Авторы также провели полезное абляционное исследование, варьируя гранулярность документа: по мере того как гранулярность становилась всё мельче — от документа к абзацу и к предложению — точность обнаружения фактической несогласованности возрастала.

Another simple approach is that of sampling.

Ещё один простой подход — сэмплирование.

Here’s an example from SelfCheckGPT. Given an input document, we generate the summary multiple times. Then, we check if those generated summaries are similar to each other, such as via n-gram overlap, or embedding similarity.

Вот пример из SelfCheckGPT. Для входного документа мы генерируем саммари несколько раз. Затем проверяем, похожи ли сгенерированные саммари друг на друга — например, по пересечению n-грамм или близости эмбеддингов.

The assumption is that, if the summaries are wildly different, it’s because they’re not grounded on the context document and are thus hallucinations.

Предположение таково: если саммари сильно различаются, это потому, что они не опираются на исходный документ и, следовательно, являются галлюцинациями.

But, if the summaries are similar, then we can assume that they are grounded effectively and thus likely to be factually consistent with the context document.

Но если саммари похожи, то можно предположить, что они эффективно основаны на контексте и, скорее всего, фактически согласованы с исходным документом.

A final approach is asking a strong LLM.

Последний подход — спросить сильную LLM.

In this paper, given an input document and summary, they get the LLM to return a summary score. However, the LLM has to be pretty strong and they used GPT-4 to do this. As we saw earlier, GPT-4 can be pretty pricey. For the specific use case of detecting factual inconsistency, I’ve seen similar methods outperform using an LLM and thus would suggest starting with simple instead.

В этой статье, имея входной документ и саммари, авторы просят LLM вернуть оценку саммари. Однако LLM должна быть достаточно сильной, и для этого использовался GPT-4. Как мы видели ранее, GPT-4 может быть довольно дорогим. Для конкретной задачи обнаружения фактической несогласованности я видел, как более простые методы превосходят использование LLM, поэтому советую начинать с простого.

Okay, to close the loop, let’s touch briefly on collecting feedback.

Итак, чтобы замкнуть круг, кратко коснёмся сбора обратной связи.

Why is collecting feedback important? First, it helps us understand what users like and don’t like. This is important in helping us figure out what features to double down on and what to pivot from.

Почему сбор обратной связи важен? Во-первых, он помогает понять, что нравится и не нравится пользователям. Это важно для принятия решений — во что вкладываться, а от чего отказываться.

Also, collecting user feedback helps with building our evaluation and finetuning dataset. New models are released every day, but evals and finetuning data is one of the few assets that can transfer across models and techniques.

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

But collecting feedback from users is not as straightforward as it seems. Explicit feedback, which is feedback we ask from users, can be sparse. Here’s a quick thought experiment.

Но собирать обратную связь от пользователей не так просто, как кажется. Явная обратная связь — та, которую мы запрашиваем у пользователей — может быть очень разреженной. Вот небольшой мысленный эксперимент.

For folks that use ChatGPT, how often do you click on this button to get feedback?

Те из вас, кто пользуется ChatGPT — как часто вы нажимаете эту кнопку для отправки обратной связи?

<Около дюжины слушателей из 500 подняли руки>

Now, you folks are the beta testers that product developers dream of. <audience laughs>

Вот вы — те самые бета-тестеры, о которых мечтают разработчики продуктов. <зал смеётся>

The point here is, even if we include these feedback buttons, we may not actually receive the voluminous feedback we expect.

Суть в том, что даже если мы добавим кнопки обратной связи, мы можем не получить того объёма отзывов, на который рассчитываем.

Now, if the issue with explicit feedback is sparsity, the problem with implicit feedback is that it can be noisy. Implicit feedback is data that we organically get as people use our product, without our product asking users for feedback.

Если проблема явной обратной связи — разреженность, то проблема неявной обратной связи — шум. Неявная обратная связь — это данные, которые мы органически получаем по мере использования продукта, без того чтобы продукт запрашивал у пользователей отзыв.

Here’s that same example: How often do you click on the copy code button?

Вот тот же пример: как часто вы нажимаете кнопку копирования кода?

<30-50 people raise their hands>

<30–50 человек подняли руки>

But, does clicking on the copy-code button mean that the code is incorrect?

Но означает ли нажатие кнопки копирования кода, что код корректен?

(Note: At this time, the answer was not revealed.)

(Примечание: в этот момент ответ ещё не был раскрыт.)

No. In this example, nrows is not a valid argument for pandas.read_parquet. But, if we were to consider all code snippets that were copied as positive feedback, we might have a lot of bad data in our training set.

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

So, how do we collect feedback? One good example is GitHub Copilot. For people not familiar with it, you type your function signature or some comments and it suggests some code. Then, given the code suggestion, we can either accept the suggestion, go to the next suggestion, or reject or ignore it. We can also accept the code and make small edits.

Так как же собирать обратную связь? Хороший пример — GitHub Copilot. Для тех, кто не знаком: вы пишете сигнатуру функции или комментарии, а он предлагает код. Далее, получив предложение, мы можем либо принять его, перейти к следующему, либо отклонить или проигнорировать. Мы также можем принять код и внести небольшие правки.

We do this dozens of times a day, so we can only imagine how much valuable implicit feedback these coding assistants get daily.

Мы делаем это десятки раз в день, так что можно только представить, сколько ценной неявной обратной связи эти ассистенты для кодинга получают ежедневно.

Another good example is Midjourney. For folks that don’t use Midjourney, here’s how it works: You type a prompt and it generates four images. Then, based on the images, you can either ask to rerun the prompt, choose to vary one of the images slightly—that’s what the V stands for. Or, you can choose to upscale one of the images—that’s what the U stands for.

Ещё один хороший пример — Midjourney. Для тех, кто не пользуется Midjourney, вот как это работает: вы вводите промпт, и он генерирует четыре изображения. Затем, на основе изображений, вы можете попросить перезапустить промпт, выбрать небольшую вариацию одного из изображений — это обозначается буквой V. Или выбрать увеличение масштаба одного из изображений — это обозначается буквой U.

But you know what an AI engineer sees?

Но знаете, что видит AI-инженер?

Rerunning the prompt is negative feedback, because the user is saying that they don’t like any of the images generated.

Перезапуск промпта — это отрицательная обратная связь, потому что пользователь говорит, что ему не нравится ни одно из сгенерированных изображений.

Varying one of the images is small positive feedback, where the user is saying, hey, that image has potential.

Вариация одного из изображений — это слабый положительный сигнал: пользователь говорит — у этого изображения есть потенциал.

Finally, choosing to upscale the image is a large positive reward, where the user likes it and wants to use that image.

И наконец, выбор увеличения масштаба — это сильный положительный сигнал: пользователю нравится изображение, и он хочет его использовать.

Okay, that’s all I wanted to share. If you remember anything from this talk, I hope it’s these three things.

Итак, это всё, чем я хотел поделиться. Если вы запомните что-то из этого доклада, я надеюсь, это будут три вещи.

First, you need evals for your task. Just annotate 30 or 100 example for your task and try to automate evaluations on it. This will help you iterate faster on your prompt engineering, retrieval augmentation, finetuning, and so on. It’ll also help you deploy faster. Eyeballing doesn’t scale—it’s good as a final vibe check, but it doesn’t scale.

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

Next, reuse your existing systems as much as you can—there’s no need to reinvent the wheel. BM25 and metadata matching can get you pretty far, and so do the basic techniques from recommender systems. After all, these information retrieval techniques are optimized to rank the most relevant items on top.

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

Finally, UX plays a large rule in LLM products. I think a big chunk of the success with GitHub Copilot and ChatGPT is the UX—it allowed users to interact with them where they needed it, in the IDE or a chat window, instead of having to call an API. Having the right UX also makes it easier to collect useful feedback.

И наконец, UX играет огромную роль в продуктах на основе LLM. Я считаю, что значительная часть успеха GitHub Copilot и ChatGPT — это UX: он позволил пользователям взаимодействовать с ними там, где нужно — в IDE или в окне чата — вместо того чтобы вызывать API. Правильный UX также облегчает сбор полезной обратной связи.

Alright that’s all I had. Thank you, and keep on building.

На этом всё. Спасибо, и продолжайте создавать.

Cutting room floor

Неиспользованные слайды

Here are some slides that didn’t make it into the final presentation, mostly due to the strict 18 minute limit (they threatened to play the Oscars music at the 18 minute mark lol).

Вот несколько слайдов, которые не вошли в финальную презентацию, в основном из-за строгого лимита в 18 минут (они грозились включить оскаровскую музыку на 18-й минуте, ха-ха).

This was originally slide 2 and how I wanted to introduce myself as selling books at a book store, focusing on recommender systems and search. But I tried introducing myself this way to a few folks at the conference and a majority didn’t get it. Thus, I dropped it to save 20 seconds. I guess it’s more of an inside joke than anything.

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

This was originally slide 3, where I would say something like “At the bookstore, I primarily focus on recommender systems and search. But increasingly, like many of you, I’m trying to figure out how to make use of this new power source, connective tissue, and operating system.” But it felt too longwinded and I dropped it to save 30 seconds. Too bad, I really liked the analogy and alien lego image.

Изначально это был слайд 3, где я бы сказал что-то вроде: «В книжном магазине я в основном занимаюсь рекомендательными системами и поиском. Но всё чаще, как и многие из вас, я пытаюсь понять, как использовать этот новый источник энергии, соединительную ткань и операционную систему». Но это звучало слишком растянуто, и я убрал слайд, чтобы сэкономить 30 секунд. Жаль — мне очень нравились аналогия и изображение инопланетного лего.

(Interestingly, OpenAI referred to LLMs as connective tissue for multi-modality too.)

(Интересно, что OpenAI тоже назвали LLM соединительной тканью для мультимодальности.)

On the point of not having a good way to eval LLMs, I initially had examples based on 🤗’s deep dive, which included comparisons on prompts, evaluation methodology, and ranking differences. I thought it was interesting to look at the differences but unfortunately I didn’t have the time. This and the next 3 slides after it were cut to save ~2 minutes.

По поводу отсутствия хорошего способа оценки LLM — изначально у меня были примеры, основанные на глубоком разборе от 🤗, включавшем сравнения промптов, методологий оценки и различий в ранжировании. Мне казалось интересным посмотреть на различия, но, к сожалению, времени не хватило. Этот слайд и следующие 3 были убраны, чтобы сэкономить ~2 минуты.

Comparison between MMLU prompts.

Сравнение промптов для MMLU.

Comparison between MMLU evaluation approach.

Сравнение подходов к оценке MMLU.

How model ranking changes across different MMLU implementations.

Как меняется ранжирование моделей в зависимости от реализации MMLU.

I initially had this meme on how LLMs are like (some of) us, where they focus on the intro (i.e., doc in first position) and conclusion (i.e., doc in last position). But it seemed too complex and thus was cut.

Изначально у меня был мем о том, что LLM похожи на (некоторых из) нас: они концентрируются на введении (т.е. документ на первой позиции) и заключении (т.е. документ на последней позиции). Но он показался слишком сложным и был убран.

I originally wanted to share the usefulness and flexibility of the abstractive summarization task via this slide and the two slides below. But it was cut to save about 1 minute.

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

Abstractive summarization across multiple documents to build a timeline.

Абстрактная суммаризация нескольких документов для построения хронологии.

Abstractive summarization on weekly spending.

Абстрактная суммаризация еженедельных расходов.

Initially had this slide as a datapoint on the severity of hallucinations in summarization, based on this paper that was barely a month old. Nonetheless, it was cut to save ~30 secs.

Изначально этот слайд был примером серьёзности галлюцинаций в суммаризации, на основе этой статьи, которой на тот момент было едва ли месяц. Тем не менее он был убран, чтобы сэкономить ~30 секунд.

I initially wanted to include QG-QA as a technique to evaluate factual consistency in summarization because it’s one of two main approaches to detecting factual inconsistency in summarization (the other being NLI). But, I didn’t like the complexity of the technique and could not see myself using it in production. Thus, it was cut to save ~1 minute.

Изначально я хотел включить QG-QA как метод оценки фактической согласованности в суммаризации, потому что это один из двух основных подходов к обнаружению фактической несогласованности (другой — NLI). Но мне не понравилась сложность метода, и я не видел, как его можно применить в продакшене. Поэтому он был убран, чтобы сэкономить ~1 минуту.

Wanted to include another example of how implicit feedback could be noisy but this example wasn’t as easy to grasp as I would like. Thus, it was cut.

Хотел включить ещё один пример зашумлённости неявной обратной связи, но этот пример оказался не таким наглядным, как хотелось бы. Поэтому он был убран.

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

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

Yan, Ziyou. (Oct 2023). AI Engineer 2023 Keynote - Building Blocks for LLM Systems. eugeneyan.com. https://eugeneyan.com/speaking/ai-eng-summit/.

or

или

@article{yan2023aieng, title = {AI Engineer 2023 Keynote - Building Blocks for LLM Systems}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2023}, month = {Oct}, url = {https://eugeneyan.com/speaking/ai-eng-summit/} }

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

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