Чего ожидать от поколения, усиленного с помощью сверхпоиска, и самостоятельных LLM-систем

Чего ожидать от поколения, обладающего сверхспособностями благодаря использованию продвинутого поиска и самостоятельных LLM-систем

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

В блоге под названием: «Узнайте о приросте производительности с помощью усиления поколения с использованием извлечения», мы исследовали, как количество извлеченных документов может улучшить качество ответов LLM. Мы также описали, как векторизованный LLM, основанный на наборе данных MMLU, хранящемся в векторной базе данных, такой как MyScale, генерирует более точные ответы, когда его интегрируют с контекстуально связанными знаниями и без тонкой настройки набора данных.

Таким образом, главный момент заключается в следующем:

RAG заполняет знаковые пробелы, сокращает галлюцинации, дополняя подсказки внешними данными.

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

Как обеспечить большую безопасность данных и сохранить контроль над системой?

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

Почему самохостинговые LLM?

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

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

Продолжим обсуждение, обсудим эти четыре значительные проблемы более подробно:

Конфиденциальность

Конфиденциальность должна быть основной проблемой при интеграции API LLM с вашим приложением.

Почему конфиденциальность такая проблема?

Ответ на этот вопрос имеет несколько аспектов, о которых говорят следующие моменты:

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

Самохостинговые LLM решают эти проблемы, поскольку они безопасны: ваши данные никогда не передаются третьему лицу через API.

Контроль

Услуги LLM, такие как OpenAI GPT-3.5, обычно цензурируют темы, такие как насилие и запрос медицинской помощи. У вас нет контроля над тем, какое содержание подвергается цензуре. Однако вы можете захотеть разработать собственную модель цензуры (и правила).

Как вы можете применить модель цензуры, удовлетворяющую вашим требованиям?

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

Утечки знаний

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

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

Как предотвратить утечки знаний?

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

Экономическая эффективность

Спорно, являются ли самохостинговые LLM экономически выгодными по сравнению с облачными LLM. Исследование, описанное в статье: “Как непрерывная пакетная обработка увеличивает пропускную способность LLM до 23 раза, при этом сокращая задержку p50″ сообщает, что самохостинговые LLM являются более эффективными с точки зрения затрат, если правильно балансировать задержку и пропускную способность с помощью стратегии непрерывной пакетной обработки.

Примечание: Мы более подробно раскроем эту концепцию дальше в этом тексте.

Получите максимум от своего RAG с помощью самоуправляемых LLM-ов

LLM-ы поглощают вычислительные ресурсы. Они требуют огромных объемов ресурсов для вывода и предоставления ответов. Добавление RAG только увеличит потребность в вычислительных ресурсах, поскольку они могут добавить более 2000 токенов к токенам, необходимым для ответов на вопросы для повышения точности. К сожалению, эти дополнительные токены влекут дополнительные затраты, особенно если вы работаете с API LLM с открытым исходным кодом, такими как OpenAI.

Эти показатели могут улучшиться при самостоятельном размещении LLM с использованием матриц и методов, таких как KV Cache и Continuous Batching, улучшая эффективность по мере увеличения запросов. Однако, с другой стороны, большинство облачных платформ для вычисления на основе графической обработки, таких как RunPod, тарифицируют ваши работающие часы, а не пропускную способность токенов: это хорошие новости для самоуправляемых систем RAG, что приводит к более низкой стоимости за единицу подсказочного токена.

Следующая таблица говорит сама за себя: самоуправляемые LLM совместно с RAG могут обеспечить экономичность и точность. Вкратце:

  • Стоимость падает до всего 10% от gpt-3.5-turbo в случае полной загрузки.
  • Пайплайн RAG llama-2-13b-chat с десятью контекстами стоит всего $0.04 за 1840 токенов, что составляет треть от стоимости gpt-3.5-turbo без контекста.

Таблица: Общие сравнительные затраты в американских центах

Методология исследования

Мы использовали text-generation-inference, чтобы запустить неускоренную модель llama-2-13b-chat для всех оценок в этой статье. Мы также арендовали облачный под с 1x NVIDIA A100 80GB, стоимостью $1.99 в час. Под такого размера может развертываться llama-2-13b-chat. Важно отметить, что каждая цифра использует первый 4-й квантиль как нижнюю границу и третий 4-й квантиль как верхнюю границу, что визуально показывает разброс данных с помощью ящиков.

Примечание: Для развертывания моделей с 70B требуется больше доступной памяти GPU.

Расширение пропускной способности LLM до предела

