Totogi BSS Magic: как мы заменили 20 инженеров мультиагентным фреймворком на Amazon Bedrock

Проблема, от которой плачут телеком-инженеры

Представьте: оператор связи получает 500+ change request в день. Каждый - это изменение тарифа, добавление опции, исправление биллинга. Каждый проходит через 5 человек: аналитик проверяет логику, инженер - техническую реализацию, тестировщик - корректность, еще двое - согласование.

Среднее время обработки - 3-5 дней. Ошибки - в 15% случаев. Стоимость одного запроса - $200-300. Математика простая: 500 × $250 × 20 рабочих дней = $2.5 млн в месяц на ручной труд.

Решение: почему мультиагенты, а не один большой LLM

Первый инстинкт: взять Claude 4.5 (самую новую версию на 08.02.2026 в Amazon Bedrock) и скормить ему все change request. Звучит логично? На практике - катастрофа.

Проблемы монолитного подхода:

• LLM теряет контекст в длинных цепочках рассуждений
• Нет специализации: один агент должен знать и бизнес-логику, и SQL, и API, и телеком-онтологии
• Нет параллельной обработки: запросы ждут своей очереди
• Сложно отслеживать, где именно произошла ошибка

Наше решение: мультиагентный фреймворк, где каждый агент - узкий специалист. Как в хорошей больнице: терапевт ставит диагноз, хирург оперирует, медсестра ухаживает.

Архитектура: кто за что отвечает в нашем оркестре

Почему такая смесь моделей? Экономика. Haiku - быстрая и дешевая для простых проверок. Sonnet - баланс цены и качества для генерации кода. Opus - дорогая, но только для оркестрации, где нужны сложные рассуждения.

Шаг за шагом: как работает обработка запроса

1Прием и классификация

Запрос приходит в формате "Добавить опцию 'Роуминг в Европе' к тарифу 'Бизнес Плюс' с ценой $10/месяц". Аналитик-приемщик извлекает сущности:

• Действие: ADD
• Тип объекта: ADDON
• Название: Европейский роуминг
• Целевой тариф: Бизнес Плюс
• Цена: $10
• Период: monthly

Он же проверяет, что запрос написан на человеческом языке, а не "ADD ADDON TO TARIFF". Если есть неясности - запрашивает уточнения у пользователя.

2Валидация бизнес-логики

Валидатор берет извлеченные сущности и проверяет:

1. Существует ли тариф "Бизнес Плюс"?
2. Есть ли у него уже опция "Роуминг в Европе"?
3. Не конфликтует ли новая опция с существующими (например, если есть "Роуминг по всему миру")?
4. Соответствует ли цена $10 ценовой политике (не ниже себестоимости, не выше рынка)?

Для проверки валидатор использует оптимизированный поиск по онтологии, который мы описали в другой статье. Без оптимизации каждая проверка занимала бы 3.5 секунды, а с ней - 700 мс.

3Генерация SQL и API

Разработчик SQL создает миграцию:

-- Добавление опции European Roaming к тарифу Business Plus
INSERT INTO tariff_addons (tariff_id, addon_id, price_monthly, created_at)
SELECT 
    t.id,
    a.id,
    10.00,
    NOW()
FROM tariffs t
JOIN addons a ON a.name = 'European Roaming'
WHERE t.name = 'Business Plus'
AND NOT EXISTS (
    SELECT 1 FROM tariff_addons ta 
    WHERE ta.tariff_id = t.id AND ta.addon_id = a.id
);

Интегратор API создает или обновляет endpoint. Здесь важно: он не просто генерирует код, а проверяет существующую структуру API через специализированный скрапинг документации.

4Тестирование и деплой

Тестировщик генерирует не просто "проверяем, что опция добавлена". Он создает сценарии:

• Что будет, если абонент с "Бизнес Плюс" купит опцию, потом отменит, потом купит снова?
• Как поведет себя биллинг при переходе с тарифа на тариф с этой опцией?
• Что если цена изменится посреди billing cycle?

После успешных тестов оркестратор запускает деплой через CI/CD. Но перед этим - проходит через Amazon Bedrock Guardrails, которые проверяют, что код не содержит уязвимостей и соответствует политикам безопасности.

Главные ошибки, которые мы совершили (чтобы вы их не повторили)

Ошибка 1: Слишком много контекста у каждого агента

Первая версия: каждый агент получал полную историю запроса + все предыдущие шаги. Результат: промпты по 20к токенов, стоимость взлетела в 5 раз, а точность упала - агенты "терялись" в объеме информации.

Решение: строгий контекстный протокол. Аналитик передает валидатору только извлеченные сущности. Валидатор - разработчику только валидированные требования. Как в реальной разработке: тимлид не пересказывает всю бизнес-логику джуну, а дает конкретное ТЗ.

Ошибка 2: Отсутствие "человеческого надзора" для сложных случаев

Мы пытались полностью автоматизировать все. Но 3% запросов были настолько сложными (изменение архитектуры биллинга, миграция миллионов абонентов), что агенты либо отказывались их обрабатывать, либо предлагали катастрофические решения.

