Использование LLM с помощью LangChain для аналитики цепи поставок – контрольная башня, работающая на основе GPT

Оптимизация аналитики цепи поставок с помощью LLM и LangChain контрольная башня на базе технологии GPT

Создание автоматизированной башни управления цепочкой поставок с агентом LangChain SQL, подключенным к базе данных системы управления транспортом

(Изображение автора)

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

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

Башня управления цепочкой поставок с использованием Python [Ссылка] — (Изображение автора)

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

Однако этот подход имеет ограничения в области показателей и отчетов, предоставленных.

Как можно улучшить эту модель для лучшего пользовательского опыта?

Это наблюдение привело меня к многообещающему потенциалу больших языковых моделей (Large Language Models, LLM), таких как GPT от OpenAI, в предоставлении настраиваемого анализа на основе каждого запроса пользователя.

Высокоуровневая концепция решения — (Изображение автора)

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

💌 Новые статьи бесплатно прямо в ваш почтовый ящик: Рассылка📘 Ваш полный гид по аналитике цепочки поставок: Шпаргалка по аналитике

СУММАРИ I. LLM с использованием LangChain для аналитики цепочки поставок Исследование того, как LangChain и LLM могут революционизировать аналитику в управлении цепями поставок.1. Сценарий: Процесс распределения в розничном сетевом филиале сложные операции распределения в глобальном розничном сетевом филиале.2. Подготовка к экспериментуПредставление экспериментальной установки для тестирования агента LangChain SQL. 3. Экспериментальный протокол: Начать с простогоНачать с простого запроса для оценки основных возможностей агента.II. Эксперименты и ключевые идеи1. Тест 1Простой запрос без шаблона2. Тест 2Шаблон запроса с контекстом3. Тест 3Шаблон запроса с улучшенным контекстом4. Тест 4Расширенный анализ с улучшенным контекстом5. Финальный тестСоздание цепочки для написания отчета по электронной почтеIII. LLM задает будущее цепи поставок1. Простой 'доказательственный концепт'Мы можем использовать агента для отслеживания грузов с данными TMS2. Продолжение разработки прототипаЗадача агента с комплексным анализом и большим количеством таблиц.3. Исследование более широких применений в цепи поставокLLM могут улучшить пользовательский опыт для цифровых двойников, оптимизации сети, бизнес-аналитики, отчетности ESG и многих других приложений

LLM с использованием LangChain для аналитики цепочки поставок

Сценарий: Процесс распределения в розничной торговле одеждой

Представьте себя в роли дата-ученого в международной группе по одежде с глобальной сетью магазинов.

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

Сеть цепи поставок — (Изображение автора)

Она возглавляет команду планировщиков, которые управляют запасами магазинов по всему миру.

Процесс прост: когда уровень запасов достигает минимального значения

Решающим показателем эффективности является процент своевременно выполненных заказов.

Процессы цепочки распределения отслеживаются временными метками — (Изображение от автора)

От создания заказа до доставки в магазин в базу данных записываются несколько временных меток и булевых флагов.

  • Время передачи заказа записывается в поле ‘Transmission’. Если это происходит после отсечки времени, значение ‘Transmission_OnTime’ устанавливается в 0.
  • Время погрузки грузовика записывается в поле ‘Loading‘. Если это происходит после отсечки времени, значение ‘Loading_OnTime’ устанавливается в 0.
  • Прибытие грузовика в аэропорт записывается в поле ‘Airport_Arrival‘. Если это происходит после отсечки времени, значение ‘Airport_OnTime’ устанавливается в 0.
  • Приземление самолета в аэропорту записывается в поле ‘Airport_Arrival‘. Если это происходит после отсечки времени, значение ‘Airport_OnTime’ устанавливается в 0.
  • Прибытие грузовика в город записывается в поле ‘City_Arrival‘. Если это происходит вне рабочего времени магазина, значение ‘Store_Open’ устанавливается в 0.

Самой важной временной меткой является ‘Delivery_Time‘. Она сравнивается с «Ожидаемое время доставки» для установки значения ‘On_Time_Delivery’.

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

Вопрос 1: Сколько отправлений было доставлено с задержкой?

(Изображение от автора)

Вопрос 2: Где находятся отправления в настоящее время?

