ИИ-ассистент на основе базы знаний компании: от подготовки данных до запуска

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

Что умеет ИИ-ассистент на основе базы знаний компании

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

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

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

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

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

Отличия от чат-бота, поиска по документам и ИИ-агента

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

1. Сценарный чат-бот работает по заранее прописанному дереву. Он отвечает ровно на те вопросы, которые заложил проектировщик, и в любой нестандартной ситуации передаёт диалог человеку. Дёшево на старте, дорого в поддержке, потому что каждое изменение в продукте требует правки сценариев.
2. Поиск по документам возвращает список файлов и фрагментов, релевантных запросу. Он ничего не формулирует, решение остаётся за человеком. Хорошо работает, когда пользователь точно знает, что ищет.
3. ИИ-ассистент на базе знаний формирует ответ по найденным фрагментам, учитывает контекст диалога и ссылается на источники. Он отвечает на вопросы, которых никто заранее не предусмотрел, но остаётся в рамках того, что есть в базе.
4. ИИ-агент дополнительно совершает действия во внешних системах. Создаёт заявку, меняет статус задачи, инициирует согласование. Это следующий уровень автономности и следующий уровень риска, потому что ошибка агента приводит не к неверной фразе, а к неверной записи в системе учёта.

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

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

Где такой ассистент не поможет

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

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

Как формируется ответ и что такое RAG

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

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

Нарезка документов, эмбеддинги и векторная база

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

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

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

На практике одного векторного поиска редко достаточно. Рабочая конфигурация обычно совмещает несколько механизмов.

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

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

Путь запроса от вопроса до ответа со ссылкой на источник

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

1. Система принимает вопрос и определяет, кто его задал, в какой роли и с какими правами доступа.
2. Вопрос приводится к рабочему виду. Длинный запрос разбивается на части, местоимения раскрываются по истории диалога, добавляются синонимы и расшифровки внутренних сокращений.
3. Выполняется поиск по базе с учётом прав и фильтров. На выходе получается набор фрагментов-кандидатов.
4. Кандидаты переранжируются, отбираются наиболее релевантные, лишние отбрасываются.
5. Отобранные фрагменты вместе с инструкцией передаются языковой модели. Инструкция задаёт правила поведения, в том числе требование отвечать только по переданным данным и признавать отсутствие информации.
6. Модель формирует ответ, система прикрепляет ссылки на документы и фрагменты, из которых он собран.
7. Ответ, запрос, набор источников и оценка пользователя сохраняются в журнал для последующего разбора.

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

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

Пример работы ассистента по регламенту

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

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

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

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

Источники данных для базы знаний

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

• Утверждённые документы. Регламенты, политики, приказы, инструкции, должностные обязанности. Самый надёжный материал, если у каждого документа есть владелец и дата актуализации.
• Корпоративная вики и внутренний портал. Обычно содержат самое практичное знание и одновременно самое запутанное, потому что правки вносили десятки людей без единой структуры.
• Публичные материалы. Сайт, справочный центр, описания продуктов, ответы на частые вопросы. Удобны тем, что уже написаны понятным языком и прошли согласование.
• История обращений. Закрытые заявки поддержки, переписка с клиентами, записи звонков в текстовом виде. Богатый источник формулировок реальных вопросов, но требует фильтрации, потому что содержит и неверные ответы операторов.
• Учётные и операционные системы. Остатки, статусы заказов, данные о клиенте, параметры договора. Подключаются не загрузкой, а запросом в момент обращения, иначе ассистент будет отвечать по устаревшим цифрам.
• Обучающие материалы. Презентации, записи вебинаров, методички для новых сотрудников. Хорошо работают для онбординга, слабо — для точных справок, потому что часто содержат упрощения.

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

Что лучше не загружать на старте

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

