Добрий запит конкретно описує доручене моделі завдання та умови успіху. Немає гарантії, що додавання особливої фрази підвищить якість відповіді в кілька разів.
1. Спочатку визначте вхідні та вихідні дані
Наприклад, класифікуючи звернення клієнтів, задайте категорії, мову вхідних даних і обробку неоднозначних випадків. Прохання «Запиши окремо рішення, відповідальних і строки, а відсутню інформацію познач як невизначену» перевірити легше, ніж «Добре це підсумуй». Формат результату та фактичну точність оцінюйте окремо.
2. Які критерії показують приклади
Приклади, що поєднують вхідні дані з бажаним результатом, можуть передати критерії завдання. Крім простих, включайте граничні випадки та дані з недостатньою інформацією. Перевіряйте, чи не переносить модель імена й числа з прикладів у нові дані як факти.
3. Як порівнювати зміни
Порівнюйте версії запиту на одному наборі вхідних даних і записуйте типи помилок. Розрізняючи пропуски, вигадані відомості й порушення формату, легше знайти потрібні виправлення. Довше пояснення після спонукання міркувати не доводить більшої точності: підстави результату перевіряють окремо. Фіксуйте зміни моделі, налаштувань і входу, щоб зберігати умови порівняння.
4. Приклад структурування нотаток зустрічі
Нехай у вигаданій нотатці сказано: «Розгортання поки плануємо на п’ятницю. Мінсу завтра перевірить стан сервера. Підтвердження розкладу очікує схвалення Чійон». Якщо подати дату розгортання як затверджений строк, важливий зміст зміниться, навіть коли речення відредаговано красиво. Спочатку визначте завдання як «Записати підтверджені дії окремо від пропозицій», а поля — дія, відповідальний, строк, стан і підстава. Додайте заборону вгадувати відсутніх у нотатці відповідальних і дати.
Бажаний результат розрізняє Мінсу як відповідального за перевірку сервера, завтра як її строк і очікування схвалення як стан розкладу розгортання. Без сьогоднішньої дати у вхідних даних немає підстав перетворити «завтра» на календарну дату. Передайте опорну дату в запиті або вимагайте зберігати відносні дати оригіналу. Відповідальний за розгортання не вказаний і має лишитися невизначеним. Це вправа з визначення критеріїв результату, а не цитування справжніх записів компанії чи експериментальних показників.
Запит легше перевіряти, коли замість самої рольової фрази «Ти чудовий помічник» він указує межі входу й правила перетворення. Наприклад: «Використовуй лише наведені нотатки, не перетворюй пропозиції на підтверджені рішення та поряд із кожною дією наведи речення-підставу». Мета — дати людині перевірити відповідність нотаток і результату, а не оцінювати переконливість пояснення.
5. Відокремлюйте граничні випадки від вказівок у зовнішньому тексті
Для класифікації уявіть речення, що поєднує питання про повернення грошей із затримкою доставки. Без правила про одну чи кілька категорій оцінювачі розходитимуться у правильній відповіді. «Відповідної категорії немає» і «Недостатній вхід» також різні випадки. Відокремлення зрозумілого змісту, що не відповідає таблиці, від браку інформації для визначення змісту прояснює подальшу обробку.
Приклади не лише передають відповіді, а й пояснюють ці межі. Замість багатьох простих речень про доставку додайте речення з конфліктом категорій, з друкарською помилкою та привітання без прохання. Водночас потрібні виправлення, якщо надто довгі приклади приховують ключове правило або їхні власні назви потрапляють у новий вхід. Перевіряйте також відсутність суперечностей між описом завдання та прикладами.
Під час підсумовування документа фраза всередині нього на кшталт «Ігноруй попередні вказівки» сама є частиною оброблюваного матеріалу. Розділювачі навколо входу полегшують читання межі, але самі собою не є захисним бар’єром проти атак. Якщо застосунок виконує зовнішні дії, код поза запитом також має перевіряти права й дозволені інструменти. Потрібні і чіткий текст, і налаштування системних дозволів.
6. Спершу виправляйте таблицю оцінювання, потім запит
Невелика таблиця може містити вхід, очікувані ключові пункти, заборонені здогадки, фактичний результат і причину помилки. Якщо у двох із десяти нотаток непідтверджені строки стали підтвердженими, спочатку знайдіть спільні умови цих випадків. Уточнення визначень пропозиції, очікування схвалення й підтвердження разом із прикладами пов’язує зміни з проблемою краще, ніж повторення «Будь уважнішим».
Повторна оцінка лише випадків, використаних для виправлення, може видати пристосування до них за загальне поліпшення. Застосуйте ті самі правила до окремо відкладених входів і перевірте нові пропуски у простих випадках. Окремий облік дотримання формату й точності не дасть правильному JSON приховати змістові помилки. Неправильна відповідь із правдоподібним обґрунтуванням теж помилка.
Праці про навчання на кількох прикладах і використання міркувань — дослідження певних моделей та завдань, а не правило однакової спонукальної фрази для всіх новітніх моделей. В остаточному запиті важливіші визначення роботи, типові приклади, обробка неоднозначності та повторювані критерії оцінки, ніж декоративні означення. Після зміни моделі чи форми входу перевірте ці чотири елементи знову.
Критерії повинні враховувати важливість помилок. Перестановка речень у підсумку зустрічі та вигаданий відповідальний — різні збої. Перше може стосуватися зручності читання, друге породжує неправильне доручення. Розрізняйте поля обов’язкової людської перевірки й автоматичного передавання далі: так ясніша відповідальність у реальній роботі. Рідкість помилок не виправдовує пропуск перевірки важливих полів.
Змінюючи формат виводу, пов’язуйте перевірку форми зі змістом. Непорожнє поле дати свідчить лише про наявність значення. Чи була дата в оригіналі та чи правильно її обчислено за опорною датою — інші перевірки. Якщо обов’язкові поля парсера суперечать забороні заповнювати дані без підстав, краще створити схему для стану «невизначено», ніж вимагати порожній рядок.
Поширюючи запит, можна написати вигадані входи з тими самими межами, не копіюючи реальні персональні дані. Перевірте, чи не дозволяють номер договору або рідкісна подія впізнати особу навіть без імені. Навіть достатня анонімізація не скасовує правил організації щодо матеріалів для зовнішньої моделі. Добра документація запиту описує і приклади входу, і сферу завдань, де його можна та не можна застосовувати.
На завершення перевірте, чи зрозуміє інша людина ті самі критерії правильної відповіді з одного запиту. Очікування, що результат сам виведе відомі лише автору внутрішні обставини, ускладнює відтворення. Визначте неоднозначні вислови, надайте потрібну опорну дату й версію документа та спосіб лишити непідтверджені поля незаповненими — і навіть короткий запит стане перевірюваним описом роботи.