Корпоративная нейросеть — рабочий контур, который отвечает по разрешённым данным компании, учитывает роль сотрудника и сохраняет след ответа. Модель здесь только один компонент: качество зависит от источников, поиска и проверки прав. Архитектуру выбирают по типу данных и допустимым действиям пользователя.
Состав контура
Четыре опоры корпоративного контура: источники, поиск, права доступа и журнал ответов. Замена модели без этих частей редко исправляет ошибки на данных компании.
Сотрудник задаёт вопрос через внутренний интерфейс. Система определяет его роль, ищет разрешённые документы, передаёт найденные фрагменты модели и показывает ответ со ссылками. Если подтверждённого фрагмента нет, ответ сообщает об отсутствии данных. Такая схема подходит для регламентов и справочной информации; действия в CRM или 1С требуют отдельного контура разрешений и подтверждения.
База знаний — только слой источников. Материал о том, как собрать корпоративную базу знаний, разбирает подготовку документов. Здесь важен полный путь запроса: от учётной записи пользователя до журналирования результата. Статья про архитектуру RAG помогает детально понять поиск и сборку контекста.
Начните с карты данных: папки, владелец, частота изменения, ограничения доступа и признак архивной версии. Документ без ответственного быстро устаревает. Если в хранилище уже смешаны рабочие и архивные копии, нейросеть будет уверенно цитировать обе. Очистка источников в таком случае важнее настройки длины ответа или тона модели.
Для каждого слоя запишите владельца и процедуру изменения. Поиск обновляет индекс, права проверяет корпоративная система, модель формирует ответ, журнал хранит след проверки. При сбое команда сразу поймёт, кто отвечает за исправление.
Доступ по ролям
Право на документ проверяют до передачи текста модели. Если сотрудник видит только свой отдел, поиск выполняется внутри разрешённого набора, без поиска среди всех файлов и последующей маскировки ответа. Дополнительно проверяйте права на уровне фрагментов: один общий документ может содержать приложение с ограниченным доступом. Правила наследования из хранилища нужно описать явно.
| Слой | Основной вопрос | Контроль |
|---|---|---|
| Учётная запись | Кто задаёт вопрос | Вход через корпоративную систему |
| Поиск | Какие фрагменты доступны | Фильтр по роли и документу |
| Ответ | Что можно показать | Ссылки и проверка разглашения |
| Журнал | Кто видит историю | Доступ для ответственных ролей |
Тестируйте права на парах ролей: обычный сотрудник и руководитель, новый работник и HR, отдел продаж и финансовая команда. Для каждого вопроса заранее задайте ожидаемый список разрешённых источников. Модель может составить связный ответ даже по случайно попавшему фрагменту; такая утечка должна обнаруживаться тестом доступа, без оценки красоты текста.
Журнал хранит идентификатор пользователя, использованные версии источников, выбранные фрагменты, ответ и отметку о последующей правке. Срок хранения и состав записи определяют по политике компании. Тексты личных обращений требуют особого режима доступа; для технической статистики часто хватает обезличенных событий.
Проверьте отзыв доступа на тестовом пользователе. После смены роли старые фрагменты должны исчезнуть из результатов поиска и истории доступных диалогов. Такой тест часто выявляет задержки синхронизации, которые незаметны при обычной демонстрации.
Проверяемые ответы
Ответ должен показывать, на какие документы он опирается, и различать цитату источника и вывод модели. Для регламентного вопроса настройте формат: краткий ответ, ссылки на конкретные разделы, дата документа и предложение обратиться к владельцу при споре. При противоречии источников система выводит обе версии и указывает их владельцев. Уверенное объединение несовместимых правил опаснее явного сообщения о конфликте.
- Подготовьте проверочные вопросы по обычным, спорным и запрещённым для роли темам.
- Зафиксируйте ожидаемые источники и допустимый ответ для каждой роли.
- После обновления документов повторяйте набор тестов и просматривайте журнал расхождений.
Условный запрос касается правила командировок. В поиске лежат новый регламент и старый шаблон заявления. Система должна ответить по действующему регламенту, а архивный документ исключить. Если статус версии утрачен, выводите вопрос владельцу политики. Настройка модели под старый текст оставляет проблему отсутствия метаданных у источника.
Проверка RAG-базы знаний для компании полезна на уровне наполнения. Для архитектуры дополнительно измеряйте долю ответов с верным источником, случаи избыточного доступа и число запросов, переданных человеку. Именно эти показатели показывают, насколько система пригодна для ежедневной работы.
Проверьте один и тот же вопрос под разными ролями: ответ должен ссылаться только на документы, доступные вошедшему сотруднику.
Где в вашей базе знаний проходят границы доступа?
Добавьте в контрольный набор вопросы без ответа в источниках. Система должна признать пробел и указать владельца темы. Если она сочиняет убедительное правило, исправляйте настройку выдачи и проверяйте, какие фрагменты попали в контекст.
Граница модели
Для корпоративного контура можно использовать модель в сервисе вендора напрямую или открытые веса на своём либо арендованном сервере. В первом случае проверьте условия обработки данных и оплаты; во втором — ресурсы инфраструктуры и порядок эксплуатации. Выбор маршрута фиксируют вместе с перечнем данных, разрешённых к передаче.
На старте можно сравнить GigaChat и YandexGPT на одинаковом наборе внутренних вопросов, если их условия соответствуют политике компании. Сначала сравните точность ссылок и соблюдение прав доступа, затем — ясность ответа. Модель с гладкой речью может пропустить оговорку в регламенте. Для локального контура отдельно проверьте карточку выбранной модели, требования к оборудованию и способ обновления весов.
Ответы по документам и действия в системах требуют разных разрешений. Чтение справки допускает показ источника. Изменение карточки клиента или создание платёжного документа требует проверки пользователя, предварительного показа параметров и журнала подтверждения. Так ограничение задаётся на уровне процесса, вместе с проверкой инструкции модели.
По нашему опыту внедрений, набор контрольных вопросов следует пересматривать после каждого крупного изменения источников. Тесты помогают заметить деградацию поиска и прав доступа даже тогда, когда общая оценка ответов на демонстрации остаётся высокой.
Выделите отдельную процедуру обновления модели. Новая версия способна изменить формат ответа и поведение при пустом контексте. Прогон контрольных вопросов перед переключением покажет, сохраняются ли ссылки, отказ при отсутствии источника и границы ролей.
Ввод в работу
Первую очередь ограничьте одним подразделением и источниками с ясным владельцем. Настройте вход, поиск, журнал и ручной разбор спорных ответов. Сотрудникам сообщите, что ссылка на документ важнее уверенного тона модели. Затем собирайте обращения, где источник отсутствует или права назначены неверно; эти случаи дают план улучшений для базы и ролей.
Проверьте путь одного вопроса целиком: от входа сотрудника до ссылки на действующий документ и записи в журнале. Любой разрыв в этой цепочке оформите как отдельную задачу владельцу слоя.
Страница о внедрении ИИ в компании помогает обсудить состав работ по интеграции и эксплуатации. На оценку влияют количество источников, сложность прав, требования к журналу и способ размещения модели. Стоимость обсуждают после обследования этого контура. Страница корпоративного чата с документами показывает частный интерфейсный вариант, но архитектурные требования остаются теми же.
Назначьте владельцев источников, доступа и качества ответов. Еженедельный разбор ошибок должен завершаться изменением документа, прав, поиска или инструкции, с конкретным результатом вместо общего пожелания «сделать ответы лучше». Сохраняйте контрольный набор вопросов и причину каждой правки: это позволяет увидеть, какое изменение действительно улучшило работу системы.
Сотрудники должны иметь простой способ отметить ошибку ответа. Отметка попадает владельцу источника или администратору поиска вместе со ссылкой на журнал. Без маршрута обратной связи даже хорошие тесты перед запуском быстро теряют актуальность.