Ещё один кэш, но для ChatGPT
ChatGPT — впечатляющая технология, которая позволяет разработчикам создавать приложения, меняющие правила игры. Однако производительность и стоимость моделей языковых моделей (LLM) являются существенными проблемами, препятствующими их широкому применению в различных областях. Например, когда мы разрабатывали чат-бота https://osschat.io/ для сообщества open-source, ChatGPT был главным узким местом, мешавшим нашему приложению отвечать так быстро, как ожидалось. Стоимость также является еще одним препятствием, не позволяющим нам обслуживать больше open-source-сообществ.
Во время командного обеда пришла в голову идея: почему бы не добавить еще один слой кэша для ответов, сгенерированных LLM? Этот слой кэширования был бы похож на то, как Redis и Memcache когда-то были созданы для ускорения и снижения стоимости доступа к базам данных. С помощью такого кэша мы можем снизить расходы на генерацию контента и обеспечивать более быстрые ответы в реальном времени. Кроме того, кэш можно использовать для имитации ответов, что помогает нам проверять функции нашего приложения без дополнительных расходов на наши тесты.
Традиционные кэши извлекают данные только тогда, когда ключ идентичен. Это ограничение представляет серьезную проблему для AIGC-приложений, которые часто работают с естественным языком и нуждаются в более конкретных синтаксических ограничениях или дополнительных механизмах очистки данных. Чтобы решить эту проблему, мы создали Yet Another Cache для AIGC-native приложений, который назвали GPTCache (https://github.com/zilliztech/GPTCache), поскольку он изначально создан для ускорения ChatGPT и оптимизирован для семантического поиска.
С GPTCache вы можете кэшировать ответы ваших LLM всего несколькими изменениями строк кода, ускоряя ваши LLM-приложения в 100 раз. В этой статье блога мы расскажем, как мы построили семантический кэш, и о некоторых дизайнерских решениях, которые мы приняли.
Почему кэш помог бы в наших сценариях использования?
Наш чат-бот позволяет пользователям задавать общие вопросы об open-source проектах на GitHub и подробные вопросы о конкретных репозиториях GitHub и связанных с ними страницах документации. По мере роста популярности нашего сервиса увеличиваются расходы, связанные с вызовом OpenAI APIs. Мы заметили, что определенные типы контента, такие как популярные или трендовые темы и востребованные репозитории GitHub, доступны чаще. Вопросы «Что такое» являются наиболее часто запрашиваемыми, наряду со списком рекомендуемых вопросов на главной странице сервиса.
Как и в традиционных приложениях, пользовательский доступ для AIGC-приложений обладает временной и пространственной локальностью. Мы можем воспользоваться этим, внедрив систему кэширования, которая сокращает количество вызовов ChatGPT. Учитывая медленное время ответа и высокую стоимость OpenAI APIs, такая система кэширования необходима; обычно они взимают несколько долларов за 1M токенов и требуют нескольких секунд для ответа. Выполняя векторный поиск среди миллионов кэшированных векторов и извлекая кэшированный результат из базы данных, мы можем значительно сократить среднее сквозное время ответа нашего сервиса и снизить стоимость сервиса OpenAI.
Почему Redis не подойдет в сценариях AIGC?
Я большой поклонник Redis из-за его гибкости и производительности, что делает его подходящим для различных сценариев использования. Однако это не мой первый выбор для создания кэша для ChatGPT. Redis использует модель данных ключ-значение и не может запрашивать приблизительные ключи.
Например, предположим, пользователь задает вопросы вроде «Каковы преимущества и недостатки всех фреймворков глубокого обучения?» или «Расскажи мне о PyTorch vs. TensorFlow vs. JAX?». В таком случае он спрашивает об одном и том же. Однако Redis не сможет найти совпадение с запросом, независимо от того, кэшируете ли вы весь вопрос или только ключевые слова, сгенерированные токенизатором. Эта неудача связана с тем, что разные слова могут иметь одно и то же значение в естественном языке, а модели глубокого обучения лучше раскрывают эту семантику, чем правила. Поэтому нам следует включить поиск по векторному сходству как часть семантического кэша.
Еще одна причина, по которой Redis может быть не идеальным вариантом для кэширования AIGC, — его высокая стоимость. Ключи и значения имеют большой размер из-за длинного контекста, поэтому хранение всего в Redis может быстро стать дорогим. Кэширование с помощью дисковой базы данных может быть лучшей альтернативой, потому что ответы chatGPT медленные, поэтому не имеет значения, может ли кэш отвечать за доли миллисекунды или за десятки миллисекунд.
Создайте GPTCache с нуля
Мы вдохновились этой идеей и обсуждали ее всю ночь. В результате мы разработали полезную архитектурную диаграмму, показанную ниже:
Высокоуровневая архитектура GPTCache | Zilliz
Позже мы решили упростить реализацию, отказавшись от менеджера контекста. Несмотря на эти изменения, система по-прежнему состоит из пяти основных компонентов. Ниже мы перечислили важные функциональные возможности каждого из компонентов:
- LLM-адаптер: Адаптеры преобразуют запросы LLM в протокол кэша, а кэшированные результаты — в ответы LLM. Мы стремимся сделать этот кэш прозрачным, не требующим дополнительных усилий для интеграции в нашу систему или любую другую систему, зависящую от ChatGPT. Адаптер должен обеспечивать простую интеграцию всех LLM и быть расширяемым для будущих мультимодальных моделей. Изначально мы реализовали адаптеры OpenAI и langchain, поскольку наша система в значительной степени зависит от них. Несколько реализаций также обеспечили осмысленность нашего интерфейса для всех API LLM, чтобы мы могли в дальнейшем расширять адаптер.
- Генератор эмбеддингов: Генератор эмбеддингов кодирует запросы в эмбеддинги, обеспечивая поиск по сходству. Чтобы удовлетворить потребности разных пользователей, мы поддерживаем два способа генерации эмбеддингов. Первый — через облачные сервисы, такие как OpenAI, Hugging Face и Cohere. Второй — через локальную модель, обслуживаемую на ONNX. Кроме того, мы планируем поддерживать генераторы эмбеддингов PyTorch и кодировать изображения, аудиофайлы и другие типы неструктурированных данных.
- Менеджер кэша: Менеджер кэша является ключевым компонентом GPTCache и выполняет три функции: хранилище кэша, которое сохраняет запросы пользователей и ответы LLM на них; векторное хранилище, которое сохраняет векторные эмбеддинги и выполняет поиск похожих результатов; и управление вытеснением, которое контролирует емкость кэша и вытесняет устаревшие данные, когда кэш заполнен, используя политику LRU или FIFO. Менеджер кэша использует подключаемую архитектуру. Изначально мы реализовали его с SQLite и FAISS в качестве бэкенда. Позднее мы расширили его, включив другие реализации, такие как MySQL, PostgreSQL, Milvus и другие векторные базы данных, что сделало его еще более масштабируемым. Менеджер вытеснения освобождает память, удаляя старые, неиспользуемые данные из GPTCache. При необходимости он удаляет записи как из кэша, так и из векторного хранилища. Однако частые удаления в большинстве систем векторного хранения могут приводить к снижению производительности. GPTCache запускает асинхронные операции, такие как построение индекса или уплотнение, после достижения порога удаления, чтобы смягчить эту проблему.
- Оценщик сходства: GPTCache извлекает из своего кэша top k похожих ответов и использует функцию оценки сходства, чтобы определить, соответствует ли кэшированный ответ входному запросу. GPTCache поддерживает три функции оценки: оценку точного совпадения, оценку расстояния между эмбеддингами и оценку модели ONNX. Модуль оценки сходства имеет решающее значение для эффективности GPTCache. После исследования мы использовали дообученную версию модели ALBERT. Однако всегда есть возможности для улучшения за счет использования других дообученных языковых моделей или других LLM, таких как LLaMa-7b. Любые вклады или предложения будут очень приветствоваться.
- Постпроцессоры: Постпроцессор помогает подготовить окончательный ответ пользователю. Он может вернуть наиболее похожий ответ или добавить случайность на основе температуры запроса. Если похожий ответ не может быть найден в кэше, запрос будет делегирован LLM для генерации и кэширования нового ответа.
Оценка
Чтобы проиллюстрировать нашу идею, мы обнаружили набор данных, содержащий три пары предложений: положительные примеры с идентичной семантикой, отрицательные примеры со связанной, но не идентичной семантикой, и предложения между положительными и отрицательными примерами с полностью несвязанной семантикой. Вы можете найти набор данных в нашем репозитории.
Эксперимент 1
Чтобы установить базовый уровень, мы сначала кэшируем ключи всех 30 000 положительных примеров. Затем мы случайным образом выбираем 1 000 примеров и используем их парные значения в качестве запросов. Вот полученные нами результаты:
| Попадание в кэш | Промах кэша | Положительные | Отрицательные | Задержка попадания |
|---|---|---|---|---|
| 876 | 124 | 837 | 39 | 0.20s |
Мы обнаружили, что установка порога сходства GPTCache на 0.7 обеспечивает хороший баланс между долей попаданий и долей положительных результатов. Поэтому мы будем использовать эту настройку для всех последующих тестов.
Чтобы определить, является ли кэшированный результат положительным или отрицательным по отношению к запросу, мы используем оценку сходства, сгенерированную ChatGPT, и устанавливаем положительный порог на 0.6. Мы генерируем эту оценку сходства с помощью следующего промпта:
Please rate the similarity of the following two questions on a scale from 0 to 1, where 0 means not related and 1 means exactly the same meaning.
The questions "What are some good tips for self-study?" and "What are the smart tips for self-studying?" are very similar, with a similarity score of 1.0.
The questions "What are some essential things for wilderness survival?" and "What are the things you need for survival?" are quite similar, with a similarity score of 0.8.
The questions "What advice would you give to 16-year-old you?" and "Where should I promote my business online?" are completely different, so the similarity score is 0.
So, questions "Which app lets you watch live football for free?" and "How can I watch a football live match on my phone?" The similarity score is
Эксперимент 2
Мы отправили запросы, состоящие из 50% положительных образцов и 50% отрицательных образцов (несвязанных запросов). В результате после выполнения 1160 запросов мы получили следующие результаты:
| Попадание в кэш | Промах кэша | Положительные | Отрицательные | Задержка попадания |
|---|---|---|---|---|
| 570 | 590 | 549 | 21 | 0.17s |
Доля попаданий составляет почти 50%, а доля отрицательных результатов среди попаданий похожа на показатель эксперимента 1, что означает, что GPTCache отлично справился с различением связанных и несвязанных запросов.
Эксперимент 3
Мы провели еще один эксперимент, вставив все отрицательные образцы в кэш и используя их парные значения в качестве запросов. Хотя некоторые пары отрицательных образцов имели высокую оценку сходства (больше 0.9, согласно ChatGPT), к нашему удивлению, ни один из отрицательных примеров не попал в кэш. Вероятно, это связано с тем, что модель, используемая в оценщике сходства, дообучена на этом наборе данных, и почти все оценки сходства для отрицательных образцов были занижены.
Будущая оценка
Мы интегрировали GPTCache в наш сайт OSSChat и сейчас работаем над сбором производственной статистики. Так что следите за выпуском нашего следующего бенчмарка, который будет включать реальные сценарии использования.
Это конец блога, но только начало для GPTCache
Мы довольны тем, как быстро смогли реализовать и выложить в open source такую потрясающую работу менее чем за две недели. Браво! Надеемся, теперь вы полностью понимаете идею GPTCache, как он был реализован, и у вас есть множество идей о том, как его можно интегрировать в вашу систему.
Давайте быстро резюмируем некоторые ключевые моменты о GPTCache:
- ChatGPT впечатляет, но иногда он может быть дорогим и медленным.
- Как и в других приложениях, мы можем наблюдать локальность в сценариях использования AIGC.
- Чтобы полностью использовать эту локальность, вам нужен только семантический кэш.
- Чтобы создать семантический кэш, встройте контекст вашего запроса и сохраните его в векторной базе данных. Затем выполните поиск похожих запросов в кэше перед отправкой запроса в LLMs.
- Не забывайте управлять емкостью кэша!
Сейчас мы работаем над интеграцией GPTCache с большим количеством LLMs и векторных баз данных. Скоро мы выпустим GPTCache Bootcamp, который объяснит, как использовать GPTCache вместе с LangChain и Hugging Face, а также другие идеи для того, чтобы сделать GPTCache мультимодальным. Мы приветствуем любые вклады или предложения и призываем вас показать нам, как GPTCache помогает вам в вашем приложении!
Узнать больше о GPTCache
Читать далее
Milvus 2.6.x Now Generally Available on Zilliz Cloud, Making Vector Search Faster, Smarter, and More Cost-Efficient for Production AI
Milvus 2.6.x is now GA on Zilliz Cloud, delivering faster vector search, smarter hybrid queries, and lower costs for production RAG and AI applications.
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.
Vector Databases vs. Document Databases
Use a vector database for similarity search and AI-powered applications; use a document database for flexible schema and JSON-like data storage.