База знаний собирается в шесть шагов, и первый из них — не написание статей, а сбор пятидесяти реальных вопросов клиентов с эталонными ответами. Этот набор нужен до того, как написана первая статья: он показывает, о чём на самом деле спрашивают, и он же служит линейкой, по которой потом измеряют качество. Без него база пишется по представлениям сотрудников о том, что важно, и на 30–40 % состоит из разделов, которых никто не спрашивает.
Вторая вещь, которую стоит принять до начала. Ассистент врёт не потому, что модель плохая, а потому, что в базе лежат два действующих документа с разными цифрами. Модель честно находит оба и выбирает тот, который лучше похож на вопрос. Разбор противоречий между источниками — самая недооценённая работа проекта: она не выглядит технической, её невозможно поручить подрядчику целиком и она определяет качество ответов сильнее, чем выбор модели.
Ниже — критерий пригодности документа, формат одной статьи, порядок сборки с проверяемым результатом на каждом шаге, методика замера по пятидесяти вопросам и расчёт стоимости на модельной базе из 120 статей. Технические подробности нарезки и метаданных вынесены в отдельный материал, здесь важнее последовательность действий.
Что годится в базу, а что нет
Критерий один и он проверяется за десять секунд: у документа есть дата вступления в силу и есть человек, который отвечает за его содержание. Если хотя бы одного нет, документ в базу не идёт — не потому, что он плохой, а потому, что его нельзя будет обновить и нельзя будет спросить, кто решил именно так.
| Годится | Почему | Не годится | Почему |
|---|---|---|---|
| Действующий регламент с датой и владельцем | Есть кому задать вопрос и понятно, с какого числа правило работает | Переписка в рабочем чате | Договорённость без даты и без статуса: неизвестно, отменили её через час или нет |
| Приказ или распоряжение | Дата и подпись есть по определению | Устная договорённость с клиентом | Её вообще нет в природе как текста; сначала оформить, потом класть в базу |
| Прайс в машиночитаемом виде | Цены разбираются построчно и обновляются целиком | Скан прайса картинкой | Разбирается с ошибками и почти гарантированно устареет незаметно |
| Инструкция, по которой реально работают | Совпадает с практикой, значит ответы совпадут с тем, что скажет сотрудник | Инструкция, которую все обходят | Ассистент начнёт отвечать правильнее сотрудников — и клиенты найдут расхождение |
| Ответы поддержки, прошедшие вычитку | Написаны словами клиента, а не языком регламента | Презентация для клиента | Маркетинговые формулировки без условий применимости превращаются в обещания |
| Описание тарифов с условиями и датами | Понятно, к какому тарифу относится каждое условие | Черновик без владельца | Некому подтвердить, что это действующая версия, а не чьи-то мысли |
На отсеве обычно вылетает 30–50 % того, что изначально принесли в проект. Это нормальный результат и хороший знак: значит критерий применяли всерьёз. Плохой знак — когда в базу приняли всё, что нашли, потому что «пусть будет, лишним не будет». Лишний документ в базе не нейтрален: он конкурирует за место в ответе с правильным.
Сравнение в два столбца, чертёжный стиль. Левый столбец «Годится» с шестью строками: действующий регламент, приказ, прайс в машиночитаемом виде, рабочая инструкция, вычитанные ответы поддержки, описание тарифов с датами. Правый столбец «Не годится» с шестью строками: переписка в чате, устная договорённость, скан прайса картинкой, инструкция, которую обходят, презентация для клиента, черновик без владельца. Между столбцами вертикальная полоса-фильтр с надписью «есть дата вступления в силу + есть имя владельца». Внизу подпись «на отсеве вылетает 30–50 % принесённого». Подписи по-русски.
Формат одной статьи и правило нарезки
Статья базы знаний — это не кусок регламента и не абзац из инструкции. Это самостоятельный ответ на один вопрос, который читается отдельно от всего остального. Семь полей ниже — минимальный набор, без которого база не обновляется и не фильтруется.
- 1Заголовок — вопрос словами клиента. «Можно ли перенести занятие за день до начала» вместо «Порядок изменения расписания». Разница не косметическая: поиск сравнивает вопрос пользователя с текстом статьи, и совпадение по формулировке работает лучше любых настроек.
- 2Ответ в первых двух предложениях. Прямой, без разбега. Всё остальное — уточнения ниже. Если ответ начинается со слов «в соответствии с пунктом», статья написана не для читателя.
- 3Условия применимости. Для каких тарифов, категорий клиентов, регионов и с какой даты. Отсутствие условий — главная причина, по которой ассистент даёт верный ответ не тому клиенту.
- 4Что делать, если условие не выполняется. Одно предложение с направлением: куда обратиться, к кому. Это поле превращает статью из справки в инструкцию.
- 5Дата актуальности. Не дата создания файла, а дата, до которой содержание считается достоверным. Прайс — на квартал, регламент — на год, описание акции — на срок акции.
- 6Владелец — имя, а не отдел. «Отдел продаж» не может подтвердить формулировку, а конкретный человек может. У кого спрашивать при разночтении — вопрос, который возникает в первый же месяц.
- 7Метка контура: клиентская статья или внутренняя. Одна из самых дешёвых настроек и одна из самых дорогих при отсутствии: без метки ассистент однажды процитирует клиенту внутреннюю инструкцию по работе с должниками.
Нарисованная абстрактная карточка статьи базы знаний в чертёжном стиле, без имитации конкретного продукта. Сверху крупная строка-заголовок с пометкой «вопрос словами клиента». Ниже блок «ответ — первые два предложения» с выделенной рамкой. Далее четыре узкие строки: «условия применимости», «что делать, если условие не выполняется», «дата актуальности», «владелец — имя». В правом верхнем углу карточки квадратная метка «контур: клиентский / внутренний». Сбоку выноска: «одна статья — 25 минут работы, около 290 ₽». Все подписи по-русски.
Правило нарезки короткое: документ на 40 страниц режут по смысловым блокам, а не по количеству знаков. Один кусок — один законченный ответ; заголовок раздела остаётся при куске, иначе кусок теряет контекст и перестаёт находиться. Таблицы — отдельная боль: разрезанная посередине таблица тарифов даёт склейку строки одного тарифа с ценой другого, и ошибка при этом выглядит абсолютно правдоподобно. Таблицы либо кладут целиком, либо разворачивают в текст построчно. Подробный разбор нарезки, метаданных и правила актуальности мы вынесли отдельно — это уже инженерная часть работы.
Порядок сборки: шесть шагов с проверкой
Шаги идут в этом порядке не случайно. Самая частая ошибка — начать с написания статей, потому что это понятная работа, и обнаружить на четвёртой неделе, что половина написанного отвечает на вопросы, которых никто не задаёт, а по трети тем в компании нет единого мнения.
- 1Шаг 1. Проверочный набор из 50 вопросов
Берутся реальные обращения за последние 2–3 месяца, а не придуманные. К каждому вопросу пишется эталонный ответ и указывается эксперт, который его подтвердил. Получилось, если все 50 вопросов взяты из переписки или записей звонков дословно, у каждого есть эталон и имя подтвердившего, а среди вопросов есть 5–7 заведомо неудобных — про исключения, отказы и спорные ситуации.
- 2Шаг 2. Инвентаризация источников
Список всего, где сейчас живут правила: регламенты, приказы, прайсы, инструкции, папки на дисках, статьи внутренней вики. По каждому — где лежит, кто владелец, когда правился последний раз. Получилось, если в списке у каждой строки стоит имя человека и дата, а строк без владельца не осталось ни одной: у документа без владельца сначала находят владельца, потом решают его судьбу.
- 3Шаг 3. Отсев по критерию пригодности
Из списка вычёркивается всё, у чего нет даты вступления в силу или владельца, а также всё, что противоречит фактической практике. Получилось, если вычеркнуто 30–50 % источников и по каждому вычеркнутому записана причина. Если вычеркнуто меньше 10 %, критерий применяли формально и на замере это вылезет.
- 4Шаг 4. Разбор противоречий
По каждому спорному числу — цене, сроку, проценту, условию возврата — сверяются все источники, где оно встречается. Решение принимает владелец раздела, и оно записывается вместе с его именем и датой. Получилось, если по каждому найденному противоречию есть строка «правильная версия — такая, решил такой-то, дата», а проигравшая версия физически удалена из источников, а не просто помечена.
- 5Шаг 5. Написание статей в едином формате
Каждая статья — семь полей, ответ в первых двух предложениях, язык клиента. Пишут сотрудники, которые отвечают на эти вопросы каждый день, а вычитывают владельцы разделов. Получилось, если случайно выбранную статью посторонний сотрудник прочитал и смог по ней ответить клиенту, не задав ни одного уточняющего вопроса.
- 6Шаг 6. Загрузка, нарезка и первый замер
База нарезается, загружается в хранилище, настраивается поиск. Затем прогоняется проверочный набор из 50 вопросов и считаются три доли: верных ответов, честных отказов, уверенных выдумок. Получилось, если доля верных выше 80 %, доля выдумок ниже 10 %, а по каждому неверному ответу понятно, какая статья виновата.
Схема-конвейер слева направо из шести блоков: «50 вопросов с эталонами» → «Инвентаризация источников» → «Отсев по критерию» → «Разбор противоречий» → «120 статей в едином формате» → «Нарезка, загрузка, замер». От блока отсева вниз уходит стрелка в корзину с подписью «30–50 % источников»; от блока противоречий — стрелка вниз с подписью «15–25 находок, проигравшая версия удаляется». От первого блока идёт длинная пунктирная дуга поверх всей схемы к последнему с подписью «тот же набор служит замером». Под первыми пятью блоками полоса «делает компания», под последним — «нужен инженер». Подписи по-русски, чертёжный стиль.
Подрядчик не может написать вашу базу знаний за вас: он не знает, что вы отвечаете клиенту, который опоздал на два дня, и не имеет права решать, какая из двух версий правила действующая. Инженер нужен на шестом шаге и в сопровождении: нарезка, метаданные, хранилище, автоматический прогон замера, разграничение клиентского и внутреннего контуров. Проект, где подрядчик обещает «собрать базу знаний под ключ» без вашего участия, заканчивается пересказом сайта.
Противоречия: главная причина уверенного вранья
В любой компании старше трёх лет по одному и тому же вопросу существует два-три ответа. Срок возврата в регламенте — 14 дней, в описании на сайте — 10, а по факту менеджеры дают 30. Пока отвечают люди, расхождение сглаживается на ходу. Ассистент сглаживать не умеет: он находит оба документа и уверенно называет один из них.
Ищут противоречия двумя приёмами. Первый — прогон проверочного набора: расхождение видно сразу, потому что эталонный ответ есть. Второй — сквозной поиск по всем источникам по числам: ценам, срокам, процентам, размерам скидок. Каждое число, которое встречается в двух источниках в разном виде, попадает в список на разбор. На базе из 120 статей таких находок обычно 15–25.
Самая частая ошибка на этом шаге — пометить старый документ как неактуальный и оставить его лежать. Поиск не читает пометок: для него это ещё один текст, похожий на вопрос. Через месяц ассистент начнёт периодически отвечать по старой версии, и симптом будет мучительным — правильный ответ есть, но выдаётся через раз. Единственное надёжное решение: физически убрать проигравшую версию из того, что попадает в базу. Как устроена процедура замены и кто её выполняет, разбирали в материале о том, кто ведёт базу знаний поддержки.
Проверочный набор и «не знаю» как целевое поведение
Пятьдесят вопросов — рабочий минимум. Меньше тридцати не даёт разницы между «стало лучше» и «повезло», больше сотни никто не прогоняет вручную второй раз. Вопросы берутся из реальных обращений и обязательно включают неудобные: про исключения, про отказ, про спорную ситуацию, про то, чего у вас нет. Именно на них видно, врёт ассистент или честно отказывается.
Замер делается дважды: сразу после первой загрузки и после круга правок. Ниже — модельные числа по базе из 120 статей сервисной компании.
| Показатель | Первый прогон | После правок | Целевой порог |
|---|---|---|---|
| Верных ответов | 21 из 50 (42 %) | 41 из 50 (82 %) | не ниже 80 % |
| Честных отказов «не знаю» | 10 из 50 (20 %) | 6 из 50 (12 %) | не считается ошибкой |
| Уверенных выдумок | 19 из 50 (38 %) | 3 из 50 (6 %) | ниже 10 % |
| Правок в базе между прогонами | — | 23 статьи из 120 | — |
Обратите внимание на среднюю строку. Шесть честных отказов из пятидесяти — это не недоделка, а правильно настроенное поведение. Ассистент, который на любой вопрос отвечает уверенно, набирает 100 % ответов и произвольную долю правды; ассистент, который умеет сказать «не знаю, соединяю с сотрудником», ошибается редко и предсказуемо. Почему отказ дешевле выдумки и как этого добиться на уровне инструкции, разобрано в материале об ответе «не знаю» как целевом поведении. Общая методика замера качества на своих данных — в отдельном разборе о том, как измерить качество ИИ на своих данных.
Две вертикальные столбчатые группы «Первый прогон» и «После правок», каждая разделена на три сегмента с подписями чисел. Первый прогон: верных 21 из 50 (42 %), честных отказов 10 (20 %), уверенных выдумок 19 (38 %). После правок: верных 41 из 50 (82 %), честных отказов 6 (12 %), уверенных выдумок 3 (6 %). Между группами стрелка с подписью «23 правки из 120 статей». Горизонтальные пунктирные линии порогов: «верных не ниже 80 %» и «выдумок ниже 10 %». Сегмент отказов помечен подписью «не ошибка». Ось — доля ответов в процентах, подписи по-русски.
Сколько это стоит и сколько занимает
Модельная база: 120 статей для сервисной компании с 900 обращениями в поддержку в месяц. Ставки сквозные: полный час рядового сотрудника — 700 ₽, час инженера — 3 000 ₽. Одна статья пишется в среднем за 25 минут, то есть стоит около 290 ₽ рабочего времени — но только при условии, что источник уже существует. Если правило живёт в голове у эксперта, статья превращается в маленький проект по написанию регламента и занимает не 25 минут, а два часа с согласованием.
Пять-шесть недель календарно при 82 часах работы получаются потому, что эксперты дают проекту 2–3 часа в неделю, а не сидят над ним целиком. Это главная причина срыва сроков в таких проектах, и планировать надо сразу от доступности экспертов, а не от объёма работы. Поддержка — 10 правок в месяц по 15 минут плюс квартальный перезамер по проверочному набору.
Теперь честная часть про окупаемость. База сама по себе денег не экономит — экономит ассистент, который на ней работает.
Считать окупаемость только по стоимости базы было бы подтасовкой. К 171 400 ₽ надо прибавить самого ассистента: по рынку базовый агент с поиском по базе знаний — это 150 000–200 000 ₽ и 3–8 недель. Итого проект целиком обходится примерно в 346 000 ₽ и возвращается за 13–14 месяцев при 900 обращениях в месяц. Если обращений вдвое больше, срок сокращается вдвое — экономия здесь линейна по объёму, а расходы почти нет. Разбор состава такого ассистента и цен есть на странице чат-бота поддержки.
Есть и второй способ окупить ту же работу, о котором обычно забывают. База знаний нужна не только боту: по ней быстрее выходит на линию новый сотрудник. Если у вас текучесть в поддержке и каждый новичок два месяца задаёт вопросы коллегам, сокращение этого срока даёт сопоставимую экономию — и она наступает раньше, чем запустится ассистент.
Что пойдёт не так: шесть симптомов
Ошибки базы знаний проявляются не сообщениями об ошибке, а поведением ассистента. Шесть симптомов ниже покрывают почти всё, что всплывает в первый месяц.
| Симптом | Что за этим стоит | Что делать |
|---|---|---|
| Ответ пустой или «не найдено подходящих документов» на очевидный вопрос | Статья написана языком регламента, а вопрос задан словами клиента | Переписать заголовок как вопрос клиента и добавить в текст его формулировки |
| Правильный ответ есть, но выдаётся через раз | В базе лежат две версии документа, старая не удалена | Найти и физически убрать проигравшую версию; пометки «неактуально» не работают |
| Ассистент называет цену, которой нет в прайсе | В базу попал скан или устаревший прайс, срок актуальности не проставлен | Прайс класть только в машиночитаемом виде и обновлять целиком, а не правкой строк |
| Ответ склеен из условий двух разных тарифов | Таблица разрезана посередине при нарезке | Класть таблицу целиком либо разворачивать построчно в текст |
| Клиенту процитирована внутренняя инструкция | У статьи не проставлена метка контура | Разметить контуры до первого клиентского ответа, а не после инцидента |
| Ответ начинается словами «согласно пункту 4.2» | Статья скопирована из регламента без переписывания | Переписать: пункт может остаться ссылкой внизу, но не может быть началом ответа |
Отдельно стоит понимать, что часть промахов относится не к базе, а к поиску по ней: близкие по смыслу статьи конкурируют, и правильная не всегда выигрывает. Механику этих промахов и способы их лечения мы разбирали в материале о том, почему поиск по базе знаний ошибается. Практическое правило для автора базы простое: если два ответа регулярно путаются, чаще всего это не проблема поиска, а две статьи, которые надо объединить в одну.
Когда собирать базу целиком не надо
Полная сборка на 120 статей окупается не в каждой ситуации, и есть четыре случая, в которых мы советуем начать иначе или не начинать.
- Правила ещё не устоялись. Если тарифы, сроки и условия меняются раз в месяц, база будет устаревать быстрее, чем пишется. Сначала — стабилизировать хотя бы половину правил, потом собирать. Иначе вы получите 120 статей, из которых через квартал верны 60.
- Меньше 150 обращений в месяц. Экономия становится меньше стоимости поддержки базы, а времени на сборку уходит столько же. Разумный шаг — собрать 20–25 статей по самым частым вопросам для сотрудников, без ассистента, и вернуться к проекту при росте потока.
- Правила живут в головах и нигде не записаны. Тогда это не проект по базе знаний, а проект по написанию регламентов, и стоит он в разы дороже: не 25 минут на статью, а два часа с согласованиями. Это нормальная работа, но её надо назвать своим именем и запланировать отдельно.
- Вопросы не повторяются. Если в поддержку приходят уникальные инженерные задачи, а не типовые вопросы, доля закрываемых базой обращений будет не 45 %, а 5–10 %. Проверяется это за час: возьмите сто последних обращений и посчитайте, сколько из них попадают в двадцать самых частых тем.
И последнее. База знаний — это единственная часть проекта с ИИ, которая полезна сама по себе, даже если ассистента не будет. Регламент с датой, владельцем и разрешённым противоречием работает и без всякой модели: по нему отвечает сотрудник, обучается новичок и разрешается спор с клиентом. Поэтому если сомневаетесь, стоит ли начинать проект целиком, начните с базы — это единственный шаг, который не пропадёт ни при каком развитии событий.
Ассистент не знает больше вашей базы. Он знает ровно то, что вы согласились записать и подписать именем.