(Изображение от автора)

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

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

Мы подходим к пределам традиционных инструментов бизнес-аналитики (BI), которые используют визуалиции, таблицы и отчеты для ответов на операционные вопросы.

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

Можем ли мы использовать модель GPT для улучшения пользовательского опыта, предоставляя настроенные выводы для каждого запроса?

Вот что я пытаюсь выяснить с помощью простого прототипа, разработанного с помощью Python.

Подготовка сцены для эксперимента

Настройка проста:

  • Локальная база данных ‘shipments.db’ с одной таблицей ‘shipments’
  • Langchain версии 0.0.325
  • OpenAI Key для запроса моделей GPT
  • Локальная среда Python с библиотеками LangChain, SQLite и Pandas
Общий обзор решения — (изображение автора)

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

Таким образом, SQL-агент LangChain (работающий на основе модели GPT от OpenAI) может получать доступ к базе данных, писать SQL-запросы и использовать результаты для ответа на вопросы пользователей.

Экспериментальный протокол: начало с простого

Поскольку я хотел оценить эффективность агента, я начал с простого вопроса.

“Сколько отправлений было задержано в первые семь дней мая?”

Правильный ответ: 6 816 отправлений.

Целевое поведение агента — (изображение автора)

Я ожидаю, что агент создаст SQL-запрос, который будет подсчитывать все отправления с ‘2021–05–01’ по ‘2021–05–07’ с булевым флагом ‘On_Time_Delivery’ = False.

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

💡 Подписывайтесь на меня в VoAGI, чтобы получать больше статей, связанных с аналитикой 🏭 цепи поставок, устойчивостью 🌳 и производительностью 🕜.

Эксперименты и ключевые идеи

Теперь, когда все готово, я могу начать создавать агента LangChain, который будет взаимодействовать с базой данных.

Я использую тип агента AgentType.ZERO_SHOT_REACT_DESCRIPTION, который предназначен для работы в контексте “нулевого обучения”.

Этот агент способен отвечать на запросы без какого-либо предварительного специального обучения.

Тест 1: Простой запрос без шаблона

Первый тест заключается в запросе агента с простым вопросом.

“Сколько отправлений было задержано в первые семь дней мая?”

[Блок 1]: Агент начинает исследовать базу данных с уникальной таблицей ‘shipments’.

[Блок 1]: Обнаружение базы данных — (изображение автора)

Агент связывает “задержанные отправления” из вопроса с таблицей ‘shipments’ базы данных.

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

[Блок 2]: Агент создает запрос и дает неправильный ответ.

[Блок 2]: Запрос к базе данных и предоставление ответа — (изображение автора)
Тест 1: Целевой результат (слева) / Результат теста (справа) — (Изображение от автора)

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

Это может быть принято, так как мы явно не определили, что является отсрочкой отправки.

Тест 2: Шаблон запроса с контекстом

Чтобы улучшить ответ, я могу использовать шаблон запроса с контекстом.

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

context_explanation = """В качестве менеджера контрольной башни по снабжению, моя роль заключается в наблюдении за логистической сетью и обеспечении эффективной обработки и своевременной доставки грузов. 'Таблица отправлений' в нашей базе данных является важной для мониторинга этих процессов. Она содержит несколько столбцов, которые отслеживают ход и своевременность каждой отправки на различных этапах:- 'Дата заказа' и 'Ожидаемая дата погрузки' предоставляют отметки времени, когда был размещен заказ и когда ожидалась его загрузка для отправки.- 'Ожидаемое время доставки' - это отметка времени, определяющая, когда ожидается доставка груза- 'Loading_OnTime', 'Airport_OnTime', 'Landing_OnTime', 'Transmission_OnTime' - это логические значения, указывающие, была ли отправка обработана вовремя на разных этапах. Если какой-либо из них равен False, это означает, что произошла задержка, которая может вызвать перенос отправки на следующий день.- 'Store_Open' указывает, доставил ли грузовик товар в магазин до закрытия. Здесь значение False означает, что доставка должна ждать до следующего дня.- 'On_Time_Delivery' - это важный показатель нашего уровня обслуживания, показывающий, прибыла ли отправка к запрошенному времени доставки.Понимание данных в этих столбцах помогает нам выявлять узкие места в процессе отправки и принимать корректирующие меры для улучшения нашей доставочной производительности."""input_question = "Сколько отправлений было задержано в первые семь дней мая?"

