Transcription
Привет! В этом видео я расскажу о Retrieval-Augmented Generation (RAG) – методе сочетания поиска информации (Retrieval) и генерации текста (Generation) для улучшения работы ИИ. Мы рассмотрим следующие темы: Что такое RAG? Почему RAG важен? Как работает RAG? Компоненты RAG, Приложения RAG, Преимущества и ограничения, и, наконец, простую демонстрацию.
Прежде всего, что такое RAG? RAG – это гибридная модель ИИ, сочетающая методы поиска, извлечения релевантной информации из вашего источника знаний, и методы генерации, создающие новый текст. В основе лежат две вещи. Во-первых, традиционный поиск, например, поиск текста в вашей базе данных или PDF-файле, верно? Таким образом, у нас будет некая база знаний. Из неё мы можем осуществлять поиск для получения необходимой информации. Это извлечение релевантной информации из источника знаний – поиск (Retrieval). Другое – генерация (Generation). Генерация – очень важная вещь в наши дни. Вы, возможно, слышали о генеративном ИИ, верно? Чат-боты, такие как ChatGPT и Gemini, способны генерировать новый контент. Они могут создавать новые статьи, новые посты в блогах и даже новые изображения. В этом случае это будет называться мультимодальным. Внутренне он использует большую языковую модель, такую как GPT-4 в случае ChatGPT. Он использует модель GPT-4. Эти большие языковые модели (LLM) мощны в генерации, но имеют некоторые ограничения. В случае RAG, комбинируется мощь поиска и генерации. Это ключевая идея RAG – сочетание мощи поиска и генерации. Ключевая идея заключается в том, что он улучшает языковые модели, обосновывая их ответы на внешних знаниях. Это как бы направляет большие языковые модели с помощью внешних знаний.
Итак, почему RAG важен? Традиционные модели ИИ имеют несколько недостатков. Один из них – ограничение по времени знаний (Limited Knowledge Cutoff). Другой – галлюцинации (Hallucinations). Ограничение по времени знаний. Как я уже сказал, ChatGPT внутренне использует модель GPT-4. Эта модель GPT-4 – предобученная модель. Это значит, что она была обучена на большом объеме данных. В случае этих больших языковых моделей они обучаются на огромном количестве данных. С помощью больших вычислительных мощностей они были обучены. В этом случае должна быть некая дата отсечения. Например, если они обучали её два месяца назад, то у неё будут данные только до этого периода. Итак, у неё не будет последней информации. Это одна из ключевых проблем больших языковых моделей. А другая – галлюцинации. Галлюцинации – это как бы неотъемлемая черта больших языковых моделей. Они склонны генерировать неверную или бессмысленную информацию. Если вы часто используете ChatGPT, вы должны знать об этом. Иногда он даёт очень нерелевантные ответы даже на простые вопросы. Это из-за галлюцинаций. Помимо этого, много вещей происходит из-за, например, неверной информации в обучающих данных, что может вызывать галлюцинации. Итак, есть две проблемы: ограничение по времени знаний – отсутствует последняя информация, и галлюцинации. Обе вещи важны, потому что для использования любых больших языковых моделей важно иметь последнюю информацию. И аналогично, если эта информация ненадежна, то вся система столкнется с проблемой. Проблемы очень важны. Поэтому нам нужно найти лучшее решение. Именно здесь RAG играет важную роль. RAG помогает получать доступ к актуальной информации и пытается избежать галлюцинаций.
Как работает RAG пошагово? Ввод запроса. Пользователь сначала задаёт вопрос, верно? Затем – поиск (Retrieval). Модель извлекает релевантные документы из источника знаний. Затем – генерация (Generation). Модель генерирует ответ на основе полученной информации. Для пользовательского запроса сначала система поиска извлекает релевантные документы из источника знаний или внешних знаний. Затем, получив контекстную информацию, она отправляет эту контекстную информацию вместе с входным запросом в большую языковую модель для получения результата. Вот общий рабочий процесс RAG. Сначала есть две вещи. Одна – одноразовая задача, другая – регулярное использование. Одноразовая задача – это загрузка документов, верно? Предположим, вы управляете организацией, в вашем отделе может быть, предположим, пять отделов. Каждый отдел имеет свою политику и некоторые детали об отделе, верно? Предположим, кто-то задаёт вопросы о вашей компании, он не может напрямую спросить большую языковую модель, у большой языковой модели не будет этих данных, верно? У вас будут эти данные. Но мы не можем отправлять все данные в большие языковые модели. Предположим, в этом примере, если каждый отдел имеет один PDF-файл, мы не можем отправлять пять PDF-файлов вместе с пользовательским запросом в большую языковую модель. Из-за ограничения контекстного окна. Каждая большая языковая модель имеет определённый предел контекстного окна. Мы не можем отправлять огромный объём данных. Есть ограничение. В этом случае мы должны отправлять только релевантный документ вместе с пользовательским запросом. Для этого, прежде всего, мы должны хранить все документы в векторной базе данных. Есть разные подходы. Я говорю только об общем подходе. Итак, прежде всего, мы должны хранить документы в векторной базе данных. Векторная база данных – поиск в ней будет происходить очень быстро, потому что данные хранятся в числовом формате. Она преобразует текстовый контент или контент изображения в эквивалентное число. Она хранит только числа и соответствующий связанный текст, но поиск будет происходить на основе чисел. В основном, это будет очень быстро. И это будет эффективно, эффективно в том смысле, который я объясню. Итак, прежде всего, это очень быстро. Для этого нам нужно преобразовать документы в эмбеддинги, эмбеддинги, как я уже говорил, это численное представление этого контента, для этого нам нужно использовать некоторую большую языковую модель для эмбеддингов. Эта большая языковая модель будет другой. Они будут предоставлять услуги по созданию эмбеддингов. Нам нужно использовать эти услуги по созданию эмбеддингов и затем преобразовать документы в эквивалентные эмбеддинги и сохранить их в векторной базе данных. Существуют различные векторные базы данных, такие как ChromaDB, FAISS от Facebook и управляемая векторная база данных Pinecone. В случае ChromaDB мы можем использовать локально, он с открытым исходным кодом. Есть различные векторные базы данных, в которых можно хранить данные в векторной базе данных. Это одноразовый процесс. Один раз перед началом использования нашей системы, нам нужно, в качестве предварительного шага, настроить это. Как я уже сказал, эта векторная база данных, поиск в ней будет быстрее, и ещё одно преимущество – это семантический поиск. Не только поиск по ключевым словам, он будет поддерживать и семантический поиск. Эффективность этого семантического поиска будет зависеть от того, какую большую языковую модель мы используем для создания эмбеддингов. Это совершенно другая тема. В случае RAG общая структура очень проста. Большая языковая модель имеет некоторые недостатки, мы собираемся решить эти проблемы с помощью внешних данных. Для этого мы используем RAG. Мы просто дополняем процесс генерации этапом поиска. Это очень важно. Это RAG. Это очень просто. Но в случае реализации и других вещей, в зависимости от требований и использования, есть много разных вещей. Но цель этого видео – дать основы. Я обращаюсь к новичкам в этом видео. Поэтому я делаю всё очень просто.
Итак, документы преобразуются в эмбеддинги и сохраняются в векторной базе данных. Это одноразовый шаг. Затем переходим к фактическому ежедневному процессу. Пользователь задаёт вопрос. Этот вопрос, этот запрос также преобразуется в эмбеддинг. Это называется эмбеддингом запроса. Вектор запроса. Этот вектор запроса будет использован для поиска релевантной записи в векторной базе данных. Например, в нашем примере мы сказали пять отделов, верно? Если пользователь задаёт вопрос, связанный с одним конкретным отделом, например, он спрашивает о втором отделе, этот запрос будет преобразован в эмбеддинги. Этот эмбеддинг запроса будет искать в этой векторной базе данных эмбеддингов документов. Это будет как поиск данных, относящихся ко второму отделу. Это природа этого векторного поиска. Здесь он будет быстрым, а также будет проводить семантический поиск. Это ключ здесь. После получения релевантной информации, это называется фрагментами контекста, это будет как с дополнением, это будет добавлено вместе с запросом, а затем отправлено в большую языковую модель для получения ответа. Теперь это будет что-то вроде релевантного ответа. Общий процесс: одноразовые процессы хранения документов, внешних данных в виде эмбеддингов с помощью большой языковой модели эмбеддингов. А затем фактический процесс: преобразование пользовательского запроса в эмбеддинг, затем векторный поиск. Есть разные вещи, косинусное сходство, такие подходы есть. На основе этого мы должны найти релевантные фрагменты и дополнить запрос этими фрагментами контекста. Запрос будет таким: мы должны предоставить запрос и фрагменты, а затем предоставить дополнительную внешнюю информацию, например: «используйте контекстную информацию, чтобы дать ответ на этот запрос». Таким образом, мы должны предоставить некоторый системный запрос. Наконец, мы получим релевантный ответ. Это основная концепция RAG. Если вы не используете RAG, то можете получить нерелевантный ответ. Этот процесс – это обоснование большой языковой модели, это одно. И как я уже говорил ранее, это будет полезно для получения последней информации. Большая языковая модель может не иметь последней информации, но фрагмент контекста будет иметь последнюю информацию. Он будет использовать эту информацию. Компоненты RAG: поиск (Retriever), генерация (Generator), источник знаний (Knowledge Source). Поиск (Retriever) ищет в большой базе знаний релевантную информацию. Есть различные системы поиска, затем генератор (Generator), это модели GPT, это обычная большая языковая модель и источник знаний (Knowledge Source). Для того чтобы поиск (Retriever) получал данные, нам нужно иметь эти данные, верно? Для этих данных, в случае нашего примера, векторная база данных, нам нужно хранить данные, верно? Для этого нам нужно использовать какой-то источник знаний. Как я уже говорил ранее, это могут быть любые документы в простых случаях, или это может быть любой веб-сканер, извлекающий последнюю информацию из различных веб-источников. Или любая база данных. Приложения RAG. Много приложений есть. Одно очевидное – это ответы на вопросы для получения точных ответов на пользовательские запросы, а чат-боты более информированы и контекст наших разговоров, потому что мы сможем отправлять контекстную информацию, верно, чтобы она работала правильно на основе контекстной информации и создания контента, генерации статей, резюме или отчётов. Нам нужно предоставить внешние данные, чтобы большая языковая модель могла создавать контент с большей информацией. Поддержка клиентов. Очевидно, когда пользователь задаёт какие-либо вопросы, клиент задаёт вопросы, эта система сможет дать правильный ответ с помощью этих внешних знаний. Например, если больница использует систему поддержки клиентов, пользователь сможет задавать любые вопросы этой системе на естественном языке, и эта система RAG сможет искать контент, получать релевантный контент из источника знаний и затем отвечать на вопрос. В основном, я могу сказать двумя способами. Один – это как система поиска раньше, в случае этой системы поддержки клиентов больницы, раньше, если кто-то задавал какой-либо вопрос, представитель в больнице должен был просматривать некоторые PDF-файлы или базу данных. Ему нужно было выполнить поиск по ключевым словам и затем дать ответ, верно? Это традиционный способ. В этом случае он сможет получить ответ только тогда, когда ключевые слова совпадают. Это ограничение. Он не может использовать естественный язык. Он не может использовать повседневные простые языки. Ему нужно правильно использовать ключевые слова. В случае больших языковых моделей мы можем использовать естественный язык, но проблема в том, что у него не будет данных, верно? Чтобы получить выгоду от обоих вещей, мы можем, это называется RAG. Мы дополняем процесс генерации с помощью извлечения этого контента. Дополнение генерации с помощью поиска, поиск дополненная генерация.
Преимущества и ограничения. Преимущества очевидны: мы можем получать последнюю информацию в режиме реального времени или обновлённую информацию, уменьшает галлюцинации. Он сочетает в себе лучшие качества поиска и генерации. Это очевидные преимущества RAG. Ограничения. Опять же, это зависит от качества источника знаний. Даже если вы можете использовать внешний источник знаний, если качество не хорошее, то проблемы будут продолжаться. Поэтому это зависит от качества источника знаний. Вычислительно дорогостояще преобразовывать документы в векторную базу данных, это потребует значительных вычислительных мощностей. И если вы используете API, то использование API будет несколько дорогостоящим. Не на уровне генеративного, но всё же за это нужно платить. Итак, вычислительно дорогостояще. По сравнению с другими подходами, маловыборочное обучение и другие вещи, требование к набору данных для обучения здесь сравнительно высокое. Нам нужно иметь значительное количество данных во внешнем источнике. Позвольте мне показать вам простую демонстрацию. Обычно есть два подхода. Один – это использование моделей с открытым исходным кодом. У нас много всего есть. Вы можете искать в Hugging Face или Kaggle, мы можем получить много моделей эмбеддингов. Но исходя из моего опыта, если мы используем модели эмбеддингов, предоставляемые крупными организациями, такими как OpenAI, то производительность будет хорошей, а в целом будет лучше. Но за них нужно платить. Это одна вещь. В этом примере я покажу простой пример с использованием Hugging Face. Но в реальном использовании я в основном использовал API OpenAI. Здесь код, прежде всего, мы импортируем необходимые библиотеки. Этот код мы используем Langchain. Langchain – это фреймворк или библиотека для разработки. Это будет легко обрабатывать различные модели и различные типы векторных баз данных и тому подобное. Код будет простым. Но обслуживание, исходя из моего опыта, обслуживание постоянно, они постоянно меняют свои библиотеки и всё такое. Но очевидная причина в том, что ИИ развивается очень быстро, чтобы успевать за этим, они постоянно обновляют свои библиотеки. Более того, если вы пишете код индивидуально, то понимание концепции будет лёгким. Но в случае Langchain, если вы разрабатываете, если вы хотите сэкономить много времени, то вы можете использовать Langchain. Но для обучения я бы рекомендовал делать всё по отдельности. Без использования каких-либо фреймворков или библиотек. Но для новичка, чтобы дать общий обзор, я использую Langchain. Чтобы вы могли легко понять весь поток, не отвлекаясь на каждый отдельный код. Итак, здесь в целом, мы сначала импортируем все необходимые библиотеки. Итак, шаги: сначала мы должны, как я объяснил на диаграмме, есть две вещи. Один – одноразовый шаг, а другое – фактический поток, как поиск и дополнение запросов, а затем генерация, верно? Эти три шага. Всего один шаг – первый шаг – это одноразовый шаг, затем снова три шага для каждого запроса, поэтому первое – мы готовим документы. Здесь всё очень просто. Для объяснения. В противном случае я предполагаю, что каждый документ имеет длину в две-три страницы. Итак, здесь витамин С помогает укрепить иммунитет, упражнения улучшают психическое и физическое здоровье, достаточное количество воды поддерживает вас в гидратации и улучшает концентрацию. Это документ. И разбиение на части – важная концепция в RAG. Нам нужно разбить на части, то есть разделить документ на разные разделы, чтобы он мог поместиться в контекстное окно большой языковой модели. Для этого нужно также обеспечить перекрытие. Я не хочу давать все детали здесь, чтобы мы могли сосредоточиться на обзоре. В основном, мы готовим документы и разбиваем их на части. Затем создаём эмбеддинги и сохраняем их в FAISS. Векторная база данных. Для создания эмбеддингов нам нужно использовать модель эмбеддингов, мы используем эмбеддинги Hugging Face. Для использования Hugging Face нам нужно использовать API Hugging Face. Итак, я уже загрузил, то есть экспортировал API Hugging Face в среде. Если вы собираетесь использовать этот код в своей среде, убедитесь, что вы загрузили ключ Hugging Face. Вам нужно получить эти данные из токенов доступа отсюда, Hugging Face. Затем вам нужно загрузить его в среду. Затем вы можете использовать этот код. Итак, сначала мы готовим документы, разбиваем их на части. То есть делим их, а затем преобразуем каждый фрагмент в эмбеддинг и затем сохраняем эмбеддинги в векторной базе данных. Это один шаг, как для одноразовой настройки. А затем фактический чат, для этого мы используем эту большую языковую модель. И как мы дополняем запрос, предоставляя этот запрос, готовя этот запрос. Используя этот шаблон запроса, мы используем, в основном, мы спрашиваем, в основном, мы спрашиваем большую языковую модель использовать этот контекст для ответа на этот вопрос. И он должен дать ответ в этом формате. Это контекст. Это вопрос. Вы должны дать ответ так, так мы спрашиваем. Это очень важно, потому что в противном случае он будет давать ответ в другом формате. Но для примера он не дал этот формат в первый раз. Поэтому он повёл себя по-другому. Для простоты примера я просто пришёл к этому шаблону. Итак, теперь мы создаём цепочку RAG. И здесь это запрос, пользовательский запрос. Как упражнения влияют на здоровье? Итак, после запуска этой цепочки он должен дать ответ. Мы печатаем ответ. Итак, здесь три вещи есть, верно? Давайте посмотрим, что происходит. Я запускаю этот скрипт. После запуска он дал ответ, верно. Упражнения улучшают как психическое, так и физическое здоровье. Для этого вопроса он дал правильный ответ. И помимо ответа он также дал объяснение.