Анти-патерн Giant System Prompt: гігантський системний промпт

Ідея за 30 секунд

Giant System Prompt — це анти-патерн, коли майже всю логіку агента намагаються вкласти в один великий системний prompt.

У результаті інструкції починають конфліктувати, пріоритети стають неочевидними, а поведінка моделі — нестабільною. Це підвищує latency, вартість і ризик регресій після дрібних правок.

Просте правило: системний prompt має бути коротким і стабільним, а змінну логіку краще виносити в маршрутні блоки, policy-шари і валідацію в коді. Системний prompt має задавати роль і базові правила, але не містити всю бізнес-логіку системи.

Приклад анти-патерну

Команда будує агента підтримки і поступово додає нові правила просто в один системний prompt.

З часом цей prompt перетворюється на гігантський блок інструкцій для всіх сценаріїв одразу.

SYSTEM_PROMPT = """
You are support agent.
- Always be brief.
- Always provide detailed step-by-step explanation.
- Never call tools unless user asks.
- For payment issues always call get_payment_status.
- Reply only in strict JSON.
- Prefer natural text if JSON looks unnatural.
... hundreds of lines ...
"""

response = agent.run(
    system_prompt=SYSTEM_PROMPT,
    user_message=user_message,
)

У такій схемі модель бачить забагато інструкцій із різними пріоритетами:

always_be_brief + give_step_by_step_explanation
json_only + prefer_natural_text
never_call_tools + always_call_payment_tool

Для цього кейсу краще мати короткий базовий prompt і окремі route-specific блоки:

system_prompt = BASE_PROMPT + ROUTE_PROMPTS[route]

У цьому випадку giant prompt додає:

• конфлікти між правилами
• складну підтримку після змін
• нестабільний формат і тон відповіді

Чому виникає і що йде не так

Цей анти-патерн часто з’являється, коли команда хоче "швидко вирішити все промптом" без чіткої межі між інструкціями, policy і runtime-логікою.

Типові причини:

• кожен новий інцидент "лікують" ще одним рядком у system prompt
• немає модульності: один prompt для всіх маршрутів
• policy-правила живуть у тексті prompt, а не в коді
• відсутні чіткі власники і версійність prompt-блоків

У результаті виникають проблеми:

• конфлікт інструкцій — у prompt одночасно є суперечливі правила
• нестабільна поведінка — однаковий запит може давати різний стиль і формат
• вища latency і вартість — довгий prompt збільшує токени на кожен запуск
• крихкість змін — невелика правка може ламати інші сценарії
• складний дебаг — важко зрозуміти, яке саме правило спрацювало

Типові production-сигнали, що system prompt уже занадто великий:

• одна зміна правила викликає регресію в іншому маршруті
• cost per request росте через довгий незмінний prompt
• команда не може швидко пояснити пріоритет між двома конфліктними інструкціями
• після дрібної правки prompt падає success rate на частині кейсів

Вибір інструмента, формату і стилю — це частина LLM inference. Коли в prompt забагато різнорідних інструкцій, зростає кількість можливих інтерпретацій, і модель частіше обирає правило, яке формально підходить, але не є найкращим для цього маршруту.

Коли така схема розростається, без trace і візуалізації виконання важко зрозуміти, який саме prompt-блок був використаний у конкретному запуску і яке правило вплинуло на поведінку моделі.

Правильний підхід

Починайте з короткого стабільного system prompt, який задає роль і базові правила. Змінну логіку виносьте в маршрутні блоки, policy-гейти і перевірку output у коді.

Практична рамка:

• тримайте маленький BASE_PROMPT для спільних правил
• додавайте ROUTE_PROMPTS тільки для конкретного типу задач
• policy і обмеження реалізуйте в коді, а не в гігантському тексті
• перевіряйте output і міряйте ефект змін (наприклад, покращення success rate без різкого росту latency і cost per request)

Наприклад, формат відповіді краще перевіряти через schema validation перед поверненням результату.

BASE_PROMPT = """
You are a support agent.
Follow safety and output rules.
"""  # stable instructions shared across all routes

ROUTE_PROMPTS = {
    "payment": "Use payment policy. Return strict JSON.",
    "refund": "Use refund policy. Ask clarifying question if needed.",
}

def run_support_agent(user_message: str):
    route = classify_intent(user_message)  # simple classifier or rules
    system_prompt = BASE_PROMPT + "\n\n" + ROUTE_PROMPTS[route]

    response = agent.run(
        system_prompt=system_prompt,
        user_message=user_message,
    )

    if not validate_output(response):  # schema / required fields / safety checks
        return stop("invalid_output")

    return response

У такій схемі правила стають прозорішими: легше оновлювати конкретний маршрут і менше шансів зламати сусідні сценарії.

Швидкий тест

Якщо на ці питання відповідь "так", у вас є ризик giant-system-prompt:

• Чи один system prompt намагається покрити майже всі сценарії одразу?
• Чи дрібна правка в prompt часто дає побічні регресії в інших кейсах?
• Чи важко визначити, яке саме правило має вищий пріоритет у конфлікті?

Чим відрізняється від інших анти-патернів

Overengineering Agents vs Giant System Prompt

Too Many Tools vs Giant System Prompt

Agents Without Guardrails vs Giant System Prompt

Самоперевірка: чи немає у вас цього анти-патерну

Швидка перевірка на anti-pattern Giant System Prompt.
Відмічайте пункти під вашу систему і дивіться статус нижче.

Перевірте свою систему:

FAQ

Q: Довгий system prompt — це завжди погано?
A: Ні. Проблема не в довжині сама по собі, а в монолітності й конфліктах. Якщо prompt росте, але залишається модульним і зрозумілим за пріоритетами, ризики значно нижчі.

Q: Коли варто виносити правило з prompt у код?
A: Коли правило критичне для безпеки, витрат або стабільності формату. Такі обмеження краще реалізовувати як явні runtime-перевірки, а не як текстову інструкцію.

Q: Як перейти від giant prompt до модульної схеми без великого рефакторингу?
A: Почніть із малого: виділіть BASE_PROMPT, додайте 1-2 route-specific блоки для найчастіших кейсів і поступово переносіть policy-правила з prompt у кодові гейти.

Що далі

Схожі anti-patterns:

• Overengineering Agents — коли складність росте швидше, ніж користь.
• Too Many Tools — коли шум у виборі інструментів робить поведінку нестабільною.
• Agent Everywhere Problem — коли агент застосовується навіть для детермінованих задач.

Що будувати замість цього:

• Allowed Actions — як фіксувати межі дій агента в коді.
• Routing Agent — як розділяти маршрути й давати релевантні інструкції.
• Policy Boundaries in Architecture — як винести policy з prompt у явні архітектурні межі.