Как подготовить базу знаний для RAG-ассистента: чек-лист

Ассистент отвечает ровно настолько хорошо, насколько хороша база

За 21 год в IT я видел много проектов, где заказчик ждал чуда от технологии, а дело было в данных. С RAG-ассистентами это проявляется особенно ярко. Модель не «знает» вашу компанию: она читает фрагменты документов, которые ей подсунул поиск, и пересказывает их. Если в документах мусор, противоречия или пустота, ассистент воспроизведёт мусор, противоречия или пустоту — только уверенным тоном.

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

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

Типовые провалы, с которыми я сталкиваюсь на старте почти каждого проекта:

• «Какой прайс на монтаж?» — в базе три прайса разных лет, ассистент выдал прошлогодний.
• «Как оформить возврат?» — регламент есть, но это скан без текстового слоя. Поиск его не видит, ассистент отвечает общими словами.
• «Кто согласует отпуск?» — ответ живёт в голове руководителя и в чате, а не в документах. Ассистент молчит или фантазирует.
• «Сколько стоит доставка в Казань?» — в документе таблица на 40 строк, которую при разбиении на фрагменты разорвало пополам. Строка с Казанью оказалась отдельно от заголовка столбца.

Что собрать — и что оставить за дверью

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

• Регламенты и инструкции. Как оформить, кто согласует, в какие сроки. Это основа внутреннего ассистента.
• Прайсы и условия. Цены, скидки, сроки, условия оплаты и доставки. Одна актуальная версия каждого.
• FAQ поддержки. Реальные вопросы клиентов и утверждённые ответы. Самый ценный источник, потому что он уже в формате «вопрос — ответ».
• Описания продуктов и услуг. Характеристики, состав, ограничения, совместимость, что входит и что нет.
• Шаблоны договоров и типовые условия. Ответственность, сроки, порядок расчётов — без реквизитов конкретных клиентов.
• Страницы сайта. Обычно это самое актуальное описание того, что вы продаёте.
• История переписки — выборочно. Закрытые обращения, где ответ подтверждён и проблема решена.
• Оргструктура и зоны ответственности. Кто за что отвечает, куда идти с каким вопросом.

Теперь то, что класть не нужно. Это важнее, чем кажется: каждый лишний документ — это шум в поиске и шанс, что ассистент подхватит неверный фрагмент.

• Черновики и промежуточные версии. Файлы вида «регламент_v2_final_испр» — в базу идёт только утверждённое.
• Устаревшее. Прайсы прошлых лет, отменённые регламенты. Если нужны для истории — отдельный архив, не база ассистента.
• Персональные данные без необходимости. ФИО клиентов, телефоны, паспортные данные в договорах. Для ответа на вопрос «какие условия в договоре» они не нужны, а риски создают.
• Переписка целиком. Чаты — это шум: большинство сообщений не несут знаний, зато содержат эмоции, опечатки и устаревшие договорённости.
• Спорные документы. Всё, по чему внутри компании нет согласия («мы так давно не делаем, это кто-то когда-то написал»).

Форматы и источники: что работает сразу, что требует подготовки

Ассистент по документам компании технически умеет читать почти всё. Разница в том, сколько смысла он вытащит без ручной подготовки.

Три случая, которые требуют отдельного внимания.

Сканы без текстового слоя. Для поиска это картинка. Распознавание (OCR) решает проблему на 90%, но оставшиеся 10% — это как раз цифры и таблицы, то есть самое важное в прайсе или договоре. После OCR я всегда прошу проверить ключевые документы глазами.

Таблицы. При разбиении документа на фрагменты таблица теряет заголовки столбцов: фрагмент «Казань — 450 — 3» ничего не значит без шапки «Город — Стоимость — Дней». Решение простое: превратить каждую строку в текстовую запись: «Доставка в Казань: 450 рублей, 3 рабочих дня». Для прайса на сотню позиций это полчаса работы — и ассистент перестаёт путать города и цены.

Презентации и схемы. Текст на картинках для поиска невидим. Если на схеме важная информация — например, порядок согласования, — её нужно описать словами рядом.

