Как устроен запрос к модели
ИИ для разработчиков: API и агенты · Урок 1 / 20
Как устроен запрос к модели
С точки зрения кода LLM API — это обычный HTTP-эндпоинт: вы отправляете JSON, получаете JSON. Никакой магии. Но у этого запроса есть особенности, от которых зависит и качество ответа, и ваш счёт в конце месяца.
Минимальный запрос
POST https://api.openai.com/v1/chat/completions
Authorization: Bearer $OPENAI_API_KEY
Content-Type: application/json
{
"model": "gpt-4o-mini",
"messages": [
{ "role": "system", "content": "You are a terse assistant." },
{ "role": "user", "content": "Explain HTTP 429 in one sentence." }
],
"temperature": 0.2
}
Три роли и зачем они нужны
- system — правила поведения на весь диалог: тон, формат, ограничения. Модель относится к нему как к приоритетной инструкции.
- user — запрос пользователя.
- assistant — предыдущие ответы модели. Вы передаёте их обратно, чтобы модель «помнила» диалог.
Ключевой момент, который ломает голову новичкам: API не хранит состояние. Каждый запрос независим. «Память» диалога — это просто массив messages, который вы отправляете целиком каждый раз. Отсюда и рост стоимости в длинных диалогах.
Структура ответа
{
"id": "chatcmpl-...",
"choices": [{
"message": { "role": "assistant", "content": "429 means rate limited." },
"finish_reason": "stop"
}],
"usage": { "prompt_tokens": 28, "completion_tokens": 9, "total_tokens": 37 }
}
Два поля, которые нужно читать всегда, а не только при отладке:
- finish_reason —
stop(нормально),length(упёрлись в max_tokens — ответ обрезан!),tool_calls(модель хочет вызвать инструмент),content_filter. - usage — реальный расход токенов. Логируйте его с первого дня, иначе счёт станет сюрпризом.
Параметры, которые реально влияют
- temperature (0–2). 0–0.3 — извлечение данных, классификация, код. 0.7–1.0 — тексты и идеи. Для продакшн-логики держите низкой: воспроизводимость важнее «креативности».
- max_tokens — потолок ответа. Ставьте всегда: защищает от неожиданно длинной генерации и от счёта.
- top_p — альтернатива temperature. Меняйте что-то одно, не оба сразу.
- seed (где поддерживается) — повышает воспроизводимость, но не гарантирует её.
Инсайт. Проверяйте
finish_reason === "length" в каждом ответе. Молча обрезанный JSON — самая частая причина «модель вернула невалидный ответ».Частая ошибка. Класть API-ключ в клиентский код. Ключ — только на сервере, запросы к модели проксируйте через свой бэкенд.
Про-совет. Пишите
usage в логи вместе с идентификатором запроса и версией промпта. Через месяц это единственный способ понять, что именно съедает бюджет.Шпаргалка
- API без состояния: контекст = массив messages целиком.
- Роли: system (правила), user, assistant (история).
- Всегда читайте finish_reason и usage.
- temperature низкая для логики, max_tokens задавайте всегда.
1. Как модель «помнит» предыдущие сообщения?
2. Что означает finish_reason = length?
3. Какую temperature брать для извлечения данных?