Авторы: Харрисон Чейз и Брайан Рэймонд.
Темпы развития в области больших языковых моделей (LLM) резко возросли за последние несколько месяцев, и одной из самых интересных сюжетных линий стал быстрый переход к новому технологическому стеку для поддержки совершенно новой модели взаимодействия с этими языковыми моделями. В этом сообщении блога мы рассмотрим изменения, происходящие в стеке технологий LLM, и их значение для разработчиков.
Существующий стек технологий НЛП
До недавнего времени разработчики НЛП полагались на стек технологий, оптимизированный для таких задач НЛП, как классификация текста, распознавание именованных объектов, устранение неоднозначности именованных объектов. Этот технический стек обычно состоит из конвейера предварительной обработки данных, конвейера машинного обучения и различных баз данных для хранения вложений и структурированных данных. Эта архитектура хорошо работала для создания огромного количества троек, встраивания слов, встраивания предложений, выходных данных от последовательности к последовательности, вероятностей языковых моделей, весов внимания и многого другого. Разработчики обычно сохраняли эти структурированные выходные данные в базах данных ElasticSearch, Postgres или Neo4j, которые они использовали в качестве графа знаний, к которому могли обращаться пользователи (или службы).
Эта архитектура хорошо работала для создания высоконадежных структурированных данных, которые можно было развертывать в корпоративных системах для автоматизации ключевых процессов (например, классифицировать документы, находить сущности и отношения между сущностями и т. д.). Тем не менее, они изо всех сил пытались получить широкое распространение, потому что они были медленными (требовались большие объемы размеченных данных и немало тонкой настройки модели); дорого работать (часто эти архитектуры имеют более трех десятков моделей в конвейере/системе); а конвейеры загрузки и моделирования были уязвимы для новых макетов документов и типов данных.
Новый технический стек LLM
С осени 2022 года начал появляться новый технологический стек, предназначенный для использования всего потенциала LLM. В отличие от предыдущего стека технологий, этот направлен на обеспечение генерации текста — задачу, с которой современные LLM особенно хорошо справляются по сравнению с более ранними моделями машинного обучения. Этот новый стек состоит из четырех столпов: конвейер предварительной обработки данных, конечная точка встраивания + хранилище векторов, конечные точки LLM и среда программирования LLM. Есть несколько больших различий между старым технологическим стеком и новым. Во-первых: новый стек технологий не так зависит от графов знаний, которые хранят структурированные данные (например, триплеты), потому что LLM, такие как ChatGPT, Claude и Flan T-5, содержат гораздо больше информации, закодированной в них, чем более ранние модели, такие как GPT 2. Во-вторых: новый технологический стек использует готовую конечную точку LLM в качестве модели, а не специально созданный конвейер машинного обучения (по крайней мере, для начала). Это означает, что сегодня разработчики тратят гораздо меньше времени на обучение специализированным моделям извлечения информации (например, распознаванию именованных сущностей, извлечению отношений и настроению) и могут разрабатывать решения за долю времени (и затрат).
Конвейер предварительной обработки данных. Первый столп нового стека технологий практически не изменился по сравнению со старым стеком: конвейер предварительной обработки данных. Этот шаг включает соединители для приема данных, где бы они ни находились (например, корзина S3 или CRM), уровень преобразования данных и нисходящие соединители (например, к векторной базе данных). Часто наиболее ценная информация для LLM также является самой сложной для работы (PDF, PPTX, HTML и т. д.), но также документы, в которых текст легко доступен (например, .DOCX), содержат информацию, которую пользователи не знают. не хотят отправляться в конечную точку вывода (например, рекламные объявления, юридический шаблон и т. д.).
Исторически сложилось так, что этот шаг создавался специалистами по обработке и анализу данных вручную для каждого приложения. В зависимости от типов задействованных данных они могут использовать готовые модели OCR и от десятков до сотен пользовательских регулярных выражений для преобразования и очистки данных на естественном языке для обработки в нижестоящем конвейере машинного обучения. В Unstructured мы разрабатываем инструменты с открытым исходным кодом для ускорения этого этапа предварительной обработки, используя ряд моделей сегментации документов компьютерного зрения, а также модели NLP, скрипты Python и регулярные выражения для автоматического извлечения, очистки и преобразования важных элементов документа (например, заголовки, основной текст, верхние и нижние колонтитулы, списки и многое другое). В настоящее время мы работаем над новым поколением инструментов, которые упростят разработчикам поиск больших и очень разнородных массивов файлов, содержащих данные на естественном языке (например, корзину S3, содержащую тысячи PDF-файлов, PPTX-файлов, журналов чатов, извлеченных файлов HTML и т. д.). ) в одной конечной точке API и получить чистый JSON, готовый для встраивания конечной точки и хранения в векторной базе данных.
Конечная точка внедрения и хранилище векторов. Использование конечной точки внедрения и хранилища векторов представляет собой значительную эволюцию в способах хранения данных и доступа к ним. Раньше встраивания в основном использовались для нишевых задач, таких как кластеризация документов. Однако в новой архитектуре хранение документов и их вложений в базу данных векторов позволяет использовать критически важные шаблоны взаимодействия конечной точкой LLM (подробнее об этом ниже). Одним из основных преимуществ этой архитектуры является возможность напрямую хранить необработанные вложения, а не преобразовывать их в структурированный формат. Это означает, что данные могут храниться в их естественном формате, что позволяет сократить время обработки и более эффективно извлекать данные. Кроме того, этот подход может упростить работу с большими наборами данных, поскольку он может уменьшить объем данных, которые необходимо обрабатывать во время обучения и логического вывода.
Создание и хранение вложений документов вместе с версиями самих документов в формате JSON создает простой механизм взаимодействия LLM с векторным хранилищем. Это особенно полезно для приложений, где требуется обработка в реальном времени, таких как чат-боты. Минимизируя время, необходимое для извлечения данных, система может быстрее реагировать и обеспечивать лучший пользовательский интерфейс. Еще одно преимущество использования встраивания (и индекса документа) и векторного хранилища заключается в том, что это может упростить реализацию таких методов, как перенос обучения, чтобы обеспечить более эффективную точную настройку и лучшую производительность.
Конечная точка LLM. Третьим элементом нового стека технологий является конечная точка LLM. Это конечная точка, которая получает входные данные и производит выходные данные LLM. Конечная точка LLM отвечает за управление ресурсами модели, включая память и вычислительные ресурсы, а также за предоставление масштабируемого и отказоустойчивого интерфейса для предоставления выходных данных LLM нижестоящим приложениям.
Хотя большинство поставщиков LLM предлагают несколько различных типов конечных точек, мы используем это для обозначения конечных точек генерации текста. Как упоминалось выше, это новая технологическая разблокировка, которая обеспечивает работу многих новых приложений (по сравнению с более традиционными конвейерами машинного обучения). Это небольшое упрощение, но интерфейс, предоставляемый этими конечными точками LLM, представляет собой текстовое поле в качестве ввода и текстовое поле в качестве вывода.
Среда программирования LLM. Последней опорой нового технологического стека является среда программирования LLM. Эти фреймворки предоставляют набор инструментов и абстракций для создания приложений с языковыми моделями. В LangChain это именно тот фреймворк, над созданием которого мы работаем. Эти структуры быстро развиваются, что может затруднить их определение. Тем не менее, мы приближаемся к набору абстракций, которые мы подробно рассмотрим ниже.
Большая функция этих фреймворков — оркестровка всех различных компонентов. На данный момент в современном стеке появляются следующие типы компонентов: поставщики LLM (описанные в разделе выше), модели встраивания, векторные хранилища, загрузчики документов, другие внешние инструменты (поиск Google и т. д.). В LangChain мы называем способы объединения этих компонентов цепочками. Например, у нас есть цепочки для выполнения QA над хранилищем векторов, цепочки для взаимодействия с базами данных SQL и т. д.
Все эти цепочки включают вызов языковой модели в какой-то момент. При вызове языковой модели основная проблема связана с созданием подсказки для перехода к языковой модели. Эти подсказки часто представляют собой комбинацию информации, взятой из других компонентов, и базового шаблона подсказки. LangChain предоставляет набор шаблонов подсказок по умолчанию для начала работы с этими цепочками, но мы также сосредоточены на создании LangChainHub — места, где пользователи могут делиться этими подсказками.
Открытые вопросы:
Лучший способ индексации данных. В настоящее время все в основном используют векторные хранилища в качестве основного способа индексации данных, чтобы LLM могли с ними взаимодействовать. Однако это только первый этап определения того, как должны работать эти взаимодействия. Областью активного исследования является степень, в которой графы знаний в сочетании с индексами документов и их вложениями могут еще больше повысить качество выводов из LLM. Кроме того, в обозримом будущем большинству предприятий по-прежнему будут требоваться высококачественные структурированные данные (обычно в графовой базе данных) для объединения с существующими наборами данных и решениями бизнес-аналитики. Это означает, что в среднесрочной перспективе корпоративные пользователи могут фактически полагаться как на векторные, так и на графовые базы данных для поддержки существующих приложений и рабочих процессов.
Как будет выглядеть тонкая настройка/переобучение. В настоящее время для объединения ваших собственных данных с предварительно обученным LLM используются среды программирования LLM, такие как LangChain. Другой способ сделать это — настроить LLM на ваших данных. Тонкая настройка имеет некоторые плюсы и минусы. С положительной стороны, это снижает потребность в большом количестве этой оркестровки. С другой стороны, правильная настройка обходится дороже и занимает больше времени, а также требует периодического выполнения этой процедуры, чтобы быть в курсе последних событий. Будет интересно посмотреть, как эти компромиссы изменятся с течением времени.
Различные способы использования вложений.Даже если основной шаблон использования по-прежнему заключается в хранении данных во внешней базе данных, а не в их точной настройке, существуют другие способы их объединения с LLM, а не текущие подходы (которые все включают передачу его в подсказку). Наиболее захватывающими являются такие подходы, как РЕТРО, которые извлекают вложения для документов, но затем обращаются непосредственно к этим вложениям, а не передают текст в качестве подсказок. Хотя эти модели в основном использовались в исследовательских целях, будет интересно посмотреть, сделают ли они их общепринятыми и как это повлияет на среды программирования LLM.
Заключение
Переход к этому новому стеку технологий LLM — это захватывающая разработка, которая позволит разработчикам создавать и развертывать более мощные приложения NLP. Новый стек более эффективен, масштабируем и прост в использовании, чем старый стек, и раскрывает весь потенциал LLM. Мы можем ожидать появления новых инноваций в этой области в ближайшие месяцы и годы, поскольку разработчики продолжают находить новые способы использования возможностей LLM.