Структура: один вопрос — один документ

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

• Один документ — одна тема. Документ «Всё о доставке» на 30 страниц хуже, чем восемь коротких: «Сроки доставки», «Стоимость по регионам», «Самовывоз», «Что делать, если посылка повреждена». Короткий документ попадает в контекст модели целиком, без обрывов.
• Заголовки повторяют вопрос клиента. «Как вернуть товар, если прошло 14 дней» работает лучше, чем «Раздел 4.2». Поиск сопоставляет вопрос пользователя с текстом, и заголовок-вопрос даёт точное совпадение.
• Первый абзац — краткий ответ. Дальше детали и исключения. Если документ разрежут на фрагменты, главное останется в первом.
• Дата актуальности прямо в тексте. «Актуально с 1 сентября 2026». Ассистент сможет её назвать, а вы при ревизии сразу увидите старое.
• Владелец документа. Не отдел, а человек, который отвечает за правильность. К нему пойдут вопросы, когда ассистент ответит неверно.
• Единая терминология. Если в одном документе «заявка», в другом «обращение», в третьем «тикет», поиск хуже связывает вопросы с документами. Выберите один термин, остальные вынесите в глоссарий.

Шапка документа, которую я рекомендую заказчикам, выглядит так:

Название:      Возврат товара надлежащего качества
Актуально с:   01.09.2026
Владелец:      руководитель клиентской поддержки
Кратко:        вернуть можно в течение 14 дней, если сохранены
               упаковка и чек; деньги возвращаются за 3–10 дней.

Подробно:      [условия, порядок, сроки]
Исключения:    [что вернуть нельзя и почему]
Связанные:     «Возврат товара с браком», «Обмен товара»
            

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

Типичные ошибки, которые всплывают после запуска

Эти проблемы не видны, пока база лежит на диске. Они проявляются в первую неделю работы ассистента — в виде жалоб «он врёт».

Дубли. Один и тот же регламент в трёх папках, две версии отличаются одним абзацем. Поиск достаёт обе, модель получает противоречивый контекст и выбирает случайно. Решение: один источник правды для каждой темы, остальное удалить или заменить ссылкой.

Противоречия между документами. Прайс говорит одно, договор — другое, сайт — третье. Ассистент не судья, он не знает, что главнее. Решение: до загрузки сверить ключевые цифры по всем документам и назначить приоритет источников — например, «при расхождении верен договор».

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

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

Внутренние сокращения без расшифровки. «Передать в ОТК после СМР» понятно сотрудникам, но не ассистенту и не клиенту. Решение: глоссарий как отдельный документ в базе.

Слишком общие тексты. Маркетинговые описания — «индивидуальный подход», «высокое качество» — не отвечают ни на один конкретный вопрос. Они занимают место в контексте и вытесняют полезные фрагменты. Их можно не брать.

Как разметить базу за один вечер: порядок действий

Для компании до 50 человек с несколькими десятками документов это реально занимает один вечер. Для компании покрупнее — пару дней, но уже силами нескольких владельцев документов. Порядок такой:

1. Соберите 30 реальных вопросов. Из обращений в поддержку, чата с клиентами, звонков. Не придумывайте — выгрузите. Это ваша тестовая выборка: по ней вы потом проверите ассистента.
2. Для каждого вопроса найдите документ с ответом. Если документа нет — пометка «нет источника». Если нашлось два разных ответа — пометка «противоречие».
3. Создайте одну папку с плоской структурой. Общий диск, Notion или Confluence — неважно. 5–7 разделов, не больше. Переносите только утверждённые документы.
4. Переименуйте файлы по-человечески. «Прайс на монтаж 2026» вместо «price_new(2)_final.xlsx». Имя файла тоже участвует в поиске.
5. Добавьте шапку в каждый документ. Дата актуальности, владелец, краткое содержание в одно-два предложения.
6. Разрежьте длинные документы по темам. Если документ отвечает на десять разных вопросов — это десять документов или хотя бы десять заголовков второго уровня.
7. Напишите недостающие ответы. По всем вопросам с пометкой «нет источника» — коротко, 3–5 предложений, вместе с носителем знаний.
8. Разрешите противоречия. Один верный ответ, остальные документы исправить или удалить.
9. Передайте папку исполнителю. Для прототипа этого достаточно. Разбиение на фрагменты, векторизация, промпты — техническая часть, которую делает разработчик.

