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