💡 Наблюдение: Контекст – это общая презентация роли менеджера контрольной башни и содержимого базы данных.

[Блок 2]: Агент пишет запрос и предоставляет неправильный ответ.

[Блок 2]: Запрос к базе данных и предоставление ответа — (Изображение от автора)
Тест 2: Целевой результат (слева) / Результат теста (справа) — (Изображение от автора)

👎 Агент лучше понимает промежуточные флаги, но все равно пропускает основной момент.

Это определение отсрочки отправки не логично, но не соответствует операционной реальности.

💡 Наблюдение: Отправка может быть вовремя, даже если у нее один или несколько флагов на нуле. Только флаг ‘On_Time_Delivery’ может определить, является ли отправка задержанной.

Определение временных отсечек, связанных с флагами — (Изображение от автора)

🙋‍♀️ Для справедливости перед агентом это не определение, которое кто-то может легко догадаться.

Поэтому, вероятно, мне следует явно указать определение ‘задержанной отправки’ в контексте.

Тест 3: Шаблон запроса с улучшенным контекстом

Я улучшил контекст с дополнительным предложением.

‘Отправка считается задержанной, если значение ‘On_Time_Delivery’ равно false.’

И, как и ожидалось, результат хороший.

[Блок 2]: Обращение к базе данных и предоставление ответа — (Изображение автора)

👋 Агент правильно использовал флаг для определения задержанных отправлений.

Что, если мы запросим передовой анализ?

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

Отправленные отправления (верх: вовремя, низ: опоздание) — (Изображение автора)

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

В этой компании код причины определяется списком всех промежуточных флагов, равных false.

Например, если отправка задержана:

  1. Значение ‘On_Time_Delivery’ равно false
  2. Значения ‘Transmission_OnTime’ и ‘Loading_OnTime’ равны false.
  3. Код причины тогда будет ‘Transmission_OnTime, Loading_OnTime’.

Тест 4: Расширенный анализ с улучшенным контекстом

Добавим еще одну утверждение.

Код причины задержки отправки определяется списком всех флагов, равных 0 для данной отправки.

Таким образом, я могу вызвать агента с новым вопросом:

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

К сожалению, агент не смог правильно определить код причины.

[Блок 2]: Обращение к базе данных и предоставление ответа — (Изображение автора)

После нескольких итераций я обнаружил, что агенту нужно некоторое руководство.

Следовательно, я пересмотрел вопрос

Пожалуйста, создайте столбец ‘Reason_Code’ на основе данного определения. Затем предоставьте общее количество задержанных отправок в первые семь дней мая и разделение по коду причины.

[Блок 2]: Обращение к базе данных и предоставление ответа — (Изображение автора)

Теперь вывод соответствует определению причины и содержит полный анализ причин задержки доставки.

Можем ли мы использовать этот вывод для отправки отчета по электронной почте?

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

Финальное тестирование: Создание цепочки для написания отчета по электронной почте

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

  • Агент 1: Агент SQL-запроса. Этот агент интерпретирует вопрос пользователя, формулирует SQL-запрос и извлекает данные из базы данных.
  • Агент 2: Агент составления электронного письма. Этот агент берет обработанные данные от Агента SQL-запроса и составляет осмысленное и информативное электронное письмо.

Мы попросили Агента 2 написать электронное письмо от моего имени (Самир Саци, руководитель контрольной башни) операционному директору Джею Пити.

[Блок 3]: Использование вывода Агента 1 для написания электронного письма — (Изображение автора)

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

[Блок 4] Вывод письма — (Изображение автора)

Выводом является электронное письмо, подводящее итоги результатов запроса

  • Агент включает дополнительный анализ перед завершением письма.
  • Тон формальный и соответствует контексту управления логистическими операциями.

Вывод можно использовать для автоматической отправки электронной почты с помощью библиотеки SMTP Python.

Пример здесь,

Автоматизировать распределение операционных отчетов в HTML-письмах с помощью Python

Автоматизировать распределение операционных отчетов цепи поставок с визуализацией в HTML-письмах с помощью Python.

