Jak zbudować chatbota za pomocą ChatGPT API

Jak zbudować chatbota za pomocą ChatGPT API? Responses API, FastAPI

Ostatnia aktualizacja: 27 kwietnia 2026 r.

ChatGPT API to potoczna nazwa integracji z modelami OpenAI. Oficjalnie, dla nowych projektów najlepiej myśleć o OpenAI API, a szczególnie o Responses API, czyli aktualnym interfejsie do generowania odpowiedzi, obsługi narzędzi, pracy z kontekstem, modeli rozumujących i agentowych workflow. Ten poradnik pokazuje, jak zbudować własnego chatbota po polsku: od architektury, przez backend w FastAPI, po frontend, bezpieczeństwo, koszty, moderację i wdrożenie.

Artykuł został napisany tak, aby był praktyczny dla deweloperów, ale jednocześnie spójny z serwisem Czat GPT po polsku. Czat GPT to niezależny polski serwis umożliwiający rozmowę z asystentem AI po polsku. Ten tekst nie opisuje prywatnego API serwisu Czat GPT i nie twierdzi, że Czat GPT jest oficjalnym produktem OpenAI. Jeśli chcesz po prostu porozmawiać z AI bez konfiguracji technicznej, przejdź na stronę główną Czat GPT. Jeśli chcesz zbudować własną aplikację, korzystasz bezpośrednio z oficjalnego OpenAI API.

Najważniejsza aktualizacja 2026: GPT-5.5 i GPT-5.5 Pro są już dostępne w OpenAI API. Dla nowych projektów OpenAI rekomenduje Responses API, a nie stare przykłady oparte wyłącznie o openai.ChatCompletion.create() i gpt-3.5-turbo. W tym poradniku pokazujemy nowy styl pracy: client.responses.create(), bezpieczny backend, limity, moderację i dobór modeli.

Spis treści:

Co zmieniło się w budowie chatbotów w 2026 roku?

Największa zmiana jest prosta: tutoriale z endpointem /v1/chat/completions, modelem gpt-3.5-turbo i metodą openai.ChatCompletion.create() nie są już najlepszym wzorcem dla nowego projektu. Chat Completions nadal może być wspierane, ale dla nowych integracji OpenAI rekomenduje Responses API. Responses API daje jeden, spójniejszy interfejs do zwykłej generacji tekstu, modeli rozumujących, multimodalnego wejścia, narzędzi, wyszukiwania, obsługi stanu i bardziej agentowych scenariuszy.

W praktyce oznacza to pięć decyzji projektowych:

  • Używaj Responses API jako domyślnego interfejsu do nowych chatbotów.
  • Nie wkładaj klucza API do frontendu. Klucz OpenAI API powinien znajdować się wyłącznie po stronie serwera albo w zaufanym środowisku.
  • Dobieraj model do zadania. Nie każde pytanie wymaga najdroższego modelu. Prosty chatbot może zaczynać od tańszego modelu, a trudniejsze zadania routować do GPT-5.5.
  • Projektuj limity od pierwszego dnia. Rate limiting, budżety i alerty kosztowe są równie ważne jak sam kod generujący odpowiedź.
  • Informuj użytkownika o ograniczeniach AI. Chatbot może popełniać błędy, dlatego odpowiedzi dotyczące prawa, zdrowia, finansów i aktualnych faktów wymagają weryfikacji.

Jaki model wybrać do chatbota?

Dobór modelu to decyzja produktowa, techniczna i kosztowa. Oficjalna dokumentacja OpenAI wskazuje gpt-5.5 jako model frontier do złożonego rozumowania i kodowania, a mniejsze modele, takie jak gpt-5.4-mini i gpt-5.4-nano, jako opcje dla niższej latencji i niższego kosztu. Dlatego w tym poradniku przyjmujemy praktyczną strategię: start od gpt-5.4-mini dla prostego MVP, a dla trudniejszych zadań przełączenie na gpt-5.5.

SytuacjaModel startowyDlaczego
Prosty chatbot po polsku do FAQ, krótkich odpowiedzi i generowania tekstu.gpt-5.4-miniNiższy koszt i dobra jakość dla codziennych zapytań.
Chatbot techniczny, analiza dokumentów, kodowanie, wieloetapowe instrukcje.gpt-5.5Oficjalny model frontier do złożonej pracy, kodowania i profesjonalnych zadań.
Najtrudniejsze analizy, długi workflow, wysoka dokładność ważniejsza niż koszt.gpt-5.5-proNajmocniejszy wariant, ale droższy i potencjalnie wolniejszy.
Klasyfikacja intencji, tagowanie, routing do działu obsługi.gpt-5.4-nanoNiski koszt przy dużym wolumenie prostych operacji.

Nie zaczynaj od najdroższego modelu tylko dlatego, że jest najmocniejszy. Najpierw przygotuj listę typowych pytań użytkowników, zmierz jakość odpowiedzi, koszt i czas reakcji. Dopiero później zdecyduj, które zapytania powinny trafiać do mocniejszego modelu.

Aktualne ceny API, które warto znać

