Векторный поиск и RAG - баланс между точностью и контекстом
Введение
Большие языковые модели (LLM) добились значительного прогресса, особенно в машинном обучении и обработке естественного языка, позволяя машинам с легкостью выполнять сложные задачи. Однако по мере развития технологии LLM она столкнулась с уникальной проблемой: галлюцинациями ИИ. Это происходит, когда ИИ генерирует некорректную или ложную информацию, заставляя нас сомневаться в том, насколько надежны эти системы. Christy Bergman, Developer Advocate в Zilliz с богатым опытом в AI/ML, недавно рассказала о влиянии этих галлюцинаций и о том, как они сказываются на развертывании систем ИИ, на Unstructured Data Meetup.
Посмотрите выступление Christy
Во время своей презентации Christy обсудила, что вызывает галлюцинации ИИ и каковы их последствия. Она также упомянула основную концепцию под названием Retrieval Augmented Generation (RAG), метод, используемый для повышения надежности языковых моделей путем предоставления релевантной, актуальной информации, связанной с вопросом пользователя. Эта техника помогает обеспечить моделям доступ к самым новым данным, таким как свежие новости или исследования, чтобы давать более качественные ответы и снижать количество ошибок.
Понимание галлюцинаций ИИ
Галлюцинации ИИ обозначают явление, при котором системы искусственного интеллекта, особенно основанные на больших языковых моделях, генерируют фактически неверные, вводящие в заблуждение или полностью сфабрикованные результаты.
Эта проблема может возникать по нескольким причинам:
Недостаток контекста: У моделей ИИ может быть недостаточно контекста для генерации точных ответов, особенно при работе со сложными или нюансированными запросами.
Проблемы с обучающими данными: Данные, используемые для обучения моделей ИИ, могут содержать ошибки, предвзятости или устаревшую информацию, которую модели могут непреднамеренно воспроизводить.
Чрезмерное обобщение: Модели ИИ могут чрезмерно обобщать на основе своих обучающих данных, что приводит к неверным экстраполяциям при столкновении с новыми входными данными.
Ограничения дизайна: Некоторые архитектуры ИИ не предназначены для проверки правдивости своих результатов, вместо этого фокусируясь на генерации статистически вероятных ответов на основе обучающих данных.
Christy привела отличный пример этого на Unstructured Data Meetup. Она попросила систему ИИ "Gemini" перечислить трех политиков, родившихся в New York, и та включила Hillary Clinton, что неверно, потому что она родилась в Chicago.
Этот пример демонстрирует, как ИИ может ошибаться даже в простых и прямолинейных вопросах.
Как отметила Christy: “Обратите внимание, что LLM могут обучаться на нетрадиционных источниках, таких как Reddit, что может приводить к необычным результатам.”
Как RAG уменьшает галлюцинации
Retrieval Augmented Generation (RAG) — это продвинутый подход в обработке естественного языка, направленный на повышение точности и надежности моделей ИИ, особенно в снижении галлюцинаций.
Christy объяснила, что RAG — это новый метод интеграции ваших собственных данных в процесс генеративного ИИ. Вот как это работает простыми словами:
Вы начинаете с подачи своих данных в модель эмбеддингов. Эта модель превращает информацию в набор чисел, называемых векторами, которые затем сохраняются в векторной базе данных.
Когда вы задаете вопрос, та же модель эмбеддингов также преобразует ваш запрос в вектор, а затем ищет ближайших векторных соседей в этой базе данных или векторном пространстве. Когда она находит наиболее близкое совпадение, она использует его как контекст вместе с вашим вопросом, чтобы сформировать запрос к большой языковой модели. Таким образом, вы получаете ответ, который с большей вероятностью будет точным.
Теперь вот как RAG справляется с галлюцинациями ИИ:
1. Актуальность: модели RAG могут включать самые новые данные, гарантируя, что их ответы основаны на самой свежей информации.
2. Точность и детализация: эти модели предназначены для предоставления точных ответов за счет извлечения конкретной, релевантной информации. Этот процесс снижает вероятность генерации ложного или сфабрикованного контента и гарантирует, что ответы будут подробными и точно адаптированными к вопросу, избегая чрезмерно общих утверждений.
Проблемы построения системы RAG
Создание системы Retrieval Augmented Generation (RAG) включает несколько сложных этапов и решений. Вот некоторые ключевые проблемы:
Выбор модели эмбеддингов
При выборе модели эмбеддингов можно сосредоточиться на нескольких ключевых факторах:
Размерность векторов: выбирайте модели, которые создают векторы такого размера, с которым удобно работать.
Производительность извлечения: оцените, насколько хорошо работают известные модели от таких компаний, как Cohere и Voyager.
Размер модели: учитывайте размер модели, чтобы убедиться, что она соответствует вашим вычислительным возможностям.
Точность: убедитесь, что модель способна улавливать тонкие детали, важные для вашей области или продукта.
Масштабируемость: убедитесь, что модель способна обрабатывать больше данных по мере роста ваших потребностей.
А что касается вариантов, вы можете выбрать из:
Модели с открытым исходным кодом: они доступны бесплатно, и их можно сравнивать и выбирать на таких платформах, как Hugging Face embedding model hub.
Проприетарные модели: такие компании, как Cohere или OpenAI, предлагают модели, которые могут иметь уникальные функции или лучшую производительность для конкретных задач, но предоставляются за плату.
Выбор индекса
Выбор подходящей структуры индекса критически важен для производительности системы. Это включает учет следующих факторов:
Масштабируемость: индекс должен масштабироваться до миллионов или миллиардов документов, не становясь при этом неприемлемо медленным.
Объем памяти: эффективное использование памяти важно, особенно при работе с большими наборами данных.
Скорость извлечения vs. точность: часто существует компромисс между тем, насколько быстро можно извлекать документы, и тем, насколько точно они соответствуют запросу.
Чанкинг
Чанкинг предполагает разбиение документов на более мелкие, семантически связные части, чтобы обеспечить более точное извлечение.
Определение размера чанка: слишком большой — и чанки могут быть менее сфокусированными; слишком маленький — и важный контекст может быть потерян.
Сохранение связности: обеспечение того, чтобы каждый чанк оставался осмысленным и связным сам по себе.
Обработка перекрытий: решение о том, как управлять информацией, которая может подходить для нескольких чанков.
Ключевые слова или семантический поиск
Выбор между поиском по ключевым словам и семантическим поиском может повлиять на способность системы понимать запросы и отвечать на них.
Хотя поиск по ключевым словам может казаться простым и быстрым, пропуск документов, которые не содержат точных ключевых слов, даже если они семантически релевантны, может сильно снизить нашу точность. Напротив, семантический поиск обеспечивает более глубокое понимание намерения запроса, но требует больше вычислительных ресурсов и более сложных моделей.
Реранкеры
Реранкеры — это дополнительные модели или алгоритмы, которые уточняют первоначальные результаты извлечения, стремясь повысить релевантность и точность документов, выбранных для генерации итогового ответа. Возникает вопрос: стоит ли их использовать и что нужно для их успешной интеграции?
Интеграция: реранкеры должны быть бесшовно интегрированы в систему без внесения значительной задержки.
Обучающие данные: как и другим моделям, реранкерам нужны качественные, репрезентативные обучающие данные, чтобы быть эффективными.
Настройка: найти правильный баланс между первоначальным поиском и этапом реранжирования может быть непросто.
RAG мертв?
Один вопрос из выступления Christy, который в последнее время не дает мне покоя, — остается ли RAG все еще главным героем, теперь когда LLM с длинным контекстом активно улучшают свои возможности.
Недавние достижения в области LLM с длинным контекстом вызвали вопросы о будущем техник Retrieval-Augmented Generation (RAG). С такими моделями, как Claude или Gemini 1.5 Pro, которые могут обрабатывать до 10 миллионов токенов, некоторые утверждают, что динамический поисковый подход RAG больше не нужен.
Противостояние: могут ли длинные контексты отказаться от RAG?
Это вопрос, который сейчас у всех на устах. Давайте разберем его.
Стоимость и эффективность:
Экономная природа RAG, который берет только то, что ему нужно, снижает вычислительные затраты. Но по мере снижения цен на AI-технологии LLM с длинным контекстом становятся более доступными. Здесь исход почти равный.
Динамика поиска и рассуждения:
LLM с длинным контекстом объединяют свои рассуждения с поиском информации, создавая более персонализированный характер ответов. Предварительный сбор информации в RAG на этом фоне может казаться немного роботизированным.
Масштабируемость и сложность данных:
Способность RAG работать с триллионами токенов — его козырь, что делает его лидером для обработки массивных, постоянно меняющихся наборов данных. LLM с длинным контекстом здесь остаются далеко позади.
Сотрудничество вместо конкуренции:
Почему бы не использовать оба подхода? Сочетание точности RAG с адаптивностью моделей с длинным контекстом может привести к мощной синергии.
OpenAI RAG против вашего кастомизированного RAG
Итак, вы увидели, что такое RAG и какие проблемы он создает. Теперь пора погрузиться в технические аспекты построения RAG. В частности, мы обсудим OpenAI's RAG и сравним его с созданием кастомизированного RAG с использованием векторных баз данных, таких как Milvus.
Отличный вопрос, заданный одним из участников аудитории, был: «Каковы причины делать кастомный RAG вместо Open AI RAG»
Как отметила Christy, самое важное: «Так вы можете получить больше понимания системы RAG, которого у вас нет при использовании Open AI; как разработчик, вы знаете, что именно настраивать»
Роль OpenAI Assistant API в построении RAG
OpenAI Assistant API — это мощный инструмент, который позволяет создавать AI-ассистентов внутри ваших собственных приложений. Assistant имеет инструкции и может использовать модели, инструменты и файлы для ответа на запросы пользователей. Этот API отлично подходит для приложений, которым нужны увлекательные, долгосрочные беседы, например для клиентской поддержки или виртуальных персональных ассистентов.
Сравнение OpenAI RAG и кастомизированного RAG
Christy продемонстрировала два подхода к построению RAG: один с использованием OpenAI API, а другой — путем кастомизации с помощью векторной базы данных под названием Milvus. Это сравнение поможет нам понять различия и преимущества каждого подхода..
Вот ключевые различия между OpenAI RAG и кастомизированным RAG.
| Критерии | OpenAI RAG | Настраиваемый RAG |
| Пригодность для применения | Хорошо подходит для поддержки клиентов, виртуальных персональных ассистентов и долгосрочных бесед | Отлично подходит для помощи в академических исследованиях, сложных запросов и данных, основанных на фактах |
| Производительность и масштабируемость | Быстрое время ответа и высокая эффективность | Может иметь более медленное время ответа из-за извлечения данных из базы данных |
| Сложность внедрения | Легко настроить и использовать | Требует экспертизы в интеграции AI-моделей и управлении базами данных |
| Соображения по стоимости | Ценообразование на основе использования | Затраты включают вычислительные ресурсы и обслуживание базы данных |
Настраиваемый подход RAG с использованием векторных баз данных, таких как Milvus, предлагает больше гибкости и контроля, но требует больше экспертизы и ресурсов
Хотите увидеть код в действии? Посмотрите этот notebook с практическим примером!
Методы оценки RAG
Чтобы оценить RAG-пайплайн, нужно рассмотреть обе части по отдельности и вместе. Также нужно проверить, улучшается ли производительность. Для этого нужны две вещи: метрика оценки и набор данных.
Поскольку Кристи затронула эту часть в своем выступлении, главный акцент, который она упомянула, был: «Основан ли ваш ответ на источниках и добросовестно ли он отвечает на вопрос»
Один из инструментов, упомянутых Кристи, — Truera, платформа, которая помогает оценивать и оптимизировать приложения на основе больших языковых моделей (LLM).
С Truera вы можете:
Оценивать свои LLM-приложения
Оптимизировать выбор LLM-приложений с помощью функций обратной связи и отслеживания приложений
Минимизировать галлюцинации, используя такие функции, как RAG triad, и другие готовые функции обратной связи
Мониторить и отслеживать производственные LLM-приложения в масштабе, создавая адаптивные панели мониторинга и настраивая действенные оповещения
Кристи также говорила о RAGAs, это фреймворк, специально созданный для оценки RAG-пайплайнов. Он предлагает все технические средства, необходимые для оценки каждого компонента пайплайна по отдельности.
RAGAs требуется следующая информация:
· Вопрос: запрос пользователя
· Ответ: сгенерированный ответ
· Контексты: информация, извлеченная из внешнего источника знаний
· Эталонные ответы: правильный ответ на вопрос (нужен только для одной метрики)
RAGAs предоставляет несколько метрик для оценки пайплайна, включая:
· Точность контекста: насколько релевантна извлеченная информация
· Полнота контекста: была ли извлечена вся релевантная информация
· Достоверность: насколько точен сгенерированный ответ
· Релевантность ответа: насколько сгенерированный ответ релевантен вопросу
Оценка LLM с использованием других LLM в качестве судьи
Оценка больших языковых моделей (LLM) может быть сложной задачей. Одно из решений — позволить LLM оценивать друг друга. Этот процесс включает генерацию тестовых случаев и измерение производительности модели.
Вот как это работает:
Автоматическая генерация тестов: LLM создает набор тестовых случаев, включая разные входные данные, контексты и уровни сложности.
Метрики оценки: Оцениваемая LLM решает тестовые задачи, а её производительность измеряется с помощью таких метрик, как точность, беглость и связность.
Сравнение и ранжирование: Результаты сравниваются с базовой моделью или другими LLM, показывая сильные и слабые стороны каждой модели.
Интересный момент, упомянутый Кристи, который действительно интригует, — это «GPT ставит себя выше в рейтинге, когда сама выступает судьёй», что показывает ещё один аспект, который мы должны учитывать при оценке LLM, чтобы обеспечить точность.
возможно, вам стоит ознакомиться с этой статьёй, чтобы глубже погрузиться в тему.
Заключение
И на этом всё! Мы рассмотрели галлюцинации ИИ и то, как RAG может помочь решить эту проблему. Кристи отлично объяснила, что создание RAG требует тщательного выбора моделей эмбеддингов, индексов и подходов к семантическому поиску. Решая проблему галлюцинаций ИИ и используя динамическое извлечение актуальной информации, RAG предлагает мощный инструмент для создания более надёжных и контекстно-осведомлённых систем ИИ.
Путь создания системы RAG включает продуманные решения о моделях эмбеддингов, индексировании и обработке огромных наборов данных. Хотя это и сложно, выгоды с точки зрения производительности и точности весьма существенны.
Независимо от того, интересуют ли вас технические нюансы или вдохновляют практические применения, сейчас идеальное время, чтобы погрузиться в RAG. Экспериментируйте с векторными базами данных, такими как Milvus, интегрируйте их с продвинутыми методами поиска и убедитесь на собственном опыте, как RAG может преобразить извлечение данных и взаимодействие с ИИ.
Читать далее
Introducing Zilliz Cloud Global Cluster: Region-Level Resilience for Mission-Critical AI
Zilliz Cloud Global Cluster delivers multi-region resilience, automatic failover, and fast global AI search with built-in security and compliance.
Zilliz Cloud Now Available in Azure North Europe: Bringing AI-Powered Vector Search Closer to European Customers
The addition of the Azure North Europe (Ireland) region further expands our global footprint to better serve our European customers.
Milvus/Zilliz + Surveillance: How Vector Databases Transform Multi-Camera Tracking
See how Milvus vector database enhances multi-camera tracking with similarity-based matching for better surveillance in retail, warehouses and transport hubs.