Использование API OpenAI для проверки европейских логистических адресов: мы сэкономили 32% на трудозатратах и избежали двух серьезных ошибок.

На прошлой неделе завершилась акция с большими скидками «Черная неделя», и во время встречи по анализу результатов наша техническая команда обнаружила, что в этом году процент успешной автоматической проверки адресов увеличился на 41% по сравнению с прошлым годом. Также стало ясно, что в этом году достаточно оставить только одного сотрудника на временной основе, который ранее занимался обработкой неисправных адресов, вместо трех.

Но никто не хочет говорить о проблеме с ошибкой 429, с которой мы столкнулись в прошлом месяце — в самые загруженные три часа первого дня акции скидок.13% запросов на разрешение адресов возвращаются непосредственно обратно.Клиентская служба полностью вышла из строя, и команда операций чуть не пришла, чтобы перевернуть наши столы.

Для тех, кто с этим никогда не сталкивался: что же такое API от OpenAI на самом деле?

Вы просто не нужны тренировать собственные большие модели – достаточно воспользоваться уже подготовленными моделями OpenAI, такими как GPT-4o и GPT-3.5-turbo, и отправить запрос. В ответ будет получен результат, который будет рассчитан в зависимости от количества использованных токенов. Версия, поддерживающая до 128 килобайт контекста для одного запроса, теперь полностью доступна.

Причина, по которой мы выбрали это решение, была очень проста: форматы адресов в европейских странах слишком разнообразны. Например, почтовые индексы в Великобритании сильно отличаются от форматов в Германии, а также существуют ошибки в написании адресов на разных языках. Ранее созданная нами база правил обновлялась 8 раз за полгода, но все равно пропускала некоторые случаи неверного формата адресов. С использованием API для семантического анализа точность распознавания адресов увеличилась более чем на 96%, если правильно задать параметры запроса (prompt).

Мы действительно получили три реальных преимущества, без ничего лишнего.

• Не нужно создавать отдельную команду специалистов по алгоритмам для настройки моделей; три бэкенда смогли завершить работу по интеграции интерфейсов за неделю. В первый месяц после запуска системы были сэкономлены затраты на труд трех сотрудников, работавших на полставки, на 32%.
• Ранее библиотека правил не могла автоматически исправлять ошибки правописания и адреса в форматах сокращений; теперь более 90% таких ошибок устраняются. В результате количество отклонений заказов из-за неправильно введенных адресов снизилось на 28% во время оформления заказов пользователем.
• Поддерживается смешанный ввод на нескольких языках: пользователи из Польши могут вводить адреса на польском языке, а пользователи из Испании — на испанском. Не требуется отдельная локализация; достаточно передать данные интерфейсу, и они будут автоматически преобразованы в стандартный формат логистики.

Не смотря только на преимущества, из-за этих двух ошибок мы чуть не попали в беду.

Первая проблема заключается в стандартном ограничении количества запросов по одной модели. Ранее мы использовали только GPT-4o-mini, и стандартное ограничение, установленное на минутовой основе, вполне хватало для обычной работы. Однако в день крупной акции количество запросов увеличилось в три раза, что привело к активации механизма ограничения. 13% запросов получили ошибку 429. Впоследствии мы внесли дополнительные меры по снижению нагрузки, перенаправляя запросы, не приходящие в час пик, на GPT-3.5-turbo, что помогло решить проблему.

Вторая проблема заключается в неправильном определении конфиденциальных адресов. Однажды пользователь ввел адрес, содержащий слова, связанные с военной базой, и его запрос был немедленно заблокирован системой проверки контента API. Мы не предусмотрели механизмов обработки ошибок, в результате чего заказ застрял на два дня и не был отправлен, что привело к тому, что пользователь оставил негативный отзыв.

Кому это нужно? Не стоит тратить деньги впустую.

Если вы, как и мы, занимаетесь бизнесом, связанным с обработкой семантики на нескольких языках и сталкиваетесь с ситуациями, когда количество правил для решения задач невозможно полностью описать, например, при проверке адресов, автоматическом ответировании на вопросы пользователей или генерации контента на разных языках, и в вашей команде нет специализированной группы по разработке алгоритмов, то использование API от OpenAI будет гораздо экономичнее, чем создание собственных моделей.

Но если вы занимаетесь бизнесом, где критически важно, чтобы данные не покидали пределы вашей системы (например, обработкой финансовых данных, анализом медицинской конфиденциальной информации), или если объем запросов очень стабилен и правила их обработки четко определены, тогда не стоит участвовать в таких инициативах. Создание собственных правил или развертывание небольших моделей на месте может сэкономить средства и обеспечить большую безопасность.

Три совета для тех, кто использует это инструмент впервые – все они основаны на наших собственных ошибках и уроках.

• Не ограничивайтесь использованием только одной модели – подготовьте как минимум две модели разного уровня качества для аварийного сценария. Для запросов с высокими требованиями используйте модели с высокой точностью, а для запросов с низкими требованиями или в периоды пиковой нагрузки применяйте более дешевые модели. Таким образом, вы сможете сэкономить не менее 40% затрат и избежать проблем, связанных с ограничениями производительности одной модели.
• Для всех запросов необходимо внедрить логику усиленных попыток выполнения и аварийных механизмов. Планы действий на случаи проверки контента, ограничения количества запросов и превышения временных рамок должны быть заранее разработаны. Не стоит ждать, пока интерфейс перестанет работать, чтобы начать ручное решение проблем.
• Не стоит сразу использовать самые сложные (самые продвинутые) модели – сначала протестируйте их с помощью самых дешевых вариантов (например, GPT-3.5-turbo). Если результаты не удовлетворительны, тогда переходите к более совершенным моделям. Для большинства простых сценариев небольшие модели вполне подойдут.

В заключение я хочу ответить на два вопроса, которые часто задают.

Вопрос: Будет ли слишком большая задержка при вызовах из европейского региона?
Ответ: Мы используем узел во Франкфурте, и большинство запросов выполняются в течение 15 миллисекунд; лишь небольшой процент из них внезапно занимает более 200 миллисекунд. Добавление кэша решит эту проблему, и это совсем не повлияет на работу сервиса.

Вопрос: Может ли возникнуть ситуация, когда результаты анализа будут неверными?
Ответ: Да, сейчас мы переводим результаты, у которых уровень доверия меньше 80%, на ручную проверку. После внедрения этого правила уровень ошибок практически стал незначительным.