Poniższa tabela ma charakter praktycznego punktu odniesienia na dzień 27 kwietnia 2026 r. Ceny OpenAI mogą się zmieniać, a tryby Batch, Flex, Priority, długi kontekst, narzędzia i regionalne przetwarzanie danych mogą być rozliczane inaczej. Przed wdrożeniem produkcyjnym zawsze sprawdź oficjalny cennik OpenAI.

ModelNajlepsze zastosowanieCena standardowa — short contextUwagi
gpt-5.5Złożone rozumowanie, kodowanie, research, praca profesjonalna, trudniejsze chatboty.$5.00 input / $0.50 cached input / $30.00 output za 1M tokenów.Dla wejścia powyżej 272K tokenów obowiązuje wyższa cena long context: $10 input / $1 cached / $45 output.
gpt-5.5-proNajtrudniejsze zadania, gdy ważniejsza jest jakość niż koszt i czas odpowiedzi.$30.00 input / $180.00 output za 1M tokenów.Brak rabatu cached input; przy długim kontekście ceny są wyższe. Przy długich zadaniach rozważ background mode.
gpt-5.4-miniPubliczne chatboty tekstowe, obsługa klienta, generowanie treści, niższy koszt i niższa latencja.$0.75 input / $0.075 cached input / $4.50 output za 1M tokenów.Dobry punkt startowy dla MVP, jeśli nie każde pytanie wymaga modelu frontier.
gpt-5.4-nanoKlasyfikacja, routing, ekstrakcja danych, proste zadania masowe.$0.20 input / $0.02 cached input / $1.25 output za 1M tokenów.Najlepszy do prostych i tanich zadań pomocniczych, nie do głębokiego rozumowania.

Najważniejszy wniosek: gpt-5.5 jest świetny do trudniejszych zadań, ale publiczny chatbot bez limitów może szybko generować koszty. Dlatego architektura powinna obsługiwać limity, routing modeli i budżety.

Architektura produkcyjnego chatbota

Najbezpieczniejszy schemat wygląda tak:

  1. Użytkownik wpisuje wiadomość w interfejsie www, aplikacji, Slacku, Telegramie albo innym kanale.
  2. Frontend wysyła wiadomość do Twojego backendu, np. endpointu /chat.
  3. Backend waliduje dane, sprawdza limit zapytań, opcjonalnie uruchamia moderację i wybiera model.
  4. Backend wysyła zapytanie do OpenAI Responses API.
  5. Backend zapisuje minimalny stan rozmowy, jeśli jest potrzebny, i zwraca odpowiedź użytkownikowi.

Taki układ ma trzy ogromne zalety. Po pierwsze, klucz API nie trafia do przeglądarki. Po drugie, możesz kontrolować koszty i nadużycia. Po trzecie, możesz zmieniać modele, instrukcje i reguły bezpieczeństwa bez przepisywania frontendu.

Stos technologiczny

W tym poradniku użyjemy prostego stosu:

  • Python 3.11+,
  • FastAPI jako backend HTTP,
  • OpenAI Python SDK do komunikacji z Responses API,
  • python-dotenv do lokalnego ładowania zmiennych środowiskowych,
  • prosty HTML + JavaScript jako frontend testowy.

Przykładowa struktura projektu:

chatgpt-bot/
├── backend/
│   ├── main.py
│   ├── requirements.txt
│   └── .env
└── frontend/
    └── index.html

Instalacja zależności

W katalogu backend/requirements.txt dodaj:

fastapi
uvicorn[standard]
openai
python-dotenv
pydantic

Następnie zainstaluj pakiety. W środowisku produkcyjnym warto przypiąć wersje pakietów po testach, ale w projekcie demonstracyjnym najwygodniej zacząć od aktualizacji do najnowszych wersji:

cd backend
python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install --upgrade fastapi "uvicorn[standard]" openai python-dotenv pydantic

Konfiguracja klucza API

Wygeneruj klucz API w panelu OpenAI i zapisz go jako zmienną środowiskową. Lokalnie możesz użyć pliku .env:

OPENAI_API_KEY=sk-...
OPENAI_MODEL=gpt-5.4-mini
OPENAI_ADVANCED_MODEL=gpt-5.5
OPENAI_REASONING_EFFORT=low
ALLOWED_ORIGINS=http://localhost:3000,https://twoja-domena.pl

Pliku .env nigdy nie dodawaj do publicznego repozytorium. Dodaj go do .gitignore:

.env
.venv/
__pycache__/
*.pyc

Pierwsze wywołanie Responses API

Zanim zbudujemy cały backend, warto sprawdzić najprostsze wywołanie API. Przykład w cURL:

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4-mini",
    "input": "Wyjaśnij po polsku, czym jest chatbot oparty na OpenAI API.",
    "reasoning": { "effort": "low" },
    "max_output_tokens": 300,
    "store": false
  }'

Ten sam test w Pythonie:

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.4-mini",
    input="Napisz po polsku krótką odpowiedź: czym jest chatbot?",
    reasoning={"effort": "low"},
    max_output_tokens=300,
    store=False,
)

print(response.output_text)

I w JavaScripcie:

import OpenAI from "openai";

const client = new OpenAI();

