Очистка базы знаний перед подключением ассистента

Почему плохое содержание даёт плохие ответы

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

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

Противоречия усугубляют ситуацию. Одна страница говорит, что у клиентов 14 дней на отмену. Другая — 30. Обе выглядят официально. Ассистент может выбрать одну сегодня, а другую завтра, даже при том же вопросе.

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

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

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

С чего начать проверку

Начните с простого инвентаря. Прежде чем что-то удалять или переписывать, запишите все места, к которым ассистент может обращаться сегодня. Большинство команд пропускает хотя бы один источник — и именно через него плохие ответы переживают очистку.

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

Для каждого источника отмечайте четыре вещи:

• где он хранится
• какой тип контента содержит
• кто его читает
• используют ли его ещё для ответов на реальные вопросы

Тип контента важнее, чем кажется. Сгруппируйте политики вместе. Сложите справочные статьи в одну корзину. Отдельно держите SOP. То же самое для FAQ, заметок о релизах и внутренних инструкций по устранению неполадок. Как только контент упорядочен, конфликты становятся очевидными. Страница с политикой по возвратам не должна тихо сосуществовать рядом со старым ответом в FAQ, который говорит обратное.

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

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

Если команда небольшая, не нужен громоздкий инструмент — простая таблица подойдёт: одна строка на источник, один владелец, дата последней проверки и статус вроде active, stale, duplicate или internal-only.

Этот первый проход даёт карту. Без неё вы не чистите систему — вы угадываете.

Как найти дубликаты и похожие страницы

Начните с кластеров по теме, а не по заголовкам. Две страницы могут отвечать на один и тот же вопрос, хотя выглядят по-разному. Страница «Сброс пароля» и «Изменение доступа к входу» могут быть тем же документом под разными именами.

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

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

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

Откройте предположительные совпадения рядом и сравните вводную часть, шаги и скриншоты. Небольшое дрейфование имеет значение. Если на одной странице написано «Перейдите в Billing», а на другой — «Перейдите в Plans», кто‑то, скорее всего, скопировал старую страницу и отредактировал лишь часть.

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

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

Иногда похожие страницы должны оставаться раздельными. В таком случае сделайте различие очевидным в заголовке и первых строках: «Для клиентов» и «Для сотрудников финансового отдела» — ясно. Два расплывчатых заголовка — нет.

Если вы не можете объяснить, почему обе страницы существуют, вероятно, вам нужна только одна.

Как работать с устаревшими страницами

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

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

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

Простой аудит по устаревшим страницам обычно выявляет большую часть проблем:

• статьи без проверки за 6–12 месяцев
• страницы, где упоминаются старые названия продуктов или команд
• руководства со скриншотами старых интерфейсов
• рабочие процессы, основанные на инструментах, которые команда уже заменила

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

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

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

Так устаревший контент остаётся живым задолго после изменений в процессе.

Как решать конфликты в политиках

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

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

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

Простой процесс работает хорошо:

1. Скопируйте каждую версию правила дословно.
2. Назовите команду или человека, ответственного за решение.
3. Выберите текущее правило и напишите причину в одном предложении.
4. Пометьте все страницы, которые теперь с ним не согласуются, для удаления или архивации.

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

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

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

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

Простой рабочий процесс очистки

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

Начните с инвентаря. Перечислите все страницы, PDF, статьи помощи, записи FAQ и заметки политики, которые могут попасть в выдачу, затем присвойте каждой статус: keep, update, merge, archive или delete.

Эта одна метка делает много работы. Она останавливает обычный беспорядок, когда старая страница, черновик и новая версия сидят рядом и выглядят одинаково доверенными для ассистента.

Затем работайте по порядку.

Удалите мусор первым делом. Уберите тестовые страницы, пустые черновики, некорректные импорты и всё, что вы бы не хотели, чтобы ассистент цитировал.

Слейте дубликаты следующими. Если две страницы отвечают на один вопрос, оставьте более понятную и перенесите недостающие детали в неё.

Потом перепишите конфликтные места. Когда условия возврата, правила доступа или обещания поддержки не совпадают, выберите одно текущее правило и уберите остальные.

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

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

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

Закончив один полный цикл очистки, переиндексируйте. Это даст вам более чистую отправную точку и ускорит следующий раунд.

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

Пример: путаница с политикой возвратов

Клиент задаёт простой вопрос: «Сколько времени занимает возврат?» Ассистент ищет в базе знаний и находит три разных ответа. В справочном центре говорится, что возвраты занимают 30 дней. В FAQ отдела продаж — 14 дней. Внутренний SOP говорит агентам предлагать сначала кредит магазина.

Модель делает то, что часто делают системы поиска при неаккуратных исходниках: она смешивает все три ответа в один отшлифованный ответ: «Обычно возврат занимает 14 дней, хотя иногда может занять до 30 дней. Сначала может быть предложен кредит магазина.» Это звучит спокойно и уверенно. Но это неверно.

Проблема не в тоне модели, а в том, что каждый документ имел свою роль, и никто этого явно не отметили. Публичная статья отвечает клиентам. FAQ по продажам может упрощать условия, чтобы ускорить сделку. Внутренний SOP говорит агентам, что попытаться сначала предложить кредит, прежде чем одобрять возврат наличными. Когда все три находятся в одном индексе без меток или приоритетов, ассистент считает их одинаково валидными.

Именно поэтому очистка должна происходить до включения поиска. Ассистент не сможет сам решить конфликт политики, если документы противоречат друг другу.

Типичное корректирующее действие выглядит так:

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

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

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

Ошибки, которые сохраняют плохие ответы

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

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

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

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

Короткая проверка устраняет это быстро:

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

Владение важнее, чем многие думают. Когда поддержка, юридический отдел, продукт и продажи могут публиковать правила, дрейф начинается почти мгновенно. Ассистент не способен определить, какая команда имела последнее слово — он видит только конкурирующий текст.

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

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

Короткие проверки перед переиндексацией

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

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

Перед переиндексацией подтвердите четыре вещи:

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

Этот ручной контроль важнее, чем многие предполагают. Выдача может выглядеть чисто в таблице, но провалить практическую проверку. Быстрая проверка с 10–20 реальными вопросами обычно выявляет последние проблемы: старые названия, полуручно удалённые страницы или абзац политики из прошлого года.

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

Что делать после очистки

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

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

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

Простая рутина работает хорошо:

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

Тестирование важнее, чем кажется. После переиндексации задавайте ассистенту те же вопросы, которые клиенты и сотрудники задают каждую неделю. Ищите ответы, которые звучат уверенно, но пропускают лимиты, даты, исключения или новую формулировку политики.

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

Если после очистки ассистент по‑прежнему выдаёт плохие ответы, проблема может быть в настройках поиска, структуре документов или в общей настройке ИИ, а не только в контенте.

Если нужна вторая оценка, Oleg Sotnikov на oleg.is делает такие ревью в роли Fractional CTO и консультанта стартапов. Это помогает, когда контент выглядит чистым на бумаге, но ассистент всё ещё даёт нестабильные ответы в продакшене.