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

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

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

Современное озеро данных: центр тяжести инфраструктуры искусственного интеллекта

Часто говорят, что в эпоху искусственного интеллекта данные — это ваш ров . С этой целью создание приложения RAG промышленного уровня требует подходящей инфраструктуры данных для хранения, версии, обработки, оценки и запроса фрагментов данных, составляющих ваш собственный корпус. Поскольку MinIO использует подход к искусственному интеллекту, ориентированный на данные, наша первоначальная рекомендация по инфраструктуре по умолчанию для проекта этого типа — настроить современное озеро данных и векторную базу данных. Хотя на этом пути может потребоваться подключение других вспомогательных инструментов, эти два элемента инфраструктуры являются основополагающими. Они будут служить центром тяжести почти для всех задач, которые впоследствии возникнут при запуске вашего приложения RAG в производство.

Современную эталонную архитектуру Data Lake, построенную на MinIO, можно найти. здесь . Сопутствующий документ, показывающий, как эта архитектура поддерживает все рабочие нагрузки AI/ML,: здесь .

RAG: этапы конвейера документирования

Оценка

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

• Эвристическая оценка на основе кода . Программная оценка результатов с использованием различных показателей, таких как количество выходных токенов, наличие/отсутствие ключевых слов, достоверность JSON и т. д. Их часто можно оценить детерминированно с использованием регулярных выражений и библиотек утверждений для обычного модульного тестирования.

  
  

• Алгоритмическая оценка на основе кода — оценка результатов с использованием различных известных показателей науки о данных. Например, переосмыслив подсказку как задачу ранжирования, вы можете использовать популярные функции оценки из рекомендательных систем, такие как нормализованный дисконтированный совокупный выигрыш (NDCG) или средний обратный ранг (MRR). И наоборот, если подсказку можно сформулировать как задачу классификации, тогда могут подойти точность, полнота и оценка F1. Наконец, вы можете использовать такие меры, как BLEU, ROUGE и семантическое сходство ответов (SAS), чтобы сравнить семантический вывод с известной основной истиной.

  
  

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

  
  

• Человеческая оценка . Просьба к экспертам в области человеческой деятельности дать лучший ответ обычно является золотым стандартом. Хотя этот метод медленный и дорогой, его не следует упускать из виду, поскольку он может оказаться неоценимым для получения информации и построения исходного набора данных для оценки. Если вы хотите получить дополнительный результат от выполненной работы, вы можете использовать методы, подобные тем, которые подробно описаны в AutoEval выполнено правильно документ, который дополнит ваши оценки, созданные экспертами, синтетическими вариациями.

Наряду с принятием решения о том, какие методы оценки использовать, рассмотрите возможность создания собственного набора данных для сравнительной оценки — общих, которые обычно используются в таблицах лидеров Hugging Face, таких как ММЛУ набор данных не подойдет. Ваш пользовательский набор оценочных данных будет содержать различные запросы и их идеальные ответы, которые зависят от предметной области и представляют типы запросов, которые ваши реальные клиенты будут вводить в ваше приложение. В идеале с созданием набора оценочных данных могут помочь эксперты, но в противном случае рассмотрите возможность сделать это самостоятельно. Если вы не уверены в том, какие подсказки вероятны, просто сформулируйте действующую гипотезу и двигайтесь вперед, как если бы она была подтверждена. Вы можете постоянно пересматривать свои гипотезы позже, по мере поступления новых данных.

Рассмотрите возможность применения ограничений к подсказке ввода для каждой строки в наборе оценочных данных, чтобы LLM отвечал с конкретным типом решения: двоичным, категориальным, ранжирующим, числовым или текстовым. Сочетание типов суждений обеспечит достаточное разнообразие ваших оценок и уменьшит предвзятость результатов. При прочих равных условиях, чем больше оценочных тестов, тем лучше; однако на этом этапе рекомендуется уделять больше внимания качеству, а не количеству. Недавнее исследование по оптимизации LLM в ЛИМА: Для согласования меньше значит больше В статье предполагается, что даже небольшой набор оценочных данных из 1000 строк может значительно улучшить качество результатов, при условии, что они представляют собой репрезентативные выборки действительно более широкой совокупности. В приложениях RAG мы случайно наблюдали улучшение производительности при использовании наборов оценочных данных, состоящих из десятков и сотен строк.

