Использование внешних AI моделей в Loginom

В последние годы технологии LLM (Large Language Model) активно захватили информационное пространство под вывеской «Искусственный интеллект» (Artificial Intelligence — AI). Сам факт того, что можно весьма полезно беседовать с AI-моделью как с человеком, обладающим экспертными знаниями, поражает воображение и наводит на мысль о возможном делегировании задач системам, построенным с использованием таких моделей.

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

AI-модели

LLM представляет собой нейросетевую модель, просто очень большую (large). Нейронные сети известны с середины прошлого века и повсеместно применяются в различных системах обработки данных. Например, Loginom содержит штатные компоненты «Нейросеть (классификация)» и «Нейросеть (регрессия)» для решения соответствующих задач.

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

Эпоха LLM началась в 2017 году после выхода статьи «Attention Is All You Need», описавшей нейросетевую архитектуру «Трансформер», и последующей публикации моделей семейств BERT (Bidirectional Encoder Representations from Transformers) и GPT (Generative Pre-trained Transformer). Новая архитектура позволила эффективно обучать модели на гигантских объемах данных, что, в свою очередь, привело к резкому росту размеров таких моделей.

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

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

После этапа предобучения AI-модель обладает существенным объемом информации, но не способна эффективно взаимодействовать с пользователями, отвечая на их вопросы. Для исправления этой проблемы предназначен этап дообучения, на котором LLM учится отвечать на вопросы на различных языках и в различной стилистике, формировать цепочки размышлений для поиска решения сложных проблем, вызывать внешние сервисы для получения дополнительной информации и т.п.

Использование LLM

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

• закрытые модели (OpenAI o3, o1, GPT-4, Google Gemini 2, YandexGPT, GigaChat), развернутые для использования на серверах разработчика, — использование таких моделей возможно только через программный интерфейс или API;
• открытые модели (LLaMA, QWQ, Mistral, Gemma, T-Pro) — доступные в виде файлов, которые можно загрузить и использовать на собственном сервере.

Сосредоточимся на использовании закрытых моделей в сценариях Loginom. Эти модели обладают следующими особенностями:

• преимущества:
  • качество моделей — закрытые модели обычно самые точные и современные;
  • простота использования — все вопросы хостинга решены разработчиком, достаточно отправлять запросы через API;
  • расширенный функционал — помимо обычной работы с моделями в режиме вопрос/ответ предлагается дополнительный функционал: использование различных ассистентов, дообучение модели на своих данных, функциональные вызовы и т.п.;
  • повышенная безопасность — разработчики интегрируют механизмы контроля ответов для защиты пользователей;
• недостатки:
  • стоимость использования — каждый запрос оплачивается, и расходы сложно контролировать;
  • отсутствие конфиденциальности — все запросы к модели передаются на сервера ее разработчиков, то есть информация покидает контур безопасности компании;
  • ограничения использования — разработчики накладывают ограничения на использование моделей (например, модели от OpenAI или Google не доступны для пользователей из России).

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

Роль Loginom в системах с LLM

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

Непосредственное взаимодействие с AI-моделью — лишь один из этапов обработки. Предварительно необходимо подготовить запрос на основе реальных данных, проконтролировать ответ модели, при необходимости повторить запрос или выстроить последовательный диалог с LLM для реализации сложных методов, таких как цепочки размышлений (chain-of-thoughts).

Аналитическая платформа Loginom — удобный инструмент как для создания отдельных компонентов (сценариев), взаимодействующих с AI-моделями, так и для построения полных информационных систем, решающих задачи иерархической обработки данных.

Схема организации взаимодействия Loginom и сервера LLM по REST API

Необходимые для решения задачи данные недоступны для AI-модели напрямую и должны быть извлечены из различных источников (файлов, баз данных и т.п.). Объем исходных данных может быть весьма велик, что не позволит включить их в запрос полностью. Кроме того, большие запросы обходятся дорого и часто лишь снижают качество ответа LLM.

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

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

Таким образом, взаимодействие c LLM требует наличия множества компонентов обвязки, для создания которых можно использовать Loginom.

Постановка задачи

