Как перенести базу знаний и не перенести хаос

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

Формально это база знаний. Практически — лотерея.

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

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

Переезд базы не лечит старые противоречия

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

Но база знаний — не архив. Клиент и оператор идут туда не за историей изменений, а за ответом, которому можно доверять. Если в старой базе жили разные версии одного процесса, после импорта они продолжат конкурировать между собой.

Типичная проблема выглядит так:

• статья для клиента говорит одно;
• внутренний регламент для оператора — другое;
• старая инструкция из прошлого интерфейса всё ещё находится поиском;
• короткая заметка «временно делаем так» осталась навсегда.

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

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

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

Дубли редко выглядят как полные копии. Чаще это родственники: статьи с похожими названиями, заметки после запуска новой функции, инструкции под разные отделы, старые ответы из макросов.

Например, в базе есть «Как вернуть оплату», «Возврат денег клиенту», «Возврат по карте» и «Шаблон ответа про возврат». Каждая появилась по делу. Одна — после вопроса клиента, другая — для бухгалтерии, третья — после изменения банка, четвёртая — как быстрый ответ оператору.

Через год никто уже не помнит, какая главная.

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

Рабочий способ простой:

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

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

Если базы как таковой ещё нет и вы только собираете первые материалы, лучше не начинать с большого дерева разделов. Мы уже разбирали, почему первые статьи стоит выбирать из вопросов, которые команда отвечала на этой неделе, а не из воображаемой идеальной структуры.

Устаревшее лучше пометить до импорта, а не искать после жалобы

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

В базе часто остаются инструкции после смены тарифов, доставки, интерфейса, реквизитов, SLA, правил возврата. Их не удаляли не из вредности. Просто в момент изменения процесса задача была «срочно сообщить команде», а не «почистить все связанные статьи».

Перед переносом полезно пройти базу с тремя метками:

• оставить — статья актуальна и нужна;
• обновить — тема нужна, но текст расходится с реальностью;
• убрать — статья больше не должна находиться поиском и попадать в ответы.

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

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

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

Один формат важнее красивого оглавления

После удаления дублей и отметки устаревшего остаётся ещё одна работа: привести ответы к одному виду.

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

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

• что это за ситуация;
• короткий ответ клиенту;
• условия и ограничения;
• что должен сделать оператор;
• что написать, если условие не выполнено;
• связанные статьи или документы.

Для публичной базы часть внутренних пунктов не нужна. Клиенту не надо знать, в какой отдел передаётся заявка после проверки. Ему нужно понять, что отправить, куда нажать, сколько ждать и что будет дальше.

Для внутренней базы наоборот важны детали: кто ответственный, какой статус поставить, когда звать старшего, что нельзя обещать. Если смешать это в одной статье без разделения, клиент увидит служебную кухню, а оператор будет вылавливать действия среди объяснений.

Это особенно важно, если база будет использоваться не только людьми, но и ассистентом. Ему нужны тексты, из которых можно собрать прямой ответ. Регламенты, написанные для сотрудников, часто плохо подходят для клиента: там много сокращений, внутренних ролей и шагов без контекста. Эту разницу мы подробно разбирали в статье о том, чем кормить ИИ-ассистента, чтобы он отвечал по делу.

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

Импорт стоит делать партиями, а не одним большим мешком

Когда база разобрана, появляется соблазн загрузить всё сразу. Иногда это нормально: если статей мало, команда рядом, а спорные материалы уже убраны.

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

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

• находится ли нужная статья по словам клиента, а не только по внутреннему названию;
• нет ли рядом старой версии с похожим заголовком;
• понятен ли первый абзац без контекста;
• есть ли следующий шаг;
• не смешаны ли клиентские ответы и внутренние указания.

Такой подход медленнее на старте. Зато вы не просыпаетесь с новой базой, в которой 400 статей, но никто не понимает, какие из них можно использовать.

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

В DeskAI можно загружать статьи и документы из PDF, Word, текстов и сайтов; база может быть публичной или внутренней, с разделами и статьями в Markdown. Эти материалы становятся источником ответов для ассистента: поиск находит релевантные фрагменты, а в ответах видны источники. Поэтому перед импортом особенно важно не тащить в базу дубли и устаревшие инструкции.

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