- Визначте питанняОберіть конкретну тему та очікувані відповіді.
- Уточніть джерелаПозначте відповідальних, чинні версії та пріоритети.
- Перевірте розпізнаванняПорівняйте скани й таблиці з оригіналами.
- Перевірте відповідіЗвірте докази, поведінку без джерел і межі доступу.
Почніть із питання, а не всього архіву
Визначте, про що люди запитуватимуть: як залучити постачальника, виконати процедуру обслуговування або знайти затверджені правила. Так простіше зібрати початковий набір документів і зрозуміти, чи допомагає відповідь виконати роботу.
Велика кількість файлів не означає неминучих помилок, але ускладнює визначення меж теми, суперечностей і прав доступу. До першої пошукової добірки включіть потрібні матеріали. Старі версії можна залишити для історичних питань, якщо їхній статус зрозумілий.
- Запишіть питання, на які має відповідати перша версія.
Позначте чинну версію
Призначте відповідального за кожен документ і зазначте версію, статус затвердження та дату набрання чинності, де це доречно. Поясніть, яке джерело має пріоритет у разі суперечності. Слово 'фінальний' у назві файлу цього не вирішує.
Домовтеся, хто оновлює добірку після зміни правил і як скасовані матеріали позначаються або виключаються з відповідей про поточні процедури. Пошукова система не може сама вирішити, яку з незгоджених інструкцій компанія вважає чинною.
- Зробіть відповідальність за зміст та оновлення видимою.
Перевірте, що система прочитала
Електронний текст, скани, таблиці та схеми потребують різних способів обробки. OCR розпізнає текст на сканах, а мультимодальні інструменти можуть аналізувати зображення, проте жоден із цих підходів не гарантує точності. Тестуйте типові файли, а не лише їхні формати.
Порівняйте отриманий вміст з оригіналом. Перевірте заголовки стовпців, зв'язки рядків, одиниці виміру, примітки й об'єднані клітинки. У сканах зверніть увагу на нечіткий текст і повернуті сторінки. Збережіть структуру, без якої таблицю можна прочитати неправильно.
- Включіть до тесту складні частини ваших робочих документів.
Перевіряйте відповіді разом із доступом
Користувач має отримувати інформацію лише з дозволених йому джерел. Перевірте цю межу в пошуку, відповідях, посиланнях і кешованих результатах. Додайте випадок, коли користувач не має доступу до потрібного документа.
Посилання має дозволяти знайти джерело: назва документа або адреса, а також сторінка, розділ чи клітинка, якщо доступні. Перевірте, чи підтверджує цитований фрагмент відповідь. Поставте питання з відомою відповіддю, суперечливими версіями та без джерела. Якщо підтвердження немає, система має повідомити про це, а не вигадувати інструкцію.
- Перед ширшим використанням попросіть власника документів переглянути відповіді.
Практичний наступний крок
Оберіть одну тему й відповідального, зберіть чинні документи та невеликий набір типових питань для спільної перевірки.
Читайте також
Зробіть документ придатним до читання
Перевірте, чи витягується текст з PDF і чи зберігається зміст таблиць. Скан може потребувати розпізнавання, а складна таблиця — окремого представлення з заголовками колонок. Перегляньте отриманий текст очима: наявність символів у файлі ще не означає, що ціна, одиниця виміру та примітка залишилися разом.
Деталі для впровадження
Заголовок розділу, назва продукту й умови застосування мають бути зрозумілими без читання всього архіву. Не відривайте виняток від правила. Для довгих документів визначте межі фрагментів так, щоб відповідь могла послатися на конкретний розділ і відкрити його людині.
Як це працює
Один із можливих сценаріїв
Запитання
Співробітник формулює задачу своїми словами.
Потрібний документ
Пошук знаходить матеріал, доступний цій людині.
Відповідь із джерелом
Можна відкрити оригінал і перевірити контекст.
Встановіть межі доступу до пошуку
Право бачити відповідь не повинно бути ширшим за право читати її джерело. Перевіряйте обмеження під час пошуку, а не лише приховуйте посилання після генерації. У пілоті потрібні запити від різних ролей, включно зі спробою знайти документ без дозволу.
Деталі для впровадження
Текст документа — це матеріал для відповіді, а не команда асистенту змінити правила. OWASP відносить prompt injection до ризиків LLM-застосунків. Практичний наслідок для пілота: не дозволяйте довільному тексту з джерела самостійно запускати дії чи відкривати нові дані.
Підготуйте питання з очікуваними джерелами
Зберіть справжні запитання команди та позначте документ або розділ, який підтверджує відповідь. Додайте питання з неоднозначним формулюванням, застарілу версію правила й питання, відповіді на яке немає. Останній випадок перевіряє, чи вміє система чесно відмовитися від здогадки.
Деталі для впровадження
Оцінюйте окремо: чи знайдено правильний фрагмент, чи відповідь йому відповідає, чи посилання відкривається і чи дотримано доступ. Красиве формулювання з неправильного документа — помилка. Один загальний відсоток без складу вибірки приховає причину.
Домовтеся, як знання оновлюються
Визначте, хто затверджує нову версію й коли попередня перестає брати участь у відповідях. Якщо джерело недоступне або синхронізація затрималася, користувач має бачити відповідний стан. Мовчазне використання старої інструкції може бути гіршим за відсутність відповіді.
Деталі для впровадження
Перед передачею документів погодьте, де зберігаються оригінали, які частини надходять зовнішній моделі, скільки зберігаються журнали та хто має доступ. Не називайте рішення повністю локальним лише тому, що файли лежать на вашому сервері: шлях запиту й обробки потрібно перевірити окремо.
Що входить у предметний перший пілот
Обсяг можна сформулювати як один набір документів, погоджені ролі, контрольні запитання та екран відповіді з джерелами. Результат пілота — звіт про конкретні правильні й неправильні відповіді, а також рішення, що виправляти далі. Це корисніше за демонстрацію лише вдалих запитів.
Деталі для впровадження
Якщо основна проблема — суперечливі документи, наступним кроком буде робота з їхніми власниками. Якщо джерела впорядковані, але пошук пропускає потрібне, можна покращувати індексацію й перевіряти ту саму контрольну вибірку.