AI-агенты в проде: Как мы зафорсили Gemini писать код за нас (и не уволились)
Салют, инженеры! Сегодня я хочу поделиться с вами историей нашего крупного технологического заплыва. Мы решили не просто хайпануть на теме искусственного интеллекта, а прикрутить Vertex AI и новейшие модели Gemini прямо в сердце нашего высоконагруженного продакшена. Спойлер: это было чертовски больно, мы собрали все возможные грабли, но итоговый результат превзошел наши самые смелые ожидания. Если вы до сих пор думаете, что AI — это просто прикольный чат-бот для генерации мемных стихов или написания простеньких писем, то вы глубоко ошибаетесь. В современном мире Cloud Native-разработки это мощнейший инструмент автоматизации, который способен бустануть эффективность вашей команды в космос. Нужно лишь уметь его правильно готовить.
Почему мы вообще решили туда лезть?
Давайте начистоту: поддержка клиентов — это адски тяжелый, рутинный и дорогой процесс. Как-то раз на очередном утреннем дейлике мы начали анализировать тикеты, поступающие в нашу службу поддержки первой линии (L1 Support). Картина оказалась удручающей. Около 70% всех запросов составляли абсолютно однотипные вопросы: «как настроить интеграцию через вебхуки», «почему не проходит платеж по карте», «где найти логи запросов в личном кабинете» или «сбросьте мне двухфакторную аутентификацию». На разбор этой рутины уходило гигантское количество времени. Тратить драгоценные часы синьор-инженеров и квалифицированных специалистов поддержки на ручную отправку ссылок из документации — это полный кринж, оверпрайс и прямой путь к выгоранию команды.
Мы сели за калькулятор и посчитали среднюю стоимость обработки одного тикета. Цифры кусались. Тогда и родилась безумная идея: а что, если мы заставим нейросеть делать всю грязную работу? Сказано — сделано. Мы быстро развернули песочницу в Google Cloud Platform (GCP) Platform (GCP), получили доступ к Gemini Pro через платформу Vertex AI и начали проектировать полноценного интеллектуального агента, способного не просто отвечать по шаблону, а глубоко анализировать контекст проблемы.
Время обработки тикетов по категориям (в минутах)
Сравнение среднего времени обработки запросов до и после внедрения ИИ-агента на базе Gemini.
Как мы архитектурили это чудо
Когда дело доходит до продакшена, архитектура решает всё. Мы сразу отказались от идеи пилить тяжелый монолит и пошли по классическому пути Cloud Native. Нам требовалась гибкая, масштабируемая и отказоустойчивая система, которая не ляжет при резком наплыве пользователей. В качестве фундамента мы выбрали технологический стек GCP, так как он предоставляет бесшовную интеграцию между всеми сервисами и гарантирует корпоративный уровень безопасности.
Основой нашего микросервиса стал Cloud Run. Это полностью управляемая Serverless-платформа для запуска контейнеров. Мы обожаем её за то, что нам не нужно вручную настраивать тяжелые Kubernetes-кластеры, следить за виртуальными машинами и конфигурировать HPA (Horizontal Pod Autoscaler). Cloud Run автоматически масштабирует количество инстансов от нуля до сотен в зависимости от входящего трафика. Если ночью запросов нет — мы платим ровно ноль. Деплой контейнера выполняется буквально одной командой в консоли:
gcloud run deploy ai-agent-service --source . --platform managed --region us-central1 --min-instances 1Обратите внимание на флаг --min-instances 1. Мы намеренно держим один инстанс постоянно запущенным. Это позволяет полностью победить проблему холодного старта (cold start), гарантируя, что первый пользователь не будет ждать лишние 5-10 секунд, пока поднимается наше приложение.
Для организации надежного асинхронного взаимодействия мы внедрили очередь сообщений Pub/Sub. Время ответа от больших языковых моделей (LLM) может сильно варьироваться — от пары секунд до полуминуты в моменты пиковой нагрузки на инфраструктуру Google. Если бы мы обрабатывали запросы синхронно в рамках одного HTTP-соединения с нашей CRM-системой, мы бы гарантированно ловили Gateway Timeout (ошибка 504). Наш асинхронный пайплайн устроен следующим образом: когда клиент отправляет тикет, CRM публикует событие в топик incoming-tickets. Сервис на Cloud Run, подписанный на этот топик через механизм Push subscription, забирает задачу в обработку, отправляет запрос в Vertex AI, сохраняет промежуточное состояние диалога в базу данных Firestore и по готовности шлет результат обратно в CRM через вебхук.
Борьба с галлюцинациями и построение RAG-архитектуры
Самая жесткая проблема, с которой мы столкнулись на этапе тестирования — это, конечно же, галлюцинации модели. Gemini с невероятно уверенным видом могла выдумывать несуществующие методы нашего API, ссылаться на недействующие тарифные планы или давать вредные советы по настройке серверов. Для продакшена такое поведение абсолютно недопустимо.
Решением стала реализация полноценной архитектуры RAG (Retrieval-Augmented Generation). Мы поняли, что модель бесполезно просто просить «быть умной». Ей нужно дать правильный контекст. Мы построили следующий пайплайн:
- Мы регулярно выгружаем все наши статьи из Confluence, файлы технической документации в формате Markdown и историю успешных ответов поддержки.
- С помощью скрипта на Node.js мы нарезаем эти тексты на небольшие смысловые чанки размером около 1000 символов с перекрытием в 200 символов, чтобы не терять контекст на стыках.
- Каждый чанк мы отправляем в Vertex AI Embeddings API (используя модель
text-embedding-004), получая на выходе векторное представление текста (вектор из 768 чисел). - Эти векторы мы сохраняем в специализированную базу данных векторного поиска — Vertex AI Vector Search.
Когда в систему поступает новый тикет от пользователя, мы сначала превращаем его вопрос в вектор с помощью той же модели text-embedding-004. Затем мы делаем быстрый поиск ближайших соседей (алгоритм k-NN) в Vector Search, находим топ-3 наиболее релевантных куска нашей документации и динамически подмешиваем их в системный промпт для модели. Промпт выглядит примерно так:
Контекст из внутренней базы знаний:
[Здесь располагаются найденные куски документации]
Инструкция: Ответь на вопрос пользователя, используя исключительно предоставленный выше контекст.
Если в контексте нет точного ответа на вопрос, вежливо скажи, что у тебя недостаточно информации,
и предложи перевести тикет на технического специалиста. Не придумывай ничего от себя.
Вопрос пользователя: [Текст тикета]Благодаря этому подходу уровень галлюцинаций снизился практически до нуля. Модель перестала фантазировать и начала отвечать строго по фактам, оперируя только актуальной информацией из наших систем.
Жесткая валидация ответов через Zod
Но мало получить правильный текстовый ответ. Нам нужно, чтобы наш ИИ-агент отдавал структурированные данные, которые может легко распарсить наша CRM-система. Мы хотели получать от модели не просто полотно текста, а четкий JSON-объект, содержащий категорию проблемы, уровень уверенности модели (confidence score) и сам текст ответа.
Анти-пробки для доставки цветов и еды: Google Maps Routes API (TSP-оптимизация) против грабительских комиссий курьерских агрегаторов
Для этого мы настроили Gemini на работу в режиме структурированного вывода, передав параметр responseMimeType: "application/json". Но языковые модели — штука капризная. Периодически они могут нарушать схему данных, пропускать обязательные поля или возвращать некорректные типы данных. Чтобы обезопасить себя, мы прикрутили библиотеку Zod для жесткой рантайм-валидации на стороне нашего микросервиса на TypeScript.
Мы описали строгую схему ожидаемого ответа:
import { z } from 'zod';
const TicketAnalysisSchema = z.object({
category: z.enum(['billing', 'auth', 'integration', 'bug']),
confidence: z.number().min(0).max(1),
suggestedResponse: z.string().min(10),
requiresHumanReview: z.boolean()
});Если полученный от Gemini JSON-ответ не проходит валидацию схемы Zod, наше приложение перехватывает ошибку в блоке catch, отправляет тревожную метрику в Cloud Monitoring и автоматически инициирует повторный запрос к API. При этом для повторного запроса мы принудительно снижаем параметр температуры модели до минимального значения temperature: 0.1, чтобы сделать ответы максимально детерминированными и строгими.
Процент ошибок валидации JSON в зависимости от температуры
Зависимость некорректных ответов Gemini (сбой парсинга Zod) от параметра Temperature.
Безопасность корпоративного уровня
Когда вы работаете с клиентскими данными в энтерпрайзе, безопасность — это главный приоритет. Использование стандартных публичных API от сторонних вендоров часто вызывает вопросы у отдела безопасности: где хранятся данные? Не утекут ли персональные данные (PII) в обучающую выборку публичной модели? Кто имеет доступ к истории переписки?
Использование Vertex AI в рамках инфраструктуры Google Cloud полностью снимает эти вопросы. Во-первых, Google гарантирует на уровне соглашения о конфиденциальности, что ваши промпты и данные клиентов никогда не будут использованы для обучения публичных моделей. Во-вторых, мы завернули весь наш трафик в периметр безопасности с помощью VPC Service Controls (VPC-SC). Наш контейнер в Cloud Run общается с базой данных Firestore и сервисами Vertex AI через приватные сетевые эндпоинты, не выходя в публичный интернет. Это полностью исключает возможность проведения сетевых атак типа Man-in-the-Middle и гарантирует строгое соответствие стандартам GDPR и SOC 2.
Экономика проекта и реальные результаты
Давайте поговорим о самом приятном — о деньгах. Любая крутая технология должна приносить бизнесу пользу и окупаться. До внедрения ИИ-агента средняя стоимость ручной обработки одного тикета силами первой линии поддержки составляла около $4.5 (с учетом фонда оплаты труда, стоимости рабочих мест и лицензий на софт).
После полноценного запуска нашего решения в продакшен мы смогли полностью автоматизировать около 40% всех входящих обращений. Модель сама классифицирует проблему, находит нужное решение в базе знаний, формирует ответ и отправляет его клиенту. Еще в 35% случаев агент готовит качественный черновик ответа и собирает необходимые логи, существенно экономя время живого инженера, которому остается лишь нажать кнопку подтверждения.
В результате средняя стоимость обработки одного тикета снизилась до рекордных $1.2! При этом наши затраты на инфраструктуру GCP (включая запросы к Gemini API, работу Cloud Run, дисковое пространство в Firestore и поддержку векторного индекса в Vector Search) составляют всего около $350 в месяц. Мы получили колоссальную экономию бюджета и, что не менее важно, разгрузили наших инженеров от унылой рутины, позволив им сфокусироваться на действительно сложных архитектурных задачах.
Так что, друзья, не бойтесь тащить передовые технологии искусственного интеллекта в свой продакшен. Главное — подходить к этому с холодной инженерной головой: не верить моделям на слово, использовать надежные асинхронные архитектурные паттерны, настраивать строгую валидацию данных и не забывать про информационную безопасность. А у вас уже есть опыт интеграции моделей семейства Gemini или других больших языковых моделей в реальные бизнес-процессы? С какими трудностями столкнулись вы? Жду вас в комментариях, давайте обсудим!
Реальные ограничения и компромиссы решения
Инженерная честность OZAT: при внедрении решения «AI-агенты в проде: Как мы зафорсили Gemini писать код за нас (и не уволились)» в промышленную эксплуатацию вы обязаны учитывать следующие технологические ограничения:
- Галлюцинации и недетерминированность LLM: Любые мутирующие операции обязаны проходить через детерминированный Policy Layer и строгую валидацию JSON-схем (Pydantic/Zod).
- Контроль расхода токенов и квот Vertex AI: Для предотвращения исчерпания TPM (Tokens Per Minute) необходима очередь запросов (Cloud Tasks) и кэширование контекста (Context Caching).
- Дрейф данных и концептов (Data Drift): Прогнозные модели оттока и скоринга требуют автоматического мониторинга метрик ROC-AUC и ежемесячного дообучения.
- Задержка ответа при сложном рассуждении: Вызовы многоагентных систем занимают от 2 до 8 секунд, требуя асинхронной архитектуры и стриминга статуса пользователю.
💡 Совет OZAT: Готовы к внедрению? Рассчитайте архитектуру и бюджет через Scope Builder или пройдите бесплатный ИИ-аудит.
Рустам Шарафутдинов
Эксперт в области архитектуры Google Cloud и Senior Full-Stack разработчик с более чем 15-летним опытом. Специализируется на отказоустойчивых архитектурах, оптимизации высоконагруженных проектов и интеграции AI (Vertex AI).