§ 01 · Ситуация
Ситуация: агент, который боялся нестандартных вопросов
К нам обратилась компания с уже работающим ИИ-чат-ботом для клиентов. Агент был собран на LangGraph: жёсткий граф состояний, где каждый сценарий диалога прописан отдельной веткой. Пока пользователь шёл по предусмотренному пути, всё работало. Но стоило задать вопрос не по сценарию — цепочка разваливалась: агент либо уводил диалог не туда, либо застревал в промежуточном состоянии.
Вторая проблема — цена изменений. Добавление нового сценария означало правку графа: новые узлы, новые переходы, регрессия по старым веткам. Команда клиента тратила на поддержку конструкции больше времени, чем на развитие продукта.
§ 02 · Аудит
Аудит: два вывода, оба неочевидные
Мы начали не с кода, а с аудита: разобрали архитектуру агента и то, как развёрнута модель. Выводов получилось два, и оба на первый взгляд контринтуитивные.
- Граф состояний здесь был лишним. Современные модели достаточно хорошо планируют сами — жёсткий пайплайн не помогал агенту, а мешал, отбирая у модели право принимать решения.
- Модель была выбрана по принципу «больше — лучше»: open-source модель на 35 миллиардов параметров. Аудит показал, что 27B-версия на задачах этого агента отвечает качественнее — при меньших требованиях к железу.
§ 03 · Tool-calling
Решение 1: от жёсткого графа к прямому tool-calling
Мы убрали пайплайн-фреймворк целиком. Новая архитектура — это прямой вызов эндпоинта модели с набором описанных инструментов (tools): поиск по базе знаний, запросы к CRM, оформление заявки, эскалация на оператора. Модель сама решает, какой инструмент вызвать и в каком порядке, — вместо того чтобы двигаться по заранее нарисованному графу.
Кода стало заметно меньше, а каждая оставшаяся часть — проще и изолированнее. Падение одного инструмента больше не роняет диалог: агент видит ошибку и выбирает другой путь. Добавление новой возможности — это регистрация одного нового инструмента, а не перестройка графа с регрессией по всем веткам.
Важная оговорка: LangGraph и LangChain — рабочие инструменты, мы сами используем их там, где процессу действительно нужен управляемый граф с контрольными точками. Зрелость решения — в том, чтобы знать, когда фреймворк нужен, а когда он лишний слой между моделью и задачей.
§ 04 · Модель
Решение 2: модель меньше — ответы умнее
По итогам аудита развёртывания мы заменили 35B-версию open-source модели на 27B-версию. Это одна из тех неочевидных вещей, которые часто не понимают: число параметров — не рейтинг интеллекта. Качество модели определяется поколением, архитектурой и обучением, и более компактная модель вполне может обходить более крупную — что здесь и произошло на реальных диалогах агента.
Бонусом клиент получил экономию на инфраструктуре: меньшая модель требует меньше видеопамяти и отвечает быстрее. То есть переход дал одновременно и качество, и скорость, и снижение стоимости эксплуатации — без единого компромисса.
§ 05 · Результат
Результат
За два дня агент из хрупкой конструкции превратился в систему, которую легко развивать: новые сценарии добавляются без переписывания логики, нестандартные вопросы перестали быть проблемой, а стоимость эксплуатации снизилась вместе с размером модели.
Этот кейс хорошо показывает наш подход: сначала аудит и понимание задачи, потом архитектура — и простота как осознанный инженерный выбор, а не экономия на качестве.