ИИ-ассистент по базе знаний компании
Сотрудник задаёт вопрос обычным языком и получает ответ с указанием нужного документа. Начинаем с одного раздела знаний: инструкции, описание услуг или внутренние регламенты.
- Инструкции
- Справочники
- Регламенты
- Ответ
- Источник
- Уточнение
«Как согласовать отпуск и где взять форму заявления?»
Ответ из базы знаний
- Порядок
- Заявление → согласование
- Источник
- Правила команды · § 4
- Нет данных
- Передать вопрос сотруднику
Поиск только в разрешённых источниках
Когда компании нужен поиск по своим документам
Менеджер знает, что ответ на вопрос клиента уже есть в инструкции, но не помнит, где именно. В общем диске лежат несколько версий, в переписке обсуждалось исключение, а коллега, который всё это помнит, занят. В итоге сотрудник либо тратит время на поиск, либо отвечает по памяти. Ассистент по базе знаний полезен, когда такая ситуация повторяется и у компании уже есть материалы, на которые можно опереться.
Выбрать раздел знаний
Начать можно с правил работы с заказами, справочника продуктов, инструкций для новых сотрудников или внутренних процедур. У каждого раздела должен быть человек, отвечающий за содержание. Если условия существуют только в голове руководителя, сначала потребуется записать и согласовать их. Модель не сможет восстановить незафиксированную договорённость: убедительный ответ в таком случае будет особенно опасен.
Сделать ответ проверяемым
Задача первого запуска — дать сотруднику быстрый путь к проверяемому ответу. Рядом с объяснением он должен видеть источник и иметь возможность открыть нужный фрагмент. Это помогает проверить формулировку перед разговором с клиентом и заметить устаревший документ. Подключение всех файлов компании одновременно обычно затрудняет такую проверку: непонятно, из какого раздела пришла ошибка и кто должен её исправить.
Как выглядит вопрос и полезный ответ
Возьмём условный пример: сотрудник спрашивает, какие материалы нужны для начала работы над упаковкой. В согласованной инструкции перечислены размеры, развёртка, технические требования типографии и окончательные тексты. Помощник находит эту инструкцию, собирает короткий список и показывает ссылку. Если для отдельного вида упаковки есть дополнительные требования, он должен указать, для какого случая они действуют.
Если правила нет
Вопрос «можно ли начать без развёртки?» требует другого ответа. Если в документах нет утверждённого исключения, помощнику следует сообщить об отсутствии правила и направить сотрудника к ответственному. Подменять неизвестное удобным предположением нельзя. На приёмке мы отдельно проверяем такие вопросы: пользователь может сформулировать их так, будто разрешение уже существует.
Какие вопросы взять в пилот
Это пример устройства базы, а не история выполненного клиентского проекта. Конкретный набор вопросов берём из вашей работы. Хорошая начальная подборка содержит обычные формулировки сотрудников, сокращения, названия продуктов и несколько спорных ситуаций. По ней легче понять, помогает ли система разобраться в документах или лишь пересказывает первый найденный абзац.
Что означает RAG и почему одной загрузки файлов мало
- Поиск по источникам
- RAG — подход, при котором система сначала ищет сведения в подключённых источниках, а затем использует найденное при подготовке ответа. Так можно работать с внутренними материалами без предположения, что модель уже знает правила вашей компании. При этом наличие поиска само по себе не гарантирует верного результата: можно найти не тот раздел, пропустить оговорку или соединить несовместимые версии.
- Проверка результата
- Поэтому работу разделяем на проверку поиска и проверку ответа. Сначала смотрим, находит ли система нужный документ по реальному вопросу. Затем проверяем, правильно ли передаёт его смысл. Если поиск не нашёл правило, переписывание инструкции для модели может ничего не изменить. Если источник найден, но ответ потерял важное условие, исправлять нужно уже этап подготовки ответа.
- Связанные сведения
- Отдельная задача — связанные сведения. Таблица может содержать сроки, а примечание под ней объяснять исключения. При подготовке источника важно сохранить эту связь. Скан, в котором плохо распознаются цифры, требует проверки до подключения. В смете учитываются состояние и структура материалов: одинаковое количество файлов может означать совершенно разный объём подготовки.
Подготовка документов и обновление знаний
Собрать актуальные источники
В начале составляем перечень источников: где они находятся, кто их обновляет и какие сведения нужны выбранной группе сотрудников. Убираем устаревшие копии из рабочего набора, отмечаем противоречия и определяем основную версию. Если два отдела используют разные условия, требуется явное правило выбора, например по продукту или типу договора. Техническая настройка не заменяет это решение владельца процесса.
Указать дату и владельца
Для каждого важного документа полезно знать дату действия и ответственного. Удаление файла, изменение цены и новая редакция инструкции должны учитываться при обновлении базы. Проверяем не только появление нового материала, но и прекращение использования старого. Иначе сотрудник продолжит получать отменённое правило, хотя в общем диске его уже заменили.
Согласовать обновление
Порядок обновления фиксируем в передаче системы: кто публикует изменения, когда они становятся доступны и как проверить результат. Для первого запуска можно выбрать небольшой управляемый раздел. В дальнейшем новые материалы подключаются после проверки формата, владельца и доступа. Такой порядок позволяет расширять базу без накопления противоречий, которые трудно обнаружить по одному внешне правильному ответу.
Доступ: кто вправе увидеть конкретный ответ
Разделить права пользователей
До подключения документов определяем группы пользователей. Общая инструкция отдела и индивидуальные условия клиента могут требовать разных разрешений. Ограничение должно применяться к источникам, из которых готовится ответ, а не только к видимости ссылки в интерфейсе. Скрытая ссылка не поможет, если закрытый текст уже попал в объяснение.
Проверить ограничения хранилища
Способ реализации зависит от хранилища, подключения и системы входа. Проверяем, можно ли сохранить существующие права или потребуется отдельный набор материалов для каждой группы. Нельзя заранее считать, что любое подключение к общему диску автоматически перенесёт все ограничения. На тесте один и тот же вопрос задают пользователи с разными правами, включая человека, которому доступ недавно закрыли.
Определить состав журнала
Также обсуждаем историю запросов: кто её видит, что записывается для разбора ошибок и какие сведения вообще не нужны в журнале. Для демонстрации используем согласованные примеры. Реальные пароли, ключи и лишние персональные данные не должны попадать в пробный набор ради удобства настройки. Правила хранения и доступ администратора входят в описание выбранного решения.
Как принимаем первый запуск
До разработки согласуем вопросы и ожидаемые источники. В набор входят точный вопрос, разговорная формулировка, неполные условия, отсутствие ответа и конфликт версий. Для каждого случая заранее понятно, что считать успехом: правильный ответ со ссылкой, уточняющий вопрос или передача человеку. Отказ ответить может быть корректным результатом, если база не содержит нужных сведений.
Ошибки разделяем по причинам. Неверный источник требует проверки поиска; устаревшая инструкция — работы с содержанием; искажённая формулировка — проверки подготовки ответа; закрытый фрагмент — исправления доступа. Общая оценка «ответил хорошо» скрывает эти различия. В журнале пилота полезно сохранять вопрос, найденный источник, замечание проверяющего и принятое исправление.
Сохранять набор проверочных вопросов
После исправлений повторяем проверку ранее проблемных вопросов. Одновременно следим, чтобы решение одной ошибки не испортило другие ответы. Передаём этот набор команде вместе с инструкцией: его можно использовать после обновления документов или изменения настроек. Расширение на новый отдел обсуждаем, когда понятны качество ответов и реальные затраты на поддержание первого раздела.
Стоимость, обязанности и дальнейшее расширение
Бюджет первого этапа
Ориентир базового ИИ-помощника в прайсе HeadPills — от 500 €. База знаний с несколькими хранилищами, ролями и сложными документами оценивается отдельно. На объём влияют подготовка источников, способ входа, разграничение доступа, качество распознавания материалов и нужный интерфейс. Количество документов само по себе недостаточно для расчёта.
Текущие расходы могут включать размещение, поиск, обращения к модели и обслуживание подключений. Отдельно учитывайте время сотрудника, который обновляет инструкции и разбирает замечания. После запуска у системы должен оставаться владелец. Если никто не отвечает за актуальность правил, даже хорошо настроенный помощник постепенно начинает работать с неверными исходными данными.
Для первой оценки пришлите названия хранилищ, выбранный раздел знаний, пример обезличенного документа и несколько типичных вопросов. Укажите, кто будет пользоваться системой и кто проверит ответы. По этим материалам можно определить состав пилота, условия доступа и проверку готовности. Если окажется, что достаточно привести в порядок навигацию по существующим инструкциям, это тоже полезный результат разбора.
Стоимость и первый этап
Стоимость — после оценки источников и доступа
Ориентир базового помощника — от 500 €. База знаний с несколькими хранилищами и ролями требует отдельной сметы.
Вопросы
Перед началом работы
Нужно обучать свою нейросеть?
Часто достаточно поиска по подготовленным документам и подходящей модели. Необходимость другого подхода определяем по задаче.
Можно загрузить все документы сразу?
Сначала лучше выбрать один актуальный раздел и проверить доступы и качество ответов.
Будут ли ответы всегда верными?
Нет. Предусматриваем источники, тестовые вопросы и передачу неизвестного или спорного вопроса человеку.
Можно подключить существующее хранилище?
После проверки возможностей выбранного хранилища и модели доступа. Поддержка конкретного сервиса фиксируется в предложении.
Расскажите, какую информацию команда постоянно ищет
В ответ обсудим состав первого этапа, нужные подключения и критерии готовности.