const response = await client.responses.create({
  model: "gpt-5.4-mini",
  input: "Napisz po polsku krótką odpowiedź: czym jest chatbot?",
  reasoning: { effort: "low" },
  max_output_tokens: 300,
  store: false
});

console.log(response.output_text);

Najważniejsze różnice względem starych przykładów są następujące: używamy endpointu /v1/responses, metody responses.create, pola input, parametru instructions dla zasad zachowania modelu oraz response.output_text do pobrania tekstu odpowiedzi.

Backend FastAPI: kompletny przykład

Poniższy backend jest wystarczający jako baza do MVP. Obsługuje endpoint /chat, sesje rozmowy, lokalny limit zapytań per IP, moderację wiadomości użytkownika, wybór modelu w trybie standard lub advanced, wywołanie OpenAI Responses API i bezpieczne przechowywanie klucza API po stronie serwera.

import os
import time
import uuid
from collections import defaultdict, deque
from typing import Deque, Literal

from dotenv import load_dotenv
from fastapi import FastAPI, HTTPException, Request
from fastapi.middleware.cors import CORSMiddleware
from openai import (
    APIConnectionError,
    APIStatusError,
    APITimeoutError,
    AsyncOpenAI,
    RateLimitError,
)
from pydantic import BaseModel, Field

load_dotenv()

OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
OPENAI_MODEL = os.getenv("OPENAI_MODEL", "gpt-5.4-mini")
OPENAI_ADVANCED_MODEL = os.getenv("OPENAI_ADVANCED_MODEL", "gpt-5.5")
OPENAI_REASONING_EFFORT = os.getenv("OPENAI_REASONING_EFFORT", "low")

if not OPENAI_API_KEY:
    raise RuntimeError("Brak OPENAI_API_KEY. Ustaw klucz w zmiennych środowiskowych lub pliku .env.")

client = AsyncOpenAI(api_key=OPENAI_API_KEY)

app = FastAPI(title="Chatbot oparty na OpenAI Responses API")

allowed_origins = [
    origin.strip()
    for origin in os.getenv("ALLOWED_ORIGINS", "http://localhost:3000").split(",")
    if origin.strip()
]

app.add_middleware(
    CORSMiddleware,
    allow_origins=allowed_origins,
    allow_credentials=True,
    allow_methods=["POST", "GET", "OPTIONS"],
    allow_headers=["*"],
)

SYSTEM_INSTRUCTIONS = """
Jesteś pomocnym asystentem AI dla polskojęzycznych użytkowników.
Odpowiadaj jasno, rzeczowo i po polsku, chyba że użytkownik poprosi o inny język.
Nie twierdź, że jesteś oficjalnym produktem OpenAI, ChatGPT ani serwisem Czat GPT.
Nie proś użytkownika o hasła, numery kart, tokeny API, dane medyczne ani inne dane wrażliwe.
Gdy pytanie dotyczy prawa, zdrowia, finansów, bezpieczeństwa albo aktualnych faktów,
zaznacz potrzebę weryfikacji w oficjalnych źródłach lub konsultacji ze specjalistą.
"""

class ChatRequest(BaseModel):
    session_id: str | None = Field(default=None, description="Identyfikator sesji rozmowy.")
    message: str = Field(min_length=1, max_length=4000, description="Wiadomość użytkownika.")
    mode: Literal["standard", "advanced"] = Field(
        default="standard",
        description="standard = tańszy/szybszy model; advanced = trudniejsze zadania."
    )

class ChatResponse(BaseModel):
    session_id: str
    model: str
    reply: str

# Demo: pamięć w procesie aplikacji. W produkcji użyj Redis/PostgreSQL z TTL.
sessions: dict[str, list[dict[str, str]]] = {}
MAX_MESSAGES_PER_SESSION = 24

# Prosty limiter per IP do demo. W produkcji użyj Redis + limitów per konto/użytkownik.
WINDOW_SECONDS = 60
MAX_REQUESTS_PER_WINDOW = 20
request_log: dict[str, Deque[float]] = defaultdict(deque)

def choose_model(mode: str) -> str:
    return OPENAI_ADVANCED_MODEL if mode == "advanced" else OPENAI_MODEL

def choose_reasoning_effort(mode: str) -> str:
    if mode == "advanced":
        return "medium"
    return OPENAI_REASONING_EFFORT

def get_client_ip(request: Request) -> str:
    # Jeśli aplikacja stoi za proxy/CDN, nagłówki typu X-Forwarded-For
    # traktuj jako zaufane tylko po poprawnej konfiguracji infrastruktury.
    return request.client.host if request.client else "unknown"

def check_local_rate_limit(ip: str) -> None:
    now = time.time()
    bucket = request_log[ip]

    while bucket and now - bucket[0] > WINDOW_SECONDS:
        bucket.popleft()

    if len(bucket) >= MAX_REQUESTS_PER_WINDOW:
        raise HTTPException(
            status_code=429,
            detail="Za dużo zapytań. Spróbuj ponownie za chwilę."
        )

    bucket.append(now)

def trim_history(history: list[dict[str, str]]) -> list[dict[str, str]]:
    return history[-MAX_MESSAGES_PER_SESSION:]