Хотя вы можете начать проводить оценки вручную на разовой основе, не ждите слишком долго, прежде чем внедрять конвейер CI/CD для автоматизации выполнения процесса оценки оценок. Запуск оценок ежедневно или по триггерам, связанным с репозиториями исходного кода и инструментами наблюдения, обычно считается лучшей практикой ML-операций. Рассмотрите возможность использования системы оценки RAG с открытым исходным кодом, например раги или ДипЭвал чтобы помочь вам быстро приступить к работе. Используйте озеро данных в качестве источника достоверных данных для таблиц, содержащих как версионные наборы данных оценки, так и различные выходные метрики, генерируемые каждый раз при выполнении оценки. Эти данные предоставят ценную информацию, которую можно будет использовать в дальнейшем в проекте для внесения стратегических и целенаправленных улучшений.

Экстракторы данных

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

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

• Извлечение документов . Собственные PDF-файлы, офисные документы, презентации и файлы уценки могут быть богатыми источниками информации. Для извлечения этих данных существует обширная экосистема инструментов с открытым исходным кодом и SaaS. Как правило, экстракторы данных зависят от типа файла (JSON, CSV, docx и т. д.), основаны на распознавании символов или основаны на алгоритмах машинного обучения и компьютерного зрения. Начните с простого и усложняйте только по мере необходимости.

  
  

• Извлечение API . Публичные и частные API могут быть богатыми источниками знаний внутри предметной области. Более того, хорошо спроектированные веб-API на основе JSON и XML уже имеют некоторую встроенную структуру, что упрощает целевое извлечение соответствующих свойств из полезной нагрузки, отбрасывая при этом все, что считается ненужным. Существует обширная экосистема доступных коннекторов API с низким кодированием и без кода, которые помогут вам избежать написания пользовательских ETL для каждого API, который вы хотите использовать — подход, который может быть трудно поддерживать и масштабировать без специальной команды инженеров по обработке данных.

  
  

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

  
  

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

  
  

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

Разбивка на части

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

Эффективное разбиение на фрагменты требует выбора подходящего размера фрагмента. Блоки большего размера имеют тенденцию сохранять контекст и семантическое значение фрагмента текста за счет того, что в контекстном окне может присутствовать меньшее количество фрагментов. И наоборот, меньшие размеры фрагментов позволят разместить в контекстном окне LLM более дискретные фрагменты контента. Однако без дополнительных ограждений каждая часть контента рискует ухудшиться, если ее удалить из окружающего контекста.

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

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

  
  

• Стратегия динамического размера . Этот метод использует различные характеристики содержимого, чтобы определить, где начинать и останавливать фрагмент. Простым примером может служить блокировщик знаков препинания, который разбивает предложения на основе наличия определенных символов, таких как точки и новые строки. Хотя блокировщик знаков препинания может работать достаточно хорошо для простого короткого контента (например, твитов, описаний продуктов с ограниченным количеством символов и т. д.), он будет иметь очевидные недостатки, если его использовать для более длинного и сложного контента.

  
  

• Стратегия с учетом содержимого . Блоки с учетом содержимого настраиваются на тип извлекаемого контента и метаданных и используют эти характеристики, чтобы определить, где начинать и останавливать каждый фрагмент. Примером может быть блокировщик для HTML-блогов, который использует теги заголовков для обозначения границ фрагментов. Другим примером может быть семантический блокировщик, который сравнивает показатель парного косинусного сходства каждого предложения с его предыдущими соседями, чтобы определить, когда контекст изменился достаточно существенно, чтобы оправдать выделение нового фрагмента.

  
  

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

Обогащение