• Черновики, версии с правками и документы без отметки об утверждении. Система не отличит проект от действующей редакции.
• Архивы отменённых регламентов, если в метаданных не проставлен статус. Отменённый пункт по смысловой близости выигрывает у действующего так же часто, как проигрывает.
• Личные папки сотрудников и неструктурированные свалки файлов. Там почти наверняка лежат данные, доступ к которым не определён.
• Переписка, содержащая персональные данные клиентов, если не настроена предварительная очистка. Это вопрос не удобства, а соблюдения требований законодательства.
• Документы на нескольких языках в одной коллекции без разметки языка. Поиск начинает смешивать версии и давать несогласованные ответы.

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

Как подготовить документы, чтобы ассистент не галлюцинировал

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

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

Актуальность и одна действующая версия

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

Решение лежит не в настройке модели, а в дисциплине хранения.

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

Система с опорой на базу знаний не улучшает документы. Она делает их качество видимым для всей компании сразу.

Конкретика вместо общих формулировок

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

Переписывать нужно не всё, а те места, по которым приходят вопросы. Ориентир простой. Если формулировка не содержит числа, роли, условия или последовательности действий, она не даёт ответа. Сравните два варианта описания одного процесса.

Исходная формулировка	Пригодная для ассистента
Отсрочка платежа может быть предоставлена надёжным клиентам по согласованию с руководством	Отсрочка до 30 календарных дней согласуется руководителем отдела продаж при сумме сделки до 2 млн рублей. От 30 до 60 дней требует согласования финансового директора и обеспечения в виде банковской гарантии
Возврат оборудования осуществляется в установленном порядке	Возврат оформляется заявкой в системе учёта с приложением акта осмотра. Срок рассмотрения 3 рабочих дня. При выявлении механических повреждений заявка передаётся в сервисный отдел
Новый сотрудник проходит необходимое обучение	В первую неделю сотрудник проходит вводный курс по безопасности и курс по продуктовой линейке. Доступ к рабочим системам открывается после отметки о прохождении в системе обучения

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

Структура, заголовки и короткие смысловые блоки

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

• Один раздел отвечает на один вопрос. Если в разделе описаны и порядок согласования, и условия оплаты, и ответственность, его стоит разделить.
• Заголовок формулируется так, как спросил бы человек. Порядок согласования скидок работает лучше, чем Раздел 4.2 Особые условия.
• Абзац не превышает пяти-шести строк. Длинные монолитные блоки плохо режутся и тянут в контекст лишнее.
• Условия и исключения пишутся рядом с правилом, а не в примечании на другой странице. Иначе фрагмент с правилом найдётся, а фрагмент с исключением нет.
• В начало каждого фрагмента при индексации автоматически добавляется название документа и путь по заголовкам. Это дешёвый приём, который заметно поднимает точность.

Контекст и перекрёстные связи

Знание в компании распределено между документами, и человек достраивает связи по памяти. Ассистент так не умеет. Если матрица полномочий лежит в одном файле, а коммерческая политика в другом, и между ними нет явной ссылки, система ответит по одному источнику и пропустит ограничение из второго.

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

Таблицы, изображения и сложные форматы

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

• Таблицы приводятся к простому виду без объединённых ячеек и вложенных заголовков. Каждая строка должна читаться самостоятельно.
• Крупные таблицы с тарифами или параметрами лучше подключать как структурированные данные, а не как текст. Числа и условия точнее извлекать запросом, чем поиском по смыслу.
• К каждой схеме добавляется текстовое описание процесса словами. Это занимает двадцать минут и делает материал пригодным одновременно для ассистента и для незрячих сотрудников.
• Сканы проходят распознавание с выборочной проверкой. Ошибка распознавания в номере пункта или в сумме дороже, чем кажется.
• Презентации редко подходят как есть. Содержательную часть переносят в текстовый документ, потому что смысл слайда часто жил в словах докладчика.

Единая терминология и метки доступа

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

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

Сценарии применения по отделам

Ценность ассистента неравномерна по компании. Есть подразделения, где эффект виден за три недели, и есть те, где внедрение разумно отложить. Разница определяется двумя факторами. Насколько вопросы повторяются и насколько ответы уже зафиксированы письменно.

Поддержка и колл-центр

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

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

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

Кадровая служба, онбординг и внутренние политики

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

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

