Сценарий повторяется из компании в компанию. Бизнес подключает ИИ-помощника к корпоративной вики, показывает демо руководству, получает бюджет. Через два месяца сотрудники возвращаются к тому, чтобы спрашивать коллег в чате: ответы помощника выглядят убедительно, но им нельзя доверять.
Причину обычно ищут в модели — выбрали не ту, мало контекста, нужен файн-тюнинг. На деле причина чаще не в модели, а в источнике, к которому её подключили.
Контент заперт в проприетарной базе
Большинство систем управления знаниями хранят статьи в собственной базе данных. Забрать оттуда контент целиком, как правило, нельзя: наружу он отдаётся выдержками — без истории правок и без связей с остальными документами.
Разница видна на простом запросе. Сотрудник спрашивает про условия возврата, помощник находит подходящий абзац и отвечает по нему — не зная, что двумя разделами ниже описано исключение, а в истории правок этот пункт месяц назад меняли. Ответ формально взят из базы и при этом неверен.
Альтернатива — хранить знания в открытом формате. Если статьи лежат обычными Markdown-файлами в системе контроля версий, помощник получает документ целиком: со всеми разделами, историей изменений и ссылками на смежные регламенты. По такому принципу построен, например, Gramax: контент остаётся файлами в Git, а не записями в закрытой базе. Заодно контент остаётся у компании в читаемом виде и не зависит от того, работает ли поставщик платформы.
В базе живут противоречия, и ИИ их не показывает
Вторая причина неприятнее, потому что она не техническая. В любой базе знаний, которую несколько лет наполняли разные отделы, накапливаются дубли и расхождения. Две инструкции про один процесс, написанные в разное время. Регламент, обновлённый в одном разделе и забытый в другом. Условия, которые отдел продаж описал иначе, чем поддержка.
Пока по базе ищет человек, ущерб ограничен: сотрудник видит две статьи, замечает расхождение и идёт уточнять. ИИ-поиск устроен иначе — он собирает ответ и подаёт его как единственный. Противоречие не доходит до пользователя: оно молча разрешается в пользу документа, который лучше совпал с запросом. Сотрудник получает уверенный ответ и не догадывается, что рядом лежал другой.
Отсюда практический вывод: чистка базы — не подготовительный этап перед внедрением ИИ, а постоянный процесс. Помогает, когда платформа сама находит дубли и расхождения, а редактор видит их раньше, чем по ним ответит помощник. В Gramax такая проверка встроена в работу с базой и запускается до публикации ответа.
Знания устаревают быстрее, чем их успевают переписывать
Третья причина — темп. Условия акций, правила возврата, требования к процессам меняются постоянно, а обновление статей всегда стоит в очереди после более срочных задач. База стареет незаметно: формально она есть, фактически по половине разделов отвечать уже нельзя.
Здесь ИИ полезнее не как отвечающий, а как редактор. Агент может отслеживать изменения в документах, задачах и обсуждениях и приносить готовые правки на проверку. Ключевое слово — на проверку: человек видит предложенное изменение построчно и решает, принять его, отклонить или поправить. Автоматическое обновление без этого шага быстро превращается в новый источник ошибок.
Что проверить до запуска
Три вопроса предсказывают результат внедрения точнее, чем выбор модели.
· В каком виде хранится контент — можно ли получить его целиком, а не фрагментами?
· Знает ли компания, сколько в базе дублей и расхождений, и чем их находить?
· Кто обновляет статьи, когда меняется процесс?
Качество ИИ-ответа — это в первую очередь вопрос гигиены источника. Модель усиливает то, что ей дали: чистую базу она делает доступнее, запущенную — опаснее, потому что теперь ошибка звучит уверенно.
