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