async def moderate_user_input(text: str) -> None:
    moderation = await client.moderations.create(
        model="omni-moderation-latest",
        input=text,
    )

    if moderation.results and moderation.results[0].flagged:
        raise HTTPException(
            status_code=400,
            detail="Wiadomość nie może zostać przetworzona ze względów bezpieczeństwa."
        )

@app.get("/health")
async def health() -> dict[str, str]:
    return {"status": "ok"}

@app.post("/chat", response_model=ChatResponse)
async def chat(payload: ChatRequest, request: Request) -> ChatResponse:
    ip = get_client_ip(request)
    check_local_rate_limit(ip)

    session_id = payload.session_id or str(uuid.uuid4())
    user_message = payload.message.strip()

    await moderate_user_input(user_message)

    model = choose_model(payload.mode)
    reasoning_effort = choose_reasoning_effort(payload.mode)

    history = sessions.get(session_id, [])
    history.append({"role": "user", "content": user_message})
    history = trim_history(history)

    try:
        response = await client.responses.create(
            model=model,
            instructions=SYSTEM_INSTRUCTIONS,
            input=history,
            reasoning={"effort": reasoning_effort},
            max_output_tokens=900,
            store=False,
        )
    except RateLimitError:
        raise HTTPException(
            status_code=429,
            detail="Limit OpenAI API został przekroczony. Spróbuj ponownie później."
        )
    except APITimeoutError:
        raise HTTPException(
            status_code=504,
            detail="Model odpowiadał zbyt długo. Spróbuj ponownie."
        )
    except APIConnectionError:
        raise HTTPException(
            status_code=502,
            detail="Nie udało się połączyć z OpenAI API."
        )
    except APIStatusError as exc:
        raise HTTPException(
            status_code=exc.status_code,
            detail="OpenAI API zwróciło błąd. Sprawdź logi serwera."
        )

    assistant_reply = (response.output_text or "").strip()

    if not assistant_reply:
        assistant_reply = "Nie udało się wygenerować odpowiedzi. Spróbuj sformułować pytanie inaczej."

    history.append({"role": "assistant", "content": assistant_reply})
    sessions[session_id] = trim_history(history)

    return ChatResponse(session_id=session_id, model=model, reply=assistant_reply)

Jak działa najważniejszy fragment?

Kluczowe wywołanie wygląda tak:

response = await client.responses.create(
    model=model,
    instructions=SYSTEM_INSTRUCTIONS,
    input=history,
    reasoning={"effort": reasoning_effort},
    max_output_tokens=900,
    store=False,
)

instructions ustawia zasady zachowania asystenta: język, ton, ograniczenia i komunikaty bezpieczeństwa. input zawiera historię rozmowy w danej sesji. reasoning pozwala kontrolować wysiłek rozumowania: niższe wartości są szybsze i tańsze, wyższe mogą poprawić jakość trudniejszych analiz. store=False ogranicza przechowywanie odpowiedzi jako trwałego obiektu po stronie API tam, gdzie nie jest to potrzebne aplikacji.

W przykładzie trzymamy historię w słowniku sessions. To jest dobre tylko do testów. W produkcji użyj Redis, PostgreSQL albo innego magazynu z czasem życia sesji, np. 1–24 godziny. Jeżeli uruchomisz kilka instancji aplikacji, pamięć w procesie nie wystarczy, bo różne instancje nie będą widziały tej samej historii.

Uruchomienie lokalne

cd backend
uvicorn main:app --host 0.0.0.0 --port 3000 --reload

Test endpointu w trybie standardowym:

curl -X POST http://localhost:3000/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"Cześć, wyjaśnij mi, czym jest API w prostych słowach."}'

Test endpointu w trybie advanced, czyli z mocniejszym modelem:

curl -X POST http://localhost:3000/chat \
  -H "Content-Type: application/json" \
  -d '{"mode":"advanced","message":"Przeanalizuj ryzyka wdrożenia chatbota AI w sklepie internetowym."}'

Frontend HTML + JavaScript

Poniżej znajduje się prosty frontend testowy. W prawdziwej aplikacji można go zastąpić Reactem, Vue, Svelte, Next.js albo dowolnym UI. Zasada pozostaje taka sama: frontend wysyła wiadomość do własnego backendu, a nie bezpośrednio do OpenAI.