В качестве примера рассмотрим задачу стандартизации нормативно-справочной информации (НСИ) на примере нормализации описания товарно-материальных ценностей (ТМЦ):

• исходное состояние:
  • вся информация о ТМЦ хранится в ее описании;
  • нормализуемая база данных хранит записи ТМЦ из различных источников, что приводит к различию в форматах их описания;
  • описания ТМЦ изначально вносились вручную или в результате операции сканирования и распознавания документов, что приводит к значительному «зашумлению» данных (наличие опечаток, омографов, некорректных символов и т.п.);
  • предварительно сформировано онтологическое описание, содержащее набор классов ТМЦ, набор атрибутов для каждого класса, для каждого атрибута хранится его описание и примеры допустимых значений;
  • записи ТМЦ были предварительно классифицированы, в примере используем записи класса «Автошина»;
• необходимо для каждой записи ТМЦ на основании текстового описания определить значения следующих атрибутов класса «Автошина»:
  • норма слойности;
  • обозначение размера;
  • протектор;
  • страна происхождения.

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

Варианты решения задачи

Рассматриваемая задача является классической задачей NER (Named-entity recognition — распознавания именованных сущностей) с добавлением дополнительной логики по стандартизации данных (распознано — материал: деревянный, необходимо сохранить — материал: дерево). Обычно подобные задачи решают одним из трех способов:

1. применение парсеров — для извлечения информации из неструктурированного текста создаются наборы правил, либо на базе регулярных выражений, либо на базе специализированных языков более высокого уровня; программа (сценарий) парсера применяет эти правила для каждого обрабатываемого текстового описания и сохраняет выделенные результаты;
2. применение специализированных моделей (прежде всего нейросетевых) — при данном способе основные трудозатраты идут на подготовку обучающего набора данных, в котором для каждого текстового описания сохранены уже выделенные значения; после обучения модели она может применяться к новым данным и дообучаться по мере необходимости;
3. применение AI-моделей — LLM способны анализировать информацию и рассуждать аналогично тому, как это делает человек; основная работа в данном способе сводится к выбору используемой модели и формированию цепочек рассуждений — наборов последовательно задаваемых модели вопросов для получения требуемого результата.

Применение LLM позволяет существенным образом сократить трудозатраты на решение задачи, поскольку:

• не требует написания правил парсинга или подготовки наборов обучающих данных;
• цепочки рассуждений являются универсальными — по сути, стандартизация НСИ для всех классов выполняется с применением одного шаблона вопросов, в который автоматически подставляются нужные атрибуты и примеры, т.е. нет необходимости подготовки тех же правил парсинга для каждого класса в отдельности;
• отсутствия необходимости внесения корректировок в процессе работы решения: в случае появления ТМЦ с измененным форматом описания (например, вместо 195/65R14 для маркировки автошины будет применяться полная расшифровка вида ширина — 195, высота — 65, конструкция — радиальная, диаметр диска — 14) в первых двух способах потребуются корректировки в правила парсинга и модели, а LLM же способна понять, что приведенные примеры описывают одно и тоже;
• повышение качества решения задачи может быть достигнуто простым переходом на использование новых версий LLM, скорость развития которых весьма высока.

Недостаток применения AI-моделей состоит прежде всего в гораздо более высоких аппаратных требованиях: на решение задачи будет потрачено значительно больше вычислений и энергии.

Использование GigaChat API

Для решения поставленной задачи можно воспользоваться закрытой LLM от ПАО СберБанк — GigaChat. Документация по GigaChat API доступна на сайте разработчиков СБЕР. После регистрации своего проекта будет бесплатно доступно стартовое количество токенов (разное для разных моделей), которого хватит для оценки возможностей предлагаемых моделей по решению вашей задачи.

GigaChat API требует направления запроса к модели в виде массива сообщений messages. Каждое сообщение должно состоять из двух элементов, определяющих роль и содержание сообщения, например:

{  
"role": "system",  
"content": "Ты профессиональный переводчик на английский язык. Переведи точно сообщение пользователя."  
}

Для параметра роль доступны следующие значения: «system», «user», «assistant», «function». Таким образом, запрос к модели формируется в виде диалога, начинающегося с системного запроса (роль — «system») и продолжающегося чередованием сообщений от остальных участников: пользователя — user, модели — assistant, дополнительных сервисов — function.

