Коротко
Единый API-ключ упрощает подключение OpenAI, Claude и Gemini, но не гарантирует одинакового поведения моделей. Для SaaS, оценивающего резюме по критериям вакансии, автор предлагает версионируемый контракт, локальную проверку результатов и набор из шести тестов до допуска модели к рабочему трафику.
Контекст
Автор описывает архитектуру небольшого SaaS для оценки кандидатов по рубрике вакансии. Исходная проблема — недопустимо считать модели взаимозаменяемыми лишь потому, что к ним можно обращаться через схожий интерфейс: неподтверждённый балл может повлиять на решение о найме.
Главное
- Объединять провайдеров стоит за доменным методом scoreCandidate(), а не за универсальным chat(): общий формат запросов обеспечивает совместимость транспорта, но не результатов.
- В контракте запроса есть rubricVersion, критерии с id, description и weight, а также candidateText. Результат содержит версию рубрики и оценки по критериям.
- Оценка критерия — 0, 1, 2 или null. Ноль означает, что критерий не пройден; null — что данных недостаточно для вывода.
- Адаптер возвращает unknown, а приложение проверяет результат локально: совпадение версии рубрики, известные и неповторяющиеся ID, полный набор критериев, допустимые оценки и строковые свидетельства.
- Итоговый взвешенный балл вычисляется в приложении, а не моделью. Если хотя бы один результат равен null, общий балл не формируется.
- Перед запуском предлагается проверять каждый конкретный провайдер и модель по шести сценариям: сильные подтверждения, отсутствие данных, противоречие, инструкция-подмена в резюме, длинная биография и почти одинаковые кандидаты около порога.
- Продвижение в продакшен разрешается после прохождения всех шести тестов; вместе с развёртыванием сохраняют нормализованные результаты проверок и отпечаток конфигурации.
- Ошибки нужно различать: для недопустимого вывода возможна ограниченная попытка исправления, затем — ручная проверка; отказ по политике не следует трактовать как некорректный JSON или нулевой балл.
- Резервная модель тоже должна пройти ту же версию тестов. В записи оценки необходимо указывать, какая цель фактически обработала запрос; незаметно подменять модель нельзя.
Как сделано
Автор предлагает описать контракт предметной области независимо от терминов конкретного провайдера и обернуть каждую модель адаптером ScoringTarget. Ответ адаптера остаётся недоверенным до локальной проверки схемы и бизнес-правил. Для промышленной реализации рекомендуется поддерживаемая библиотека схем, но сами проверки должны отражать требования продукта.
При ошибках следует действовать ограниченно и явно: сетевые сбои и лимиты могут допускать повтор с задержкой, усечённый ответ — ограниченную попытку исправления, после которой случай передаётся на ручную проверку. Неизвестные данные нельзя молча превращать в отказ или зачёт. Интерактивные запросы и отложенную пакетную обработку автор предлагает моделировать как разные процессы; OpenAI Batch API описан как цикл загрузки входа, создания задания, проверки статуса и получения результата.
Для каждой пары «провайдер — точная модель» запускают шесть фиксированных тестов. В частности, проверяют, что инструкция внутри текста резюме не заменяет рубрику, а оценка опирается на сведения о кандидате. В журнале развёртывания сохраняют версию адаптера и рубрики, ID цели, задержку, результат проверки, число повторов и ID корреляции; необработанные резюме не следует помещать в обычные логи.
Результаты
Предложены архитектурный контракт и минимальный набор из шести приёмочных сценариев для проверки моделей перед производственным использованием. Статья не сообщает о проведённом сравнительном тестировании моделей, численных показателях качества или фактическом внедрении; описанный результат — практический план разработки и допуска.
Ограничения
Шесть сценариев названы минимальной отправной точкой, а не универсальным бенчмарком: они не доказывают одинаковое качество во всех задачах, отраслях и типах рубрик. В статье нет измерений точности, стоимости, задержки или эффекта на решения о найме. Результаты зависят от конкретной версии модели, адаптера и рубрики. Обработка конфиденциальных резюме требует отдельных правил доступа и хранения. Пакетная обработка упомянута кратко; технической реализации адаптеров и тестового стенда не приведено.
Что взять себе
- Не считайте модели взаимозаменяемыми из-за общего API: закрепляйте точную модель и проверяйте её на ожидаемом поведении продукта.
- Отделяйте отсутствие данных от отрицательного результата: null сохраняет неопределённость и помогает не создавать ложную точность.
- Проверяйте ответы модели в приложении и рассчитывайте итоговые баллы детерминированно, по правилам продукта.
- Для переключения или резервной модели требуйте прохождения тех же тестов и записывайте, какая модель выдала результат.
- Не логируйте резюме без необходимости; сохраняйте версии, исход проверки и технические метаданные, нужные для расследования сбоев.
Читать оригинал, если…
Откройте оригинал, если нужны точные типы TypeScript, таблица шести тестовых случаев и ссылки на руководство OpenAI Batch API.