Хочу разобрать кейс из практики про построение системы на базе LAM + LLM + ML. Это хороший пример того, почему «просто подключить LLM» почти никогда не работает в реальных задачах.
Задача — автоматизировать принятие решений в маркетинге. Что нужно было уметь системе: анализировать профиль клиента, учитывать поведение и историю, оценивать риск и выбирать оптимальное действие (канал / оффер / момент).
На старте была гипотеза: «давайте возьмём LLM и дадим ему всё это решать».
Что произошло? LLM действительно мог анализировать текст, обобщать информацию и генерировать рекомендации. Но решения были нестабильными, не учитывались численные ограничения и невозможно контролировать результат.
И главное — LLM не оптимизирует целевую функцию бизнеса. LLM отвечает на вопрос: «Что выглядит разумно?» А система должна отвечать: «Что максимизирует результат при ограничениях?». Это разные задачи.
Что сделали? Перешли от «одной модели» к агентной архитектуре.
Мы разделили логику на компоненты:
1️⃣ ML-блок (предиктивный слой) считает вероятности и оценки: P(response), P(churn), Expected value и риск. Это числовая основа.
2️⃣ LLM-блок (интерпретация и логика) отвечает за объяснение, работу с текстом, генерацию гипотез и гибкую логику, которую сложно зашить в код.
3️⃣ LAM / агентный слой (оркестрация) — ключевая часть системы. Он управляет последовательностью действий, вызывает нужные модели, учитывает ограничения и принимает итоговое решение. По сути, это decision engine.
Как выглядит поток?
➖ Агент получает задачу;
➖ Запрашивает ML-оценки;
➖ Передаёт контекст в LLM;
➖ Применяет бизнес-ограничения;
➖ Выбирает действие.
Почему это работает? ML даёт точные оценки, LLM даёт гибкость, агент даёт контроль. По отдельности этого недостаточно.
Если вы строите систему на LLM, задайте себе вопрос, где у вас находится контроль решения? Если ответ «внутри LLM», это почти всегда проблема.