Jak zbudować aplikację Character AI: architektura, kod i rachunek kosztów

Krótka odpowiedź: architektura czterech komponentów

Nie musisz trenować ani fine-tunować modelu. Każda poważna aplikacja-towarzysz na rynku dzisiaj, łącznie z tymi obsługującymi miliony użytkowników, to cienka warstwa orkiestracji nad hostowanymi API LLM. Postać żyje w prompcie i bazie danych, nie w wagach. Reszta tego przewodnika buduje każdy komponent z działającym kodem na standardowym endpoincie kompatybilnym z OpenAI, a potem przechodzi przez rachunek tokenów, żebyś wiedział, ile faktycznie kosztuje miesięcznie aktywny użytkownik, zanim wystartujesz.

• Prompt persony: ustrukturyzowany system prompt (500 do 1000 tokenów), który definiuje, kim jest postać i jak mówi.
• Pamięć: przesuwane okno ostatnich tur plus okresowo odświeżane podsumowanie, żeby rozmowy przetrwały poza limit kontekstu.
• Moderacja: bramka wiekowa, klasyfikator wejścia i polityki treści dopasowane do modelu, do którego routujesz.
• Routing: mała funkcja, która wybiera tani model do swobodnego czatu i mocniejszy do długich scen.

Komponent 1: prompt persony

Prompt persony to produkt. To wiadomość systemowa wysyłana z każdym zapytaniem, zazwyczaj zawierająca pięć części: tożsamość (imię, wiek, historia), cechy osobowości, styl mówienia z dwiema lub trzema przykładowymi liniami, twarde zasady zachowania (nigdy nie wypadaj z roli, trzymaj odpowiedzi poniżej limitu długości) i aktualny scenariusz. Trzymaj go między 500 a 1000 tokenów. Krótsze persony dryfują; dużo dłuższe zużywają budżet wejściowy przy każdej pojedynczej wiadomości i rzadko poprawiają wierność roli. Przechowuj persony jako wiersze w swojej bazie danych, żeby użytkownicy mogli tworzyć i edytować postacie, co jest głównym cyklem produktów w stylu Character.AI. Oto pełne zapytanie. Ten sam kształt działa z każdym backendem kompatybilnym z OpenAI; ten przykład używa endpointu gateway z wieloma modelami, więc możesz zamieniać modele, zmieniając jeden string:

curl https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $KEAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [
      {"role": "system", "content": "You are Mira, a sarcastic starship engineer in her 30s. Personality: dry wit, fiercely loyal, hates small talk. Speech style: short technical sentences, occasional teasing. Example: \"The coupling is fried. Again. Did you touch it?\" Rules: never break character, never mention being an AI, keep replies under 120 words."},
      {"role": "user", "content": "Mira, the reactor is making that noise again."}
    ],
    "temperature": 0.9,
    "max_tokens": 300,
    "stream": true
  }'

Komponent 2: pamięć, która przetrwa długie rozmowy

Sesje w aplikacjach-towarzyszach trwają długo. Trójwarstwowy stos pamięci utrzymuje kontekst spójny bez wysyłania całej historii za każdym razem: Warstwa 1 to przesuwane okno: ostatnie 10 do 14 surowych tur, wysyłane dosłownie. Warstwa 2 to bieżące podsumowanie: co jakieś 20 tur tani model kompresuje starsze wiadomości do akapitu śledzącego imiona, stan relacji i otwarte wątki fabularne. Warstwa 3 to przypięte fakty: trwałe szczegóły o użytkowniku (imię, preferencje, przeszłe wydarzenia, które postać powinna pamiętać), wyodrębnione do Twojej bazy danych i wstrzykiwane jako krótka wiadomość systemowa. Oto cała implementacja w Pythonie z oficjalnym SDK OpenAI:

from openai import OpenAI

client = OpenAI(
    api_key="sk-...",
    base_url="https://api.apisrouter.com/v1",
)

def build_context(persona, summary, pinned_facts, recent_turns, user_msg):
    facts = "\n".join(f"- {f}" for f in pinned_facts)
    return [
        {"role": "system", "content": persona},
        *([{"role": "system", "content": f"Facts to remember:\n{facts}"}]
          if pinned_facts else []),
        *([{"role": "system", "content": f"Story so far: {summary}"}]
          if summary else []),
        *recent_turns[-12:],
        {"role": "user", "content": user_msg},
    ]

def refresh_summary(old_turns, prev_summary):
    prompt = (
        "Update this running summary of a roleplay chat. Keep names, "
        "relationship state, and open plot threads. Max 150 words.\n\n"
        f"Current summary: {prev_summary}\n\nNew messages: {old_turns}"
    )
    resp = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=400,
    )
    return resp.choices[0].message.content

Komponent 3: moderacja i polityki treści

