Перейти к содержанию

Сервисы Студии

Что вы узнаете

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

Главный принцип прост:

Модель может предложить использовать сервис, но окончательное разрешение определяет Студия.

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

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

1. Что такое сервис Студии

Обычная модель умеет работать только с теми сведениями, которые уже находятся в её контексте. Например, если спросить модель:

Какие виртуальные машины сейчас работают в нашем каталоге Яндекс Облака?

без подключённого сервиса модель не должна угадывать ответ. У неё нет права самостоятельно обращаться в облако.

Если администратор подключил системный сервис «YC — Инфраструктура», работа выглядит так:

вопрос пользователя
        ↓
модель определяет, что нужны актуальные данные
        ↓
Студия проверяет доступность сервиса
        ↓
Студия проверяет политику и права
        ↓
разрешённый запрос к сервису
        ↓
структурированный результат
        ↓
модель объясняет результат пользователю

Таким образом, сервис — это не «дополнительный разум». Это контролируемый способ получить данные или выполнить заранее разрешённую операцию.

2. Чем сервис отличается от модели

Эти понятия нельзя смешивать.

Сущность За что отвечает
Модель понимает запрос, рассуждает, формирует текст ответа
Сервис Студии получает данные или выполняет строго определённую операцию
ИИ-помощник задаёт постоянные инструкции, знания и набор доступных возможностей
Проект группирует связанные разговоры
База знаний хранит и ищет сведения в загруженных документах

Например, локальная модель может одинаково хорошо объяснить результат, полученный из Яндекс Облака, из корпоративной базы данных или из официальной документации. Источник данных и модель, которая объясняет эти данные, — разные части системы.

Это разделение важно для безопасности. Замена модели не должна автоматически менять права сервисов.

3. Какие бывают сервисы

В документации Студии удобно делить сервисы на четыре класса.

3.1. Системные сервисы Студии

Они входят в поставку и управляются администратором.

Примеры:

  • просмотр инфраструктуры Яндекс Облака;
  • поиск по официальной документации Яндекс Облака;
  • анализ расходов;
  • просмотр функций, контейнеров, триггеров и рабочих процессов;
  • поиск по каталогу данных.

Пользователь не указывает адрес такого сервиса и не передаёт ему собственные ключи.

3.2. Встроенные возможности

Некоторые функции выглядят для пользователя похоже на сервисы, но относятся к основным возможностям самой Студии:

  • поиск в интернете;
  • поиск по документам;
  • память;
  • навыки.

Для пользователя разница обычно несущественна. Для администратора она важна, потому что правила подключения и безопасности различаются.

3.3. Корпоративные сервисы

Организация может добавить собственный источник данных, например:

  • внутреннюю базу заявок;
  • систему наблюдения за инфраструктурой;
  • каталог оборудования;
  • внутреннюю документацию;
  • систему управления активами;
  • собственный финансовый сервис.

В текущей поставке 0.3.66 произвольные внешние подключения не создаются обычными пользователями через интерфейс. Такое подключение проектируется и публикуется администратором как часть управляемой конфигурации Студии.

3.4. Внешние сервисы

Это системы, расположенные за пределами контура организации. Их подключение требует отдельной оценки:

  • какие данные будут передаваться;
  • кто является владельцем сервиса;
  • где обрабатываются сведения;
  • какие ключи требуются;
  • можно ли ограничить права;
  • какие операции сервис способен выполнять.

Наличие технической возможности подключения не означает автоматического разрешения на использование внешней системы.

4. Чтение и изменение — принципиально разные операции

Каждая операция сервиса должна относиться как минимум к одному из классов риска.

Только чтение

Операция получает информацию, но не должна изменять состояние внешней системы.

Примеры:

  • показать список виртуальных машин;
  • получить состояние сети;
  • прочитать метрики;
  • получить сумму расходов;
  • найти страницу документации.

Даже чтение может раскрывать чувствительные сведения, поэтому «только чтение» не означает «безопасно для всех».

Изменение

Операция меняет внешнюю систему.

Примеры:

  • создать ресурс;
  • изменить настройки;
  • удалить объект;
  • остановить или запустить машину;
  • отправить сообщение;
  • изменить файл;
  • назначить права.

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

Запрещённая операция

Некоторые действия могут быть запрещены политикой всей Студии независимо от пользователя.

В текущем профиле 0.3.66:

  • изменение и удаление ресурсов через системные сервисы Яндекс Облака запрещено;
  • выполнение произвольного серверного кода запрещено;
  • создание пользователями произвольных внешних сервисов запрещено.

5. Пять независимых уровней контроля

Полезно представлять доступ к сервису не одним переключателем, а цепочкой.

1. Функция доступна роли пользователя?
        ↓
2. Сервис опубликован администратором?
        ↓
3. Операция разрешена политикой Студии?
        ↓
4. Нужно подтверждение пользователя?
        ↓
5. Внешняя система разрешила действие своими правами?

Если любой уровень отвечает «нет», операция не должна выполняться.

Например, даже если модель выбрала операцию чтения виртуальной машины, запрос не пройдёт, если служебная учётная запись Яндекс Облака не имеет нужной роли.

