Інтеграція OpenAI API: GPT-4o, o1, o3 — під капотом
Нещодавно на проєкті з десятками тисяч запитів на добу команда вперлася в бюджет через використання однієї моделі для всіх завдань. Після міграції на комбінацію GPT-4o, o3-mini та GPT-4o-mini вдалося знизити вартість у 3 рази без втрати якості. Розберемо, як обирати моделі, налаштовувати клієнт з ретраями та впроваджувати structured outputs. Наш досвід — 5 років у AI-інтеграціях і понад 50 завершених проєктів — дозволяє гарантувати uptime 99.9%.
Які моделі обирати і чому новачки помиляються
OpenAI пропонує сімейство моделей з різною архітектурою. GPT-4o — універсальний мультимодальний солдат: приймає текст і зображення, видає структуровані відповіді, працює швидко. Для глибоких міркувань (математичні доведення, алгоритмічний код) використовуйте o1 та o3-mini — вони витрачають більше часу на chain-of-thought. Для high-load сценаріїв з простими завданнями (наприклад, класифікація) беріть GPT-4o-mini: його latency p99 у 2 рази нижчий, а cost на токен — майже в 10 разів менше.
| Модель | Призначення | Особливості |
|---|---|---|
| GPT-4o | Універсальний чат, vision, structured outputs | Найкращий balance quality/cost, підтримка function calling |
| GPT-4o-mini | High-load, прості завдання, класифікація | Швидкий, дешевий, але слабший у міркуваннях |
| o3-mini | Глибокі міркування, код, логіка | Reasoning effort adjustable, не підтримує system prompt |
Типова помилка — використовувати єдину модель для всього. GPT-4o-mini справляється з 80% завдань, але багато хто ставить GPT-4o скрізь, переплачуючи. Нижче — порівняння для трьох типових сценаріїв.
| Сценарій | Рекомендована модель | Вигода |
|---|---|---|
| Класифікація тональності (тисячі запитів/хв) | GPT-4o-mini | Зниження cost у 8 разів проти GPT-4o |
| Генерація коду з верифікацією | o3-mini (reasoning_effort=high) | У 2 рази точніше GPT-4o на складних завданнях |
| Мультимодальний аналіз документів | GPT-4o | Єдина модель з native vision |
Як ми налаштовуємо клієнт і обробляємо помилки
Використовуємо офіційний SDK openai та Pydantic для схем. Огортаємо всі виклики в retry з exponential backoff (tenacity) — при 429 або 5xx чекаємо зі збільшеною паузою. Нижче — робочий приклад для синхронного та асинхронного режимів:
from openai import OpenAI, AsyncOpenAI from pydantic import BaseModel client = OpenAI() # Використовує OPENAI_API_KEY з env async_client = AsyncOpenAI() # Синхронний виклик з ретраєм from tenacity import retry, stop_after_attempt, wait_exponential @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=4, max=10)) def chat(prompt: str, model: str = "gpt-4o") -> str: response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=0.1, ) return response.choices[0].message.content # Структурований вивід class Extraction(BaseModel): name: str amount: float currency: str def extract_structured(text: str) -> Extraction: response = client.beta.chat.completions.parse( model="gpt-4o", messages=[{"role": "user", "content": f"Витягни дані: {text}"}], response_format=Extraction, ) return response.choices[0].message.parsed # Streaming def stream_response(prompt: str): with client.chat.completions.stream( model="gpt-4o", messages=[{"role": "user", "content": prompt}], ) as stream: for chunk in stream.text_stream: yield chunk # Vision (GPT-4o) def analyze_image(image_url: str, question: str) -> str: response = client.chat.completions.create( model="gpt-4o", messages=[{ "role": "user", "content": [ {"type": "image_url", "image_url": {"url": image_url}}, {"type": "text", "text": question} ] }] ) return response.choices[0].message.content Чому важливо структурувати відповіді?
Без схеми API повертає вільний текст — його складно парсити та валідувати. Ми використовуємо response_format з Pydantic для гарантії формату. Це скорочує час обробки на бекенді та виключає помилки парсингу. Приклад для вилучення сутностей вже показано вище.
Як працюють o1/o3 для задач міркування?
Ці моделі не підтримують system prompt, temperature (фіксовані) та streaming. Зате дозволяють налаштувати reasoning_effort (low/medium/high). Ми застосовуємо їх для вузьких задач: верифікація коду, доведення, логічні ланцюжки. Приклад:
# o1 не підтримує system prompt, temperature, streaming def reason_with_o1(problem: str) -> str: response = client.chat.completions.create( model="o3-mini", messages=[{"role": "user", "content": problem}], reasoning_effort="high", ) return response.choices[0].message.content Ембедінги та семантичний пошук
Для RAG-систем використовуємо text-embedding-3-small (1536 вимірів). Він дешевий і ефективний. Зберігаємо вектори в Qdrant або pgvector. Приклад:
def get_embeddings(texts: list[str]) -> list[list[float]]: response = client.embeddings.create( model="text-embedding-3-small", input=texts, ) return [item.embedding for item in response.data] Типові помилки при інтеграції OpenAI API
- Неправильна обробка rate limits: без retry exponential backoff клієнт падає при 429.
- Відсутність моніторингу токенів — неочікувані рахунки.
- Використання system prompt для o1/o3 — модель його ігнорує.
- Зберігання ембедінгів у неоптимальній БД — високий latency пошуку.
Що входить у роботу під ключ
- Налаштування клієнта з ретраями, логуванням та моніторингом (включаючи алерти по latency p99).
- Вибір оптимальної моделі під кожне завдання (вартість/якість).
- Впровадження structured outputs з Pydantic.
- Інтеграція ембедінгів та векторної БД (RAG).
- Документація по API та навчання команди.
- Гарантія uptime 99.9% (наша відповідальність). Понад 50 проєктів за 5 років — статистика, якій можна довіряти.
Строки та як почати
- Базова інтеграція chat completions: 0.5–1 день.
- Structured outputs + інструменти: 2–3 дні.
- Retry logic + cost management: 1–2 дні.
- Повний RAG-пайплайн: до 5 днів.
Зв'яжіться з нами — оцінимо ваш проєкт за 1 годину. Ми гарантуємо прозорий код і повну документацію. Отримайте консультацію прямо зараз.
—
[Детальніше про chain-of-thought](https://en.wikipedia.org/wiki/Chain-of-thought_prompting) та Official OpenAI API docs.)