Оценка ваших потребностей в ИИ

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

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

Команды часто используют понятия «навыки» (skills) и «плагины» (plugins) как взаимозаменяемые с размещаемыми ИИ-ассистентами и системами, и могут называть одну и ту же ИИ-возможность «агентом». Эти термины описывают разные части проектирования: как мы упаковываем и предоставляем возможность, а также какой степенью свободы она обладает во время выполнения.

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

Владение и поведение во время выполнения

Наше первое решение касается упаковки и владения: что мы создаем и как люди получают к этому доступ.

• Навык (skill) упаковывает инструкции и вспомогательные ресурсы для повторяющегося рабочего процесса.
• Плагин (plugin) упаковывает навыки и инструменты для распространения через поддерживаемый ИИ-хост.
• Размещаемый ИИ-ассистент (hosted AI assistant) упаковывает настроенный диалоговый опыт, который люди могут использовать напрямую через существующую ИИ-платформу.
• ИИ-система (AI system) помещает модель внутрь приложения, которое мы создаем и эксплуатируем, предоставляя нам право владения интерфейсом и бэкендом, а также доступ к данным и элементам управления.

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

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

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

Когда достаточно навыка

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

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

Когда подходит размещаемый ИИ-ассистент

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

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

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

Когда нам нужна система

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

Окружающие компоненты важны не меньше, чем вызов модели: поиск (retrieval) удерживает ответы в рамках актуального контента, а защитные барьеры (guardrails) блокируют недопустимые действия. Оценка проверяет, улучшают ли изменения функцию, в то время как наблюдаемость (observability) записывает, какие источники и инструменты сформировали ответ в рабочей среде.

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

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

Когда добавлять поведение агента

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

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

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

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

Последовательность принятия решений

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

• Где должен находиться пользовательский опыт? Существующий ИИ-хост может уже охватывать целевых пользователей, поэтому повторно используемый пакет или размещаемый ИИ-ассистент могут быть достаточными. Опыт, который принадлежит нашему приложению, требует системы, которую мы контролируем.

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

• Что мы пытаемся использовать повторно? Повторяющаяся процедура указывает на навык, который можно упаковать как плагин, если процедуру нужно установить вместе с инструментами. Настроенный диалоговый опыт указывает на размещаемого ИИ-ассистента.

Что мы пытаемся использовать повторно? Повторяющаяся процедура указывает на навык, который можно упаковать как плагин, если процедуру нужно установить вместе с инструментами. Настроенный диалоговый опыт указывает на размещаемого ИИ-ассистента.

• Что мы должны контролировать? Подключения к сервисам размещаемого ИИ-ассистента остаются в рамках продукта и модели управления хоста. Аутентификация, принадлежащая продукту, и данные клиентов с правами доступа указывают на систему, так же как записи аудита и управление выпуском.

Что мы должны контролировать? Сервисные подключения размещенного ИИ-помощника остаются в рамках продукта и модели управления хоста. Аутентификация, принадлежащая продукту, и данные клиентов с ограниченным доступом указывают на систему, так же как записи аудита и управление релизами.

• Можем ли мы определить шаги заранее? Известный путь относится к обычной оркестрации приложений; изменяющийся путь, требующий выбора инструментов и восстановления, может оправдать поведение агента внутри этой системы.

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

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

Как сочетаются варианты

Одна возможность может объединять несколько вариантов: команда разработчиков может сохранить свой метод проверки запросов на включение (pull request) как навык и упаковать этот навык в виде плагина, когда более широкой группе потребуется установить этот рабочий процесс на совместимую ИИ-платформу.

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

Заключение

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

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

Чтобы узнать больше о создании приложений и агентов на базе ИИ с помощью Progress, ознакомьтесь со следующими ресурсами:

• Инженерные решения Progress AI
• Progress Agentic RAG