1. Главная
  2. Docs
  3. Глоссарий
  4. Подготовка базы знаний

Подготовка базы знаний

10

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

Инвентаризация: где живут знания и что реально спрашивают

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

Что спрашивают, важнее того, что лежит. Логи обращений и тикетов за 3–6 месяцев, интервью с поддержкой и типовые вопросы новых сотрудников дают список реальных вопросов. Как правило небольшой набор тем закрывает большую часть обращений — корпус строится вокруг этого набора, а не вокруг того, что удобнее выгрузить.

Разрыв между вопросами и документами — главный вывод инвентаризации. Часть вопросов не покрыта ничем — эти документы предстоит написать; часть покрыта тремя противоречащими версиями — эти предстоит разбирать. Обе работы всплывают до индексации или становятся инцидентами после запуска.

Критерии отбора: что включать и что нет

Частота обращений — первый критерий. В корпус идут темы, по которым спрашивают регулярно. Справка, нужная одному человеку раз в год, — работа ассистента или эксперта, а не контент базы: она не окупает шум в поиске и место в индексе.

Изменяемость определяет сопровождение. Часто меняющиеся документы — тарифы, регламенты с регулярными правками — включаются только вместе с владельцем и сроком пересмотра, иначе база устаревает быстрее, чем её осваивают пользователи.

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

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

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

Очистка: дубли, версии, противоречия

Дубли бывают точные и смысловые. Точные — файл в Word, PDF и скан — выявляются сравнением автоматически; смысловые — два регламента об одном процессе — ищутся поиском по пересечениям и проверяются человеком. В корпусе остаётся один канонический документ.

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

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

Владельцы и регламент обновлений

У каждого документа — владелец, дата актуальности, срок пересмотра. Владелец — ответственный за процесс, про который написан документ, а не ИТ-отдел: ИТ отвечает за конвейер, содержание — за бизнес. Дата актуальности видна пользователям и попадает в ответы — дешёвый способ вернуть доверие к базе.

Регламент описывает события, а не пожелания. Изменение документа — переиндексация по событию; полная ревизия корпуса — раз в квартал или полгода в зависимости от изменчивости; отзыв документа — исключение из индекса в тот же день. Без регламента база деградирует за 6–12 месяцев — это и есть дрейф данных в чистом виде.

Где уместно и когда нужно

Полный цикл подготовки нужен промышленной системе. Бот по базе знаний, внутренний поиск, RAG-ассистент для сотрудников — везде, где система отвечает людям без оператора, качество корпуса критично. Механика следующего этапа — в статьях «Индексация документов» и «Чанкинг».

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

Типичные ошибки

  • «Загрузим всё и посмотрим». Шум понижает точность поиска, противоречия — доверие; оба эффекта не видны на пяти тестовых вопросах и проявляются в эксплуатации.
  • Один документ в трёх форматах. Word, PDF и скан одного регламента индексируются как три источника: ответы дублируются, цитаты расходятся, поддержка получает три версии правды.
  • Включение без проверки прав. Поиск не спрашивает разрешения — он отдаёт всё, что проиндексировал; закрытые документы попадают в выдачу всем, у кого есть доступ к боту.
  • Нет владельцев. База устаревает, система продолжает отчитываться высокими метриками, пользователи уходят в чаты — возврат их в базу после потери доверия занимает месяцы.
  • Противоречия «разберём после запуска». После запуска на разбор нет ни ресурса, ни мотива; инцидент с неверным ответом наступает раньше плановой ревизии.
  • Очистка как разовый проект. Без регламента обновлений качество возвращается к исходному за несколько месяцев; подготовка — процесс, а не этап.

Частые вопросы

Сколько документов нужно для старта?

Качество важнее объёма: 100–500 актуальных документов обычно закрывают типовой сценарий поддержки. Пять тысяч нечищеных файлов дадут худший результат, чем триста выверенных.

Как часто переиндексировать базу?

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

Кто должен быть владельцем документа?

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

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

Не включать в основной индекс. Если архив нужен для поиска — отдельный индекс с явной пометкой «архив» в ответах и собственным разграничением доступа; смешивать архив с актуальным корпусом нельзя.

Как понять, что база мешает, а не помогает?

По метрикам RAG и доле ответов со ссылкой на неактуальный или противоречивый документ; косвенный признак — падение обращений к боту при росте вопросов в чатах. Метрики разобраны в статье про метрики RAG.

Нужно ли наводить порядок в названиях и структуре файлов?

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

Что почитать по теме