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