AI-ассистент по базе знаний компании: как запустить и проверить качество ответов

AI-ассистент по базе знаний это система, которая отвечает на вопросы сотрудников словами ваших внутренних документов и показывает, из какого документа взят ответ. Знания не «зашиты в модель»: на каждый вопрос система находит подходящие фрагменты в ваших регламентах, инструкциях и договорах и формулирует ответ только по ним. Ценность здесь не в самом факте генерации текста, а в дисциплине: насколько точно ассистент держится источника и насколько честно отказывается отвечать, когда данных нет.

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

Соседний сценарий: AI-ассистент менеджера поддержки: ответы клиентам ->

Когда нужен ассистент, а когда достаточно обычного поиска?

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

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

Чем это отличается от обычного ChatGPT?

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

Отличия, которые важны для эксплуатации:

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

Как ассистент приходит к ответу?

Путь вопроса состоит из пяти шагов, и на каждом можно потерять качество.

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

Какие документы можно подключить?

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

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

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

Почему сначала нужно навести порядок в документах?

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

Минимальная гигиена перед стартом:

• у каждого документа есть владелец и дата последнего пересмотра;
• отменённые и архивные версии физически отделены от действующих;
• дубли удалены, а не переименованы;
• в названии файла видно, что это за документ, а не «Регламент_финал_2_испр».

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

Как устроить права доступа?

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

Рабочая схема:

• Роли, а не персональные списки. Уровни доступа привязываются к ролям (сотрудник, руководитель подразделения, HR, финансы) и берутся из текущего каталога пользователей компании.
• Фильтр на уровне индекса. Фрагменты, недоступные пользователю, не должны попадать в контекст ответа в принципе.
• Разделение по разделам базы. Кадровые и финансовые документы в отдельных пространствах с собственными правилами.
• Журналирование. Кто, что спросил, какие источники получил. Нужно и для разбора инцидентов, и для оценки качества.
• Контур обработки. Отдельно фиксируется, куда уходят фрагменты документов при генерации ответа и сколько они хранятся.

Подробнее о безопасности и контуре обработки данных ->

Что делать, если ответа в документах нет?

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

Как это устроено на практике:

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

Такой отчёт часто оказывается полезнее самого ассистента в первые месяцы: он показывает, каких документов в компании физически нет.

Как подготовить набор контрольных вопросов?

Контрольный набор это основной инструмент приёмки. Без него спор о качестве превращается в обмен впечатлениями.

Как его собрать:

• Источник вопросов это сотрудники, а не разработчики. Берите реальные обращения из чатов, тикетов, вопросов новичков за последние месяцы.
• Объём: 50-100 вопросов для первого запуска. Меньше не даёт статистики, больше тяжело поддерживать вручную.
• К каждому вопросу заранее пишется эталонный ответ и эталонный источник (документ и раздел). Это делает эксперт по теме, а не команда разработки.

Набор должен покрывать разные типы:

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

Как оценивать качество ответов?

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

Правильность ответа по существу

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

Соответствие источнику

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

Корректность ссылки

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

Умение отказаться

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

Передача вопроса человеку

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

Скорость и стоимость одного запроса

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

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

Облако или свой контур: на что влияет выбор?

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

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

Зачем начинать с пилота на 20-50 документах?

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

Как выбрать раздел для пилота:

• высокая частота вопросов (видно по чатам и тикетам);
• документы в приемлемом состоянии, с понятными владельцами;
• есть эксперт, готовый проверять ответы;
• ошибка не критична для клиента или бухгалтерии.

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

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

Как устроены этапы работ и запуск в эксплуатацию ->

Из чего складывается стоимость?

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

• Объём и состояние базы. Тысяча аккуратных страниц дешевле трёхсот разнородных сканов.
• Форматы источников. Сканы, сложные таблицы и презентации требуют отдельной обработки и проверки.
• Количество систем-источников. Каждая интеграция это отдельная работа: доступы, синхронизация, обработка обновлений.
• Модель прав доступа. Один общий раздел для всех и матрица прав по ролям это разные по трудоёмкости задачи.
• Облако или свой контур. Локальное размещение добавляет инфраструктуру и администрирование.
• Требования к качеству. Высокий порог по соответствию источнику и по отказам требует больше итераций настройки поиска.
• Объём запросов. Влияет на операционные расходы, а не на разработку.
• Языки. Многоязычная база и ответы на нескольких языках усложняют поиск и проверку.
• Сопровождение. Переиндексация, контроль качества на новых документах, развитие контрольного набора.

Как мы считаем стоимость AI-проектов ->

Когда AI-ассистента делать не нужно?

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

Ассистент не решит задачу

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

Ассистент нужен, но начинать надо не с него

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

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

Как понять, что компания готова: чек-лист

Отметьте пункты, которые уже выполнены.

С чего начать

Мы разрабатываем такие модули под процессы компании: подключение источников, поиск с учётом прав доступа, контроль отказов и приёмка по контрольному набору вопросов. Дальше многое зависит от того, как вы прошли чек-лист.

Если первые две группы закрыты. Берём раздел с самой высокой частотой вопросов, собираем контрольный набор, запускаем пилот на 20-50 документах и фиксируем критерии приёмки до старта. По итогам видно и качество ответов, и реальную стоимость запроса, и объём работ по остальной базе.

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

В обоих случаях начинается с одного и того же разговора: что за вопросы, сколько их и кто на них отвечает сегодня.

Обсудить задачу или посмотреть сценарии AI-модулей для бизнеса.

---

FAQ

Нужно ли дообучать модель на наших документах?

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

Как быстро ответы обновляются после правки регламента?

После переиндексации изменённого документа. Обычно это настраивается автоматически: система отслеживает изменения в источнике и обновляет индекс без участия человека.

Что делать, если ассистент дал неверный ответ?

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

Можно ли обойтись без передачи данных во внешние сервисы?

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

Сколько документов нужно для старта?

Для пилота достаточно 20-50 документов одного раздела с высокой частотой вопросов. Этого хватает, чтобы оценить качество ответов и понять объём работ по остальной базе.

Кто должен проверять качество ответов: разработчики или заказчик?

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

Заменит ли ассистент службу поддержки или наставника для новичков?

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