Спочатку висновок: якщо прототип розумного чат-бота має одночасно порівнювати шість великих моделей, то за прямого офіційного підключення лише підтримка SDK з'їсть два тижні робочого часу. Після переходу на уніфікований інтерфейс від вибору до запуску минуло лише три дні. У цій статті ми розберемо реальний процес нашої команди оцінювання, включно з кодом, який можна відтворити, та п'ятьма підводними каменями, які обов'язково треба оминути.
Передумови проєкту: один прототип розумного чат-бота, шість моделей на одній сцені
Минулого місяця я отримав внутрішнє завдання з оцінювання — створити прототип розумного чат-бота для команди, що працює в онлайн-освіті. Вимоги були чіткі: одну й ту саму партію користувацьких запитань подати окремо до GPT-4o, Claude 4 Sonnet, DeepSeek-V3, Qwen-Max, ERNIE та Doubao, порівняти якість відповідей і затримку відповіді, а зрештою вибрати дві моделі для схеми active-active.
Уніфікований набір тестових випадків — 300 реальних діалогів служби підтримки, що охоплюють три категорії: політика повернення коштів, консультації щодо курсів і технічні збої. Було три виміри оцінювання: точність відповіді, затримка першого token і вартість за одиницю token. Тут треба наголосити: набір тестів має бути фіксованим, інакше після заміни партії запитань висновки попливуть.
Етап вибору: не поспішайте писати код, спершу пройдіть порівняння цін
Шість моделей — шість різних систем тарифікації: деякі рахують вхід і вихід окремо, деякі дають знижку за влучання в кеш. Ми спочатку порахували обсяг token для 300 тестових випадків, а потім підставили прайс-листи кожної моделі. На цьому кроці інструмент порівняння цін великих моделей може заощадити чимало часу.
За результатами тестів, в одному й тому самому сценарії підтримки вартість однієї розмови на різних моделях може відрізнятися в рази. Щодо якості: у питаннях, де потрібно суворо дотримуватися правил, як-от політика повернення коштів, Claude 4 Sonnet і Qwen-Max показали стабільні результати; у діагностиці технічних збоїв ланцюг міркувань DeepSeek-V3 був повнішим. GPT-4o загалом збалансована, але ціна за одиницю зависока.
Найбільший урок етапу вибору: не дивіться лише на рейтинги. Завдання в рейтингах часто не збігаються з розподілом вашого бізнесу — лише власний прогін тестового набору дає право на висновок.
Етап підключення: кошмар підтримки шести SDK
Спочатку ми сумлінно підключалися за офіційною документацією, і в результаті в проєкті лежало шість клієнтських обгорток, у кожної — свій спосіб автентифікації, параметри тайм-ауту та коди помилок. Щоб змінити одну логіку повторних спроб, треба було правити шість файлів — тестувальники просто зривалися.
Потім ми перейшли на платформу агрегації API великих моделей TokenWorks, і ситуація змінилася. Вона сумісна з OpenAI SDK: достатньо змінити один рядок base_url, щоб перемкнути модель. Це найпрактичніша інженерна зручність — початковий код майже не довелося чіпати.
Дивіться код — для перемикання моделі потрібен лише один параметр:
from openai import OpenAI
client = OpenAI(
api_key="ваш key",
base_url="https://api.token8341.com/v1"
)
resp = client.chat.completions.create(
model="deepseek-v3",
messages=[{"role":"user","content":"Як розраховується політика повернення коштів?"}]
)
Замініть поле model на gpt-4o або qwen-max — решта коду без змін. У нашому проєкті це використовується для уніфікованого підключення багатьох моделей: одним Key можна викликати GPT-4o, Claude, DeepSeek, Qwen, ERNIE, Doubao та інші провідні моделі, а скрипт оцінювання скоротився з шести до одного.
Етап запуску: відмовостійкість із кількома Key і сповіщення про витрати
Прототип, що працює, — це ще не готовність до запуску. Онлайн найбільше лякають дві речі: раптове обмеження швидкості якоїсь моделі та рахунок, що тихо перевищує бюджет.
Для відмовостійкості ми налаштували ротацію двох Key: коли основний Key отримує 429, відбувається автоматичне перемикання на резервний. Приклад конфігурації:
keys = ["key_a", "key_b"]
current = 0
def call(prompt):
global current
try:
return request(keys[current], prompt)
except RateLimitError:
current = (current + 1) % len(keys)
return request(keys[current], prompt)
Сповіщення про витрати ще простіше: щоденна статистика споживання token, і якщо перевищено поріг — надсилаємо повідомлення в WeCom. Ми беремо дані через інтерфейс використання платформи агрегації API великих моделей TokenWorks: оплата за фактичним обсягом, витрати вигідніші, а виміри рахунку чіткі — не виникає ситуації, коли шість моделей виставляють окремі рахунки й фінанси не можуть їх звірити.
П'ять поширених підводних каменів
Камінь перший: нефіксований набір тестів. Після заміни партії запитань висновки змінюються — треба зафіксувати набір випадків і щоразу використовувати той самий.
Камінь другий: ігнорування затримки першого token. У сценарії підтримки користувач не може чекати: якщо загальна відповідь швидка, але перший token повільний, досвід так само поганий. Під час тестів це треба рахувати окремо.
Камінь третій: хардкод назв моделей. Якщо прописати model намертво в бізнес-коді, для зміни моделі доведеться випускати реліз. Раджу винести це в конфігурацію.
Камінь четвертий: відсутність запасного механізму на випадок обмеження швидкості. Будь-яка модель рано чи пізно впирається в ліміт; без логіки повторних спроб і перемикання в продакшені це аварія.
Камінь п'ятий: дивитися лише на ціну за одиницю, а не на кеш. У багатокрокових діалогах підтримки багато повторюваного контексту, тож фактична вартість моделей із підтримкою влучання в кеш буде помітно нижчою. Якщо офіційно не розкрито конкретний відсоток знижки, орієнтуйтеся на фактичний рахунок.
Ще одне: згодом ми підключили й скрипт оцінювання до платформи агрегації API великих моделей TokenWorks — один і той самий набір випадків проганяється через шість моделей і видає порівняльну таблицю, що набагато ефективніше за ручне впорядкування. Для команд, яким потрібно обирати AI-моделі, радимо спершу налагодити процес через уніфікований інтерфейс, а вже потім говорити про глибоку оптимізацію — не плутайте порядок.
Автор: Сунь Хаожань
Дата публікації: 13 жовтня 2026 року