Базу знаний убивает не нехватка статей. Через полгода после запуска в ней уже есть всё нужное — и половина этого противоречит реальности: цены другие, поставщик сменился, порядок возврата отменён приказом в марте. Сотрудник в такой базе перестаёт искать и идёт спрашивать коллегу. ИИ-ассистент поступает хуже: он находит отменённый порядок и уверенно пересказывает его клиенту.
Лечится это не редактором в штате, а регламентом из пяти правил, которые распределяют работу между теми, кто и так меняет реальность. Сквозной пример один на всю статью: интернет-магазин, 60 человек, база знаний из 240 статей в шести разделах, четыре владельца разделов, бот отвечает клиентам в мессенджере, опираясь на эту же базу. Как базу собрать с нуля, разобрано отдельно в материале про то, как собрать базу знаний для ИИ-ассистента; здесь — как не дать ей протухнуть.
Пять правил регламента
Регламент помещается на одну страницу. Длиннее — не читают; короче — не работает, потому что исчезают сроки и фамилии.
- 1Владелец раздела — фамилия, а не отдел. «За раздел „Доставка“ отвечает руководитель логистики.» Отдел ответственным быть не может: у отдела нет календаря и нет обязанности прийти в базу к четвергу.
- 2У каждой статьи есть срок жизни. По умолчанию шесть месяцев. Для статей про цены, тарифы и сроки поставки — один месяц. Для статей про требования закона — до ближайшей известной даты изменения. Срок ставится в поле «актуально до» при публикации, а не когда-нибудь потом.
- 3Правку вносит тот, кто изменил реальность. Поменяли условия возврата — статью правит инициатор изменения, а не поддержка, которая узнает об этом от первого рассерженного клиента. Владелец раздела при этом принимает правку: у любого изменения есть автор и есть тот, кто его пропустил.
- 4В статье стоит дата актуальности и ссылка на источник правды. Источник правды — приказ, страница сайта, карточка товара в учётной системе. Если статья и источник расходятся, прав источник, а статья немедленно уходит на правку.
- 5Раз в квартал проходит ревизия выборки. Не всей базы: 20 статей, три вопроса к каждой, четыре часа работы. Полная ревизия «когда-нибудь» не случается никогда, выборочная случается всегда.
Полугодовой срок выбран не из осторожности, а из практики: за шесть месяцев в компании на 60 человек успевают смениться цены, один поставщик и один внутренний порядок. Год — это уже два таких цикла, и к моменту пересмотра статью проще переписать заново, чем понять, что именно в ней перестало быть правдой.
Форма статьи: шесть обязательных полей
Статья базы знаний — не заметка, а карточка одинаковой формы. Единообразие здесь не эстетика: оно определяет, найдёт ли статью человек и правильно ли процитирует её ассистент.
| Поле | Что в нём | Пример из базы магазина |
|---|---|---|
| Заголовок-вопрос | Формулировка так, как спрашивает человек | Как вернуть товар, купленный по акции? |
| Короткий ответ | 2–4 предложения, ответ в первом | Товар по акции возвращается на общих основаниях в течение 14 дней. Возвращается фактически уплаченная сумма, а не цена без скидки. |
| Условия применимости | Для кого и когда правило действует, и куда идти, если не подходит | Для заказов физических лиц с доставкой по России. Для юридических лиц — статья №118. |
| Источник правды | Документ или экран, который главнее статьи | Приказ №14 от 03.03.2026, раздел «Возвраты» на сайте |
| Владелец и автор | Две фамилии: кто написал и кто отвечает за раздел | Автор — старший оператор, владелец — руководитель клиентского сервиса |
| Даты | Дата последней правки и дата, до которой статья считается верной | Изменена 12.06.2026, актуальна до 12.12.2026 |
Поле «условия применимости» пропускают чаще всего, а оно самое ценное. Именно из-за него ассистент перестаёт давать розничный ответ оптовому клиенту: если условие написано словами, модель видит границу применения статьи и переключается на соседнюю. Тот же принцип, что и в описании процессов, — правило без границ применения не правило, а пожелание; подробнее об этом в материале про то, как описать регламент процесса.
Схема карточки статьи: прямоугольник, разделённый на шесть подписанных зон сверху вниз — «Заголовок-вопрос», «Короткий ответ, 2–4 предложения», «Условия применимости», «Источник правды», «Автор и владелец раздела», «Изменена / актуальна до». Две нижние зоны выделены жирной рамкой. Справа сбоку узкая полоса статуса с тремя положениями: «черновик», «опубликована», «архив». Чертёжный стиль, подписи по-русски.
Триггеры обновления и судьба устаревшей статьи
Регламент работает, если у каждого типа изменения есть свой ответственный и свой срок. Иначе действует правило «узнают все, не приходит никто».
| Что изменилось | Кто обязан прийти в базу | Срок |
|---|---|---|
| Цена, тариф, срок доставки | Руководитель, утвердивший изменение | 1 рабочий день |
| Внутренний порядок или регламент | Владелец процесса | 3 рабочих дня |
| Требование закона или площадки | Ответственный за это направление | До даты вступления требования в силу |
| Поставщик, подрядчик, условия договора | Закупщик или инициатор смены | 3 рабочих дня |
| Поведение системы после релиза | Руководитель проекта со стороны заказчика | В день релиза |
| Повторяющийся вопрос клиентов без статьи | Владелец раздела | 5 рабочих дней после третьего обращения |
Последняя строка — единственный способ наращивать базу осмысленно. Не «напишите статьи по всем темам», а «третье одинаковое обращение автоматически рождает задачу на статью». Такое правило удобно вешать на классификацию обращений: система сама считает частоту тем и показывает, какой статьи не хватает.
Отдельный вопрос — что делать со статьёй, которая перестала быть верной. Удаление кажется гигиеничным решением и создаёт две проблемы. Во-первых, исчезает возможность объяснить претензию: клиент обратился в апреле, действовал апрельский порядок, и доказать это нечем. Во-вторых, теряется история — через год никто не сможет понять, почему бот три месяца отвечал не то.
Рабочая формулировка для регламента: «Статья, переставшая быть верной, переводится в статус „архив“ с указанием даты и причины. Архивные статьи исключаются из индекса ассистента, но остаются доступны сотрудникам по прямой ссылке и в поиске с фильтром „включая архив“. Удаление статьи возможно только по требованию закона.» Ключевое здесь — про индекс: если архив остаётся в источнике для ассистента, вся операция бессмысленна, бот продолжит цитировать отменённое.
Горизонтальная лента жизненного цикла с пятью отметками: «Черновик — пишет автор», «Опубликована — принял владелец раздела», «Срок жизни 6 месяцев, для цен 1 месяц», «Триггер или срок — пересмотр», «Архив: исключена из индекса ассистента, доступна людям». От отметки «Пересмотр» вниз ответвление «правка → снова опубликована», от неё же вбок ответвление «не актуальна → архив». Чертёжный стиль, подписи по-русски.
Квартальная ревизия: 20 статей, три вопроса и её цена
Ревизия делается по выборке, а не по всей базе. Двадцать статей из 240 — это 8 % базы за квартал и треть базы за год, чего достаточно, чтобы поймать системную протухаемость. Выборка формируется не случайно: пять самых читаемых, пять с ближайшей датой окончания срока, пять из раздела, который менялся, пять случайных.
- 1Вопрос первый: это до сих пор правда?
Владелец раздела сверяет статью с источником правды. Ответ «наверное» приравнивается к «нет» и означает правку.
- 2Вопрос второй: её кто-нибудь открывал?
Смотрим число просмотров и число обращений ассистента к статье за квартал. Ноль — повод не переписывать, а спросить, зачем она есть. Часто это признак, что вопрос сформулирован не так, как его задают люди.
- 3Вопрос третий: сотрудник делает так же?
Один звонок исполнителю: «Расскажи, как ты это делаешь». Расхождение между статьёй и практикой означает, что неверна либо статья, либо практика, и разбираться надо сейчас, а не в момент претензии.
По каждой статье принимается одно из трёх решений: оставить и продлить срок, поправить, архивировать. Решение записывается — иначе на следующей ревизии та же статья будет обсуждаться заново.
Теперь цена вопроса. Расчёт по канонным для журнала ставкам: владелец раздела — руководитель подразделения, 1 800 ₽/час, оператор поддержки — 700 ₽/час. Средняя стоимость возврата, принятого по отменённым условиям, взята как 1 900 ₽ — разница между старым и новым порядком в модельном примере.
Соотношение примерно двукратное в пользу ревизии, и это ещё скромная оценка: в расчёт не вошли ни репутационные последствия, ни то, что после публичного разбора сотрудники перестают доверять базе целиком. А недоверие к базе стоит дороже любой отдельной ошибки — люди возвращаются к вопросам в чате, и весь смысл проекта исчезает.
Ошибка бота — это чаще всего дефект базы
Когда ассистент отвечает неправильно, первым делом предлагают «поменять модель» или «дописать промпт». В разборе журнала ответов картина обычно другая. Из десяти разобранных ошибок шесть — статьи нет или она устарела, две — формулировка допускает два прочтения, и только две относятся к поиску и самой модели.
Смена модели стоит недели работы и денег, а исправление шести статей — часа. Порядок разбора любой жалобы на ответ бота: сначала найти статью, по которой он ответил, потом проверить её дату актуальности, потом посмотреть, нет ли двух статей с противоречащими ответами, и только затем идти в настройки. Механика того, почему поиск находит не то, разобрана в материале о том, почему поиск по базе знаний ошибается.
Практическое следствие для регламента: каждая жалоба на ответ ассистента обязана заканчиваться либо правкой статьи, либо записью «база в порядке, дефект в поиске». Второй вариант должен быть редким. Если он встречается чаще чем в трети случаев, проблема действительно техническая, и тогда стоит смотреть на подготовку базы к индексации — как это устроено, разобрано в материале про обновление базы знаний бота.
Когда регламент — лишняя бюрократия
Пять правил рассчитаны на базу, которую читают люди, не писавшие её. Если это не ваш случай, регламент создаёт работу и не создаёт пользы.
- Меньше 30 статей и меньше 10 сотрудников. Такую базу держит в голове один человек, и её заменяет один документ с оглавлением. Достаточно одного правила из пяти — даты актуальности.
- База ведётся ровно теми, кто ею пользуется — например, два инженера пишут для себя. Владелец раздела и ревизия здесь не нужны: расхождение с практикой они заметят в тот же день.
- Правила меняются реже раза в год — узкое производство по стабильной технологии, где инструкция 2019 года до сих пор верна. Тогда срок жизни статьи ставится в год, а ревизия делается вместе с годовым пересмотром документации.
- Ассистента нет и не планируется. Часть требований — про индексацию и границы применимости — существует ради машины. Если базу читают только люди, эти пункты можно опустить, оставив владельца, дату и порядок правки.
И честная граница снизу: регламент бесполезен, если в нём нет фамилий. Документ, где написано «ответственность за актуальность несут все сотрудники», не регламент, а декларация. Лучше назначить одного владельца на всю базу и ревизию раз в полгода, чем расписать шесть разделов между отделами — второе выглядит убедительнее и не работает.
