3

WebTech

Личный кабинет

Проекты, коммерческие предложения, документы и отчёты — в одном месте.

Войти Зарегистрироваться Забыли пароль?
База знаний

Единый источник правды для ассистента и для операторов

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

Или сразу: +7 (962) 368-39-51 Telegram

гибрид
лексический поиск плюс векторные эмбеддинги
top-5
фрагментов уходят в контекст модели после реранкинга
PDF и 1С
регламенты и инструкции в одном индексе
владелец
у каждой статьи и срок следующей проверки
Задачи

Почему базой знаний никто не пользуется

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

Знания живут в переписке и в головах

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

Поиск не находит нужную статью

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

Статьи устаревают незаметно

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

PDF и регламенты не индексируются

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

У статьи нет владельца

У документа нет ответственного, даты проверки и истории изменений. На вопрос, почему здесь написано иначе, в команде нет ответа, и правки вносятся бессистемно.

Ошибки в ответах не разбираются

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

Решения

Как устроена работающая база знаний

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

Подготовка источников и чанкинг

Превращаем разрозненные документы и историю обращений в структурированный набор фрагментов с метаданными.

  • Разбор тикетов, PDF, DOCX, Confluence и инструкций из 1С, включая сканы через OCR
  • Фрагменты по 300–800 токенов с перекрытием, чтобы ответ не разрезался посередине
  • Метаданные для фильтрации: продукт, версия, регион, дата актуальности, язык
  • Удаление дублей и слияние почти одинаковых статей из разных источников

Гибридный поиск и реранкинг

Лексический поиск ловит точные термины и артикулы, векторный — смысл формулировки, реранкер расставляет результаты по релевантности.

  • BM25 и векторные эмбеддинги работают параллельно, результаты объединяются
  • Фильтры по метаданным и правам: сотрудник не получит статью чужого подразделения
  • Реранкинг пятидесяти кандидатов до пяти фрагментов, которые уходят в контекст
  • Порог уверенности, ниже которого система честно сообщает, что ответа нет

Жизненный цикл статей

Документация остаётся актуальной, только если у неё есть владелец, срок проверки и понятный процесс правки.

  • Владелец, рецензент и срок следующей проверки у каждой статьи
  • Версии и статусы: черновик, на проверке, опубликовано, устарело
  • Шаблоны статей под тип обращения: симптом, причина, решение, эскалация
  • Отчёт по статьям с истёкшим сроком проверки и по темам без документа

Оценка качества и контроль галлюцинаций

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

  • Контрольный набор из 150–300 реальных вопросов клиентов с эталонными ответами
  • Метрики recall@k и точность попадания статьи в топ выдачи
  • Разбор вопросов без ответа и причин промаха: нет статьи, плохой чанкинг, слабый поиск
  • Регрессионные прогоны при каждой переиндексации и обновлении модели
Процесс

Этапы построения базы знаний

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

  1. 01 1–2 недели

    Инвентаризация знаний

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

  2. 02 2–3 недели

    Пайплайн обработки и индекс

    Настраиваем извлечение текста, OCR для сканов, разбиение на фрагменты и расчёт эмбеддингов. Собираем индекс с метаданными и проверяем его на случайной выборке документов.

  3. 03 1–2 недели

    Поиск, реранкинг и пороги

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

  4. 04 2–3 недели

    Регламент обновления и метрики

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

Размер фрагмента важнее выбора модели эмбеддингов

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

Мы разбиваем документы так, чтобы фрагмент оставался смысловой единицей: один шаг процедуры, одно условие тарифа, одно описание ошибки. Диапазон 300–800 токенов и перекрытие в 10–15% дают устойчивый результат: поиск находит нужное место, а контекст не раздувается настолько, чтобы ответ стал дорогим и медленным.

Как измерять качество базы знаний

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

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

Что делать с устаревшими инструкциями

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

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

Частые вопросы

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

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

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

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

AI для клиентского сервиса: другие направления

Смежные задачи, которые обычно решаются в одном проекте с этой.

Проверим, найдёт ли поиск ответы в ваших документах

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