Працівник ставить запитання про внутрішній процес, а потрібна відповідь розпорошена між інструкцією, довідником і кількома оновленнями. Звичайна мовна модель не знає, який із цих документів компанія вважає чинним. Щоб отримати корисну відповідь, програмі потрібно знайти відповідні матеріали та використати їх як контекст.
Такий підхід часто називають RAG — генерацією з доповненням через пошук. Розглянемо, як він працює, чому якість документів має значення та що потрібно підготувати перед створенням внутрішнього помічника.
Як поєднуються пошук і відповідь моделі
У спрощеній схемі система спочатку шукає фрагменти документів, пов’язані із запитанням. Потім передає відібрані уривки мовній моделі разом із запитом та інструкціями щодо відповіді. Модель готує пояснення, спираючись на наданий контекст. Програма може додати посилання на використані документи.
Сам пошук може враховувати ключові слова, близькість змісту або поєднувати кілька підходів. Але навіть складний пошук не виправить суперечливі інструкції. Якщо в базі одночасно лежать дві версії правила без позначення актуальності, це залишається проблемою джерел.
Приклад: як знайти чинну внутрішню інструкцію
Уявімо компанію з довідником для нових працівників. Людина запитує: «Як подати заявку на доступ до навчальної платформи?» У старому документі вказана адреса пошти, у новому — внутрішня форма. Помічник має знайти чинну інструкцію, а не просто документ із найбільшою кількістю однакових слів.
Корисна відповідь у цьому умовному сценарії містить порядок дій, посилання на форму та назву джерела. Якщо право подавати заявку залежить від підрозділу, система враховує доступний контекст або просить уточнення. Вона не повинна самостійно додумувати правило, якого немає в документах.
Для перевірки можна поставити кілька варіантів того самого запитання: офіційний, розмовний і з помилкою в назві платформи. Команді важливо побачити, чи знаходиться правильна інструкція за різного формулювання та чи не потрапляє до відповіді застаріла адреса.
Що потрібно зробити з документами
Перший крок — інвентаризація. Визначте, де зберігаються матеріали, хто відповідає за зміст і як відрізнити чинну версію від архівної. Для початкової версії часто корисніше обрати один добре впорядкований розділ, ніж підключати весь файловий простір компанії.
- Актуальність. Позначте версію, дату набрання чинності або іншу ознаку, за якою можна обрати потрібний документ.
- Структура. Збережіть заголовки, списки й зв’язок між правилом та винятками. Окремий уривок без пояснення може змінити зміст.
- Якість тексту. Перевірте, чи читається вміст сканів і чи правильно відновлені важливі назви, числа та таблиці.
- Власник. Визначте людину або команду, яка виправлятиме неточності й повідомлятиме про оновлення.
- Доступ. Вкажіть, яким групам користувачів дозволено бачити документ і його фрагменти.
Таке впорядкування корисне й без ШІ. Воно допомагає команді зрозуміти, яку інформацію система взагалі може вважати надійною основою відповіді.
Чому важливо зберігати контекст фрагментів
Великі матеріали часто поділяють на частини для пошуку. При цьому разом із фрагментом варто зберігати назву документа, розділ, версію та посилання. Інакше знайдений текст може не містити важливої умови з попереднього абзацу або винятку з наступного.
Наприклад, речення «заявка подається керівником» без назви розділу не пояснює, для якого типу доступу діє правило. Під час перевірки потрібно читати не лише сформовану відповідь, а й уривки, які отримала модель. Це допомагає відрізнити помилку пошуку від помилки пояснення.
Доступ до знань перевіряє програма
Внутрішня база може містити як загальні інструкції, так і матеріали окремих команд. Система має знаходити лише ті фрагменти, які дозволені конкретному користувачу. Цю перевірку потрібно виконувати до передавання вмісту в контекст відповіді.
Приховати назву документа вже після генерації недостатньо, якщо його вміст став основою пояснення. Тому під час проєктування погоджують джерело прав доступу, поведінку після їх зміни та правила обробки видалених матеріалів. Це частина інтеграції, яку не замінює інструкція в запиті до моделі.
Як перевірити, чи працює база знань
Підготуйте запитання з відомими правильними джерелами. Додайте випадки, коли відповіді немає, документи суперечать один одному або користувач не має доступу. Окремо перевірте оновлення: нова редакція має потрапляти в пошук, а вилучена інформація — перестати використовуватися.
- Перевірте, чи знайдений потрібний документ і достатній контекст.
- Зіставте твердження відповіді з відповідними уривками.
- Перейдіть за посиланням і переконайтеся, що джерело відкривається для цього користувача.
- Оцініть, чи система просить уточнення або повідомляє про відсутність даних там, де це потрібно.
- Повторіть перевірку після оновлення матеріалів або налаштувань пошуку.
Який результат варто очікувати
Корисна база знань допомагає швидше знаходити й пояснювати актуальну інформацію, але не усуває потребу підтримувати документи. Її якість залежить від змісту, пошуку, доступів і перевірки відповіді разом. Для першого етапу оберіть одну тему та погодьте, які запитання система повинна обробляти.
Якщо після знаходження відповіді потрібно також створити заявку чи перевірити її статус, до бази знань додаються інтеграції з бізнес-системами. Це окремий крок із власними вимогами до доступів і підтвердження дій.