Ассистент, не знающий, кто именно задал вопрос, в кадровой тематике приносит столько же путаницы, сколько пользы.

Поддержка информационных систем

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

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

Продажи

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

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

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

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

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

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

Безопасность и права доступа

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

Ролевая модель и фильтрация ответов

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

1. Каждый фрагмент при индексации получает метки доступа, унаследованные от документа и его расположения.
2. Система аутентифицирует пользователя и получает его роли из корпоративного каталога, а не хранит их отдельно.
3. Поисковый запрос выполняется с жёстким фильтром по пересечению прав пользователя и меток фрагмента.
4. Модель получает только разрешённые фрагменты. Ответ собирается исключительно из них.
5. Ссылки на источники показываются с проверкой права на открытие документа, чтобы не раскрывать даже названия закрытых файлов.

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

Размещение и закрытый контур

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

Вариант размещения	Когда подходит	Что учитывать
Внешний сервис российского поставщика	Публичные и малочувствительные материалы, быстрый пилот, небольшая команда	Нужен договор с условиями обработки данных, фиксация места хранения, запрет использования запросов для обучения
Гибридная схема	Основная часть данных чувствительна, но нужна сильная модель для формулировок	Поиск и хранение внутри контура, во внешнюю модель уходят только обезличенные фрагменты. Требуется контроль того, что уходит
Полностью в своей инфраструктуре	Персональные данные, коммерческая тайна, требования отраслевого регулирования	Нужны вычислительные мощности, компетенции по сопровождению, готовность к более скромному качеству формулировок открытых моделей

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

Журналирование и контроль утечек

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

• Текст запроса, время, пользователь и его роли на момент обращения.
• Перечень фрагментов, попавших в контекст, с идентификаторами документов.
• Итоговый ответ и показанные источники.
• Оценка пользователя и его комментарий, если он был оставлен.
• Факты отказа системы отвечать и причины, по которым ответ не был найден.

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

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

Внедрение: пошаговый план

Проект такого рода проваливается не из-за технологий, а из-за порядка действий. Типичная неудачная траектория выглядит так. Сначала выбирается платформа, затем в неё заливаются документы, потом выясняется, что документы противоречат друг другу, и проект замирает на стадии доработки базы без сроков и владельца. Рабочая последовательность обратная. Данные, тестирование, ограниченный запуск, расширение.

Шаг 1. Аудит источников и очистка данных

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

1. Соберите список повторяющихся вопросов и сгруппируйте их по темам. Обычно десять тем закрывают около семидесяти процентов потока.
2. Для каждой темы найдите документ, который содержит ответ. Отметьте случаи, где документа нет, где он устарел и где источников несколько с расхождениями.
3. Назначьте владельца по каждой теме. Это человек, который отвечает за содержание, а не за техническую загрузку.
4. Разберите расхождения между источниками. Этот шаг нельзя делегировать подрядчику, решение о правильной версии принимает компания.
5. Приведите отобранные документы в пригодный вид по требованиям из предыдущего раздела. Структура, конкретика, метаданные, метки доступа.
6. Зафиксируйте, что осталось за рамками первой версии. Открытый перечень исключений лучше, чем молчаливые пробелы.

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

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

Шаг 2. Настройка поискового конвейера и тестирование на реальных вопросах

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

Набор обязательно включает неудобные случаи, иначе он даст ложно хорошую картину.

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

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

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

Шаг 3. Пилот на одном подразделении

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

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

1. Определите группу от десяти до тридцати человек и зафиксируйте базовые показатели до запуска. Без замера до старта оценить эффект будет невозможно.
2. Встройте доступ туда, где люди уже работают. Отдельное окно, которое нужно специально открывать, снижает использование в разы по сравнению с интеграцией в рабочий интерфейс или корпоративный мессенджер.
3. Проведите короткое обучение. Достаточно получаса с объяснением, как формулировать вопрос, что означают ссылки на источники и в каких ситуациях ответу нельзя доверять без проверки.
4. Сделайте оценку ответов обязательной и лёгкой. Две кнопки и необязательный комментарий. Без потока оценок улучшать систему не на чем.
5. Раз в неделю разбирайте журнал неудачных обращений вместе с владельцами тем. Половина правок окажется правками документов, а не настроек.
6. Через четыре-шесть недель сравните показатели с базовыми и решите судьбу проекта на фактах.

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

