How to Match LLM Patterns to Problems

eugeneyan

eugeneyan

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

How to Match LLM Patterns to Problems

Как подбирать паттерны LLM под конкретные задачи

[ llm production ] · 6 min read

[ llm production ] · 6 мин. чтения

After my previous write-up on LLM patterns, I’ve received questions on how to match those patterns to various LLM problems. Thus, in this follow-up, we’ll discuss some potential problems faced when using LLMs and the patterns that help mitigate them.

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

External vs. internal LLMs, data vs. non-data patterns

Внешние и внутренние LLM, паттерны на основе данных и без

Before we dive into it, I think it’s helpful to distinguish between external vs. internal LLMs.

Прежде чем перейти к делу, полезно разграничить внешние и внутренние LLM.

External LLMs are models we don’t have full control over. We can’t fine-tune them, are constrained by rate/token limits, and may have concerns with sending them confidential or proprietary data. Nonetheless, they’re currently the SOTA in terms of quality and safety.

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

Internal LLMs are those we develop and host ourselves. While they may not have the constraints of external LLMs, we incur the cost of developing and hosting these LLMs. Also, we typically build them on top of open LLMs (unless you have a couple million to pre-train your own). Unfortunately, these open LLMs tend to be months, if not years, behind the best 3rd-party provider LLMs.

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

With regard to patterns, I think it’s useful to understand the role data plays: Is data the main component or a by-product? Or is the pattern minimally related to data?

Что касается паттернов, полезно понимать роль данных: являются ли данные основным компонентом или побочным продуктом? Или паттерн минимально связан с данными?

For example, evals and fine-tuning are tied to data. We can’t do evals without gold labels or references; we can’t fine-tune without demonstration data. In contrast, patterns such as caching, defensive UX, and guardrails have more to do with infra and UI than data.

Например, evals и fine-tuning напрямую зависят от данных. Невозможно провести eval без эталонных меток или референсов; невозможно сделать fine-tuning без демонстрационных данных. Напротив, такие паттерны, как кэширование, defensive UX и guardrails, больше связаны с инфраструктурой и интерфейсом, чем с данными.

On the other hand, patterns such as RAG and collecting user feedback lie somewhere in the middle. RAG provides data for in-context learning but needs to be backed by retrieval or search indices. User feedback helps with fine-tuning but needs to be collected via the right UX and refined via analysis and data pipelines.

С другой стороны, такие паттерны, как RAG и сбор обратной связи от пользователей, занимают промежуточное положение. RAG предоставляет данные для обучения в контексте, но требует поисковых или индексных систем. Обратная связь помогает при fine-tuning, но её нужно собирать через правильный UX и обрабатывать с помощью аналитики и пайплайнов данных.

Matching patterns to problems

Сопоставление паттернов и проблем

Here are some LLM problems and the patterns that help address them. Since we’ve previously discussed the patterns extensively, we’ll focus on the problems here.

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

Lack of performance metrics for our specific task. When benchmarking external and internal LLMs, we often want to—rightly or wrongly—summarize performance into a table of numbers. (Note: This is fiendishly difficult, especially for more abstract tasks where there are innumerable good outputs.) And as we tweak our systems via updating prompt templates, fine-tuning models, or improving RAG, we need a way to measure improvements or regressions. Finally, how do we measure if users like or dislike these new LLM-based features, and the impact of our tweaks?

Отсутствие метрик производительности для конкретной задачи. При сравнении внешних и внутренних LLM мы часто хотим — справедливо или нет — свести производительность к таблице с числами. (Примечание: это дьявольски сложно, особенно для абстрактных задач, где существует бесчисленное множество хороших ответов.) По мере того как мы дорабатываем системы — обновляем шаблоны промптов, дообучаем модели или улучшаем RAG — нам нужен способ измерять улучшения или регрессии. Наконец, как понять, нравятся ли пользователям новые функции на базе LLM, и как оценить эффект наших доработок?

Evals: для сравнения моделей и измерения производительности при каждом изменении Сбор обратной связи: чтобы понять, что нравится и не нравится пользователям

External model performing poorly. This can be due to the model not being trained on recent data (e.g., ChatGPT’s knowledge cutoff of Sept 2021) or proprietary data within your org (e.g., internal code and documents). Other concerns include hallucinations or incorrect responses because the model lacks sufficient or the most recent context.

Внешняя модель работает плохо. Причиной может быть то, что модель не обучена на свежих данных (например, дата отсечки знаний ChatGPT — сентябрь 2021) или на проприетарных данных вашей организации (например, внутренний код и документы). Другие проблемы — галлюцинации или некорректные ответы из-за нехватки актуального контекста.

RAG: для предоставления релевантного контекста, снижения галлюцинаций и улучшения ответов Evals: для измерения улучшений при настройке поисковых индексов

Internal model performing poorly. Open LLMs tend to perform poorly on specific tasks in our specific domain out of the box. This can lead to defects such as poor extraction or summarization, non-factual responses, going off-topic, or simply lack of fluency. These LLMS may also return harmful responses that we want to minimize. While the patterns that apply to external LLMs are also relevant, because it’s an internal model, we have a few more tricks at our disposal.

Внутренняя модель работает плохо. Открытые LLM, как правило, плохо справляются с конкретными задачами в конкретном домене «из коробки». Это может приводить к некачественному извлечению или суммаризации, нефактологичным ответам, уходу от темы или просто отсутствию беглости. Такие LLM могут также генерировать вредоносные ответы, которые необходимо минимизировать. Хотя паттерны для внешних LLM здесь тоже применимы, для внутренних моделей у нас есть дополнительные инструменты.

