Прибуток:
- Може спроектувати, як системна підказка веде модель через усю розмову
- Розуміє роль і вплив на вартість адаптивного мислення та параметрів зусиль
- реалізує елементи керування виведенням, такі як max_tokens, зупинкові послідовності та структурований вивід
Два різних вироби однієї моделі можуть поводитися абсолютно по-різному. Різниця не в самій моделі, а в системній підказці та наданих їй параметрах. Системна підказка — це «робочий контракт» моделі, а параметри — «робочі налаштування». У цьому розділі ви дізнаєтеся, як розробити потужну системну підказку, що роблять налаштування мислення та зусиль у сучасних моделях, і як контролювати вихід для формату/довжини. Правильне налаштування цих налаштувань дозволяє одночасно керувати якістю, так і вартістю.
Системна підказка: постійна директива моделі
Системна підказка – це інструкція високого рівня, яка застосовується протягом усієї розмови. Ці правила залишаються дійсними незалежно від того, що вводить користувач. Хороша системна підказка включає такі компоненти:
- Роль/ідентичність: хто є моделлю? («Ви помічник корпоративної підтримки»)
- Сфера дії та межі: що він робить і чого не робить? («Лише на основі наданого документу політики»)
- Правила форматування: як має виглядати вихід? («Максимум 3 статті, офіційна мова.»)
- Поведінка в умовах невизначеності: що робити, коли не впевнений? («Якщо інформації немає, доведіть її, скеруйте до відповідного підрозділу»).
- Безпека/конфіденційність: що не хоче/не хоче? («Запит персональних даних»)
Порада: не змінюйте системне повідомлення. Не вставляйте інформацію, яка змінюється з кожним запитом (поточна дата, ім’я користувача, ідентифікатор сеансу). Це одночасно порушує узгодженість і робить недійсним кеш запитів на блоці 6. Розмістіть інформацію про змінну в повідомленні користувача.
Надмірно агресивна інструкційна пастка
Сучасні моделі дуже чітко дотримуються інструкції. Агресивні фрази на кшталт «ПОТРІБНО», «ЗАВЖДИ», «ОБОВ’ЯЗКОВО зробіть це» тощо, які працювали в старих моделях, сьогодні призводять до надмірного запуску: модель викликає агента, коли він не потрібен, або працює невиправдано довго. Пом’якшіть правило: замість «ОБОВ’ЯЗКОВО використовуйте інструмент пошуку» точнішим буде «Якщо відповіді немає в бесіді, використовуйте інструмент пошуку».
Параметри моделі: думка і зусилля
Класичні LLM мали температурний параметр: нижче значення створювало більш конкретний/послідовний результат, вищий – більш різноманітний/творчий результат. Сучасні моделі покоління (такі як Opus 4.8, Sonnet 5) замінюють цей підхід двома більш потужними механізмами та більше не приймають такі параметри вибірки, як температура.
- Адаптивне мислення: модель міркує крок за кроком у своїй «голові», перш ніж відповісти. Модель вирішує, скільки думати, виходячи зі складності завдання. Значно підвищує точність складних багатокрокових задач; Він менше думає, щоб уникнути непотрібних затримок на прості питання.
- Зусилля: ручка високого рівня, яка регулює, наскільки глибоко модель занурюється в завдання та скільки жетонів вона витрачає загалом. Типові рівні: низький, середній, високий і вище. Значні зусилля можуть покращити якість, але це також збільшує затримку та вартість; Невеликі зусилля забезпечують швидкість і економію.
Налаштування
Що робить
коли
Роздуми без зусиль
Швидко, дешево, поверхово
Проста класифікація, коротка відповідь, затримка чутливих завдань
Адаптивне мислення + середні зусилля
Збалансована якість/вартість
Більшість завдань загального призначення
Адаптивне мислення + великі зусилля
найвища точність
Складне міркування, кодування, довгострокова агентська робота
Увага: рефлекс «максимум зусиль, незважаючи ні на що» збільшує витрати. Пристосовуйте зусилля до завдання; У простих завданнях невеликі зусилля часто дають такий же точний результат за набагато меншу ціну. Підніміться високо там, де потрібна критична точність.
Контроль виведення: формат, довжина, структура
Окрім параметрів, ви також контролюєте сам вихід:
- max_tokens: Жорстка стеля виходу (1-й і 3-й блоки).
- Зупинка послідовностей: зупинка моделі, коли вона бачить певний рядок. Корисно для встановлення контрольних точок у структурованому виробництві.
- Структурований вихід: примусово відповідайте відповіді моделі наданій вами схемі JSON. Це гарантує, що вихідні дані піддаються програмному аналізу та є дійсними. Це надійніше, ніж сказати "просто поверніть JSON" із запитом.
{ "output_config": { "format": { "type": "json_schema", "schema": { "type": "object", "additionalProperties": false, "properties": { "category": { "type": "string", "enum": ["invoice", "technical", "return", "other"] }, "urency": { "type": "рядок", "enum": ["низький", "середній", "високий"] } }, "потрібний": ["категорія", "терміновість"] } } }}
Шаблони системних підказок, які можна копіювати
# Помічник корпоративної підтримки Ви помічник корпоративної підтримки.- Покладайтеся виключно на наданий документ політики; Якщо її немає в документі, скажіть «У мене немає цієї інформації». - Дайте формальну та чітку відповідь максимум 3 реченнями. - Запитуйте персональні дані (номер ТК, номер картки) і не повторюйте їх у відповіді. - Якщо ви не впевнені, не вгадуйте.
# Класифікатор структурованого виводу Ви класифікатор попиту. Введенням є повідомлення клієнта. Повернути тільки запитані поля, не писати коментарі. Якщо ви не впевнені, використовуйте «інше».
# Аналітик із визначеною поведінкою в умовах невизначеності. Ви аналітик даних. З наданої таблиці робіть лише висновки, які можна перевірити. Ніколи не робіть висновків, яких немає в даних. Якщо висновок незрозумілий, напишіть «недостатньо даних».
# Автор контенту з контролем тону та довжини. Ви автор контенту. Використовуйте теплий, але професійний тон. Обмежте кожен текст до 120 слів або менше. Уникайте маркетингових шаблонів.
Слабка підказка / Сильна підказка
# СЛАБКИЙ Будьте корисними та давайте хороші відповіді. Зробіть все можливе.
# STRONGРоль: фахівець з технічної підтримки. Обсяг: надається лише посібник із продукту. Формат: крок за кроком, нумерований список, максимум 5 кроків. Обмеження: Рекомендувати рішення, якого немає в посібнику; Скажіть «Я не зміг знайти це в посібнику». Конфіденційність: не повторюйте серійний номер, наданий користувачем у відповіді.
Потужна версія; Окремо визначає роль, обсяг, формат, межі та конфіденційність. Узгодженість результатів випливає безпосередньо з цієї ясності.
Три міні-чохли
Випадок 1 — Зменшення витрат шляхом коригування зусиль. Одна команда проводила всі свої дзвінки з великим зусиллям + мисленням; Навіть прості дайджести електронної пошти були дорогими та повільними у створенні. Вони призначали прості завдання, такі як підсумки, для невеликих зусиль і аналіз контрактів для великих зусиль. Точність була збережена, середня затримка зменшилася вдвічі, а місячні витрати зменшилися на третину.
Випадок 2 — гарантія JSON. Оперативна група запитувала вихідні дані класифікації з підказкою «просто надайте JSON», але модель час від часу писала «Ось результат:», і синтаксичний аналізатор аварійно завершував роботу. Коли я підключав налаштовану схему виводу, вихід кожного разу повертав дійсний JSON; помилки аналізу скинуто.
Випадок 3 — Агресивна швидка віддача. Підказка помічника сказала: «ПОТРІБНО шукати КОЖНЕ ПИТАННЯ»; Модель зробила непотрібні пошуки навіть для простих запитань, на які вона вже знала відповідь, сповільнюючи та збільшуючи витрати. Вони послабили правило: «Якщо відповідь не в контексті, шукайте»; Кількість непотрібних дзвінків зменшилася на 70%, а відповіді прискорилися.
Поширені помилки
- Вбудовування змінних даних у системну підказку: порушує узгодженість і робить кеш недійсним.
- Надто агресивна інструкція: надмірне спрацьовування та непотрібна вартість у сучасних моделях.
- Значні зусилля в кожному завданні: марнотратство в простих завданнях; пристосувати зусилля до завдання.
- Запит JSON лише через підказку: час від часу він ламається; якщо критично, використовуйте структурований вихід.
- Поведінка без визначення межі/неоднозначності: модель заповнює прогалину вигадкою (галюцинацією).
- Стара «температурна» звичка: сучасні моделі цього не сприймають; Скеровуйте поведінку швидко та зусиль.
Глибше: написання підказки як контракт
Досвідчені команди сприймають системну підказку як договір, а не літературний текст: чіткі пункти, вимірювані правила, однозначні межі. Цей підхід має три конкретні переваги. По-перше, це узгодженість: той самий вхід дає подібний вихід у різний час. По-друге, це можливість тестування: ви можете перевірити кожен елемент окремо за зразком. По-третє, це простота обслуговування: якщо поведінка неправильна, ви знаєте, який елемент замінити.
Хороша практика – показувати позитивні приклади. Замість того, щоб надавати список «не робіть цього», набагато ефективніше в сучасних моделях надати приклад, який говорить «саме так виглядає бажаний результат». Наприклад, у класифікаторі додавання одного або двох зразків очікуваного JSON до підказки значно зменшує помилки форматування.
Інший потужний прийом полягає в тому, щоб явно записати поведінку невизначеності. Речення на кшталт «Якщо не впевнені, не вгадуйте; скажіть «недостатньо даних»» пригнічує тенденцію моделі заповнювати прогалини вигадками (галюцинаціями). Це єдине речення розвантажує рівень перевірки, який ми розглянемо в блоці 11: якщо модель вже позначила невизначеність, стає легше привести до перевірки людиною.
Нарешті, подумайте разом про зусилля та підказку. При великих зусиллях модель досліджує більше і іноді виконує небажану «додаткову роботу» (непотрібні пояснення, додаткові пропозиції). Поява «лише бажаного результату, не додавання додаткових коментарів» у підказці компенсує цей побічний ефект великих зусиль.
Підсумовуючи
Системна підказка є постійною директивою моделі: вона визначає роль, область, формат, поведінку невідомості та конфіденційність. У сучасних моделях поведінка визначається адаптивним мисленням і параметрами зусиль, а не температурою; Узгодження зусиль із завданням забезпечує водночас управління якістю та вартістю. Ви захищаєте вивід за допомогою max_tokens, стоп-масивів і структурованого виводу.
Аплікаційне завдання
Виберіть завдання. (1) Напишіть системну підказку з п’ятьма компонентами (роль, обсяг, формат, неоднозначність, конфіденційність). (2) Вкажіть, який рівень зусиль ви б вибрали для цього завдання і чому. (3) Якщо вихідні дані мають бути структурованими, намалюйте невелику схему JSON. (4) Перевірте, чи немає у вашій підказці надто агресивного шаблону, і пом’якшіть його.
контрольний список
- [ ] Я можу назвати п’ять компонентів хорошої системної підказки.
- [ ] Я можу пояснити, що роблять параметри адаптивного мислення та зусилля.
- [ ] Я можу збалансувати якість/вартість, регулюючи зусилля відповідно до завдання.
- [ ] Я знаю, чому структурований вихід безпечніший, ніж запит JSON через підказку.
- [ ] Я розумію ризик у надто агресивних інструкціях сучасних моделей.