Вокруг LLM (Large Language Models) идёт большой ажиотаж, но помимо шумихи и обещаний, языковые модели в последнее время действительно находят свою нишу, где их можно эффективно применять, а также всё прочнее в нашу жизнь входят агенты. В статье я бы хотел поделиться опытом реализации проектов с LLM, перспективами развития, небольшим обзором фреймворков и некоторыми инсайтами по их применению. Те, кому может быть интересен подобный опыт и для кого языковые модели ещё не превратились в рутину, добро пожаловать под кат :)
Кратко вспомним важные аспекты работы с LLM и ограничения, которые из них вытекают:
LLM относятся к генеративным моделям, т.е. выдают текст при условиях входной последовательности (промта). Поэтому, например, задачи векторного поиска, прогнозирования, рекомендаций и т. п. решаются совсем другими подходами.
LLM прежде всего работают с текстами (несмотря на развитие мультимодальных моделей, их качество пока отстаёт от результатов LLM). Следовательно, мы их можем применять в бизнес процессах, где происходит работа с текстовой информацией, либо той, которая может быть переведена в текст (например, аудио).
LLM склонны фантазировать (или галлюцинировать). Отсюда следует, что в задачах, которые мы хотим решать с помощью LLM, должны быть чёткие критерии, по которым мы сможем оценить общий результат (посчитать бизнес метрики, получить обратную связь для возможности корректировки пайплайна, входных данных, промта и т. п.). И также должен быть понятный общий алгоритм действий, необходимых для достижения результата, который можно сформулировать в виде инструкции и обернуть в промт. В идеале это задачи, которые можно декомпозировать на более мелкие, атомарные. Таким образом, появляется возможность контролировать промежуточные результаты в узловых точках и отслеживать общее направление "мыслительного процесса" LLM, вовремя его корректируя.
Теперь подробнее опишу кейсы, где уже успешно получилось применить LLM, и какие ниши ещё свободны (в которых применение LLM пока не так популярно), но, вероятно, будут заняты уже скоро. Достаточно явно выделяются три направления, в которых можно применять LLM:
в поиске;
для обработки и агрегирования текста (и информации, которую можно перевести в текст);
для генерации текста.
Применение LLM в поиске
В первую очередь это, конечно, RAG (Retrieved Augmented Generation). По сути это связка поиска по фрагментам информации с ответом на вопрос пользователя и генерация ответа на основе найденных фрагментов. RAG полезен, когда у вас есть какая-то база знаний: чтобы пользователю не копаться в ней самостоятельно, он задаёт вопрос в свободной форме, на который получает ответ. Популярными кейсами, в которых RAG может упростить компании жизнь, являются:
Автоматизация технической поддержки, позволяющая отвечать LLM на частые вопросы, (в то время как сложные и нестандартные уже переадресуются специалистам).
Поиск документов по внутренней вики компании, часто реализуется в виде бота, который просят выдать заявление на отпуск, увольнение и т. п. Стандартные вопросы, которые долго искать самостоятельно по Wiki.
Развитие RAG в качестве неотъемлемой части современных поисковиков. Часто у пользователя в поисковом запросе содержится не запрос формата "обзор фотоаппаратов за последние 5 лет", а конкретный вопрос типа: "лучший фотоаппарат такого-то года". И если задан вопрос, на который существует ответ, то его можно найти и выдать его пользователю одной строчкой, сократив таким образом время поиска. В последнее время появляется всё больше подобных решений — яндекс нейро, perplexity, ChatGPT search и т. д.
Диалоговый ассистент как альтернатива поиску. Есть ряд случаев (например, на маркетплейсах), когда диалог с ботом может быть не менее эффективным для поиска, поскольку, возможность взаимодействия позволяет уточнить параметры запроса, выдать результат в красивой форме и на основании ответов пользователя скорректировать результат выдачи.
Применение LLM для обработки и агрегирования текста
Валидация, проверка и разметка данных. Используя LLM, можно автоматически писать код для тестов и проверок данных, либо результатов вычислений на основании требований заказчика. LLM можно просить устанавливать пороги (в задачах, где фигурируют пороги, которые выбираются эмпирически на основании природы данных), обнаруживать дубликаты, аномалии, выбросы (статья с хорошим примером). И конечно, LLM можно эффективно использовать при разметке данных (например: в задачах классификации вместо того чтобы прибегать к разметке асессоров, можно просить LLM выполнить эту работу).
Дедупликация и определение характеристик, матчинг товаров. В базовой постановке дедупликация — это задача про то, как разгрести и структурировать кучу «хлама» (накопившиеся номенклатурные записи в БД, названия товаров в маркетплейсах, любой список сущностей). Поэтому задача и её вариации встречаются достаточно часто и включает следующие шаги:
разбить на какие-то осмысленные группы/категории;
пройтись по списку всех сущностей и для каждой определить категорию;
для каждой категории определить присущие ей свойства и для каждой сущности, принадлежащей этой категории, заполнить эти свойства;
начальный поиск схожих сущностей удобно искать при помощи эмбеддингов и затем кластеризовать, а дальше всё это надо «осмыслить» и подкорректировать, и в этом уже может помочь LLM;
валидация кластеров (исключение выбросов, разделение/объединение похожих кластеров);
составление описаний и названий кластеров для дальнейшей проверки людьми;
определение характеристик кластера и их валидация;
заполнение определённых ранее характеристик для каждой сущности.
На определённых этапах возможно подключение специалистов для контроля качества, но дюжую часть работ, как показывает практика, можно закрыть LLM. Частой разновидностью этой задачи является матчинг товаров (обычно на маркетплейсах), когда нам необходимо сопоставить сущности, найти аналоги, дубликаты.
Обработка текста и аудио. Различная обработка текста. Если в бизнес-процессе появляется аудио (запись звонков, бизнес встреч, аудиторские проверки, различные интервью), то эти аудио транскрибируется, а затем LLM также обрабатывает их как текст:
составление summary по тексту;
ответы на вопросы по тексту;
заполнение протоколов встреч, либо проверка таких протоколов;
проверка отчётности, подсвечивание потенциальных мест интереса.
Агрегирование информации по различным источникам — это как раз про то, чтобы натравить LLM на просмотр ленты Twitter, чтобы на выходе получить сводку самого интересного, если нет времени копаться во всём самому. Этот приём также можно экстраполировать на анализ различных новостных, научных источников информации.
Работа с резюме. Это пример успешного кейса, вобравшего в себя несколько пунктов, изложенных выше. В современном мире море резюме. Одни заинтересованы в том, чтобы отобрать кандидатов на позицию, другие заинтересованы в том, чтобы успешно себя «продать». И есть ещё третьи — целые компании по хантингу, которые хотят соединить первых и вторых. Соответственно, наш проект был связан с посредниками и в рамках него LLM нам может помочь автоматизировать следующие бизнес процессы:
проверка резюме на соответветствие требованиям вакансии;
составление summary по резюме, проверка на красные флаги;
рекомендации по улучшению резюме под конкретную вакансию (речь идёт не о подделке резюме, а о том, чтобы лучше расписать опыт, необходимый для конкретного проекта/вакансии).
Применение LLM для генерации
Генерация кода и медиаматериала. Несколько компаний уже заняли эту нишу и встроили свои решения в известные фреймворки, но на задачу можно также посмотреть шире: генерация любого контента — презентации, посты, постеры, отчёты, протоколы, деловые письма. Если этот контент является шаблонным, как конструкции кода, то его можно довольно успешно дополнять, стилизовать. Важно помнить, что автодополнение не будет предлагать принципиально нового, скорее популярные сценарии и варианты окончания. Причём, если мы говорим о генерации медиаматериалов, например, презентаций, то на арену как раз выходят мультимодальные модели. Эта тенденция способствует развитию подобного рода инструментов.
Планировщик задач — после груминга/брейншторма по наброску тикетов или роудмапа LLM может дополнить, детализировать, расписать эти задачи.
Помощник оформления документов — поиск необходимого шаблона документа и его заполнение, чтобы сотруднику осталось только подписать: если в систему подтянуть личную информацию пользователя, чтобы она проставлялась автоматически без ввода вручную, это сильно сокращает время на заполнение.
Заканчивая этот список хочется отметить два наиболее успешных направления, связанных с большими языковыми моделями. Это кодогенерация и саппорт (служба технической поддержки). Кодогенерация — поскольку код аналогичен человеческому языку, но в нём более простые и стандартизированные конструкции, отсутствует двусмысленность, просто проверить синтаксис и возможность компилирования, прогнать и получить обратную связь от среды, в которой запускается этот код. Саппорт – поскольку этот процесс можно разложить на простые этапы, которые легко автоматизируются.
Итак, мы обсудили ограничения больших языковых моделей (это в первую очередь работа с текстовым доменом, возможности галлюцинаций) и направления их применения. Также мы привели примеры прикладных задач, решаемых с помощью LLM. Но что если перед нами более комплексная задача, содержащая подзадачи (то есть решаемая не однократным действием, а в несколько шагов), и для решения которой необходимо привлечение дополнительной информации из разных источников? Тогда нам понадобится система, способная к планированию и оценке своих действий, а также включающая в себя каналы взаимодействия с внешним миром и возможности кооперации с другими подобными системами (ведь одна голова хорошо, а две, как известно, лучше).
Агенты
Мир стал двигаться к агентным системам, которые становятся всё популярнее. На какой стадии развития они сейчас? Пока что на стадии начала внедрения, но мир уже осознал их возможности и вкладывается в них все больше. Одним из подтверждений этому является недавний релиз OpenAI Agents SDK и агентов, подобных Computer-Using Agent.
Агентная система — это та, в в которой языковые модели динамически управляют собственными вызовами и используемыми инструментами, контролируя выполнение решаемой задачи (в отличие от LLM, которой мы напрямую даём указания по решению задачи). Чтобы понять сильные стороны агентных систем и где их можно эффективно применять, давайте посмотрим, где проще обойтись без них. Множество задач, которые интуитивно хочется решить агентами, на деле можно дешевле и быстрее решить просто с использованием LLM, и вот почему:
Агенты = дополнительные затраты на планирование действий, оценку результата. Всё это скажется в количестве запросов и стоимости вашего workflow;
Агенты это дополнительная обёртка над LLM, реализующая более сложную гибкую и разветвлённую неоднозначную логику. Если по характеру задачи понятен путь её решения, он просто, прозрачен и ясны критерии оценки (которые можно заложить в промт или цепочку промтов), то быстрее и дешевле разработка решения без использования агентов.
Агентов лучше избегать, когда при работе LLM задача решается линейно (без ветвления) и нет необходимости привлечения дополнительной информации. Например, обработать текст, затем достать именованные сущности, заполнить ими шаблон или анкету. Подобный сценарий можно решить просто цепочкой запросов.
Тогда как же понять, что пришло время использовать агентов? Здесь работает старый принцип – начинать с простого и усложнять по мере необходимости, останавливаясь тогда, когда будет достигнуто приемлемое качество. Усложнять систему можно следующим образом (подробно эти приёмы описаны в оригинальной статье: Building effective agents от Anthropic, здесь привожу выжимку с дополнениями от себя):
Цепочка промтов (Prompt chaining). Когда задача становится более сложной, декомпозируем её на этапы. Что получаем: на каждом этапе LLM выполняет более простое действие, результаты промежуточных этапов можно валидировать – появляется возможность лучшего контроля и растёт точность. Что теряем: увеличивается количество запросов и общее время решения задачи.
Маршрутизация запросов (Routing). Приём работает, когда в общей задаче можно выделить частые сценарии под определённые входные данные и для них написать отдельные промты. Далее (отдельной моделью либо еще одним запросом в LLM) происходит классификация входного потока данных и решение персонализированным промтом. Что получаем: рост в точности и возможность более гибкой обработки.
Параллелизация (Parallelization). Используется, если структура задачи позволяет распараллелить какие-то этапы и затем агрегировать их результат, а также в тех задачах, где необходим множественный вызов LLM с однотипным запросом для повышения достоверности и подбора параметров (например, оценка кода на уязвимости либо подбор трешхолдов)
Использование оркестратора (Worker orchestrator). LLM динамически разбивает задачу на подзадачи (также решаемые LLM, сторонними сервисами либо просто скриптами), делегирует их и обрабатывает результаты. Отличие от параллелизации в том, что мы не можем заранее сказать, какие подзадачи потребуются, либо с какими параметрами происходит их вызов. Таким образом, ключевая особенность, которую привносит оркестратор состоит в гибкости — подзадачи не задаются заранее, а определяются организатором на основе входных данных. И этот механизм нас уже вплотную приближает к агентам.
Использование оценщика-оптимизатора (Evaluator-optimizer). Когда у нас есть чёткие критерии качества, можно использовать LLM для оценки результатов и повторного запуска задачи в цикле, пока критерии не будут удовлетворены. Дополнительно на каждой итерации мы просим сообщить LLM, что было не так, чтобы в следующей итерации улучшить этот аспект. Дисклаймер: при практической реализации критически важно также выработать 1) критерии останова и 2) правильное логирование (справедливо и для всех пунктов выше), чтобы а) не уйти в бесконечный цикл и б) обеспечить базу для дальнейшего совершенствования системы.
Возможно, вы уже пришли к чему-то из описанного выше и использовали в своих пайплайнах. Так или иначе, при постепенном добавлении описанных приемов в рабочий процесс, LLM в своей работе становится более автономной и в какой-то момент переходит в агента. Граница размыта, но вероятно можно выделить следующие критерии, определяющие LLM агента и отличающие его от просто продвинутого использования LLM:
понимание сложных входных данных, зачастую неоднородных (например: агент собирает и обрабатывает информацию с сайта, которая может содержать текст, таблицы, аудио и ссылки на сторонние ресурсы);
умение рассуждать и планировать на основе полученных данных и результата совершённых действий;
рефлексия — способность анализировать результат собственных действий и находить в них ошибки;
планирование и рассуждение — умение декомпозировать задачи на подзадачи, строить оптимальный план по их выполнению;
понимание и умение использовать инструментарий для взаимодействия с внешней средой, в том числе взаимодействовать с другими агентами;
наличие базовых механизмов защиты от сбоев и ошибок в процессе работы (когда агент может зайти в бесконечный цикл, либо результат выполнения его действий поломает систему).
Таким образом, глобально в агентах возникает потребность в момент, когда в задаче невозможно предсказать необходимое количество шагов, и где вы не можете жестко задать фиксированный путь решения, точно определить дополнительные инструменты, которые понадобятся.
Перекладывая все больше и более сложных задач на языковые модели, мы движемся к развитию агентов, что повлечёт за собой формирование среды, в которой они будут функционировать (инфраструктура, используемые ими инструменты для взаимодействия с внешней средой, механизмы безопасности). Остановимся теперь на том, что в данный момент предлагает рынок.
Вероятно, самыми популярными на сегодня являются LlamaIndex, LangGraph, Swarm, (который эволюционировал в the OpenAI Agents SDK), CrewAI, Semantic Kernel, AutoGen от Microsoft и Smolagents от Hugging Face (хотя последних двух не нашёл на AI Engineering Landscape). Кратко об идеологии и сильных сторонах каждого фреймворка (по убыванию популярности в зависимости от количества звёзд на github).
LangGraph (часто используется в связке с Langfuse для логирования и версионирования результатов) использует под капотом LangChain и графы: основная идея здесь в использовании действий агента как узлов в направленном графе. Таким образом, решение задачи разбивается на переходы между узлами (действиями агентов). Подход позволяет хорошо декомпозировать задачи, распараллеливать процессы, внедрять пользовательскую логику на определённых этапах и контролировать результат в каждом узле. За счёт этого хорошо подходит для комплексных бизнес процессов, в которых необходимо прозрачность и контроль workflow.
Open AI Agents SDK - пока не самый популярный, но многообещающий набор инструментов от OpenAI. Он предлагает специализированную среду выполнения и простой API для назначения ролей, инструментов и триггеров, что упрощает оркестрацию агентов. Проект на ранней стадии развития, но уже успел стать популярным. Помимо того, что это решение от одного из лидеров индустрии, его преимуществом является нативная интеграция со всеми продуктами Open AI.
Crew AI делает ставку на идею коллаборацию агентов для решения общей задачи. На практике здесь мы оперируем командами или даже контейнерами, содержащими набор агентов, каждый из которых имеет определенную роль или функцию. Соответственно, фреймворк для задач, в которых важна мультиагентность. Также преимуществами фреймфорка является достаточно простая конфигурация и возможность удобная работа с памятью и обработкой ошибок.
LlamaIndex изначально создавалась как RAG решение для работы с чат-ботами и большими наборами документов, которое со временем обросло возможностями для работы с агентами. Поэтому фреймфорк ориентирован на работу с данными различной природы и его сильной стороной являются возможности по работе локальными и внешними хранилищами, а также богатый набор инструментов, позволяющий индексировать данные, разбивать тексты на фрагменты и объединять LLM с базами знаний.
AutoGen и Semantic Kernel от Microsoft. Эти два продукта имеют разную историю, но двигаются к одной цели и, возможно, их ждёт слияние. AutoGen изначально задумывался как исследовательский проект от Microsoft Research, поэтому в нём заложены возможности для экспериментов. Semantic Kernel разрабатывался как production ready SDK, который интегрирует LLM и хранилища данных в приложения, позволяя создавать продуктовые решения с агентами. К достоинствам обоих следует отнести более широкую поддержку языков программирования C#, Python и Java и хорошие возможность по интеграции со всеми экосистемами продуктов Microsoft.
Smolagents с его красноречивым названием является минималистичным решением, ориентированным на код. Он хорош для сценариев, когда нужен небольшой автономный агент, который может вызывать библиотеки Python или выполнять быстрые вычисления без создания целой группы обеспечения доступности базы данных или мультиагентного потока взаимодействия. Таким образом, основные плюсы Smalagents в быстроте настройки и прототипировании.
Если преимущества каждого фреймворка и выбор для конкретной задачи сжать в упрощённую схему, то получится следующая картинка.
В приведённой схеме не до конца ясен выбор между одним агентом и несколькими. Отдельно взятый агент способен автономно решать специализированный круг задач (поскольку он ограничен заданными настройками, инструментами и способами взаимодействия со средой). Большие задачи могут быть эффективно решены мультиагентными системами (подобно тому как разноплановые задачи эффективно решаются специалистами разных профессий). Мультиагентность также позволяет распараллелить, масштабировать и дополнительно снять часть ошибок кросс проверкой агентами результатов друг друга. Более подробно нюансы каждого фреймворка раскрыты в этой статье.
Но говоря про агентов надо, всё же, сделать пару ремарок: как упоминалось выше, для их использования необходимо наличие определённой среды (инфраструктура, протоколы взаимодействия, механизмы контроля и безопасности и тд), на её формирование уйдёт время. А что можно ожидать от мира LLM в ближайшие месяцы, может быть, годы?
Продолжающееся развитие LLM, улучшение качества работы моделей из коробки. На этом фоне, скорее всего, будет происходить закат дообучения (из всего, что попадалось про дообучение, вот, пожалуй, самая интересная статья – Scaling Down to Scale Up: A Guide to Parameter-Efficient Fine-Tuning), поскольку, это большая и затратная процедура, содержащая много нюансов с подготовкой данных, конечной оценкой, с тем чтобы избежать галлюцинаций на выходе и т.п. С учётом растущего качества, большинство потребностей можно закрыть моделями из коробки. Помимо этого, переходным шагом будет обрастание моделей различным функционалом по взаимодействию с внешним миром и его сервисами. И тут еще хочется упомянуть одну полезную вещь, которую до сих пор не все используют: часто от LLM нам необходим ответ в строгом формате (например, распарсить какие-то поля из plain text в json, получить число в ответ на математическую задачу и т.п.). И тут нам на помощь приходит Structured output. Вот реализация в OpenAI, реализация в vLLM, Ollama. Вместо подбора специализированных промтов и кучи дополнительных проверок сильно упрощает жизнь!
За помощь с подготовкой статьи огромная благодарность Валерии Елпатьевской, а также всей команде ЦК Дата в Ланит, с которой удалось реализовать многие из описанных выше проектов.
Удачи нам всем в борьбе с машинами за должности в ИТ и да пребудем с вами сила!
