Короткий ответ. База знаний помогает ИИ-агентам использовать проверенные сведения о компании, но сама по себе не превращает их в автономную команду. Для надёжной работы нужны источники с владельцами и сроком действия, разграничение прав, роли, сценарии, проверка действий и понятная передача человеку. Внешний контакт и изменение CRM следует отделять от подготовки рекомендации.
Какие сведения положить в базу
Начните с документов, которые сотрудники реально используют: описание продукта, условия, процессы, типовые вопросы, глоссарий, шаблоны и правила эскалации. Для каждой записи укажите источник, владельца, дату проверки, аудиторию и ограничения применения. Черновики, архивные материалы и утверждённые положения должны быть различимы.
Полезная единица — не файл целиком, а ответ на рабочий вопрос с ссылкой на первоисточник. Например: «Какие условия пилота можно предлагать?» — короткий ответ, действующий документ и случаи, когда нужно согласование. Если два документа противоречат друг другу, агент должен сообщить о конфликте и остановиться, а не выбирать наиболее убедительную фразу.
Не загружайте без разбора всё, что есть у компании. В источниках могут быть персональные данные, коммерческие условия конкретного клиента, устаревшие инструкции и документы с разными уровнями доступа. Сначала составьте каталог, назначьте владельца и решите, какие роли могут читать каждый раздел.
Как связать знания с рабочим потоком
ИИ-офис удобно понимать как маршрут:
контекст компании → задача → роль агента → найденные основания → предложение действия → проверка → передача результата.
Маркетолог может подготовить гипотезу сегмента на основании утверждённого предложения. Агент продаж — собрать факты о компании-кандидате и отметить, чего не удалось проверить. CRM-роль — предложить черновик карточки, который сотрудник проверяет перед сохранением. Это пример архитектуры работы; не следует считать, что все перечисленные действия доступны автоматически без настройки.
У каждой роли должны быть чёткие границы: какие данные читает; какие инструменты вызывает; что может только предложить; что требует подтверждения; как сообщить о неизвестном. Нужны и правила отказа. Например, если источник не открывается или критерий не подтверждён, агент возвращает кандидатуру на проверку.
Поиск потенциальных клиентов через базу знаний
Цикл поиска начинается не с выгрузки списка организаций, а с формулировки гипотезы: кому подходит продукт и какой сигнал указывает на возможную задачу. Далее агент ищет в разрешённых источниках, прикладывает ссылку и дату, сравнивает компанию с критериями и формирует краткое обоснование. Дубликаты и качество фактов проверяются до создания записи.
В CRM должен появиться не только список имён. Нужны происхождение данных, основание соответствия, дата проверки, уровень неопределённости, владелец и следующий шаг. Внешнее письмо, звонок или создание сделки — отдельная стадия с разрешениями, лимитом и подтверждением. Такое разделение позволяет проверить качество поиска, не начиная массовый контакт.
Как проверять знания и ответы
Сформируйте набор типовых вопросов: прямой факт, сочетание двух документов, устаревшая версия, противоречие и ситуация, в которой ответа нет. Для каждого сохраните ожидаемый источник и критерии корректного отказа. Проверяйте не только текст ответа: если агент использует инструмент, нужно посмотреть фактический вызов и результат, а не полагаться на фразу «я сделал».
Версионируйте источники, инструкции и сценарии отдельно. После изменения базы повторите тесты на тех же вопросах. Отслеживайте устаревшие ответы, неверные ссылки, пропуски, утечки контекста между ролями и действия без нужного подтверждения.
Для каждого процесса назначьте человека-владельца. Он отвечает за актуальность фактов, разбор инцидентов и остановку роли при проблеме. Автоматизация без владельца превращает исключение в незамеченную норму.
Везория и ИИ Офис
Везория показывает рабочую среду с ролями, задачами и контекстом компании. Важный пользовательский маршрут — перейти от базы знаний к конкретной задаче, увидеть основания рекомендации и проверить следующий шаг. В составе проекта отдельно уточняются подключённые источники, каналы и разрешённые действия.
Смотрите ИИ Офис Везории, корпоративную базу знаний, базу знаний для ИИ-агента и аудит процесса перед ИИ.
Жизненный цикл записи в базе знаний
Каждому материалу нужны статус, владелец, версия и дата следующего пересмотра. Опишите, как сотрудник предлагает правку, кто её проверяет и что происходит с архивной версией. Если изменения условий попадают в CRM, коммерческую презентацию и сайт в разное время, владельцу базы нужно видеть конфликт.
Для критичных сведений добавьте подтверждение актуальности и аудиторию. Цены, условия пилота, функции и сроки особенно чувствительны. При запросе на такой факт агент должен возвращать источник и дату, а не опираться на похожий старый документ. Срок действия можно задавать по типу информации.
Разделение полномочий по ролям
Доступ к знаниям и инструментам не должен быть одинаковым у всех агентов. Маркетологу могут быть доступны публичные продуктовые факты и утверждённые примеры. Агенту CRM — часть операционных полей и действия, необходимые для черновика. Руководитель утверждает внешние обещания и изменения с существенными последствиями.
Проверьте не только позитивный сценарий, но и попытку получить запрещённую информацию через цитату, вложение или переписанный запрос. Для каждого типа роли задайте тесты чтения и действия. Если инструмент доступен системе, промпт не всегда достаточен как ограничение; применяйте реальные права на стороне интеграции.
Управляемый цикл поиска клиентов
Разделите этот процесс на независимые этапы: сформировать критерий из базы знаний; искать доступные компании в утверждённом источнике; сохранить ссылку и дату; проверить соответствие; сопоставить с CRM; предложить следующий шаг; принять решение о контакте. На первом запуске ограничьтесь подготовкой списка для человека. Это покажет, что качество поиска и критериев достаточно, прежде чем появятся внешние действия.
Создайте очередь проверки с понятными статусами: новый кандидат; факты подтверждены; нужна дополнительная проверка; не подходит; возможный дубль; готов к решению. Не смешивайте отказ по профилю с отсутствием данных. У каждого кандидата должен быть путь закрытия, чтобы список не превращался в бесконечную накопительную папку.
Пример диагностики сбоя
В демонстрационной ситуации агент предлагает написать компании, потому что на сайте указано несколько филиалов. Менеджер отмечает, что продукт предназначен только организациям с самостоятельной обработкой входящих обращений; на сайте кандидата этот процесс не подтверждён. Это не доказывает плохую работу модели: возможно, критерий поиска был задан слишком широко или источник не раскрывает нужный факт.
Разбор должен ответить: как сформулирован сегмент; какие поля агент увидел; почему счёл признак достаточным; есть ли правило для «неизвестно»; какая правка уменьшит похожие ошибки. Так команда улучшает критерии вместо того, чтобы просто просить агента «быть точнее».
Проверки перед расширением офиса
До подключения большего числа ролей проверьте на тестовом наборе: ответы на прямые вопросы; действия при пустом источнике; конфликты версий; сохранение ссылок; соблюдение прав; передачу задачи; повторные события; журналирование; поведение при недоступности CRM. Повторите набор после изменения модели, инструкции и источников.
В пилоте важно включить настоящих пользователей. Попросите их выполнить один рабочий сценарий без подсказки и запишите моменты, где они не понимают, что делает агент. Исправьте обозначения статусов и обратную связь, прежде чем добавлять больше функций. Качество интерфейса и процесса не измеряется количеством анимированных действий.
Владелец офиса и правила обновления
Назначьте человека, который согласует новые роли, источники и действия. Отдельно определите технического владельца интеграции и владельца бизнес-результата. Один сотрудник может совмещать несколько ролей в небольшом проекте, но ответственность всё равно должна быть явной.
Раз в установленный период разбирайте необработанные вопросы, конфликты документов, ручные корректировки и действия, которые не сработали. Результат обзора — изменения базы, инструкции или прав, а не только отчёт. Если роль не используется, выясните, мешает ли сценарий, доступ или отсутствие понятного преимущества.
ИИ-офис для бизнеса: что должно происходить внутри роли
Пользователь должен понимать, какую задачу выполняет агент, на какие сведения опирается и что изменится после подтверждения. В роли маркетолога это может быть гипотеза сегмента; в роли продаж — проверка компании; в роли координатора — передача задачи. Общее пространство помогает увидеть связи, но ценность появляется в конкретном действии и результате, который человек может принять.
У каждой задачи должны быть вход, выход и критерий готовности. «Найти клиентов» слишком широко. «Подготовить кандидатов по утверждённому профилю со ссылками и причинами отбора» уже позволяет проверить работу. При таком описании офис можно развивать по ролям, не обещая сразу полный автономный цикл компании.
Сохраняйте происхождение результата между ролями. Когда маркетолог передаёт критерии поисковому агенту, тот должен видеть их версию. Когда находка попадает в CRM-роль, вместе с ней передаются источники и ограничения. Если контекст каждый раз заново пересказывается без ссылок, ошибки будут накапливаться по цепочке.
Как построить первый раздел знаний
Выберите одну повторяющуюся задачу, например подготовку ответа на вопрос о внедрении. Соберите только необходимые сведения: что делает компания, кому подходит услуга, какие данные нужны, как начинается работа и какие условия нельзя обещать без обсуждения. Привяжите каждый существенный ответ к действующему документу или владельцу.
Проверьте набор на вопросах пользователя. Если агент не находит ответ, выясните, отсутствует ли факт, плохо ли он сформулирован или не подходит ли способ поиска. Не надо сразу загружать ещё больше документов. Иногда достаточно короткой утверждённой карточки, которая объясняет сложный факт и ссылается на подробный источник.
Соберите словарь компании: названия продуктов, сокращения, старые и новые термины. Он помогает интерпретировать запросы, но не должен скрывать изменение продукта. Если старое название больше не используется, отметьте это и укажите актуальное. Система должна различать историческую справку и действующее предложение.
Как агент превращает знания в гипотезу сегмента
Попросите роль объяснить связь между возможностью продукта и признаком компании. Например, распределённая команда может нуждаться в общем контексте работы, но наличие филиалов само по себе не доказывает конкретную проблему. Агент формирует гипотезу и вопрос для проверки. В карточке должны оставаться отдельно факт о кандидате и предположение о его задаче.
Для каждого сегмента задайте обязательные и исключающие условия. Гипотеза должна отвечать, чем выбранная группа отличается от общего списка компаний. Если разницы нет, поиск будет создавать много нерелевантных записей. Начинайте с узкого проверяемого варианта, а расширяйте его после обратной связи менеджеров.
Перед переходом к внешним источникам согласуйте допустимые страницы и поля. Это помогает удерживать исследование в рамках задачи и не собирать лишние данные. Поиск клиента не должен незаметно превращаться в накопление персональных профилей без понятной цели и срока использования.
Что происходит, когда роль не знает ответа
Предусмотрите несколько полезных исходов: нет источника; источники противоречат; не хватает прав; инструмент не ответил; вопрос выходит за рамки роли. Для каждого покажите пользователю следующий шаг. Например, передать владельцу базы, запросить уточнение или сохранить задачу на повтор. Один общий текст «произошла ошибка» не помогает продолжить работу.
Если источник недоступен, агент не должен ссылаться на него как на прочитанный. Если права не позволяют увидеть данные, нельзя обходить ограничение через другую роль или резюме. Результат должен отражать фактическое состояние. Эти случаи включают в тестовый набор наравне с обычными успешными задачами.
Отказ от ответа может быть качественным результатом. Важно, чтобы он был конкретным и не перекладывал весь процесс на пользователя. «Не найдено действующее условие пилота; запрос направлен владельцу раздела» полезнее, чем уверенная выдумка или неопределённое «уточните информацию».
Как показывать работу в интерфейсе офиса
Видимая активность должна соответствовать реальным этапам: изучает источник, сравнивает критерии, готовит черновик, ждёт решения, завершила задачу. Анимация не должна изображать отправленное письмо или созданную сделку, если фактического действия не было. В демонстрационном режиме это обозначают прямо и показывают условные данные.
При переходе к результату пользователь видит краткий ответ, основания и доступные решения. Для поиска это список кандидатов с причиной отбора. Для контента — материал с источниками. Для CRM — поля и найденные совпадения. Один общий чат может объединять обсуждение, но принятие существенных действий лучше отображать ясным отдельным шагом.
Сцену офиса полезно дополнять обычным доступным списком ролей и задач. Тогда человек может быстро перейти к нужному результату без ожидания движения камеры. Это особенно важно на мобильном устройстве и при слабом соединении. Визуальная среда помогает объяснить систему, а рабочий маршрут остаётся прямым.
Проверка цепочки ролей на одном примере
Возьмите учебную задачу и заранее опишите ожидаемый путь: роль прочитала утверждённое предложение, сформировала критерии, нашла подтверждение компании, отметила пробел и передала черновик человеку. На каждом переходе проверяйте, сохранилась ли ссылка на предыдущий шаг и не появилось ли новое неподтверждённое утверждение.
Затем внесите одно контролируемое изменение: устаревший документ, недоступная страница или уже существующая компания в CRM. Система должна отреагировать на изменение в нужном месте. Если она продолжает красивую последовательность независимо от входа, это демонстрация, а не подтверждение работающего процесса. Для продуктовой приёмки нужны реальные события и журналы.
Как оценить запуск офиса
Начните с одной задачи и нескольких пользователей, которые выполняют её регулярно. Измерьте весь маршрут: постановку, получение результата, проверку, исправление и дальнейшее действие. Попросите участников отметить, где им пришлось повторить контекст или искать источник самостоятельно. Эти затраты входят в реальную стоимость автоматизации.
Решение о следующей роли принимайте по итогам процесса. Если база знаний неактуальна, добавление нового агента увеличит число ответов из тех же проблемных данных. Если всё упирается в ручное одобрение, возможно, нужно изменить очередь и владельца. Развитие Везории стоит связывать с устранением конкретного ограничения, а не с количеством персонажей в офисе.
Первый маршрут для нового пользователя офиса
Дайте человеку выбрать роль и одну задачу без изучения всей сцены. Он должен увидеть, какие знания доступны, какой результат ожидается и где потребуется решение. После выполнения покажите ответ, источники и следующие действия. Если задача демонстрационная, обозначьте это до запуска, чтобы анимация не воспринималась как реальный поиск или внешний контакт.
Для более опытного пользователя полезен быстрый переход к очереди результатов. Пространственный офис объясняет связи ролей, а список помогает работать без лишних переходов. Оба представления должны отражать одно состояние. Нельзя показывать в сцене «завершено», если рабочая задача ещё ждёт проверки.
На приёмке попросите несколько сотрудников выполнить маршрут без подсказок автора. Сравните, понимают ли они основания и последствия кнопок. Если пользователь подтверждает действие, не прочитав, что изменится, исправьте представление. Цель ИИ-офиса — поддержать работу компании, поэтому понятность решения важнее числа визуальных эффектов.
Первичные материалы
- NIST AI RMF Playbook: Map — Описание контекста, границ применения и роли человека.
- REST API Битрикс24: CRM — Сущности, методы и связи CRM.
- OWASP: риски приложений с большими языковыми моделями — Обзор угроз и контрольных мер для приложений с LLM.