Корпоративный ИИ-ассистент по базе знаний (RAG-бот): ответ за 7 секунд вместо 15 минут
Корпоративный ИИ, который отвечает строго по загруженным регламентам и документам — без фантазий и с учётом прав доступа. Ниже — как устроен RAG изнутри, что портит качество ответов и сколько занимает внедрение.
Задача: ответ есть в регламенте, но найти его нельзя
В компании накопились десятки регламентов, инструкций и внутренних документов. Чтобы найти нужный пункт, сотрудник открывал файл за файлом или писал в поддержку — на простой вопрос уходило до 15 минут. Поддержка тонула в однотипных обращениях, а часть ответов всё равно оказывалась устаревшей.
Пробовали готовые чат-боты на базе больших языковых моделей, но столкнулись с классической проблемой: ИИ без ограничений «фантазирует» — уверенно выдаёт правдоподобный, но выдуманный ответ. Для регламентов, где цена ошибки высока, это неприемлемо. Нужен был ИИ-ассистент по базе знаний, который отвечает только фактами из документов и честно говорит «не знаю», если ответа в базе нет.
Отдельная сложность любой корпоративной базы знаний в том, что поиск по словам работает плохо. Сотрудник спрашивает «сколько дней на согласование отпуска», а в регламенте написано «заявление подаётся не позднее чем за N рабочих дней». Общих слов почти нет — обычный поиск по совпадению такой документ не найдёт, и человек делает вывод, что правила просто не существует.
Решение: RAG вместо «умного» бота
Собрал RAG-бот (Retrieval-Augmented Generation): прежде чем генерировать ответ, система ищет релевантные фрагменты в загруженной базе знаний и отвечает строго на их основе. Это и есть ключевое отличие от обычного чат-бота — модель не «придумывает», а опирается на ваши документы.
- Документы и регламенты разбиваются на фрагменты, превращаются в векторы и складываются в векторную БД на pgvector — это даёт быстрый смысловой поиск, а не поиск по точному совпадению слов.
- На входящий вопрос бот достаёт самые релевантные куски из базы и передаёт их в модель Claude / GPT API с жёсткой инструкцией: отвечать только по предоставленному контексту.
- Строгий режим «не знаю, если нет в базе» — бот не додумывает и при отсутствии данных прямо сообщает об этом, со ссылкой на источник, когда ответ найден.
- Учёт прав доступа: каждый сотрудник видит только те документы, к которым у него есть доступ — поиск идёт в пределах его прав, чужие регламенты в ответ не попадают.
- Вся логика — оркестрация запросов, фильтрация по доступам, обращение к модели — собрана в n8n, а общается пользователь с ботом прямо в Telegram.
Такой корпоративный ИИ легко обновлять: добавили новый регламент в базу — бот сразу отвечает по нему, без переобучения модели.
Как устроен RAG изнутри
Со стороны это один чат. Внутри — конвейер, в котором каждый слой отвечает за свою часть качества ответа.
- Подготовка решает больше, чем модель. Как нарезаны документы, так бот и отвечает: разрежешь регламент посреди таблицы или списка условий — получишь половину правила и уверенный неверный ответ.
- Метаданные обязательны. У каждого фрагмента должны быть источник, раздел, дата и уровень доступа. Без этого невозможны ни ссылка на документ, ни разграничение прав.
- Индекс. В pgvector есть два типа индексов: HNSW строится дольше и требует больше памяти, зато даёт лучшее сочетание скорости и полноты выдачи; IVFFlat собирается в разы быстрее, но со временем деградирует, если в базу активно добавляют новые записи. Для живой базы знаний разумный выбор по умолчанию — HNSW.
- Отбор. Модель получает не всю базу, а несколько наиболее подходящих фрагментов. Чем аккуратнее отбор, тем короче и точнее ответ — и тем дешевле каждый запрос.
Права доступа и честное «не знаю»
Именно эти две вещи отделяют рабочий корпоративный ассистент от демонстрации. Фильтр по правам должен применяться на этапе поиска, а не при выводе: если модель уже увидела чужой документ, она может пересказать его содержание, даже не приводя ссылку. Права берутся из вашего каталога пользователей, а не дублируются в боте — иначе они разъедутся через месяц.
Ответ «в базе этого нет» — не провал, а функция. Бот, который в 10% случаев честно отказывается, полезнее бота, который в тех же 10% уверенно врёт: первому можно доверять оставшиеся 90%.
Пока читаете — можно сразу проверить свою задачу. Опишите процесс, и я скажу, решается ли он и во сколько обойдётся.
Что портит качество ответов и как это чинить
Когда RAG-бот отвечает мимо, причина почти никогда не в модели. Ниже — типичные источники ошибок и то, чем они лечатся.
| Симптом | Причина | Что делать |
|---|---|---|
| Бот отвечает по отменённому регламенту | В базе лежат обе версии документа | Версионирование и дата в метаданных, старые редакции убираются из индекса при загрузке новой |
| Ответ обрывочный, половина условий потеряна | Документ нарезан механически, по числу символов | Резать по смысловым границам — разделам и пунктам, сохранять заголовок раздела вместе с фрагментом |
| Нужный документ не находится | Вопрос сформулирован не теми словами, что текст регламента | Смысловой поиск вместе с обычным текстовым, плюс расширение запроса синонимами предметной области |
| Сотрудник видит чужой документ | Фильтр по правам применяется после поиска | Ограничивать выборку на этапе поиска, права брать из каталога пользователей компании |
| Таблицы и сканы игнорируются | Разбор формата теряет структуру, у сканов вообще нет текстового слоя | Отдельный разбор таблиц, распознавание для сканов; документы без текстового слоя честно помечать как неиндексированные |
Практический способ держать качество под контролем — набор контрольных вопросов с заранее известными правильными ответами. Полсотни таких вопросов прогоняются после каждого изменения базы или настроек: если доля верных ответов просела, видно сразу, а не через месяц по жалобам сотрудников.
Сколько занимает внедрение
- Инвентаризация документов (2–4 дня). Что вообще есть, где лежит, что из этого актуально и кто владелец. Обычно на этом шаге выясняется, что треть регламентов устарела и её нельзя пускать в базу.
- Подготовка и загрузка (3–7 дней). Разбор форматов, нарезка, метаданные, права. Самый трудоёмкий этап, особенно если часть документов — сканы.
- Сборка и настройка поиска (3–5 дней). Индекс, отбор фрагментов, правила ответа и отказа, ссылки на источник.
- Проверка на контрольных вопросах (2–5 дней). Список реальных вопросов от сотрудников с эталонными ответами, замер точности, донастройка нарезки и отбора.
- Запуск и наблюдение (1–2 недели). Бот работает, вопросы и ответы логируются. Просмотр логов первой недели даёт больше улучшений, чем любая теоретическая настройка.
На типовую базу — 2–4 недели. Срок задаёт не техника, а состояние документов: чистая и структурированная база знаний собирается за неделю, разрозненные файлы по папкам сотрудников — за месяц.
Результат
Время на поиск ответа по документам сократилось с 15 минут до 7 секунд — сотрудник просто спрашивает бота в Telegram и получает ответ с опорой на актуальный регламент. Точность ответов держится выше 90%, а главное — бот не выдумывает: если данных нет, он честно об этом сообщает.
Служба поддержки разгрузилась от потока однотипных вопросов и переключилась на действительно сложные обращения. Чат-бот по документам стал единой точкой правды по регламентам, а контроль прав доступа снял риск утечки внутренней информации между отделами.
Побочный эффект, который ценят не сразу: логи вопросов показывают, чего в базе не хватает. Если один и тот же вопрос регулярно упирается в ответ «в базе этого нет», значит, регламент либо не написан, либо написан так, что его никто не находит.
Когда RAG не нужен
Не каждая база знаний заслуживает ассистента, и иногда задача решается заметно дешевле.
- Документов десяток и они не меняются. Хватит нормального оглавления и обычного поиска по файлам.
- Вопросы строго типовые. Двадцать повторяющихся вопросов дешевле закрыть готовыми ответами по кнопкам, чем смысловым поиском.
- Ответ должен быть юридически точным. Тогда ассистент показывает цитату и ссылку на пункт, а решение принимает человек — формулировать за него нельзя.
- Документы не приведены в порядок. Пока в папках лежат три версии одного регламента без дат, бот будет уверенно отвечать по любой из них. Сначала порядок, потом ИИ.
И обратное: если сотрудники регулярно пишут в поддержку с вопросами, ответ на которые уже есть в документах, — это ровно тот случай, когда RAG окупается быстрее всего.
Частые вопросы
Чем RAG-бот отличается от обычного чат-бота на нейросети?
Обычный бот отвечает из общих знаний модели и не может сослаться на источник. RAG сначала ищет подходящие фрагменты в ваших документах и отвечает строго по ним, а если данных нет — прямо об этом говорит. Для регламентов подходит только второй вариант.
Бот точно не выдумает ответ?
Модель получает жёсткую инструкцию отвечать только по переданному контексту и приводить ссылку на источник. Здесь точность держится выше 90%, а в остальных случаях бот отвечает, что данных в базе нет, — это заложено как режим работы, а не как ошибка.
Как учитываются права доступа?
Фильтр применяется на этапе поиска: сотрудник ищет только внутри тех документов, к которым у него есть доступ. Права берутся из корпоративного каталога пользователей, а не дублируются в боте, иначе они рассинхронизируются.
Нужно ли переобучать модель при обновлении регламента?
Нет. Документ загружается в базу знаний, разбирается и попадает в индекс — бот начинает отвечать по нему сразу. Именно поэтому RAG дешевле в сопровождении, чем дообучение модели.
Данные уходят наружу?
База знаний и индекс разворачиваются в вашем контуре. Если используется внешняя модель, в неё уходит только вопрос и несколько найденных фрагментов, а не вся база; при жёстких требованиях модель разворачивается локально.
Сколько времени занимает внедрение?
Обычно 2–4 недели: инвентаризация документов, подготовка и загрузка, настройка поиска, проверка на контрольных вопросах и период наблюдения. Срок задаёт состояние документов, а не техническая часть.
Читайте дальше
Хотите так же у себя?
Расскажите задачу — за 20 минут покажу, что автоматизировать в первую очередь и какой эффект ждать. Без предоплаты за весь объём.
Получить разбор