Moderacja w aplikacji-towarzyszu ma trzy odrębne zadania, a mylenie ich to najczęstszy błąd przy starcie. Po pierwsze, ogranicz swoją publiczność. Jeśli Twoja aplikacja dopuszcza dojrzałe motywy fikcyjne, umieść je za bramką wiekową dla dorosłych i zachowaj osobny domyślny tryb dla wszystkich grup wiekowych. Zarówno App Store, jak i Play Store sprawdzają to przy recenzji, a procesorzy płatności też zwracają na to uwagę. Po drugie, przesiewaj wejścia. Uruchom tani przebieg klasyfikatora na wiadomościach użytkownika, zanim dotrą do modelu postaci, blokując kategorie, których żaden dostawca nie dopuszcza: treści z udziałem osób niepełnoletnich, wiarygodną realną szkodę i nielegalne instrukcje. Pojedyncze wywołanie deepseek-v4-flash z rubryką tak/nie kosztuje ułamek centa i dodaje mniej niż sekundę opóźnienia. Po trzecie, dopasuj politykę treści do modelu. Dostawcy różnią się w kwestii fikcji: opublikowana polityka xAI wprost dopuszcza dojrzałe motywy fikcyjne dla dorosłych użytkowników, DeepSeek i inne modele wywodzące się z otwartych wag są faworytami społeczności do roleplayu, bo ich hostowane polityki są elastyczne wobec fikcji, podczas gdy polityka Anthropic zabrania treści jednoznacznych, co czyni Claude właściwym wyborem tylko do twórczego pisania dla wszystkich grup wiekowych. Zrozumienie tych polityk, zanim zaczniesz routować ruch, oszczędza Ci burz odmów na produkcji. Cokolwiek zbudujesz, musi respektować regulamin każdego dostawcy, którego wywołujesz.

Komponent 4: routing modeli i macierz wyboru

Większość wiadomości w aplikacji-towarzyszu to krótkie swobodne tury, z którymi budżetowy model radzi sobie doskonale. Mniejszość to długie emocjonalne sceny albo kreatywne popisy, gdzie jakość prozy jest produktem. Routing według głębokości sceny drastycznie obniża koszty, a użytkownicy tego nie zauważają:

ROUTES = {
    "casual": "deepseek-v4-flash",
    "scene": "deepseek-v4-pro",
    "prose": "claude-sonnet-4-6",  # tylko twórcze pisanie dla wszystkich grup wiekowych
}

def pick_model(user_msg: str, turns_in_scene: int) -> str:
    if turns_in_scene > 6 or len(user_msg) > 400:
        return ROUTES["scene"]
    return ROUTES["casual"]

Ile faktycznie kosztuje miesięcznie aktywny użytkownik

Rachunek tokenów przed startem jest lepszy niż niespodzianka na fakturze po. Przy budżecie kontekstu z tabeli pamięci: około 3300 tokenów wejściowych i 250 tokenów wyjściowych na wiadomość. Użytkownicy aplikacji-towarzyszy są intensywni; liczby zgłaszane przez społeczność stawiają zaangażowanych użytkowników na dziesiątkach wiadomości dziennie, więc załóż około 40 wiadomości dziennie przez 20 aktywnych dni, czyli około 800 wiadomości na MAU miesięcznie. To daje 2,64M tokenów wejściowych i 0,2M tokenów wyjściowych na MAU miesięcznie. Mnożąc przez stawki katalogowe:

Jeden endpoint na każdy model z macierzy

Zakładanie pięciu kont u dostawców, żeby uruchomić jeden router, to realny narzut: pięć kluczy, pięć paneli rozliczeniowych, pięć zestawów limitów zapytań. Gateway z wieloma modelami to upraszcza. APIsRouter udostępnia każdy model powyżej przez jeden kompatybilny z OpenAI base URL https://api.apisrouter.com/v1, więc fragment kodu routera działa bez zmian, zmieniając tylko string modelu. Rozliczenie jest pay-as-you-go bez subskrypcji, modele globalne działają 20% poniżej oficjalnych cen, modele chińskie poniżej ich oficjalnych stawek, a checkout bez rejestracji na /topup wysyła klucz na Twój e-mail po płatności, przy czym pierwsza wpłata dodaje +100% salda. GET /v1/models z Twoim kluczem zwraca aktualną listę modeli, co też przydaje się do wypełnienia selektora modelu we własnym panelu admina.

Wskazówki produkcyjne, które oszczędzają realne pieniądze i ból głowy

• Streamuj wszystko. Czas do pierwszego tokena to metryka, którą czują użytkownicy; streamowana odpowiedź po 2 sekundach wydaje się szybsza niż kompletna odpowiedź po 4.
• Trzymaj stabilny prefiks stabilnym. Persona i przypięte fakty powinny być identyczne co do bajtu między zapytaniami, żeby backendy wspierające cachowanie prefiksu mogły z tego skorzystać.
• Ogranicz max_tokens na trasę. Swobodne tury rzadko potrzebują więcej niż 300 tokenów wyjściowych; nieograniczony model, który się rozwleka, podwaja Twój rachunek za wyjście.
• Loguj koszt na użytkownika, nie tylko na zapytanie. Niewielki odsetek intensywnych użytkowników zdominuje wydatki; musisz ich widzieć, żeby zaprojektować sprawiedliwe poziomy użycia.
• Wbuduj fallback w router. Jeśli główny model przekroczy czas albo odmówi, spróbuj raz z modelem siostrzanym, zanim pokażesz błąd.
• Przycinaj przesuwane okno według tokenów, nie tur, żeby jedna długa wklejka nie wysadziła budżetu.
• Obsługuj odmowy w roli. Zmapuj odmowę na eleganckie odchylenie w ramach historii, zamiast pokazywać surowy tekst API.
• Nie przechowuj surowych czatów dłużej niż to konieczne i napisz o tym w polityce prywatności. Logi czatów towarzysza są z natury wrażliwe.

Częste pytania