Общая пропускная способность должна быть первым критерием для рассмотрения. Мы перегрузили LLM от 1 до 64 потоков, чтобы имитировать множество одновременных запросов. Ниже приведено описание того, как пропускная способность генерации снижается с увеличением размера запросов. Пропускная способность генерации была стабилизирована на уровне около 400 токенов в секунду, независимо от того, как вы увеличиваете параллелизм.

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

Измерение времени загрузки для более длинных подсказок

Реактивность модели имеет для нас важнейшее значение. Мы также знаем, что процесс генерации для обычной языковой модели является итеративным. Для улучшения времени отклика модели мы кэшировали результаты предыдущих генераций, чтобы уменьшить время вычислений с помощью KV Cache. Мы называем этот процесс “загрузкой”, когда создается LLM с использованием KV Cache.

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

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

Следующие мункты относятся к этому графику:

  • Время загрузки до 32 потоков является приемлемым;
  • Время загрузки большинства примеров составляет менее 1000 мс.
  • Время загрузки резко увеличивается при увеличении параллелизма.
  • Примеры с использованием 64 потоков начинаются выше 1000 мс и заканчиваются примерно за 10 секунд.
  • Это слишком долго для ожидания пользователей.

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

Оценка задержки генерации

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

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

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

Разумно ожидать задержку генерации менее 90 мс, а даже около 60 мс, если вы не давите слишком сильно на контексты и конкурентность. Следовательно, в этой настройке мы рекомендуем пять контекстов с конкурентностью 32.

Сравнение стоимости gpt-3.5-turbo

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

  • Cserv – почасовая стоимость облачного сервера с GPU.
  • Tboot и Tgen – время загрузки и время генерации (в миллисекундах) для каждого запроса соответственно.
  • Nparallel – определяет количество обрабатываемых одновременно потоков (параллелизм).

Использование кэша KV и непрерывной пакетной обработки повышает эффективность системы и потенциально снижает расходы до одной десятой стоимости gpt-3.5-turbo при правильной настройке. Для оптимальных результатов рекомендуется использовать конкурентность 32 потока.

Что дальше?

Последний вопрос, который мы задаем,:

Что мы можем узнать из этих диаграмм и куда идти дальше?

Баланс между задержкой и пропускной способностью

Всегда есть компромисс между задержкой и пропускной способностью. Оценка вашего ежедневного использования и терпимости пользователей к задержке является хорошей отправной точкой. Чтобы максимизировать производительность за потраченные деньги, мы рекомендуем ожидать 32 конкуренции на 1x NVIDIA A100 80GB с моделью llama-2-13b или аналогичными. Это даст вам наилучшую пропускную способность, относительно низкую задержку и разумный бюджет. Вы всегда можете изменить свое решение, но помните, что сначала всегда оценивайте свой случай использования.

Тонкая настройка модели: длиннее и сильнее

Теперь вы можете тонко настроить свою модель с помощью систем RAG. Это поможет модели привыкнуть к длинным контекстам. Есть репозитории с открытым исходным кодом, которые настраивают LLM на более длинную длину ввода, например Long-LLaMA. Модели, тонко настроенные на более длинные контексты, хорошо обучены внутриконтекстным обучением и показывают лучшие результаты, чем модели, растянутые с помощью RoPE-масштабирования.

Сочетание MyScale с системой RAG: анализ стоимости вычислений и стоимости базы данных

Сочетая MyScale и 10 GPU A100 от RunPod с MyScale (векторная база данных), вы можете легко настроить систему Llama2-13B + базу знаний «Wikipedia», полностью удовлетворяющую потребностям до 100 одновременных пользователей.

Прежде чем мы закончим это обсуждение, давайте рассмотрим простой анализ стоимости работы такой системы:

Примечания:

  • Эти расчеты примерные на основе расчетов стоимости, подсвеченных выше.
  • Системы RAG большого масштаба значительно улучшают производительность LLM при менее чем 15% дополнительных затратах на услуги векторной базы данных.
  • Амортизированная стоимость векторной базы данных будет еще ниже по мере увеличения числа пользователей.

В заключение

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

Наконец, можно увидеть, что стоимостная эффективность MyScale делает системы RAG намного более масштабируемыми!

Поэтому, если вас интересует оценка производительности QA в RAG-процессах, присоединяйтесь к нам на Discord или Twitter. А также вы можете оценить свои собственные RAG-процессы с помощью RQABenchmark!

Мы будем держать вас в курсе наших новейших открытий в отношении LLM и векторных баз данных!