Будет ли Retrieval Augmented Generation (RAG) убита LLM с длинным контекстом?
Стремление к инновациям и превосходству в ИИ не показывает никаких признаков замедления. Недавно Google представила Gemini 1.5, всего через два месяца после дебюта Gemini, своей новейшей большой языковой модели (LLM), способной обрабатывать контексты объемом до впечатляющих 10 миллионов токенов. Одновременно OpenAI вышла на сцену с Sora, мощной моделью преобразования текста в видео, известной своими захватывающими визуальными эффектами. Противостояние этих двух передовых технологий вызвало дискуссии о будущем ИИ, особенно о роли и потенциальном исчезновении Retrieval Augmented Generation (RAG).
В этом блоге мы рассмотрим тонкости возможностей Gemini в работе с длинным контекстом, ограничения и влияние на эволюцию техник Retrieval Augmented Generation. Самое главное — мы обсудим, находится ли RAG на грани исчезновения и как оптимизировать RAG-системы.
Понимание способности Gemini работать с длинным контекстом
Хотя привлекательность визуальных эффектов Sora привлекает больше внимания, меня больше интересует Gemini и сопровождающий ее технический отчет, объемом более 50 страниц, в котором исследуется тестирование возможностей Gemini в работе с длинным контекстом и мультимодальностью. Согласно этому отчету, Gemini 1.5 Pro поддерживает сверхдлинные контексты объемом до 10 миллионов токенов и обработку мультимодальных данных, что позволяет Gemini беспрепятственно взаимодействовать с разнообразными данными — от целой книги и массивных коллекций документов до обширных библиотек кода и часового фильма.
Gemini 1.5 Pro поддерживает сверхдлинные контексты объемом до 10M токенов. Источник изображения: https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/
Стабильность и точность извлечения
В этом отчете представлен метод оценки "иголка в стоге сена" для тестирования и сравнения способности Gemini 1.5 Pro и GPT-4 к извлечению информации. В этом тесте Google вставляет текстовые сегменты ("иголки") в разные позиции длинного документа ("стога сена"), а Gemini и GPT должны найти и назвать соответствующие документы, чтобы извлечь их.
Результаты тестирования показывают, что Gemini 1.5 Pro достигает 100% полноты при объеме до 530 000 токенов и сохраняет более 99,7% полноты при объеме до 1M токенов. Даже при сверхдлинном документе объемом 10M токенов модель сохраняет впечатляющий показатель полноты 99,2%. Хотя GPT-4 отлично справляется с объемом менее 128 000 токенов, Gemini более эффективно обрабатывает более протяженные контексты. Эти результаты подчеркивают превосходное извлечение информации, стабильность и точность Gemini в исключительно длинных контекстах объемом до 10M токенов.
Источник изображения: https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
Ответы на вопросы
Помимо тестирования способности Gemini к извлечению информации, Google оценивает ее способность отвечать на вопросы при предоставленном контексте. В этом тесте Google использует книгу Les Misérables (710 000 токенов) в качестве контекста и просит Gemini 1.5 Pro, Gemini 1.0 Pro и Claude 2.1 от Anthropic отвечать на вопросы о книге.
Поскольку Gemini 1.0 Pro и Claude 2.1 поддерживают меньшую длину контекста, чем 710 000 токенов, они должны использовать технику генерации с дополненным извлечением (RAG), чтобы получить доступ к наиболее релевантным фрагментам Top-K (до 4 000 токенов) из книги в качестве своего контекста. У Gemini более большое контекстное окно, поэтому он использует всю книгу в качестве своего контекста. Этот тест также сравнивает производительность трех моделей в сценарии 0-shot, где в качестве контекстов ничего не предоставляется.
Результаты тестирования показывают, что Gemini 1.5 Pro превосходит другие LLM на базе RAG в ответах на вопросы, демонстрируя свое доминирование в понимании и обработке гигантских текстовых коллекций. Этот тест также показывает, что техника генерации с дополненным извлечением часто испытывает трудности с разрешением референциальных выражений и рассуждением между источниками данных с дальними зависимостями.
Источник изображения: https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
Убьют ли LLM с длинным контекстом RAG?
Фреймворк генерации с дополненным извлечением, включающий векторную базу данных, LLM и prompt-as-code, — это передовая технология, которая бесшовно интегрирует внешние источники знаний, чтобы обогатить базу знаний LLM для получения точных и релевантных документов и ответов. Это проверенное решение, которое эффективно решает фундаментальные проблемы LLM, такие как галлюцинации и отсутствие предметно-специфичных знаний.
Наблюдая впечатляющую производительность Gemini при обработке длинных контекстов, некоторые голоса быстро предсказывают гибель RAG. Например, в обзоре Gemini 1.5 Pro в Twitter доктор Яо Фу смело заявил: «Контекст 10M убивает RAG».
Верно ли это утверждение? С моей точки зрения, ответ — «НЕТ». Развитие технологии RAG только началось и продолжит эволюционировать. Хотя Gemini превосходно справляется с управлением расширенными контекстами, он сталкивается с устойчивыми проблемами, обобщенными как 4V: Velocity, Value, Volume и Variety.
Проблемы 4V для LLM
Velocity: Gemini сталкивается с препятствиями в достижении времени ответа менее секунды для обширных контекстов, что подтверждается 30-секундной задержкой при ответе на 360 000 контекстов. Несмотря на оптимизм в отношении вычислительных достижений LLM, быстрые ответы на уровне менее секунды при извлечении длинных контекстов остаются сложной задачей для крупных моделей на базе трансформеров.
Value: Ценностное предложение LLM подрывается значительными затратами на инференс, связанными с генерацией высококачественных ответов в длинных контекстах. Например, извлечение 1 миллиона токенов наборов данных по цене 1.50 за один запрос. Этот фактор стоимости делает такие высокие расходы непрактичными для повседневного использования, создавая значительный барьер для широкого внедрения.
Volume: Несмотря на способность обрабатывать большое контекстное окно объемом до десяти миллионов токенов, объемная емкость Gemini выглядит незначительной по сравнению с масштабами неструктурированных данных. Например, ни одна LLM, включая Gemini, не может адекватно вместить колоссальный масштаб данных, содержащихся в поисковом индексе Google. Кроме того, частные корпоративные данные должны оставаться в пределах своих владельцев, которые могут выбрать использование RAG, обучение собственных моделей или использование частной LLM.
Разнообразие: Реальные сценарии использования включают не только неструктурированные данные, такие как длинные тексты, изображения и видео, но и широкий спектр структурированных данных, которые могут быть нелегко захвачены LLM для целей обучения, например данные временных рядов, графовые данные и изменения кода. Оптимизированные структуры данных и алгоритмы извлечения необходимы для эффективной обработки таких разнообразных данных.Все эти вызовы подчеркивают важность сбалансированного подхода при разработке AI-приложений, делая RAG все более важным в развивающемся ландшафте искусственного интеллекта.
Стратегии оптимизации эффективности RAG
Хотя retrieval augmented generation доказала свою пользу в снижении галлюцинаций LLM, у нее есть ограничения. В этом разделе мы рассмотрим стратегии оптимизации эффективности retrieval augmented generation, чтобы достичь баланса между точностью и производительностью и сделать системы RAG более адаптируемыми для более широкого спектра приложений.
Улучшение понимания длинного контекста
Традиционные методы retrieval augmented generation часто полагаются на разбиение на фрагменты для векторизации неструктурированных данных, главным образом из-за ограничений размера моделей эмбеддингов и их контекстных окон. Однако этот подход с разбиением на фрагменты имеет два заметных недостатка.
- Во-первых, он разбивает входную последовательность на изолированные фрагменты, нарушая непрерывность контекста и негативно влияя на качество эмбеддингов.
- Во-вторых, существует риск разделения последовательной информации на отдельные фрагменты, что потенциально может привести к неполному извлечению важной информации.
В ответ на эти вызовы новые стратегии эмбеддингов на основе LLM получили распространение как эффективные решения. Они обладают лучшей способностью к созданию эмбеддингов и поддерживают расширенные контекстные окна. Например, SRF-Embedding-Mistral и GritLM7B, две наиболее эффективные языковые модели эмбеддингов в Huggingface MTEB LeaderBoard, поддерживают контексты длиной 32 тыс. токенов, демонстрируя существенное улучшение возможностей эмбеддингов. Это улучшение встраивания неструктурированных данных также повышает способность RAG понимать длинные контексты.
Еще один эффективный подход к решению описанных выше проблем — недавно выпущенная стратегия BGE Landmark Embedding. Этот подход использует архитектуру без разбиения на фрагменты, где эмбеддинги для мелкозернистых входных единиц, например предложений, могут генерироваться на основе связного длинного контекста. Он также использует функцию, учитывающую позицию, чтобы облегчить полное извлечение полезной информации, состоящей из нескольких последовательных предложений в длинном контексте. Поэтому landmark embedding полезен для повышения способности систем RAG понимать и обрабатывать длинные контексты.
Архитектура landmark embedding. Токены Landmark (LMK) добавляются в конец каждого предложения. Скользящее окно используется для обработки входных текстов, длина которых превышает контекстное окно LLM. Источник изображения: https://arxiv.org/pdf/2402.11573.pdf
Эта диаграмма сравнивает методы Sentence Embedding и Landmark Embedding в помощи RAG-приложениям отвечать на вопросы. Первый работает с разбитым на фрагменты контекстом, который, как правило, выбирает заметное предложение. Второй поддерживает связный контекст, что позволяет ему выбрать правильное предложение. Предложения, выделенные синим и фиолетовым цветом, являются ответами, извлеченными двумя методами embeddings соответственно. RAG-система, использовавшая Sentence embedding, дала неверный ответ, тогда как RAG на основе Landmark embedding дала правильный ответ. Это изображение адаптировано из: https://arxiv.org/abs/2402.11573
Использование гибридного поиска для улучшения качества поиска
Качество ответов retrieval augmented generation зависит от его способности извлекать высококачественную релевантную информацию. Очистка данных, извлечение структурированной информации и гибридный поиск — все это эффективные способы повысить качество извлечения. Недавние исследования показывают, что модели sparse vector, такие как Splade, превосходят модели dense vector в извлечении знаний вне предметной области, восприятии ключевых слов, семантическом поиске и многих других областях.
Недавно выпущенная с открытым исходным кодом BGE_M3 модель embedding может генерировать sparse, dense и Colbert-подобные токен-векторы в рамках одной модели. Эта инновация значительно улучшает качество извлечения в vector database за счет выполнения гибридных извлечений по разным типам векторов. Примечательно, что этот подход соответствует широко принятой концепции гибридного поиска среди поставщиков vector database, таких как Zilliz. Например, предстоящий релиз Milvus 2.4 обещает более комплексный гибридный поиск по dense и sparse векторам.
Использование передовых технологий для повышения производительности RAG
На этой диаграмме Wenqi Glantz перечислила 12 болевых точек при разработке RAG pipeline и предложила 12 соответствующих решений для устранения этих проблем. Источник изображения:https://towardsdatascience.com/12-rag-pain-points-and-proposed-solutions-43709939a28c
Максимизация возможностей RAG включает решение многочисленных алгоритмических задач и использование сложных инженерных возможностей и технологий. Как подчеркнула Wenqi Glantz в своем блоге, разработка RAG pipeline представляет как минимум 12 сложных инженерных задач. Решение этих задач требует глубокого понимания алгоритмов ML и использования сложных методов, таких как переписывание запросов, данные для обучения распознаванию намерений,, и обнаружение сущностей.
Даже продвинутые модели, такие как Gemini 1.5, сталкиваются с существенными препятствиями. Им требуется 32 вызова, чтобы достичь уровня точности 90,0% в бенчмарк-тестах Google MMLU. Это подчеркивает характер максимизации производительности в RAG-системах.
Векторные базы данных, одна из передовых технологий ИИ, являются ключевым компонентом в конвейере RAG. Выбор более зрелой и продвинутой векторной базы данных, такой как Milvus, расширяет возможности вашего конвейера RAG от генерации ответов до таких задач, как классификация, извлечение структурированных данных и обработка сложных PDF-документов. Такие многогранные улучшения векторных баз данных способствуют адаптивности систем RAG в более широком спектре сценариев применения.
Заключение: RAG остается ключевым элементом устойчивого успеха AI-приложений.
Большие языковые модели меняют мир, но они не могут изменить фундаментальные принципы нашего мира. Разделение вычислений, памяти и внешнего хранилища данных существует с момента появления архитектуры фон Неймана в 1945 году. Однако даже сегодня, когда память одной машины достигает терабайтного уровня, SATA- и флеш-диски по-прежнему играют важнейшие роли в различных сценариях применения. Это демонстрирует устойчивость устоявшихся парадигм перед лицом технологической эволюции.
Фреймворк RAG по-прежнему является ключевым элементом устойчивого успеха AI-приложений. Предоставление им долговременной памяти для больших языковых моделей оказывается незаменимым для разработчиков, стремящихся к оптимальному балансу между качеством запросов и экономической эффективностью. При развертывании генеративного ИИ крупными предприятиями RAG является критически важным инструментом контроля затрат без ущерба для качества ответов.
Подобно тому как развитие оперативной памяти не может вытеснить жесткие диски, роль RAG в сочетании с поддерживающими его технологиями, такими как векторная база данных, остается неотъемлемой и адаптивной. Он готов сохранять свою значимость и сосуществовать в новом, постоянно развивающемся ландшафте данных AI-приложений и информационного поиска.
Читать далее
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.
Zilliz Cloud Update: Tiered Storage, Business Critical Plan, Cross-Region Backup, and Pricing Changes
This release offers a rebuilt tiered storage with lower costs, a new Business Critical plan for enhanced security, and pricing updates, among other features.
Build for the Boom: Why AI Agent Startups Should Build Scalable Infrastructure Early
Explore strategies for developing AI agents that can handle rapid growth. Don't let inadequate systems undermine your success during critical breakthrough moments.