<!doctype html>
<html lang="pl">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Przykładowy chatbot AI</title>
  <style>
    body { font-family: system-ui, Arial, sans-serif; max-width: 760px; margin: 40px auto; padding: 0 16px; }
    #chat { border: 1px solid #ddd; border-radius: 12px; padding: 16px; min-height: 320px; }
    .msg { margin: 10px 0; line-height: 1.5; white-space: pre-wrap; }
    .user { text-align: right; }
    .assistant { text-align: left; }
    form { display: flex; gap: 8px; margin-top: 16px; }
    input { flex: 1; padding: 12px; border: 1px solid #ccc; border-radius: 8px; }
    button, select { padding: 12px 16px; border: 1px solid #ccc; border-radius: 8px; cursor: pointer; }
  </style>
</head>
<body>
  <h1>Przykładowy chatbot AI</h1>
  <p>To demo wysyła wiadomości do Twojego backendu FastAPI, a nie bezpośrednio do OpenAI.</p>

  <div id="chat" aria-live="polite"></div>

  <form id="chat-form">
    <select id="mode" aria-label="Tryb odpowiedzi">
      <option value="standard">standard</option>
      <option value="advanced">advanced</option>
    </select>
    <input id="message" autocomplete="off" placeholder="Napisz wiadomość..." required>
    <button type="submit">Wyślij</button>
  </form>

  <script>
    const chat = document.querySelector("#chat");
    const form = document.querySelector("#chat-form");
    const input = document.querySelector("#message");
    const mode = document.querySelector("#mode");

    let sessionId = localStorage.getItem("chat_session_id");
    if (!sessionId) {
      sessionId = crypto.randomUUID
        ? crypto.randomUUID()
        : String(Date.now()) + Math.random().toString(36).slice(2);
      localStorage.setItem("chat_session_id", sessionId);
    }

    function addMessage(text, role) {
      const div = document.createElement("div");
      div.className = "msg " + role;
      div.textContent = text;
      chat.appendChild(div);
      chat.scrollTop = chat.scrollHeight;
    }

    form.addEventListener("submit", async (event) => {
      event.preventDefault();

      const message = input.value.trim();
      if (!message) return;

      addMessage(message, "user");
      input.value = "";

      try {
        const res = await fetch("/chat", {
          method: "POST",
          headers: { "Content-Type": "application/json" },
          body: JSON.stringify({
            session_id: sessionId,
            message,
            mode: mode.value
          })
        });

        const data = await res.json();

        if (!res.ok) {
          addMessage(data.detail || "Wystąpił błąd.", "assistant");
          return;
        }

        sessionId = data.session_id;
        localStorage.setItem("chat_session_id", sessionId);
        addMessage(data.reply, "assistant");
      } catch (error) {
        addMessage("Nie udało się połączyć z serwerem.", "assistant");
      }
    });
  </script>
</body>
</html>

Jeśli frontend działa pod inną domeną niż backend, ustaw poprawnie ALLOWED_ORIGINS i CORS. W produkcji nie używaj szerokiego allow_origins=["*"] dla aplikacji obsługującej użytkowników, sesje lub dane.

Jak zarządzać pamięcią rozmowy?

Każde wywołanie modelu jest niezależne, jeśli nie przekażesz mu wcześniejszego kontekstu albo nie skorzystasz z mechanizmów stanu. Masz trzy typowe podejścia:

  • Ręczne przekazywanie historii: trzymasz listę wiadomości po swojej stronie i wysyłasz ją w input. To podejście pokazuje przykład FastAPI powyżej.
  • previous_response_id: możesz łączyć kolejne odpowiedzi, przekazując identyfikator poprzedniej odpowiedzi. To wygodne, ale wymaga świadomego podejścia do retencji danych.
  • Conversations API: dla dłużej żyjących rozmów i agentów możesz używać trwałych obiektów konwersacji, jeśli odpowiada to Twoim wymaganiom prywatności i architekturze.

Dla prostego publicznego chatbota najlepszy start to zwykle ręcznie zarządzana historia z limitem długości, TTL i streszczeniem starszych wiadomości, gdy rozmowa robi się długa. Nie wysyłaj całej historii bez końca, bo zwiększa to koszt, opóźnienie i ryzyko ujawnienia niepotrzebnych danych.

Structured Outputs: gdy odpowiedź ma być JSON-em

Jeśli odpowiedź ma być przetwarzana przez program, nie polegaj wyłącznie na promptach typu „odpowiedz w JSON”. Użyj Structured Outputs i schematu JSON. To przydatne przy obsłudze zgłoszeń, ekstrakcji danych, klasyfikacji intencji, routingu zapytań i generowaniu odpowiedzi do panelu administracyjnego.

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.4-mini",
    input="Klient pyta: 'Czy mogę zwrócić produkt po 10 dniach?'",
    text={
        "format": {
            "type": "json_schema",
            "name": "support_answer",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "intencja": {"type": "string"},
                    "odpowiedz": {"type": "string"},
                    "wymaga_czlowieka": {"type": "boolean"}
                },
                "required": ["intencja", "odpowiedz", "wymaga_czlowieka"],
                "additionalProperties": False
            }
        }
    },
    store=False,
)

print(response.output_text)

Jeśli model ma wywołać funkcję w Twojej aplikacji, np. sprawdzić status zamówienia, użyj function calling. Jeśli ma tylko zwrócić uporządkowaną odpowiedź, zwykle wystarczy structured output.

Czy chatbot powinien mieć dostęp do internetu?

Zwykły chatbot tekstowy nie musi przeszukiwać internetu. Jeśli jednak aplikacja ma odpowiadać na pytania o aktualne wydarzenia, ceny, dokumentację lub dane zmieniające się w czasie, możesz użyć narzędzia web_search w Responses API.

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.5",
    tools=[{"type": "web_search"}],
    input="Znajdź aktualne informacje o najnowszych zmianach w dokumentacji OpenAI API.",
    store=False,
)

