Operator: A look under the hood

Мы только что запустили Operator — Агента для ваших клиентских операций, который помогает понимать, управлять и улучшать весь клиентский опыт.

Чтобы вы могли оценить, насколько мощный это Агент, мы подробнее расскажем о его технической инфраструктуре и об инженерных решениях, которые позволили Operator надёжно работать в продакшене на тысячах клиентских воркспейсов.

Если вы технический руководитель, оценивающий, стоит ли строить нечто подобное самостоятельно, или пытаетесь понять разницу между хорошо настроенным LLM и production-системой Агента — это для вас.

Как выбраться из ловушки «это же просто LLM»

Большинство инженерных команд, которые исследуют это пространство, начинают одинаково: с прототипа. Берёте базовую модель, даёте ей доступ по API к данным поддержки, добавляете системный промпт с доменным контекстом — и вот у вас есть нечто, что обращается к вашей базе данных, суммирует тикеты и генерирует отчёты, которые выглядят правильно. Демонстрация выглядит убедительно.

Проблема такого прототипа в том, что он скрывает реальный масштаб того, что на самом деле требуется. Он демонстрирует те 10% системы, которые легко построить, и возникает соблазн предположить, что и остальное столь же просто. Это не так. Разрыв между работающим демо и production-системой, на которую ваша команда полагается ежедневно, — это и есть то место, где сосредоточена основная часть инженерных вложений.

В Operator мы глубоко вложились в каждый слой: инструментарий, рассуждение, то, как Агент совершает действия, и инфраструктуру, которая делает его надёжным в масштабе. Вот более подробный взгляд.

Слой инструментария

Первое, с чем нам пришлось столкнуться, — это то, что очевидный подход (дать модели доступ к вашим API и позволить ей самой во всём разобраться) не выдерживает в продакшене. Модель принимает разумные решения для простых запросов, но при работе с тысячами клиентских воркспейсов с разными конфигурациями, моделями данных и паттернами использования подхода «разберись сама» оказывается далеко не достаточно точным.

Что вам нужно — это специально созданный инструментарий: инструменты, которые кодируют решения о том, какие данные извлекать, как их структурировать, какой контекст включать, а что оставить за рамками. У Operator более 50 таких инструментов и 10 навыков (skills).

Инструмент (tool) — это одно действие, которое выполняет Operator (поиск контента, выполнение запроса, просмотр диалога). Навык (skill) связывает несколько инструментов вместе для выполнения целой задачи — например, отладки диалога от начала до конца, развёртывания обновления контента по всему справочному центру или выявления следующей возможности для автоматизации.

Разница между использованием тонких обёрток вокруг API-эндпоинтов и специально созданным инструментарием проявляется в чём-то столь, казалось бы, простом, как вопрос о производительности. Когда вы спрашиваете «как Fin справился на прошлой неделе?», наивная реализация выполняет запрос и возвращает вам таблицу. Operator же запускает инструмент отчётности, который определяет, какие метрики релевантны для вашего конкретного воркспейса, какие из них значимы для вашего конкретного вопроса и что эти числа реально означают в контексте, давая гораздо более содержательный ответ, с которым можно сделать что-то осязаемое.

Разработка такого поведения заняла месяцы инженерной работы. Не потому, что какая-то отдельная часть концептуально сложна, а потому, что добиться правильной работы по всему диапазону клиентских воркспейсов, конфигураций и пограничных случаев — это итеративный процесс. Вы это строите, тестируете на реальных диалогах, находите случаи, где оно ломается, исправляете их и повторяете. Короткого пути нет.

Слой интеллекта

Слой инструментария решает, что делать, но под ним лежит более трудная задача: понять, что вообще стоит делать и почему. Это тот слой, который заставляет Operator понимать ваш бизнес, а не просто обращаться к нему с запросами. В него входят три компонента:

1. Семантический поиск

