Проблема была не в отсутствии чат-бота

Wilhelm-Klein — средний немецкий дистрибьютор товаров для гигиены и здравоохранения. После резкого роста спроса компания расширила персонал, ассортимент, складские и логистические операции. Порядок работы менялся быстрее, чем успевали обновлять инструкции. По описанию проекта Европейской сети центров цифровых инноваций, сотрудники дублировали действия, обходили неудобные процедуры, а нагрузка на внутреннюю поддержку росла. Существующая ERP тоже перестала хорошо соответствовать новым ролям и процессам.

Типичная реакция на такую ситуацию — купить «ИИ-поиск по всем файлам». Но поиск по противоречивым и устаревшим документам способен быстро и уверенно выдать устаревший ответ. В проекте поэтому сначала наблюдали реальную работу подразделений: кто создаёт инструкции, какие обходные пути появились, где сотрудник не может уточнить спорный шаг у автора документа. Это важно и для российского малого бизнеса: знания о закупках, возвратах и отгрузке часто живут в почте, папках и переписке, а не в единой базе.

Что сделали на практике

Старую файловую систему перенесли в корпоративный SharePoint и ввели роли и категории. Это не просто техническая миграция: у документа должен появиться владелец, понятная область применения и круг читателей. Затем сделали демонстратор с двумя интерфейсами рядом — на основе DeBERTa и генеративной GPT-модели. Сотрудники более двух месяцев сравнивали многодокументный поиск, ответы с контекстом и без него, оценку уверенности, переход к исходным фрагментам и возможность связаться с автором документа.

В итоге выбрали генеративный вариант с функциями прослеживания ответа и обратной связи. Сотрудник мог проверить, из каких документов получен ответ, задать уточнение или предложить исправление источника. Для RAG это ключевой цикл: неверный ответ не должен исчезать в чате; он должен становиться сигналом ответственному за знание. При этом тестировали решение не только руководители, а будущие пользователи из рабочих групп.

По описанию EDIH, финальная инфраструктура внедряется во внутреннем окружении компании на собственных вычислительных ресурсах, но с лицензированной подпиской на модель. Это не тождественно полностью локальному ИИ: размещение приложения, расположение исходных документов и условия обработки моделью нужно проверять отдельно. Перенос в SharePoint также означает облачный контур хранения документов в данном конкретном кейсе.

Что можно считать результатом, а что нельзя

Источник сообщает, что оценка в ходе теста показала *ожидаемое* снижение числа заявок во внутреннюю ИТ-поддержку более чем на 60% и *ожидаемый* рост вовлечённости в работу с документами на 50%. Эти показатели нельзя выдавать за подтверждённые результаты длительной промышленной эксплуатации: в кейсе нет опубликованной методики подсчёта, исходного числа тикетов, контрольной группы и полного расчёта стоимости. Подтверждённый итог скромнее, но полезнее для внедрения: проведён двухмесячный пилот, выбран рабочий подход и начато развёртывание с собственным хостингом и подпиской.

Важный урок — обратная связь сотрудников меняла не только интерфейс, но и сами документы. Авторы кейса обнаружили неполные и устаревшие инструкции. Значит, измерять нужно не число ответов бота, а долю вопросов, решённых правильно и с проверяемым источником, число повторных обращений и время на поддержание базы в актуальном состоянии.

Как перенести идею в российский бизнес

Не требуется копировать SharePoint или выбранную модель. Если уже есть корпоративный файловый сервер, система документооборота или база знаний, сначала проверьте, можно ли получить из неё документы с метаданными и правами доступа. Минимальная архитектура пилота выглядит так:

  • назначить владельца каждой группы инструкций, версию и дату проверки;
  • индексировать только утверждённые документы, сохраняя ссылку на оригинал и ограничения доступа;
  • искать релевантные фрагменты и передавать их модели вместе с вопросом;
  • показывать ответ и конкретные источники, а при слабом основании — честно передавать вопрос человеку;
  • собирать исправления и передавать их владельцу документа, а не «дообучать» модель на каждой жалобе.

Если данные должны оставаться в защищённом контуре, разместите индекс и модель там же и отдельно проверьте, куда уходят журналы, резервные копии и телеметрия. Если выбирается внешний API, сначала согласуйте классы данных и договорные условия. Microsoft подчёркивает, что поиск SharePoint учитывает права читателя; собственный RAG-коннектор должен сохранять этот принцип на каждом этапе, иначе бот способен показать фрагмент документа тому, кому он не разрешён.

Экономика без выдуманной окупаемости

Релиз кейса не даёт надёжной стоимости проекта, поэтому вот лишь модельный расчёт для решения о пилоте. Допущения: 50 однотипных внутренних вопросов в неделю, 12 минут работы специалиста на каждый; система корректно покрывает 20 вопросов, а проверка ответа сотрудником занимает 3 минуты. Тогда потенциально освобождается `(12 − 3) × 20 = 180 минут`, или 3 часа в неделю. Если на обновление документов уходит 2 часа, остаётся час до учёта лицензии, инфраструктуры, поддержки и ошибок. При низком качестве источников пилот может не окупиться вообще.

Руководителю нужен не обещанный процент автоматизации, а замер собственной очереди. За две недели соберите 30–50 повторяющихся вопросов, время обработки и документы, которыми пользовался эксперт. Отметьте устаревшие инструкции и закрытые разделы. Затем сравните обычный поиск, RAG с локальной моделью и, если политика данных допускает, вариант с внешней моделью на одном наборе вопросов. Критерий успеха — правильный ответ с корректным источником и соблюдённым доступом, а не впечатляющая демонстрация.

Что ограничивает подход

RAG не чинит ERP, не исправляет противоречие между реальным процессом и регламентом и не заменяет владельца знания. Генеративная модель может неверно обобщить даже найденный документ; оценка уверенности не является гарантией истинности. Нужны версии источников, тестовые вопросы, журнал ошибок, право сотрудника оспорить ответ и маршрут к человеку для дорогих или рискованных решений. Рекомендации NIST по управлению рисками генеративного ИИ поддерживают именно такой подход: проверять систему в контексте применения и управлять ошибками на протяжении жизненного цикла.

Практический следующий шаг невелик: выберите один процесс — например, возвраты или ввод нового сотрудника — и приведите в порядок десяток самых используемых инструкций. Если после этого обычный поиск уже решает проблему, сложный агент не нужен. Если вопросы требуют синтеза нескольких актуальных документов, тогда RAG получает обоснованное место в архитектуре.