Печалби:
- Може да проектира как системната подкана води модела през целия разговор
- Разбира ролята и въздействието върху цената на адаптивното мислене и параметрите на усилията
- прилага изходни контроли като 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": "низ", "преброяване": ["ниско", "средно", "високо"] } }, "задължително": ["категория", "спешност"] } } }}
Копируеми шаблони за системни подкани
# Асистент за корпоративна поддръжка Вие сте асистент за корпоративна поддръжка.- Разчитайте единствено на предоставения документ за политика; Ако не е в документа, кажете „Нямам тази информация“. - Дайте формален и ясен отговор в максимум 3 изречения. - Поискайте лични данни (TC ID номер, номер на карта) и не ги повтаряйте в отговора си. - Ако не сте сигурни, не предполагайте.
# Класификатор за налагане на структуриран изход Вие сте класификатор на търсенето. Входът е клиентско съобщение. Върнете само заявените полета, не пишете коментари. Ако не сте сигурни, използвайте „друго“.
# Анализатор с дефинирано поведение на стоене в несигурност Вие сте анализатор на данни. Направете само проверими изводи от предоставената таблица. Никога не правете заключение, което не съществува в данните. Ако изводът е неясен, напишете „недостатъчни данни“.
# Писател на съдържание с контрол на тона и дължината Вие сте писател на съдържание. Използвайте топъл, но професионален тон. Ограничете всеки текст до 120 думи или по-малко. Избягвайте маркетинговия език като клише.
Слаба подкана / Силна подкана
# СЛАБ Бъдете полезни и давайте добри отговори. Дайте всичко от себе си.
# СИЛНА Роля: Специалист по техническа поддръжка. Обхват: Предоставено само продуктово ръководство. Формат: Стъпка по стъпка, номериран списък, максимум 5 стъпки. Ограничение: Препоръчайте решение, което не е в ръководството; Кажете "Не можах да го намеря в ръководството." Поверителност: Не повтаряйте серийния номер, споделен от потребителя в отговора.
Мощна версия; Той определя отделно ролята, обхвата, формата, границите и поверителността. Последователността на изхода идва директно от тази яснота.
Три мини калъфа
Случай 1 — Намаляване на разходите чрез коригиране на усилията. Един екип изпълняваше всичките си разговори с големи усилия + мислене; Дори обикновените обобщени имейли бяха скъпи и бавни за производство. Те възложиха прости задачи като обобщения на минимални усилия и анализ на договори на големи усилия. Точността беше запазена, средното забавяне беше намалено наполовина, а месечните разходи бяха намалени с една трета.
Случай 2 — JSON гаранция. Оперативен екип поиска резултата от класификацията с подкана, казваща „просто дайте JSON“, но моделът понякога пишеше „Ето резултата:“ и анализаторът се сриваше. Когато свързах конфигурираната изходна схема, изходът връщаше валиден JSON всеки път; грешките при синтактичния анализ са нулирани.
Случай 3 — Агресивен незабавен откат. Подкана от асистент каза: „ТРЯБВА да търсите ВСЕКИ ВЪПРОС“; Моделът направи ненужни търсения дори на прости въпроси, на които вече знаеше отговора, забавяйки и увеличавайки разходите. Те смекчиха правилото до „Ако отговорът не е в контекста, потърсете“; Ненужните обаждания намаляха със 70% и отговорите се ускориха.
Често срещани грешки
- Вграждане на променливи данни в системния ред: Нарушава последователността и прави кеша невалиден.
- Твърде агресивни инструкции: Прекомерно задействане и ненужни разходи при съвременните модели.
- Голямо усилие във всяка задача: Разхищение при прости задачи; съобразете усилията със задачата.
- Изискване на JSON само чрез подкана: прекъсва се от време на време; ако е критично, използвайте структуриран изход.
- Без дефиниране на граница/поведение при неяснота: Моделът запълва празнината с измислици (халюцинации).
- Стар "температурен" навик: Съвременните модели не приемат това; Ръководете поведението с бързина и усилия.
По-дълбоко: Написване на подканата като договор
Опитните екипи третират подканата на системата като договор, а не като литературен текст: ясни клаузи, измерими правила, недвусмислени граници. Този подход има три конкретни предимства. Първият е последователност: един и същ вход дава подобен изход в различно време. Второто е възможността за тестване: можете да тествате всеки артикул поотделно с проба. Трето е лесната поддръжка: ако дадено поведение не е наред, вие знаете кой елемент да смените.
Добра практика е да водите с положителни примери. Вместо да предоставите списък с „не правете това“, е много по-ефективно в съвременните модели да предоставите пример, който казва „точно така изглежда желаният резултат“. Например, в класификатор, добавянето на една или две проби от очаквания JSON към подканата значително намалява грешките при форматиране.
Друга мощна техника е да напишете изрично поведението при несигурност. Клауза като „Ако не сте сигурни, не гадайте; кажете „недостатъчно данни““ потиска тенденцията на модела да запълва празното място с измислици (халюцинации). Това единствено изречение разтоварва верификационния слой, който ще разгледаме в раздел 11: след като моделът вече е маркирал несигурност, става по-лесно да се доведе до валидиране от хора.
И накрая, обмислете усилията и подканата заедно. При големи усилия моделът изследва повече и понякога извършва нежелана „допълнителна работа“ (ненужно обяснение, допълнително предложение). Казването „дайте само желания резултат, не добавяйте допълнителни коментари“ в подканата компенсира този страничен ефект от големи усилия.
В обобщение
Системната подкана е постоянната директива на модела: тя определя ролята, обхвата, формата, поведението при неизвестност и поверителността. В съвременните модели поведението се ръководи от адаптивното мислене и параметрите на усилието, а не от температурата; Съгласуването на усилията със задачата управлява качеството и разходите едновременно. Защитавате изхода с max_tokens, стоп масиви и структуриран изход.
Задача за приложение
Изберете задача. (1) Напишете системна подкана с пет компонента (роля, обхват, формат, неяснота, поверителност). (2) Посочете какво ниво на усилие бихте избрали за тази задача и защо. (3) Ако изходът трябва да бъде структуриран, начертайте малка JSON схема. (4) Проверете дали има прекалено агресивен модел във вашата подкана и го смекчете.
контролен списък
- [ ] Мога да назова пет компонента на добрата системна подкана.
- [ ] Мога да обясня какво правят параметрите на адаптивното мислене и усилията.
- [ ] Мога да балансирам качество/цена, като коригирам усилията според задачата.
- [ ] Знам защо структурираният изход е по-безопасен от искането на JSON чрез подкана.
- [ ] Мога да разпозная риска в модерните модели на прекалено агресивни инструкции.