Гурмит Саран (Gurmeet Saran) работает инженером в Anthropic в Сан-Франциско и отвечает за инфраструктуру, которая позволяет понять, как ведёт себя AI-агент на базе Claude, и убедиться, что он выдаёт надёжные результаты. Свою задачу он формулирует буднично: следить, чтобы данные были точными, структурированными и заслуживающими доверия, а приватные данные оставались приватными (IEEE Spectrum).
Из этой формулировки вырастают три практических тезиса. Приватность не получится добавить поверх готовой системы: её закладывают в архитектуру с самого начала. Для баз данных и веб-сервисов инструменты мониторинга давно есть, для LLM их ещё предстоит выработать. Если нельзя доверять логике системы, нельзя делать надёжные утверждения о её поведении, а у этого есть прямые последствия для безопасности.
Дальше разберём, что стоит за этими тезисами, как выглядит наблюдаемость агента на практике и какие шаги имеет смысл сделать в своём проекте.
Кто такой Гурмит Саран и почему его опыт важен для AI-индустрии
Саран - старший член IEEE (IEEE senior member) и инженер Anthropic, компании, которая разрабатывает Claude. Его работа связана с двумя задачами: понять механику поведения чат-бота и обеспечить надёжность выходных данных его архитектуры. Проще говоря, он строит то, что позволяет инженерам Anthropic отвечать на вопрос «почему агент поступил именно так», а не догадываться об этом по косвенным признакам.
Путь от Yahoo до Anthropic: формирование экспертизы
Карьера Сарана началась в 2007 году в Yahoo: ещё аспирантом он возглавил команду данных в Бангалоре. Проблема, с которой он там столкнулся, знакома любой компании с несколькими аналитическими командами: одну и ту же метрику разные команды считали по чуть разной логике и получали противоречивые числа. Показательный пример из материала - ежедневные активные пользователи сайта (daily active site users): расхождения возникали из-за разных определений одного и того же показателя.
Решение оказалось организационно-техническим: команда собрала центральное хранилище данных с определёнными метриками, то есть единый источник правды. Саран описал модель, которая задаёт, что означает «ежедневные активные пользователи сайта»: какие события учитываются, как обрабатывать граничные случаи и что делать, когда стандартный код не справляется (IEEE Spectrum).
Образование: бакалавр по электронике и телекоммуникационной инженерии в Университете Каляни (2004) и магистр программной инженерии в Технологическом институте Бирлы в Пилани (2010).
Что источник не подтверждает: в материале IEEE Spectrum, на котором основана эта статья, карьера Сарана после Yahoo не раскрыта. Сведения о его работе в Intuit, Meta и Wealthfront, о проекте Metric360 и о защите данных налогоплательщиков по требованиям IRS в источнике отсутствуют, поэтому здесь они не приводятся как факты.
Что такое наблюдаемость AI-агентов и почему это сложнее, чем мониторинг веб-сервисов
Наблюдаемость (observability) агента - это возможность по собранным данным восстановить, что именно произошло во время его работы: какой запрос пришёл, какие шаги агент предпринял, какие инструменты и с какими аргументами вызвал, какие данные получил и почему выдал такой ответ. Без этого отладка превращается в гадание, а разговор о надёжности системы остаётся разговором о впечатлениях.
Ключевая разница с классическим мониторингом - зрелость инструментов. Саран формулирует это прямо: для баз данных и веб-сервисов есть рабочие инструменты мониторинга, а для LLM их ещё только предстоит выработать (IEEE Spectrum). Anthropic приоритизирует безопасность, и это задаёт рамку: миссия Claude в заявлении компании описана как «по-настоящему полезный для людей, с которыми он работает или от имени которых действует, а также для общества, при этом без небезопасных, неэтичных или вводящих в заблуждение действий». Проверить соблюдение такой формулировки без наблюдаемости невозможно.
Ключевые отличия мониторинга LLM от классических систем
- Недетерминированность. Один и тот же запрос даёт разные ответы. У веб-сервиса эталонный ответ один, у LLM эталона нет, поэтому сравнивать выход с выходом напрямую нельзя.
- Ошибка не бинарна. В веб-сервисе сбой - это код 500 или таймаут. Ответ LLM с корректным HTTP-кодом 200 может быть фактически неверным, устаревшим или неуместным по тону, и ни одна техническая метрика этого не заметит.
- Нет фиксированной схемы ответа, если вы её не навязали. Для надёжности ответ приходится валидировать: проверять структуру, обязательные поля, ссылки на источники, диапазоны значений.
- Оценивать нужно семантику. Релевантность, соответствие ожиданиям пользователя, отсутствие выдуманных фактов не считаются через время ответа и число ошибок.
- Финального ответа недостаточно: важна траектория. Агент может прийти к верному результату через неверные шаги, и это проявится на следующей похожей задаче.
Отсюда список того, что стоит фиксировать: вызовы модели с версиями модели и промпта, вызовы инструментов с аргументами и результатами, обращения к файлам и базам, идентификатор сессии, промежуточные решения агента, время и стоимость каждого шага. Персональные данные в этих записях должны быть вычищены до сохранения.
Приватность как часть архитектуры: почему нельзя «прикрутить» её сверху
Саран говорит, что приватность не может быть слоем, который прикручивают поверх, она должна быть частью архитектуры с самого начала, и добавляет, что усвоил это ещё в начале карьеры. Причина в природе данных агента: если персональные данные попадают в промпты, в трейсы, в кэш ответов и в векторные хранилища, никакой фильтр на выходе не гарантирует, что они не утекут через логи или выгрузку.
Цена ошибки измеряется репутацией и деньгами. Требования регуляторов к персональным данным и к отдельным категориям сведений (например, налоговым) определяют, где данные могут храниться, кто имеет к ним доступ и как долго их держат. Когда такие данные уже размазаны по трейсам и датасетам, выполнить эти требования сложнее и дороже, чем заложить ограничения на старте.
Практические шаги: как заложить приватность в AI-агента
- Классифицируйте данные до того, как подключать агента к источнику: категория чувствительности, владелец, что можно показывать модели, а что нет.
- Минимизируйте: агенту передавайте только те поля, которые нужны для задачи. Идентификаторы и полезные данные храните раздельно, чтобы компрометация одного хранилища не раскрывала связку «кто» и «что».
- Шифруйте на уровне полей: шифрование диска и канала не защищает от утечки через выгрузку или лог.
- Вычищайте персональные данные до записи в трейсы и логи. Маскирование и хеширование на входе и выходе дешевле, чем чистка накопленной истории.
- Разделяйте контуры: трейсы, размеченные датасеты и продакшн-хранилища держите отдельно, с разными правами доступа и сроком хранения.
- Ведите аудит доступа: кто читал трассировки, какие права были у агента, какие инструменты он вызывал.
- Пересматривайте риски по расписанию: смена модели, промптов или набора инструментов меняет поверхность утечки.
Это ориентиры, а не готовый рецепт: набор мер зависит от юрисдикции, категории данных и круга людей с доступом к системе. При обучении на собственных наборах риск снижают дифференциальная приватность и федеративное обучение, но они заметно усложняют пайплайн и не отменяют контроль доступа. Логи, права, изоляция и мониторинг в реальном времени разобраны отдельно в материале про базовую сетевую гигиену AI-агентов.
Как оценивать качество ответов LLM и отлаживать AI-агентов
Подход Сарана к данным задаёт и подход к оценке: если нельзя доверять логике, нельзя делать надёжные утверждения о поведении системы, а это имеет последствия для безопасности. На практике это значит, что оценка качества опирается на структурированные данные, а не на отдельные примеры удачных ответов.
Рабочая схема складывается из четырёх уровней.
- Проверки структуры. Схема ответа (например, JSON Schema), обязательные поля, допустимые значения, наличие ссылок на источники. Ловят сбои парсинга и формата, смысл не проверяют.
- Автоматические метрики. BLEU и ROUGE сравнивают n-граммы ответа с эталоном. Для свободных ответов агента они малоинформативны: правильный по смыслу ответ с другими формулировками получит низкую оценку, а уверенно неверный с похожими словами - высокую.
- Оценка моделью (LLM-as-judge) по явно описанным критериям. Даёт масштаб, но требует калибровки: судью сверяют с разметкой людей на выборке, иначе получите стабильно смещённые оценки.
- Человеческая оценка и A/B-тесты на реальных задачах. Самый дорогой уровень, поэтому его применяют на выборке и для спорных случаев.
Отладка идёт по трассировке, и порядок разбора почти всегда одинаковый: проверить, попал ли в контекст нужный фрагмент данных; проверить выбор инструмента и аргументы вызова; проверить, что вернул инструмент; и только затем смотреть на финальную генерацию. Ошибка в парсинге запроса, неверный инструмент и галлюцинация на выходе выглядят для пользователя одинаково, а чинятся по-разному.
Инструменты и подходы для мониторинга LLM
Устоявшихся стандартов мониторинга LLM пока нет: по словам Сарана, инструменты для этого ещё вырабатываются. Внутренние решения Anthropic источник не описывает, поэтому ориентироваться стоит на критерии, а не на названия продуктов:
- работа с траекториями: шаги агента и вызовы инструментов, а не только HTTP-запросы;
- кастомные метрики и ручная разметка, без них вы застрянете на технических показателях;
- фильтры и поиск по версиям модели и промпта, иначе не поймёте, что именно изменило качество;
- контроль над хранением: где лежат трейсы, у кого есть доступ, какой у них срок жизни, как вычищаются персональные данные;
- стоимость хранения: трассировка агента растёт быстро, и счёт за хранилище стоит посчитать заранее;
- интеграция с существующим стеком: логи, очереди, хранилища, система разметки.
Выбор между своей разработкой и готовым решением разобран в материале про сборку AI-агента с нуля: архитектуру, метрики и код на Python, там же сравнение latency, cost и reliability. Если агент работает с корпоративной базой знаний, пригодятся подходы из руководства по системе управления знаниями для AI-команд: выбор хранилища и фильтрация на входе напрямую влияют на то, что попадёт в трейсы.
Роль IEEE в стандартизации AI-инфраструктуры и глобальном сообществе инженеров
Саран - старший член IEEE, и это единственное, что источник сообщает о его связи с организацией. Участвует ли он в разработке стандартов для AI-инфраструктуры, материал не раскрывает, поэтому выдавать такое участие за факт нельзя.
Почему тема важна для практиков: пока форматы телеметрии, определения метрик и требования к оценке качества агентов у каждой компании свои, команды строят одни и те же инструменты заново, а сравнивать системы между собой почти невозможно. История с метрикой daily active site users в Yahoo - маленькая иллюстрация общего принципа: пока нет единого определения, два инженера из разных команд получат из одних данных разные числа. Общие требования к трассировке, к разметке персональных данных в логах и к описанию метрик сняли бы часть этой работы с команд и упростили бы аудит.
Для инженеров из разных стран участие в профессиональных сообществах даёт доступ к обсуждениям, которое сложно заменить чтением документации: видно, как похожие задачи решают в других командах и на каком оборудовании. Конкретные программы IEEE и условия участия стоит уточнять на сайте организации, а не по пересказам.
Что это значит для разработчиков: практические выводы
- Логируйте траекторию, а не только финальный ответ: вызовы модели с версией промпта, вызовы инструментов с аргументами, обращения к данным.
- Определите, что считаете ошибкой в своём домене, до того как рисовать дашборды. Без определения метрики графики ничего не решают.
- Держите принцип «одна метрика - одно определение» и единый источник правды. Разные команды с разной логикой расчёта гарантируют спор о числах.
- Закладывайте приватность на старте: классификация данных, минимизация, шифрование полей, вычистка персональных данных из трейсов, отдельные контуры хранения.
- Оценивайте качество на нескольких уровнях: структура, автоматические метрики, оценка моделью с калибровкой, человеческая выборка.
- Начинайте с малого: сначала логирование шагов и структурирование данных, затем оценка качества на выборке, затем архитектура приватности. Перепрыгнуть сразу к третьему пункту обычно означает переделывать первые два.
Когда агентов становится несколько, а поведение меняется от версии к версии, задача смещается от постройки системы к управлению ею. Этот переход, вместе с принципом управления по исключениям, разобран в материале про Governor shift и управление AI-системами.