Корпоративный ИИ находит старую версию регламента, путает одноименных клиентов и не замечает локальное исключение. Ответ звучит уверенно, поэтому на разборе возникает привычный вывод: нужна модель сильнее.
Иногда нужна. Но чаще проблема находится ближе. Системе дали папку документов, не объяснив, какой справочник главный, какой документ действует и кто утвердил исключение. Модель может работать с переданным контекстом, но не способна сама восстановить правила компании, которые нигде не закреплены.
Контекст — не папка с файлами
Для рабочего сценария контекст состоит минимум из трех слоев.
Первый — мастер-данные. Это устойчивые объекты бизнеса: клиент, договор, продукт, площадка, оборудование, сотрудник, единица измерения. У каждого должен быть идентификатор, основные атрибуты и источник истины.
Второй — знания. Инструкции, описания продуктов, решения, переписка, протоколы и накопленный опыт. Эти материалы объясняют, как действовать и почему.
Третий — правила процесса. Кто имеет право принять решение, какая проверка обязательна, что считать исключением, в какой последовательности выполняются операции и когда работа передается другому человеку.
Поиск по документам обычно охватывает второй слой. Без первого система не всегда понимает, о каком объекте идет речь. Без третьего она предлагает информацию, но не надежное действие.
Ошибка объекта опаснее неточной формулировки
Представим двух клиентов с похожими названиями и несколькими договорами. В письме указано сокращение. Поиск находит релевантную переписку, но она относится к другой организации. Текст ответа может быть безупречным, а бизнес-решение — неверным.
Поэтому перед генерацией нужно разрешить сущность: сопоставить название с идентификатором клиента, проверить договор, подразделение и статус. Если уверенности недостаточно, система задает уточняющий вопрос или передает случай человеку. Она не должна заполнять пробел наиболее правдоподобным вариантом.
Такая работа выглядит менее эффектно, чем демонстрация свободного диалога. Именно она превращает поиск в управляемый процесс.
Актуальность должна быть видимой
В корпоративной базе легко оказываются две инструкции с разными датами, презентация с упрощенными обещаниями и письмо, описывающее разовое исключение. Если система ранжирует их только по похожести текста, старый документ может победить действующий.
Каждому источнику полезно назначить статус: утвержденный, рабочий проект, архивный, справочный. Нужны дата действия, владелец, область применения и ссылка на заменившую версию. При ответе ИИ должен учитывать не только семантическую близость, но и эти атрибуты.
Если актуальность невозможно определить автоматически, результат маркируют. Фраза «найдено в документе без подтвержденного статуса» честнее уверенного ответа, который пользователь примет за правило.
Правило нельзя прятать в длинном документе
Критичное условие иногда живет в абзаце регламента на сороковой странице. Поисковая система может найти его, но агенту, выполняющему действие, нужна структурированная проверка.
Например: изменение срока допускается только для активного договора, при отсутствии просроченной задолженности и после подтверждения владельца клиента. Эти условия лучше реализовать как отдельную бизнес-политику, которая получает факты из систем и возвращает разрешение или запрет. Документ остается основанием и объяснением, но не единственным механизмом контроля.
Так отделяются рассуждение и полномочие. Модель предлагает решение, а детерминированное правило проверяет допустимость.
У контекста должен быть владелец
База знаний без владельцев быстро становится складом. Для каждого класса контента нужно определить, кто утверждает материал, как часто проверяет его, что происходит при конфликте и как пользователь сообщает об ошибке.
ИТ может отвечать за платформу, доступность и техническую индексацию. Но смысл и актуальность инструкции принадлежат владельцу процесса. Передать эту ответственность команде ИИ означает закрепить ошибочную модель управления: технология будет обслуживать знания, которые никто в бизнесе не считает своими.
Полезный минимальный реестр содержит название набора, владельца, источник истины, период обновления, допустимую задержку, уровень чувствительности и сценарии использования.
Чем больше контекста, тем не всегда лучше
Попытка загрузить «все, что есть» увеличивает шум, стоимость обработки и риск раскрыть лишнюю информацию. Агенту по сервисным заявкам не обязательно видеть финансовые условия всех клиентов, если его задача ограничена классификацией и поиском инструкции.
Контекст подбирают по принципу минимальной достаточности. Сначала разрешают объект, затем получают только нужные поля, после этого находят несколько актуальных источников и применяют правила процесса. Такой конвейер проще тестировать, чем один огромный запрос с десятками документов.
Минимизация помогает и качеству. Модель реже путает противоречивые источники, а журнал позволяет восстановить, почему использован конкретный фрагмент.
Как проверить контекст до пилота
Соберите набор реальных вопросов и случаев. Включите старые названия, дубли, отмененные документы, конфликтующие версии, исключения и запросы вне полномочий. Для каждого случая зафиксируйте правильный объект, допустимые источники, ожидаемое решение и условие передачи человеку.
Тестируйте отдельно этапы:
- Система правильно определила объект?
- Выбрала действующие источники?
- Извлекла необходимые факты без домысла?
- Применила правило процесса?
- Указала ограничение или неопределенность?
Средняя оценка ответа скрывает причину ошибки. Раздельные метрики показывают, что исправлять: справочник, метаданные, поиск, инструкцию или бизнес-политику.
Экономика качества контекста
Подготовка данных кажется предварительной работой без быстрого эффекта. Но плохой контекст создает постоянный налог: сотрудники перепроверяют ответы, команда вручную разбирает исключения, доверие падает, а каждая новая функция требует обходных правил.
В модель проекта стоит включить стоимость владения контекстом: ведение справочников, актуализацию документов, разметку статусов, обратную связь и контроль качества. Одновременно можно посчитать, сколько повторной работы и ошибок эта функция устраняет не только для ИИ, но и для обычных сотрудников и аналитики.
Хорошо устроенный контекст является общим активом. Им пользуются поиск, агенты, отчетность, обучение новых сотрудников и автоматические проверки процесса.
Сначала карта контекста, потом новая модель
Корпоративный ИИ не обязан знать компанию сам по себе. Ему нужна проверяемая модель бизнеса: однозначные объекты, актуальные знания и явные правила действий. Чем дороже решение, тем опаснее полагаться на свободный текст без статуса и владельца.
Начните с одного сценария и карты контекста: какие объекты участвуют, где источник истины, какие документы действуют, какие правила проверяются и кто отвечает за обновление. Затем сравнивайте модели. До этого сравнение легко измеряет качество беспорядка в данных, а не качество ИИ.
По теме: data governance для корпоративной аналитики и архитектура доступа ИИ-агента к CRM.