print(response.output_text)

Nie włączaj web search bez potrzeby. Zwiększa koszt, złożoność i wymaga widocznego prezentowania źródeł użytkownikowi. Dla serwisu takiego jak Czat GPT ważne jest jasne rozróżnienie: jeżeli dana funkcja nie jest wdrożona, nie opisuj prostego czatu jako wyszukiwarki działającej w czasie rzeczywistym.

Streaming odpowiedzi

W chatbotach użytkownik oczekuje szybkiej reakcji. Jeśli odpowiedzi są dłuższe, warto użyć streamingu. Dzięki temu frontend może wyświetlać tekst fragment po fragmencie, zamiast czekać na zakończenie całej odpowiedzi.

Streaming warto wdrożyć dopiero wtedy, gdy proste MVP działa stabilnie. W produkcji możesz użyć Server-Sent Events albo WebSocketów. Jeśli budujesz chatbota do dłuższych analiz, streamowanie znacząco poprawia odczucie szybkości, nawet gdy całe zadanie trwa tyle samo.

Bezpieczeństwo, prywatność i moderacja

Publiczny chatbot powinien mieć zabezpieczenia od pierwszej wersji. Minimum to:

  • walidacja długości wiadomości,
  • rate limiting,
  • moderacja wejścia użytkownika,
  • instrukcje systemowe określające zakres odpowiedzi,
  • blokada danych wrażliwych,
  • monitorowanie nadużyć,
  • mechanizm zgłoszenia błędnej lub szkodliwej odpowiedzi,
  • jasna polityka prywatności.

W przykładzie backendu użyliśmy modelu omni-moderation-latest:

moderation = await client.moderations.create(
    model="omni-moderation-latest",
    input=text,
)

Moderacja nie zastępuje dobrego projektu produktu. Jeśli chatbot ma odpowiadać w obszarach wysokiego ryzyka, takich jak zdrowie, finanse, prawo, edukacja lub bezpieczeństwo, dodaj dodatkowe zasady: odpowiedzi informacyjne zamiast decyzyjnych, zachęcanie do konsultacji ze specjalistą, ograniczanie automatycznych działań i weryfikację źródeł.

Prywatność i dane użytkowników

Nie wysyłaj do modelu haseł, tokenów API, numerów kart, danych medycznych, danych klientów ani tajemnic firmowych, chyba że masz pełną podstawę prawną, właściwą architekturę bezpieczeństwa i świadomą zgodę. Dane przesyłane przez OpenAI API nie są domyślnie używane do trenowania lub ulepszania modeli, chyba że klient wyraźnie zdecyduje się je udostępnić. Jednocześnie mogą istnieć logi bezpieczeństwa, retencja i ustawienia opisane w dokumentacji OpenAI.

Dla chatbota zgodnego z dobrymi praktykami:

  • dodaj w polityce prywatności informację, że zapytania mogą być przetwarzane przez zewnętrznego dostawcę AI,
  • nie przechowuj historii dłużej, niż jest to konieczne,
  • stosuj store=False, jeśli nie potrzebujesz przechowywania odpowiedzi po stronie API,
  • maskuj lub usuwaj dane osobowe z logów,
  • stosuj TLS, bezpieczne sekrety, rotację kluczy i zasadę najmniejszych uprawnień,
  • nie obiecuj użytkownikowi pełnej anonimowości technicznej, jeśli usługa przetwarza dane techniczne potrzebne do działania.

Takie podejście jest spójne z zasadami serwisu Czat GPT: prosty czat po polsku, jasne rozróżnienie między niezależnym serwisem a oficjalnym ChatGPT, oraz uczciwe komunikaty o prywatności, bezpieczeństwie i ograniczeniach AI. Warto linkować użytkowników do stron Polityka prywatności, Bezpieczeństwo i Regulamin.

Rate limits i obsługa błędów

OpenAI API ma limity szybkości zależne od organizacji, projektu, modelu, typu limitu i sposobu użycia. Zamiast wpisywać w artykule jedną liczbę typu „X requestów na minutę”, lepiej opisać mechanizm: limity mogą dotyczyć requestów na minutę, requestów na dzień, tokenów na minutę, tokenów na dzień i innych zasobów.

W backendzie obsłuż przede wszystkim:

  • 429 Rate Limit: pokaż użytkownikowi komunikat i zastosuj retry z exponential backoff.
  • Timeout: nie blokuj UI bez końca; ustaw rozsądny limit czasu.
  • Błędy połączenia: zwróć komunikat „spróbuj ponownie”.
  • Własne limity użytkowników: np. wiadomości na minutę per IP, konto lub sesję.
  • Budżet: ustaw limity wydatków i alerty w panelu OpenAI.

W produkcji loguj liczbę tokenów, model, czas odpowiedzi, tryb, błędy i przybliżony koszt, ale nie zapisuj pełnych danych wrażliwych użytkownika.

Jak obniżać koszty chatbota?

