Привет, Хаброжители!

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

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

И в книге «Разработка приложений на базе GPT-4 и ChatGPT. 2-е изд.» содержится подробное руководство для разработчиков на Python, желающих научиться создавать приложения с использованием больших языковых моделей.

Книга начинается с обсуждения основных возможностей и преимуществ моделей GPT-4 и GPT-3.5. Авторы объясняют принципы работы этих моделей, что позволит читателям лучше понять их потенциал в контексте разработки. GPT-4 и GPT-3.5 известны своими выдающимися способностями в области обработки естественного языка, что открывает новые горизонты для создания интерактивных приложений, включая интеллектуальных ассистентов и генераторов текста.

Читатели найдут в книге детальное руководство по разработке приложений с использованием библиотеки OpenAI для Python. Упор делается на практические аспекты, включая генерацию текста, отправку вопросов и получение ответов, что делает процесс разработки доступным даже для начинающих программистов. Все примеры кода размещены в репозитории GitHub, что облегчает их воспроизведение и адаптацию к собственным проектам.

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

Текст написан понятным и лаконичным языком, что делает «Разработку приложений на базе GPT-4 и ChatGPT» доступной для широкой аудитории. Тем не менее, желательно, чтобы читатели обладали базовыми знаниями Python. Структура издания включает множество примеров, которые помогают усвоить ключевые концепции и применить их в реальных условиях. В конце книги представляется глоссарий ключевых терминов, что дополнительно облегчает восприятие материала.

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

Отличия от первого издания

• Авторы рассматривают, как изменения технологии искусственного интеллекта повлияли на разработку приложений.
• Оливье Келен и Мари-Алис Блете делятся своим опытом и знаниями о таких моделях, как GPT-4 и GPT-3.5, предоставляя читателям пошаговые инструкции, теоретические основы и практические примеры.
• Учтены обновления API OpenAI, включая возможности компьютерного зрения в GPT-4.

TL;DR

«Разработка приложений с GPT-4 и ChatGPT» является обязательным чтением для всех, кто заинтересован в использовании больших языковых моделей в своих проектах. Это идеальный старт для разработки современных приложений, способных изменить способ взаимодействия с машинами.

После прочтения книги вы узнаете:

• Основы и преимущества моделей GPT-4 и GPT-3.5, включая основные функции и принципы их работы.
• Как интегрировать эти модели в приложения на базе Python, используя возможности обработки естественного языка и преодолевая специфические проблемы, связанные с LLM.
• Примеры приложений, демонстрирующих API OpenAI на Python для таких задач, как генерация текста, ответы на вопросы, резюмирование контента, классификация и многое другое.
• Расширенные темы LLM, такие как проектирование подсказок (prompt engineering), тонкая настройка моделей для конкретных задач, RAG, плагины, LangChain, LlamaIndex, GPT и интеллектуальные ассистенты.

Если вы готовы внедрить передовые технологии AI в свою практику, эта книга станет вашим надежным спутником на этом пути.

Предлагаем ознакомиться с отрывком «RAG»

В предыдущих главах мы представили концепцию генерации с использованием расширенного поиска (RAG) и привели простой пример. Цель этого раздела — углубиться в принципы реализации RAG.

Первое ограничение моделей GPT, которое приходит на ум, — это отсутствие актуальных знаний.

• Актуальные данные. Модель GPT не может обладать информацией о событиях, произошедших после ее обучения.
• Собственные данные. Модель GPT не может отвечать на вопросы о персональных данных, к которым она не имела доступа во время обучения.
• Данные, специфичные для конкретного домена или «ниши». Возможно, модель имела доступ к этим данным, но недостаточно для того, чтобы действительно их усвоить.

