Як побудувати застосунок Character AI: архітектура, код і математика вартості

Коротка відповідь: архітектура з чотирьох компонентів

Вам не потрібно тренувати чи дообучати модель. Кожен серйозний застосунок-компаньйон на ринку сьогодні, включно з тими, що обслуговують мільйони користувачів, це тонкий шар оркестрації над хостинговими LLM API. Персонаж живе в промпті і базі даних, а не у вагах. Решта цього гайду будує кожен компонент з робочим кодом проти стандартного OpenAI-сумісного ендпоінта, а потім проходить математику токенів, щоб ви знали, скільки насправді коштує місячний активний користувач до запуску.

• Промпт персони: структурований системний промпт (500-1000 токенів), що визначає, ким є персонаж і як він говорить.
• Пам'ять: рухоме вікно останніх ходів плюс періодично оновлюваний підсумок, щоб розмови переживали ліміт контексту.
• Модерація: віковий гейт, класифікатор вхідних даних і політики контенту, узгоджені з моделлю, до якої йде маршрутизація.
• Маршрутизація: невелика функція, що обирає дешеву модель для звичайного чату і сильнішу для довгих сцен.

Компонент 1: промпт персони

Промпт персони це продукт. Це системне повідомлення, яке йде з кожним запитом і зазвичай містить п'ять частин: ідентичність (ім'я, вік, передісторія), риси характеру, стиль мовлення з двома-трьома прикладами реплік, жорсткі поведінкові правила (ніколи не виходити з ролі, тримати відповіді в межах ліміту довжини) та поточний сценарій. Тримайте його між 500 і 1000 токенів. Коротші персони дрейфують; набагато довші спалюють вхідний бюджет на кожному повідомленні і рідко покращують дотримання ролі. Зберігайте персон як рядки у вашій базі даних, щоб користувачі могли створювати і редагувати персонажів, що є основним циклом продуктів у стилі Character.AI. Ось повний запит. Та сама форма працює з будь-яким OpenAI-сумісним бекендом; цей приклад використовує ендпоінт мультимодельного шлюзу, тож ви можете міняти моделі, змінюючи один рядок:

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
  }'

Компонент 2: пам'ять, що переживає довгі розмови

Сесії застосунків-компаньйонів тривають довго. Триshaровий стек пам'яті тримає контекст зв'язним, не надсилаючи всю історію щоразу: Шар 1 (рухоме вікно): останні 10-14 сирих ходів, надіслані дослівно. Шар 2 (поточний підсумок): приблизно кожні 20 ходів дешева модель стискає старіші повідомлення в абзац, що відстежує імена, стан стосунків і відкриті сюжетні лінії. Шар 3 (закріплені факти): стійкі деталі користувача (ім'я, вподобання, минулі події, які персонаж має пам'ятати), витягнуті у вашу базу даних і вставлені як коротке системне повідомлення. Це вся реалізація на Python з офіційним OpenAI SDK:

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

Компонент 3: модерація і політики контенту

Модерація в застосунку-компаньйоні виконує три окремі функції, і їх змішування є найпоширенішою помилкою запуску. По-перше, гейтуйте аудиторію. Якщо ваш застосунок дозволяє дорослі вигадані теми, помістіть їх за віковим гейтом для дорослих і тримайте окремий стандарт для всіх віків. І App Store, і Play Store перевіряють це, і платіжні процесори теж на це звертають увагу. По-друге, скринінг вхідних даних. Запускайте дешевий прохід класифікатора над повідомленнями користувача перед тим, як вони досягнуть моделі персонажа, блокуючи категорії, які не дозволяє жоден провайдер: контент за участю неповнолітніх, достовірна реальна шкода і незаконні інструкції. Один виклик deepseek-v4-flash з правилом так/ні коштує частку центу і додає менше секунди затримки. По-третє, узгоджуйте політику контенту з моделлю. Провайдери відрізняються щодо художнього письма: опублікована політика xAI прямо дозволяє дорослі вигадані теми для дорослих користувачів, DeepSeek та інші моделі, похідні від відкритої ваги, є фаворитами спільноти для рольової гри, тому що їхні хостингові політики гнучкі щодо художнього письма, тоді як політика Anthropic забороняє відвертий контент, роблячи Claude правильним вибором лише для творчого письма для всіх віків. Розуміння цих політик до маршрутизації трафіку рятує вас від шквалу відмов у продакшні. Що б ви не будували, це має поважати умови надання послуг кожного провайдера, якого ви викликаєте.

