Честные запасные варианты: детерминированная классификация, когда модель не работает

Почему это важно SaaS-продукты на базе искусственного интеллекта сталкиваются с неприглядной реальностью: время ожидания моделей истекает, API-интерфейсы ограничены по скорости, а у провайдеров бывают плохие дни. Продукт все еще должен ответить. Вопрос в том, что он говорит, когда умный путь недоступен. Детерминированная классификация как запасной вариант Мы постоянно возвращаемся к шаблону, заключающемуся в сохранении детерминированного классификатора рядом с классификатором, основанным на модели. Оценка ключевых слов на основе правил, маршрутизация с точным соответствием и конвейеры с конечным состоянием могут охватывать значимый фрагмент запросов вообще без каких-либо выводов. Маршрутизация по ключевому слову + регулярному выражению дешево охватывает наиболее распространенные намерения. Конвейеры конечных состояний дают проверяемые, повторяемые решения. Кэшированные внедрения позволяют поддерживать поиск ближайших соседей во время сбоев в работе провайдера. Дело не в том, что правила побеждают модели. Речь идет о том, что предсказуемый ухудшенный режим лучше ошибки 500. Принципы проектирования резервных вариантов Деградируйте, не разбивайтесь. Каждая конечная точка, поддерживаемая моделью, должна иметь определенный немодельный путь, даже если он уже. Обозначьте режим. Сообщайте пользователям, когда они выбирают детерминированный путь: честность вызывает больше доверия, чем притворство, что медленный ответ был быстрым. Зарегистрируйте дельту. Отслеживайте, как часто срабатывает резервный вариант и как он работает.