Цей модуль охоплює основні концепції та методики створення ефективних підказок для генеративних моделей ШІ. Важливо, як ви формулюєте свою підказку до великої мовної моделі (LLM). Ретельно продумана підказка може забезпечити кращу якість відповіді. Але що саме означають терміни підказка та інжиніринг підказок? І як покращити вхідну підказку, яку я надсилаю LLM? Це питання ми спробуємо розглянути у цій і наступній главі.
Генеративний ШІ здатний створювати новий контент (наприклад, текст, зображення, аудіо, код тощо) у відповідь на запити користувачів. Це досягається за допомогою Великих мовних моделей (Large Language Models), таких як серія GPT від OpenAI ("Generative Pre-trained Transformer"), натренованих для роботи з природною мовою та кодом.
Користувачі тепер можуть взаємодіяти з цими моделями, використовуючи знайомі формати, як-от чат, без технічної підготовки або навчання. Моделі є підказковими — користувачі надсилають текстовий вхід (підказку) і отримують у відповідь відповідь ШІ (завершення). Вони можуть "спілкуватися з ШІ" по черзі, у багатоетапних розмовах, уточнюючи підказку, поки відповідь не відповідатиме їхнім очікуванням.
Тепер "підказки" стають основним інтерфейсом програмування для додатків генеративного ШІ, задаючи моделям, що робити, і впливаючи на якість отриманих відповідей. "Інжиніринг підказок" — це швидкозростаюча галузь, що зосереджується на розробці та оптимізації підказок для забезпечення послідовних і якісних відповідей у великому масштабі.
У цьому уроці ми дізнаємося, що таке інжиніринг підказок, чому він важливий і як створювати більш ефективні підказки для конкретної моделі та цілей застосування. Ми зрозуміємо основні поняття та найкращі практики інжинірингу підказок — а також дізнаємося про інтерактивне середовище Jupyter Notebooks "пісочниця", де можна побачити застосування цих концепцій на реальних прикладах.
До кінця цього уроку ми зможемо:
- Пояснити, що таке інжиніринг підказок і чому він важливий.
- Описати компоненти підказки та їх використання.
- Вивчити найкращі практики та методики інжинірингу підказок.
- Застосувати вивчені методики до реальних прикладів з використанням кінцевої точки OpenAI.
Інжиніринг підказок: Практика проєктування та вдосконалення вхідних даних для керування моделями ШІ задля отримання бажаних результатів. Токенізація: Процес перетворення тексту на менші одиниці — токени, які модель може розуміти та обробляти. Мовні моделі з налаштуванням на інструкції: Великі мовні моделі (LLM), які були додатково навчені за допомогою специфічних інструкцій для покращення точності та релевантності відповідей.
Інжиніринг підказок наразі більше мистецтво, ніж наука. Найкращий спосіб покращити інтуїцію — це більше практикуватися та застосовувати методику проб і помилок, поєднуючи галузеву експертизу з рекомендованими прийомами та оптимізаціями, специфічними для моделей.
Jupyter Notebook, що супроводжує цей урок, надає середовище пісочниці, де ви можете випробувати набуті знання — під час проходження уроку або у вигляді коду на фінальному завданні. Для виконання вправ вам знадобиться:
- API-ключ Azure OpenAI — кінцева точка сервісу для розгорнутої LLM.
- Середовище Python — у якому можна виконувати ноутбук.
- Локальні змінні оточення — зараз виконайте кроки SETUP, щоб підготуватися.
Ноутбук містить початкові вправи, але вас заохочують додавати власні розділи з Markdown (опис) і Кодом (запити підказок) для спроб різних прикладів або ідей — і щоб розвивати інтуїцію у дизайні підказок.
Хочете швидко отримати загальне уявлення про теми уроку? Перегляньте цей ілюстрований посібник, який дає задуматися над основними темами й ключовими висновками. Дорожня карта уроку веде від розуміння основних понять і викликів до їх подолання з допомогою відповідних технік і найкращих практик інжинірингу підказок. Зверніть увагу, що розділ "Розширені техніки" у цьому посібнику стосується матеріалів наступної глави цього курсу.
Тепер поговоримо, як ця тема пов’язана з місією нашого стартапу щодо впровадження інновацій ШІ в освіту. Ми хочемо створювати застосунки ШІ для персоналізованого навчання, тож подумаймо, як різні користувачі нашого додатку можуть "проєктувати" підказки:
- Адміністратори можуть попросити ШІ проаналізувати дані навчальної програми для виявлення пропусків у її охопленні. ШІ може узагальнити результати або візуалізувати їх за допомогою коду.
- Викладачі можуть попросити ШІ створити план уроку для цільової аудиторії та теми. ШІ створює персоналізований план у заданому форматі.
- Учні можуть попросити ШІ наставляти їх із складного предмета. ШІ допомагає учням через уроки, підказки та приклади, адаптовані до їх рівня.
Це лише верхівка айсберга. Перегляньте Prompts For Education — відкриту бібліотеку підказок, відбір якої зробили експерти з освіти — щоб краще усвідомити можливості! Спробуйте запустити деякі з цих підказок у пісочниці або на OpenAI Playground, щоб побачити, що станеться!
Ми почали цей урок з визначення інжинірингу підказок як процесу проектування та оптимізації текстових вхідних даних (підказок) для забезпечення послідовних і якісних відповідей (завершень) відповідно до цілей застосування та моделі. Можна уявити це як двоетапний процес:
- проектування початкової підказки для певної моделі й цілі
- вдосконалення підказки ітеративно для покращення якості відповіді
Це необхідно робити методом проб і помилок, що вимагає інтуїції користувача та зусиль для досягнення оптимальних результатів. Отже, чому це важливо? Для відповіді спочатку потрібно зрозуміти три поняття:
- Токенізація = як модель "бачить" підказку
- Базові LLM = як фундаментальна модель "обробляє" підказку
- LLM з налаштуванням на інструкції = як модель тепер "бачить" завдання
LLM розглядає підказки як послідовність токенів, причому різні моделі (або версії моделі) можуть токенізувати одну й ту саму підказку по-різному. Оскільки LLM навчаються на токенах (а не на сирому тексті), спосіб токенізації підказок безпосередньо впливає на якість створеної відповіді.
Щоб зрозуміти, як працює токенізація, спробуйте інструменти на кшталт OpenAI Tokenizer, показаний нижче. Вставте вашу підказку і перегляньте, як вона розбивається на токени, звертаючи увагу на те, як обробляються пропуски та пунктуація. Зауважте, що приклад показує старішу модель LLM (GPT-3) — тому для новішої моделі результат може відрізнятись.
Після токенізації підказки основна функція "Базової LLM" (фундаментальної моделі) полягає в прогнозуванні токена в цій послідовності. Оскільки LLM навчаються на величезних текстових наборах, вони мають добрі уявлення про статистичні зв’язки між токенами і можуть робити прогнози з певною впевненістю. Зверніть увагу, що вони не розуміють значення слів у підказці або токенах; вони бачать лише шаблон, який можуть "заповнити" своїм наступним прогнозом. Вони можуть продовжувати прогнозування послідовності доти, доки це не буде припинено користувачем або через певні умови.
Хочете побачити, як працює завершення на основі підказок? Введіть вищезазначену підказку у Microsoft Foundry playground з настройками за замовчуванням. Система налаштована розглядати підказки як запити інформації — тож ви отримаєте відповідь, що задовольняє цей контекст.
Але що як користувач хоче побачити щось конкретне, що відповідає певним критеріям чи цілям завдання? Саме тут на сцену виходять LLM з налаштуванням на інструкції.
LLM з налаштуванням на інструкції починаються з фундаментальної моделі і додатково навчаються на прикладах або парах вхід-вихід (наприклад, багатоходові "повідомлення"), які можуть містити чіткі інструкції — а відповідь ШІ намагається слідувати цим інструкціям.
Це використовує методики, як-от підсилювальне навчання з людським зворотним зв’язком (RLHF), що тренують модель слухатися інструкцій і вчитися на зворотному зв’язку, щоб виробляти відповіді, більш придатні для практичних застосувань і більш релевантні цілям користувача.
Спробуймо — поверніться до поданої вище підказки, але тепер змініть системне повідомлення, щоб вказати таку інструкцію як контекст:
Підсумуйте наданий вам матеріал для учня другого класу. Залиште результат у вигляді одного абзацу з 3-5 ключовими пунктами.
Бачите, як відповідь тепер адаптована до бажаної мети та формату? Викладач може безпосередньо використовувати цю відповідь у своїх слайдах для цього уроку.
Тепер, коли ми розуміємо, як LLM обробляють підказки, поговорімо про те, чому потрібен інжиніринг підказок. Відповідь полягає в тому, що сучасні LLM ставлять ряд викликів, які ускладнюють досягнення надійних і послідовних завершень без зусиль над побудовою та оптимізацією підказок. Наприклад:
-
Відповіді моделей є стохастичними. Така сама підказка може давати різні відповіді на різних моделях або версіях моделі. Інколи вона може давати різні результати навіть на одній і тій же моделі у різний час. Методики інжинірингу підказок допомагають мінімізувати ці коливання, задаючи кращі обмеження.
-
Моделі можуть вигадувати відповіді. Моделі натреновані на великих, але обмежених наборах даних, тому вони не мають знань про поняття за межами цих даних. Через це вони можуть генерувати неточні, вигадані або навіть суперечливі відомим фактам відповіді. Техніки інжинірингу підказок допомагають користувачам виявляти та пом’якшувати такі вигадки, наприклад, запитуючи ШІ про цитати чи аргументацію.
-
Можливості моделей будуть відрізнятись. Нові моделі або їхні покоління мають ширші можливості, але й унікальні особливості та компроміси у вартості й складності. Інжиніринг підказок допомагає розробляти найкращі практики та робочі процеси, що абстрагують ці відмінності і адаптуються під особливості конкретної моделі масштабовано й безперебійно.
Переконайтеся в цьому, використовуючи OpenAI або Azure OpenAI Playground:
- Спробуйте ту саму підказку на різних розгортаннях LLM (наприклад, OpenAI, Azure OpenAI, Hugging Face) — чи помітили ви відмінності?
- Використайте ту саму підказку кілька разів на одному розгортанні LLM (наприклад, Azure OpenAI playground) — як відрізнялись ці варіації?
У цьому курсі ми вживаємо термін "вигадка" для явища, коли LLM іноді генерують фактично неправильну інформацію через обмеження під час навчання чи інші фактори. Ви могли чути про це як про "ілюзії" (hallucinations) у популярних статтях або дослідженнях. Проте ми наполегливо рекомендуємо вживати саме термін "вигадка", щоб уникнути антропоморфізації поведінки, приписуючи людські риси машинному результату. Це також підтримує принципи відповідального ШІ з точки зору термінології, усуваючи слова, які можуть бути в деяких контекстах образливими або недоречними.
Хочете зрозуміти, як працюють вигадки? Подумайте про підказку, яка наказує ШІ створити контент на тему, якої не існує (щоб переконатися, що її немає в навчальному наборі). Наприклад, я спробував таку підказку:
Підказка: створити навчальний план про Марсіанську війну 2076 року.
Веб-пошук показав, що є вигадані оповідання (наприклад, телесеріали чи книги) про марсіанські війни, але не про 2076 рік. Здоровий глузд також підказує, що 2076 — це майбутнє, і тому не може бути пов’язаний з реальною подією.
Отже, що станеться, якщо ми запустимо цей запит до різних постачальників LLM?
Відповідь 1: OpenAI Playground (GPT-35)
Відповідь 2: Azure OpenAI Playground (GPT-35)
Відповідь 3: : Hugging Face Chat Playground (LLama-2)
Як і очікувалося, кожна модель (або версія моделі) дає дещо різні відповіді завдяки стохастичній поведінці та відмінностям у можливостях моделей. Наприклад, одна модель орієнтована на аудиторію восьмого класу, а інша розраховує на учня старшої школи. Але всі три моделі згенерували відповіді, які можуть переконати необізнаного користувача, що подія була реальною.
Техніки розробки запитів, такі як метазапити та налаштування температури, можуть дещо знизити вигадки моделей. Нові архітектури розробки запитів також безперешкодно інтегрують нові інструменти та методики у потік запиту, щоб пом’якшити або зменшити деякі з цих ефектів.
Завершимо цей розділ, ознайомившись із тим, як інженерія запитів використовується у реальних рішеннях на прикладі GitHub Copilot.
GitHub Copilot — це ваш "AI партнер-програміст" — він перетворює текстові запити в доповнення коду і інтегрований у ваше середовище розробки (наприклад, Visual Studio Code) для безперебійного користувацького досвіду. Як зазначено у серії блогів нижче, найперша версія була заснована на моделі OpenAI Codex — інженери швидко зрозуміли необхідність донавчання моделі і розробки кращих технік інженерії запитів для покращення якості коду. У липні вони представили покращену AI-модель, що виходить за межі Codex для ще швидших пропозицій.
Читайте пости послідовно, щоб простежити їхній процес навчання.
- травень 2023 | GitHub Copilot краще розуміє ваш код
- травень 2023 | Всередині GitHub: робота з LLM за GitHub Copilot.
- червень 2023 | Як писати кращі запити для GitHub Copilot.
- липень 2023 | .. GitHub Copilot виходить за межі Codex з покращеною моделлю AI
- липень 2023 | Посібник для розробників з інженерії запитів та LLM
- вересень 2023 | Як створити корпоративний додаток з LLM: уроки від GitHub Copilot
Ви також можете переглянути їхній інженерний блог для отримання додаткових публікацій, як-от цей, який показує, як ці моделі та методики застосовуються для керування реальними додатками.
Ми бачили, чому інженерія запитів важлива — тепер давайте зрозуміємо, як запити конструюються, щоб ми могли оцінити різні техніки для більш ефективного дизайну запитів.
Почнемо з базового запиту: текстового вводу, надісланого моделі без іншого контексту. Ось приклад — коли ми відправляємо перші кілька слів національного гімну США до OpenAI Completion API, воно миттєво завершує відповідь наступними рядками, ілюструючи базову поведінку передбачення.
| Запит (вхід) | Відповідь (вихід) |
|---|---|
| Oh say can you see | Це звучить так, ніби ви почали співати слова "The Star-Spangled Banner", національного гімну Сполучених Штатів. Повний текст гімну містить ... |
Тепер додамо контекст і інструкції до базового запиту. API для чат-комплішенів (Chat Completion API) дозволяє формувати складний запит як колекцію повідомлень з:
- парами вводу/виводу, що відображають ввід користувача і відповідь асистента.
- системним повідомленням, яке встановлює контекст поведінки або особистості асистента.
Запит тепер має наступну форму, де токенізація ефективно захоплює релевантну інформацію з контексту та розмови. Зміна системного контексту може бути такою ж впливовою на якість відповіді, як і самі ввідні дані користувача.
response = client.responses.create(
model="gpt-5-mini",
input=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Who won the world series in 2020?"},
{"role": "assistant", "content": "The Los Angeles Dodgers won the World Series in 2020."},
{"role": "user", "content": "Where was it played?"}
]
)У наведених прикладах користувацький запит був простим текстовим запитом, який можна інтерпретувати як прохання про інформацію. З інструкційними запитами ми можемо використати цей текст для детального визначення завдання, надаючи кращі вказівки ШІ. Ось приклад:
| Запит (вхід) | Відповідь (вихід) | Тип інструкції |
|---|---|---|
| Напишіть опис Громадянської війни | повернув простий абзац | Простий |
| Напишіть опис Громадянської війни. Наведіть ключові дати та події і опишіть їхнє значення | повернув абзац, за яким слідує список ключових дат та описів подій | Складний |
| Напишіть опис Громадянської війни в 1 абзаці. Наведіть 3 ключові дати з їх значенням у вигляді маркованих пунктів. Наведіть 3 марковані пункти з ключовими історичними фігурами та їх внеском. Поверніть результат у файлі JSON | повертає розгорнуті деталі у текстовій коробці, відформатовані у JSON, які ви можете скопіювати й вставити у файл та за потреби перевірити | Складний. Відформатований. |
У наведених прикладах запит все ще був досить відкритим, дозволяючи LLM самостійно визначити, яка частина його попередньо натренованого набору даних є релевантною. З дизайном основного контенту вхідний текст розбивається на дві частини:
- інструкція (дія)
- релевантний контент (що впливає на дію)
Ось приклад, де інструкція — "підсумуйте це у 2 речення".
| Запит (Вхід) | Відповідь (Вихід) |
|---|---|
| Юпітер — п’ята планета від Сонця і найбільша у Сонячній системі. Це газовий гігант з масою в тисячу разів меншою за масу Сонця, але в два з половиною рази більшою за суму мас усіх інших планет Сонячної системи разом. Юпітер — один із найяскравіших об’єктів, видимих неозброєним оком у нічному небі, відомий стародавнім цивілізаціям ще до початку писемної історії. Названий на честь римського бога Юпітера.[19] При спостереженні з Землі Юпітер може бути достатньо яскравим, щоб його відбите світло кидало видимі тіні,[20] і в середньому є третім за яскравістю природним об’єктом у нічному небі після Місяця та Венери. Підсумуйте це у 2 короткі речення |
Юпітер, п’ята планета від Сонця, найбільший у Сонячній системі і відомий як один із найяскравіших об’єктів у нічному небі. Названий на честь римського бога Юпітера, це газовий гігант з масою у два з половиною рази більшою за суму мас усіх інших планет Сонячної системи разом узятих. |
Сегмент основного контенту можна використовувати різними способами для ефективнішого формулювання інструкцій:
- Приклади — замість прямої інструкції дайте моделі приклади того, що робити, і вона сама виведе шаблон.
- Сигнали — додайте після інструкції "сигнал", який підготуватиме відповідь, направляючи модель до більш релевантних відповідей.
- Шаблони — це повторювані «рецепти» для запитів із заповнювачами (змінними), які можна адаптувати даними для конкретних випадків використання.
Давайте розглянемо це на практиці.
Це підхід, коли ви використовуєте основний контент, щоб "підкріпити модель" прикладами бажаного виходу для заданої інструкції і даєте їй самій вивести шаблон бажаного результату. Залежно від кількості наданих прикладів, ми маємо нульовий (zero-shot), один (one-shot), кілька (few-shot) прикладів тощо.
Запит тепер складається з трьох компонентів:
- опис завдання
- кілька прикладів бажаного результату
- початок нового прикладу (який стає неявним описом завдання)
| Тип навчання | Запит (вхід) | Відповідь (вихід) |
|---|---|---|
| Нульовий | "The Sun is Shining". Перекладіть іспанською | "El Sol está brillando". |
| Один приклад | "The Sun is Shining" => ""El Sol está brillando". "It's a Cold and Windy Day" => |
"Es un día frío y ventoso". |
| Кілька прикладів | Гравець пробіг усі бази => бейсбол Гравець подав эйс => теніс Гравець набрав шістку => крикет Гравець зробив слем-данк => |
баскетбол |
Зверніть увагу, що в нульовому прикладі потрібно було явно вказати інструкцію ("Перекладіть іспанською"), тоді як у прикладі з одним запитом це виводиться самим. Приклад із кількома дозволяє моделі більш точно виводити шаблони без додаткових інструкцій.
Ще одна техніка використання основного контенту — давати сигнали, а не приклади. У цьому випадку ми даємо моделі підказку, починаючи зі шматка тексту, який відображає бажаний формат відповіді. Модель тоді "ловить сигнал" і продовжує у тому ж стилі.
| Кількість сигналів | Запит (вхід) | Відповідь (вихід) |
|---|---|---|
| 0 | Юпітер — п’ята планета від Сонця і найбільша у Сонячній системі. Це газовий гігант з масою в тисячу разів меншою за масу Сонця, але в два з половиною рази більшою за суму мас усіх інших планет Сонячної системи разом. Юпітер — один із найяскравіших об’єктів, видимих неозброєним оком у нічному небі, відомий стародавнім цивілізаціям ще до початку писемної історії. Підсумуйте це |
Юпітер — найбільша планета в нашій Сонячній системі і п’ята від Сонця. Це газовий гігант з масою, що дорівнює 1/1000 маси Сонця, але він важчий за всі інші планети разом узяті. Стародавні цивілізації давно знали про Юпітер, і його легко побачити на нічному небі. |
| 1 | Юпітер — п’ята планета від Сонця і найбільша у Сонячній системі. Це газовий гігант з масою в тисячу разів меншою за масу Сонця, але в два з половиною рази більшою за суму мас усіх інших планет Сонячної системи разом. Юпітер — один із найяскравіших об’єктів, видимих неозброєним оком у нічному небі, відомий стародавнім цивілізаціям ще до початку писемної історії. Підсумуйте це Що ми дізналися, так це те, що Юпітер |
є п’ятою планетою від Сонця і найбільшою в Сонячній системі. Це газовий гігант із масою в тисячу разів меншою за масу Сонця, але в два з половиною рази більшою за суму всіх інших планет разом узятих. Він легко видимий неозброєним оком і відомий з давніх часів. |
| 2 | Юпітер — п’ята планета від Сонця і найбільша в Сонячній системі. Це газовий гігант із масою, що становить одну тисячну частину маси Сонця, але вдвічі з половиною більше за сумарну масу всіх інших планет Сонячної системи разом узятих. Юпітер — один із найяскравіших об’єктів, видимих неозброєним оком на нічному небі, і відомий давнім цивілізаціям ще до появи писемної історії. Підсумуйте це Топ 3 фактів, які ми дізналися: |
1. Юпітер — п’ята планета від Сонця і найбільша в Сонячній системі. 2. Це газовий гігант із масою, що становить одну тисячну частину маси Сонця... 3. Юпітер видимий неозброєним оком з давніх часів ... |
Шаблон запиту — це заздалегідь визначений рецепт для запиту, який можна зберігати та повторно використовувати за потреби для забезпечення більш послідовного користувацького досвіду у масштабі. У найпростішій формі це просто колекція прикладів запитів, як-от цей від OpenAI, що надає як інтерактивні компоненти запиту (повідомлення користувача та системи), так і формат запиту через API — для підтримки повторного використання.
У більш складній формі, як цей приклад від LangChain, він містить заповнювачі, які можна замінити даними з різних джерел (вхідні дані користувача, контекст системи, зовнішні джерела даних тощо) для динамічного створення запиту. Це дозволяє створити бібліотеку багаторазових шаблонів, які можна використовувати для забезпечення послідовного користувацького досвіду програмно у масштабі.
Нарешті, справжня цінність шаблонів полягає в здатності створювати та публікувати бібліотеки запитів для вертикальних застосувань — де шаблон запиту тепер оптимізований, щоб відображати контекст або приклади, специфічні для застосування, що робить відповіді більш релевантними і точними для цільової аудиторії користувачів. Репозиторій Prompts For Edu є чудовим прикладом такого підходу, який містить бібліотеку запитів для освітньої сфери з акцентом на ключові цілі, як планування уроків, розробка навчальних програм, репетиторство студентів тощо.
Якщо розглядати конструкцію запиту як поєднання інструкції (завдання) та цільового (основного) контенту, то додатковий контент — це як додатковий контекст, який ми надаємо, щоб якось вплинути на вихід. Це можуть бути параметри налаштування, інструкції форматування, таксономії тем тощо, які допомагають моделі налаштувати відповідь відповідно до бажаних цілей або очікувань користувача.
Наприклад: маючи каталог курсів з докладними метаданими (назва, опис, рівень, теги, викладач тощо) усіх доступних курсів навчальної програми:
- ми можемо визначити інструкцію для "підсумування каталогу курсів для осені 2023 року"
- ми можемо використати основний контент, щоб надати кілька прикладів бажаного результату
- ми можемо використати допоміжний контент, щоб визначити топ-5 "тегів" інтересу.
Тепер модель може надати підсумок у форматі, показаному на кількох прикладах — але якщо результат містить кілька тегів, вона може віддати пріоритет 5 тегам, визначеним у допоміжному контенті.
Тепер, коли ми знаємо, як промпти можуть бути сконструйовані, можна почати думати про те, як їх розробляти, щоб відображати найкращі практики. Ми можемо розглянути це двома частинами — маючи правильний мислення та застосовуючи відповідні техніки.
Інженерія запитів — це процес методом проб і помилок, тому тримайте на увазі три широкі керівні фактори:
-
Важливе розуміння домену. Точність і релевантність відповіді залежать від домена, у якому працює це застосування або користувач. Використовуйте свою інтуїцію та експертизу в домені, щоб додатково налаштувати техніки. Наприклад, визначайте доменно-специфічні особистості у системних промптах або використовуйте доменно-специфічні шаблони у користувацьких запитах. Надавайте допоміжний контент, що відображає доменно-специфічні контексти, або використовуйте доменно-специфічні сигнали та приклади, щоб спрямувати модель на знайомі шаблони використання.
-
Важливе розуміння моделі. Ми знаємо, що моделі за своєю природою стохастичні. Але впровадження моделі також може відрізнятися за типом навчального набору даних (передтреновані знання), можливостями (наприклад, через API чи SDK) та типом контенту, для якого вони оптимізовані (наприклад, код, зображення, текст). Розумійте сильні та слабкі сторони використовуваної вами моделі і використовуйте ці знання для пріоритизації завдань або створюйте налаштовані шаблони, оптимізовані під можливості моделі.
-
Важлива ітерація та валідація. Моделі швидко розвиваються, і поступово змінюються техніки інженерії запитів. Як експерт у домені, у вас може бути додатковий контекст або критерії для вашого конкретного застосування, які не застосовуються до ширшої спільноти. Використовуйте інструменти й техніки інженерії запитів, щоб "швидко розпочати" створення запитів, потім ітеруйте й перевіряйте результати, застосовуючи власну інтуїцію й експертизу домену. Записуйте свої висновки і створюйте базу знань (наприклад, бібліотеки шаблонів), які можуть бути використані іншими як нова відправна точка для швидших ітерацій у майбутньому.
Тепер розглянемо поширені найкращі практики, рекомендовані фахівцями OpenAI і Azure OpenAI.
| Що | Чому |
|---|---|
| Оцінюйте найновіші моделі. | Нові покоління моделей, ймовірно, мають покращені функції та якість — але можуть також бути дорожчими. Оцініть їхній вплив, а потім приймайте рішення про міграцію. |
| Відокремлюйте інструкції та контекст | Перевірте, чи ваш провайдер/модель визначає розмежувачі, щоб чіткіше відрізняти інструкції, основний і допоміжний контент. Це допомагає моделям точніше призначати ваги токенам. |
| Будьте конкретними та чіткими | Надавайте більше деталей про бажаний контекст, результат, довжину, формат, стиль тощо. Це покращить і якість, і послідовність відповідей. Фіксуйте рецепти у багаторазові шаблони. |
| Будьте описовими, використовуйте приклади | Моделі можуть краще реагувати на підхід "показати і розповісти". Починайте з підходу zero-shot, коли даєте інструкцію (без прикладів), потім спробуйте few-shot для уточнення, надаючи кілька прикладів бажаного результату. Використовуйте аналогії. |
| Використовуйте сигнали для початку відповіді | Підштовхуйте модель до бажаного результату, даючи їй кілька початкових слів або фраз, які вона може використати як точку старту відповіді. |
| Подвоюйте зусилля | Іноді потрібно повторити інструкції моделі. Надавайте інструкції до і після основного контенту, використовуйте інструкцію та сигнал тощо. Ітеруйте та перевіряйте, щоб побачити, що працює. |
| Порядок має значення | Порядок, у якому ви подаєте інформацію моделі, може впливати на результат, навіть у навчальних прикладах, через ефект недавності. Спробуйте різні варіанти, щоб побачити, що працює найкраще. |
| Дайте моделі "вихід" | Надайте моделі резервну відповідь, яку вона може надати, якщо з якоїсь причини не зможе виконати завдання. Це знижує ймовірність того, що модель згенерує хибні або вигадані відповіді. |
Як і з будь-якою найкращою практикою, пам’ятайте, що ваші результати можуть відрізнятися залежно від моделі, завдання та домену. Використовуйте це як відправну точку й ітеруйте, щоб знайти те, що найкраще пасує вам. Постійно переоцінюйте процес інженерії запитів у міру появи нових моделей і інструментів, зосереджуючись на масштабованості процесу та якості відповіді.
Вітаємо! Ви дійшли до кінця уроку! Час випробувати деякі з цих концепцій і технік на реальних прикладах!
Для нашого завдання ми використовуватимемо Jupyter Notebook з вправами, які можна виконувати інтерактивно. Ви також можете розширити ноутбук власними Markdown і кодовими комірками, щоб досліджувати ідеї та техніки самостійно.
- (Рекомендовано) Запустіть GitHub Codespaces
- (Альтернативно) Клонуйте репозиторій на свій локальний пристрій і використовуйте з Docker Desktop
- (Альтернативно) Відкрийте ноутбук у бажаному середовищі виконання ноутбуків.
- Скопіюйте файл
.env.copyіз кореня репозиторію у.envта заповніть значенняAZURE_OPENAI_API_KEY,AZURE_OPENAI_ENDPOINTіAZURE_OPENAI_DEPLOYMENT. Поверніться до розділу Learning Sandbox, щоб дізнатися як.
- Виберіть ядро виконання. Якщо використовуєте варіанти 1 або 2, просто оберіть стандартне ядро Python 3.10.x, надане у контейнері розробника.
Ви готові виконувати вправи. Зверніть увагу, що тут немає правильних чи неправильних відповідей — просто дослідження варіантів методом проб і помилок та вироблення інтуїції щодо того, що працює для конкретної моделі і домену застосування.
З цієї причини у цьому уроці немає сегментів з кодом рішення. Замість цього ноутбук містить Markdown комірки з назвою "My Solution:", які демонструють один приклад відповіді для довідки.
Який із наведених запитів є хорошим відповідно до розумних найкращих практик?
- Покажи мені зображення червоного автомобіля
- Покажи мені зображення червоного автомобіля марки Volvo, моделі XC90, припаркованого біля обриву на заході сонця
- Покажи мені зображення червоного автомобіля марки Volvo, моделі XC90
Відповідь: 2, це найкращий запит, оскільки він надає деталі щодо "що саме" і уточнює (не просто автомобіль, а конкретна марка і модель), а також описує загальний антураж. 3-й варіант наступний за якістю, бо також містить багато опису.
Спробуйте застосувати техніку "сигналу" із запитом: Завершіть речення "Покажи мені зображення червоного автомобіля марки Volvo та ". Як модель відповідає, і як ви б це покращили?
Хочете дізнатися більше про різні концепції інженерії запитів? Перейдіть на сторінку продовження навчання, щоб знайти інші чудові ресурси з цієї теми.
Перейдіть до Уроку 5, де ми розглянемо розвинені техніки промптингу!
Відмова від відповідальності: Цей документ було перекладено за допомогою сервісу штучного інтелекту для перекладу Co-op Translator. Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ рідною мовою слід вважати авторитетним джерелом. Для критично важливої інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникли внаслідок використання цього перекладу.