Как устроен запрос к модели

ИИ для разработчиков: 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_reasonstop (нормально), 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 брать для извлечения данных?

🔒 Ответьте на вопрос верно, чтобы перейти к следующему уроку.

Как устроен запрос к модели — ИИ для разработчиков: API и агенты — Skilvy