Как сделать корпоративного ИИ-помощника, которому можно доверять

Кому и зачем это читать

Статья пригодится руководителю или ИТ-специалисту, если сотрудники:

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

После разбора вы поймёте:

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

Ассистент отвечает настолько хорошо, насколько хорошо подготовлены данные

Идея «подключить чат к документам» звучит просто. На практике знания компании редко лежат в одном аккуратном справочнике. Они распределены между внутренней вики, сетевыми папками, почтой, учётной системой и CRM.

Если загрузить всё без подготовки, помощник столкнётся с типичными проблемами:

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

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

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

Почтовый архив нужно очищать до поиска

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

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

Перед загрузкой архива стоит:

1. объединить сообщения в цепочки по служебным заголовкам;
2. отделить новый текст от процитированной переписки;
3. удалить повторяющиеся подписи и технический шум;
4. только после этого разделить письма на фрагменты для поиска.

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

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

Документу нужны не только фрагменты, но и смысловые ориентиры

Регламент обычно написан формальным языком. Сотрудник формулирует запрос иначе: «что делать, если клиент просит перенести оплату» или «кто согласует возврат оборудования».

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

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

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

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

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

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

Для таких данных нужен другой путь:

1. помощник понимает, какая информация нужна;
2. вызывает инструмент для конкретной системы;
3. получает текущий результат;
4. формирует ответ с указанием источника.

Учётную систему можно подключить через OData или отдельный HTTP-сервис, CRM - через REST API. Интеграции удобно оформлять как отдельные инструменты, чтобы один и тот же доступ использовать в разных интерфейсах и не переписывать его при замене модели.

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

Права доступа должны проверяться вне модели

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

Ограничения нужно задавать технически:

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

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

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

Проверять нужно не модель, а рабочие сценарии

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

Такой набор помогает проверить:

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

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

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

Что сделать

Начните не с выбора модели, а со списка источников и 50-100 реальных вопросов сотрудников. Затем разделите данные на два потока: стабильные документы для индекса и оперативные сведения, которые помощник будет получать напрямую с проверкой прав.