В отличие от решений, полагающихся на совпадение ключевых слов, Operator использует систему, которая понимает, о чём контент, а не только какие слова в нём содержатся. Когда он ищет по вашему справочному центру, он использует тот же движок семантического поиска, который мы годами оптимизировали для самого Fin. Это система извлечения данных, настроенная на миллионах реальных диалогов поддержки, с характеристиками точности (precision) и полноты (recall), которые мы измеряли и непрерывно улучшали.

2. Осведомлённость об атрибутах

Operator имеет доступ к вашим данным и знает, что значимо для разных вопросов. Он знает, какие метрики реально используются в вашем воркспейсе, какие пользовательские атрибуты несут сигнал, а какие поля заполнены в отличие от фактически пустых. Мы создали специальные навыки, которые дают Operator это мета-знание, так что, исследуя вопрос о производительности, он смотрит на правильные вещи, а не галлюцинирует выводы из разрежённых данных.

3. Интеллектуальное рассуждение

Хорошо построенный Агент может ответить на ваш вопрос и предугадать, что вам следует спросить дальше. Если вы спросите Operator о всплеске эскалаций, он не просто скажет: «эскалации выросли на 23% неделя к неделе». Он продолжит и расскажет вам, почему это произошло, изучив эскалированные диалоги и выявив, что непропорционально большое их число касалось конкретной продуктовой области, после чего проверит, актуален ли соответствующий справочный контент, и, если нет, предложит обновление.

Эта цепочка рассуждений — не промпт-инжиниринг. Она закодирована в навыках, которые мы построили и отточили на паттернах, которые видим по всей нашей клиентской базе.

Слой действий

Именно здесь инженерная сложность возрастает на порядок, потому что вместо того чтобы просто анализировать проблемы и рекомендовать решения, Operator сам совершает действия для их решения. Он может обновлять правила Guidance, составлять и публиковать справочные статьи, создавать Procedures, настраивать коннекторы данных и изменять вашу конфигурацию Fin.

Каждое из этих действий должно быть безопасным, обратимым и поддающимся аудиту. Аналитический инструмент, который иногда возвращает неверное число, раздражает. Но Агент, который иногда применяет неверное изменение конфигурации к работающей системе поддержки, — это проблема совсем другой категории.

Чтобы это предотвратить, мы построили надёжную систему предложений, в которой каждое изменение, предлагаемое Operator, представлено как проверяемый diff. Вы видите ровно то, что изменится, прежде чем что-либо будет применено, с возможностью принять, отклонить или доработать. Ничто не вступает в силу без вашего явного одобрения.

Что ещё выделяет Operator

Помимо технических сложностей, которые приводят Operator в действие за кулисами, мы также упорно работали над тем, чтобы создать отличный пользовательский опыт.

Интерфейс, который одновременно диалоговый и графический, а не что-то одно

Operator сочетает диалоговое взаимодействие со специально созданными графическими компонентами:

Diff'ы предложений, показывающие ровно то, что изменится в статье. Встроенные графики, визуализирующие тренды производительности. Дашборды, отрисовываемые прямо внутри ветки диалога.

Это значит, что когда менеджер по знаниям просматривает предложенное обновление контента, он видит структурированный diff, а не стену сгенерированного LLM текста. Когда руководитель команды спрашивает о недельной производительности, он получает график с понятными осями и контекстом, а не абзац, приблизительно описывающий данные прозой.

Построить такой гибридный интерфейс крайне трудно без нативной интеграции с платформой. В чат-интерфейсе или CLI вы ограничены текстовым выводом; в отдельном дашборде вы теряете диалоговый контекст.

Operator делает и то, и другое в одной ветке, так что каждое взаимодействие детально и насыщено контекстом.

Он живёт там, где ваша команда уже работает

Operator встроен в ту же платформу, которой ваша команда пользуется каждый день. Это не отдельный инструмент с отдельным логином и не Slack-бот, которого настроил ваш инженер и о котором знают всего три человека. Он работает ровно там, где находитесь вы, рядом с диалогами, статьями справочного центра, рабочими процессами и данными, с которыми вы работаете.

