Боты не знают регламенты: RAG и база знаний в OpenClaw

Виртуальный сотрудник уверенно отвечает клиенту: срок возврата «до 30 дней», скидка «как обычно 15%», доставка «завтра без проблем». В регламенте — другие цифры и другие условия. Оператор потом разруливает конфликт, юристы смотрят переписку, а руководитель спрашивает: «Зачем мы подключали ИИ, если он фантазирует?»

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

Разберём, почему боты выдумывают регламенты, какие ошибки делают при внедрении RAG и как связать OpenClaw с внутренней документацией так, чтобы виртуальный сотрудник работал по правилам компании, а не по статистике интернета.

Когда «умный» ответ дороже тишины

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

Скрипт поддержки частично описан в корпоративной вики, частично в головах старших смен. Модель заполняет пробелы правдоподобным текстом. Правдоподобие без источника — риск, особенно на темах возвратов, гарантий и персональных данных.

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

Ошибки внедрения базы знаний

Свалить в индекс всё подряд: старые PDF, дубли, личные заметки, противоречивые версии одного и того же регламента. RAG честно находит мусор и красиво его пересказывает — с уверенностью, которая выглядит как экспертиза.

Не назначить владельца контента. Документы гниют, бот стареет вместе с ними, доверие падает быстрее, чем успевают вырасти метрики пилота. Без владельца база знаний — склад, а не продукт.

Разрешить модели отвечать без цитирования источника и без режима «не знаю». Тогда галлюцинация неизбежна на хвосте вопросов, где покрытия документами нет.

Путать пилот для демо с промышленной эксплуатацией. На демо достаточно красивого ответа. В проде нужны права доступа, журнал, эскалация, запрет выдумывать коммерческие условия и понятный процесс обновления знаний.

Оценивать успех только по «вау» первых диалогов. Без контроля галлюцинаций и актуальности документов через месяц бот станет источником инцидентов, а не экономии на поддержке.

Как устроить RAG, чтобы регламент был главным

Сначала наведите порядок в источниках истины: один актуальный слой регламентов, политик, FAQ и скриптов. Черновики и архив — отдельно, с другими правами или вне индекса ответа клиентам. Пока в индексе хаос, никакая модель не сделает из него дисциплину.

Опишите правила ответа: опираться только на найденные фрагменты; если уверенности нет — уточнить или передать человеку; не назначать скидки и сроки вне документа; не обещать действий, которых нет в процессе.

Настройте выдачу с опорой на фрагменты: агент показывает, из какого-регламента взял норму. Это снижает риск и ускоряет проверку оператором, когда диалог всё же эскалирован.

Разделите контуры: клиентский бот видит внешние политики, внутренний ассистент — расширенный набор. Права на документы важны не меньше качества поиска и эмбеддингов.

Введите цикл обновления: изменение-регламента автоматически или по процедуре попадает в базу, старая версия выводится из ответа. Иначе-RAG-закрепляет прошлое и делает его убедительнее живого эксперта.

Добавьте метрики качества: долю ответов с источником, долю эскалаций, число инцидентов «бот пообещал лишнее», время на актуализацию документации, повторные обращения после автоответа.

Практический путь для команды

Сначала выберите узкий домен, например, возвраты или статусы заказов. Не пытайтесь обучить бота всей компании за неделю — так рождаются неконтролируемые обещания. «обучить всей компании» за неделю — так рождаются неконтролируемые обещания.

Соберите несколько десятков реальных вопросов и эталонных ответов из-регламента. Прогоните до и после подключения RAG — увидите разницу без маркетинга и без веры в магию.

Подключите-storage-документации к агентной платформе и запретите свободные фантазии на юридических, финансовых и кадровых темах. Там цена ошибки максимальна.

Настройте эскалацию с контекстом: какой документ искали, чего не нашли, что уже уточнили у пользователя, какой следующий шаг рекомендует процесс.

Назначьте редакционный цикл: кто утверждает новые фрагменты знаний, кто выводит устаревшие, как часто пересматривают спорные темы. Без редакции-RAG-деградирует так же предсказуемо, как неподдерживаемая вики.

В контуре OpenClaw это естественная связка «агент-+-знания-+-инструменты». Имеет смысл опираться на системное внедрение OpenClaw с RAG-и ролями, а не на чат с моделью без ограждений и без владельца контента.

Бизнес эффект дисциплины знаний

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

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

Растёт скорость онбординга. Новому сотруднику проще опираться на живую базу с ассистентом, чем на устаревшие PDF и устные легенды отдела. Это прямой эффект на время выхода на продуктивность.

Отдельно появляется управляемость контента как актива. Регламенты перестают быть «файлами на диске» и становятся рабочим контуром ответов с владельцем, версиями и метриками качества.

Если бот отвечает не по правилам, нужно не отключать его, а запретить отвечать без опоры на базу знаний. Регламент должен быть источником, модель — способом его донести понятным языком.