Databricks про production AI: почему модель выбирают ближе концу проекта (Рубрика AI4SDLC)
Посмотрел доклад Sandipan Bhaumik из Databricks "The Production AI Playbook: Deploying Agents at Enterprise Scale", в котором автор делился своим подходом к внедрению агентов в клиентские enterprise проекты, где надо было пройти путь от вау-эффекта на демо до продакшена:)
Автор иронично начал с того, что раньше большинство AI-проектов начиналось с вопроса "GPT или Claude?". Дальше быстро собирался красивый прототип на чистых данных, руководство радовалось, а через несколько недель в production никто не понимал, а почему агент отвечает странно, кто за это отвечает и где искать причину. Для того, чтобы не попадать в такую ситуацию он предлагает свой playbook из пяти опор
1️⃣ Evaluation (Define success before code) Fdnjh называет их спецификацией AI-системы: до кода и до выбора модели нужно понять, что считается успехом в числах. Не просто "accuracy", а какая точность достаточна для конкретного бизнеса, сколько простых обращений должен закрыть агент, какие ошибки допустимы, где нужен человек.
2️⃣ Observability (see everything, always) Если агент отказал клиенту, неправильно вызвал tool или три раза сходил в одну и ту же базу, это должно быть видно по шагам: intent classification, API call, поиск документа, reasoning, guardrail check, финальный ответ. Иначе в инциденте остается только гадать.
3️⃣ Data foundation (question + tracking data) Автор делит этот пункт на данные, из которых агент отвечает пользователю, и tracking data - следы работы агента. Он отмечает, что люди прощают плохие данные, агенты нет. Человек увидит странность в отчете и переспросит. Агент уверенно даст неверный ответ.
4️⃣ Orchestration (patterns that scale) Работу одного агента еще можно держать в голове. Пять совместно работающих агентов уже требуют паттернов, например
- Orchestrator-worker, где центральный агент раздает работу
- Choreography, где агенты слушают события и работают параллельно
- Human-in-the-loop, где человек входит в контур при низкой уверенности или рискованном действии
5️⃣ Governance (what keeps you in production) В докладе это не только data governance (который уже должен быть как пререквизит), но в общем про управление рисками и ответственностью. Это аудит логи, проверки персональной информации, версионирование промптов, процесс над изменением моделей в проде и ответы на вопросы вида "кто отвечает, если агент сломался в 3 часа ночи".
В самом докладе автор делится кейсом чатбота для ритейл банка, где клиент Databricks потратил около 85 тысяч фунтов и 6 месяцев на PoC, который не вышел в production: никто не мог объяснить, почему система работает с низким качеством. В новом подходе команда выбрала модель только на 7-й неделе 8-недельного проекта. До этого они собрали около 200 реальных кейсов ответов людей в чатботе, описали метрики, построили пайплан для evaluation, включили трассировки и подготовили слой данных.
Шесть недель после запуска случился нормальный production-инцидент: банк обновил политику по процентным ставкам, клиенты начали ставить плохие оценки ответам чатбота, так как агент продолжал ссылаться на устаревший документ. Без трассировки это выглядело бы как "AI опять ведет себя странно". С трейсами стало видно, что новый документ по процентным ставкам не попал в векторную базу и чатбот про него не знал.
Отсюда вырастает плейбук для работы с инцидентами - Detect - увидеть просадку через дашборд evals (оффлайн метрики) или по онлайн метрикам
- Diagnose - разобрать трейсы и понять что идет не так
- Contain - принять меры: откатить prompt, перевести поток на человека или включить circuit breaker
- Fix - поправить данные, tool call, prompt или модель
- Prevent - в финале обязательно добавить новый случай в набор evaluation, чтобы система ловила его в следующий раз
Databricks, понятно, показывает это через свои продукты: MLflow для tracing/evals/monitoring, Unity Catalog для прав и контекста, Agent Bricks и Unity AI Gateway для управления агентами, моделями, tools и доступами. Но ценность доклада, мне кажется, шире конкретной платформы.
Мне этот доклад нравится тем, что он хорошо укладывается в тему, что я рассказывал буквально вчера на Highload++, где AI начинает работать в компаниях хорошо, если с его помощью меняется производственная система. А вот если вокруг агента нет harness, наблюдаемости, данных и governance, то масштабирование быстро приведет вас от красивого демо до проблем на проде.
#AI #AI4SDLC #Engineering #Agents #Architecture #Management