Во многих случаях фрагменты контента, индексированные для извлечения во время RAG, контекстуально отличаются от фактических запросов, с которыми ваше приложение столкнется в рабочей среде. Например, если вы создаете бота, отвечающего на вопросы с искусственным интеллектом, у вас может быть обширный массив частной информации, содержащей множество правильных ответов на запросы клиентов. Однако в исходном виде ваш корпус вряд ли будет предварительно организован в формате пар вопрос-ответ, который идеально подходит для поиска по встраиванию на основе сходства. В этом примере, если во время извлечения мы будем наивно искать в нашем корпусе фрагменты необработанного контента, которые семантически похожи на входящий вопрос клиента, мы можем столкнуться с неоптимальной релевантностью набора результатов поиска. Это результат того, что мы сравниваем сходство контекстуально несопоставимых предметов, а именно вопросов с ответами. К счастью, решение относительно простое: мы можем использовать возможности LLM, чтобы обогатить наши возможные ответы – т. е. фрагменты необработанного контента – путем реконтекстуализации их в гипотетические вопросы. Затем мы индексируем эти гипотетические вопросы в нашу векторную базу данных для последующего поиска. Эта техника, названная Гипотетические встраивания документов (HyDE) , иллюстрирует возможности использования LLM для обогащения ваших данных в конвейере обработки документов. Вот пример использования этой техники на некотором контенте из известного набор данных Squad_v2 :

 System Prompt: Given the provided snippet of text, generate three hypothetical questions that could be asked about it. Each question must be able to be answered using the information within the referenced snippet of text and only that information. Be concise. User Prompt: “At the 52nd Annual Grammy Awards, Beyoncé received ten nominations, including Album of the Year for I Am... Sasha Fierce, Record of the Year for "Halo", and Song of the Year for "Single Ladies (Put a Ring on It)", among others. She tied with Lauryn Hill for most Grammy nominations in a single year by a female artist. In 2010, Beyoncé was featured on Lady Gaga's single "Telephone" and its music video. The song topped the US Pop Songs chart, becoming the sixth number-one for both Beyoncé and Gaga, tying them with Mariah Carey for most number-ones since the Nielsen Top 40 airplay chart launched in 1992. "Telephone" received a Grammy Award nomination for Best Pop Collaboration with Vocals.” Response: Here are some questions that could be asked based on the provided text: * How many nominations did Beyoncé receive at the 52nd Annual Grammy Awards? * For which album was Beyoncé nominated for Album of the Year at the 52nd Annual Grammy Awards? * Which song earned Beyoncé a nomination for Record of the Year at the 52nd Annual Grammy Awards?

Если вы работаете с корпусом, состоящим из длинного и/или тематически сложного контента, рассмотрите возможность дополнительной предварительной обработки, чтобы предварительно суммировать фрагменты контента и тем самым уменьшить их семантическую размерность. Во время извлечения вы можете запросить встраивание сводок фрагментов, а затем заменить необобщенный текст для вставки контекстного окна. Этот метод повышает релевантность при выполнении RAG для большого, сложного и/или часто меняющегося корпуса данных.

Токенизация

Большие языковые модели в 2024 году, как правило, представляют собой нейронные сети на основе преобразователей, которые изначально не понимают письменное слово. Входящий необработанный текст преобразуется в токены, за которыми следуют многомерные векторы внедрения, оптимизированные для операций матричного умножения. Этот входящий процесс обычно называется кодированием. Инвертированный исходящий процесс называется декодированием. Многие LLM будут работать только для вывода, используя ту же схему токенизации, на которой они обучались. Следовательно, важно понимать основы выбранной стратегии токенизации, поскольку она может иметь множество тонких последствий для производительности.

Несмотря на то, что существуют простые схемы токенизации на уровне символов и слов, на момент написания почти все современные LLM используют токенизаторы подслов. Следовательно, мы сосредоточимся здесь только на этой категории токенизаторов.

Токенизаторы подслов рекурсивно разбивают слова на более мелкие единицы. Это позволяет им понимать слова, не входящие в словарный запас, не слишком увеличивая размер словарного запаса — ключевой фактор для эффективности обучения и способности LLM обобщать невидимые тексты.

Распространенным методом токенизации подслов, используемым сегодня, является кодирование парами байтов (BPE). На высоком уровне алгоритм BPE работает следующим образом:

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

  
  

• Замените общие пары токенов из предыдущего шага одним токеном, представляющим пару, и добавьте его в словарь.

  
  

• Рекурсивно повторите описанные выше шаги.

  
  

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

Заключение

Современное озеро данных, построенное на основе хранилища объектов MinIO, обеспечивает базовую инфраструктуру для уверенного запуска приложений на основе RAG в производство. Благодаря этому вы можете создавать оценочные данные и набор оценочных данных для конкретного домена, которые можно хранить и управлять версиями внутри таблиц озера данных. Используя эти оценки, неоднократно оценивайте и постепенно улучшайте каждый компонент конвейера документов вашего приложения RAG — экстракторы, блокираторы, обогащение и токенизаторы — настолько, насколько это необходимо для создания конвейера обработки документов промышленного уровня.

Если у вас есть вопросы, обязательно свяжитесь с нами по телефону Слабый !