Кирилл Филипенко, Автор в Академия Selectel

LLM агент — это программная система на основе большой языковой модели, способная самостоятельно решать, какие действия предпринимать для достижения поставленной цели. Иными словами, такой агент действует не по жестко запрограммированному сценарию, а сам выбирает последовательность шагов на основе ответа модели. Например, LLM-агент может решить, какой из доступных инструментов ему вызвать, когда выдать ответ или как разбить сложную задачу на простые подзадачи. В последние годы появились проекты вроде AutoGPT и аналогичные автономные сервисы, которые демонстрируют потенциал LLM-агентов в решении нетривиальных задач. Чтобы понять, как это работает на уровне системы, важно разобраться, из чего состоит подобный агент. Разберем его внутреннюю архитектуру: как он планирует свои действия, как хранит информацию и как использует внешние инструменты. Планирование: chain-of-thought, ReAct, tree-of-thoughts Планирование действий — ключевой компонент LLM-агента. Оно позволяет модели разбивать сложные задачи на цепочки рассуждений и шагов. Простой подход — так называемый Chain-of-Thought (CoT) или цепочка мыслей. В рамках него модель побуждают генерировать последовательность промежуточных рассуждений перед финальным ответом. Исследования показали, что формирование явной цепочки рассуждений заметно улучшает способности LLM решать сложные задачи. Например, если попросить модель пошагово объяснить ход решения математической задачи, точность ответа возрастает. Chain-of-Thought prompting фактически заставляет модель планировать: идти к решению не напрямую, а через серию логических шагов. Однако одна только цепочка мыслей не оставляет агенту возможности действовать во внешней среде. Здесь появляется парадигма ReAct (Reason + Act) — сочетание рассуждений и действий. Архитектура ReAct предполагает, что на каждом шаге агент сначала думает (Reasoning), а затем может выполнить действие (Act), получая обратную связь из окружения. Эти шаги чередуются: мысль → действие → наблюдение → новая мысль и так далее. Такой цикл продолжается, пока агент не соберет достаточно информации для ответа. Действия могут быть разными — вызов инструмента (поиска, калькулятора или чего-то еще) или просто переход к ответу. Важно, что ReAct объединяет два аспекта: модель разрабатывает план решения в процессе (chain-of-thought) и одновременно применяет действия во внешней среде для сбора данных. Практика показывает, что эта связка заметно эффективнее, чем только рассуждение или только последовательные вызовы инструментов по отдельности. Кроме того, она делает ход решения более прозрачным: в логах агента видно, какие шаги он предпринял. Это улучшает интерпретируемость и упрощает отладку, так как можно увидеть траекторию решения, понятную человеку. Рассмотрим упрощенный пример ReAct-цикла с использованием фреймворка LangChain. Предположим, у нас есть два инструмента — калькулятор и веб-поиск. Агента попросили: «Посчитай, сколько будет 6 в степени 13, а результат переведи на английский». Ниже приведен фрагмент кода, демонстрирующий настройку такого агента и его работу. В режиме verboseTrue LangChain выведет детальный лог размышлений агента. В рамках нашего примера он будет выглядеть так. Этот процесс иллюстрирует, как ReAct-агент чередует рассуждения с действиями. Языковая модель сама решает, какой инструмент вызвать и что делать дальше, основываясь на предыдущем наблюдении. Фреймворки (как LangChain) автоматически подставляют последние мысли и наблюдения в контекст модели на каждом шаге, реализуя этот цикл. Еще один продвинутый подход к планированию — Tree-of-Thoughts (ToT), или дерево мыслей. Он развивает идею chain-of-thought, позволяя модели разветвлять ход рассуждений и исследовать несколько вариантов решений параллельно, оценивая их. В отличие от linear chain-of-thought, здесь агент может на каком-то шаге разветвлять свои мысли. Так он пробует разные пути, а затем выбирает самый перспективный. Это похоже на поиск решений по дереву: модель может прикинуть несколько промежуточных шагов вперед, откатиться и пойти другим путем, если по ее наблюдениям текущая ветвь не принесет результата. Исследователи сообщают о впечатляющих успехах этого метода. Возможно, вы слышали про головоломку «двадцать четыре». В рамках нее нужно произвести любые арифметические действия с четырьмя числами, чтобы в результате получилось 24. Обычный GPT-4 с цепочкой мыслей решает эту головоломку лишь в 4% случаев, тогда как метод tree-of-thoughts — в 74%. Такой скачок демонстрирует силу продвинутого планирования. Хотя ToT пока больше в области исследований, идеи дерева мыслей постепенно внедряются в агентные системы, когда требуется стратегический поиск решения. Таким образом, модуль планирования LLM-агента может быть реализован с разной сложностью — от простого линейного размышления (CoT) до итеративного цикла с действиями (ReAct) и даже разветвленного поиска (ToT). В любом случае цель одна — позволить модели самостоятельно разбить задачу на шаги и выполнить их, максимально эффективно используя свои возможности. Память: краткосрочная и долгосрочная В процессе работы агент генерирует и потребляет большое количество информации: это и история диалога, и результаты вызова инструментов, и промежуточные выводы. Чтобы не потерять важное, ему требуется память — механизм хранения данных вне кратковременного внимания модели. Различают два основных типа памяти агента. Краткосрочная память — охватывает контекст внутри одной сессии (диалога, задачи). В нее входит история сообщений с пользователем, недавние наблюдения от инструментов, промежуточные выводы. Эта память ограничена текущим контекстным окном LLM: модель «помнит» лишь то, что передано ей в промпт. В простейшем случае это весь диалог целиком. Например, ChatGPT помнит несколько последних сообщений. В более продвинутом случае используются разные стратегии: важные части контекста могут сохраняться, неважные — отбрасываться или сжиматься. Фреймворки сохраняют состояние диалога как часть состояния агента (state), которое можно приостановить и продолжить (например, LangChain сохраняет state между запусками с помощью checkpoint). Долгосрочная память — общее хранилище знаний между сессиями. Это может быть база фактов, которые агент узнал, или результаты, к которым он может обращаться в будущем, даже в новом разговоре. Долгосрочная память обычно реализуется через внешние хранилища — базы данных, векторы в embedding-хранилище, файлы. LangChain. Например, она предлагает интерфейс Stores для сохранения и поиска таких воспоминаний. Оба вида памяти дополняют друг друга. Краткосрочная обеспечивает связность текущего разговора и локального плана, а долгосрочная предоставляет агенту ощущение опыта — словно он знает о прошлом или о вещах вне текущего контекста. Однако реализация памяти сталкивается с проблемами. Главный вызов — ограниченная длина контекстного окна современных LLM. Если диалог или задача слишком длинные, весь соответствующий текст может не поместиться в промпт. Даже если поместится, это способно повлиять на качество модели. Поэтому инженеры разработали следующие стратегии управления памятью агента. Очистка контекста — удаление наименее релевантных или устаревших частей истории. Например, можно оставлять только последние части сообщений или краткое резюме старых сообщений. Сжатие (суммаризация) — преобразование длинных участков диалога в более короткое резюме, которое сохраняет суть беседы. Извлечение по запросу — хранение деталей диалогов или данных в векторном хранилище и выбор релевантных кусочков в контекст при необходимости (подход Retrieval-Augmented Generation, по сути долгосрочная память на основе поиска). Применяя эти техники, агент поддерживает баланс между объемом памяти и качеством работы. Например, если список сообщений больше определенного размера, можно превращать старые сообщения в резюме. Тогда модель не забудет, о чем шла речь, но и не станет перечитывать каждое слово прошлой беседы. Важно отметить, что память — это не магические знания модели. Ее нужно явно реализовывать, читать и писать в нее, управляя входами LLM. Без долгосрочной памяти агент ограничен только тем, что помещается в промпт, и забывает все старое, как только сессия заканчивается. Инструменты и вызов функций (function calling, плагины) Один из самых впечатляющих навыков LLM-агентов — это способность взаимодействовать с внешним миром: вызывать API, запускать коды, искать информацию онлайн, пользоваться сторонними сервисами. Для этого агенту предоставляются инструменты (tools) — специально описанные функции, доступные для вызова. Языковая модель на выходе может выдавать не только текст с ответом пользователю, но и специальную команду на вызов инструмента. Эту команду программа-инфраструктура затем исполнит и передаст результат обратно модели. Такой цикл мы отчасти рассмотрели выше. В 2023 году компания OpenAI официально представила механизм function calling — вызов функций из ChatGPT. С его помощью разработчики могут зарегистрировать в модели набор доступных функций с их именами, описаниями и JSON-схемами параметров. Модель GPT-4 или GPT-3.5 после получения пользовательского запроса сама решает, нужна ли для ответа какая-либо функция. Если да, она возвращает специальный ответ с JSON, заполняя аргументы для вызова. Например, если пользователь спрашивает: «Какая погода в Париже?», модель может вернуть не обычный текст, а JSON вроде {"name": "get_current_weather", "arguments": {"location": "Paris", "unit": "celsius"}}. Приложение распознает, что нужно вызвать функцию get_current_weather, вызывает ее (например, через API прогноза погоды) и затем передает модели результат — например, {"temperature": "15°C", ...}. После этого модель уже отвечает пользователю с учетом полученных данных. Такой подход надежнее, чем разбор команды из обычного текста: JSON-ответ строго структурирован под функцию, и разработчик гарантированно получит параметры. По сути, function calling — это мост между возможностями GPT и внешними инструментами. Модель учат генерировать не только слова, но и вызовы функций. Появление function calling открывает множество возможностей. Перечислю те, которые приводит нам OpenAI. Создание чат-ботов, которые отвечают, обращаясь к внешним инструментам (подобно плагинам ChatGPT). Например, вызывают функцию send_email по просьбе пользователя отправить письмо, или get_current_weather по запросу погоды. Преобразование произвольного запроса пользователя в последовательность вызовов API или баз данных — фактически, генерация кода по описанию. Например, запрос «Выбери 10 лучших клиентов за последний месяц» может быть автоматически превращен в SQL-запрос через функцию вроде sql_query. Извлечение структурированных данных из текста. Модель может сама разобрать текст (статью, документ) и вернуть JSON-объект по заданной схеме, заполнив его извлеченной информацией. Таким образом, LLM получает роль оркестратора, способного вызывать разные утилиты для выполнения задачи. Такой подход ранее демонстрировался в прототипах. Например, проект LangChain имел похожую функциональность, в рамках которой модель выбирает и вызывает Tool из списка, как я продемонстрировал выше. Теперь это встроено на уровне API модели. Стоит упомянуть и плагины ChatGPT. Плагин — это, по сути, внешний инструмент со стандартизированным интерфейсом, который может подключаться к ChatGPT. Во время использования плагина модель понимает, что у нее есть дополнительная функция, и может ей пользоваться. Официально плагины определялись как инструменты, помогающие языковым моделям получать актуальную информацию, запускать вычисления или обращаться к сервисам. В 2023 году были представлены первые плагины (например, поиск по web, кодовый интерпретатор, плагин WolframAlpha для вычислений, интеграции с сервисами вроде Expedia, Zapier и др.). Технологически плагин похож на описанный function calling: модель получает в промпт описание, как и когда использовать тот или иной плагин, и возвращает вызов. На стороне ChatGPT это выглядит прозрачно: пользователь просит что-то забронировать — ChatGPT отвечает, что бронирует (в реальности вызывая через плагин API бронирования). Пример использования инструмента через function calling с Ollama. Предположим, мы хотим позволить нашему агенту пользоваться калькулятором для вычислений. С помощью OpenAI API можем описать функцию и передать ее в параметры вызова: Модель поймет, что для ответа нужен калькулятор, и вернет специальный ответ function_call с именем calculate и аргументом "(2+2)*3". Теперь наше приложение должно перехватить это и действительно выполнить функцию calculate. Допустим, у нас она реализована просто через eval (небезопасно в общем случае, но для примера подойдет). Итого, на выходе из нашего скрипта мы получим следующее: Как вы можете заметить, взаимодействие состоит их нескольких фаз: модель запрашивает функцию → мы отвечаем результатом → модель выдает итоговый ответ. В реальных сценариях агент может иметь десятки функций: например, калькулятор, поиск информации, отправка запроса в базу, генерация изображения и т.д. С ростом числа инструментов особенно важно планирование: модель должна решать, какой инструмент сейчас уместен (и вообще требуется ли инструмент для данной задачи). Современные агенты способны на лету выбирать нужное: скажем, сначала выполнить поиск, потом на основе найденного что-то вычислить, потом отформатировать результат (так, например, работает с инструментами модель o3 от OpenA). Интеграция инструментов расширяет возможности LLM-агента далеко за рамки «просто поговорить». Он становится интерфейсом, который на естественном языке принимает задачу, а затем разбивает ее на конкретные операции с помощью кода и сервисов. Здесь кроется большая сила: используя LLM как «мозг», можно объединить множество узкоспециализированных систем (баз данных, API, скриптовых инструментов) в единый конвейер решения задачи, управляемый гибкими инструкциями. Конечно, подключение внешних инструментов несет и риски: каждый вызов — потенциальная точка отказа (ошибка сети, неверный ответ API, непредвиденный ввод). Агенты обретают новые уязвимости: например, если не фильтровать выход веб-сервиса, модель может сбиться или получить вредоносные данные. Поэтому разработчики прорабатывают аспекты безопасности (OpenAI отдельно отметила, что данные от инструментов надо считать недоверенными и проверять, прежде чем слепо передавать модели). Заключение LLM-агенты сочетают в себе возможности больших языковых моделей и классические методы программного управления. Их архитектура включает: планировщик — модель, ведущая диалог сама с собой и принимающая решения о шагах; память для хранения информации между шагами и сессиями; набор инструментов — функций, расширяющих возможности модели. В совокупности получается гибкая система, способная на сложные многошаговые операции — от поиска и агрегирования данных до выполнения пользовательских команд в реальном мире. Однако важно помнить, что LLM-агент – не магический «искусственный интеллект, решающий все сам». Это всего лишь умелая комбинация заранее разработанных компонентов. Ограничения базовой модели (неточности, галлюцинации, ограниченный контекст) никуда не исчезают — агент лишь помогает их сгладить, используя обходные пути вроде внешней памяти или вызова проверенных инструментов. Тем не менее, правильно спроектированные LLM-агенты уже сейчас показывают впечатляющие результаты, автоматизируя задачи, которые ранее требовали человеческого вмешательства. Их внутренняя кухня — отличный пример того, как инженерный подход раскрывает потенциал больших моделей. Это не волшебство, а новый строительный блок для создания интеллектуальных приложений. В следующей статье мы рассмотрим, как такие агенты применяются на практике, каких успехов удалось добиться и с какими ограничениями все еще приходится сталкиваться. До встречи во второй части!