В предыдущем разделе вы увидели, что тонкая настройка — это интересный вариант для адаптации LLM под ваши нужды. Однако исследования (https://oreil.ly/gO08M) показали, что по сравнению с тонкой настройкой RAG является более надежным решением. Подробнее о том, как сделать выбор, вы узнаете в разделе «Выбор между стратегиями».

Теперь рассмотрим различные стратегии реализации RAG.

Простая реализация RAG

Простой RAG — это отправная точка, самая простая реализация RAG из возможных.

Принцип работы следующий:

1. На основе базы знаний вычисляются вложения, которые сохраняются для последующего использования (в базе данных, в памяти, сериализованными на диск и т. д.).
2. Для каждого запроса от пользователя вычисляется вложение.
3. Это вложение используется для векторного поиска по ранее вычисленным вложениям. В результате получаются выдержки из документов.
4. Наконец, мы вызываем модель GPT с запросом вроде: Учитывая ФАКТЫ, ответь на ВОПРОС. ФАКТЫ:… ВОПРОС: ....

Продвинутая реализация RAG

Успешная работа простого RAG во многом зависит от двух условий: вопрос пользователя должен быть четко сформулирован, а данные — хорошо структурированы и качественны. Это при условии, что данные действительно содержат ответ на вопрос.

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

Некоторые фреймворки, такие как LlamaIndex и LangChain, предлагают решения, облегчающие продвинутую реализацию RAG. Примеры вы найдете в главе 5.

Предварительная обработка запроса пользователя

Это то, что мы делали в нашем примере проекта из предыдущего раздела: извлекали ключевые слова. В зависимости от проекта можно также переформулировать запрос с помощью модели GPT, чтобы убедиться, что опечатки или некорректная формулировка не повлияют на результаты. Переформулировка может также учитывать историю разговора, например, когда пользователь ссылается на предыдущую концепцию: вопрос «Как это работает?» должен быть переформулирован в «Как работает меч Линка?» Другие преобразования выполняются последовательно, в зависимости от конкретного случая использования: убедитесь, что в тексте нет аббревиатур, которые могут привести к сбою семантического поиска, используйте специфичные для предметной области термины и т. д.

Как показано на рис. 4.11, вы также можете применять модель OpenAI для создания списка запросов, чтобы расширить поиск и увеличить шансы на получение нужных данных:

• генерируйте похожие запросы;
• разложите пользовательский ввод на несколько запросов;
• создавайте более широкие запросы, чтобы результаты поиска включали больше контекста.

Цель — улучшить запрос, который будет использоваться для семантического поиска. Вы можете попробовать несколько методик и посмотреть, что лучше всего подходит для вашего решения и как это соотносится с вашими затратами.

Предварительная обработка базы знаний

Первый аспект, на который можно обратить внимание, — это разбиение данных на фрагменты. В примере проекта 3 главы 3 мы разделили входной документ на фрагменты фиксированной длины, что является простейшим решением. Чтобы улучшить результаты поиска, мы можем разбить документ таким образом, чтобы фрагменты имели собственное значение, например на абзацы или предложения. Также необходимо найти компромисс с размером фрагментов. Каждый фрагмент должен быть достаточно мал, чтобы поиск был эффективным (векторы имеют фиксированную длину независимо от размера фрагмента, поэтому вектор, созданный из нескольких слов или предложений, будет более точным, чем вектор, охватывающий несколько страниц текста). Однако фрагмент также должен быть довольно большим, чтобы LLM имела достаточно контекста для его обработки. Для решения этой проблемы используется следующий подход (рис. 4.12): поиск осуществляется по небольшим фрагментам, но результаты, отправляемые в LLM, расширяются несколькими предложениями или фрагментами до и после найденного результата.

Далее мы рассмотрим структуру документов и метаданные. При разделении документов на абзацы могут быть удалены заголовки разделов или глав, что может привести к неудачному поиску. Решением может стать добавление метаданных к фрагментам — либо выполнение другого поиска по метаданным, либо векторизация комбинации метаданных и самого фрагмента. Бывает, что документы содержат изображения, диаграммы или таблицы, которые, в свою очередь, также могут нуждаться в обработке для получения лучших результатов поиска.

Следующая идея для улучшения результатов поиска — повысить семантическое соответствие запросам пользователя, превращая их в гипотетические. Здесь снова поможет обращение к GPT-3.5 Turbo или GPT-4. Можно использовать запрос вроде «Сгенерируй вопрос, ответ на который содержится в этом абзаце», а сгенерированные вопросы уже применять для поиска. Обратный подход также возможен: метод HyDE (hypothetical document embeddings) заключается в генерации гипотетических документов на основе запроса пользователя и выполнении векторного поиска на базе этих документов.

За продвинутые методы RAG приходится платить: они в значительной степени зависят от количества обращений к API OpenAI, что повышает стоимость такой реализации. Возможно, будет полезно сделать шаг назад и проанализировать качество и структуру данных, прежде чем рассматривать RAG-решения.

Улучшение поиска

В проекте 3 из главы 3 используется поиск методом k-ближайших соседей (KNN) с метрикой косинусного сходства, предоставляемый Redis. Алгоритм KNN определяет k ближайших точек в наборе данных к заданной точке запроса на основе заданной метрики расстояния. При использовании косинусного сходства тождество между точками запроса и набора данных оценивается путем измерения косинуса угла между ними. Это решение считается стандартным для векторного поиска, однако существуют и другие алгоритмы, которые могут быть предпочтительнее, так как временная сложность алгоритма KNN для прогнозирования одной точки, когда обучающий набор данных содержит X наблюдений, линейно пропорциональна X, и, следовательно, алгоритм становится слишком медленным при увеличении числа наблюдений.

Другие алгоритмы поиска могут быть предоставлены как готовой векторной базой данных или используемым фреймворком RAG, так и вашей собственной реализацией. В зависимости от ваших данных и готовности идти на компромисс между производительностью и вычислительными затратами вам может подойти алгоритм поиска ближайших соседей (ANN). Принцип ANN заключается в том, что он эффективно определяет достаточно близкие точки данных с меньшей вычислительной сложностью, что делает его особенно подходящим для больших наборов данных, для которых точные расчеты расстояния требуют значительных вычислительных затрат.

Мы рекомендуем тщательно проанализировать требования к вычислительным ресурсам и задержкам и провести эксперименты на своих данных, чтобы найти оптимальный вариант, не забывая о том, что KNN с косинусным сходством доказал свою эффективность.

Есть и другое решение: можно использовать гибридный поиск (fusion retrieval), также называемый смешанным поиском. Идея заключается в том, чтобы объединить поиск по ключевым словам (стандартные алгоритмы для этого — TF-IDF и BM25) с поиском по вложениям и сгруппировать результаты с помощью алгоритма Reciprocal Rank Fusion (RRF) (рис. 4.13). Поиск по ключевым словам позволяет выявить наиболее релевантные фрагменты документов путем измерения частоты и значимости определенных терминов, которые в них встречаются. Мы будем использовать RRF для объединения результатов, найденных благодаря поиску по ключевым словам и вложениям. Это работает за счет агрегации рангов документов, полученных двумя различными стратегиями поиска, и приоритизации тех, у которых более высокие ранги в результатах поиска. Такой гибридный подход обеспечивает более полный опыт поиска, сочетая возможности точного сопоставления (как в методах поиска по ключевым словам) и контекстного понимания (как векторный поиск по вложениям) для повышения релевантности результатов поиска.

И LangChain, и LlamaIndex предлагают решения для легкой реализации этого подхода.

Постобработка

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

Успех продвинутой реализации RAG строится эмпирически, путем проб различных подходов, анализа результатов и повторения попыток. Ключевым моментом является эффективное измерение производительности проектирования RAG, чтобы этот итеративный подход действительно приводил к реальным улучшениям, а не просто полагался на «интуицию». Для этого можно настроить различные стратегии оценки, которые будут основываться как на самой производительности поиска, так и на способности LLM обрабатывать фрагменты документов и выдавать релевантные ответы. Вы можете найти примеры в инструментах LangChain и LlamaIndex, представленных в главе 5, или в других, таких как Ragas (https://oreil.ly/yOmH7), или же вы можете реализовать собственную систему.

Ограничения RAG

В некоторых случаях у вас может быть конфиденциальная информация, но RAG не подходит, в частности когда документы не содержат явных ответов на вопросы пользователей. Например:

• Какие ошибки содержатся в документе MyDocument.docx? На этот вопрос нельзя ответить с помощью семантического поиска, вместо этого требуется анализ документа.
• На скольких языках программирования доступен SDK? Ваша база знаний может содержать фразу вроде «OpenAI предоставляет SDK для Python и Java», однако вопрос требует более глубокого анализа, который LLM не факт, что выполнит, особенно если есть много других результатов поиска. Кроме того, в вашей документации может не быть такой фразы, а просто отдельные разделы для Python и Java. В этом случае семантический поиск не даст никаких результатов.

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

RAG — сложная тема: легко настроить простую реализацию, но продвинутые проекты RAG бывают чрезвычайно сложными, со множеством конвейеров, параллельной обработкой и неоднократными обращениями к API OpenAI. Мы могли бы пойти еще дальше, чем описано в этих параграфах, и ввести агентское поведение и возможности чата, сделав систему чрезвычайно мощной. Но иногда лучшим решением является работа над базой знаний для улучшения ее качества, а не разработка очень сложного в обслуживании и дорогостоящего решения.

Более подробно с книгой можно ознакомиться на сайте издательства:

» Оглавление
» Отрывок

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — GPT