И наоборот: наличие широких прав у служебной учётной записи не должно автоматически разрешать модели все операции. Студия дополнительно ограничивает публикуемый набор возможностей.

6. Кто управляет сервисами

Пользователь

Обычный пользователь:

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

Администратор Студии

Администратор:

  • определяет, какие сервисы входят в поставку;
  • задаёт права использования;
  • определяет правила подтверждения;
  • подключает серверные секреты;
  • задаёт сетевые ограничения;
  • проверяет журналы и состояние;
  • выполняет приёмочные испытания перед выдачей пользователям.

Администратор внешней системы

Например, администратор Яндекс Облака:

  • выдаёт служебной учётной записи роли;
  • ограничивает область действия прав;
  • отзывает ключи;
  • контролирует собственный журнал событий.

Один администратор может совмещать несколько ролей, но сами уровни контроля всё равно остаются независимыми.

7. Что видит пользователь

Когда сервис нужен для ответа, пользователь обычно видит одно из трёх состояний.

Сервис используется автоматически

Такой режим допустим для заранее доверенных операций низкого риска.

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

Студия просит подтверждение

Это означает, что политика требует участия человека до отправки операции.

Перед подтверждением нужно проверить:

  • какой сервис будет вызван;
  • что он собирается сделать;
  • какие параметры передаются;
  • может ли действие изменить данные;
  • соответствует ли оно вашему запросу.

Операция запрещена

Если политика запрещает действие, подтверждение пользователя не должно обходить запрет.

Например, в текущем безопасном режиме пользователь не может «разрешить» изменение инфраструктуры Яндекс Облака, если шлюз публикует только операции чтения.

8. Как понять, что ответ действительно получен из сервиса

Не ориентируйтесь только на уверенный тон модели.

Проверьте:

  1. Был ли реально вызван нужный сервис.
  2. Вернул ли сервис успешный результат.
  3. Есть ли в ответе конкретные значения из результата.
  4. Не пишет ли модель, что «проверила систему», хотя вызова не было.
  5. Для критичных данных сравните часть результата с первичным источником.

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

9. Где проходит граница данных

При использовании сервиса в обработке могут участвовать три типа данных:

  • текст запроса пользователя;
  • параметры, которые модель сформировала для вызова;
  • результат, который вернул сервис.

Нужно заранее знать, куда они уходят.

Внутренний сервис

Если сервис размещён внутри инфраструктуры организации, сетевой обмен может полностью оставаться в собственном контуре.

Яндекс Облако

Запрос к сервисам Яндекс Облака уходит во внешние программные интерфейсы Яндекса через защищённый шлюз Студии. Авторизованный ключ и полученный IAM-токен при этом не добавляются в сообщения модели.

Сторонняя внешняя система

Перед подключением нужно отдельно определить её границу обработки данных и правила хранения.

10. Сервис не должен получать весь разговор без необходимости

Хорошая интеграция передаёт минимум данных, необходимых для конкретной операции.

Плохо:

отправить внешнему сервису весь диалог за последние два часа, хотя для запроса нужен только идентификатор сервера.

Лучше:

передать только идентификатор сервера и необходимые параметры чтения.

При проектировании собственного сервиса используйте принцип минимально необходимого контекста.

11. Вкладка «Параметры»

В текущем выпуске вкладка «Параметры» показывает корпоративный профиль поведения и безопасности.

Она нужна, чтобы пользователь и администратор могли быстро увидеть:

  • что разрешено автоматически;
  • где требуется подтверждение;
  • что полностью запрещено;
  • как защищено подключение к Яндекс Облаку;
  • где обрабатываются данные.

В версии 0.3.66 этот экран прежде всего показывает применяемые серверные правила. Он не является способом обойти или ослабить серверную политику из браузера.

Подробнее: Политики администратора.

12. Практический пример

Пользователь спрашивает:

Какие пять сервисов дали наибольший расход в этом месяце и что можно проверить в первую очередь?

Возможный ход работы:

запрос
  ↓
модель понимает, что нужны фактические расходы
  ↓
выбирается сервис расходов Яндекс Облака
  ↓
Студия проверяет роль пользователя и рабочую область
  ↓
сервис получает агрегированные данные
  ↓
модель отделяет факты от рекомендаций
  ↓
пользователь получает расходы + объяснение

Факт:

Сервис A — 12 500 ₽ за период.

Интерпретация:

Стоит проверить простаивающие ресурсы этого сервиса.

Эти две части нельзя смешивать. Первая должна происходить из полученных данных. Вторая является выводом ИИ.

13. Краткое правило выбора

Если задача требует только рассуждения над уже предоставленным текстом — сервис не нужен.

Если требуется актуальное состояние внешней системы, используйте разрешённый сервис.

Если требуется изменить внешнюю систему, убедитесь, что:

  • такое изменение вообще разрешено продуктовой политикой;
  • у пользователя есть нужное право;
  • внешняя учётная запись имеет минимальные полномочия;
  • действие требует подтверждения;
  • результат можно проверить;
  • событие попадает в журнал.

Что дальше