Шаг 4. Расширение и работа с обратной связью

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

Параллельно выстраивается постоянный процесс сопровождения. Он не требует большой команды, но требует регулярности.

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

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

Что нужно для старта

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

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

По роли на стороне компании минимальный состав выглядит так.

Роль	Что делает	Загрузка на пилоте
Заказчик от бизнеса	Определяет цель, принимает решения по спорным формулировкам, отвечает за результат	Два-четыре часа в неделю
Владелец базы знаний	Отвечает за содержание и актуальность документов, координирует правки	Половина ставки на период подготовки
Эксперты по темам	Формулируют эталонные ответы, проверяют корректность выдачи	Четыре-шесть часов на тему
Специалист по информационным системам	Обеспечивает доступы, интеграции, размещение в контуре	Полторы-две недели суммарно
Служба безопасности	Согласует модель доступа, требования к хранению и журналированию	Согласование на старте и приёмка

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

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

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

Как измерить эффект

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

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

1. Время на поиск информации. Замеряется выборочным наблюдением или опросом до запуска и после. Для операторов поддержки точнее брать среднее время обработки обращения из системы учёта.
2. Доля вопросов, закрытых без привлечения другого человека. Считается по журналу ассистента в сопоставлении с динамикой внутренних обращений к экспертам и эскалаций.
3. Точность ответов и доля ответов с корректными источниками. Измеряется прогоном тестового набора и выборочной проверкой реальных диалогов экспертом. Именно вторая часть показателя важна для доверия, потому что правильный ответ без верной ссылки проверить нельзя.
4. Срок выхода нового сотрудника на рабочий режим. Берётся по формальным отметкам о допуске и по показателям качества работы в первые два месяца.

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

Показатель	Ориентир для пилота	Как считать
Полезные ответы	От 70 до 80 процентов	Оценки пользователей с выборочной перепроверкой экспертом
Корректная ссылка на источник	Не ниже 90 процентов от числа ответов по существу	Ручная проверка на выборке из 100 диалогов
Ответы без опоры на базу	Близко к нулю	Разбор случаев, где источники не показаны или не подтверждают текст
Регулярное использование	Половина целевой группы и выше	Доля сотрудников с обращениями не реже раза в два дня
Время обработки обращения	Снижение на 10 процентов и более	Сравнение с базовым периодом по системе учёта

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

Показатель, который не замерен до запуска, после запуска превращается в предмет спора, а не в аргумент.

Типичные ошибки при запуске

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

Загрузка всего массива без подготовки

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

Права доступа как задача второй очереди

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

Отсутствие владельца и регламента обновления

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

Минимальный регламент, который снимает риск, состоит из нескольких правил.

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

Запуск сразу на всю компанию

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

Оценка на глаз

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

Попытка заменить людей вместо усиления

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

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

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

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

Что делать, если ассистент выдумывает ответы

Начните с журнала и посмотрите, какие фрагменты попали в контекст. Почти всегда выясняется, что нужного фрагмента там не было, а модель собрала ответ из нерелевантного материала. Лечится это на стороне поиска и данных. Отдельно проверьте, задано ли в инструкции требование отвечать только по переданному контексту и прямо сообщать об отсутствии информации, и установлен ли порог, ниже которого система отказывается отвечать.

Сколько документов нужно, чтобы система была полезна

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

Можно ли подключить данные из учётных систем

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

Как быть с документами, которые противоречат друг другу

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

Заменит ли ассистент первую линию поддержки

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

Как понять, что проект пора останавливать

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

Такая система не создаёт знания и не наводит порядок за компанию. Она превращает порядок, который уже есть, в мгновенный доступ к ответу, и ровно в этом её ценность.