Некоторое время назад стал замечать в рунете исследования на тему внедрения AI: - Технология Доверия - 86% российских компаний уже интегрируют инструменты AI, но только 28% готовы направлять от 1% до 3% инвестиционного бюджета на инициативы, связанные с искусственным интеллектом - Ассоциации менеджеров - 33% российских компаний сталкиваются с сопротивлением персонала при внедрении технологий AI, а 45% отмечают нехватку квалифицированного персонала

Газпром, Сбер, ВТБ, Холдинг Т1 и другие активно анонсируют AI-инициативы. Сбер заявляет, что 90% регионов России применяют AI-решения. В Т1 более 1,7 тыс. сотрудников используют нейросети при программировании. Часто все эти инициативы позиционируются как способ “оптимизации” процессов и персонала.

Но мое мнение не понравится топ-менеджерам. Я глубоко убеждее, что часть этих “оптимизаций” — это бездумное внедрение AI там, где классические решения были бы эффективнее, дешевле и не требовали бы сокращения людей. Уверен, что люди, принимающие решения, не совем понимают где именно AI добавляет сложность без реальной выгоды, а “оптимизация” в итоге превращается в самоцель.

Разберу кейс из личной практики, в котором AI выбрали вместо людей, но классические решения оказалось лучше, а людей сохранили.

Кейс: Замена операторов поддержки на LLM-чатботов

Ситуация Команда в крупной IT-компании получила задачу “оптимизировать” службу поддержки через AI. План простой: заменить 15 операторов на LLM-чатбот, который будет отвечать на все запросы. Обоснование руководства: “AI понимает контекст, люди не нужны”.

Мой анализ Я запросил исторические данные за последние 6 месяцев и провёл архитектурный аудит существующей системы: - 85% запросов попадают в 12 стандартных категорий - Паттерны формулировок повторяются: “не могу войти”, “не приходит оплата”, “как настроить” - Средняя длина запроса — 2-3 предложения - 70% запросов решаются за 1-2 ответа по готовым инструкциям - Пиковая нагрузка: ~200 запросов/мин в часы пик - Средняя нагрузка: ~50 запросов/мин

Архитектурный разбор предложенного решения (LLM-чатбот на все запросы)

Проблемы масштабирования: - Latency: каждый запрос к LLM API — 800-2000ms (сетевые задержки + обработка) - Cost: при 200 запросов/мин × 60 мин × 24 часа = 288k запросов/день Стоимостьв рамках ТСО кластера GPT-4 (Qwen или DeepSeek): ~$0.03 на запрос → $8,640/день = ~$260k/мес - Rate limits: большинство LLM API имеют лимиты 100-500 запросов/мин, что не покрывает пиковую нагрузку - Надёжность в рамках масштабируемоси кластера создаёт single point of failure

Архитектурное решение (гибридный подход) 1️⃣ уровень: классическая автоматизация - База знаний на Elasticsearch (индексация FAQ, инструкций, документации) - Поиск по ключевым словам и синонимам (latency: 10-50ms) - Шаблоны ответов для 12 стандартных категорий (Jinja2-шаблоны с переменными) - Правила маршрутизации на основе категоризации запроса

[Запрос] → [Классификатор] → [Elasticsearch] → [Шаблонизатор] → [Ответ] _ ↓ (не найдено) _ [LLM Fallback] → [Ответ]

2️⃣ уровень: AI только для сложных кейсов - LLM-чатбот подключается только если: - Elasticsearch не нашёл релевантный ответ (confidence < 0.7) - Запрос не попал ни в одну из 12 категорий - Пользователь явно запросил эскалацию

3️⃣ уровень: люди для критичных задач - 3 оператора вместо 15 (фокус на сложных кейсах и эскалациях) - Эскалация происходит если: - LLM не смог решить за 2 итерации - Запрос касается финансовых операций или безопасности - Пользователь запросил человека

Результат После внедрения гибридного подхода: - Latency снизился с 2-3 минут (ожидание оператора) до 10-20 секунд (автоответы по шаблонам) для 85% запросов - Стоимость снизилась на 80% (vs полная замена на LLM) - Качество осталось на уровне 95% (vs 92% у чистого LLM-чатбота) - Сохранили 3 операторов для сложных кейсов (вместо увольнения всех 15) - Система выдерживает пиковую нагрузку без деградации (классическая часть масштабируется независимо)

Продолжение в ч.2 ⏩

#архитектура #AI #антипаттерны #оптимизация #SolutionsArchitect #бигтех