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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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