Это помогает сократить расстояние между обнаружением проблемы и её решением: когда ваш менеджер по знаниям замечает устаревшую статью при просмотре диалога Fin, Operator может предложить исправление в той же сессии. Когда руководитель команды утром замечает всплеск эскалаций, он может попросить Operator разобраться, не переключая инструменты, не дожидаясь выгрузки данных и не заводя тикет для вашей инженерной команды.

Кастомный инструмент всегда будет жить вне рабочего процесса. Инженер его строит, поддерживает и зачастую остаётся единственным, кто умеет им пользоваться. Operator доступен любому, кто может задать вопрос обычным языком, что превращает его в систему, на которой работает вся ваша команда.

Накопительное преимущество

Каждый клиент, использующий Operator, чему-то нас учит. Мы видим, какие подходы к отладке работают в разных типах операций поддержки, узнаём, какие структуры контента показывают себя лучше, и можем выявлять стратегии автоматизации, которые стабильно срабатывают. Эти паттерны кодируются обратно в навыки и инструменты Operator.

Когда мы обнаруживаем, что определённая последовательность шагов расследования надёжно выявляет первопричину всплеска эскалаций, мы встраиваем это в диагностический навык Operator. Когда мы находим, что конкретный способ структурирования справочных статей ведёт к более высокому уровню решения проблем Fin'ом, мы кодируем это в навык создания контента. Наша инженерная команда непрерывно выпускает улучшения на основе того, что мы наблюдаем по всей клиентской базе.

Кастомное решение даёт вам ровно то, что вы построили, — то есть оно не становится умнее, пока вы не вложите инженерные ресурсы в то, чтобы сделать его умнее. А это значит ресурсы, не потраченные на ваш основной продукт.

Мы не запираем дверь

Некоторые команды хотят строить собственных Агентов. Некоторые из наших самых технически продвинутых клиентов так и делают. Но когда вы это делаете, вы работаете с сырыми API и строите собственный инструментарий поверх них. Когда вы используете Operator, вы работаете с системой, которая уже знает, какие вопросы задавать, понимает ваши данные и кодирует лучшие практики, которые мы извлекли из работы с тысячами команд поддержки.

Недавно мы запустили Fin CLI, что означает, что вы можете использовать сторонних агентов, таких как Claude Code или Cursor, для взаимодействия с вашими данными и конфигурацией Fin. Эта дверь открыта. Что мы надеемся прояснить этой статьёй — это всё то, что входит в создание Operator:

Более 50 инструментов и 10 навыков, специально созданных для операций поддержки. Годы вложений в семантический поиск. Глубокая интеграция с каждым слоем стека Fin. Система предложений. Слой интеллекта. Инфраструктура надёжности.

Если вы всё же хотите двигаться вперёд и строить кастомное решение, вот честная оценка:

Полезный инструмент только для чтения можно построить за недели. Он будет обращаться к вашим данным, суммировать тикеты и генерировать отчёты, но превращение его в production-систему займёт кварталы. Надёжность, безопасность, обработка пограничных случаев, изоляция данных в мультитенантной среде и плавная деградация — всё это важные архитектурные решения, которые нужно принять правильно с самого начала.

Слой действий — это также то место, где вы рискуете застрять. Перейти от «вот что не так» к безопасному внесению изменений в production-систему — это принципиально иная инженерная задача, чем анализ. Большинство DIY-проектов до этого так и не доходят.

Наконец, вам придётся поддерживать это вечно. Каждое обновление модели, изменение API и новая возможность вашей платформы поддержки означают необходимость обновлять ваш кастомный инструментарий. У нас есть команда, выделенная для этого. Вам тоже понадобится такая.

Наш CTO Darragh Curran написал подробную статью о плюсах и минусах создания собственного AI-Агента против его покупки — её стоит прочитать. Экономика по-прежнему на стороне покупки, когда вендор вложил в проблему больше, чем вы можете оправдать внутри компании. Что, я надеюсь, добавляет эта статья — это более ясную картину того, как такие вложения на самом деле выглядят с инженерной точки зрения.

Вложения продолжаются. Проблемы, которые мы решаем на уровне инфраструктуры сегодня, труднее тех, что мы решали год назад, и эта траектория не замедляется.