[ИА агент] ч.3. Начало выше ⤴️

➡️ Layer 2 - Оркестрация. Клеевой слой между ЛЛМ и нашей бизнес логикой.

Модель с горем пополам выбрали. Дальше нам нужен какой-то фреймворк, который будет жонглировать запросами в ЛЛМ.

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

Самые известные - это пожалуй LangGraph и его родительская экосистема LangChain.

LangChain - набор абстракций, либ и классов. Нужен чтобы быстро собирать приложения из “кирпичиков” (модели, промпты, парсеры, ретриверы, тулзы) и не писать с нуля. Топ для прототипирования и лёгких флоу.

Второй поразвесистее - LangGraph. Нужен, когда агент/воркфлоу нуждается в неком состоянии + переходах: ветвления, циклы, долгие процессы, возобновление после падений, human-in-the-loop, долговременная память и прочие плюшки, которые тут доступны уже из коробки.

У нас на проектах используются оба в равной степени успешности. Есть еще более специфичные RAG-направленные под поиск (Haystack, Semantic Kernel) и тд, но не будем распыляться.

Базовые "кирпичики" :

➡️ Промпт(ы) - Описываете правила/инструкции по которым LLM будет знать что делать с вашим Input'ом. Это то, что будет "бегать" с каждым запросом к ЛЛМ. Есть системный (базовые рулы), есть сценарный (под конкретные бизнес сабкейсы).

➡️ Граф исполнения - это набор нод сценарного графа, где рёбра - условия перехода. Ноды - узлы исполнения. Можете сделать линейный и простой, можете разветвлённый и ультра-сложный с подсистемами принятия решений/лупами, возвратами в определенные ноды и тд. Ну в общем, типичный ориентированный граф, где у каждой ноды - свой sub-state.

➡️ State - состояние агента/его память. Можете хранить в любом провайдере - память, файлы, Redis, постгря. Суть - хранить цепочки инпутов/аутпутов/метаинформации чтобы можно было восстановить "диалог" в прошлом, а так же иметь возможность вернуться к определенным чекпоинтам в череде исполнения между узлами.

➡️ Tools - тулы/api , которыми будет пользоваться ЛЛМ при необходимости. Это специальные методы, которые ЛЛМ может вызвать. Например DeleteOrder, GetUserBillingInformation, BookAppartment. В двух словах - вы определяете сами функции, обработчики и описываете параметры, а в инструкциях пишете как ими пользоваться и в каких случаях вызывать. И ллм через внутренний протоколы скрытый как раз за ширмой абстракций langchain'а дёргает по сценариям ваши методы.

Тут же в тему упомянуть про MCP (Model Context Protocol) - это по сути то же самое, только обёрнутое уже в stand-alone сервер. Подобие вынесенной "во-вне" api, стандартизированный протокол для общения с внешними/нашими агентами. С различными транспортами на выбор. Он предоставляет консьюмерам списки методов, которые им можно дёргать. Ну и всё это еще поверх обмазано аутентификацией, авторизацией и прочим сахаром.

➡️Other - различные инструменты для валидации/формата инпутов аутпутов, настройки моделей, парсеры, работа с трейсами и логами. Настройки самих моделей, ретраев, дедупликации, бэкоффов, таймаутов и прочей важной мелочёвки для работы с потоком данных, который будет проходить через этот слой.

Продолжение ниже ⤵️

@Айтигребец