Почему AI-чат-бот в Teams не находит ответы в документах
Бот в Teams установлен, отвечает быстро и уверенно — но на вопрос про регламент отпусков выдаёт общие рассуждения. Причина почти никогда не в модели: поиск по внутренним документам либо не подключён к реальным источникам, либо собран из одного сетевого диска, тогда как знания лежат в wiki, тикетнице и почте. Модель без релевантного контекста не признаётся, что не знает, и достраивает правдоподобный ответ.
Второй слой — права доступа. Бот, который ходит в хранилища от служебной учётной записи, видит либо всё, либо ничего: в первом случае сотрудник получает фрагмент закрытого договора, во втором — «в документах нет информации». Рабочий вариант — запрос от имени пользователя с наследованием прав групп на уровне фрагментов, а не целых файлов: иначе общий документ с одной закрытой главой выпадает из выдачи целиком.
Третий слой — качество выдачи. Нарезка текста фиксированными блоками рвёт таблицы и заголовки, поэтому векторный поиск возвращает «похожее по теме», а не отвечающее на вопрос. Гибридная схема — точные термины и аббревиатуры вместе с векторами — и переранжирование кандидатов поднимают нужный фрагмент в начало контекста. Без ссылки на источник ответ бесполезен: инженер не проверит, из какой редакции документа взята цифра.
Отдельно — свежесть индекса: без переиндексации бот месяцами цитирует отменённый приказ. Корпоративный поиск не находит ответы чаще всего не из-за модели, а из-за разрыва между индексом, правами и выдачей — разбираем, как связать их в один контур.
Что меняется после внедрения: скорость и точность ответов
До внедрения сотрудник ищет ответ на рабочий вопрос в среднем 8–12 минут: обходит файловое хранилище, пролистывает переписку, спрашивает в общем канале. Часть этих вопросов повторно уходит в поддержку — на типовые темы приходится заметная доля обращений, и первая линия отвечает на одно и то же разными словами.
Ассистент живёт в Microsoft Teams, поэтому поиск идёт в том же окне, где человек и так работает: не нужно переключать контекст и заново формулировать вопрос. Ответ собирается не «по памяти» модели, а из фрагментов ваших документов: поисковый индекс пересобирается по расписанию, каждый ответ содержит ссылку на исходный файл и раздел, где лежит подтверждение.
Отсюда два измеримых эффекта. Время до первого ответа сокращается до 20–40 секунд с учётом времени на формулировку. Точность перестаёт быть вопросом веры: мы считаем долю ответов с подтверждающим источником и долю случаев, когда ассистент честно передаёт вопрос человеку вместо догадки. Метрики снимаем на подготовленном наборе контрольных вопросов и на реальном потоке обращений, чтобы рост не оказался эффектом новизны.
Разгрузка службы поддержки — следствие, а не лозунг. Повторные обращения по темам, которые закрывает база знаний, уходят из очереди первой линии, и служба занимается нестандартными случаями, где нужен разбор. На замерах после запуска доля таких обращений снижается на 40–60%, а скорость ответа поддержки растёт за счёт того, что очередь перестаёт состоять из однотипных вопросов.
Варианты поиска по внутренним данным: сравнение подходов
Схема поиска задаёт, что бот вернёт на вопрос сотрудника в Teams, и выбирать её стоит до разработки, а не после первых жалоб на качество ответов. Поиск по ключевым словам точен на реквизитах и названиях, но ломается на перефразировке; векторный поиск по документам понимает смысл вопроса, зато проскакивает артикулы и номера договоров.
Гибридный поиск в сравнении с одиночными схемами обычно выигрывает: он объединяет оба сигнала и добавляет поиск с опорой на источники, когда ответ обязан сопровождаться ссылкой на фрагмент. Ниже — четыре реальных варианта с их границами применимости.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Поиск по ключевым словам | База со стабильной терминологией, поиск по номерам и названиям | Не находит синонимы и перефразировку; качество держится на ручных правилах |
| Векторный поиск по документам | Разнородные тексты, вопросы формулируют своими словами | Теряет точные реквизиты и редкие сокращения; нужна переиндексация при обновлении базы |
| Ответы с опорой на источники | Нужна проверяемая ссылка на фрагмент, а не готовый вывод | Требует размеченного корпуса и учёта прав доступа, иначе отвечает уверенно, но мимо |
| Гибридная схема | Смешанные запросы: смысл плюс точные идентификаторы | Сложнее настройка ранжирования; без регулярной оценки качества растёт доля нерелевантных фрагментов |
Готовые коннекторы ограничения имеют свои: они забирают документы из источника как есть, без разметки прав на уровне фрагмента, поэтому доступы приходится донастраивать. Отдельно проверяем поведение схемы на обновлении базы — от этого зависит, за какой срок новый документ становится находимым.
Этапы работ: от аудита источников до передачи контура
Работа идёт итерациями: результат каждого этапа — артефакт, на который опирается следующий. Ниже — последовательность внедрения корпоративного поиска, от инвентаризации знаний до передачи контура вашей команде.
- Аудит источников знаний. Собираем перечень систем — файловые хранилища, вики, почтовые архивы, базы заявок — с объёмом и частотой обновления, отдельно отмечаем дубли и мёртвые разделы. Результат — карта источников с владельцами и приоритетом подключения.
- Схема поиска. Определяем, какие типы документов режем на фрагменты, как храним метаданные (отдел, дата, тип), как объединяем смысловой и точный поиск. От этого зависит, найдёт бот нужный пункт регламента или просто похожий абзац.
- Разграничение доступа. Права наследуются из систем-источников: в ответе сотрудник видит только то, что открыто ему напрямую. Проверяем на смешанных ролях — руководитель, внешний подрядчик, новичок.
- Схема развёртывания бота и настройка. Решаем, где живут сервис индексации и модель, как обновляется индекс и что происходит при недоступности источника. Сам бот встраивается в Microsoft Teams как обычное приложение.
- Проверка на контрольных вопросах. Несколько десятков вопросов с эталонными ответами: фиксируем долю корректных попаданий в источник и вопросы, где ответа нет. Ошибки разбираем по причинам — документа нет, устарел, потерян при разбиении.
- Приёмка поискового решения. Метрики согласованы заранее: точность попадания в источник, время ответа, отсутствие утечек закрытых данных. Отдельно проверяем честное «не знаю» вместо досочинённого ответа.
- Передача контура. Отдаём схему развёртывания, регламент обновления индекса, инструкции администраторам и план развития. Команда сопровождает контур сама, мы остаёмся на подхвате.
Что передаём на руки: конфигурации, схемы и регламенты
Пакет передачи — не папка с файлами «на посмотреть», а набор артефактов, по которым ваша команда сможет сопровождать решение без нас. Каждый документ привязан к узлу системы: что настроено, какие значения параметров выбраны и почему, что произойдёт при отклонении.
- Описания конфигураций — словарь индекса, модель эмбеддингов, размер фрагмента и перекрытие, сколько источников возвращается в ответ, порог релевантности. С обоснованием: почему выбраны такие значения и как их менять.
- Схема потоков данных — от источников (файловые хранилища, вики, почта) через разбор и индексацию до ответа в чате. С пометками, где данные шифруются и что удаляется после обработки.
- Политики доступа к данным — права бота привязаны к учётной записи сотрудника: в ответ не попадёт то, что закрыто в исходной системе. Матрица ролей и исключений прилагается.
- Документация по внедрению поиска — порядок подключения новых источников, требования к форматам, контрольный список проверок после добавления.
- Инструкция для сотрудников — как формулировать запрос, как оценивать ответ, куда сообщать об ошибке; короткая версия на одну страницу для рассылки.
- Регламент обновления базы знаний — частота полной и частичной переиндексации, владелец каждого источника, действия при рассинхроне.
- План отката и журнал изменений — какие версии артефактов совместимы и как вернуть индекс к предыдущему состоянию.
Приёмка идёт по контрольным вопросам: разворачивается ли система на вашем контуре, воспроизводится ли ответ при том же запросе, соблюдается ли разграничение прав. Что не проходит проверку — дорабатываем до передачи.
Кейс: поиск по базе знаний для сервисной службы
Что было до
Сервисная служба отвечала на внутренние вопросы сотрудников вручную: заявки шли через почту, общий чат и личные сообщения дежурным инженерам. База знаний существовала в двух местах и расходилась — инструкции по обслуживанию оборудования, регламенты эскалации и шаблоны ответов клиентам обновлялись без синхронизации. Сотрудник с вопросом «какой регламент сейчас действует» ждал ответа 25-40 минут, если попадал в очередь, и получал ссылку на устаревшую версию документа примерно в каждом пятом случае.
Что изменили
Мы собрали корпоративный чат-бот в Microsoft Teams и подключили его к базе знаний через поиск по смыслу: система находит релевантные фрагменты регламентов и формирует ответ с обязательной ссылкой на источник. Если уверенность поиска низкая, бот не додумывает, а сразу предлагает эскалацию на дежурного специалиста с уже приложенным контекстом вопроса.
Индекс пересобирается по событию изменения документа, а не по расписанию, поэтому вчерашнее обновление регламента сотрудник видит сегодня, а не через неделю. В выдаче остаются только действующие версии — черновики и архивные редакции в индекс не попадают.
Что стало
Доля вопросов, закрытых без участия специалиста, выросла с 34% до 71%: дежурные инженеры перестали быть первой линией и занимаются только реальными отклонениями. Время до первого корректного ответа сократилось с десятков минут ожидания в очереди до нескольких секунд. Отдельно ушёл класс ошибок «ответ по устаревшему регламенту» — каждое утверждение бота сопровождается ссылкой на актуальную редакцию, и спорный ответ можно проверить в один клик.
Что делать, если чат-бот уже развёрнут, но отвечает неточно?
Неточные ответы почти никогда не связаны с самой моделью — она отвечает ровно настолько, насколько полон, свеж и правильно нарезан поисковый индекс под ней. Диагностику ведём по четырём точкам: актуальность источников, разбиение документов на фрагменты, учёт прав доступа и проверка ответа по первоисточнику. Не закрыта хотя бы одна — и бот отвечает неточно даже на простых вопросах.
Чаще всего виноваты устаревшие источники: индекс собрали при внедрении, документы с тех пор правились, а переиндексация идёт раз в сутки или не идёт вовсе — бот уверенно цитирует отменённую редакцию регламента. Актуализация данных для поиска должна быть событийной: изменение документа запускает обновление его фрагментов в индексе за минуты, а не за сутки.
Вторая причина — отсутствие нарезки: документ на десятки страниц входит в индекс целиком, и его вектор усредняет сразу несколько тем, поэтому на вопрос о сроках согласования приходит ответ о порядке подписания. Разбиение документов на фрагменты по смысловым разделам, с перекрытием на границах и метаданными (версия, дата, подразделение), возвращает попадание в нужный абзац.
Права доступа фильтруем до поиска, а не после выдачи: иначе часть ответов собирается из закрытых документов либо, при грубом отсечении, бот говорит «не найдено» там, где ответ есть. И финальное — проверка ответа по первоисточнику: без ссылки на конкретный фрагмент ответ не показываем. Улучшение качества ответов замеряем на наборе эталонных вопросов: доля ответов с подтверждённым источником до и после правок.
Частые технические сомнения перед стартом работ
Сомнения перед стартом касаются не модели, а поведения поиска в корпоративном контуре: что он вернёт на конкретный вопрос, кому покажет найденный документ и что станет с базой через полгода.
Насколько точным будет поиск по нашим документам?
Точность определяет не модель, а подготовка корпуса: разбивка на фрагменты, перекрытие, метаданные, ранжирование. Ответ приходит со ссылкой на исходный фрагмент — ошибку видно сразу.
Как поиск учитывает права доступа?
К каждому фрагменту индекса пишутся метки доступа из источника. Запрос идёт от имени пользователя, поэтому сотрудник видит ровно тот набор, который разрешён ему в исходной системе.
Что делать с разнородными источниками?
Системы подключаются отдельными коннекторами: базы знаний, файловые хранилища, переписка, тикеты. Всё приводится к единой структуре, но ссылка на оригинал сохраняется — ответ можно сверить с первоисточником.
Где хранятся данные и индекс?
В вашем контуре: на своей инфраструктуре или в закрытом выделенном сегменте. Индекс, модель и журналы запросов не покидают периметр, наружу уходит только явно разрешённое.
Кто поддерживает базу знаний в актуальном состоянии?
Переиндексация идёт по расписанию и по событию — при изменении или удалении документа. Устаревшие фрагменты вычищаются, а отчёт о покрытии показывает источники, давно не обновлявшиеся.
Обсудим задачу: вернёмся с оценкой и планом работ
Чтобы вернуться с оценкой и планом работ, а не с уточняющими вопросами, полезно собрать несколько вводных. Формальный документ не нужен — достаточно понимания, где лежат знания, кому они нужны и какие ограничения есть по контуру. Именно эти ответы определяют архитектуру поискового чат-бота и состав этапов. Что чаще всего стоит подготовить к разговору:
- Перечень источников знаний, которые должны попадать в поиск: регламенты, проектная документация, база знаний, тикеты, файловые хранилища — и владелец каждого из них.
- Модель доступа: как сегодня разграничены права, чтобы ответ собирался только из тех документов, которые сотрудник вправе видеть, и не подтягивал чужие данные.
- Двадцать-тридцать реальных вопросов сотрудников с ожидаемыми ответами — на этой выборке проверяем качество выдачи и настраиваем отбор фрагментов.
- Объём корпуса и частота изменений: как быстро документы устаревают и с какой периодичностью нужно переиндексировать материалы.
- Требования к контуру: где допустимо хранить документы и вектора, есть ли запрет на внешние сервисы, кто выдаёт доступы к Teams и хранилищам.
- Кто со стороны заказчика принимает результат и в какие окна можно запустить пилотную группу пользователей.
Отдельно полезно заранее договориться, как поймём, что поиск работает: доля ответов со ссылкой на подтверждающий источник, снижение потока однотипных обращений в поддержку, время до первого корректного ответа у нового сотрудника.
Если часть пунктов пока не сформулирована — это не блокирует старт. Обсудим внедрение поиска на том, что есть, и вернёмся с оценкой, планом работ и границами первого этапа. Даже короткий запрос на внедрение чат-бота — опишите пользователей, источники и ограничения — достаточен, чтобы мы посчитали сроки.