Решение: эскалационная матрица. Если оркестратор видит, что:

• Два агента не могут договориться (валидатор говорит "можно", разработчик - "нельзя")
• Запрос затрагивает более 1 млн абонентов
• Есть юридические или регуляторные аспекты

Тогда запрос идет к human-in-the-loop - senior инженеру, который принимает решение. Система готовит ему анализ: что предложили агенты, какие риски видят, какие зависимости затрагиваются.

Ошибка 3: Игнорирование латентности между агентами

В теории: агент А закончил → сразу запускается агент Б. На практике: между завершением одного и стартом другого - 500-1000 мс на сериализацию/десериализацию, логирование, метрики.

При 500 запросах в день и 5 агентах на запрос: 500 × 5 × 0.75с = 1875 секунд простоев в день. Почти полчаса!

Решение: пайплайнинг. Пока агент Б обрабатывает запрос №1, агент А уже начинает запрос №2. Как на конвейере. Это снизило общее время обработки на 40%.

Технические детали, о которых молчат в маркетинговых кейсах

Как мы храним телеком-онтологию

Не в PostgreSQL. Не в Elasticsearch. Мы используем Amazon Neptune (графовая БД) потому что:

• Запросы типа "найди все тарифы, которые зависят от технологии 5G, но не включают международный роуминг" - это один запрос на Gremlin, а не 10 JOIN в SQL
• Обновление онтологии (добавление нового типа услуги) - это добавление вершины и ребер, а не перестройка схемы
• Визуализация зависимостей для отладки - встроенная в Neptune

Но есть проблема: LLM не умеет работать с Gremlin напрямую. Решение: мы создали слой трансляции. Агент формулирует запрос на естественном языке ("найди конфликты между этой опцией и существующими"), транслятор конвертирует в Gremlin, выполняет, результат конвертирует обратно в текст.

Версионирование промптов

Промпты - это такой же код. Они меняются, улучшаются, иногда ломаются. Мы храним их в Git, с тегами версий. Каждый агент имеет версию промпта в метаданных.

Зачем? Представьте: вы обновили промпт валидатора, и он начал отвергать 30% валидных запросов. С версионированием вы можете:

1. Быстро откатиться к предыдущей версии
2. Запустить A/B тест: 50% запросов по старому промпту, 50% по новому
3. Анализировать, какие именно изменения в промпте привели к проблеме

Мониторинг и алертинг

Мы отслеживаем не только "агент упал". Ключевые метрики:

• Accuracy decay: если точность агента падает на 2% за день - это алерт
• Cost per request: внезапный рост стоимости - значит, агенты стали генерировать больше токенов
• Escalation rate: процент запросов, ушедших к human-in-the-loop. Рост означает, что агенты не справляются со сложностью
• Cycle time: время от получения запроса до деплоя. Медленный рост - признак деградации производительности

Все метрики - в Amazon CloudWatch, дашборды - в Grafana. Алерты - в Slack и PagerDuty.

Результаты: цифры, которые заставят вашего CFO улыбнуться

После 6 месяцев работы системы:

Но главный результат не в цифрах. Главное - predictability. Раньше вы не знали, когда запрос будет готов. Сейчас знаете: простой - 15 минут, средний - 25, сложный - 45. Можно планировать релизы. Можно обещать клиентам.

Что дальше? Мультимодальность и глобальный вывод

Следующие шаги:

1. Мультимодальные запросы: клиент присылает скриншот старого счета и говорит "сделай такой же, но на 10% дешевле". Агент должен прочитать скриншот, понять структуру тарифа, предложить аналогичный. Здесь поможет мультимодальный RAG от Amazon Bedrock.
2. Голосовые запросы: оператор кол-центра говорит "добавь клиенту опцию международных звонков", система понимает, генерирует change request. Похоже на то, что делала Clarus Care для медицинского кол-центра, но для телекома.
3. Глобальный вывод: сейчас система работает в us-east-1. Но клиенты есть в Европе, Азии, Латинской Америке. Нужно развернуть агентов ближе к ним, чтобы снизить latency. Планируем использовать подход из статьи про глобальный вывод Claude 4.5.

Финальный совет: начинайте с онтологии, а не с агентов

Видите красивую архитектуру с кучей агентов? Не торопитесь ее копировать. 80% нашего успеха - не в промптах, не в моделях, не в оркестрации. 80% - в качественной телеком-онтологии.

Потратьте месяц на то, чтобы описать:

• Все сущности вашего домена (тарифы, опции, клиенты, счета)
• Все отношения между ними (тариф включает опции, опция зависит от технологии)
• Все бизнес-правила (цена не может быть ниже себестоимости, акция не может длиться больше года)
• Все edge cases (что делать, если клиент меняет тариф посреди billing cycle?)

Без онтологии ваши агенты будут как слепые котята - милые, но бесполезные. С онтологией - как швейцарские часы: точные, надежные, предсказуемые.

И последнее: не бойтесь human-in-the-loop. Полная автономность - это утопия. 97% автоматизации с 3% человеческого надзора - это не провал. Это зрелость.