База знаний компании: как проверить, что сотрудник находит правильную инструкцию

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

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

Задача про замену, которую нельзя решить по заголовку

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

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

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

Выберите задачи, в которых ошибка имеет последствия

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

У тестового вопроса должен быть конкретный результат: найти правило и выполнить шаг или объяснить, почему шаг нельзя сделать. «Что у нас есть по гарантиям?» годится для исследования терминов, но слаб для проверки рабочего решения. «Куда направить заявку дилера о поломке после установки и можно ли назвать срок?» сильнее: ответ можно проверить по маршруту и ограничениям.

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

Как задать правильный ответ, не превращая его в одну фразу

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

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

Рекомендация W3C PROV-O описывает модель происхождения данных через сущности, действия и участников. Для рабочей проверки достаточно сохранить понятную связь ответа с источником, его версией и владельцем. Если ссылка ведёт на файл без номера версии, не всегда можно объяснить, почему вчера был другой ответ. Это особенно заметно после обновления инструкций.

Три проверки, три разных владельца

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

Представим 24 задачи. В 20 нашли нужный источник. Из них в 16 сотрудник или агент правильно изложил правило. Из этих 16 только в 12 можно выполнить следующий шаг без звонка старшему сотруднику. Если отчёт показывает «83% успешности», он описывает поиск. Если показывает «50%», он описывает исполнение по принятой методике. Покажите все ступени. Иначе работу по улучшению прав поручат редактору справки.

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

Проверяйте на разных ролях и версиях

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

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

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

Контрольные задания, которые стоит прогнать

Где брать задания и кто утверждает эталон

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

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

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

Найденная инструкция и выполненная задача: как измерить время

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

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

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

Как проверять запросы, где правильного ответа нет

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

Второй тип — вопрос содержит недостаточно условий. «Можно ли оформить замену?» требует определить канал, продукт и состояние заказа. Хороший ответ уточняет то, что влияет на решение. Не надо спрашивать всё сразу, если одно условие определяет нужную ветку. Сотрудник должен понимать, почему его просят уточнить канал, а не воспринимать это как отказ системы.

Третий тип — видимое противоречие. В одном файле указан срок, в другом другой. Здесь важно распознать конфликт, назвать применимые версии, предложить проверку владельцем. Если внутренний регламент определяет приоритет, эталон должен это отразить. Если приоритета нет, ответ не выбирает победителя по красоте заголовка. У пользователя остаётся конкретное действие, а редактор получает основание устранить расхождение.

Что исправлять сначала после теста

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

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

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

Как использовать результат после первого прогона

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

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