В конечном счете для вывода на рынок приложений генеративного искусственного интеллекта (GenAI) требуются общая операционная модель и платформа для интеграции данных, пишет на портале The New Stack Эндрю Селлерс, возглавляющий группу технологической стратегии компании Confluent.

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

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

Компании по всему миру экспериментируют с созданием приложений и инструментов на базе GenAI, чтобы повысить эффективность и усилить инновации. Согласно новому прогнозу IDC, в 2023 г. расходы на GenAI в мире достигнут 15,9 млрд. долл. Но эти инвестиции не принесут непропорциональной выгоды лишь нескольким компаниям, как это было в прошлых итерациях ИИ.

Хотя развивается многообещающий подход к созданию приложений с поддержкой GenAI с обучением «zero-shot» (с нуля без примеров) или «few-shot» (на малом количестве примеров), большинство нетривиальных сценариев использования требуют, чтобы подсказки были контекстуализированы с помощью данных, специфичных для конкретной области, которые не были доступны, когда обучались LLM. От семантического поиска до рекомендательных систем — большинство ценных сценариев использования приложений с поддержкой GenAI требуют сопряжения подсказок с релевантными, своевременными и точными корпоративными данными для создания полезных результатов, обычно с применением схемы, известной как генерация с расширенным поиском (RAG).

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

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

Основываясь на результатах обсуждений, проведенных нашей командой с сотнями компаний, создающих приложения GenAI, мы пришли к выводу, что лучший способ их создания — это принятие событийно-ориентированного подхода. Мы выделили четыре общих этапа, которые обычно присущи работе таких приложений. Каждый шаг в идеале должен быть реализован как событийно-управляемое приложение.

Ключевые шаги для создания приложений на основе LLM с потоковой передачей событий

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

Давайте посмотрим, как это сделать:

Шаг 1. Расширение данных

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

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

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

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

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

Шаг 2. Вывод (инференс)

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

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

Теперь давайте посмотрим, как может помочь событийно-ориентированный подход.

Если вы посмотрите на изображение ниже, то увидите слева веб-приложение, которое обычно создаются командой полного цикла (fullstack), в основном сосредоточенной на том, как данные поступают и выводятся в сессиях объектно-реляционного отображения (ORM) и управления. При такой схеме веб-приложение может работать независимо от потребительской группы, которую вы видите справа и которая может быть бэкенд-командой, специализирующейся на разработке ИИ-приложений. Эта группа обращается к векторному хранилищу для проектирования подсказки, которая обращается к LLM-сервису.

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

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

Шаг 3. Рабочие процессы

Рабочие процессы — это общая концептуальная модель (например, цепочки в LangChain) для объединения агентов рассуждений и шагов вывода для создания приложений с поддержкой GenAI. Идея относительно агентов заключается в том, что нам часто нужно что-то, что автоматизирует действия, например, следующий вызов LLM, основываясь на том, каким был предыдущий ответ. LLM могут быть подходящими интеллектуальными агентами для некоторых применений, но это часто специализированные, более традиционные модели, которые могут полагаться на знания, специфичные для конкретной области.

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

Теперь давайте посмотрим на изображение выше. Как и раньше, разработчики веб-приложений могут работать независимо друг от друга. Инженеры полного цикла могут создавать веб-приложения, а инженеры бэкенд-систем формировать потребительские группы, которые могут осуществлять поиск на естественном языке в оперативных данных, как в реляционной СУБД. Это то, что позволяют делать SQLBuilder и LangChain. Они могут использовать агенты рассуждения и контекстуализировать подсказки на основе того, что находится в хранилище векторов. Можно сделать столько последующих обращений к LLM, сколько необходимо, что поможет ответить на любой запрос веб-приложения.

Шаг 4. Постобработка

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

Как здесь может помочь использование событийно-ориентированной методологии? Если вы посмотрите на изображение ниже, то увидите независимую группу потребителей постобработки. И снова: это позволяет отделить постобработку от остальной части приложения.

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

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

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

Использование платформ потоковой передачи данных

Одно из основных преимуществ потоковой передачи данных заключается в том, что вы не ограничены местом хранения данных. Потоковая передача данных позволяет компаниям направлять соответствующие потоки данных в любое место, где они необходимы, в режиме реального времени, делая данные легкодоступными для GenAI-приложений.

Платформы потоковой передачи данных обеспечивают работу генеративных приложений в режиме реального времени в масштабе за счет:

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

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

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