Модель как архитектурный объект: роутер + пайплайны в LLM‑агентах
В статье «Граница код | модель как архитектурный объект» предлагается построить LLM‑агентов как набор модулей‑проектов: роутер запросов, пайплайны обработки и интеграция с AWS и Claude. На примере text2sql показаны плюсы такой модульности.
Что описывает статья
Автор размышляет над тем, как модель LLM может выступать не просто как «чёрный ящик», а как архитектурный объект. Основная идея – разделить агентскую логику на два уровня:
- Router – модуль, который получает запрос пользователя, определяет его тип (SQL‑запрос, аналитический отчёт, чат‑ответ) и направляет дальше.
- Pipelines – цепочки обработчиков, каждый из которых отвечает за отдельный шаг: формирование запросов к базе, их исполнение в облаке (AWS), пост‑обработку результатов и формирование финального ответа.
Пример из практики
В качестве «знакомого» кейса рассматривается text2sql‑агент. Традиционно такой агент делает всё в одном большом промпте: определяет, что пользователь хочет получить, генерирует SQL‑запрос, исполняет его и формирует ответ. Автор показывает, как можно вынести каждый из этих шагов в отдельный пайплайн, а роутер будет лишь выбирать нужную цепочку.
Технологический стек
- Claude (Anthropic) используется в качестве LLM‑ядра для генерации запросов и формулировки ответов.
- AWS (Lambda, RDS) – платформа исполнения SQL‑запросов и хранения данных.
- Внутренний роутер реализован на Python, но концепция переносима на любые сервер‑лесные среды.
Почему это важно
- Модульность упрощает отладку – каждый пайплайн можно тестировать отдельно.
- Гибкость – меняя один компонент (например, заменив Claude на Gemini), не нужно переписывать всю логику.
- Повторное использование – один и тот же пайплайн «форматировать результат» можно применять к разным типам запросов.
Статья доступна на Habr AI: https://habr.com/ru/articles/1083130/
Для разработчиков LLM‑агентов такой подход открывает путь к более чистой, масштабируемой архитектуре. Вместо монолитных промптов можно собрать «конвейер» из проверенных блоков, быстро менять провайдеров и легче поддерживать код. Однако потребуется продумать роутинг и согласованность интерфейсов между пайплайнами, иначе модульность превратится в лишнюю сложность.