Как обновлять базу после запуска

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

• Владелец базы. Один человек, который отвечает за актуальность в целом — не за каждый документ, а за процесс. Обычно это руководитель поддержки или операционный директор.
• Регламент обновления. Три вопроса: что меняется, кто правит документ, как изменение попадает в ассистента. Триггеры: новый прайс, новый продукт, изменение процесса, новый частый вопрос.
• Автосинхронизация. Ассистент подключён к папке на диске, разделу сайта или пространству в Notion и переиндексирует изменения сам — по расписанию или по событию. Тогда «обновить базу» означает просто «отредактировать документ». В моих проектах это стандартная часть поставки.
• Разбор вопросов без ответа. Раз в неделю смотреть, на что ассистент ответил «не нашёл» или получил низкую оценку от пользователей. Это готовый список документов, которых не хватает.
• Ревизия раз в квартал. Пройти по документам с датой актуальности старше полугода и либо подтвердить, либо обновить.
• Замена, а не дополнение. Новая версия документа заменяет старую в базе ассистента. Старая не лежит рядом «на всякий случай».

Чек-лист: 15 пунктов перед запуском RAG-ассистента

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

• Собраны 30 и больше реальных вопросов клиентов или сотрудников для проверки ассистента.
• Для каждого вопроса известен документ-источник ответа.
• В базе только утверждённые версии документов; черновики и старые редакции исключены.
• Прайсы и условия актуальны, у каждого ровно одна версия.
• Противоречия между документами найдены и устранены, назначен приоритет источников.
• У каждого документа есть дата актуальности и владелец.
• Один документ — одна тема; длинные документы разделены.
• Заголовки сформулированы как вопросы или темы клиента, а не номера разделов.
• Сканы без текстового слоя распознаны и проверены глазами.
• Ключевые таблицы переведены в текстовые записи с названиями столбцов.
• Презентации и схемы переписаны в текст или исключены.
• Персональные данные удалены, обезличены или закрыты правами доступа.
• Внутренние сокращения расшифрованы в глоссарии.
• Назначен владелец базы знаний и описан регламент обновления.
• Выбран источник для автосинхронизации: папка, сайт, Notion, Confluence или CRM.

Если половина пунктов не закрыта — это нормально. Именно поэтому в моих проектах сбор и структурирование базы входят в стоимость внедрения ИИ-ассистента: я прохожу этот чек-лист вместе с заказчиком в первую неделю, а прототип на его документах показываю через одну-две. А понять, какие документы и процессы стоит подключать первыми, можно на бесплатном AI-аудите.

Часто задаваемые вопросы

Сколько документов нужно, чтобы запустить RAG-ассистента?

Для пилота обычно хватает 20–50 документов, которые закрывают самые частые вопросы. Важнее не количество, а покрытие: если 30 реальных вопросов из поддержки находят ответ в базе, ассистент уже полезен. Добавлять документы можно после запуска — архитектура RAG позволяет это без переобучения модели.

Нужно ли переписывать все документы в специальный формат?

Нет. Ассистент работает с PDF, Word, Google Docs, страницами Notion и Confluence, сайтом. Переписывать стоит только проблемные документы: сканы без текстового слоя, презентации и большие таблицы. Остальным достаточно навести порядок — убрать дубли, добавить дату актуальности и владельца.

Что делать со сканами договоров и инструкций?

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

Как быть с персональными данными в документах?

Решить до загрузки. Если данные не нужны для ответов (например, ФИО и телефоны клиентов в договорах), их вырезают или обезличивают. Если нужны — скажем, ассистент для менеджеров смотрит статусы клиентов, — настраивают права доступа и размещают модель так, чтобы данные не уходили за пределы контура. Конкретные требования 152-ФЗ стоит проверить с юристом.

Кто готовит базу знаний: мы сами или подрядчик?

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