Анатомия промпта: от заклинаний к коду

Коллеги, давайте договоримся на берегу: LLM (Large Language Model) — это не «интеллект» и не «магия». Это вероятностный генератор токенов. Когда вы пишете «пожалуйста, напиши код», вы тратите токены впустую.

В инженерном подходе промпт — это код. У него есть синтаксис, переменные и ожидаемый формат вывода (Output Signature). Если вы не контролируете вход и выход, вы строите систему на генераторе случайных чисел.

1. Архитектура запроса: System, User, Assistant

Любой современный API (OpenAI, Anthropic, Llama via vLLM) принимает не строку, а массив объектов. Игнорирование ролей — главная ошибка новичков.

• System: Мета-инструкция. Здесь живут «законы физики» для модели. Она задает формат вывода, ограничения и тон.

• User: Входные данные (Payload).

• Assistant: История диалога или (внимание!) One-shot примеры.

Плохой паттерн (все в одной куче):

Переведи этот текст в JSON, выдели имя и email. Текст: "Привет, я Иван..."

Инженерный паттерн (разделение контекста):

messages = [
    {"role": "system", "content": "Ты — парсер логов. Твоя задача — извлекать сущности в формате JSON. Не пиши пояснений."},
    {"role": "user", "content": "Ошибка 500 на сервере auth-service, user_id: 12345"},
    # Few-shot learning через имитацию ответа ассистента:
    {"role": "assistant", "content": "{\"service\": \"auth-service\", \"error\": 500, \"uid\": 12345}"},
    {"role": "user", "content": "Timeout error at payment-gateway, user_id: 99999"} 
]

2. Паттерны проектирования промптов

Few-Shot (Обучение на примерах)

Zero-shot (промпт без примеров) работает нестабильно. Модели лучше понимают паттерн, чем инструкцию. Если вам нужен специфический SQL-запрос — покажите модели 3 примера «Вход -> Выход».

Chain-of-Thought (Цепочка рассуждений)

Если заставить модель сразу выдать ответ, она часто галлюцинирует в логике. Если заставить её «подумать вслух», точность растет. Хак: Добавьте в системный промпт: Think step-by-step before outputting JSON.

Пример:

Запрос: Есть ли в логах критическая ошибка? Без CoT: "Да." (Может соврать). С CoT: "1. Анализирую таймстемп... 2. Вижу статус 500... 3. Это критично. Ответ: Да."

3. Спецификации вывода: Строгий JSON

Вашему бэкенду не нужен текст «Конечно, вот ваш JSON...». Вам нужен чистый объект для JSON.parse().

Техника 1: JSON Mode Большинство API имеют флаг response_format={"type": "json_object"}. Но этого мало.

Техника 2: TypeScript Definition Лучший способ описать схему данных для модели — дать ей интерфейс TypeScript. LLM видели гигабайты кода и отлично понимают типизацию.

system_prompt = """
Ты — API-интерфейс. Ты принимаешь текст тикета и возвращаешь JSON строго по схеме:

interface TicketAnalysis {
  priority: 'LOW' | 'HIGH' | 'CRITICAL';
  tags: string[];
  summary: string; // макс 50 символов
  assignee?: string; // null, если не понятно кому назначить
}
"""

Задание

Напишите скрипт (на Python или псевдокоде), который:

1. Имеет системный промпт с описанием TypeScript-интерфейса для извлечения данных из git commit message (нужно достать тип коммита: fix/feat, ID задачи и описание).

2. Использует технику Few-shot (минимум 2 примера внутри истории сообщений).

3. Принимает на вход «грязный» коммит (например: "fixed bug in auth logic JIRA-123") и выдает чистый JSON.

Краткие итоги

1. Промпт — это структура, а не текст. Используйте массив сообщений с ролями.

2. Примеры сильнее инструкций. Few-shot learning повышает стабильность вывода на 30-40%.

3. Типизируйте вывод. Скармливайте модели схемы данных (JSON Schema или TS Interface), чтобы не писать потом сложные регулярки для парсинга ответов.