How to Match LLM Patterns to Problems

eugeneyan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• • •

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

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

Yan, Ziyou. (Aug 2023). How to Match LLM Patterns to Problems. eugeneyan.com. 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/} }

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