Fine-tuning: для повышения качества на конкретных задачах в нашем домене Сбор обратной связи: для использования пользовательских предпочтений в fine-tuning

Constraints on external models. These constraints can be technical (e.g., rate limits, latency, models being excessively fine-tuned), legal (e.g., not sending confidential or user private data, copyright over and use of external LLM output), and financial (i.e., high cost of API calls). AFAIK, there are two viable solutions: Either negotiate a contract with your external LLM provider or develop and self-host your own LLMs. I suggest saintly patience for the former and the patterns below for the latter.

Ограничения внешних моделей. Эти ограничения могут быть техническими (например, лимиты запросов, задержки, чрезмерный fine-tuning моделей), юридическими (например, запрет на отправку конфиденциальных или персональных данных пользователей, авторские права на выход внешних LLM и его использование) и финансовыми (высокая стоимость API-вызовов). Насколько мне известно, есть два рабочих решения: либо договариваться о контракте с провайдером внешней LLM, либо разрабатывать и хостить собственные модели. Для первого варианта рекомендую ангельское терпение, для второго — паттерны ниже.

Fine-tuning: для повышения качества внутренних моделей на наших конкретных задачах Evals: для отслеживания прогресса внутренних LLM и сравнения с внешними Сбор обратной связи: для получения данных для fine-tuning и оценки

Latency exceeds UX requirements. Certain use cases require the entire LLM output to be available within a few hundred milliseconds, including running guardrails on the output. While streaming output helps a ton with the UX, it may not be viable for certain user experiences and interfaces (no, I’m not referring to chat).

Задержка превышает требования UX. Некоторые сценарии требуют, чтобы полный ответ LLM был доступен в течение нескольких сотен миллисекунд, включая прогон guardrails. Хотя потоковый вывод существенно улучшает пользовательский опыт, он может не подходить для определённых интерфейсов и сценариев (нет, я имею в виду не чат).

Кэширование: поиск разумных способов генерации (пакетной или асинхронной) и кэширования ответов помимо семантического сходства (например, по ID объектов)

Unreliable or unusable model output. I categorize these as syntactic vs. semantic errors. Syntactic errors occur when the model doesn’t adhere to a specific format such as JSON or a specific sentence structure, or the generated code or SQL doesn’t run. Semantic errors occur when the model output is harmful, non-factual, off-topic, or simply incoherent.

Ненадёжный или непригодный вывод модели. Я разделяю эти проблемы на синтаксические и семантические ошибки. Синтаксические ошибки возникают, когда модель не соблюдает заданный формат — JSON, определённую структуру предложений — или когда сгенерированный код или SQL не запускается. Семантические ошибки возникают, когда вывод модели вреден, нефактологичен, не по теме или просто бессвязен.

Guardrails (направляющие + синтаксические проверки): направляют вывод LLM; проверяют синтаксические ошибки Guardrails (семантические проверки): проверяют безопасность контента, фактологичность, соответствие теме и т. д.

Customer experience paper cuts. Machine learning models aren’t perfect—they will produce inaccurate output. The same goes for LLMs. Thus, after we’ve built a new LLM product/feature, how do we make it easy for users to explore and increase adoption? Also, how do we acknowledge that errors will happen, mitigate them, and earn trust over time?

Мелкие неудобства в клиентском опыте. Модели машинного обучения несовершенны — они будут выдавать неточные результаты. То же касается и LLM. Поэтому после создания нового продукта или функции на базе LLM возникает вопрос: как облегчить пользователям знакомство и повысить уровень принятия? А также — как признать неизбежность ошибок, минимизировать их и завоевать доверие со временем?

Defensive UX (для онбординга): опираться на знакомое и задавать правильные ожидания Defensive UX (для мелких неудобств): задавать правильные ожидания, обеспечивать быстрое отклонение и исправление, предоставлять подходящую атрибуцию, где это возможно Сбор обратной связи: чтобы понять, какие функции работают, а какие нет, и собрать данные для fine-tuning и evals для улучшения следующей итерации

Lack of visibility on customer impact. How do we know if our models are helping or hurting? Someone shared an anecdote of running an LLM-based customer support solution in prod for two weeks before discontinuing it—an A/B test showed that losses were 12x more when using an LLM as a substitute for their support team!

Отсутствие видимости влияния на клиентов. Как узнать, помогают наши модели или вредят? Кто-то рассказал случай, когда решение для поддержки клиентов на базе LLM проработало в проде две недели, а затем было отключено — A/B-тест показал, что убытки при использовании LLM в качестве замены команды поддержки были в 12 раз выше!

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

• • •

• • •

Are there any key problems I’ve missed? Please let me know!

Есть ли ключевые проблемы, которые я упустил? Пожалуйста, дайте мне знать!

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

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

Yan, Ziyou. (Aug 2023). How to Match LLM Patterns to Problems. eugeneyan.com. https://eugeneyan.com/writing/llm-problems/.

Yan, Ziyou. (Aug 2023). How to Match LLM Patterns to Problems. eugeneyan.com. https://eugeneyan.com/writing/llm-problems/.

or

или

@article{yan2023llm-problems, title = {How to Match LLM Patterns to Problems}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2023}, month = {Aug}, url = {https://eugeneyan.com/writing/llm-problems/} }

@article{yan2023llm-problems, title = {How to Match LLM Patterns to Problems}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2023}, month = {Aug}, url = {https://eugeneyan.com/writing/llm-problems/} }

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

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