Największy koszt w publicznym chatbocie zwykle wynika z długiego kontekstu, zbyt dużej historii rozmowy, braku limitów, niepotrzebnego użycia mocnego modelu i braku cache. Praktyczne sposoby redukcji kosztów:

  • Routing modeli: proste pytania do gpt-5.4-mini, trudniejsze do gpt-5.5.
  • Limit historii: wysyłaj tylko ostatnie wiadomości lub streszczenie rozmowy.
  • Krótki output: ustaw max_output_tokens i proś o zwięzłe odpowiedzi, gdy to wystarczy.
  • Structured Outputs: dla zadań systemowych zwracaj krótkie JSON-y zamiast długich opisów.
  • Batch/Flex: dla zadań niewymagających natychmiastowej odpowiedzi rozważ tańsze tryby przetwarzania.
  • Pomiar jakości: nie zgaduj; testuj, gdzie mocniejszy model naprawdę poprawia wynik.

Integracje: Slack, Telegram, WhatsApp, Messenger

Ten sam backend może obsługiwać wiele kanałów. Różnica leży tylko w adapterze:

  • Slack: odbierasz eventy przez webhook, weryfikujesz podpis Slacka, mapujesz użytkownika na session_id i odsyłasz odpowiedź przez Slack API.
  • Telegram: odbierasz wiadomości przez webhook albo polling, a odpowiedzi wysyłasz przez Bot API.
  • WhatsApp: korzystasz z WhatsApp Cloud API lub dostawcy typu Twilio i mapujesz wiadomości na endpoint /chat.
  • Messenger, Teams lub Discord: kanał komunikacji staje się cienką warstwą nad centralnym backendem AI.

Nie duplikuj logiki modelu w każdej integracji. Najlepiej wydzielić funkcję typu generate_reply(session_id, message, mode), a każdy kanał powinien tylko dostarczyć wiadomość i odebrać odpowiedź.

Wdrożenie

Do wdrożenia backendu FastAPI możesz użyć Render, Railway, Fly.io, VPS, Dockera, Kubernetes albo dowolnej chmury. Minimalny Dockerfile:

FROM python:3.12-slim

WORKDIR /app

COPY backend/requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY backend .

CMD ["sh", "-c", "uvicorn main:app --host 0.0.0.0 --port ${PORT:-3000}"]

Najważniejsze ustawienia produkcyjne:

  • ustaw OPENAI_API_KEY jako sekret w panelu hostingu,
  • nie commituj pliku .env,
  • ustaw konkretną listę ALLOWED_ORIGINS,
  • użyj Redis lub bazy danych do sesji, jeśli masz więcej niż jedną instancję,
  • włącz logi błędów, ale nie zapisuj pełnych danych wrażliwych,
  • dodaj monitoring kosztów i alerty,
  • testuj prompt injection, nietypowe wiadomości użytkowników i próby obchodzenia zasad,
  • przy bardzo długich zadaniach i modelach takich jak gpt-5.5-pro rozważ tryb background zamiast zwykłego requestu HTTP czekającego na odpowiedź.

Checklist przed publikacją chatbota

  • Klucz API jest tylko po stronie serwera.
  • Endpoint /chat ma walidację długości wiadomości.
  • Masz rate limiting po stronie aplikacji.
  • Obsługujesz błędy 429, timeouty i błędy połączenia.
  • Historia rozmowy ma limit i czas życia.
  • Masz politykę prywatności opisującą przetwarzanie przez zewnętrznego dostawcę AI.
  • Nie opisujesz chatbota jako oficjalnego ChatGPT, jeśli jest niezależną aplikacją.
  • Masz jasne komunikaty o ograniczeniach AI i możliwości błędów.
  • Masz testy jakościowe dla typowych pytań użytkowników.
  • Masz budżet, usage limits i alerty kosztowe w panelu OpenAI.
  • Masz plan aktualizacji modeli i promptów po zmianach w dokumentacji OpenAI.

Najczęstsze błędy w starych tutorialach

Stary element w tutorialachDlaczego to problemLepsza wersja w 2026
openai.ChatCompletion.create()Stary styl SDK i przykłady oparte na Chat Completions.client.responses.create() w Responses API.
gpt-3.5-turbo jako domyślny modelNie jest aktualnym punktem startowym dla nowych integracji.gpt-5.4-mini dla kosztu albo gpt-5.5 dla złożonych zadań.
Klucz API w kodzie frontenduUżytkownik może go skopiować i wygenerować koszty.Klucz tylko na backendzie lub w zaufanym środowisku.
Brak limitów i budżetuRyzyko nadużyć, wysokich kosztów i przeciążenia.Rate limiting, usage limits, alerty kosztowe, retry z backoffem.
„Chatbot zawsze mówi prawdę”Modele AI mogą popełniać błędy i halucynować.Komunikat o ograniczeniach, weryfikacja faktów, źródła dla aktualnych danych.

Jak ten poradnik wspiera Czat GPT po polsku?

Ten artykuł pełni inną rolę niż strona główna Czat GPT. Strona główna powinna pomagać użytkownikowi szybko rozpocząć rozmowę z AI po polsku. Ten poradnik jest dla osób technicznych, które chcą zrozumieć, jak podobne systemy można budować przy użyciu oficjalnego OpenAI API.

