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