ИИ-агенты в базе знаний: как они работают и какие задачи бизнеса могут решать

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

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

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

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

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

В современных реализациях в качестве «движка» для понимания задачи и планирования чаще всего используется большая языковая модель (LLM). Однако это не обязательное условие: архитектура агента может строиться и на других механизмах рассуждения — например, на правилах, символьных планировщиках или специализированных ML-моделях. Поэтому корректнее говорить, что LLM — распространённый, но не единственный вариант реализации ИИ-агента.

ИИ-агент состоит из следующих компонентов:

Допустим, менеджеру по продажам нужно подготовить отчёт по переговорам с новым клиентом. Сценарий может выглядеть так.

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

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

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

Несколько агентов может потребоваться в случаях, когда задача предполагает:

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

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

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

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

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

На итоговом этапе агент готовит список тем и вопросов, которые нужно доработать, и указывает, чего в них не хватает.

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

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

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

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

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

Что должно быть в Базе знаний:

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

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

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

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

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

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

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

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

При этом первичная разработка может остаться на стороне вендора — всё зависит от сложности задачи и компетенций пользователей Базы знаний. Но даже если разработкой агента будет заниматься вендор или сторонний подрядчик, при переиспользовании и адаптации к новым сценариям уже не потребуется высокий уровень квалификации. С такой задачей справится аналитик. Это снижает зависимость от разработчиков и позволяет постепенно масштабировать агентные сценарии внутри компании.

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

Это следующий логичный шаг в развитии KMS-платформ: повышение продуктивности сотрудников и более глубокая интеграция базы знаний в рабочие процессы.

InKnowledge — это no-code платформа для создания единой базы знаний внутри компании. Она позволяет собирать и систематизировать всю рабочую информацию и легко ориентироваться в ней.

Платформу можно настроить под разные отделы, создавая независимые порталы, и управлять доступом к данным. Благодаря встроенному AI-помощнику, пользователи могут быстро находить нужные сведения и удобно работать с большими объемами информации, а совместное редактирование помогает команде работать над проектами в режиме реального времени.

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