Dlatego warto utrzymać w artykule trzy jasne komunikaty:

  • ChatGPT to oficjalna aplikacja OpenAI.
  • OpenAI API / Responses API to usługa dla deweloperów budujących własne aplikacje.
  • Czat GPT to niezależny polski serwis do rozmowy z asystentem AI po polsku, a nie oficjalny produkt OpenAI.

Takie rozróżnienie pomaga użytkownikom, wzmacnia zaufanie i chroni SEO przed nieprecyzyjnymi obietnicami. Dobrze też łączy tę stronę z innymi materiałami w serwisie, takimi jak Czym jest ChatGPT?, GPT-5.5, FAQ i dokumentacja API.

Podsumowanie

Budowa chatbota za pomocą ChatGPT API w 2026 roku oznacza przede wszystkim pracę z OpenAI Responses API, świadomy dobór modelu i bezpieczny backend. Najprostszy działający schemat to: frontend wysyła wiadomość do FastAPI, FastAPI waliduje i moderuje treść, wybiera model, wywołuje client.responses.create(), a następnie zwraca odpowiedź użytkownikowi.

Dla większości prostych chatbotów tekstowych zacznij od gpt-5.4-mini, ustaw store=False, trzymaj klucz API po stronie serwera, dodaj limity i nie przechowuj historii dłużej, niż jest to potrzebne. Gdy użytkownik zadaje trudniejsze pytania, przełączaj się na gpt-5.5. Dla najtrudniejszych zadań rozważ gpt-5.5-pro, ale pamiętaj o koszcie, czasie odpowiedzi i właściwej architekturze.

Jeśli budujesz polski serwis podobny do Czat GPT, najważniejsze są trzy rzeczy: prosty interfejs po polsku, uczciwe informacje o prywatności i jasne rozróżnienie między niezależnym serwisem a oficjalnym ChatGPT/OpenAI.

FAQ

Czy „ChatGPT API” to oficjalna nazwa?

„ChatGPT API” to potoczna nazwa. Oficjalnie deweloperzy korzystają z OpenAI API, a dla nowych projektów najważniejszym interfejsem jest Responses API. W artykułach SEO można używać frazy „ChatGPT API”, ale warto od razu wyjaśnić, że chodzi o oficjalne OpenAI API.

Czy Responses API zastępuje Chat Completions?

Chat Completions nadal może być używane w wielu projektach, ale OpenAI rekomenduje Responses API dla nowych integracji. Responses API lepiej obsługuje najnowsze modele, narzędzia, workflowy agentowe i mechanizmy stanu.

Jaki model wybrać do prostego chatbota po polsku?

Dla prostego chatbota tekstowego dobrym punktem startowym jest gpt-5.4-mini, ponieważ ma niższy koszt i dobrą jakość w codziennych zadaniach. Dla trudniejszych analiz, kodowania i dłuższych workflow warto routować zapytania do gpt-5.5.

Czy GPT-5.5 jest dostępny w API?

Tak. Na dzień 27 kwietnia 2026 r. gpt-5.5 i gpt-5.5-pro są dostępne w OpenAI API. Dostępność, ceny, limity i endpointy mogą się zmieniać, dlatego przed wdrożeniem produkcyjnym należy sprawdzić aktualną dokumentację OpenAI.

Czy mogę trzymać klucz OpenAI API w frontendzie?

Nie. Klucz API powinien być przechowywany wyłącznie po stronie serwera albo w zaufanym środowisku. Frontend powinien wysyłać wiadomości do Twojego backendu, a backend dopiero do OpenAI API.

Czy ten poradnik opisuje publiczne API Czat GPT?

Nie. Ten poradnik opisuje budowę własnego chatbota przy użyciu oficjalnego OpenAI API. Czat GPT to niezależny polski serwis do rozmowy z asystentem AI po polsku i nie jest oficjalnym produktem OpenAI.

Czy dane wysyłane przez OpenAI API są używane do trenowania modeli?

Zgodnie z dokumentacją OpenAI dane przesyłane przez API nie są domyślnie używane do trenowania ani ulepszania modeli, chyba że klient wyraźnie zdecyduje się je udostępnić. Nadal należy jednak informować użytkowników o przetwarzaniu przez zewnętrznego dostawcę AI i unikać wysyłania danych wrażliwych.

Ile kosztuje zbudowanie chatbota z OpenAI API?

Koszt zależy od modelu, liczby użytkowników, długości wiadomości, długości odpowiedzi, użycia narzędzi i trybu przetwarzania. Prosty chatbot na gpt-5.4-mini może być znacznie tańszy niż chatbot, który każde pytanie wysyła do gpt-5.5 albo gpt-5.5-pro. Dlatego od początku warto wdrożyć limity, routing modeli i monitoring kosztów.

Czy chatbot musi mieć dostęp do internetu?

Nie. Większość chatbotów tekstowych działa bez wyszukiwania w sieci. Dostęp do internetu przez web_search warto dodać dopiero wtedy, gdy chatbot ma odpowiadać na pytania o aktualne informacje, ceny, dokumentację albo wydarzenia.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *