Коротко. Корпоративный ИИ ломается не на выборе модели, а на слое между данными компании и агентом. Документы, CRM, история проектов и переписка имеют разную достоверность, актуальность и уровень доступа — сложенные в одно хранилище, они дают не память компании, а свалку контекста. Enterprise Knowledge Layer — это слой, который отвечает на вопросы «что у нас есть», «насколько этому можно доверять», «кому это разрешено видеть» и «какие источники нужно объединить для этого запроса». Без него самая сильная модель уверенно работает с плохим контекстом.
Внедрение обычно начинается одинаково: берут документы, инструкции, презентации, договоры, регламенты, подключают поиск по векторам, добавляют модель — и получают чат, который отвечает по внутренним материалам. На демонстрации это выглядит хорошо.
Дальше начинается работа. Сотрудник спрашивает не «что написано в регламенте по закупкам», а:
- «У нас три клиента из финансового сектора. Покажи, какие похожие проекты мы уже делали, какие технологии использовали, сколько длилась реализация и какие ограничения возникали у заказчиков».
- «Сравни два последних коммерческих предложения, найди отличия в условиях и скажи, какой вариант ближе к текущему запросу».
- «На основе истории проектов предложи структуру нового решения и укажи, где риски».
Это уже не поиск документа. Это работа с корпоративным знанием — и именно здесь появляется отдельный архитектурный слой.
Почему поиска по документам недостаточно
Схему «документы → векторы → поиск → модель → ответ» описывают как решение. Для простых сценариев её хватает. Но в компании одновременно живут документы, CRM, учётные системы, базы данных, внутренние вики, презентации, договоры, тикеты, переписка, записи звонков, продуктовая и нормативная документация, финансовые данные, история проектов.
У этих данных разная ценность, актуальность и уровень доступа. Один документ — действующая политика компании. Второй — презентация пятилетней давности. Третий — рабочая заметка сотрудника. Четвёртый — конфиденциальная информация конкретного клиента. Сложенные в одно хранилище без различий, они дают не корпоративную память, а корпоративную свалку контекста.
Что делает слой корпоративного знания
Это промежуточный слой между данными компании и ИИ-приложениями. Его задача — не хранить, а отвечать на семь вопросов по каждому запросу.
| Вопрос | Что за ним стоит |
|---|---|
| Что у нас есть | Реестр источников, а не список папок |
| Где это находится | Единая точка обращения вместо десяти интеграций у каждого приложения |
| Насколько можно доверять | Статус документа: действующий, устаревший, черновик |
| Кому разрешено видеть | Права проверяются при выдаче фрагмента, а не в интерфейсе |
| Какой контекст нужен | Отбор под задачу, а не выдача десяти похожих текстов |
| Какие источники объединить | Ответ часто собирается из документа, записи в системе и истории проекта |
| Когда поиска мало | Часть запросов требует нескольких последовательных обращений |
Главная ошибка — начинать с модели
Разговор «нам нужен ассистент, давайте выберем модель» стоит развернуть: какими знаниями этот ассистент должен обладать, чтобы дать результат в конкретном процессе. Самая сильная модель не исправит плохую информационную архитектуру.
Если агент получает устаревшие документы, неполный контекст, не ту версию, нерелевантные фрагменты, данные без пометок и без проверки прав — он уверенно отработает с плохим контекстом. Со стороны это выглядит как проблема модели, хотя это проблема организации знания.
Четыре типа знания — и почему их нельзя обрабатывать одинаково
| Тип | Что относится | Что критично |
|---|---|---|
| Официальное | Политики, регламенты, утверждённые прайсы, юридические документы, продуктовая документация | Версия, срок действия, владелец |
| Рабочее | История проектов, решения команд, тикеты, внутренние инструкции, разборы инцидентов | Практической информации здесь обычно больше, чем в официальных документах |
| Опытное | Выводы после проектов, кейсы, комментарии, заметки, решения со встреч | Самое ценное неявное знание — и самое плохо оформленное |
| Структурированные данные | CRM, учётные и финансовые системы, продуктовые и кадровые базы | Часто правильнее выполнить обычный запрос к системе, а не превращать в векторы |
Поиск и рассуждение — разные задачи
Возьмём запрос: «Какие наши проекты в Казахстане были связаны с модернизацией инфраструктуры банков и какие технологии там использовались?»
Обычный поиск по смыслу найдёт несколько похожих документов. Рабочий сценарий требует последовательности: определить сущности, понять, что речь о проектах, отфильтровать географию, найти релевантные проекты, собрать информацию из нескольких источников, сопоставить технологии, отбросить лишнее и собрать итоговый контекст. Это уже многошаговый поиск, а не одно обращение.
Пять способов поиска, которые нужны вместе
| Способ | Что даёт | Где один не справляется |
|---|---|---|
| По смыслу | Находит близкое по значению, даже другими словами | Путается на артикулах, кодах и названиях продуктов |
| По словам | Точные термины, имена, номера версий | Не находит переформулировку |
| По меткам | Ограничение по стране, подразделению, клиенту, дате, типу документа, уровню доступа | Работает только если метки проставлены |
| Переоценка результатов | Поднимает наверх действительно релевантное | Добавляет задержку, нужна на выборке, а не на всём |
| Агентный поиск | Разбивает сложный вопрос на несколько обращений и оценивает, хватает ли найденного | Дороже и медленнее; нужен не для каждого запроса |
Самая недооценённая часть — метки
У документа должно быть описание, а не только текст. Минимальный набор:
| Поле | Пример | Зачем |
|---|---|---|
| Тип | политика | Отделить действующий документ от заметки |
| Владелец | отдел архитектуры | Есть кого спросить об актуальности |
| Подразделение и страна | технологии, Казахстан | Локальные правила отличаются |
| Версия и статус | 3.2, действует | Отсечь отменённые редакции |
| Даты создания и пересмотра | обновлён 21.07 | Основание считать документ свежим |
| Классификация | внутренний | Основание для проверки прав |
«Найди информацию» и «найди действующую информацию по Казахстану, доступную этому пользователю» — два разных запроса. Второй возможен только при наличии меток.
Права доступа закладываются в основание, а не сверху
Типичная и опасная ошибка: сначала собрать единый индекс по кадрам, финансам, юристам, продажам и поддержке, а потом решать вопрос доступа на уровне интерфейса.
Правильный принцип — выдача с учётом прав: агент получает только те фрагменты, которые пользователь имеет право видеть. Причём на уровне документа, папки, записи и отдельного поля, с учётом роли, подразделения и проекта. Вопрос «это релевантно» и вопрос «имеет ли он право это видеть» решаются в одном месте, а не в разных.
Дальше документов
Корпоративное знание становится разнородным: таблицы, схемы, скриншоты, аудио, видео, записи встреч. Таблица с финансовыми показателями — не просто текст. Архитектурная схема — тоже. Запись встречи содержит участников, дату, тему, принятые решения и задачи; без этого транскрипт почти бесполезен.
Направление развития понятное: от поиска по документам к слою, который понимает разные типы содержимого.
Агенту нужна не база знаний, а связка знания и инструментов
Агенту в продажах для одной задачи нужны одновременно CRM, продуктовое знание, прайс, договоры, прошлые предложения, история клиента и рыночная информация. А после анализа — собрать справку по сделке, предложить следующий шаг, подготовить черновик предложения и обновить запись в CRM.
Пользователь
│
▼
Агент
│
├── Слой знания ──── документы · данные · история
│
└── Инструменты ──── CRM · учётная система · заявки · интерфейсы систем
Агент получает не только знания, но и контекст, инструменты и границы прав. Один слой знания при этом обслуживает несколько приложений: помощника в продажах, кадрового, юридического, закупочного, аналитического.
Чем это отличается от корпоративного поиска
Обычный поиск отвечает: «вот документы, где встречается нужное». Слой знания отвечает иначе: «вот информация под вашу задачу, вот источники, вот ограничения и вот что стоит проверить дополнительно». Это другой продукт и другой сценарий работы — конечным интерфейсом становится не строка поиска.
Что это даёт бизнесу
| Эффект | Как проявляется |
|---|---|
| Быстрее ввод в должность | Новый сотрудник получает доступ к знанию, не собирая его неделю по коллегам |
| Меньше зависимости от отдельных людей | Знание перестаёт жить только в головах трёх экспертов |
| Быстрее подготовка предложений | Похожие проекты, прошлые предложения, логика цены и кейсы находятся за минуты |
| Быстрее поддержка | Актуальная документация и история взаимодействия в одном ответе |
| Меньше повторной работы | Решённая однажды задача находится снова, а не решается заново |
Слой не создаёт знание из ничего
Можно построить безупречную техническую архитектуру и получить плохой результат. Если документы устарели, версии противоречат друг другу, владельцев нет, структура файлов хаотична и за актуальность никто не отвечает — система просто масштабирует этот беспорядок.
Поэтому до внедрения проводится аудит знаний. Минимальный список вопросов:
- Какие источники существуют
- Кто владелец каждого источника
- Что актуально, а что устарело
- Что дублируется
- Какие документы противоречат друг другу
- Какие данные чувствительные и кто имеет к ним доступ
- Какое знание критично для бизнеса
- Что из этого реально нужно агентам
Жизненный цикл знания
Создание → классификация → индексирование → выдача → использование → оценка → обновление → архив.
Пропускают обычно два шага — оценку и обновление. Без них база знаний за год превращается в архив, а агент начинает уверенно отвечать по отменённым регламентам. Изъятие устаревшего из индекса важнее, чем добавление нового.
Как измерять качество
Вопрос «отвечает ли правильно» слишком общий. Измерять нужно отдельно поиск, отдельно ответ и отдельно эффект.
| Уровень | Что смотреть |
|---|---|
| Поиск | Доля найденного из релевантного, доля релевантного среди найденного, позиция первого верного результата, точность ссылок на источник |
| Ответ | Фактическая точность, опора на источники, полнота, доля выдуманного |
| Бизнес | Время поиска информации, время подготовки предложения, время решения обращения, срок ввода в должность, доля вопросов без человека, стоимость обработки запроса |
Проект измеряется изменением процесса, а не числом проиндексированных документов.
Три варианта реализации
| Вариант | Когда подходит | Чем платите |
|---|---|---|
| Готовый управляемый сервис | Важны скорость запуска, готовые соединители с системами, минимум своей инфраструктуры | Меньше контроля над обработкой и хранением |
| Своё развёртывание на готовых компонентах | Нужен контроль над хранением, разбиением, индексом и ранжированием | Своя команда эксплуатации |
| Собственная архитектура | Сложная предметная область, графовые связи, жёсткие требования к задержке и месту хранения данных, своя логика доступа | Самая высокая стоимость владения |
Вопрос звучит не «какое решение лучше», а «какой уровень контроля действительно нужен нашему бизнесу и готовы ли мы его обслуживать».
С чего начать
- Один процесс. Продажи, поддержка, кадры, закупки или юристы — не всё сразу.
- Три-пять задач. Для продаж: найти похожие проекты, собрать справку по клиенту, найти кейсы, подготовить вопросы к встрече, предложить следующий шаг.
- Конкретные источники. Не «все документы компании», а CRM, плейбук, кейсы, продуктовая документация и прошлые предложения.
- Минимальный слой знания. Загрузка, метки, выдача с учётом прав, ссылки на источники, оценка качества.
- Агент — после. Подключать только когда поиск стабильно находит нужный контекст.
- Измерить до и после. И только затем расширять на следующий процесс.
Плохие данные дают плохую выдачу, плохая выдача — плохой контекст, плохой контекст — бесполезного агента. И наоборот: организованное знание даёт осмысленную выдачу, проверяемый контекст и агента, которым пользуются. Поэтому работа над корпоративным ИИ начинается задолго до того, как пользователь впервые что-то спросит у модели.
Частые вопросы
Связанное
- AI Knowledge Lifecycle — жизненный цикл знания подробно
- RAG — как устроена выдача по документам
- Управление данными для ИИ
- AI Agent Lifecycle — что добавляется, когда агент начинает действовать
- RAG, векторный поиск, галлюцинация — в глоссарии