Компонент 4: маршрутизація моделей і матриця вибору

Більшість повідомлень у застосунку-компаньйоні це короткі звичайні ходи, з якими ідеально впорається бюджетна модель. Меншість це довгі емоційні сцени чи творчі епізоди, де якість прози це продукт. Маршрутизація за глибиною сцени різко знижує витрати, і користувачі цього не помічають:

ROUTES = {
    "casual": "deepseek-v4-flash",
    "scene": "deepseek-v4-pro",
    "prose": "claude-sonnet-4-6",  # лише творче письмо для всіх віків
}

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"]

Скільки насправді коштує місячний активний користувач

Математика токенів до запуску краща за сюрприз від рахунку після. Використовуючи бюджет контексту з таблиці пам'яті: приблизно 3300 вхідних токенів і 250 вихідних токенів на повідомлення. Користувачі застосунків-компаньйонів активні; звіти спільноти вказують, що залучені користувачі надсилають десятки повідомлень на день, тож припустимо приблизно 40 повідомлень на день протягом 20 активних днів, або близько 800 повідомлень на MAU на місяць. Це дає 2.64М вхідних токенів і 0.2М вихідних токенів на MAU на місяць. Множення на тарифи каталогу:

Один ендпоінт для кожної моделі в матриці

Реєстрація в п'яти акаунтах провайдерів для запуску одного роутера це реальні накладні витрати: п'ять ключів, п'ять панелей білінгу, п'ять наборів рейт-лімітів. Мультимодельний шлюз усе це згортає. APIsRouter надає кожну модель вище через єдиний OpenAI-сумісний base URL https://api.apisrouter.com/v1, тож фрагмент коду роутера працює як є, змінюючи лише рядок моделі. Білінг це оплата за фактичне використання без підписки, глобальні моделі йдуть на 20% нижче офіційних цін, а китайські моделі дешевші за офіційні тарифи, а оформлення без реєстрації на /topup надсилає ключ на ваш email після оплати, а перше поповнення додає +100% до балансу. GET /v1/models з вашим ключем повертає актуальний список моделей, що також зручно для заповнення селектора моделей у власному адмін-інтерфейсі.

Продакшн-поради, що заощаджують реальні гроші і нерви

• Стрімте все. Час до першого токена є метрикою, яку відчувають користувачі; стрімлена відповідь за 2 секунди відчувається швидшою за повну відповідь за 4.
• Тримайте стабільний префікс стабільним. Персона і закріплені факти мають бути побайтово ідентичними між запитами, щоб бекенди, що підтримують кешування префіксів, могли цим скористатись.
• Обмежуйте max_tokens за маршрутом. Звичайні ходи рідко потребують більше 300 вихідних токенів; необмежена модель, що розводить, подвоює ваш рахунок за вихід.
• Логуйте вартість на користувача, а не лише на запит. Невелика частка важких користувачів домінуватиме у витратах; вам потрібно їх бачити, щоб спроєктувати справедливі рівні використання.
• Вбудуйте резервний варіант у роутер. Якщо основна модель перевищує час очікування чи відмовляє, спробуйте один раз на суміжній моделі, перш ніж показати помилку.
• Обрізайте рухоме вікно за токенами, а не за ходами, щоб один довгий вставлений текст не розбив бюджет.
• Обробляйте відмови в ролі. Мапте відмову на плавне ухилення в межах історії замість того, щоб показувати сирий текст API.
• Не зберігайте сирі чати довше, ніж необхідно, і скажіть про це у політиці конфіденційності. Логи чатів компаньйона за своєю природою чутливі.

Поширені запитання