В простейшем случае массив messages должен содержать единственное сообщение от пользователя с вопросом, однако формирование диалога позволяет увеличить качество ответа LLM за счет:

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

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

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

Описание демонстрационного сценария

Ниже представлен верхний уровень сценария Loginom, решающего поставленную задачу. Для корректной работы сценария в системе должна быть определена переменная окружения GIGA_CHAT_PERS, хранящая полученный «Ключ авторизации» (Authorization key).

Компонент «ТМЦ для обработки» загружает подлежащие обработке записи ТМЦ в формате Идентификатор/Описание из Excel-файла. В реальной системе данные могут поступать из БД в виде запросов к веб-сервису, файлов различных форматов, интеграционных подсистем и т.п. Такой функционал может быть также реализован в Loginom.

Описание ТМЦ будет добавлено в массив сообщений как запрос пользователя, однако предварительно нужно сформировать системный запрос и набор примеров. Для этого используются компоненты группы «Подготовка запросов». На вход поступают два набора данных:

• «Примеры» — содержит исходное описание ТМЦ и результат его разбора в формате JSON (ключ — наименование атрибута, значение — результат определения его значения), такой набор может быть сформирован вручную или получен из используемой ранее системы, решавшей аналогичную задачу;
• «Атрибуты» — содержит онтологическое описание обрабатываемого класса в формате «Класс» — «Описание класса» — «Атрибут» — «Описание атрибута» — «Значение» (колонка «Значение» содержит примеры значений атрибута).

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

Работа с LLM реализуется подмоделью «Определение атрибутов». Помимо входного набора обрабатываемых данных, подаваемого на табличный порт, на входном порту переменных должны быть определены следующие:

• Модель (model) — содержит название используемой модели согласно GigaChat API, при этом использование более крупных моделей обходится дороже, но, как правило, дает более точный ответ;
• Температура (temperature) — вещественное число, большее нуля, определяет случайность (креативность) ответа модели, большие значения соответствуют более случайным ответам; для рассматриваемой задачи лучше использовать близкие к нулю значения;
• Максимум токенов в ответе (max_tokens) — ограничивает количество токенов, которые будут использованы для создания ответа (полезно при работе с закрытыми моделями для контроля расходов);
• предварительно подготовленные переменные:
  • Примеры (examples) — строка, содержащая примеры определения атрибутов в форме последовательных сообщений пользователя и модели, разделенных запятыми;
  • Системный запрос (system_prompt) — определяет роль модели и набор инструкций.

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

Подмодель «Токен авторизации» реализует механизм получения токена доступа GigaChat API. Для корректной работы необходимо до запуска Loginom создать переменную окружения GIGA_CHAT_PERS, в которую сохранить полученный «Ключ авторизации» (Authorization key) — подробно эта процедура описана в документации GigaChat API. На выход подмодели передается переменная access_token, значение которой используется для дальнейших обращений к LLM. Токен доступа выдается на 30 минут, после чего требует обновления (перезапуска подмодели).

Компонент «Формирование запроса» собирает запрос согласно требованиям GigaChat API, а компонент «REST-запрос» направляет его к модели. Ответ LLM разбирается и преобразуется к нужному виду компонентами «JSON парсер» и «Ключ: значение».

Заключение

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

Среди недостатков сценария, объясняющихся его демонстрационной простотой, следует упомянуть недостаточную стандартизацию получаемого результата. Например, в качестве разделителя значения атрибута «обозначение размера» на выходе может использоваться символ «-» вместо «/». Этот недостаток может быть частично устранен с помощью перехода к более крупной модели или введения дополнительной логики обработки ответа LLM в сценарий.

Основным преимуществом демонстрируемого решения является легкая адаптация для произвольных классов ТМЦ, что позволяет достаточно быстро построить систему стандартизации НСИ на базе Loginom, закрывающую требования конкретного заказчика.

Другие материалы по теме:

ModelOps в Loginom: управление моделями и экспериментами

Как избежать проклятий: правильная организация сценариев в Loginom