![]()
На одном коротком запросе Claude Haiku и GPT Luna могут выглядеть одинаково полезными. На тысяче задач решающими становятся редкие ошибки: перепутанная категория, пустой ответ или уверенная догадка там, где нужен ручной разбор. Именно эти случаи стоит искать до массового запуска.
В Чатиуме можно собрать очередь небольших AI-заданий с проверкой спорных результатов. Начнём с сортировки обращений по отделам — простой функции, у которой хорошо видны последствия неправильного выбора.
Создай сортировщик обращений по отделам. Сравнивай Haiku и GPT Luna на одном наборе сообщений. Показывай выбранную категорию и основание, а неоднозначные случаи отправляй на ручную проверку. Сохраняй исправления и статистику ошибок по категориям.
Почему название «быстрая модель» ещё ничего не решает
Claude Haiku 5.5 и GPT-6 Luna рассчитаны в том числе на массовые задачи с чувствительностью к задержке и расходам. В каталоге OpenRouter на 24 октября 2026 года их базовые ставки для короткого входа совпадают: 0,10 доллара за миллион входных и 0,50 — выходных токенов. Для длинного контекста и дополнительных операций действуют отдельные условия.
Поэтому автоматически выбирать одну из них только по базовой цене в этом примере бессмысленно. Важнее стабильность на ваших данных, длина ответа и число повторов. Время ожидания также измеряют в своём приложении: оно зависит не только от названия модели.
Пример: куда отправить обращение
Пусть есть четыре категории: «доступ», «оплата», «работа продукта» и «нужно уточнение». Сообщение «оплатил, но не могу войти» затрагивает сразу две темы. Если правило компании отдаёт такие случаи отделу доступа с отметкой об оплате, это нужно явно описать в справочнике.
Без правила две разные категории не обязательно означают ошибку модели. Возможно, само задание недоопределено. Сначала согласуйте пограничные случаи, а затем оценивайте маршруты.
| Сообщение | Что важно в проверке |
|---|---|
| «Забыл пароль» | Выбрана категория доступа |
| «Где скачать чек?» | Выбрана категория оплаты |
| «После входа кнопка не реагирует» | Не перепутано с проблемой авторизации |
| «У меня всё сломалось» | Модель не выдумала конкретную причину |
Почему общая точность может скрывать проблему
Представим учебную выборку: девятьсот простых обращений и сто сложных. Если система хорошо сортирует первые и ошибается почти во всех вторых, итоговая цифра может выглядеть прилично. Но именно сложные обращения будут постоянно теряться между отделами.
Считайте ошибки по категориям и по степени неоднозначности. Отдельно отмечайте отказ от уверенного выбора: он может быть правильным результатом, если сообщение не содержит нужных сведений. Требование «всегда выбирай один отдел» искусственно улучшит заполненность полей, но ухудшит смысл.
Для массовой очереди важна повторяемость обработки. Один и тот же запрос не должен создавать две независимые записи только потому, что пользователь повторно нажал кнопку. Это уже задача приложения, а не способность Haiku или Luna.
Как сравнить маршруты в Чатиуме
В sourceText передайте справочник категорий, правила спорных случаев и одно обращение. Сначала используйте небольшой размеченный набор, затем расширяйте очередь.
Ниже — серверный фрагмент для одинакового задания двум моделям. ctx даёт Чатиум, sourceText содержит один и тот же проверенный исходник. done и failed — зарегистрированные обработчики app.function, которые проверяют источник вызова: caller.type === 'plugin' && caller.appSlug === 'start'.
import { startCompletion } from '@start/sdk'
const jobs = []
for (const model of ['anthropic/claude-haiku-5.5', 'openai/gpt-6-luna']) {
const { completionId } = await startCompletion(ctx, {
model,
system: 'Выбери категорию обращения по данному справочнику и правилам. Объясни основание одной фразой. Если данных недостаточно, выбери категорию уточнения.',
messages: [{ role: 'user', content: [{ type: 'text', text: sourceText }] }],
onCompletionCompleted: done,
onCompletionFailed: failed,
})
jobs.push({ model, completionId })
}
В jobs лежат идентификаторы задач, а не готовые ответы. Приложение сохраняет соответствие модели и completionId, принимает результаты позже через обработчики и показывает отдельное состояние каждого запуска. Полный интерфейс и хранение в этот короткий пример не входят.
В рабочей версии ограничьте число одновременных задач, храните состояние каждой и допускайте повтор только по понятному правилу. Для машинной обработки результата полезен строгий формат ответа, но проверка допустимой категории всё равно остаётся на сервере.
Частые вопросы
Стоит ли сразу прогонять тысячу сообщений?
Сначала проверьте небольшой набор с известными ответами и пограничными случаями. Это дешевле, чем потом разбирать тысячу неверно распределённых обращений.
Какая модель быстрее?
Без измерения вашего маршрута и задания честного общего ответа нет. Сравнивайте одинаковый вход, длину результата и фактическое время до готового ответа.
Можно ли убрать человека из процесса?
Для однозначных проверенных случаев автоматизация может быть полезна. Спорные сообщения лучше оставлять в отдельной очереди. Похожий сценарий есть в разборе входящих заявок.