towardsdatascience.com

💡 Что я узнал?

Этой простой эксперимент с агентами LangChain SQL научил меня, что…

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

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

📝Дополнительный комментарий: Я был довольно удивлен, что использовал Chat GPT-4, который оказал замечательную поддержку, чтобы помочь мне улучшить контекст шаблона запроса, который я использовал с его «младшим братом» GPT-3.5 Turbo.

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

LLMs определяют будущее поставочной цепи

Простое «доказательство концепции»

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

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

Агенты LangChain, связанные с несколькими продуктами данных — (Изображение автора)

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

Пользователи не используют наши панели инструментов. Почему?

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

Продолжение разработки прототипа

Завершение этих начальных испытаний дает весьма положительные результаты.

Однако, у меня все еще есть некоторые тесты для выполнения перед окончательным завершением данного прототипа

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

Я бы не развертывала его в производство без пользовательских тестов приемки, чтобы узнать, какие вопросы пользователи будут задавать (и следить за поведением агента).

Я поделюсь своими будущими экспериментами в будущих статьях, не стесняйтесь подписываться на меня в VoAGI, если вас это интересует.

Поиск широких применений в снабжении

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

Я жажду исследовать другие применения LLM в области аналитики снабжения.

Среди них интеграция LLM с моделями оптимизации:

  • 👬📈 Цифровые близнецы поставочной цепиПрименение: Агент поможет пользователям запускать симуляции с использованием сценариев, сформулированных на естественных языках. (Пользователи могут спрашивать: “Что, если мы переместим центральный склад в Италию?”)

Что такое цифровой близнец поставочной цепи?

Исследуйте цифровые близнецы с помощью Python: моделирование сетей поставочной цепи, улучшение принятия решений и оптимизация операций.

towardsdatascience.com

  • 🔗🍃 Устойчивое проектирование сети поставокПрименение: Пользователи могли бы создавать модели оптимизации, формулируя цели и ограничения на естественных языках. (Пользователи могут спрашивать: “Мы хотим создать сеть фабрик для доставки на французский рынок, удовлетворяющую спросу при минимизации выбросов CO2.”)

Создайте веб-приложение для оптимизации устойчивой поставочной цепи

Помогите вашей организации объединить устойчивое закупочное снабжение и оптимизацию поставочной цепи для снижения как затрат, так и экологического воздействия…

towardsdatascience.com

  • 🏭🍃 Устойчивое снабжение: выбор лучших поставщиковПрименение: Команды по закупкам могут формулировать свои зеленые инициативы на естественных языках и видеть их влияние на затраты. (Пользователи могут спрашивать: “Мы хотели бы оценить стоимость выбора только углеродно-нейтральных фабрик для поставки этого артикула.”)

Что такое устойчивое снабжение?

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

s-saci95.medium.com

Мы также можем использовать нашего агента для улучшения качества данных или поддержки аудита данных, используемых для стратегических отчетов:

Что такое отчетность ESG?

Использование аналитики данных для всесторонней и эффективной отчетности об экологических, социальных и корпоративных аспектах деятельности компании

towardsdatascience.com

  • 📉✅ Что такое качество данных?Применение: Используйте нашего агента для проверки или поддержки методик, обеспечивающих точность, согласованность и полноту данных. (Пользователи могут спрашивать: “Можете ли вы проанализировать количество доставленных в прошлом году отправок с пропущенным статусом?”)

Что такое качество данных?

Изучите методологии, гарантирующие точность, согласованность и полноту данных по цепям поставок

towardsdatascience.com

Каждая из этих сфер имеет огромный потенциал для использования генеративного искусственного интеллекта в развертывании решений “аналитика-как-сервис” в вашей компании.

Если вы разделяете это энтузиазм, не стесняйтесь давать свои предложения в разделе комментариев!

Обо мне

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

Если вас интересуют аналитика данных и цепи поставок, загляните на мой веб-сайт

Самир Саци | Data Science & Productivity

Технический блог, фокусирующийся на Data Science, личной продуктивности, автоматизации, исследованиях операций и устойчивом развитии…

samirsaci.com

💡 Подписывайтесь на меня в ВоАГИ, чтобы получать больше статей, связанных с аналитикой поставок, устойчивостью и производительностью.